How Validating Works

In this section, we will discuss how validating works. The different actors of the mechanism and the technological solutions will be presented.

FIGURE 1: How Validating Works?

Actors

Two types of actors are involved in the block creation process:

• The Delegate, that can be:
  • a validator, who participates in the consensus by creating new blocks and by attesting the blocks created by other validators.
  • an Accuser, who participates in the consensus by monitoring the work done by validators.
• The Delegator, that can delegate their tokens to a Delegate.

Before we dive in, lets define a cycle and some important nomenclature around it:

Cycle

The Mavryk consensus is organized in cycles. One cycle corresponds to BLOCKS_PER_CYCLE = 16,384 blocks (≈ 2.8 days). At any point, the shell will not implicitly accept a branch (chain of blocks) which fork point is in a cycle more than PRESERVED_CYCLES = 5 cycles in the past (≈ 14 days).

We also define:

• BLOCKS_PER_CYLCE = 16,384 blocks.
• n, th current cycle.
• PRESERVED_CYCLES = 5 cyles, i.e. the number of cycles during which the tokens are frozen.

Roles of a delegate

Validating

Validating is the act of creating, signing, and publishing blocks.

Validators select and validate all transactions and add them to the blockchain. If a validator behaves dishonestly, the protocol has a built-in mechanism that can cause them to lose their security deposit.

Validators are rewarded with MVRK for securing the network.

In Mavryk, the right to produce a block in a cycle, lets denote it as cycle n, is assigned to a randomly selected delegate in a randomly selected stake snapshot from cycle (n - PRESERVED_CYCLES - 2).

Validators are randomly selected from the list of all nodes that have declared themselves as delegates, in proportion to the amount of MVRK they have staked and delegated to them.

A validator is a delegate, while a token holder who delegates their MVRK is a delegator. Note that a Validator does not necessarily need delegators to function, they can run solo, but they have fewer chances to be selected for validating.

The selected validator is allowed to create the next block and add it to the chain, they then communicate that new block in the chain's sequence to the network. As a reward for their work, they receive a certain number of MVRK upon successful block creation and acceptance.

At the start of the process to create a block, several validators are elected to create the block from a priority list. The one with the highest priority will try to create a block. If they fail to do so within a time limit, the job will pass to the next validator. A block generated by the validator that does not have priority will be invalid and refused by the network.

To create a block, a validator has to freeze part of their tokens, which will be made available back to them only PRESERVED_CYCLES = 5 cycles later.

A validator can be marked as either active or passive. A passive delegate cannot be selected for validating or attesting. A validator becomes passive in cycle n if they fail to create any block or attestation in the past PRESERVED_CYCLES cycles, that is to say, in cycles n-1, n-2, …, n - PRESERVED_CYCLES.

Attesting

Among the validators, a list of validators is drawn up for each block. Their role is to attest the blocks created by the validator (i.e. to officially attest the block) in exchange for a reward.

To attest a block at level n, the validators each add a signature operation that is included in the n + 1 level block. Once the block n + 1 is created, no more attestation operations are accepted for block n.

Each block has 7,000 attestation slots. There is no obligation for a validator to include attestations with attesting power more than 2/3 of the total attestation slots but the validator will receive a bonus proportional to the extra attesting power of the attestations included.

A validator may obtain several attestation slots for a given block. They will then be rewarded for each attestation slot completed (i.e. for each slot validated).

Accusation

There are also accusers. This is a delegate who monitors validators so they don't create two competing blocks at the same level nor attest multiple blocks.

If an accusation is correct, the accuser gets a part of the funds that were frozen by the validator as a reward. The remaining part is burned.

Any attempt to fraudulently double-validate (creating 2 blocksat the same time) is punished.

Delegates' rights selection

At each cycle, a random seed is created. A pseudo-random number generator uses the seed to generate the priority list based on a stake snapshot 2 cycles ago.

Stake snapshots

Snapshots of delegates' stakes are done every 1024 blocks and define who can bake. The probability to sample a particular delegate is its stake in the snapshot over the total stake in that snapshot.

A stake snapshots represents the stake distribution for a given block. Stake snapshots are taken every BLOCKS_PER_STAKE_SNAPSHOT = 1024 levels.

Random seed

Since Mavryk runs a deterministic protocol, there is no real randomness. More specifically, there is no randomness in the snapshot selection and validating/attestation slots attribution, i.e., we know the result before the operation occurs (unlike in PoW where you can only estimate it).

The seed is created by requesting a secret number (nonce) from all delegates. All secret numbers are gathered and used to create a hash that will be used as the random seed. Since the last owner to reveal their secret already knows the other numbers, a 2-phase process called "Commit & Reveal" is necessary.

The random seed for cycle n is a 256-bit number generated at the very end of cycle n-1 from the previous seed and the nonces that delegates commit during cycle n-2.

