Remove sub blocks mentioned in docs

src/pages/protocol/blockspace/overview.mdx

@@ -1,5 +1,5 @@
 ---
-description: Technical specification for Tempo block structure including header fields, payment lanes, subblocks, and system transaction ordering.
+description: Technical specification for Tempo block structure including header fields, payment lanes, and system transaction ordering.
 ---
 
 # Blockspace Overview
@@ -10,7 +10,7 @@ This specification defines the structure of valid blocks in the Tempo blockchain
 
 ## Motivation
 
-Tempo blocks extend the Ethereum block format in multiple ways: there are new header fields to account for payment lanes and sub-blocks, and system transactions are added to the block body for the fee AMM and other protocol operations. This specification contains all the modifications to the block format.
+Tempo blocks extend the Ethereum block format in multiple ways: there are new header fields to account for payment lanes and shared gas accounting, and system transactions are added to the block body for the fee AMM and other protocol operations. This specification contains all the modifications to the block format.
 
 ## Specification
 
@@ -25,20 +25,18 @@ pub struct Header {
 }
 ```
 - `inner` is the canonical Ethereum header (parent_hash, state_root, gas_limit, etc.).
-- `general_gas_limit` and `shared_gas_limit` carve up the canonical `gas_limit` for payment and sub-block gas (see [payment lane specification](/protocol/blockspace/payment-lane-specification) and [sub-block specification](/protocol/blockspace/sub-block-specification)).
+- `general_gas_limit` and `shared_gas_limit` partition the canonical `gas_limit` for payment and non-payment capacity (see [payment lane specification](/protocol/blockspace/payment-lane-specification)).
 - `timestamp_millis_part` stores the sub‑second component; the full timestamp is `inner.timestamp * 1000 + timestamp_millis_part` .
 
 ### Block body
 The block body in Tempo retains the canonical Ethereum block body structure, with the addition of system transactions. Transactions are ordered in the following sections:
 
 1. Start-of-block system transaction(s) (must begin with the rewards registry call).
 2. Proposer lane transactions, subject to `general_gas_limit` on non-payment transactions.
-3. Sub-block transactions, grouped by proposer and prefixed with the reserved nonce key.
-4. Gas incentive transactions that consume leftover shared gas.
-5. End-of-block system transactions (see below).
+3. Remaining transactions that consume the shared gas budget.
+4. Protocol-defined end-of-block system transactions, when required.
 
 ### System transactions
 
-A valid tempo block must contain the following system transactions:
+A valid tempo block must contain the following system transaction:
   - **Rewards Registry (start-of-block)** — must be the first transaction in the block body; refreshes validator rewards metadata before user transactions begin.  Detailed specification [here](/protocol/tip20-rewards/spec).
-  - **Subblock Metadata (end-of-block)** — contains metadata about the sub-blocks included in the block. Detailed specification [here](/protocol/blockspace/sub-block-specification).

src/pages/protocol/blockspace/payment-lane-specification.mdx

@@ -6,7 +6,7 @@ description: Technical specification for Tempo payment lanes ensuring dedicated
 
 ## Abstract
 
-This specification introduces a second consensus gas constraint for **non-payment** transactions. Transactions are classified as either payments or non-payments based solely on their transaction data, without requiring any access to blockchain state. For a block to be valid, total `gas_used` by the block must be less than the `gas_limit`. Non-payment transactions executed in the proposer's lane (i.e. before the gas incentive section) must consume at most `general_gas_limit`, a new field added to the header. Once that budget is exhausted, any additional inclusion must come via the gas incentive lane defined in the [sub-blocks specification](/protocol/blockspace/sub-block-specification).
+This specification introduces a second consensus gas constraint for **non-payment** transactions. Transactions are classified as either payments or non-payments based solely on their transaction data, without requiring any access to blockchain state. For a block to be valid, total `gas_used` by the block must be less than the `gas_limit`. Non-payment transactions executed in the proposer's lane (i.e. before the gas incentive section) must consume at most `general_gas_limit`, a new field added to the header. Once that budget is exhausted, additional inclusion is constrained by the remaining shared gas budget.
 
 ## Motivation
 
@@ -52,4 +52,3 @@ for all i such that !is_payment(tx[i]) and tx[i] is in the proposer's lane
 ```
 
 Where `gas_consumed` includes intrinsic gas and gas burned by reverts, as in the existing protocol.
-

src/pages/protocol/index.mdx

@@ -44,7 +44,7 @@ This section provides details on the Tempo Protocol specifications, and serves a
     title="Tempo Transactions"
   />
   <Card
-    description="Block format, payment lanes, and sub-blocks for optimized throughput"
+    description="Block format and payment lanes for optimized throughput"
     to="/protocol/blockspace/overview"
     icon="lucide:layout"
     title="Blockspace"

src/pages/protocol/transactions/spec-tempo-transaction.mdx

@@ -179,7 +179,7 @@ Each authorization in the list:
 
 - **Protocol nonce (key 0)**: Existing account nonce, incremented for regular txs, 7702 authorization, or `CREATE`
 - **User nonces (keys 1-N)**: Enable parallel execution with special gas schedule
-- **Reserved sequence keys**: Nonce sequence keys with the most significant byte `0x5b` are reserved for [sub-block transactions](/protocol/blockspace/sub-block-specification#11-sub-block-transactions).
+- **Reserved sequence keys**: Nonce sequence keys with the most significant byte `0x5b` are reserved for protocol-managed validator sequencing.
 
 #### Account State Changes
 - `nonces: mapping(uint256 => uint64)` - 2D nonce tracking
@@ -1128,4 +1128,3 @@ The introduction of 7702 delegated accounts already created complex cross-transa
 Because a single transaction can invalidate multiple others by spending balances of multiple accounts
 
 **Assessment:** While this transaction type introduces additional pre-execution validation costs, all costs are bounded to reasonable limits. The mempool complexity issues around cross-transaction dependencies already exist in Ethereum due to 7702 and accounts with code, making static validation inherently difficult. So the incremental cost from this transaction type is acceptable given these existing constraints.
-