Snark: Designing Snark Finalization
Blockchains are comprised of;
- p2p
- accounts
- transactions
- transaction pool or queue
- state processor
- consensus
- blocks
- blockchain
- rpc
A blockchain is an event driven system, we define the following events
- A user unlocks their wallet (accounts)
- A user creates a transaction (accounts, transaction)
- A user sends the transaction to a node’s transaction pool(transaction, rpc, transaction pool)
- Transactions are received from nearby nodes (transaction, p2p)
- The transaction is proxied to known nodes (transaction, p2p)
- The transaction is validated and applied to the state (transaction, transaction pool, state processor)
- Successful transactions are put into a block (transaction, block)
- Blocks are mined (block, consensus)
- Blocks are received from nearby nodes (block, p2p)
- Received blocks are replayed for consensus (block, consensus, transaction, state processor)
- Successfully mined blocks are added to the chain (block, blockchain)
- Blocks added to the chain are propagated (block, p2p)
Snark’s key changes
Transactions are grouped in {queued|pending|accepted|finalized}
- Transaction is received and set to queued
- Transaction nonce is checked to see if execution can occur, if false, stay queued, else move to pending
- Pending Transactions are applied to the state, if successful move to accepted, else discard
- Accepted transactions are monitored for 51% consensus. If achieved, move to finalized
Architectural changes
- Transaction pool includes accepted and finalized types
- Node provides stake information (for liveliness)
- Stake confirmed against precompiled smart contract
- Stake not matched ignored
- Node provides short codes for accepted but not finalized transactions
- Known Nodes transaction accepted stake / Known Nodes total stake > 51%, finalize transaction
- Known Nodes transaction accepted stake / Known Nodes total stake > r% where r > 51% and < 100%, can remove broadcasting transaction
Challenge, perpetual accepted transactions. Transactions that achieve > 51% but never reach > r%
Challenge, deterministic replay. Node stake is mutable across time.
Both challenges are address with fixed voting epochs. Stake is locked in for a fixed epoch. Release requests only trigger after epoch end. Transactions not finalized in an epoch are reset.
Example
- A sends transaction tx1 to Node n1
- n1 has (for each live node) knowledge of Node Info, Node accepted transactions, Node Stake.
- n1 calculates tx1 known stake 0% and the network total stake 100%.
- n1 propagates tx1 to all known Nodes.
- Known Nodes transmit Node Info, accepted transactions, stake.
- n1 receives tx1 in accepted transaction lists from nodes.
- n1 calculates tx1 known stake x% and the network total stake y%
- x/y > 51%, finalized transaction
- x/y > r%, stop broadcasting transaction
Challenge, known nodes stake < 51% of total system stake. Transaction finalized and removed.
Liveliness is important, this issue is resolved with the Network Nodes and transmitting to Network Nodes for up to date data.
Challenge, all Network Nodes DDOS, and known nodes stake < 51% of total system stake.
Introduction of finalization confirmation.
Nodes transmit accepted transactions and current observed stake. When node has realized 51% stake, move transaction to finalized state. r% of known nodes set to finalized, hard finalize.
Challenge, r-51% total stake owned by malicious node. Creating transaction DDOS. Slasher protocol for malicious behavior.
