MIP-27: Supernova - Sub‑second Finality

MIPs
1
  • MIP: 27
  • Title: Supernova - Sub‑second Finality
  • Status: Discussion Draft (Agora)
  • Category: Core / Protocol
  • Created: [2025‑08‑14]
  • Requires: Andromeda (MIP‑25); Barnard
  • Replaces: -

1. Summary (TL;DR)

Supernova reduces transaction time‑to‑finality to sub‑second by (a) cutting the block slot from 6 s → 600 ms (initial) and (b) switching the protocol from Execute‑then‑Propose/Vote to Propose/Vote‑then‑Execute, so consensus no longer waits for execution. Execution results are usually notarized in the next block and may be batched if they catch up.

Key outcomes

  • Faster inclusion & finality: 10× tighter proposal cadence; consensus path is shorter (no pre‑proposal execution).
  • Deterministic inclusion of results: new Execution‑Result Inclusion Estimator (EIE) decides how many results are safe to notarize in the header.
  • Header/schema updates: block headers notarize previous execution results; support for multiple results per header and a succinct LastExecutionResultInfo.
  • Throughput & utilization: block gas capacity managed via estimated gas with reactive down‑adjustments; gross over‑estimation penalties already lowered in Barnard.
  • Economics unchanged: end‑of‑epoch emission schedule remains identical; calculations adjusted for variable rounds.

2. Motivation & Problem Statement

  • Why now: Andromeda removed confirmation blocks and lowered finality. The remaining bottleneck is the synchronous execution that stalls proposals. Supernova removes execution from the consensus‑critical path while keeping safety.
  • Goals: sub‑second finality (measured from proposal to irreversible), predictable inclusion, high utilization, deterministic rules implementable by min‑spec validators.
  • Non‑goals: changing the inflation schedule; altering ESDT/NFT semantics; immutable miniblocks (considered future work).

3. Scope of Change

  • Consensus/Finality: Propose/Vote happens before execution; proof creation can be done by any validator; blocks final once >2/3 votes exist.
  • Cross‑shard execution: unchanged flow, but results notarized on subsequent headers; receiver‑side execution continues as today. Next round notarization of execution results on meta chain considered for a future release (similar to consensus proofs).
  • Economics: round‑count‑aware end‑of‑epoch calculations so epoch inflation remains unchanged; fee burn continues to offset emissions.
  • Protocol Parameters: initial 600 ms slot; gas capacity stated in estimated gas with reactive control; ms‑precision timestamps.
  • Node software & networking: EIE added; txpool gains virtual‑state tracking for pending proposals.
  • VM & Smart Contracts: time hooks switch to millisecond timestamps after an activation epoch.
  • APIs / Indexers / SDKs: header schema extended with notarized results and LastExecutionResultInfo.

4. Technical Specification

4.1 Consensus & Finalization

  • Andromeda (baseline): consensus after verification + (normal) execution + vote propagation; scheduled execution runs in parallel and does not delay finality.
  • Supernova: the proposer constructs a block from cross‑shard miniblocks and txpool selections without prior execution, sends it for voting, then queues the proposal for execution. Validators verify proposal rules and vote immediately; they also queue the proposal for execution locally. With >2/3 votes the block is final; execution results are typically notarized in the next header.
  • Finality measurement: aligned with other L1s (e.g., Solana Alpenglow) - from proposal dissemination to irreversibility.

4.2 Execution & Results in Headers

  • Scheduled execution and partial mini blocks execution are deactivated in Supernova, as they are not needed for the propose‑then‑execute flow.
  • Partial mini blocks no longer needed as execution does not need to finish before proposal or risk failing the block. Scheduled execution is now the default through propose/vote then execute, but before transitioning to the new schemas all previous scheduled execution must be finalized.
  • Previously combined Execute-and-Propose functionality split into Propose, Validate Proposal, and Execute Proposal
  • Execute Proposal is now common flow for both proposer and validators reducing disparity between proposer and validators.
  • Each header (execution shards & metachain) includes notarization of prior execution results. This is similar to how previous block scheduled execution results were part of the next header reported results in Andromeda (and previous versions).
  • Multiple results per header are allowed to cover catch‑up scenarios; a succinct LastExecutionResultInfo is provided.
  • Miniblocks in results reference final states (invalid/unpayable txs removed at execution time). Moving to immutable miniblocks is deferred.

