This is part 4 of a series on Polkadot consensus. See Part 1 for an introduction, Part 2 for a discussion of GRANDPA, and Part 3 for a discussion of BABE.
first level title
election cycle
In order for validators to know that a block has more than two-thirds agreement, GRANDPA needs to know how many validators there are in total. The chain's governance process sets (and can change) the number, but the goal is to have at least 1,000 validators running BABE and GRANDPA in Polkadot.
Once we know how many validators will be in the set, we will hold an election to decide who becomes a validator.
Just as BABE splits time into cycle cycles, GRANDPA splits time into cycles. At the end of each cycle, past cycles are rewarded and elections are held for the next cycle. The cycle schedule is approximately 24 hours long.
Polkadot uses Nominated Proof-of-Stake (NPoS) to select validators and uses Phragmen's method for election. The introduction section discusses security in proof-of-stake networks in relation to value-at-risk. Users signal their intent to participate in the security of the network by locking funds, known as staking.
While the number of validators is limited, the number of people who can participate in the security of the network through staking is not. If you are not a validator, you can still participate by nominating. Nominators stake their tokens and choose 16 trusted validators to represent them. Nominators can enjoy the rewards of the validators they support, and they will also be punished accordingly.
A functional goal of Polkadot is to form an evenly staked validator set. Rewards are paid based on performance rather than equity, so nominators have the probability of obtaining a higher rate of return if they support some small validators.
award
award
Rewards are the main incentive for people to run validators on the network. As described in Sections 2 and 3, validators run the BABE and GRANDPA protocols to create and finalize the Polkadot blockchain.
Unlike other proof-of-stake protocols, Polkadot determines rewards based on validator behavior rather than each validator's deposit. Validators accumulate points based on their activity. Points are allocated primarily in the regular chain based on validity claims and generation. There are also credits issued for blocks that are not terminated in the regular chain.
When everyone clarifies the amount of total points in a period, it can only be converted into the corresponding token value after the end of a period. The distribution of rewards in a cycle is based on the proportion of points owned by the verifier in the total cycle points. Rewards are then distributed to nominators for each validator.
first level title
discipline and punishment
Rewards provide a reason to stake, but the network protocol must ensure that stakers follow the rules. Slashing tokens is a penalty for not following the protocol. To prevent being attacked, the security of the network requires that the penalty for an attempted attack be so great.
Violations range from overt slack to outright deceit. The most basic requirement for a validator is to be available online. Validators prove their validity by creating blocks or sending sentimental messages to the network. The probability of being penalized for going offline is very low, since every system experiences periodic downtime within reason.
But as long as validators pay reasonable attention to their infrastructure configuration, downtime should be a rare event with small penalties and easy recovery.
More serious violations are considered ambiguous. Ambiguous situations can occur in both BABE and GRANDPA. In BABE, ambiguity generates two chunks in the same slot.
In GRANDPA, pre-votes or pre-delivery messages are sent for two conflicting chains in the same round. Ambiguity often comes with severe penalties. If there are too many ambiguous verifiers, it is impossible to choose a single canonical chain.
first level title
super linear cut
You may have noticed that the rewards are not tied to the number of stakes of a single validator, so if there are enough tokens to run two validators, the rewards may also be doubled.
This behavior is to be encouraged. We expect that a single entity (whether a large number of token holders or as a service provider) will run multiple validators. Polkadot cannot do anything to prevent certain entities from acquiring large stakes and running validators. To prevent a single entity from gaining too much power, Polkadot allows them to increase their Stake when attempting to do damage.
Polkadot uses a superlinear slashing mechanism. As the number of substantively criminal validators increases, so does the percentage of token slash. If a single validator is ambiguous, it may be due to a poor infrastructure setup. But if 30% of the validators are ambiguous in a round, it is more likely to be a coordinated attack and thus increase the penalty.
As more validators become ambiguous, the penalties get progressively harsher. When more than 33% of validators are ambiguous (an event that would bring down the network), violators will be penalized by tokens down to 100%.
shared security
shared security
Security in a proof-of-stake network is based on economics, and because there is finite economic value in the world, there is finite security in the world. When the number of blockchains increases due to the single-chain scaling problem, its economic value and security are spread across multiple chains, and the value of each chain is more dispersed.
Smart contracts executed in a shared execution environment such as the Ethereum Virtual Machine can interact trustlessly. With Polkadot, the logical interface is moved from the single execution environment in the blockchain to the logic of the blockchain itself.
However, when considering how to make chains interact while breaking trust boundaries, it must be realized that trust does not come from executing in the same environment. Trust comes from operating under the same economic and national transition guarantees.
Polkadot introduces a security model for sharing chain-to-chain interactions, while fully understanding that information interaction chains have the same security guarantees as themselves.
A bridge-based solution (each chain handles its own security) forces the receiver to trust the sender. Polkadot's security model provides the necessary security guarantees for cross-chain messaging without having to confirm the security status of the message sending chain itself.
Relay chain blocks mainly contain validity proofs from parachains, which means that when the relay chain verifies the state transitions of the parachains, it shows that the states of both the relay chain and the parachains are fixed. To restore a parachain's blocks, an attacker would have to restore the entire Polkadot system, including adding each individual parachain and securing the race.
This system by sharing security in the relay chain does not even require parachains to provide their own security and the security of the verifier group. Polkadot's relay chain provides this economic guarantee so that chains in the Polkadot ecosystem can focus on growing the logic of their applications.
To learn more about Polkadot's consensus and economics, visit the Polkadot Wiki.
Original link:https://polkadot.network/
