Enhance Block Production

SUMMARY.md

@@ -11,8 +11,10 @@
 * [Characteristics](technical-specs/characteristics/README.md)
   * [Execution Environment](technical-specs/characteristics/execution-environment.md)
   * [Block Production](technical-specs/characteristics/block-production/README.md)
-    * [Pre-Confirmations](technical-specs/characteristics/block-production/pre-confirmations.md)
-    * [Decentralized Sequencer Network](technical-specs/characteristics/block-production/decentralized-sequencer-network.md)
+    * [Mempool](technical-specs/characteristics/block-production/mempool.md)
+    * [Sequencer](technical-specs/characteristics/block-production/sequencer.md)
+    * [Sequencer Commitments](technical-specs/characteristics/block-production/sequencer-commitments.md)
+    * [Soft Confirmations](technical-specs/characteristics/block-production/soft-confirmation.md)
   * [Proof Generation](technical-specs/characteristics/proof-generation.md)
   * [Nodes](technical-specs/characteristics/nodes.md)
   * [Bitcoin Settlement: Trust-minimized BTC Bridge](technical-specs/characteristics/bitcoin-settlement-trust-minimized-btc-bridge/README.md)

technical-specs/characteristics/block-production/README.md

@@ -1,9 +1,25 @@
 # Block Production
 
-<figure><img src="../../../.gitbook/assets/block_prod.png" alt=""><figcaption><p>Block Production in Citrea</p></figcaption></figure>
+This section details Citrea's block production and finalization process, from transaction submission to confirmation. It covers the roles of the sequencer, commitments, mempool, and overall process. 
 
-In Citrea, the entity responsible for producing blocks is called the "sequencer." A sequencer, unlike a validator or miner, doesn't need validations over produced blocks from other sequencers or nodes because every block produced by sequencers undergoes a zero-knowledge proving process, which acts as a natural and trustless validation mechanism over blocks.
+#### Components Overview
 
-The sequencer builds blocks using its own local mempool. Anyone can send a transaction to sequencer's mempool using its RPC endpoints or a full node. In case of censorship, there is a force transaction mechanism that falls back to Bitcoin and guarantees transactions will be included in the next batch.
+You can read more on each component of the block production process with detailed explanation below:
 
-The sequencer is only responsible for ordering and publishing blocks. It can neither steal users' funds nor freeze them thanks to ZK proofs, force transaction mechanism, and on-chain data availability.
+- [Mempool](./mempool.md): A holding area for user transactions before they are included in a block.
+- [Sequencer](./sequencer.md): A special full node that orders the transactions, produces rollup blocks, and publishes commitments to the Bitcoin DA.
+- [Sequencer Commitments](./sequencer-commitments.md): Cryptographic commitments to the Citrea blocks that are inscribed on Bitcoin by the sequencer to prevent reorgs.
+- [Soft Confirmations](./soft-confirmations.md): A confirmation mechanism used by the sequencer to provide soft-finality of blocks.
+
+#### Block Production Process
+
+Here is a diagram that shows process & components of block production in Citrea. Feel free to check each component above for more detailed information in the diagram.
+
+<figure><img src="../../../.gitbook/assets/block_cycle.png" alt=""><figcaption><p>Extended Block Production</p></figcaption></figure>
+
+In short, block production in Citrea is as follows:
+- User transactions enter the mempool where they undergo some checks until they are included in a block.
+- The sequencer selects valid transactions from the mempool, orders them, and produces a rollup block.
+- The sequencer also provides soft confirmations alongside the block data, allowing full nodes to update their local chain state with a soft-finality.
+- To finalize the ordering of the transactions, sequencer commitments are inscribed on Bitcoin by the sequencer, allowing full nodes to trustlessly verify the blocks.
+- Lastly, the proving of execution is completed by the prover and batch proofs are inscribed (and finalized) on Bitcoin, and hence block becomes finalized & proven.

technical-specs/characteristics/block-production/mempool.md

