Recently, Ethereum Co-founder Vitalik Buterin published a proposal regarding the implementation of cross-shard transactions on the Ethereum network. According to the post, one of the main requirements of phase 2 is the ability to move ETH quickly between shards. Buterin added that while cross-shard transactions are feasible in general through receipt mechanisms, cross-shard ETH requires more enshrined in-protocol activity.
The reason for this, Buterin said, is that there is a need to keep track of how much ETH is present in each shard, and an enshrined mechanism is required to prevent a replay of cross-shard transfers. According to Buterin, the usual receipt-based mechanism solves this, but only by having a state tree of “already consumed receipt IDs” which would be considered complex enough to be added to the currently nominally stateless system.
“The reason this receipt ID tree is required is that we allow receipts to be consumed out of order. That is, if Alice sends a transaction from shard A -> B and then Applebaum sends a transaction from shard A -> B, it’s possible that Appelbaum’s transaction gets received in shard B first. This is necessary because with the gas-market-based approach for handling receipt-consuming transactions, it’s possible that Alice may decide to just not pay for the transaction to finish the transfer on shard B.”
Buterin’s proposed solution is to create a state variable for the “ID of the receipt shard B last received from shard A,” where every shard A maintains two values in its state for every other shard B. These values are the nonce of the next receipt that will be sent from A to B, and the nonce of the next receipt that will be received from B to A.
“The second half of processing a cross-shard transaction free (block producers would be required to process a certain number of receipts from other shards per block), with the rate-limiting done by charging fees on the source shard of the receipt. However, this has a major problem: what if one does a DoS attack on a specific shard by sending receipts to it from all shards?”
To solve this, Buterin proposed another mechanism.
“Every shard is required to process up to N receipts (eg. N = 64) in a block; if there are fewer than N receipts from other shards to process, it can use Merkle proofs from other shards to prove this. Each shard continually relays to the beacon chain the total number of receipts it has processed, and this is used to provide an updated “gas price” for sending receipts to that shard.”
The Ethereum Co-founder added that this would ensure that a DoS attack would eventually fail to increase the length of a receiving shard’s queue, allowing each message to be processed. This will still allow for sending transactions that do minimal cross-shard activity, he said.
“Alternatively, shards will already need to publish their EIP 1559 gasprices to the beacon chain to process block fees; this fee can be dual-purposed for this function as well.”
Buterin also stated that the mechanism for sending ETH between shards would allow it to dual-purpose for receipt sending functionality and enshrined cross-shard transaction system. He also claimed that the challenge would be in computing the effects of receipts, which would require a voluntary Merkle state witness.
“If full state is not enshrined, one cannot force this at protocol level; but what one can do is add a requirement of the form in order to include one of your own transactions, you must also provide witnesses for a cross-shard receipt that is in the queue”
