BTC Finality
The SovaEVM has secure multi-level approach to ensure Bitcoin transaction finality when users interact with the chain. The following explains how Sova's "storage slot locking system" works to prevent double spending and maintain cross-chain consistency.
Problem: Double Spending in Cross-Chain Systems
Sova faces a critical challenge: ensuring that Bitcoin deposits on Sova accurately reflect confirmed transactions on the Bitcoin blockchain. Without a proper protection mechanism:
Bitcoin transactions could be sent but never confirmed
Could lead to inconsistent or fraudulent states on Sova
Users could potentially claim the same Bitcoin value multiple times
Solution: Storage Slot Locking
Sova implements a storage slot locking mechanism that temporarily locks specific storage slots in Smart Contracts while waiting for Bitcoin transaction confirmation. This system, called Sentinel, acts as a guardian that watches over locked slots and manages their lifecycle.
How It Works
When a new Bitcoin transaction is included in a Sova transaction:
The node identifies storage slots that will undergo state changes
Sentinel verifies that the slots are not already locked
If any slot is currently locked, the Sova transaction is reverted and the Bitcoin transaction is not broadcast
Otherwise, Sentinel locks the slot and tracks the previous state to handle a potential revert
The lock remains until either:
The Bitcoin transaction confirms: the lock is released and the state change persists
The transaction fails or isn't confirmed within a timeout period: the state is reverted to the previous value
Technical Implementation: sova-reth
This diagram explains the overall block building modifications made to support the Sentinel service.
The sentinel and its slot locks are enforced by REVM Inspectors. These are essentially hooks that run before and after certain processes in payload building and block execution. The sova-reth inspector has a local cache that is checked during the main transaction loops. The final state of that cache is added to the sentinel database after the simulation and execution phases so that it can be enforced in the next block. Run this script for simulating the sequence shown in the diagram. Side Notes when running a node:
Dev Mode (Single node): Payload Builder and Execution/ Validation are called in the same block building process.
Multi node: Only block proposer uses Payload Building flow. Everyone else validates the payload with Execution/Validation flow.
Technical Implementation: Sova Sentinel
Sova Sentinel is a gRPC service that manages storage slot locks for EVM smart contracts on Sova. It provides the following key functions:
SlotLockService {
rpc LockSlot(LockSlotRequest) returns (LockSlotResponse);
rpc GetSlotStatus(GetSlotStatusRequest) returns (GetSlotStatusResponse);
rpc UnlockSlot(UnlockSlotRequest) returns (UnlockSlotResponse);
}Configuration
Sentinel can be configured with Bitcoin-specific parameters such as:
BITCOIN_CONFIRMATION_THRESHOLD: Number of confirmations required to unlock a slot (default: 6)BITCOIN_REVERT_THRESHOLD: Number of blocks after which a locked slot will revert (default: 18)
Cross-Chain Atomicity
The Sentinel ensures that state changes on Sova remain consistent with dependent Bitcoin transaction outcomes.
Revertible Operations
Unlike traditional blockchain operations which are immediately final, slot locking allows for a "pending" state that can be reverted if the corresponding Bitcoin transaction fails.
Guaranteed Finality
The node network running with the locking mechanism can guarantee that after a specific number of blocks, the network will provide the correct finalized outcome regarding whether a certain event happened on Bitcoin.
Consensus Rules Enforcement
Database Synchronization: Every Sova node maintains a synchronized database of locked slots. This database is part of the consensus-critical state.
Block Validation: During block validation, nodes verify that:
No transaction attempts to modify a locked slot
Unlocks only occur when proper Bitcoin confirmation evidence is provided
Reverts happen automatically after the configured timeout period
Lock Propagation: When a new lock is created, it is propagated to all nodes in the network as part of the transaction data.
Deterministic Processing: The rules for processing locks, unlocks, and reverts are deterministic, ensuring all nodes reach the same conclusion about the state of each slot.
Last updated