@@ -0,0 +1,26 @@
+# Mempool
+
+Citrea has a private mempool (memory pool) as a temporary staging area for pending transactions before they are included in a block. 
+
+Once a transaction is submitted, some basic checks are as follows:
+- Is there enough space in the mempool? (see configs section below)
+- Does it fit into account limits? (see configs section below)
+- Does the transaction have a valid nonce that is bigger or equal than the current nonce?
+- Does the address have enough balance?
+
+If the transaction passes these checks, it is added to the mempool. 
+
+#### Configuration
+
+Citrea uses a private mempool, inaccessible via RPC, which prioritizes transactions based on their fee.
+
+Citrea mempool has custom [SubPools](https://reth.rs/docs/reth_transaction_pool/enum.SubPool.html#variants) that uses `reth-transaction-pool` architecture. Namely:
+- Queued: Includes transactions not ready to be included in the next block due to lack of funds, nonce, etc.
+- BaseFee: Includes transactions not ready to be included in the next block due to insufficient base fee.
+- Pending: Includes transactions ready to be included in the next block.
+
+For Queued, BaseFee, and Pending pools, Citrea has the 10x configuration limits compared to default values of Ethereum: 100000 transactions per subpool with 200MB limit.
+
+Citrea does not have a Blob pool as it does not support blob transactions at the moment. Number of transactions allowed in Blob pool is set to 0.
+
+One more custom mempool configuration is the number of transaction slots per account, `max_account_slots`. Citrea has a maximum of 64 slots per account in the mempool, to prevent spamming.

technical-specs/characteristics/block-production/sequencer-commitments.md

@@ -0,0 +1,26 @@
+# Sequencer Commitments
+
+Sequencer commitments are envelopes on Bitcoin that are inscribed by the sequencer before proof generation. Such envelope contains:
+
+- **Soft Confirmation Hashes**: Merkle root built on top of the hashes of soft confirmations, representing a set of Citrea blocks.
+- **Start - End Block Heights**:  It includes the range information of Citrea blocks (identified by their start and end heights) that were processed to reach the new state.
+
+These commitments are inscribed directly on Bitcoin, creating an immutable record. Thus, unless Bitcoin is re-orged, the sequencer commitments will continue to be trustlessly accessible. 
+
+A sequencer commitment is generated by the sequencer and submitted to Bitcoin based on a number of soft confirmations and a state diff size threshold. 
+
+#### Benefits
+
+Sequencer commitments are used to keep track of the canonical history of the rollup's state, as they represent a commitment to a set of Citrea blocks derived from a Bitcoin block. 
+
+Once a commitment is inscribed (and finalized) on Bitcoin, the sequencer cannot re-order transactions within that batch without invalidating the commitment. This maintains the integrity of the batch, and therefore the rollup's state. 
+
+While it does not fully guarantee data availability, sequencer commitments prevent re-orgs on Citrea blocks once they are finalized. It allows full nodes to verify the sequencer's claims about the state transitions.
+
+Sequencer commitments are also used in the Batch Proof circuits for Blockspace Proving. You can read more about it [here](https://www.blog.citrea.xyz/citreas-batch-proofs/).
+
+Lastly, Light Client Proofs that are used in BitVM based Clementine bridge also benefits from the sequencer commitments indirectly as well. You can read a summary of it [here](https://x.com/citrea_xyz/status/1877746951309176971).
+
+#### Querying Sequencer Commitments
+
+Sequencer commitments can be queried by using the Citrea Batch Explorer, along with the [RPC endpoints](/developer-documentation/rpc-documentation/ledger-rpc-documentation.md). You can find the explorer [here](https://citrea.xyz/batch-explorer).

technical-specs/characteristics/block-production/sequencer.md

@@ -0,0 +1,20 @@
+# Citrea Sequencer
+
+The Citrea sequencer is a specialized full node responsible for ordering user transactions and constructing rollup blocks.
+
+#### Process of Block Production
+
+Sequencer carries the following operations to build a block, in detail:
+
+- It continuously monitors the [mempool](./mempool.md), a dedicated area for pending transactions. 
+- Every two seconds, the sequencer assembles a new block from the transactions in the mempool. The subset of transactions selected from the mempool are stated under the mempool section. The ordering of these transactions are based on their priority fees.
+- Along with user transactions, sequencer is also responsible for including system transactions, such as updating the `L1BlockHash` in the [BitcoinLightClient](/developer-documentation/system-contracts/bitcoin-light-client.md) or handling [Deposit](/developer-documentation/system-contracts/bridge.md) transacations.
+- The sequencer executes the assembled transactions against the current state of the rollup, updates the balances, storage values, and state. Gas usages and state changes are recorded in transaction receipts.
+- Once the trasactions are executed, the sequencer also generates a signed [soft confirmation](./soft-confirmation.md). This provides a soft-finality to the transactions.
+- The signed soft confirmation with block data is broadcasted to the network for full nodes to update their local chain state.
+
+Soft confirmations does not provide finality - you can refer to [Sequencer Commitments](./sequencer-commitments.md) for more information.
+
+#### Trust Assumptions
+
+Regarding the trust assumptions that come with sequencer's role, it's important to recall that ZK Proofs are used to ensure the validity of the transactions and the block. Combined with force transaction mechanism and on-chain data availability, the sequencer may cause liveness failures, but it cannot act maliciously and damage users' funds or freeze them voluntarily. 

technical-specs/characteristics/block-production/soft-confirmation.md

@@ -0,0 +1,22 @@
+# Soft Confirmations
+
+Issued by the sequencer, soft confirmations in Citrea provide soft-finality for transactions in a block, offering users rapid feedback while the rollup awaits finalization on the DA layer. They represent interim state updates within the Citrea rollup.
+
+#### Structure
+
+Each soft confirmation encapsulates essential information about a block:
+
+-   **Rollup Block Information:** The information of corresponding rollup block.
+-   **Previous Hash**: The hash of the preceding soft confirmation, forming a chain of blocks that prevents replay attacks and ensures correct ordering.
+-   **DA Block Information**: The height, hash, and the transaction commitment data of the associated DA block on Bitcoin.
+-   **L1 Fee Rate**: The fee rate on Bitcoin L1, relevant for calculating transaction costs.
+-   **Transactions**: Transaction data included in the block.
+-   **State Root**: The root hash of the rollup state after applying the transactions in this soft confirmation.
+-   **Signature**: The sequencer's signature on the soft confirmation data.
+-   **Public Key**: The sequencer's public key used to verify the signature.
+-   **Deposit Data**: Information about deposit transactions from the BitVM-based Clementine bridge.
+-   **Timestamp**: The timestamp of the block, recording when it was produced by the sequencer.
+
+The structure above is signed and distributed to the network. 
+
+Soft confirmations form the basis for [sequencer commitments](./sequencer-commitments.md), which are published to the DA layer for finalization.