Asynchronous Execution
Celestium introduces Asynchronous Execution as a core innovation to significantly enhance transaction throughput and system performance. This approach decouples the execution of transactions from the consensus process, enabling both processes to run in parallel.
Background: The Limitation of Interleaved Execution
Traditional blockchains like Ethereum follow an interleaved execution model, where consensus and execution are tightly coupled:
A block proposer assembles a block and executes all transactions in it.
Validators execute the transactions before voting to agree on the block's validity.
The block is finalized only after both consensus and execution are complete.
This approach leads to performance bottlenecks because:
Execution delays block finalization.
The gas limit must be conservative to ensure execution completes within the block time.
Block time is underutilized, as consensus occupies most of it.
How Asynchronous Execution Works in Celestium
Celestium decouples consensus and execution into two separate processes:
Consensus Layer: Determines the order of transactions within a block without executing them.
Execution Layer: Executes transactions after a block is finalized.
Key Differences from Traditional Execution:
Consensus + Execution
Happens together within block time.
Consensus first, execution after.
Execution Budget
Limited by consensus time.
Full block time available.
Finality
Includes execution result.
Finality is about ordering; execution follows.
Benefits of Asynchronous Execution
1. Increased Execution Throughput
Since execution is no longer constrained by consensus, the full block time (1 second) can be dedicated to execution. This results in a much higher gas limit per block and improved throughput.
2. Faster Finality
Finality is achieved in 1 second based on transaction ordering alone. Users know their transactions are included in the blockchain without waiting for execution to complete.
3. Reduced Execution Latency
Nodes can optimize execution pipelines and parallelize transaction processing, further increasing system efficiency.
4. Improved Resilience
Nodes can handle execution failures independently without delaying consensus. For example, if a node executes transactions incorrectly, it can detect this later and re-execute them correctly.
Delayed Merkle Root for State Consistency
To maintain state consistency across nodes:
Each block header contains a Merkle root representing the final state.
This root is delayed by D blocks (e.g., D=10), allowing nodes time to execute and confirm the correct state.
Nodes that detect discrepancies in state can rollback and re-execute blocks until their state matches the agreed Merkle root.
This approach ensures that all nodes converge on the same state while enabling fast block finality.
Example Timeline:
Block N
Finalized (1s)
Execution begins
Block N+1
Finalized (1s)
Execution continues
Block N+D
Finalized (1s)
Merkle root confirmed
Handling Failed Transactions
Since consensus only orders transactions, failed transactions are still included in blocks.
Nodes will execute transactions later; if a transaction fails (e.g., out of gas), it will still fail consistently across all nodes.
Users can query the result after execution completes, with no effect on finality.
User Experience Impact
Transaction Submission
Near-instant inclusion (1s).
Order Finality
Guaranteed in 1s.
Execution Outcome
Typically available in < 1s after finality for full nodes.
Light Client Proof
Available after D=10 blocks (~10s) with Merkle proof.
Why It Matters
Asynchronous execution is a fundamental shift that allows Celestium to:
Scale beyond the limitations of single-threaded execution.
Support complex applications with higher gas limits.
Maintain fast finality and user experience without sacrificing security.
This innovation positions Celestium as a performance-optimized Layer 1 blockchain while retaining full compatibility with the Ethereum ecosystem.
Last updated