Transition Testcases

Client Configurations

Each test case should be run with following configurations with at least 2^14 validators:

1. 100% of each EL+CL combo (60?)
2. Something that roughly mimics client currently share on EL+CL

Test Cases

Happy Case

A mock client mines a normal PoW chain which reaches TotalTerminalDifficulty, CL+EL continue to finalization with live ExecutionPayloads.

Steps

• Mock client mines a terminal PoW block and propogates it to all EL clients.
• The next proposer constructs a beacon block with a TRANSITION_BLOCK.
• The proposer after that should build a block which builds an execution payload on top of the TRANSITION_BLOCK.
• So on and so forth until the chain finalizes a checkpoint that includes a non-zero ExecutionPayload.

Checks

• Verify the chain post-transition finalizes.
• Verify every CL client agrees on the head.
• Verify execution_payload.block_hash of a finalized checkpoint is in the canonical chain of all ELs.
• Verify all beacon clients have proposed a block with a valid ExecutionPayload.
• Verify TRANSITION_BLOCK.parent is the terminal PoW block.

Withholding Terminal PoW Block

A mock client mines a normal PoW chain and propogates TRANSITION_BLOCK to a single partition in the network. After missing finalization, propogate to the rest of the network.

Steps

• Mock client mines up to a terminal PoW block and propogates it to all EL clients, except the terminal block.
• The mock client reveals the terminal PoW block to one partition of the network.
• There seems like three main test cases here:
  • Partition
    $A$ where
    $|A|>2n/3$ of validators and partition
    $B$ where
    $|B|<n/3$. In this case, the chain will finalize a TRANSITION_BLOCK. Once the terminal block is released to partition
    $B$, partition
    $B$ should begin accepting current canonical chain.
  • Partition
    $A$ where
    $|A|<n/3$ of validators and partition
    $B$ where
    $|B|>2n/3$. In this case, the chain will continue to finalize. Once the terminal block is released to partition
    $B$, partition
    $A$ and
    $B$ should accept a TRANSITION_BLOCK that builds on the terminal block.
  • Partition
    $A$ where
    $|A|=n/2$ and parition
    $B$ where
    $|B|=n/2$. Similar to above, although it's not clear to me how quickly the network will resolve these issues and finalize a chain without a TRANSITION_BLOCK.

Checks

• Verify the chain does not finalize a TRANSITION_BLOCK before it is propogated to all partitions.
• Verify the chain finalizes after the TRANSITION_BLOCK is propogated to all partitions.
• Verify all CL clients agree on the head.
• Verify execution_payload.block_hash of a finalized checkpoint is in the canonical chain of all EL clients.
• Verify all CL clients have proposed a block with a valid ExecutionPayload.

Multiple Terminal PoW Blocks

A mock client mines a normal PoW chain and propogates multiple TRANSITION_BLOCKs to different partitions of the network.

Steps

• Mock client mines up to a terminal PoW block and propogates it to all EL clients, except the terminal block.
• The mock client reveals a distinct terminal PoW block for each partition of the network.
• There seems like three main test cases here are roughly the same as in the withholding test case, except it's testing that a client can let go of it's current terminal block and accept a new one.

Checks

• Verify the chain finalizes.
• Verify all CL clients agree on the head.
• Verify execution_payload.block_hash of a finalized checkpoint is in the canonical chain of all EL clients.
• Verify all beacon clients have proposed a block with a valid ExecutionPayload.

Syncing Test Case(s) (?)

I don't quite understand this test case:

passing a terminal block point while syncing; then CL must go back and validate terminal block conditions, finalized and not yet finalized cases should be covered; similar to the case when block is withheld

---

Another one: CL+EL both fully partitioned with miners on both and after a few epochs reveal one partition to the other