Preliminaries

We assume that at address VALIDATOR_MANAGER_ADDRESS (on the existing "main shard") there exists a contract that manages an active "validator set", and supports the following functions:

Parameters

Specification

We first define a "shard header" as an RLP list with the following values:

[
    shardId: uint256,
    prev_state_root: bytes32,
    tx_list_root: bytes32,
    coinbase: address,
    post_state_root: bytes32,
    receipt_root: bytes32,
    children: [
        child1_hash: bytes32,
        ...
        child[SHARD_CHILD_COUNT]hash: bytes32
    ],
    state_branch_node: bytes32,
    signatures: [
        sig1: bytes,
        ...
        sig[SIGNATURE_COUNT]: bytes
    ],
    mixhash: bytes32,
    nonce: uint64
]

Where:

For blocks where block.number >= SERENITY_FORK_BLKNUM, the block header's extra data must be either a locally valid shard header for shard 0 or the empty string. We define the "current state branch root" as being the state_branch_node of shard 0 for the most recent block that had a shard header, the "current state branch node" of any shard as being the state branch node that is in the tree whose root is the state branch root, and the "current state root" of any shard as being the state root that is in the tree whose root is the state branch root.

If there has not yet been a shard header, then we assume the current state root of a shard is the genesis state root of that shard (this is a protocol parameter), and we can use this to derive the starting state branch nodes for every shard, including the starting state root.

We define a shard header as "locally valid" if:

Note that there exist two classes of participants in this scheme:

We expect collators to only create shard headers that satisfy all of the above criteria except the second last, as well as only including locally valid shard headers as children. We expect signers to only sign shard headers that satisfy all of the above criteria except the second last, as well as only signing headers that include locally valid shard headers as children. Even though the minimum threshold for a collation is 2**32, we expect shard signers to maintain private difficulty thresholds so that on average one shard header produced per shard matches their private threshold; this ensures that shard signers usually agree on which shard header to sign.

Claim: if most signers are honest, then the entire shard tree should be valid, in the sense that every shard header in the tree is locally valid, with 100% minus negligible probability.

Incentives

Currently, the coinbase of a block is rewarded with 5 ether, plus extra ether for uncle and nephew rewards, as part of the "block finalization function". Here, we also have a finalization function for each shard, though the logic is different:

  1. Increase the balance of the coinbase (ie. shard collator) by ROOT_SHARD_COLLATOR_REWARD / SHARD_REWARD_DECAY_FACTOR ** shard_depth
  2. Increase the balance of each signer of the previous successfully included shard header of this shard by ROOT_SHARD_SIGNER_REWARD / SHARD_REWARD_DECAY_FACTOR ** shard_depth

Governance

The above proposal does NOT include the following highly important features:

The intention is for both to be resolved at the "chain governance" layer. That is, we introduce a contract on the current shard where anyone can burn their ether, and agree to include the ETH in the genesis state of the shard that they want it transferred to. We also make a promise that future hard forks will add the ability to move ETH between shards, as well as adding fault recovery mechanisms (see here for some details), and during a future hard fork we would do a "reset" where for every shard on which there has been a fault we reset its state to the last known valid available state of that shard, so any successful attack on a shard can only accomplish the task of shutting it down until the next fork, not stealing any ETH or causing any invalid state changes.

Rationale

This allows for a quick and dirty form of medium-security proof of stake sharding in a way that achieves exponential scaling through separation of concerns between block proposers and collators, and thereby increases throughput by ~100x without too many changes to the protocol or software architecture. The intention would be to replace it in the next hardfork with a design that adds in erasure coded data availability proofs, fraud proofs, and the formal requirement for block proposers and validators to reject collations that are not valid at the transactional level, even if they have the requisite number of signatures. Additionally, this model does not support movement of ETH between shards; it is the intention that the next hardfork after this will.

The shard tree structure ensures that no participant in the system needs to deal with more than SHARD_CHILD_COUNT * SIGNATURE_COUNT signatures; with 3 children and 40 signatures, multiplied by 200000 gas per signature, this gives an upper limit of 24 million gas, though in practice we expect many signatures to be much smaller than the maximum.