4.3 Execution‑Result Inclusion Estimator (EIE)

  • Purpose: decide, at proposal/validation time, how many pending results can be safely included so that a min‑spec node can finish execution of all referenced blocks before it must validate the new block.
  • Deterministic inputs: pending results (nonce order), last notarized result time, T_gas (e.g., 1 ns per gas), safety margin μ, MaxResultsPerBlock.
  • Computation (high‑level): accumulate ET += Δgas * T_gas over pending results; compute t_done = t_base + ET * (1 + μ); include results until t_done exceeds the current header time (or the max count is reached).
  • Outputs: allowed count [0..N] to embed in the header.

4.4 Gas Capacity & Utilization

  • Problem: proposals use estimated gas; over‑estimation can under‑fill blocks.
  • Countermeasures: (i) lower gross‑overestimation penalty (Barnard: threshold from >10× to >2×), (ii) over‑estimate block capacity to mask moderate overages, (iii) reactive down‑adjust of per‑block limits when proposal→result gaps appear.
  • Initial capacity: for a 600 ms slot, 1.2B estimated gas per block (min‑spec hardware target).

4.5 Protocol Parameters (Before → After)

Parameter Current (Andromeda + Barnard) Supernova (Initial) Notes
Block slot 6 s 600 ms Synchronized change; see §10.2
Finality rule Proof after vote (may include normal exec) Proof after vote (exec decoupled) Results notarized next header
Finality estimation 100ms → 1.6s (empirical data) 100ms → 250ms Time from proposal dissemination until irreversibility
Header Prior scheduled execution result notariz Prior execution results notarized; supports multiple execution results contains also LastExecutionResultInfo
Gas per block Mix of real (normal) + est. (scheduled/x‑shard) Estimated‑gas based, 1.2B est. gas target Reactive down‑adjust
Over‑estimation penalty >2× (Barnard) >2× (Barnard) Already live
Timestamp resolution Seconds Milliseconds Activates at epoch boundary

4.6 TxPool & Selection Logic (Supernova)

Overview. In Supernova, each block carries (a) transactions selected for subsequent execution and (b) the execution outcome of previously selected transactions. A leader must not re‑select transactions that were already selected in earlier proposed blocks (even if those have not executed yet).

Notifications. To keep selection consistent with the evolving chain state, the mempool subscribes to two notifications from the processing pipeline:

  • mempool.onProposedBlock(block) - informs about transactions selected/proposed in block.
  • mempool.onExecutedBlock(block) - informs about transactions executed in block and their outcomes.

Selection tracker. Internally, the mempool maintains a selection tracker - a collection of block metadata (a.k.a. tracked blocks). Each block metadata holds a map of account breadcrumbs for every seen sender/relayer in that block.

Breadcrumbs. When onProposedBlock/onExecutedBlock arrives, the mempool walks the block’s transactions and, for each sender/relayer, compiles a breadcrumb with:

  • first nonce and last nonce observed in that block;
  • consumed balance in the scope of that block (processing fee accounting).

Minimal validation is done when compiling breadcrumbs (e.g., contiguous nonce spans).

Virtual state derivation at selection start. Given the current blockchain rootHash and the set of tracked blocks whose results are not yet captured on‑chain, the mempool derives, by following breadcrumbs, per‑account tuples:

  • {address, initialNonce, initialBalance, consumedBalance}.

These tuples seed a virtual SelectionSession (existing Spica concept) so the selector can skip non‑executable transactions deterministically (e.g., nonce gaps or insufficient balance for processing fees). The derivation is performed at the beginning of each selection.

Selection algorithm. The core selection algorithm (Spica) remains largely unchanged; it now operates over the virtual account state supplied by the selection tracker to produce a proposal that is executable once results catch up.

Lifecycle & updates.

  • The selection tracker is only updated via notifications (onProposedBlock / onExecutedBlock). It is not mutated at the end of a selection.
  • Deletion of transactions remains the responsibility of processing components, as before Supernova.
  • This keeps selection deterministic and side‑effect free, and prevents leaders from re‑selecting already proposed transactions.

