EIP-2225: Methods to Merge Ethereum Blockchains Together #2225
There are no files selected for viewing
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,126 @@ | ||
| --- | ||
| eip: 2225 | ||
| title: Methods to Merge Ethereum Blockchains Together | ||
| author: Wei Tang (@sorpaas) | ||
| discussions-to: https://github.com/sorpaas/EIPs/issues/8 | ||
| status: Draft | ||
| type: Standards Track | ||
| category: Core | ||
| created: 2019-08-02 | ||
| requires: 155, 1702 | ||
| --- | ||
|
|
||
| This EIP defines methods that can be adopted to merge two | ||
| Ethereum-like blockchains together. | ||
|
|
||
| Note that this EIP is purely an exploration of technical | ||
| possibilities, and it does not mean the author endorse merging | ||
| Ethereum and Ethereum Classic, or any other two blockchains together. | ||
|
|
||
| ## Simple Summary | ||
|
|
||
| We define methods to merge multiple blockchains together, in a fully | ||
| backward compatible way. | ||
|
|
||
| ## Abstract | ||
|
|
||
| This defines how Ethereum merging can happen, with backward | ||
| compatibility in mind. This is done by utilizing account versioning | ||
| together with transaction replay protection. We also define three | ||
| additional opcodes to allow merged chains to work across two sides of | ||
| state. | ||
|
|
||
| ## Motivation | ||
|
|
||
| There are many reasons why we may want to merge multiple Ethereum | ||
| (eth1.x) blockchains together. For example, there may have been chain | ||
| splits of a blockchain, where later the community issues are resolved, | ||
| and we want to avoid a permanent split due to a temporary issue. It | ||
| may also be two completely distinct blockchains that want to merge in | ||
| order to share proof of work, or to improve inter-chain communication. | ||
|
|
||
| ## Specification | ||
|
|
||
| The merge process happens at fork block, where we have a **merger** | ||
| chain and a **mergee** chain. At fork height, a miner should mine both | ||
| a merger chain's block, and a mergee chain's block. For those two | ||
| blocks: | ||
|
|
||
| * Both of them should have no transactions. | ||
| * Merger chain's fork height block and mergee chain's fork height | ||
| block should have its state root processed as normal. | ||
| * Merger chain's fork height block should set its extra data field to | ||
| mergee chain's fork height block's state root. The same for mergee | ||
| chain's fork height block. | ||
| * After mergee chain's fork height block, its proof of work should be | ||
| abandoned. That is, updated miners should not continue to mine | ||
| mergee chain any more. | ||
|
|
||
| ### State Root | ||
|
|
||
| For the block after merger chain's fork height block, the state root | ||
| meaning is changed to be hash of concatenating merger chain's original | ||
| state root, and mergee chain's original state root. | ||
|
|
||
| ### Block Rewards | ||
|
|
||
| Use merger chain's original block rewards. And mine coinbase always to | ||
| the merger chain's side of the state. | ||
|
|
||
| ### Transactions and Account Versioning | ||
|
|
||
| After merge, transactions with both chain ids are considered valid on | ||
| the merger chain. We define two account versions, one with merger | ||
| chain's original EVM config, and one with mergee chain's original EVM | ||
| config. Accessing accounts originally from either chain should use | ||
| EIP-1702's account versioning rules. We define how accounts are | ||
|
There was a problem hiding this comment. What about an account with the same address on both chains? EIP-1702 is an attribute on an account not a selector (currently) so an account has only one version. There was a problem hiding this comment. They work perfectly well, and in backward compatible way. We have a top level binary merkle tree to distinguish them, and all previous opcodes functions on one side. For cross side communication we added several new opcodes. |
||
| referred on the merged blockchain below: | ||
|
|
||
| * For end user interface, prefix `0x01` for accounts on the merger | ||
|
There was a problem hiding this comment. Would this be prepended to the preimage for the account state root of the entire account tree? Or just UX? There was a problem hiding this comment. The prepend is just UX. |
||
| chain, and prefix `0x02` for accounts on the mergee chain. | ||
| * The transaction format is unchanged with addresses using original | ||
| format. We distinguish whether a transaction operates on merger chain | ||
| or mergee chain by its chain id. None replay protected transactions | ||
| must be disabled prior to merging. | ||
| * All original opcodes `CALL*`, `CREATE*` are unchanged, where it only | ||
| accesses accounts on the same originating chain. | ||
|
|
||
| ### Cross the Merger and Mergee Chain Boundary | ||
|
|
||
| Define factor `P // Q`, which determines how coins are exchanged on | ||
|
There was a problem hiding this comment. what are the variables There was a problem hiding this comment.
I think that is subject to negotiation (something that would be very chaotic in decentralized systems, but very interesting as a thought experiment). I see two models:
Mathematically, both cases are identical, that is, nobody loses value, but the second case eliminates bimonetarism and creates a single new currency. On the other hand, the above currency merger models have the problem that one or the other currency may be at a disadvantage if the market caps are very different, for example ETH is 32-to-1 with respect to ETC. In that case it's a matter of negotiation and for both ecosystems to set an exchange rate that is convenient for both. There was a problem hiding this comment. It all depends on whether the merger is accretive. If both systems together are worth more than the sum of their part before the merger, then it would be convenient for both ecosystems. OTOH, there are roadmaps, philosophies and future monetary policies to homogenize in case of merger. There was a problem hiding this comment. hmmm thats interesting... #1 is interesting, im assuming one of them will need to be the reward token |
||
| merger chain and mergee chain. Define three new opcodes `MCALL`, | ||
| `MCREATE` and `MCREATE2`. They function the same as `CREATE`, `CALL` | ||
| and `CREATE2` with the same gas cost, except that it calls accounts on | ||
| the other side of the state. Values `V` to be exchanged are computed as | ||
| `V * P // Q` from merger side of state to mergee side of state, and | ||
| `V * Q // P` from mergee side of state to merger side of state. | ||
|
|
||
| ## Rationale | ||
|
|
||
| This EIP accomplishes the chain merge by concatenating two blockchain's | ||
| state root. In clients, this can be represented as a simple depth one | ||
| binary merkle tree where root's left is the merger state, and root's | ||
| right is the mergee state. We use account versioning and transaction | ||
| replay protection to make it backward compatible for full nodes, | ||
| without changing any internal address representation or transaction | ||
| representation. We then define additional opcodes to make two sides | ||
| communicatable. | ||
|
|
||
| ## Backwards Compatibility | ||
|
|
||
| This EIP is fully backward compatible for EVM and account states. It | ||
| is not backward compatible for light client state proof verification, | ||
| because an additional binary merkle tree is added. | ||
|
|
||
| ## Test Cases | ||
|
|
||
| To be added. | ||
|
|
||
| ## Implementation | ||
|
|
||
| To be added. | ||
|
|
||
| ## Copyright | ||
|
|
||
| This work is licensed under a [Creative Commons Attribution-ShareAlike | ||
sorpaas marked this conversation as resolved.
Show resolved
Hide resolved
|
||
| 4.0 International](https://creativecommons.org/licenses/by-sa/4.0/). | ||
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
How can merger and mergee know the other's fork block height state root if they are waiting for the other to actually finish their blocks?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Prior to the fork block, those miners that support the merge should maintain chain of both merger and mergee (as normal full nodes, meaning it should handle shadow reorg). On fork height, the miner broadcast two “cousin” blocks together, of both merger and mergee. Other nodes only accept those two cousin blocks if both of them are in the node’s local state. From this point on, every node who accepts the cousin fork blocks have the same view of the merger and mergee’s state root.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This implies both chains have to reach their fork height at the same time so they know the state root from the other chain. Given how hard it is to predict when a particular block height will be reached, that creates a significant potential for one chain to stall for quite a long time waiting for the other to catch up.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Good point, but I suppose this can be fixed by only setting the fork block for merger chain, and let the miner decide mergee chain's head.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Or, maybe, instead of using a single block as a "fork block" to use a 3 step process:
So there would be three fork blocks A, B, and C (A and C in merger chain, and B in mergee chain). After 'C' the chains are merged.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I think there may be fork choice issues in that. The reason why we have the setup in this EIP is that we ensure merger fork block and mergee fork block are produced at the same time.