Repository: rollkit/rollkit
Pull request #2061: docs: Header and data separation ADR
Author: login: Manav-Aggarwal
Created: 2025-03-11T22:22:02Z | Merged: 2025-03-20T14:33:17Z

<!--
Please read and fill out this form before submitting your PR.

Please make sure you have reviewed our contributors guide before submitting your
first PR.

NOTE: PR titles should follow semantic commits: https://www.conventionalcommits.org/en/v1.0.0/
-->

## Overview

Closes: #2046

<!-- 
Please provide an explanation of the PR, including the appropriate context,
background, goal, and rationale. If there is an issue with this information,
please provide a tl;dr and link the issue. 

Ex: Closes #<issue number>
-->



Diff:
diff --git a/block/block-manager.md b/block/block-manager.md
index c07eea187e..2cc9787cab 100644
--- a/block/block-manager.md
+++ b/block/block-manager.md
@@ -160,6 +160,7 @@ The communication between the full node and block manager:
 * The genesis `ChainID` is used to create the `PubSubTopID` in go-header with the string `-block` appended to it. This append is because the full node also has a P2P header sync running with a different P2P network. Refer to go-header specs for more details.
 * Block sync over the P2P network works only when a full node is connected to the P2P network by specifying the initial seeds to connect to via `P2PConfig.Seeds` configuration parameter when starting the full node.
 * Node's context is passed down to all the components of the P2P block sync to control shutting down the service either abruptly (in case of failure) or gracefully (during successful scenarios).
+* The block manager supports the separation of header and data structures in Rollkit. This allows for expanding the sequencing scheme beyond centralized sequencing and enables the use of a decentralized sequencer mode. For detailed information on this architecture, see the [Header and Data Separation ADR](./header-and-data-separation-adr.md).
 
 ## Implementation
 
@@ -179,6 +180,10 @@ See [tutorial] for running a multi-node network with both sequencer and non-sequ
 
 [5] [Tutorial][tutorial]
 
+[6] [Header and Data Separation ADR](./header-and-data-separation-adr.md)
+
+[7] [Rollkit Minimal Header](./rollkit-minimal-header.md)
+
 [maxSubmitAttempts]: https://github.com/rollkit/rollkit/blob/main/block/manager.go#L50
 [defaultBlockTime]: https://github.com/rollkit/rollkit/blob/main/block/manager.go#L36
 [defaultDABlockTime]: https://github.com/rollkit/rollkit/blob/main/block/manager.go#L33
