# Dynamic Proof of Stake

## Overview

Darkfi is based off Ouroboros Crypsinous, a privacy focused proof-of-stake algorithm. Below you may find the technical specifications of DarkFi's blockchain implementation.

## Blockchain

Blockchain is a series of epochs: it's a tree of chains, , , , , the chain of the max length in is the driving chain .

Crypsinous Blockchain is built on top of Zerocash sapling scheme, and Ouroboros Genesis blockchain. Each part stores it's own local view of the Blockchain . is a sequence of blocks (i>0), where each it's a vector of that aren't yet in . the Blocks' \emph{st} is the block data, and \emph{h} is the hash of that data. the commitment of the newly created coin is: , is the clock current time. \emph{} is the coin's serial number revealed to spend the coin. is is from random oracle evaluated at , is the following epoch's seed. \emph{ptr} is the hash of the previous block, is the NIZK proof of the LEAD statement.

## st transactions

the blockchain view is a chain of blocks, each block , while st being the merkle tree structure of the validated transactions received through the network, that include transfer, and public transactions.

for , and for tuple iff:

• .
• . note here the nonce of the new coin is deterministically driven from the nonce of the old coin, this works as resistance mechanism to allow the same coin to be eligible for leadership more than once in the same epoch.
• .
• \emph{path} is a valid Merkle tree path to in the tree with the root \emph{root}.
• \emph{} is a valid path to a leaf at position in a tree with a root .
• note that this process involves renewing the old coin who's serial number gets revealed(proof of spending), becoming an input, to of the same value,

## transfer transaction

transfer transaction of the pouring mechanism of input: old coin, and public coin, with output: new return change coin, and further recipient coin. such that input total value is forward secure encryption of to . the commitment of the new coins , is:

### spend proof

the spend proofs of the old coins are revealed.

### NIZK proof

for the circuit inputs, and witnesses

is a proof for the following transfer statement using zerocash pouring mechanism.

path_1\text{ is a valid path to } cm_{c_1} \text{ in a tree with the root} \emph{ root}

path_2\text{ is a valid path to } cm_{c_2} \text{ in a tree with the root} \emph{ root}, sn_{c_2}=PRF_{root_{sk_{c_1}^{COIN}}}^{zdrv}(\rho_{c_1})

# toward better decentralization in ouroboros

the randomization of the leader selection at each slot is hinged on the random , , , those three values are dervied from , and root of the secret keys, the root of the secret keys for each stakeholder can be sampled, and derived beforehand, but is a response to global random oracle, so the whole security of the leader selection is hinged on .

## solution

to break this centeralization, a decentralized emulation of functionality for calculation of: note that first transaction in the block, is the proof transaction.

## Epoch

An epoch is a vector of blocks. Some of the blocks might be empty if there is no winnig leader.

At the onset of each slot each stakeholder needs to verify if it's the weighted random leader for this slot.

check if the random y output is less than some threshold

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 node would know the leader identity or how many leaders are there for the slot, until it receives a signed block with a proof claiming to be a leader.

is random nonce generated from the blockchain, is block id

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

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.

### target T n term approximation

• s is stake, and is total stake.

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

# Appendix

This section gives further details about the structures that will be used by the protocol.

## Blockchain

FieldTypeDescription
blocksVec<Block>Series of blocks consisting the Blockchain
FieldTypeDescription
versionu8Version
previousblake3HashPrevious block hash
epochu64Epoch
slotu64Slot UID
timestampTimestampBlock creation timestamp
rootMerkleRootRoot of the transaction hashes merkle tree

## Block

FieldTypeDescription
magicu8Magic bytes
headerblake3HashHeader hash
txsVec<blake3Hash>Transaction hashes
lead_infoLeadInfoBlock leader information

signatureSignatureBlock owner signature
public_inputsVec<pallas::Base>Nizk proof public inputs
serial_numberpallas::Basecompeting coin's nullifier
eta[u8; 32]randomness from the previous epoch
proofVec<u8>Nizk Proof the stakeholder is the block owner
offsetu64Slot offset block producer used
leadersu64Block producer leaders count