Blockchain Slot Masking | Sova Labs Blog

Plato once said, "The true creator is necessity, who is the mother of our invention". While working on a feature to prevent Bitcoin from being double spent when deposited on Sova, we realized the need to temporarily lock or block certain storage slots of Sova Smart Contracts. The mechanism described here describes said invention which shares fascinating parallels with the fundamental computer science concept of bit masking.

What is double spending and how do storage slot locks protect against it? Since Sova acts as a complementary Bitcoin layer, it faces a challenge: ensuring Bitcoin deposits on Sova reflect confirmed transactions on Bitcoin. Without a mechanism to enforce consistency, a Bitcoin transaction could be sent but never confirmed, leading to inconsistent or even fraudulent states. To prevent this, we introduced the concept of slot locking. Slot Locks are temporary locks on certain storage slots of a Smart Contract. These locks are enforced at the execution layer and tied to an external verification process. Slots are locked when a Bitcoin transaction is initiated on Sova and remains locked until an external verifier confirms the transaction’s inclusion in a Bitcoin block. If it is not confirmed within a certain number of blocks, the state is rolled back to its last valid change.

Much like how bit masking uses binary flags to control access to specific bits in a register, our slot locking mechanism manages the state of storage slots using binary locked/unlocked states.

On Sova, it is possible to broadcast Bitcoin transactions via our custom precompiles (more on that in a future post). However, the network has no way to guarantee that a Bitcoin transaction made it onto a Bitcoin block. To ensure that the state of Sova is not impacted by this, we include the slot locking mechanism in the execution flow to store and enforce storage slot locks.

We’re calling this slot locking mechanism Sentinel, a guardian that watches over the locked slots and manages their lifecycle. When a new Bitcoin transaction is included in a Sova transaction, a few things happen.

Our node identifies storage slots that will undergo a state change in the same Sova transaction.
Sentinel verifies that the slots are not 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.

This lock remains until either:

The Bitcoin transaction confirms. At that time, the lock is released and the state change persists.
The transaction fails or is not confirmed within a reasonable time. Then the state is reverted to the previous value.

The implementation of the Sentinel shares many conceptual similarities with traditional bit masking techniques. Just as bit masks use binary operations (AND, OR, XOR) to atomically modify specific bits while preserving others, our storage slot locking system atomically manages slot states while preserving transaction integrity. Similar to how a bit mask can be used to update specific bits in a register, our system uses Bitcoin block confirmations as a signal to update the state of our locked slots. When new Bitcoin blocks are confirmed, we apply these updates to our lock set, effectively 'masking' our state to match Bitcoin's reality.

How does Sova benefit from a feature like this?

Cross-Chain Atomicity: We can ensure that state changes on Sova remain consistent with dependent Bitcoin transaction outcomes.

Revertible Operations: Unlike traditional blockchain operations which are immediately final, slot masking allows for a "pending" state that can be reverted if the corresponding Bitcoin transaction fails.

Guaranteed Finality: A node network running with a locking mechanism can promise that in X future blocks, the network can give you the correct finalized outcome regarding whether a certain event happened on Bitcoin or not.

powvt & E.S.