5. Blocks & Transactions

5.1 Block Structure

Blocks are strictly serialized using Ethereum's RLP (Recursive Length Prefix) encoding, ensuring deterministic byte layouts for hashing.

5.1.1 Block Header Fields

Headers contain the parent_hash, state_root, transactions_root, receipts_root, logs_bloom, proposer address, height, and a Quorum Certificate.

5.1.2 Block Body

The body contains the ordered list of transactions for that slot.

5.1.3 Block Hashing & Validation

The block hash covers every consensus field. Incoming blocks are bounded in size and structurally validated (e.g., verifying that the RLP length matches the actual bytes) before any memory allocation occurs, preventing resource exhaustion attacks.

5.1.4 Genesis Block

The genesis block configuration is strict. Placeholders (like unspendable addresses or precompile ranges) are actively rejected during genesis initialization rather than launching a broken chain.

5.2 Transaction Types

Kortana supports all standard EVM transaction types, plus native protocol operations:

• 5.2.1 Legacy Transactions (Type 0)
• 5.2.2 EIP-2930 (Type 1): Access List transactions.
• 5.2.3 EIP-1559 (Type 2): Fee Market transactions (Base Fee + Priority Tip).
• 5.2.4 Native Transaction Types: Dedicated transaction types exist for staking, governance, and protocol defense, such as Stake, Unstake, GovernancePropose, GovernanceVote, and ReportEquivocation (Type 0x40).

5.3 Transaction Lifecycle

5.3.1 Signing & Sender Recovery

Transactions are structurally unauthenticated in the payload; the from field is advisory. The true sender is mathematically recovered from the signature using either secp256k1 (for 0x... addresses) or Ed25519 (for ktn: addresses). Kortana strictly enforces EIP-2 (low-S values) to prevent signature malleability.

5.3.2 Mempool Admission & Ordering

The mempool prioritizes transactions by Fee (Priority Tip), then strictly orders them by Nonce for a given sender. Reverting/replacing a transaction requires a standard fee bump. Authenticated sender addresses are cached upon admission.

5.3.3 Block Inclusion

The scheduled leader pulls the highest-priority valid transactions from the mempool and executes them to generate the state_root for the new block.

5.3.4 Receipts & Logs

Every executed transaction generates a receipt containing the status (success/revert), gas used, and emitted event logs. Reverted Quorlin transactions emit Error(string) compatible with standard Solidity ABIs to explain failures.

5.3.5 Logs Bloom Filters

Receipts generate a Bloom filter, and all receipt filters in a block are aggregated into the block header's logs_bloom. This allows light clients and indexers to rapidly check if a block contains events matching specific topics without downloading the entire block body.

---