In order to assist in replicating cryptographic commitment data for sBTC stackers as part of their distributed key generation and signing protocols, the Stacks node's p2p network will be extended to implement a replicated database for storing this data on behalf of stackers. The replicated database, called a StackerDB, has the following properties:
Store-and-forward. Each Stacks node maintains a full replica of all stacker-submitted data, which it stores and forwards to its neighbors.
Chunk-oriented. The database schema grants each stacker one or more fixed-sized flat data spaces ("chunks") into which they can store arbitrary data.
Controlled by Smart Contracts. A StackerDB replica queries a given smart contract to determine (a) how many chunks the DB has, (b) how big they are, and (c) who is allowed to write to which chunks. As such, a StackerDB instance is tied to a particular smart contract.
Per-replica Monotonic Reads and Writes on Chunks. When a stacker writes a new chunk, and the new chunk is discovered by a replica, that replica will never serve an older replica to a reader.
The system is not coupled to sBTC, but is designed with sBTC's needs in mind. The system will be rolled out to the master branch well before sBTC is live, and any node operator will be able to subscribe to any smart contract-controlled StackerDB and serve as a replica. In doing so, we can implement mocked sBTC instances such that each instance has its own associated StackerDB into which stackers read and write the FROST cryptographic data.
This issue tracks the completion of the design work for the system itself. It is referenced by other issues, and should only be closed once the system itself is built and tested.
jcnelson
commented
2 weeks ago
In order to assist in replicating cryptographic commitment data for sBTC stackers as part of their distributed key generation and signing protocols, the Stacks node's p2p network will be extended to implement a replicated database for storing this data on behalf of stackers. The replicated database, called a StackerDB, has the following properties:
Store-and-forward. Each Stacks node maintains a full replica of all stacker-submitted data, which it stores and forwards to its neighbors.
Chunk-oriented. The database schema grants each stacker one or more fixed-sized flat data spaces ("chunks") into which they can store arbitrary data.
Controlled by Smart Contracts. A StackerDB replica queries a given smart contract to determine (a) how many chunks the DB has, (b) how big they are, and (c) who is allowed to write to which chunks. As such, a StackerDB instance is tied to a particular smart contract.
Per-replica Monotonic Reads and Writes on Chunks. When a stacker writes a new chunk, and the new chunk is discovered by a replica, that replica will never serve an older replica to a reader.
The system is not coupled to sBTC, but is designed with sBTC's needs in mind. The system will be rolled out to the
masterbranch well before sBTC is live, and any node operator will be able to subscribe to any smart contract-controlled StackerDB and serve as a replica. In doing so, we can implement mocked sBTC instances such that each instance has its own associated StackerDB into which stackers read and write the FROST cryptographic data.This issue tracks the completion of the design work for the system itself. It is referenced by other issues, and should only be closed once the system itself is built and tested.