Double Spend Protection

Overview

Sova's double spend protection mechanism ensures Bitcoin finality when interacting with Sova Smart Contracts. This document explains how the "storage slot locking system" works to prevent double spending and maintain cross-chain consistency. We named this service the "Sentinel". See the code for the Sentinel service.

Problem: Double Spending in Cross-Chain Systems

As a complementary Bitcoin layer, 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

• This could lead to inconsistent or fraudulent states across chains

• 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

1. 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

2. 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 the script for running 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)

Benefits

The Storage Slot Locking mechanism provides several advantages for Sova:

Cross-Chain Atomicity

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 Integration

The storage slot locking mechanism is not just an application-level feature but is integrated directly into Sova's network consensus rules. This integration ensures that all nodes in the network maintain an identical view of which storage slots are locked and when they should be unlocked or reverted.

Consensus Rules Enforcement

1. Database Synchronization: Every Sova node maintains a synchronized database of locked slots. This database is part of the consensus-critical state.

2. 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

3. Lock Propagation: When a new lock is created, it is propagated to all nodes in the network as part of the transaction data.

4. 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.

Technical Parallels: Bit Masking

The implementation of Sentinel shares conceptual similarities with bit masking techniques in computer science:

• Just as bit masks use binary operations (AND, OR, XOR) to atomically modify specific bits while preserving others, the Sentinel atomically manages slot states while preserving transaction integrity

• Similar to how a bit mask can update specific bits in a register, our system uses Bitcoin block confirmations as a signal to update the state of locked slots

• When new Bitcoin blocks are confirmed, we apply updates to our lock set, effectively "masking" our state to match Bitcoin's reality