Algorithm for Cross-shard Cross-EE Atomic User-level ETH Transfer in Ethereum
AAlgorithm for Cross-shard Cross-EE AtomicUser-level ETH Transfer in Ethereum 2
Raghavendra RameshConsensys Software R & [email protected]
Abstract
We address the problem of atomic cross shard value transfer in Ethereum 2. Weleverage on Ethereum 2 architecture, more specificially on Beacon chain andcrosslinks, and propose a solution on top of the netted-balance approach thatwas proposed for EE-level atomic ETH transfers. We split a cross-shard transferinto two transactions: a debit and a credit. First, the debit transaction isprocessed at the source shard. The corresponding credit transaction is processedat the destination shard in a subsequent block. We use netted shard statesas channels to communicate pending credits and pending reverts. We discussvarious scenarios of debit failures and credit failures, and show our approachensures atomicity even in the presence of a Byzantine Block proposer.The benefits of our approach are that we do not use any locks nor imposeany constraints on the Block Proposer to select specific transactions. Howeverwe inherit the limitation of an expensive operation from the netted-balanceapproach of querying partial states from all other shards.
Keywords: cross-shard, Ethereum 2, atomicity, netted-balance
Ethereum 2 is planned to have 64 shards. The blocks on the shard chainssynchronise with the Beacon chain using crosslinks. The crosslinks are thestateroots (root of Merkle tree of the shard state), and provide a means tovaliditate the integrity of a shard state on another shard.The execution in Ethereum 1 happens in a fixed fashion using EVM andfixed notion of account id and balances. The plan is to generalise this notionof execution environment (EE) in Ethereum 2. For instance, an environmentsimilar to Bitcoin can be hosted on Ethereum 2 as one EE. Some EEs coulduse another virtual machine instead of EVM. The EEs and users of them aredistributed across multiple shards. In such a scenario, the cross-shard cross EE1 a r X i v : . [ c s . D C ] F e b TH transfers become necessary. This paper presents an algorithm for atomicuser-level ETH transfers between two EEs hosted on two different shards.Because one execution environment is complete in its own means, we need tomaintain ETH balances of each of these execution environments separately. AnEE could provide another currency on top of ETH . Users are associated withEEs in the sense that an EE serves as a home for multiple users. The problemof transferring value from a user a of EE E to another user b of another EE E involves two aspects:1. the transfer of ETH from EE E to EE E , and2. the transfer of values from the user a to user b .Vitalik Buterin proposed a netted balance approach ([1]) for atomic cross-shard transfer of ETH between EEs. This paper proposes user-level atomiccross-shard transfer on top of this netted balance approach of EE-level transfers.We have published this approach at [2]. Vitalik Buterin proposed a netted balance approach ( [1]) for atomic cross-shardtransfer of ETH between EEs. The na¨ıve idea is for every shard to maintain itsbalance of every EE. In the netted-balance approach, every shard maintains thepart-balances of every EE on every other shard.Suppose we have three shards A , B and C . Consider an EE e . Then, thebalance information of e on shard A is distributed on all shards A , B and C . So,each shard now stores an ordered triple of part-balances. For example the e ’sbalance information on A is stored as an ordered triple of the form (10 , , e ’s part-balance on shard A is 10, e ’s part-balance on shard B is 20,and e ’s part-balance on shard C is 30. Continuing the example, suppose wehave triples ( − , ,
20) on B and (1 , − ,
3) on C . To obtain e ’s full balanceon shard A , we need to sum up e ’s part balances on shards A , B , and C , i.e.,10 + ( −
5) + 1 = 6 ETH .The benefit of this arrangement is that the transfer of x ETH from shard A to shard B can be affected by an intra-shard operation only on the source shard(operation completely on A here) by subtracting x ETH from A ’s part-balanceand adding x to B ’s part-balance. The A ’s triple changes from (10 , ,
30) to(10 − x,
20 + x, Atomic User-level Transfer
The core idea of this proposal is to extend and leverage the netted-balanceapproach of distribution of EE-balances to outstanding user-level credits andoutstanding user-level reverts. The netted state (extends the netted balance)is used as a channel to communicate outstanding credits to recipient shard andoutstanding reverts to the sender shard. We now describe the approach in fulldetail now.
For i in natural numbers, let s i ’s denote shards, E i ’s denote execution envi-ronments, a i , b i ’s denote users. We use the concept of System Event messages from [3]. These messages are similar to application event messages in contractcode, but are unforgeable by the application.In our approach, we use one System Event message called
ToCredit , whichincludes: • sender details (shard-id, EE-id, user address), • recipient details (shard-id, EE-id, user address), • transfer amount, • the block number of the shard block where this event is emitted, and • an index number starting from 0 (for every block).We use ToCredit ( a, x, b ) to denote a system event with sender details of user a , the transfer amount x , and the receipient details of the user b , and elide theblock number and the index number when they are obvious from the context. A cross-shard transfer of x ETH from an user a i on ( s , E ) to an user b i on( s , E ) is split by our system into two transactions in a natural way: a cross-shard debit transfer (= ⇒ ) and a cross-shard credit transfer ( −→ ), correspondingto deducting x on the source side and adding x to the destination side respec-tively. Cross-shard debit transfer transaction is signed by the sender a i , andthe signature is stored in the fields v, r and s as in Ethereum 1. It containsa unique transaction identifier. It is submitted on sender shard, and emits a ToCredit
System event on success.
Cross-shard credit transfer transaction is submitted on recipient shard,and includes the
ToCredit
System Event and the Merkle Proof for it.3 .3 Shard State
In the netted-balance approach, each shard s stores the part-balances of everyEE on every shard. It can then be seen as a matrix, say s.partBalance of sizenumber of shards × number of EE’s. Here, s.partBalance [ s i , E j ] gives the part-balance of EE E j on shard s i , which is recorded at shard s . The real balanceof EE E j on shard s i is given by : realBalance [ s i , E j ] = (cid:88) k s k .partBalance [ s i , E j ] . We introduce more elements on top of part balances in the shard state, andwe use the name partState matrix in place of partBalance matrix. Each cell ofthis matrix has 3 elements, as shown in Figure 1. They are: • partBalance (as in netted-balance approach), • credits , the set of cross-shard credit transactions that needs to be im-ported on the destination shard, • reverts , the set of cross-shard revert transactions that needs to be effected.Figure 1: Shard StateThe shard state contains a map called outstandingCredits . At the time ofprocessing a block k on shard s , for every EE E , s.outstandingCredits adds4he outstanding credit transactions targeted to ( s, E ) from a shard s (cid:48) and anEE E (cid:48) whose corresponding debit transactions were successfully processed inthe immediately previous block at shard s (cid:48) . So, we have: s.outstandingCredits [ E ][ s (cid:48) , E (cid:48) , k −
1] = { e | e ∈ s (cid:48) .partState [ s, E ] .credits } The k − k − s.outstandingCredits . One,is by the successful proccessing of the credit transfer transaction, the other iswhen we time-out processing of the credit transfer. The time-out is requiredto guarantee a bound on the transfer time. Typically time-outs are specified interms of number of blocks.For every EE E , the shard state contains the EET ransf erAmount thatbookkeeps the net amount to be transferred at EE-level.For every user of every EE, the shard state also stores the user’s balance.We use s.userBalance [ E, a ] to denote the balance of user a of EE E on shard s .Because the primary purpose of the shards is to divide the content, the users’balances are not distributed. Users are typically assigned a shard. We now present the main contribution: the algorithm for the block proposerin handling cross-shard cross-EE transfers with the guarantee of atomicity. Aspreviously mentioned, the idea is to split a cross-shard transfer into a debitand a credit. First, a debit transaction is processed at the source shard, andthe EE-level transfer is fully effected. If successful, the corresponding user-levelcredit transaction is queued on to the destination shard, which is processed in asubsequent block. If the credit fails, then we do the EE-level revert and user-levelreverts NOT as separate transactions but as enshrined execution processing.Without loss of generality, assume that a Block Proposer (BP) is proposinga block numbered k on shard s . Then BP executes the following steps for everyEE E i .1. Initialisation.
Obtain the part states of E i from every shard. Ensurethat the obtained s i .partState s, 1 ≤ i ≤ n , are correct using Merkle Proofsand crosslinks. Compute the real balance of E i on s using realBalance [ s , E i ] = (cid:88) n s n .partState [ s , E i ] .balance. For every shard s and every EE E , set s .EET ransf erAmount [ s, E ] to0.2. Preprocess pending credits • Add entries to s .outstandingCredits [ s (cid:48) , E (cid:48) , ( k − (cid:55)→ (cid:83) n s n .partState [ s , E i ] .credits Kick out expired credits from s .outstandingCredits . If there is anentry with [ s (cid:48) , E (cid:48) , k (cid:48) ] such that k (cid:48) + timeOut == k then do: – s .partState [ s (cid:48) , E (cid:48) ] .reverts := s.outstandingCredits [ s (cid:48) , E (cid:48) , k (cid:48) ]. – Delete the entry with [ s (cid:48) , E (cid:48) , k (cid:48) ]. – s .EET ransf erAmount [ s (cid:48) , E (cid:48) ] := (cid:80) r x r where r ∈ s .partState [ s (cid:48) , E (cid:48) ] .reverts and x r denotes r ’s transfer amount.3. Process user-level reverts . For every r ∈ s .partState [ s , E i ] .reverts , s .userBalance [ E i , sender ( r )]+ = x r , where x r denotes r ’s transfer amount.After this operation, s .partState [ s , E i ] .reverts is set to ∅ .4. Process transactions.
For every pair ( s , E j )(a) Select cross-shard transactions t , . . . , t m between ( s , E i ) and ( s , E j )to be included in the block. It can be a new transaction from thetransaction pool, or a credit transaction from s .outstandingCredits [ s , E j ].(b) For every n ∈ { , . . . , m } : • If t n is a cross-shard debit transaction of the form a n x n = ⇒ b n and realBalance ( s , E i ) > s .EET ransf erAmount ( s , E j ) + x n – include t n to the block, – if t n executes successfully ∗ s .userBalance ( E i , a n ) -= x n (implied with successful ex-ecution of t n ) ∗ s .EET ransf erAmount [ s , E j ]+ = x n ∗ emit ToCredit ( a n , x n , b n ) System Event ∗ s .partState [ s , E j ] .credits ∪ = { a n x n −→ b n } • Else if t i is a cross-shard credit transaction of the form b n x n −→ a n AND Merkle Proof check of the included
ToCredit
SystemEvent passes AND realBalance ( s , E i ) > s .EET ransf erAmount ( s , E j )+ x n – include t n to the block – Remove t n from s .outstandingCredits [ s , E j , k (cid:48) ] where theblock number k (cid:48) is derived from the included ToCredit
Sys-tem Event. – if t n executes successfully then s .usersBalance [ E i , a n ]+ = x n (implied by the successful execution of t n ) – if it fails s .partState [ s , E j ] .reverts ∪ = { ( b n , x n , a n ) } s .EET ransf erAmount [ s , E j ]+ = x n .(c) Process EE-level transfer s .partState [ s , E i ] .balance − = s .EET ransf erAmount [ s , E j ], s .partState [ s , E j ] .balance + = s .EET ransf erAmount [ s , E j ].6 .5 Features of the algorithm Let us visit some of the notable features of the above algorithm.1. Before processing a pending cross-shard credit transfer transaction b i x i −→ a i , the EE-level transfer is already complete.2. User-level reverts happen in the immediate next slot after a failed or anexpired credit transfer. The EE-level revert happens in the same slot asthe failed / expired credit transfer. This technique pushes the revert tothe EE host functions instead of treating them as separate transactions.This avoids complex issues like revert timeouts and revert gas pricing.3. Transaction identifiers need to be unique inside the time-out blocks win-dow.4. There is a corner case where the sender disappears by the time reverthappens, then we end up in a state where there is ETH loss at user-level,but not at EE-level. We feel this is the best state to be in when such asituation happens.5. A transaction is not included in a block if the EE does not have sufficientbalance. Note that EE balance check is done even for credit transfersbecause of potential reverts.6. A time-out is required to kick out long pending credit transfers. Thesecond bullet of step 3 describes this procedure. The idea is to move outthe expired user-level credit transfers, convert them into user-level revertson the sender shard, thus achieving a fixed size for outstandingCredits datastructure.7. No locking / blocking.8. No constraint on the block proposer to pick specific transactions or toorder them.9. Main goal.
Atomicity of a cross-shard transfer.10.
Demerit.
In every block, a BP has to get the outstanding credits andreverts from every other shard. This is inherited from the netted balanceapproach, where a BP requires the netted balances from all shards. How-ever, in the EE-level netted-balance approach the querying is restricted tothe sender EE’s that are derived from the user-level transactions includedin the block. The problem is aggravated here, because we need to queryfrom all EE’s, even for the EE’s not touched in this block.
In this section, we apply the algorithm from Section 3.4 in different kinds ofrepresentative scenarios and show how atomicity is preserved.Assume that a , a , a are users on ( s , E ) and b , b , b are users on ( s , E ).7 .1 Optimistic case Let us look at the optimistic case, where everything happens as expected. Sup-pose we include three cross-shard transactions as shown in Figure 2 in a blockon the shard s . In the very next block on s , the s .outstandingCredits isupdated with 3 pending credit transactions. In the same block or subsequentlyin some block on s these credit transactions are processed.Note that the EE-level transfers are complete at the s ’s block itself. The s ’sblock could process the credit transactions all in the same block or in differentblocks. The blocks processing the credit transfers could include new cross-shardtransactions as shown in Figrue 2 or other intra-shard transactions.Figure 2: Optimistic case Let us look at the case when the processing of a credit transaction fails. Considera slight variation from the above scenario, where the credit transaction a −→ b fails or is expired. Then in the same block the EE-level revert happens (with E getting its 30 ETH back), and finally in the very next block on s the user-levelreverts are processed. Consider the case when the initial debit transaction fails. This is a very simplecase, as nothing needs to be done. Simply this transaction has to be resubmittedas in the case of Ethereum 1. 8igure 3: When credit fails
Consider the case of a Byzantine Block Proposer (BBP). A BBP might chooseto deviate from the above algorithm. It becomes clear from the following thatthe protocol withstands such a BBP.Let us recollect the checks done by a validator / attester.1. Verify that the received part states from other shards for all EEs arecorrect.2. Verify that the data structure outstandingCredits is populated with theimpending credits for this shard.3. Verify that the impending reverts are processed, meaning the sender usersare credited with the transfer amount.4. Verify that correct
ToCredit
System Events are emitted for included andsuccessful cross-shard debit transfer transactions.5. Verify that correct outgoing credit transfers are written to the appropriatepart state.6. Verify that the outstanding credit transfer is removed when a cross-shardcredit transfer happens successfully.7. Verify that a correct revert transfer is placed for a failed cross-shard credittransfer transaction.8. Check that the correct amount is transferred at the EE-level.9igure 4: When debit failsBecause a validator / an attester has access to the current shard state,(s)he can verify points: 2, 3, 5, 6, 7, 8. An attester is also given with the partState s from other shards along with their Merkle Proofs and (s)he has accessto crosslinks form the Beacon block. So, (s)he can check points 1 and 8, thatis, verify part balances, impending credits and impending reverts. Also because(s)he has access to all the transaction receipts of the transactions included inthe block, (s)he can check point 4.So, if a BBP chooses to • show no or false – part EE-balances or – set of impending credits or – set of reverts, or • not update or wrongly update outstandingCredits with impending cred-its, or • not process or wrongly process impending reverts, or • not emit or emit with incorrect data the ToCredit
System Event • not include a revert for a failed credit transaction, or • not affect appropriate EE-level transfer,his / her block will be invalidated by the attesters, assuming that the two-thirdsof the attesters are honest. 10 Conclusion
We presented an atomic cross-shard cross-EE user-level value transfer algorithmfor Ethereum 2 in presence of a Byzantine Block Proposer on top of an existingnetted-balance approach for EE-level transfers.As part of the future work, we plan to optimise the space requirements forstoring outstanding credits and outstanding reverts, and explore caching foroptimising the reads of partStates of every EE of every other shard in everyblock (related to the above mentioned demerit).
Acknowledgements
We thank Roberto Saltini, Peter Robinson, Nicholas Liochon and David Hyland-Wood for all the insightful discussions.
References [1] Vitalik Buterin. An even simpler meta-execution environmentfor eth. https://ethresear.ch/t/an-even-simpler-meta-execution-environment-for-eth/6704 , December 2019.[2] Raghavendra Ramesh. Atomic asynchronous cross-shard user-level ethtransfers over netted ee transfers. https://ethresear.ch/t/atomic-asynchronous-cross-shard-user-level-eth-transfers-over-netted-ee-transfers/7277 , April 2020.[3] Peter Robinson. Atomic cross shard function calls using systemevents, live parameter checking, and contract locking. https://ethresear.ch/t/atomic-cross-shard-function-calls-using-system-events-live-parameter-checking-contract-locking/7114https://ethresear.ch/t/atomic-cross-shard-function-calls-using-system-events-live-parameter-checking-contract-locking/7114