Invariants. A leader’s proposal must reflect breadcrumb knowledge: do not re‑select previously proposed txs from the same account if it would create a nonce gap or exceed available balance in the virtual state.

4.7 APIs / Tooling

  • ApiBlock stays the façade. The existing ApiBlock (used pre‑Supernova) continues to decouple protocol internals from public API output.
  • New field: LastExecutionResult. ApiBlock now includes LastExecutionResult, which holds the notarized execution result corresponding to the latest block state. Internally, first‑level fields such as rootHash and validatorStateRootHash are removed from the protocol block structure and are embedded inside LastExecutionResult / ExecutionResult.
  • Compatibility behavior. For a transition window, ApiBlock will continue to expose the legacy top‑level fields (rootHash, validatorStateRootHash) by populating them from LastExecutionResult / ExecutionResult. This allows existing consumers to keep working unchanged while migrating to the new fields.
  • Augmented schema. ApiBlock also exposes the new execution‑result notarization references (including support for multiple results per header) and the compact LastExecutionResultInfo.
  • Changelogs & sunset. The re‑interpretation of legacy fields and the eventual deprecation timeline will be documented. External API providers should switch to reading LastExecutionResult / ExecutionResult as the source of truth.
  • SDKs. Minimum versions TBA; changelogs will detail field additions and any re‑interpretations or deprecations.

5. Rationale & Design Trade‑offs

  • Latency vs Utilization: decoupling execution yields sub‑second finality; estimated‑gas fitting plus reactive control protects utilization.
  • Determinism & Safety: EIE ensures headers never reference results that min‑spec validators could not have finished.
  • Complexity: header/result structures grow modestly; immutable miniblocks deferred to limit scope.
  • Bandwidth: half‑split between incoming cross‑shard vs intra/outgoing to preserve liveness and fairness during congestion.

6. Security Considerations

  • Byzantine assumptions unchanged; decoupling does not relax quorum thresholds.
  • Equivocation prevention: notarized execution results are tied to header hashes/nonces; multiple‑result support avoids liveness stalls.
  • DoS surfaces: reactive gas caps mitigate pathological estimation; txpool virtual state reduces proposal churn.

7. Backwards Compatibility

  • Smart contracts: time‑related hooks switch to ms precision at activation; no ABI or host‑function changes in this release.
  • Protocol vs API structures: protocol‑internal block/header structures change to carry notarized execution results (supporting multiple results per header) and a compact LastExecutionResultInfo. The public ApiBlock adapts by adding the new LastExecutionResult field and by deriving legacy fields (e.g., rootHash, validatorStateRootHash) from LastExecutionResult/ExecutionResult during a transition window so existing consumers remain functional.
  • Indexers / explorers / bridges / wallets: internally maintained components will be updated in lock‑step. External providers should adapt to the augmented ApiBlock schema; during the transition both legacy fields (derived) and new fields will be available. A deprecation epoch will be announced ahead of removal of compatibility behavior.
  • Transactions/serialization: unchanged on the wire; only header content expands to include notarized references.

8. Performance Expectations & Benchmarks

  • Targets: sub‑second finality measured proposal → irreversible; high inclusion rate under load.
  • Observed: methodology to mirror §4.1 definition.
  • Resource impact: CPU/RAM/disk/bandwidth deltas on validators.

9. Stakeholder Impact

  • Validators/SPs: new client with EIE; minor config for reactive gas cap; monitor proposal→result gap metric.
  • Delegators/Stakers: no change to emission schedule; APR drivers unchanged except fee‑driven deflation.
  • Developers: no contract changes required; SDKs to read new header fields.
  • Users/Wallets: faster apparent finality; UX updates in xPortal to reflect definition.

10. Deployment & Rollout Plan

10.1 Testnet Phases

  • Phase A: ms timestamps; deactivation of new partial mini blocks and scheduled mini blocks proposals (continue with already started partial mini blocks execution) ; success: stable indexing, all partial and scheduled execution finalized before next phase.
  • Phase B: 600 ms slot; EIE on, header/result schema behind flags, propose/vote then execute; success: proposal→result gap bounded; validators at target CPU, no safety violations, acceptable orphan rate.

