This post outlines an in-protocol cross-shard messaging system by proposing changes to the block validity and fork choice rules. This is a part of the CBC Casper sharding proposal, but can be easily applied to later phases of Eth2.0. A description of this can be found in the CBC Casper draft paper in Section 4.6
Eth2.0 supports cross-shard messaging on an out-of-protocol basis, meaning that users have to manually perform some operations to deliver a cross-shard message. The protocol handles the delivery of the receipt of the transaction from a shard chain to the beacon chain, and the user has to create a transaction on the recipient shard that refers to this receipt.
The goal is to have a protocol which handles the end-to-end delivery of the cross-shard message, in which the user only has to generate a transaction on the first shard chain.
2.1. Block Structure
Blocks now contain 2 new logs, one for sent messages (in this block) and received messages (in this block) each.
Messages are objects that contain:
target_blockon the recipient shard
Any cross-shard message is going to have to make 2 hops - Shard A to Beacon Chain, and Beacon Chain to Shard B.
recipient_shard_ID are for the specific hop, and
final_destination_shard_ID identifies Shard B.
The message can be received in blocks on the recipient shard between heights
In the above figure, the
blocks_to_liveis 2. This message can be received only in blocks
2.3. Block Validity & Fork Choice
The atomicity of sends and receives needs to be maintained; either a message is sent in the sender shard and received in the recipient shard (eventually), or it does not appear anywhere.
I’ll skip the obvious ones like: each message can only be received once, chains can only receive messages destined for themselves, etc.
2.3.1. Shard Chains
The shard chain fork choice follows the beacon chain fork choice, and these modifications enforce the send-receive atomicity:
- If the beacon chain sends a shard some message, then the
target_blockis in the fork choice on the shard chain.
- If the beacon chain receives some message from a shard, the sender block is in the fork choice on the shard.
- If the beacon chain does not receive a shard chain message by it’s expiry, then the sender block is orphaned in the shard.
- Any shard chain block that doesn’t receive a yet-unreceived message by it’s
blocks_to_liveexpiry is orphaned.
The below figure illustrates the first rule:
The below figure illustrates the second rule:
2.3.2. Beacon Chain
The beacon chain block validity rule enforces that messages received in a block are immediately redirected and sent to the final destination. If a message is in the receive log of a block, it must also appear on the sent log of the block with:
sender_shard_IDidentifying the beacon chain
final_destination_shard_IDof the received message
blocks_to_liveon the recipient shard
Since the shard chain fork choices are dependent on the beacon chain fork choice, the beacon chain fork choice must follow this rule to avoid chaos in the shards:
- The beacon chain cannot send to/receive from one fork of a shard and later send to/receive from a conflicting fork of the shard. (“send to a fork” refers to the fork containing the
The purpose of this fork choice rule is to avoid the below situation:
3. How Are Messages Traveling Between Shards?
Messages can get from the beacon chain to the shards/from shards to the beacon chain naturally because of the way validators are distributed:
- Messages from the beacon chain to a shard chain are seen by all validators on the shard, since they are also validators on the beacon chain. Validators on the shard chain also have all necessary information for executing the fork choice.
- Messages sent from a shard to the beacon chain are collected by the respective crosslink committee and included in the crosslink information on the beacon chain. It is important to note that not all beacon chain validators have access to necessary information for executing the beacon chain fork choice and block validity rules. The requirement is that atleast one of the validators on the shard chain provides fraud proofs in case the stated rules are broken.