diff --git a/block/header-and-data-separation-adr.md b/block/header-and-data-separation-adr.md
new file mode 100644
index 0000000000..97079d2548
--- /dev/null
+++ b/block/header-and-data-separation-adr.md
@@ -0,0 +1,223 @@
+# Header and Data Separation ADR
+
+## Abstract
+
+The separation of header and data structures in Rollkit unlocks expanding the sequencing scheme beyond centralized sequencing and unlocks the use of a decentralized sequencer mode. This means that the creation of list of the transactions can be done by another network as well while rollup nodes still produce headers after executing that list of transactions. This overall change is akin to the proposer-builder separation in the Ethereum protocol, where the Rollkit header producer acts as the proposer, and the sequencer, which produces a list of transactions, acts as the builder.
+
+### Before Separation
+
+```mermaid
+flowchart LR    
+    CS[Centralized Sequencer] -->|Creates| B[Block]
+    B -->|Contains| SH1[SignedHeader]
+    B -->|Contains| D1[Data]
+    
+    class CS,B,SH1,D1 node
+```
+
+### After Separation
+
+```mermaid
+flowchart LR    
+    HP[Header Producer] -->|Creates| SH2[SignedHeader]
+    SEQ[Sequencer] -->|Creates| D2[Data]
+    SH2 -.->|References via DataCommitment| D2
+    
+    class HP,SEQ,SH2,D2 node
+```
+
+## Protocol/Component Description
+
+Before, Rollkit only supported the use of a centralized sequencer that was responsible for creating a list of rollup tx by reaping its mempool, executing them to produce a header, and putting them together in a rollup block. Rollkit headers and data were encapsulated within a single block structure. The block struct looked like this:
+
+```go
+// Block defines the structure of Rollkit block.
+type Block struct {
+	SignedHeader SignedHeader
+	Data         Data
+}
+```
+
+The separation of header and data into distinct structures allows them to be processed independently. The `SignedHeader` struct now focuses on the header information, while the `Data` struct handles transaction data separately. This separation is particularly beneficial in unlocking based rollups, where users submit transactions directly to the Data Availability layer which acts as the entity responsible for creating the list of transactions.
+
+```mermaid
+classDiagram
+    class Block {
+        SignedHeader
+        Data
+    }
+    
+    class SignedHeader {
+        Header
+        Signature
+    }
+    
+    class Header {
+        ParentHash
+        Height
+        Timestamp
+        ChainID
+        DataCommitment
+        StateRoot
+        ExtraData
+    }
+    
+    class Data {
+        Metadata
+        Txs
+    }
+    
+    Block *-- SignedHeader
+    Block *-- Data
+    SignedHeader *-- Header
+```
+
+This change also affects how rollup full nodes sync. Previously, rollup full nodes would apply the transactions from the `Block` struct and verify that the `header` in `SignedHeader` matched their locally produced header. Now, with the separation, full nodes obtain the transaction data separately (via the DA layer directly in based sequencer mode, or via p2p gossip/DA layer in centralized sequencer mode) and verify it against the header signed by the header producer once they have both components. If a full node receives the header/data via a p2p gossip layer, they should wait to see the same header/data on the DA layer before marking the corresponding block as finalized in their view.
+
+This ensures that the data integrity and consistency are maintained across the network.
+
+```go
+// SignedHeader struct consists of the header and a signature
+type SignedHeader struct {
+    Header // Rollkit Header
+    Signature  Signature // Signature of the header producer
+    ...
+}
+
+// Header struct focusing on header information
+type Header struct {
+    // Hash of the previous rollup block header.
+    ParentHash Hash
+    // Height represents the block height (aka block number) of a given header
+    Height uint64
+    // Block creation timestamp
+    Timestamp uint64
+    // The Chain ID
+    ChainID string
+    // Pointer to location of associated block data aka transactions in the DA layer
+    DataCommitment Hash
+    // Commitment representing the state linked to the header
+    StateRoot Hash
+    // Arbitrary field for additional metadata
+    ExtraData []byte
+}
+
+// Data defines Rollkit block data.
+type Data struct {
+	*Metadata // Defines metadata for Data struct to help with p2p gossiping.
+	Txs Txs // List of transactions to be executed
+}
+```
+
+The `publishBlock` method in `manager.go` now creates the header and data structures separately. This decoupling allows for the header to be submitted to the DA layer independently of the rollup block data, which can be built by a separate network. This change supports the transition from a centralized sequencer mode to a decentralized sequencer mode, making the system more modular.
+
+## Message Structure/Communication Format
+
+### Header Producer
+
+Before the separation: Only the entire `Block` struct composed of both header and data was submitted to the DA layer. The `Block` and `SignedHeader` were both gossipped over two separate p2p layers: gossipping `Block` to just full nodes and gossipping the `SignedHeader` to full nodes and future rollup light nodes to join that will only sync headers (and proofs).
+
+After the separation: The `SignedHeader` and `Data` are submitted separately to the DA layer. Note that the `SignedHeader` has a `Header` that is linked to the `Data` via a `DataCommitment` from the DA layer. `SignedHeader` and `Data` are both gossipped over two separate p2p layers: gossipping `Data` to just full nodes and gossipping the `SignedHeader` to full nodes and future rollup light nodes to join that will only sync headers (and proofs).
+
+In based sequencing mode, the header producer is equivalent to a full node.
+
+### Before Separation
+
+```mermaid
+flowchart LR
+    
+    CS1[Centralized Sequencer] -->|Submits Block| DA1[DA Layer]
+    CS1 -->|Gossips Block| FN1[Full Nodes]
+    CS1 -->|Gossips SignedHeader| LN1[Light Nodes]
+    
+    class CS1,DA1,FN1,LN1 node
+```
+
+### After Separation - Centralized Mode
+
+```mermaid
+flowchart LR
+    
+    CS2[Centralized Sequencer] -->|Submits Data| DA2[DA Layer]
+    HP2[Header Producer] -->|Submits SignedHeader| DA2
+    
+    CS2 -->|Gossips Data| FN2[Full Nodes]
+    HP2 -->|Gossips SignedHeader| FN2
+    HP2 -->|Gossips SignedHeader| LN2[Light Nodes]
+    
+    class CS2,HP2,DA2,FN2,LN2 node
+```
+
+### After Separation - Based Mode
+
+```mermaid
+flowchart LR
+    
+    Users -->|Submit Txs| DA3[DA Layer]
+    FN3[Full Node/Header Producer] -->|Reads Data| DA3
+    
+    class Users,DA3,FN3,LN3 node
+```
+
+### Syncing Full Node
+
+Before the separation: Full Nodes get the entire `Block` struct via p2p or the DA layer. They can choose to apply the block as soon as they get it via p2p OR just wait to see it on the DA layer. This depends on whether a full node opts in to the p2p layer or not. Gossipping the `SignedHeader` over p2p is primarily for rollup light nodes to get the header.
+
+After the separation: Full nodes get the `Data` struct and the `SignedHeader` struct separately over p2p and DA layers. In code, this refers to the `HeaderStore` and the `DataStore` in block manager. A Full node should wait for having both the `Data` struct and the corresponding `SignedHeader` to it before applying the block data to its associated state machine. This is so that the full node can verify that its locally produced header's state commitment after it applies the `Data` associated to a block is consistent with the `Header` inside the `SignedHeader` that is received from the header producer. The `Header` should contain a link to its associated Data via a `DataCommitment` that is a pointer to the location of the `Data` on the DA layer.
+
+```mermaid
+sequenceDiagram
+    participant FN as Full Node
+    participant P2P as P2P Network
+    participant DA as DA Layer
+    participant SM as State Machine
+    
+    Note over FN,DA: After Separation - Sync Process
+    
+    P2P->>FN: Receive Data
+    P2P->>FN: Receive SignedHeader
+    FN->>DA: Verify Data availability
+    FN->>DA: Verify SignedHeader availability
+    FN->>FN: Match Data with SignedHeader via DataCommitment
+    FN->>SM: Apply Data to state machine
+    FN->>FN: Verify locally produced header matches received Header
+    FN->>FN: Mark block as finalized
+```
+
+In a centralized sequencer mode, before, a full node marks a block finalized, it should verify that both the `SignedHeader` and `Data` associated to it were made available on the DA layer by checking it directly or verifying DA inclusion proofs.
+
+In based sequencing mode, blocks can be instantly finalized since the `Data` is directly always derived from the DA layer and already exists there. There's no need for a `SignedHeader` to exist on the DA layer.
+
+```mermaid
+sequenceDiagram
+    participant DA as DA Layer
+    participant FN as Full Node
+    participant SM as State Machine
+    
+    Note over DA,FN: Based Sequencing Mode
+    
+    DA->>FN: Data already available
+    FN->>FN: Read Data from DA
+    FN->>FN: Execute transactions
+    FN->>FN: Produce Header
+    FN->>SM: Apply state changes
+    FN->>FN: Finalize Block
+    Note right of FN: No need to submit SignedHeader to DA
+```
+
+## Assumptions and Considerations
+
+- Considerations include ensuring that headers and data are correctly synchronized and validated to prevent inconsistencies.
+- Ensure that all components interacting with headers and data are updated to handle them as separate entities.
+- Security measures should be in place to prevent unauthorized access or tampering with headers and data during transmission and storage.
+- Performance optimizations may be necessary to handle the increased complexity of managing separate header and data structures, especially in high-throughput environments.
+- Testing and validation processes should be updated to account for the new structure and ensure that all components function correctly in both centralized and decentralized sequencer modes.
+
+## Implementation
+
+The implementation of this separation can be found in the Rollkit repository, specifically in the changes made to the `manager.go` file. The `publishBlock` method illustrates the creation of separate header and data structures, and the associated logic for handling them independently. See [Rollkit PR #1789](https://github.com/rollkit/rollkit/pull/1789)
+
+## References
+
+- [Rollkit PR #1789](https://github.com/rollkit/rollkit/pull/1789)
+- [Proposer-Builder Separation](https://www.alchemy.com/overviews/proposer-builder-separation)
diff --git a/specs/src/SUMMARY.md b/specs/src/SUMMARY.md
index 8923f51703..4e3fbb63dc 100644
--- a/specs/src/SUMMARY.md
+++ b/specs/src/SUMMARY.md
@@ -9,5 +9,7 @@
 - [DA](./specs/da.md)
 - [Full Node](./specs/full_node.md)
 - [Header Sync](./specs/header-sync.md)
+- [Header and Data Separation ADR](./specs/header-and-data-separation-adr.md)
+- [Rollkit Minimal Header](./specs/rollkit-minimal-header.md)
 - [P2P](./specs/p2p.md)
 - [Store](./specs/store.md)
diff --git a/specs/src/specs/header-and-data-separation-adr.md b/specs/src/specs/header-and-data-separation-adr.md
new file mode 120000
index 0000000000..0007e49b10
--- /dev/null
+++ b/specs/src/specs/header-and-data-separation-adr.md
@@ -0,0 +1 @@
+../../../block/header-and-data-separation-adr.md
\ No newline at end of file
diff --git a/specs/src/specs/rollkit-minimal-header.md b/specs/src/specs/rollkit-minimal-header.md
new file mode 120000
index 0000000000..851e28e0f6
--- /dev/null
+++ b/specs/src/specs/rollkit-minimal-header.md
@@ -0,0 +1 @@
+../../../block/rollkit-minimal-header.md
\ No newline at end of file


Reviews:
user: login: tac0turtle
body: nice job, left some comments/questions
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-12T10:24:46Z
user: login: Manav-Aggarwal
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-12T19:53:26Z
user: login: Manav-Aggarwal
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-12T19:56:47Z
user: login: Manav-Aggarwal
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-12T20:27:40Z
user: login: tac0turtle
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-13T10:41:59Z
user: login: Manav-Aggarwal
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-13T13:08:45Z
user: login: MSevey
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-03-13T13:24:41Z
user: login: tzdybal
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-03-17T21:35:28Z
user: login: tac0turtle
state: APPROVED
author_association: CONTRIBUTOR
submitted_at: 2025-03-19T15:10:14Z
user: login: tac0turtle
state: COMMENTED
author_association: CONTRIBUTOR
submitted_at: 2025-03-19T15:11:05Z
user: login: Manav-Aggarwal
state: COMMENTED
author_association: MEMBER
submitted_at: 2025-03-20T14:32:18Z

Review comments:
diff_hunk: @@ -0,0 +1,61 @@
+# Header and Data Separation ADR
+
+## Abstract
+
+The separation of header and data structures in Rollkit unlocks expanding the sequencing scheme beyond centralized sequencing and unlocks the use of a decentralized sequencer mode. This means that the creation of list of the transactions can be done by another network as well while rollup nodes still produce headers after executing that list of transactions. This overall change is akin to the proposer-builder separation in the Ethereum protocol, where the Rollkit header producer acts as the proposer, and the sequencer, which produces a list of transactions, acts as the builder.
+
+## Protocol/Component Description
+
+Before, Rollkit only supported the use of a centralized sequencer that was responsible for creating a list of rollup tx by reaping its mempool, executing them to produce a header, and putting them together in a rollup block. Rollkit headers and data were encapsulated within a single block structure. The block struct looked like this:
+
+```go
+// Block defines the structure of Rollkit block.
+type Block struct {
+	SignedHeader SignedHeader
+	Data         Data
+}
+```
+
+The separation of header and data into distinct structures allows them to be processed independently. The `SignedHeader` struct now focuses on the header information, while the `Data` struct handles transaction data separately. This separation is particularly beneficial in unlocking based rollups, where users submit transactions directly to the Data Availability layer which acts as the entity responsible for creating the list of transactions.
+
+This change also affects how rollup full nodes sync. Previously, rollup full nodes would apply the transactions from the `Block` struct and verify that the `header` in `SignedHeader` matched their locally produced header. Now, with the separation, full nodes obtain the transaction data separately (via the DA layer directly in based sequencer mode, or via p2p gossip/DA layer in centralized sequencer mode) and verify it against the header signed by the header producer once they have both components. This ensures that the data integrity and consistency are maintained across the network.
path: block/header-and-data-separation-adr.md
user: login: tac0turtle
body: can they get the header from DA as well? 
created_at: 2025-03-12T10:22:20Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,61 @@
+# Header and Data Separation ADR
+
+## Abstract
+
+The separation of header and data structures in Rollkit unlocks expanding the sequencing scheme beyond centralized sequencing and unlocks the use of a decentralized sequencer mode. This means that the creation of list of the transactions can be done by another network as well while rollup nodes still produce headers after executing that list of transactions. This overall change is akin to the proposer-builder separation in the Ethereum protocol, where the Rollkit header producer acts as the proposer, and the sequencer, which produces a list of transactions, acts as the builder.
+
+## Protocol/Component Description
+
+Before, Rollkit only supported the use of a centralized sequencer that was responsible for creating a list of rollup tx by reaping its mempool, executing them to produce a header, and putting them together in a rollup block. Rollkit headers and data were encapsulated within a single block structure. The block struct looked like this:
+
+```go
+// Block defines the structure of Rollkit block.
+type Block struct {
+	SignedHeader SignedHeader
+	Data         Data
+}
+```
+
+The separation of header and data into distinct structures allows them to be processed independently. The `SignedHeader` struct now focuses on the header information, while the `Data` struct handles transaction data separately. This separation is particularly beneficial in unlocking based rollups, where users submit transactions directly to the Data Availability layer which acts as the entity responsible for creating the list of transactions.
+
+This change also affects how rollup full nodes sync. Previously, rollup full nodes would apply the transactions from the `Block` struct and verify that the `header` in `SignedHeader` matched their locally produced header. Now, with the separation, full nodes obtain the transaction data separately (via the DA layer directly in based sequencer mode, or via p2p gossip/DA layer in centralized sequencer mode) and verify it against the header signed by the header producer once they have both components. This ensures that the data integrity and consistency are maintained across the network.
+
+```go
+// SignedHeader struct focusing on header information
+ type SignedHeader struct {
+    Header // Rollkit Header
path: block/header-and-data-separation-adr.md
user: login: tac0turtle
body: could this be defined? 
created_at: 2025-03-12T10:22:42Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,61 @@
+# Header and Data Separation ADR
+
+## Abstract
+
+The separation of header and data structures in Rollkit unlocks expanding the sequencing scheme beyond centralized sequencing and unlocks the use of a decentralized sequencer mode. This means that the creation of list of the transactions can be done by another network as well while rollup nodes still produce headers after executing that list of transactions. This overall change is akin to the proposer-builder separation in the Ethereum protocol, where the Rollkit header producer acts as the proposer, and the sequencer, which produces a list of transactions, acts as the builder.
+
+## Protocol/Component Description
+
+Before, Rollkit only supported the use of a centralized sequencer that was responsible for creating a list of rollup tx by reaping its mempool, executing them to produce a header, and putting them together in a rollup block. Rollkit headers and data were encapsulated within a single block structure. The block struct looked like this:
+
+```go
+// Block defines the structure of Rollkit block.
+type Block struct {
+	SignedHeader SignedHeader
+	Data         Data
+}
+```
+
+The separation of header and data into distinct structures allows them to be processed independently. The `SignedHeader` struct now focuses on the header information, while the `Data` struct handles transaction data separately. This separation is particularly beneficial in unlocking based rollups, where users submit transactions directly to the Data Availability layer which acts as the entity responsible for creating the list of transactions.
+
+This change also affects how rollup full nodes sync. Previously, rollup full nodes would apply the transactions from the `Block` struct and verify that the `header` in `SignedHeader` matched their locally produced header. Now, with the separation, full nodes obtain the transaction data separately (via the DA layer directly in based sequencer mode, or via p2p gossip/DA layer in centralized sequencer mode) and verify it against the header signed by the header producer once they have both components. This ensures that the data integrity and consistency are maintained across the network.
+
+```go
+// SignedHeader struct focusing on header information
+ type SignedHeader struct {
+    Header // Rollkit Header
+    Signature  Signature // Signature of the header producer
+    ...
+}
+
+// Data defines Rollkit block data.
+type Data struct {
+	*Metadata // Defines metadata for Data struct to help with p2p gossiping.
+	Txs Txs // List of transactions to be executed
+}
+```
+
+The `publishBlock` method in `manager.go` now creates the header and data structures separately. This decoupling allows for the header to be submitted to the DA layer independently of the rollup block data, which can be built by a separate network. This change supports the transition from a centralized sequencer mode to a decentralized sequencer mode, making the system more modular.
+
+## Message Structure/Communication Format
+
+Before, only the entire `Block` struct composed of both header and data was submitted to the DA layer but after the separation, the `SignedHeader` and `Data` are submitted separately to the DA layer. The `SignedHeader` is linked to the `Data` via a Data commitment from the DA layer.
+
+In addition, before the `Block` and `SignedHeader` were both gossipped over a p2p layer to full nodes as well. But after the separation, `SignedHeader` and `Data` are gossipped over the p2p layer since the `Block` struct does not exist anymore and is broken down.
path: block/header-and-data-separation-adr.md
user: login: tac0turtle
body: can you touch on how sync works? can data be applied while waiting for signed header? 
created_at: 2025-03-12T10:23:48Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,61 @@
+# Header and Data Separation ADR
+
+## Abstract
+
+The separation of header and data structures in Rollkit unlocks expanding the sequencing scheme beyond centralized sequencing and unlocks the use of a decentralized sequencer mode. This means that the creation of list of the transactions can be done by another network as well while rollup nodes still produce headers after executing that list of transactions. This overall change is akin to the proposer-builder separation in the Ethereum protocol, where the Rollkit header producer acts as the proposer, and the sequencer, which produces a list of transactions, acts as the builder.
+
+## Protocol/Component Description
+
+Before, Rollkit only supported the use of a centralized sequencer that was responsible for creating a list of rollup tx by reaping its mempool, executing them to produce a header, and putting them together in a rollup block. Rollkit headers and data were encapsulated within a single block structure. The block struct looked like this:
+
+```go
+// Block defines the structure of Rollkit block.
+type Block struct {
+	SignedHeader SignedHeader
+	Data         Data
+}
+```
+
+The separation of header and data into distinct structures allows them to be processed independently. The `SignedHeader` struct now focuses on the header information, while the `Data` struct handles transaction data separately. This separation is particularly beneficial in unlocking based rollups, where users submit transactions directly to the Data Availability layer which acts as the entity responsible for creating the list of transactions.
+
+This change also affects how rollup full nodes sync. Previously, rollup full nodes would apply the transactions from the `Block` struct and verify that the `header` in `SignedHeader` matched their locally produced header. Now, with the separation, full nodes obtain the transaction data separately (via the DA layer directly in based sequencer mode, or via p2p gossip/DA layer in centralized sequencer mode) and verify it against the header signed by the header producer once they have both components. This ensures that the data integrity and consistency are maintained across the network.
path: block/header-and-data-separation-adr.md
user: login: Manav-Aggarwal
body: Yes full nodes can receive the header signed by the header producer from either p2p gossip or/and DA layer. If they got it from the p2p layer, they should wait to see the same header on the DA layer before marking the block as finalized in their view. 
created_at: 2025-03-12T19:53:26Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,61 @@
+# Header and Data Separation ADR
+
+## Abstract
+
+The separation of header and data structures in Rollkit unlocks expanding the sequencing scheme beyond centralized sequencing and unlocks the use of a decentralized sequencer mode. This means that the creation of list of the transactions can be done by another network as well while rollup nodes still produce headers after executing that list of transactions. This overall change is akin to the proposer-builder separation in the Ethereum protocol, where the Rollkit header producer acts as the proposer, and the sequencer, which produces a list of transactions, acts as the builder.
+
+## Protocol/Component Description
+
+Before, Rollkit only supported the use of a centralized sequencer that was responsible for creating a list of rollup tx by reaping its mempool, executing them to produce a header, and putting them together in a rollup block. Rollkit headers and data were encapsulated within a single block structure. The block struct looked like this:
+
+```go
+// Block defines the structure of Rollkit block.
+type Block struct {
+	SignedHeader SignedHeader
+	Data         Data
+}
+```
+
+The separation of header and data into distinct structures allows them to be processed independently. The `SignedHeader` struct now focuses on the header information, while the `Data` struct handles transaction data separately. This separation is particularly beneficial in unlocking based rollups, where users submit transactions directly to the Data Availability layer which acts as the entity responsible for creating the list of transactions.
+
+This change also affects how rollup full nodes sync. Previously, rollup full nodes would apply the transactions from the `Block` struct and verify that the `header` in `SignedHeader` matched their locally produced header. Now, with the separation, full nodes obtain the transaction data separately (via the DA layer directly in based sequencer mode, or via p2p gossip/DA layer in centralized sequencer mode) and verify it against the header signed by the header producer once they have both components. This ensures that the data integrity and consistency are maintained across the network.
+
+```go
+// SignedHeader struct focusing on header information
+ type SignedHeader struct {
+    Header // Rollkit Header
path: block/header-and-data-separation-adr.md
user: login: Manav-Aggarwal
body: The full header structure is outside the scope of this ADR but we can add a sample structure with a minimal header. 
created_at: 2025-03-12T19:56:47Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,61 @@
+# Header and Data Separation ADR
+
+## Abstract
+
+The separation of header and data structures in Rollkit unlocks expanding the sequencing scheme beyond centralized sequencing and unlocks the use of a decentralized sequencer mode. This means that the creation of list of the transactions can be done by another network as well while rollup nodes still produce headers after executing that list of transactions. This overall change is akin to the proposer-builder separation in the Ethereum protocol, where the Rollkit header producer acts as the proposer, and the sequencer, which produces a list of transactions, acts as the builder.
+
+## Protocol/Component Description
+
+Before, Rollkit only supported the use of a centralized sequencer that was responsible for creating a list of rollup tx by reaping its mempool, executing them to produce a header, and putting them together in a rollup block. Rollkit headers and data were encapsulated within a single block structure. The block struct looked like this:
+
+```go
+// Block defines the structure of Rollkit block.
+type Block struct {
+	SignedHeader SignedHeader
+	Data         Data
+}
+```
+
+The separation of header and data into distinct structures allows them to be processed independently. The `SignedHeader` struct now focuses on the header information, while the `Data` struct handles transaction data separately. This separation is particularly beneficial in unlocking based rollups, where users submit transactions directly to the Data Availability layer which acts as the entity responsible for creating the list of transactions.
+
+This change also affects how rollup full nodes sync. Previously, rollup full nodes would apply the transactions from the `Block` struct and verify that the `header` in `SignedHeader` matched their locally produced header. Now, with the separation, full nodes obtain the transaction data separately (via the DA layer directly in based sequencer mode, or via p2p gossip/DA layer in centralized sequencer mode) and verify it against the header signed by the header producer once they have both components. This ensures that the data integrity and consistency are maintained across the network.
+
+```go
+// SignedHeader struct focusing on header information
+ type SignedHeader struct {
+    Header // Rollkit Header
+    Signature  Signature // Signature of the header producer
+    ...
+}
+
+// Data defines Rollkit block data.
+type Data struct {
+	*Metadata // Defines metadata for Data struct to help with p2p gossiping.
+	Txs Txs // List of transactions to be executed
+}
+```
+
+The `publishBlock` method in `manager.go` now creates the header and data structures separately. This decoupling allows for the header to be submitted to the DA layer independently of the rollup block data, which can be built by a separate network. This change supports the transition from a centralized sequencer mode to a decentralized sequencer mode, making the system more modular.
+
+## Message Structure/Communication Format
+
+Before, only the entire `Block` struct composed of both header and data was submitted to the DA layer but after the separation, the `SignedHeader` and `Data` are submitted separately to the DA layer. The `SignedHeader` is linked to the `Data` via a Data commitment from the DA layer.
+
+In addition, before the `Block` and `SignedHeader` were both gossipped over a p2p layer to full nodes as well. But after the separation, `SignedHeader` and `Data` are gossipped over the p2p layer since the `Block` struct does not exist anymore and is broken down.
path: block/header-and-data-separation-adr.md
user: login: Manav-Aggarwal
body: yes, updated.
created_at: 2025-03-12T20:27:40Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,61 @@
+# Header and Data Separation ADR
+
+## Abstract
+
+The separation of header and data structures in Rollkit unlocks expanding the sequencing scheme beyond centralized sequencing and unlocks the use of a decentralized sequencer mode. This means that the creation of list of the transactions can be done by another network as well while rollup nodes still produce headers after executing that list of transactions. This overall change is akin to the proposer-builder separation in the Ethereum protocol, where the Rollkit header producer acts as the proposer, and the sequencer, which produces a list of transactions, acts as the builder.
+
+## Protocol/Component Description
+
+Before, Rollkit only supported the use of a centralized sequencer that was responsible for creating a list of rollup tx by reaping its mempool, executing them to produce a header, and putting them together in a rollup block. Rollkit headers and data were encapsulated within a single block structure. The block struct looked like this:
+
+```go
+// Block defines the structure of Rollkit block.
+type Block struct {
+	SignedHeader SignedHeader
+	Data         Data
+}
+```
+
+The separation of header and data into distinct structures allows them to be processed independently. The `SignedHeader` struct now focuses on the header information, while the `Data` struct handles transaction data separately. This separation is particularly beneficial in unlocking based rollups, where users submit transactions directly to the Data Availability layer which acts as the entity responsible for creating the list of transactions.
+
+This change also affects how rollup full nodes sync. Previously, rollup full nodes would apply the transactions from the `Block` struct and verify that the `header` in `SignedHeader` matched their locally produced header. Now, with the separation, full nodes obtain the transaction data separately (via the DA layer directly in based sequencer mode, or via p2p gossip/DA layer in centralized sequencer mode) and verify it against the header signed by the header producer once they have both components. This ensures that the data integrity and consistency are maintained across the network.
+
+```go
+// SignedHeader struct focusing on header information
+ type SignedHeader struct {
+    Header // Rollkit Header
path: block/header-and-data-separation-adr.md
user: login: tac0turtle
body: how is outside the scope? can it be a set of bytes? does it need to be a concrete type. In the case of cosmos sdk, it can return the header needed for ibc removing the need for those types in rollkit itself. 
created_at: 2025-03-13T10:41:59Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,61 @@
+# Header and Data Separation ADR
+
+## Abstract
+
+The separation of header and data structures in Rollkit unlocks expanding the sequencing scheme beyond centralized sequencing and unlocks the use of a decentralized sequencer mode. This means that the creation of list of the transactions can be done by another network as well while rollup nodes still produce headers after executing that list of transactions. This overall change is akin to the proposer-builder separation in the Ethereum protocol, where the Rollkit header producer acts as the proposer, and the sequencer, which produces a list of transactions, acts as the builder.
+
+## Protocol/Component Description
+
+Before, Rollkit only supported the use of a centralized sequencer that was responsible for creating a list of rollup tx by reaping its mempool, executing them to produce a header, and putting them together in a rollup block. Rollkit headers and data were encapsulated within a single block structure. The block struct looked like this:
+
+```go
+// Block defines the structure of Rollkit block.
+type Block struct {
+	SignedHeader SignedHeader
+	Data         Data
+}
+```
+
+The separation of header and data into distinct structures allows them to be processed independently. The `SignedHeader` struct now focuses on the header information, while the `Data` struct handles transaction data separately. This separation is particularly beneficial in unlocking based rollups, where users submit transactions directly to the Data Availability layer which acts as the entity responsible for creating the list of transactions.
+
+This change also affects how rollup full nodes sync. Previously, rollup full nodes would apply the transactions from the `Block` struct and verify that the `header` in `SignedHeader` matched their locally produced header. Now, with the separation, full nodes obtain the transaction data separately (via the DA layer directly in based sequencer mode, or via p2p gossip/DA layer in centralized sequencer mode) and verify it against the header signed by the header producer once they have both components. This ensures that the data integrity and consistency are maintained across the network.
+
+```go
+// SignedHeader struct focusing on header information
+ type SignedHeader struct {
+    Header // Rollkit Header
path: block/header-and-data-separation-adr.md
user: login: Manav-Aggarwal
body: Added full header structure in this ADR: https://github.com/rollkit/rollkit/pull/2069

Yes, it can definitely be a set of bytes. Imo transformation of header needed for IBC should happen after just like noted in #2069, since that type of header is only relevant for receiving IBC clients, not users of the rollup.
created_at: 2025-03-13T13:08:45Z
author_association: MEMBER
diff_hunk: @@ -0,0 +1,223 @@
+# Header and Data Separation ADR
path: block/header-and-data-separation-adr.md
user: login: tac0turtle
body: could you put this in the adr section of the docs. Should update the docs in block manager to reflect this work and link to the adr 
created_at: 2025-03-19T15:11:05Z
author_association: CONTRIBUTOR
diff_hunk: @@ -0,0 +1,223 @@
+# Header and Data Separation ADR
path: block/header-and-data-separation-adr.md
user: login: Manav-Aggarwal
body: yes added a symbolic link, updated the block manager docs as well. Block manager will be updated more in detail in https://github.com/rollkit/rollkit/pull/2086 as well
created_at: 2025-03-20T14:32:17Z
author_association: MEMBER

PR comments:
user: login: coderabbitai[bot]
created_at: 2025-03-11T22:22:13Z
body: <!-- This is an auto-generated comment: summarize by coderabbit.ai -->
<!-- This is an auto-generated comment: skip review by coderabbit.ai -->

> [!IMPORTANT]
> ## Review skipped
> 
> Auto reviews are disabled on base/target branches other than the default branch.
> 
> 
> 
> Please check the settings in the CodeRabbit UI or the `.coderabbit.yaml` file in this repository. To trigger a single review, invoke the `@coderabbitai review` command.
> 
> You can disable this status message by setting the `reviews.review_status` to `false` in the CodeRabbit configuration file.

<!-- end of auto-generated comment: skip review by coderabbit.ai -->
<!-- tips_start -->

---

Thanks for using CodeRabbit! It's free for OSS, and your support helps us grow. If you like it, consider giving us a shout-out.

<details>
<summary>❤️ Share</summary>

- [X](https://twitter.com/intent/tweet?text=I%20just%20used%20%40coderabbitai%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20the%20proprietary%20code.%20Check%20it%20out%3A&url=https%3A//coderabbit.ai)
- [Mastodon](https://mastodon.social/share?text=I%20just%20used%20%40coderabbitai%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20the%20proprietary%20code.%20Check%20it%20out%3A%20https%3A%2F%2Fcoderabbit.ai)
- [Reddit](https://www.reddit.com/submit?title=Great%20tool%20for%20code%20review%20-%20CodeRabbit&text=I%20just%20used%20CodeRabbit%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20proprietary%20code.%20Check%20it%20out%3A%20https%3A//coderabbit.ai)
- [LinkedIn](https://www.linkedin.com/sharing/share-offsite/?url=https%3A%2F%2Fcoderabbit.ai&mini=true&title=Great%20tool%20for%20code%20review%20-%20CodeRabbit&summary=I%20just%20used%20CodeRabbit%20for%20my%20code%20review%2C%20and%20it%27s%20fantastic%21%20It%27s%20free%20for%20OSS%20and%20offers%20a%20free%20trial%20for%20proprietary%20code)

</details>

<details>
<summary>🪧 Tips</summary>

### Chat

There are 3 ways to chat with [CodeRabbit](https://coderabbit.ai?utm_source=oss&utm_medium=github&utm_campaign=rollkit/rollkit&utm_content=2061):

- Review comments: Directly reply to a review comment made by CodeRabbit. Example:
  - `I pushed a fix in commit <commit_id>, please review it.`
  - `Generate unit testing code for this file.`
  - `Open a follow-up GitHub issue for this discussion.`
- Files and specific lines of code (under the "Files changed" tab): Tag `@coderabbitai` in a new review comment at the desired location with your query. Examples:
  - `@coderabbitai generate unit testing code for this file.`
  -	`@coderabbitai modularize this function.`
- PR comments: Tag `@coderabbitai` in a new PR comment to ask questions about the PR branch. For the best results, please provide a very specific query, as very limited context is provided in this mode. Examples:
  - `@coderabbitai gather interesting stats about this repository and render them as a table. Additionally, render a pie chart showing the language distribution in the codebase.`
  - `@coderabbitai read src/utils.ts and generate unit testing code.`
  - `@coderabbitai read the files in the src/scheduler package and generate a class diagram using mermaid and a README in the markdown format.`
  - `@coderabbitai help me debug CodeRabbit configuration file.`

Note: Be mindful of the bot's finite context window. It's strongly recommended to break down tasks such as reading entire modules into smaller chunks. For a focused discussion, use review comments to chat about specific files and their changes, instead of using the PR comments.

### CodeRabbit Commands (Invoked using PR comments)

- `@coderabbitai pause` to pause the reviews on a PR.
- `@coderabbitai resume` to resume the paused reviews.
- `@coderabbitai review` to trigger an incremental review. This is useful when automatic reviews are disabled for the repository.
- `@coderabbitai full review` to do a full review from scratch and review all the files again.
- `@coderabbitai summary` to regenerate the summary of the PR.
- `@coderabbitai generate docstrings` to [generate docstrings](https://docs.coderabbit.ai/finishing-touches/docstrings) for this PR.
- `@coderabbitai resolve` resolve all the CodeRabbit review comments.
- `@coderabbitai configuration` to show the current CodeRabbit configuration for the repository.
- `@coderabbitai help` to get help.

### Other keywords and placeholders

- Add `@coderabbitai ignore` anywhere in the PR description to prevent this PR from being reviewed.
- Add `@coderabbitai summary` to generate the high-level summary at a specific location in the PR description.
- Add `@coderabbitai` anywhere in the PR title to generate the title automatically.

### CodeRabbit Configuration File (`.coderabbit.yaml`)

- You can programmatically configure CodeRabbit by adding a `.coderabbit.yaml` file to the root of your repository.
- Please see the [configuration documentation](https://docs.coderabbit.ai/guides/configure-coderabbit) for more information.
- If your editor has YAML language server enabled, you can add the path at the top of this file to enable auto-completion and validation: `# yaml-language-server: $schema=https://coderabbit.ai/integrations/schema.v2.json`

### Documentation and Community

- Visit our [Documentation](https://docs.coderabbit.ai) for detailed information on how to use CodeRabbit.
- Join our [Discord Community](http://discord.gg/coderabbit) to get help, request features, and share feedback.
- Follow us on [X/Twitter](https://twitter.com/coderabbitai) for updates and announcements.

</details>

<!-- tips_end -->
author_association: CONTRIBUTOR
user: login: codecov[bot]
created_at: 2025-03-11T22:30:54Z
body: ## [Codecov](https://app.codecov.io/gh/rollkit/rollkit/pull/2061?dropdown=coverage&src=pr&el=h1&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=rollkit) Report
All modified and coverable lines are covered by tests :white_check_mark:
> Project coverage is 23.98%. Comparing base [(`2262207`)](https://app.codecov.io/gh/rollkit/rollkit/commit/2262207691c541ac71254672d3966345ae5e85cc?dropdown=coverage&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=rollkit) to head [(`ec4988a`)](https://app.codecov.io/gh/rollkit/rollkit/commit/ec4988ae88600eaae41a4d53f014d1a1cd008728?dropdown=coverage&el=desc&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=rollkit).
> Report is 13 commits behind head on feature/exec_api.

<details><summary>Additional details and impacted files</summary>


```diff
@@                 Coverage Diff                  @@
##           feature/exec_api    #2061      +/-   ##
====================================================
- Coverage             24.11%   23.98%   -0.13%     
====================================================
  Files                    52       54       +2     
  Lines                  8231     8292      +61     
====================================================
+ Hits                   1985     1989       +4     
- Misses                 6089     6141      +52     
- Partials                157      162       +5     
```

</details>

[:umbrella: View full report in Codecov by Sentry](https://app.codecov.io/gh/rollkit/rollkit/pull/2061?dropdown=coverage&src=pr&el=continue&utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=rollkit).   
:loudspeaker: Have feedback on the report? [Share it here](https://about.codecov.io/codecov-pr-comment-feedback/?utm_medium=referral&utm_source=github&utm_content=comment&utm_campaign=pr+comments&utm_term=rollkit).

<details><summary>🚀 New features to boost your workflow: </summary>

- ❄ [Test Analytics](https://docs.codecov.com/docs/test-analytics): Detect flaky tests, report on failures, and find test suite problems.
</details>
author_association: NONE
user: login: github-actions[bot]
created_at: 2025-03-20T14:31:23Z
body: [PR Preview Action](https://github.com/rossjrw/pr-preview-action) v1.6.0
:---:
| <p></p> :rocket: View preview at <br> https://rollkit.github.io/rollkit/pr-preview/pr-2061/ <br><br>
| <h6>Built to branch [`gh-pages`](https://github.com/rollkit/rollkit/tree/gh-pages) at 2025-03-20 14:31 UTC. <br> Preview will be ready when the [GitHub Pages deployment](https://github.com/rollkit/rollkit/deployments) is complete. <br><br> </h6>
<!-- Sticky Pull Request Commentpr-preview -->
author_association: CONTRIBUTOR