10.2 Activation & Feature Flags (Mainnet)

  • Epoch E: switch timestamp precision to milliseconds for all shards.
  • Synchronized Round K (post‑epoch): switch slot duration 6 s → 600 ms on all shards to keep round numbers consistent; metachain notarizes only headers that respect the transition (no nonce gaps; within grace window); header/result schema updated, propose/vote then execute.
  • Compatibility window: RPC/indexers parse both schemas during soak.

10.3 Validator Upgrade Steps

  1. Use provided scripts to upgrade validators to the new client version.
  2. Post‑upgrade: sync/peers/CPU/mem; monitor proposal→result gap and execution backlog.

11. Monitoring & Success Metrics

  • On‑chain KPIs: finality (proposal→irreversible), orphan rate, proposal→result gap, cross‑shard latency.
  • Node health: CPU, RAM, bandwidth; EIE decisions.

12. Risks & Open Questions

  • Tuning of μ, T_gas, and MaxResultsPerBlock.
  • Throughput vs latency under adversarial gas estimation.
  • Indexers readiness; explorers UI for new result fields.
  • Future work: immutable miniBlocks & bandwidth optimizations, next round execution results notarization on metachain.

13. References

  • Andromeda (MIP‑25); Barnard penalties.
  • Finality measurement aligned to broader L1 practice

14. Appendix

A. Glossary

  • EIE: Execution‑Result Inclusion Estimator.
  • API: Application Programming Interface.
  • SDK: Software Development Kit.
  • Txpool: Transaction pool.
  • Nonce gap: A gap in the sequence of nonces for a given account.
  • Miniblock: A block containing a subset of transactions, typically used in cross‑shard execution.
  • Virtual state: A simulated state of accounts used for transaction selection.

B. Internal Schemas

Shard Blocks Execution Results

type BaseExecutionResult struct {
    HeaderHash       []byte
    HeaderNonce      uint64
    HeaderRound      uint64
    RootHash         []byte
}

type ExecutionResult struct {
    BaseExecutionResult *BaseExecutionResult
    ReceiptsHash        []byte
    MiniBlockHeaders    []MiniBlockHeader
    DeveloperFees       *math_big.Int
    AccumulatedFees     *math_big.Int
    GasUsed             uint64
    ExecutedTxCount     uint64
}

Meta Blocks Execution Results

type BaseMetaExecutionResult struct {
    BaseExecutionResult     *BaseExecutionResult
    ValidatorStatsRootHash  []byte
    AccumulatedFeesInEpoch  *math_big.Int
    DevFeesInEpoch          *math_big.Int
}

type MetaExecutionResult struct {
    ExecutionResult     *BaseMetaExecutionResult
    MiniBlockHeaders    []MiniBlockHeader
    ReceiptsHash        []byte
    DeveloperFees       *math_big.Int
    AccumulatedFees     *math_big.Int
    GasUsed             uint64
    ExecutedTxCount     uint64
}

Succinct Data for Keeping Track of Last Execution Result

type MetaExecutionResultInfo struct {
    NotarizedOnHeaderHash []byte
    ExecutionResult       *BaseMetaExecutionResult
}

type ExecutionResultInfo struct {
    NotarizedOnHeaderHash []byte
    ExecutionResult       *BaseExecutionResult
}

C. Algorithms

Execution‑Result Inclusion Estimator (EIE)

1.  let ET      ← 0                // accumulated execution time (ns)
2.  let t_base  ← (if lastNotarised == nil
    then genesisTimestampMs * 10^6 // convert to ns
    else lastNotarised.HeaderTimeMs * 10^6)
3.  for i, res ∈ pending (in nonce order):
4.      Δgas    ← res.GasUsed
5.      ET     += Δgas * T_gas     // 1 ns per gas
6.      t_done  ← t_base + ET * (1 + μ)
7.      if t_done > currentHdrTsMs * 10^6: // convert to ns
8.          return i               // cannot include res and beyond
9.      if cfg.MaxResultsPerBlock ≠ 0 and i+1 ≥ cfg.MaxResultsPerBlock:
10.         return i+1
11. return len(pending)

At step 6. ET is multiplied by a safety margin (default 1.1 - adding an extra 10%) to give even more buffer (10%) for slower validators.

3 Likes