Optimistic Execution

Optimistic Execution is a technique used in Celestium to further enhance transaction processing efficiency when executing transactions in parallel. It allows transactions to start executing before the preceding transactions in the same block have finished, under the assumption that there will be no conflicts. If conflicts arise, affected transactions are re-executed.

---

How Optimistic Execution Works

Consider a block containing multiple transactions:

1. Transactions are executed concurrently without waiting for the results of earlier transactions.

2. Each transaction tracks the state it reads and writes during execution (read-set and write-set).

3. After the transactions complete, the results are merged in block order.

4. If a transaction’s read-set depends on state modified by an earlier transaction in the block, and the state was different than expected, the transaction is re-executed with the updated state.

This approach ensures that, even with parallel execution, the final state is the same as if transactions had been executed sequentially.

---

Example of Optimistic Execution

Suppose a block contains the following transactions:

• Tx1: Alice sends 10 CLT to Bob.

• Tx2: Bob sends 5 CLT to Charlie.

Using Optimistic Execution:

1. Tx1 and Tx2 start executing in parallel.

2. Tx2 reads Bob’s initial balance (before Tx1), which might be insufficient.

3. Once the block is merged:

   • Tx1 updates Bob’s balance.

   • Tx2 detects that it used an outdated balance.

4. Tx2 is re-executed using Bob’s updated balance.

This re-execution is necessary because Tx2 depended on the result of Tx1.

---

Key Benefits

Benefit	Description
Faster Execution	Transactions start executing without waiting for prior results.
Efficient Use of Resources	Takes full advantage of parallelism with multi-core systems.
Correct State Guarantee	Final state is identical to sequential execution.

---

Optimizations in Celestium

To reduce the overhead of re-executing transactions:

• Expensive operations like signature verification are cached and not repeated during re-execution.

• State accessed in the initial execution is cached in memory, minimizing the cost of re-execution.

• Static analysis attempts to predict dependencies between transactions and minimize conflicts.

---

Example Flow in Practice

1. Transactions from a block are assigned to multiple cores for parallel execution.

2. Each transaction optimistically reads state and performs computations.

3. The outputs are merged sequentially in block order.

4. If a transaction’s read-set conflicts with an earlier transaction’s write-set:

   • The transaction is re-executed.

5. The final state is guaranteed to match sequential execution.

---

Why Optimistic?

The term "optimistic" refers to the assumption that most transactions will not conflict. In reality, many transactions are independent, such as:

• Alice sending CLT to Bob.

• Charlie deploying a smart contract.

Only dependent transactions (e.g., Bob sending CLT after receiving from Alice) require re-execution. Since conflicts are rare, this approach is highly efficient.

---

Optimistic Execution vs. Parallel Execution

Aspect	Optimistic Execution	Parallel Execution
Definition	Transactions start execution before prior transactions finish.	Transactions are executed in parallel on different cores.
Key Focus	Reducing idle time by assuming minimal conflicts.	Maximizing throughput with multi-core processing.
Conflict Handling	Re-execution of transactions if conflicts are detected.	Detects dependencies; avoids some conflicts proactively.

---

Final Thoughts

Optimistic Execution is a critical innovation in Celestium that unlocks the full potential of parallel transaction processing. It leverages modern hardware capabilities while ensuring Ethereum-compatible deterministic state.

This approach, combined with Parallel Execution and Asynchronous Execution, enables Celestium to achieve high throughput and low-latency finality without compromising on state correctness.