Dynamic Proof of Stake
Overview
DarkFi's current blockchain is based on Streamlet, a very simple consensus system based on voting between the participating parties. The blockchain is currently in the devnet phase and has no concept of a consensus token.
Darkfi is actively working to upgrade its consensus to Ouroboros Crypsinous, a privacy focused proof-of-stake algorithm. To accommodate this transition it has designed its data structures to be easy to upgrade.
Below is a specification of how DarkFi's current blockchain achieves consensus.
Blockchain
Blockchain is a series of epochs: it's a tree of chains, , , , , the chain of the max length in is the driving chain C.
Epoch
An epoch is a multiple of blocks. Some of those blocks might be empty due to the nature of the leader selection with VRF.
Genesis block
The first block in the epoch updates the stake for stakeholders, which influences the weighted random leader selection algorithm. For epoch j, the pair () is the genesis block's data for n stakeholders of the blockchain:
Note that new stakeholders need to wait for the next epoch to be added to the genesis block
Block
A block is the building block of the blockchain.
Block created for slot i by a stakeholder, and slot i leader :
Leader selection
At the onset of each slot each a stakeholder needs to verify if it's the weighted random leader for this slot.
This statement might hold true for zero or more stakeholders, thus we might end up with multiple leaders for a slot, and other times no leader. Also note that no one would know who the leader is, how many leaders are there for the slot, until you receive a signed block with a proof claiming to be a leader.
Note that , : the active slot coefficient is the probability that a party holding all the stake will be selected to be a leader. Stakeholder is selected as leader for slot j with probability , is stake.
The following are absolute stake aggregation dependent leader selection family of functions.
Linear family functions
In the previous leader selection function, it has the unique property of independent aggregation of the stakes, meaning the property of a leader winning leadership with stakes is independent of whether the stakeholder would act as a pool of stakes, or distributed stakes on competing coins. "one minus the probability" of winning leadership with aggregated stakes is , the joint "one minus probability" of all the stakes (each with probability winning aggregated winning the leadership thus:
A non-exponential linear leader selection can be:
Dependent aggregation
Linear leader selection has the dependent aggregation property, meaning it's favorable to compete in pools with sum of the stakes over aggregated stakes of distributed stakes:
let's assume the stakes are divided to stakes of value for , note that , thus competing with single coin of the sum of stakes held by the stakeholder is favorable.
Scalar linear aggregation dependent leader selection
A target function T with scalar coefficients can be formalized as let's assume , and then: then the lead statement is for example for a group order or l= 24 bits, and maximum value of , then lead statement:
Competing max value coins
For a stakeholder with absolute stake, it's advantageous for the stakeholder to distribute stakes on competing coins.
Inverse functions
Inverse lead selection functions doesn't require maximum stake, most suitable for absolute stake, it has the disadvantage that it's inflating with increasing rate as time goes on, but it can be function of the inverse of the slot to control the increasing frequency of winning leadership.
Leader selection without maximum stake upper limit
The inverse leader selection without maximum stake value can be and inversely proportional with probability of winning leadership, let it be called leadership coefficient.
Decaying linear leader selection
As the time goes one, and stakes increase, this means the combined stakes of all stakeholders increases the probability of winning leadership in next slots leading to more leaders at a single slot, to maintain, or to be more general to control this frequency of leaders per slot, c (the leadership coefficient) need to be function of the slot , i.e where is epoch size (number of slots in epoch).
Pairing leader selection independent aggregation function
The only family of functions that are isomorphic to summation on multiplication (having the independent aggregation property) is the exponential function, and since it's impossible to implement in plonk, a re-formalization of the lead statement using pairing that is isomorphic to summation on multiplication is an option.
Let's assume is isomorphic function between multiplication and addition, , thus: then the only family of functions satisfying this is the exponential function
no solution for the lead statement parameters, and constants defined over group of integers.
assume there is a solution for the lead statement parameters and constants defined over group of integers. for the statement , such that S where is the maximum stake value being , following from the previous proof that the family of function haveing independent aggregation property is the exponential function , and , the smallest value satisfying f is , then note that since thus , contradiction.
Leaky non-resettable beacon
Built on top of globally synchronized clock, that leaks the nonce of the next epoch a head of time (thus called leaky), non-resettable in the sense that the random nonce is deterministic at slot s, while assuring security against adversary controlling some stakeholders.
For an epoch j, the nonce is calculated by hash function H, as:
v is the concatenation of the value in all blocks from the beginning of epoch to the slot with timestamp up to , note that k is a persistence security parameter, R is the epoch length in terms of slots.
Protocol
Appendix
This section gives further details about the structures that will be used by the protocol. Since the Streamlet consensus protocol will be used at early stages of development, we created hybrid structures to enable seamless transition from Stremlet to Ouroboros Crypsinous, without the need of forking the blockchain.
Blockchain
Field | Type | Description |
---|---|---|
blocks | Vec<Block> | Series of blocks consisting the Blockchain |
Header
Field | Type | Description |
---|---|---|
v | u8 | Version |
st | blake3Hash | Previous block hash |
e | u64 | Epoch |
sl | u64 | Slot UID |
time | Timestamp | Block creation timestamp |
root | MerkleRoot | Root of the transaction hashes merkle tree |
Block
Field | Type | Description |
---|---|---|
magic | u8 | Magic bytes |
header | blake3Hash | Header hash |
txs | Vec<blake3Hash> | Transaction hashes |
metadata | Metadata | Additional block information |
BlockInfo
Field | Type | Description |
---|---|---|
magic | u8 | Magic bytes |
header | Header | Header data |
txs | Vec<Transaction> | Transaction payload |
metadata | Metadata | Additional block information |
sm | StreamletMetadata | Proposal information used by Streamlet consensus |
Metadata
Field | Type | Description |
---|---|---|
proof | VRFOutput | Proof the stakeholder is the block owner |
r | Seed | Random seed for the VRF |
s | Signature | Block owner signature |
Streamlet Metadata
Field | Type | Description |
---|---|---|
votes | Vec<Vote> | Epoch votes for the block |
notarized | bool | Block notarization flag |
finalized | bool | Block finalization flag |