Double Spend Protection

Overview

https://github.com/SovaNetwork/sova-sentinel

Sova's double spend protection mechanism ensures that Bitcoin transactions cannot be maliciously duplicated when interacting with Sova Smart Contracts. This document explains how our Storage Slot Locking system (Sentinel) works to prevent double spending and maintain cross-chain consistency.

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