5. Blocks & Transactions

5.1 Block Structure

Blocks in Kortana serve as the cryptographically sealed containers for state transitions. To guarantee absolute cross-platform determinism and compatibility with existing Ethereum indexing pipelines, block headers and bodies are serialized using Ethereum's canonical Recursive Length Prefix (RLP) encoding format.

5.1.1 Block Header Fields

The BlockHeader struct contains every consensus and execution parameter required to verify the validity of a block without downloading the entire state trie. The header fields include:

• parent_hash: The BLAKE3/Keccak-256 hash of the immediately preceding canonical block header.
• state_root: The 32-byte root hash of the Merkle-Patricia State Trie after executing all transactions in this block.
• transactions_root: The root hash of the Merkle trie populated with the transactions contained in this block.
• receipts_root: The root hash of the receipt trie containing execution outcomes, gas used, and event logs.
• logs_bloom: A 2048-bit (256-byte) Bloom filter aggregating all event topics emitted during block execution.
• proposer: The 20-byte address of the validator that generated and proposed the block.
• height: The monotonically increasing block height (genesis is height 0).
• view: The consensus view number in which this block was proposed.
• timestamp: The deterministic timestamp (in milliseconds) derived from the dPOH tick stream.
• gas_limit: The maximum allowable gas consumption for the block (configured at 30,000,000).
• gas_used: The total actual gas consumed by all transactions executed within the block.
• base_fee_per_gas: The EIP-1559 base fee required per unit of gas for inclusion in this block.
• poh_hash: The terminal SHA-256 hash produced by the dPOH generator for this slot's 64 ticks.
• extra_data: Bounded arbitrary byte field (up to 32 bytes) for validator telemetry.
• qc: The serialized BLS12-381 Quorum Certificate certifying 2/3 + 1 validator approval of the parent block.

5.1.2 Block Body

The BlockBody encapsulates the ordered collection of transactions executed during the slot. Transactions within the body are packed strictly in the order determined by the block proposer and verified against the header's transactions_root. The serialization ensures that transactions can be unpacked, verified, and executed deterministically across any validating node.

5.1.3 Block Hashing & Validation

Computing the cryptographic hash of a block covers every consensus-critical field in the header. The hash calculation executes over the canonical RLP-encoded header bytes.

During block validation, the node executes multi-layer defense-in-depth checks:

1. Size Bounding: The raw block byte stream is validated against a maximum block size limit before memory allocation occurs.
2. Structural RLP Integrity: The RLP parser rejects non-canonical encodings, leading zero paddings, and truncated payloads.
3. Consensus Validation: The attached Quorum Certificate is verified against the active validator set's BLS public keys and voting weights.
4. dPOH Continuity: The poh_hash is verified against the continuous hash sequence.

5.1.4 Genesis Block

The Genesis Block (Height 0) establishes the initial state of the blockchain. In kortana-node, genesis creation is strictly governed by automated validation guards.

The genesis parser explicitly rejects placeholder validator addresses, invalid public keys, or attempts to assign initial balances to restricted system precompile addresses (0x00...00 through 0x00...FF). The genesis routine computes the initial state_root by inserting all initial account allocations, sets the starting EIP-1559 base fee, verifies the supply conservation invariant, and hardcodes the initial validator set.

5.2 Transaction Types

Kortana provides native support for all standard Ethereum typed transaction envelopes (defined by EIP-2718), alongside dedicated native transaction types for protocol operations:

• 5.2.1 Legacy Transactions (Type 0): The original un-enveloped Ethereum transaction format containing nonce, gasPrice, gasLimit, to, value, data, and secp256k1 signature components (v, r, s). EIP-155 replay protection is strictly enforced.
• 5.2.2 EIP-2930 (Type 1): Transactions introducing optional access lists (address and storage_keys). Access lists allow callers to specify storage locations upfront, reducing gas costs for warm storage reads during execution.
• 5.2.3 EIP-1559 (Type 2): Modern dynamic fee transactions containing max_priority_fee_per_gas (the validator tip) and max_fee_per_gas (the fee cap). These transactions interact directly with Kortana's base fee burning mechanism.
• 5.2.4 Native Transaction Types: Dedicated transaction types for core protocol actions:
  • Stake (0x30): Lock DNR into the consensus staking pool.
  • Unstake (0x31): Initiate the unbonding period for validator stake.
  • DelegateStake (0x32): Delegate voting weight to an active validator.
  • DelegatePoH (0x33): Authorize an external node to generate dPOH tick streams.
  • GovernancePropose (0x34): Submit an on-chain parameter change proposal.
  • GovernanceVote (0x35): Cast a stake-weighted vote on an active proposal.
  • ClaimRewards (0x36): Claim accrued staking rewards.
  • ReportEquivocation (0x40): Submit cryptographic evidence of a validator double-sign.

5.3 Transaction Lifecycle

5.3.1 Signing & Sender Recovery

In the Kortana transaction model, the from address is never authenticated directly from a payload field; any declared from field is purely advisory. The authentic sender identity is mathematically recovered directly from the cryptographic signature.

For standard EVM addresses (0x...), public keys and addresses are recovered from secp256k1 ECDSA signatures using ecrecover. Kortana strictly enforces EIP-2 low-S malleability rules (s <= secp256k1_n / 2), instantly rejecting any transaction containing high-S signature components to protect the mempool against transaction hash malleability. For native ktn: addresses, signatures are validated using high-speed Ed25519 verification. The recovered sender address is cached in memory upon first validation, ensuring signature recovery occurs exactly once per transaction lifecycle.

5.3.2 Mempool Admission & Ordering

Upon arrival at a node, transactions enter the Mempool. Admission is gated by strict validation rules: the transaction signature must be valid, payload size must not exceed 128 KiB, intrinsic gas must be satisfied, the sender's liquid DNR balance must cover the maximum transaction cost (balance >= gas_limit * max_fee + value), and the nonce must match or sequentially succeed the account's current on-chain nonce.

Within the mempool, transactions are sorted into a fee-priority queue ordered by max_priority_fee_per_gas. For any specific sender address, transactions are strictly ordered by Nonce. A transaction with nonce N+1 cannot be admitted to block proposal selection until nonce N has been executed.

5.3.3 Block Inclusion

When an active validator is scheduled as the leader for a slot, its block builder queries the mempool. The builder pulls the highest-priority transactions that fit within the 30,000,000 block gas limit, verifies that their nonces form continuous sequences, and passes them to the execution pipeline.

As transactions execute sequentially against the state trie, gas consumption is metered, account nonces increment, balances mutate, and state trie intermediate nodes update. If a transaction runs out of gas or encounters an explicit revert, all state changes made by that transaction are rolled back, but the transaction is still included in the block and gas fees are collected.

5.3.4 Receipts & Logs

Every executed transaction produces an immutable TransactionReceipt. The receipt records:

• status: Integer status code (1 for successful execution, 0 for reverted execution).
• cumulative_gas_used: The total gas consumed by this and all preceding transactions in the block.
• logs: An ordered array of Log entries emitted by smart contracts during execution via EVM LOG opcodes or Quorlin emit statements.
• logs_bloom: A 2048-bit Bloom filter generated from the contract addresses and log topics emitted by this specific transaction.

For reverted transactions originating in Quorlin, the engine formats the revert reason as a standard Solidity-compatible Error(string) selector (0x08c379a0), allowing Web3 wallets and block explorers to decode error messages transparently.

5.3.5 Logs Bloom Filters

To enable lightweight clients, indexers, and decentralized application frontends to search for specific smart contract events without scanning gigabytes of block bodies, Kortana constructs hierarchical Bloom filters.

When a log is emitted, its emitting contract address and indexed event topics are hashed using Keccak-256. Three specific bits are set in the transaction's 2048-bit logs_bloom. During block completion, all transaction bloom filters are bitwise OR-aggregated into the block header's master logs_bloom. Light clients can query these header bloom filters in logarithmic time to determine whether a block contains relevant events before requesting transaction receipts.

---