On the shard chain, we include proofs in each block proving the position and public key of a validator with a beacon chain block. The following conditions have to be verified in order to enforce validity of shard blocks:
[x] Block hash and signature must validate with the included public key in the proof.
[ ] Proposer index + shard must match algorithm for finding proposer index.
[ ] Shard block proof must hash to finalized beacon chain block ValidatorProof .
If an attacker wants to fake a shard chain block, they would have to fake the validity of the public key included in the proof. To do that, they would have to have a finalized block in the beacon chain with a fake public key included. To do that, they would have to finalize a beacon chain. So, any attack that passes these 3 checks must have faked a finalized beacon block and we assume that is secure.
Shard proposer algorithm
To find the proposer of a shard block, we need an algorithm that ensures that we pick a proposer in the committee of the shard block and picks a different, randomized proposer for each block. The randomness is already taken care of because of the shuffling that happens with validators, so we'll just choose the n'th validator in the committee to propose the n + EPOCH_LENGTH * m where m is the EpochIndex block. So, the 0th validator proposes the block corresponding to EPOCH_LENGTH * m, 1th to EPOCH_LENGTH * m + 1, etc.
In the beacon validator proofs, we only need to keep track of EPOCH_LENGTH validators per shard. So, for the validator proofs, we'll set the key as hash(shard + slot) where shard is the committee the validator is assigned and slot is the slot the validator is assigned.
On the shard chain, we include proofs in each block proving the position and public key of a validator with a beacon chain block. The following conditions have to be verified in order to enforce validity of shard blocks:
ValidatorProof.If an attacker wants to fake a shard chain block, they would have to fake the validity of the public key included in the proof. To do that, they would have to have a finalized block in the beacon chain with a fake public key included. To do that, they would have to finalize a beacon chain. So, any attack that passes these 3 checks must have faked a finalized beacon block and we assume that is secure.
Shard proposer algorithm
To find the proposer of a shard block, we need an algorithm that ensures that we pick a proposer in the committee of the shard block and picks a different, randomized proposer for each block. The randomness is already taken care of because of the shuffling that happens with validators, so we'll just choose the
n'th validator in the committee to propose then + EPOCH_LENGTH * mwheremis theEpochIndexblock. So, the 0th validator proposes the block corresponding toEPOCH_LENGTH * m, 1th toEPOCH_LENGTH * m + 1, etc.In the beacon validator proofs, we only need to keep track of
EPOCH_LENGTHvalidators per shard. So, for the validator proofs, we'll set the key ashash(shard + slot)whereshardis the committee the validator is assigned andslotis the slot the validator is assigned.