In cryptography, a nonce (number used once) is an arbitrary number intended to be used only once.
A commitment is the hash of a nonce.

FIGURE 2: Commit & Reveal

One out of every BLOCKS_PER_COMMITMENT (= 32 blocks) can contain a commitment. There are therefore, at most BLOCKS_PER_CYCLE / BLOCKS_PER_COMMITMENT (= 128 commitments) per cycle. The commitment is generated by the validator who produces the block and is included in the block header.

In summary, the seed for cycle n is a hash created from:

• the seed of cycle n-1, a constant.
• every nonce that was revealed in cycle n-1

This seed is used to randomly select:

• a stake snapshot from cycle n-2
• delegates in the selected snapshot

Validator selection

The generated list of priorities identifies which delegate has the responsibility to validate a block and which delegates have to attest this new block. It is a round-robin process that cycles on the list of priorities until the end of the cycle (4096 blocks).

A round robin is a way of choosing all elements in a group equally in some rational order, usually from the top to the bottom of a list and then starting again at the top of the list and so on.

Minimum time delay before validating a block

The minimum time delay between two blocks is 15 seconds, reached if the validator is of priority 0 and has gathered at least 66.7% of the attestations. If the priority 0 validator fails to validate, the priority 1 validator may then validate the block after a certain time, defined by a so-called round duration function. To be able to validate as rapidly as possible, the validator must gain enough attestations (66.7%, that is, endorsements with endorsing power of at least 4,667 out of 7,000). Rounds follow the structure below:

$$\bm{round\_duration(0) = minimal\_block\_delay}$$

$$\bm{round\_duration(r+1) = round\_duration(r) + delay\_increment\_per\_round}$$

$$\bm{round\_duration(r+1) = minimal\_block\_delay+(r+1) ∗ delay\_increment\_per\_roundd}$$

Round duration thus increases linearly with DELAY_INCREMENT_PER_ROUND = 8s, MINIMAL_BLOCK_DELAY = 15s,r = round.

Any block validated ahead of the minimum time delay is automatically rejected under the protocol's rules.

Remote signing

Remote signing software is one way to reduce the exposure of private keys during validating operations.

In the block validation process (validating/attestation), the software interacts with a private key management system (e.g. Ledger Nano S, a remote machine communicating via a secure channel).

Remote signing involves physically separating validating/attestation requests originating from the network and intended for a given delegate, from that delegate's signing operation. The Mavkit client implements several built-in signing mechanisms (unix, tcp, http, and https) that use different communication channels to send signing requests for the validator.

The following events occur during a remote signing operation:

1. The node sends a signing request to the remote signing software that interacts with the private key management system.
2. The remote signing software verifies what the operation involves − usually the creation of a block or an attestation (The third, rarer option is a nonce revelation.) − then sends it to the key management system, which signs the operation.
3. The signature is then validated by the remote signing software and sent back to the Mavryk node, which propagates the operation to the network.

The key should preferably be held in a hardware vault so it is never directly accessible on the network. Moreover, it is more secure to ensure that the hardware vault authorizes only block signing rather than the signing of just any transaction (i.e. such as not to create a blind signing mechanism). For example: Ledger Nano S together with Kiln meets these two conditions.

In summary

• At each cycle, a priority list of validators is chosen and up to 7,000 delegates are chosen to attest the block of validators. The validators are elected pseudo randomly in proportion to the quantity of Mav that they possess.

By abuse of language, we often designate by validators: the different validators creating blocks and attesting them. Because in practice, they are the same entities that carry out the operations of creation and validation of blocks.

• To become a delegate, one must freeze a part of their tokens, at least 6000ṁ, which will be made available to him only 5 cycles later (14 days).

• A validator is a delegate and the one who delegates their MVRK is a delegator. Note that a validator does not necessarily need delegators to operate, they can play solo, but they will be less likely to be selected to create the block, because they will have less funds at their disposal.

• Several validators are added to a priority list. The one with the highest priority will try to create a block. If they fail to do so within the time limit, the hand will pass to the next validator. And so on.

• The first validator who manages to create the block will be able to add it to the blockchain. They will receive a certain number of MVRK as a reward. In turn, validators share the additional revenue generated from the delegated tokens with the delegators, in proportion to their participation.

• The accusers monitor the process and punish the cheaters.

FIGURE 3: Summary Diagram

Conclusion

The Mavryk consensus protocol uses the Liquid Proof of Stake algorithm. Delegates (people who have at least 6,000 ṁ of delegated funds) are given the responsibility of creating and attesting blocks. They are rewarded for their action. They are also required to lock a portion of their capital as a security deposit to ensure honest behavior.

References

[1][https://protocol.mavryk.org/008/proof_of_stake.html](https://protocol.mavryk.org/008/proof_of_stake.html)

[2][https://protocol.mavryk.org/active/proof_of_stake.html](https://protocol.mavryk.org/active/proof_of_stake.html)