EIP-2225: Methods to Merge Ethereum Blockchains Together #2225
Conversation
sorpaas
changed the title
|
I like the concept from an enterprise chain prospect. Defining |
| EIP-1702's account versioning rules. We define how accounts are | ||
| 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.
| 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.
|
Few questions from an economic perspective:
|
|
Hello
I really need cash. Financial problems . I do not know where I can get it
from. Do you have any idea.
sob., 3 sie 2019, 08:18 użytkownik Gregory Markou <notifications@github.com>
napisał:
… Few questions from an economic perspective:
1. What chain balance is kept, the merger or the mergee, or both? I
for-see inflationary issues.
2. Based on the above answer this may not be relevant. If a contract
from the mergee held value (i.e an escrow contract) what would occur?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2225?email_source=notifications&email_token=AJGST4PQMOJ6WX5H7WFTLTTQCUPLZA5CNFSM4IIZEO52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3PIEJQ#issuecomment-517898790>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AJGST4MNOMBP5LU2RWIVOUDQCUPLZANCNFSM4IIZEO5Q>
.
|
|
Hi yes am ist interessant
sob., 3 sie 2019, 08:18 użytkownik Gregory Markou <notifications@github.com>
napisał:
… Few questions from an economic perspective:
1. What chain balance is kept, the merger or the mergee, or both? I
for-see inflationary issues.
2. Based on the above answer this may not be relevant. If a contract
from the mergee held value (i.e an escrow contract) what would occur?
—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
<#2225?email_source=notifications&email_token=AJGST4PQMOJ6WX5H7WFTLTTQCUPLZA5CNFSM4IIZEO52YY3PNVWWK3TUL52HS4DFVREXG43VMVBW63LNMVXHJKTDN5WW2ZLOORPWSZGOD3PIEJQ#issuecomment-517898790>,
or mute the thread
<https://github.com/notifications/unsubscribe-auth/AJGST4MNOMBP5LU2RWIVOUDQCUPLZANCNFSM4IIZEO5Q>
.
|
|
| 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. |
There was a problem hiding this comment.
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.
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.
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.
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.
Or, maybe, instead of using a single block as a "fork block" to use a 3 step process:
- Merger chain reaches fork block 'A' and generates a fork block state root.
- Mergee chain "sees" the merger chain's fork block 'A' state root and includes it in its fork block 'B' extra data field, and it generates its own state root.
- Merger chain "sees" the mergee chain's fork block 'B' state root and includes it in its fork block 'C' extra data field.
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.
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.
Ok so this also proposes a massive increase in the total inflation? |
|
|
||
| ### 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 P and Q?
There was a problem hiding this comment.
Ok so this also proposes a massive increase in the total inflation?
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:
-
Where both currencies are preserved and the new merged chain continues as a bimonetary system. This is not "massive inflation" it's just adding two currencies. However one may be redundant just because before there were 2 underlying systems and now only one.
-
Where the currencies are merged into one new currency using their pre-merger market caps as proxy for distribution of the new coins. In this, two coins that have ~110 million in stock each can be merged into a single stock of, say, 100 million where holders of each coin get proportional coins depending on their pre-merger market cap proportions.
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
|
The specification is now at https://specs.that.world/37-merge/ with the ECIP realization as ECIP-1071 https://ecips.ethereumclassic.org/ECIPs/ecip-1071 |
The specification is now at https://specs.that.world/37-merge/ with the ECIP realization as ECIP-1071 https://ecips.ethereumclassic.org/ECIPs/ecip-1071