Design for the future of Ethermint #295
Conversation
Codecov Report
@@ Coverage Diff @@
## develop #295 +/- ##
========================================
Coverage 24.91% 24.91%
========================================
Files 11 11
Lines 578 578
========================================
Hits 144 144
Misses 410 410
Partials 24 24
Continue to review full report at Codecov.
|
|
A question: How should we handle private keys and access to them? Should we support unlocking of an account? Where does the keystore and the USB interface get integrated? |
docs/architecture.rst
Outdated
| The first entry point is installing ethermint and the underlying tendermint binary. This is as easy as | ||
| ``brew install ethermint``. It pulls both binaries, since tendermint is a dependency of ethermint and | ||
| places them in the correct folders. On Linux distros this process should be the same using ``apt-get``. | ||
| On Windows this should be done with chocolate. |
docs/architecture.rst
Outdated
| On Windows this should be done with chocolate. | ||
|
|
||
| To check whether the binaries are installed correctly a user can use the version command | ||
| ``ethermint version``. This prints the versions of the installed binaries of ethermint and tendermint. |
There was a problem hiding this comment.
how was tendermint installed? bit of a pain to install both binaries, no?
There was a problem hiding this comment.
The tendermint binary will be a dependency of ethermint.
When a user performs brew install ethermint brew will also install the tendermint binary since it is a dependency. The same scenario applies to apt-get.
For users that don't want to use package managers we will need to eventually create an install script like this that figures out the platform it is on and then installs the correct binaries in the correct places. This, however, is a future thing.
docs/architecture.rst
Outdated
| To connect to a live network the command simply is ``ethermint``. This initialises tendermint and | ||
| ethermint to with the correct values and starts both processes, which then start syncing. | ||
|
|
||
| To connect to a test network the command simply is ``ethermint testnet``. This does the same |
There was a problem hiding this comment.
what if there are multiple testnets? should there be a argument to specify the name of the testnet?
There was a problem hiding this comment.
Yes, eventually the command will have flags to specify which testnet.
ethermint testnet - default testnet
ethermint testnet --kovan - kovan testnet
ethermint testnet --ringby - ringby testnet
docs/architecture.rst
Outdated
| To connect to a test network the command simply is ``ethermint testnet``. This does the same | ||
| initialisation as above but uses the testnet configuration. | ||
|
|
||
| To run a private network the command simply is ``ethermint development``. This does the same |
There was a problem hiding this comment.
why not just ethermint init --testnet=private ?
There was a problem hiding this comment.
There is no init command anymore. The initialisation happens implicitly.
To run a private testnet simply issue ethermint development. Maybe there can be flags so that you can easily run multiple different testnets.
ethermint development custom1
ethermint development --pluto
ethermint development --water
And all these private networks live in the same folder organised by the flag name. I'm not too sure about this feature yet, so it's something that we can discuss once we are there.
|
I've added an explanation of how accounts can fit into the picture. The RPC needs access to the account object, but then this design should be able to provide all the use cases that we currently have for ethermint. This design is much cleaner than what go-ethereum currently has since we pulled a bunch of pieces out. Also, it will allow developers to use ethermint as a library. In the future, we could consider adding some of the other ethereum features such as whisper, but I don't think they provide massive usefulness to the general public. Ethermint will offer really fast, library ready implementation of ethereum with a readable code base, a permissive license and PoS. It will also provide IBC and connect to the cosmos hub. |
docs/architecture.rst
Outdated
| and creating an ethereum transaction from it that calls a special privileged smart contract. | ||
| Sending an IBC packet should be triggered by the web3 endpoints and involves providing a merkle proof | ||
| of some data, where the root hash matches the app hash. | ||
|
|
There was a problem hiding this comment.
Tokens are generally represented as separate ERC20 contracts in Ethereum.
IMO processing an IBC transactions is best represented as a precompiled contract.
Design questions
Should IBC packets be able to address individual contracts on an ethereum chain or should all IBC packets be routed into a single contract on the chain?
I also think a precompiled Query tx can be used for generating IBC packets.
I'm currently leaning towards a preference for IBC packets being processable by any contract but the IBC packet from the HUB needs to specify the contract that it is addressed to.
adrianbrink
force-pushed
the
feature/design
branch
from
75dfb5d to
99fff77
Compare
|
| Optionally a user can configure these global flags: | ||
| Non-consensus - these can be different between all nodes | ||
| * ``--gasprice`` sets the minimal gasprice for this node to include a transaction | ||
| * ``--coinbase`` sets the address which receives the rewards (this depends on implementation of |
There was a problem hiding this comment.
s/coinbase/rewards-address/ perhaps? I suggest this because in basecoin, we had to add a disclaimer that the repo wasn't in anyway related to coinbase.
| * accounts - an account manager that manages private keys stored under this ethermint node | ||
| * logger - a tendermint logger | ||
|
|
||
| The Ethermint object is responsible for settinp up the ethereum object and starting the rpc server. |
There was a problem hiding this comment.
Minor nit: s/settinp/setting/g
| Accounts | ||
| """""""" | ||
| Accounts wraps a go-ethereum account manager and provides that functionality. Accounts cannot be unlocked | ||
| by default when starting ethermint as that is a security risk. They have to be unlocked through some GUI. |
There was a problem hiding this comment.
I wonder, how shall we enforce this? Perhaps it doesn't have to be a GUI but some sort of challenge based authentication?
| The ethereum object is responsible for validating ethereum transactions and running them against a state. | ||
| All VM, state and state transition logic is imported from go-ethereum. It handles tendermint messages | ||
| such as BeginBlock and EndBlock. An important function is be able to respond to Commit. | ||
| Ideally, ethereum should not build its own blockchain but should rather just provide a databse layer and |
| - responds to notifications from ethereum full node by minting fresh CETH | ||
| - sends transaction that invoke release function on ethereum | ||
|
|
||
| ## Economic Incentive | ||
| Economic Incentive | ||
| ------------------ | ||
| Ethermint can take a percentage of the CETH is a transaction fee. |
adrianbrink
force-pushed
the
feature/design
branch
from
4219d62 to
270cf07
Compare
This document explains the ideal Ethermint architecture. The current design is similar but less modular. From this starting point we will start an incremental refactor until we are at this design. The design itself is not perfect and will change over time.
By splitting Ethermint up this way, we have the ability to add custom RPC endpoints. This allows the addition of special IBC endpoints which will be needed for IBC.
This adds a description of a light client for ethermint which leverages the properties of tendermint to provide a fully secure EVM light client. A light client can keep of with the state and doesn't have to trust a single node. Furthermore it can submit transactions.
I've added a paragraph that explains how accounts are managed by an ethermint instance. This is the last missing piece as now ethermint provides all the functionality in a coherent way that we need it to.
adrianbrink
force-pushed
the
feature/design
branch
from
c68a4a6 to
8dab51b
Compare
This document explains the ideal Ethermint architecture. The current design is similar but less modular. From this starting point, we will start an incremental refactor until we are at this design. The design itself is not perfect and will change over time. By splitting Ethermint up this way, we have the ability to add custom RPC endpoints. This allows the addition of special IBC endpoints which will be needed for IBC. This adds a description of a light client for ethermint which leverages the properties of tendermint to provide a fully secure EVM light client. A light client can keep of with the state and doesn't have to trust a single node. Furthermore, it can submit transactions. I've added a paragraph that explains how accounts are managed by an ethermint instance. This is the last missing piece as now ethermint provides all the functionality in a coherent way that we need it to. * Extend architecture with IBC and Rewards * Reason why we need this redesign * Explanation for accounts * Add time estimate * Simplify future design * More IBC explanations * Light client explanation
This document explains the ideal Ethermint architecture. The current design is similar but less modular. From this starting point, we will start an incremental refactor until we are at this design. The design itself is not perfect and will change over time. By splitting Ethermint up this way, we have the ability to add custom RPC endpoints. This allows the addition of special IBC endpoints which will be needed for IBC. This adds a description of a light client for ethermint which leverages the properties of tendermint to provide a fully secure EVM light client. A light client can keep of with the state and doesn't have to trust a single node. Furthermore, it can submit transactions. I've added a paragraph that explains how accounts are managed by an ethermint instance. This is the last missing piece as now ethermint provides all the functionality in a coherent way that we need it to. * Extend architecture with IBC and Rewards * Reason why we need this redesign * Explanation for accounts * Add time estimate * Simplify future design * More IBC explanations * Light client explanation
This document explains the ideal Ethermint architecture. The current design is similar but less modular. From this starting point, we will start an incremental refactor until we are at this design. The design itself is not perfect and will change over time. By splitting Ethermint up this way, we have the ability to add custom RPC endpoints. This allows the addition of special IBC endpoints which will be needed for IBC. This adds a description of a light client for ethermint which leverages the properties of tendermint to provide a fully secure EVM light client. A light client can keep of with the state and doesn't have to trust a single node. Furthermore, it can submit transactions. I've added a paragraph that explains how accounts are managed by an ethermint instance. This is the last missing piece as now ethermint provides all the functionality in a coherent way that we need it to. * Extend architecture with IBC and Rewards * Reason why we need this redesign * Explanation for accounts * Add time estimate * Simplify future design * More IBC explanations * Light client explanation
This document explains the ideal Ethermint architecture. The current design is similar but less modular. From this starting point, we will start an incremental refactor until we are at this design. The design itself is not perfect and will change over time. By splitting Ethermint up this way, we have the ability to add custom RPC endpoints. This allows the addition of special IBC endpoints which will be needed for IBC. This adds a description of a light client for ethermint which leverages the properties of tendermint to provide a fully secure EVM light client. A light client can keep of with the state and doesn't have to trust a single node. Furthermore, it can submit transactions. I've added a paragraph that explains how accounts are managed by an ethermint instance. This is the last missing piece as now ethermint provides all the functionality in a coherent way that we need it to. * Extend architecture with IBC and Rewards * Reason why we need this redesign * Explanation for accounts * Add time estimate * Simplify future design * More IBC explanations * Light client explanation
I have written my ideal architecture for Ethermint. It allows us to provide a much better experience towards the end user of ethermint, for example when connecting to testnets or the live network. Furthermore, it is designed to be used as a library and hence other people can write their own implementations of Ethermint, which run on top of Tendermint but might use a different reward strategy. Moreover it clears up the Ethermint implementation and removes a lot of the weird hacks that we currently do around go-ethereum. For example, mining simply does not exist and we configure the RPC endpoints to play nicely with Tendermint. Lastly, it will feel like Tendermint and COSMOS hub, since it has a similarly structured CLI. It is also designed to handle IBC.
Implementations:
#224 - started work on parsing config toml files