add staking module differences to block_spec (rollkit#1335)

closes rollkit#1220 Instead of rollkit#1220, we'll just fix and update the block_spec. Also adds the termination condition, and processing out-of-order rollup blocks from DA.  ## Summary by CodeRabbit - **New Features** - Introduced a requirement for blocks to have a valid signature from the centralized sequencer. - Implemented support for out-of-order rollup blocks on the Data Availability network. - Added a termination condition for sequencer double-signing scenarios. - **Documentation** - Updated block specification documentation to reflect new validation rules. - Added diagrams to illustrate out-of-order block handling and termination conditions. - **Refactor** - Removed `AggregatorsHash` and `NextAggregatorsHash` fields from block headers to streamline the validation process.  --------- Co-authored-by: Connor O'Hara <connor@switchboard.xyz>
chandiniv1 · Nov 20, 2023 · 9434283 · 9434283
1 parent 58b3152
commit 9434283
Show file tree

Hide file tree

Showing 4 changed files with 14 additions and 4 deletions.
diff --git a/block/block-manager.md b/block/block-manager.md
@@ -92,6 +92,16 @@ The block manager of the sequencer full nodes regularly publishes the produced b
 
 The block manager of the full nodes regularly pulls blocks from the DA network at `DABlockTime` intervals and starts off with a DA height read from the last state stored in the local store or `DAStartHeight` configuration parameter, whichever is the latest. The block manager also actively maintains and increments the `daHeight` counter after every DA pull. The pull happens by making the `RetrieveBlocks(daHeight)` request using the Data Availability Light Client (DALC) retriever, which can return either `Success`, `NotFound`, or `Error`. In the event of an error, a retry logic kicks in after a delay of 100 milliseconds delay between every retry and after 10 retries, an error is logged and the `daHeight` counter is not incremented, which basically results in the intentional stalling of the block retrieval logic. In the block `NotFound` scenario, there is no error as it is acceptable to have no rollup block at every DA height. The retrieval successfully increments the `daHeight` counter in this case. Finally, for the `Success` scenario, first, blocks that are successfully retrieved are marked as DA included and are sent to be applied (or state update). A successful state update triggers fresh DA and block store pulls without respecting the `DABlockTime` and `BlockTime` intervals.
 
+#### Out-of-Order Rollup Blocks on DA
+
+Rollkit should support blocks arriving out-of-order on DA, like so:
+![out-of-order blocks](https://github.com/rollkit/rollkit/blob/32839c86634a64aa5646bfd1e88bf37b86b81fec/block/out-of-order-blocks.png?raw=true)
+
+#### Termination Condition
+
+If the sequencer double-signs two blocks at the same height, evidence of the fault should be posted to DA. Rollkit full nodes should process the longest valid chain up to the height of the fault evidence, and terminate. See diagram:
+![termination conidition](https://github.com/rollkit/rollkit/blob/32839c86634a64aa5646bfd1e88bf37b86b81fec/block/termination.png?raw=true)
+
 ### Block Sync Service
 
 The block sync service is created during full node initialization. After that, during the block manager's initialization, a pointer to the block store inside the block sync service is passed to it. Blocks created in the block manager are then passed to the `BlockCh` channel and then sent to the [go-header] service to be gossiped blocks over the P2P network.

diff --git a/block/out-of-order-blocks.png b/block/out-of-order-blocks.png
diff --git a/block/termination.png b/block/termination.png
diff --git a/types/block_spec.md b/types/block_spec.md
@@ -87,11 +87,13 @@ Block.Verify()
 | **Field Name** | **Valid State**                                                          | **Validation**                                                                              |
 |----------------|--------------------------------------------------------------------------|---------------------------------------------------------------------------------------------|
 | Header         | Valid header for the block                                               | `Header` passes `ValidateBasic()` and `Verify()`                                            |
-| Commit         | 1 valid signature from the expected proposer                             | `Commit` passes `ValidateBasic()`, with additional checks in `SignedHeader.ValidateBasic()` |
-| Validators     | Array of Aggregators, should be length 1 (or zero for based rollup case) | `Validators` passes `ValidateBasic()`                                                       |
+| Commit         | 1 valid signature from the centralized sequencer                             | `Commit` passes `ValidateBasic()`, with additional checks in `SignedHeader.ValidateBasic()` |
+| Validators     | Array of Aggregators, must have length exactly 1. | `Validators` passes `ValidateBasic()`                                                       |
 
 ## [Header](https://github.com/rollkit/rollkit/blob/main/types/header.go#L25)
 
+***Note***: The `AggregatorsHash` and `NextAggregatorsHash` fields have been removed. Rollkit vA should ignore all Valset updates from the ABCI app, and always enforce that the proposer is the centralized sequencer set as the 1 validator in the genesis block.
+
 | **Field Name**      | **Valid State**                                                                            | **Validation**                        |
 |---------------------|--------------------------------------------------------------------------------------------|---------------------------------------|
 | **BaseHeader** .    |                                                                                            |                                       |
@@ -107,8 +109,6 @@ Block.Verify()
 | AppHash             | The correct state root after executing the block's transactions against the accepted state | checked during block execution        |
 | LastResultsHash     | Correct results from executing transactions                                                | checked during block execution        |
 | ProposerAddress     | Address of the expected proposer                                                           | checked in the `Verify()` step          |
-| AggregatorsHash     | Matches the NextAggregatorsHash of the previous accepted block                             | checked in the `Verify()` step          |
-| NextAggregatorsHash | Set during block execution, according to the ABCI app                                      | checked during block execution        |
 
 ## [Commit](https://github.com/rollkit/rollkit/blob/main/types/block.go#L48)