Shulou(Shulou.com)06/01 Report--

This article mainly explains "what is the core of Tendermint". Interested friends may wish to have a look at it. The method introduced in this paper is simple, fast and practical. Let's let the editor take you to learn "what is the core of Tendermint"?

The trap of proof of interest

Have no interest

At first, there are many different theories to describe the general trap of proof of interest, and no interest is proposed at this time. Jae Kwon first mentioned this issue under the unfortunate name of "wrong choice fallacy" in May 2014.

In July 2014, Vitalik popularized the exact definition of problems described by bitcoin developers as "non-interest". The problem is that the verifier can effectively break security without paying any price by voting for multiple conflicting blocks at a given height.

A simple PoS implementation is very vulnerable to these attacks. Disastrously, because there is no incentive to encourage people to focus on a single chain forever, and each incentive has to repeat signatures on conflicting chains at the same time, in order to get more block rewards, the best economic strategy is to vote on as many branches as possible. The following picture shows:

The expected number of votes on a competitive chain is higher than that on a single chain in a simple PoS design.

In the proof of workload, the "penalty" for miners digging on multiple chains is that they have to separate their computing power (a very scarce resource). In modern non-degenerate PoS designs, this cost must be embedded in the protocol to mimic the limitations of physical PoW mining.

Penalties in the "slasher" concept or protocol introduced by Vitalik Buterin in January 2014 can mitigate this attack. Jae Kwon further calculated this method in the same year, which is the first iterative progress in implementing the Tendermint consensus protocol. Harsh and permissive conditions are helpful for all non-degenerate BFT protocols, and even the three consensus presented in this article have been adopted.

Remote attack

Remote attacks stem from the right of the user to withdraw the deposit. This creates a basic problem because it means that an attacker can build a fork from any length of distance without worrying about being cut. Once the margin is unbound, the incentive not to vote long distances in front of a certain height block is cancelled. In other words, when verifiers with more than 2amp 3 unbind, they can maliciously create a second chain that contains the previous set of validators, which can lead to arbitrary transactions.

This is quite fatal for the proof of interest agreement, because the security model must be "subjective". When participating in the network requires a lot of social information, then the security model will be called "subjective". After a new node joins the network, different conclusions may be drawn about the current state of the network, because their decisions are based on subjective information, that is, social reputation. On the other hand, the security model of workload proof must be "objective", because the current network state is always the one with the most workload, and the new nodes always have the same conclusion about the network state, because their decisions are based on objective information.

PoS's remote attack is corrected under the weak subjectivity model, which requires access to subsequent new nodes in the network:

Must currently be bound. Only trust the verification node with the current margin.

The unbinding deposit must go through a "thaw" period. After unbinding, the token needs to be "unfrozen" for weeks to months to achieve the premise of "synchronization" (that is, delayed messages)

Recovery before N blocks is prohibited, where N is the length of the margin. This rule invalidates any long-distance bifurcation.

Optionally store the set of verifiers on the chain of PoW

Casper (s) and Tendermint use a simple locking mechanism (commonly known as "freeze" in "Tendermint") to lock down equity for a period of time ("thaw" after a few weeks to months) to prevent any malicious joint verifier from violating security. In CFFG algorithm, a bifurcation selection rule can only modify the block after the final block to prevent remote attacks. By using timestamps, long-distance bifurcations in CFFG are directly ignored by the protocol when they try to modify blocks earlier than the final block.

Cartel form

Third, the final obstacle is that any economy of arbitrary value will face a real oligopoly, even the local cryptocurrency.

"the cryptocurrency is incredibly concentrated, and so is the power of mining. Oligopoly competition is the norm in many real markets. Coordination between a few relatively rich verifiers is much easier than that between most relatively poor verifiers. In our case, the cartel form is completely expected."

Chapter 4 of the History of Vlad Zamfir,Casper

Tendermint relies on additional protocol management methods to confront oligopoly verifiers. Although there are no agreed measures on censorship, the basic principle for solving the formation of cartels by relying on out-of-band social information is that users will inevitably notice the formation of cartels and society will gossip about it. then give up or vote to reorganize the attacked blockchain.

So far, Vlad's Casper agreement is the only one that explicitly uses consensus censorship incentives to crack down on cartel forms.

Overview

There are many different ways to implement the algorithm of equity proof, but the two main principles of equity proof design are chain-based PoS and Byzantine fault-tolerant (BFT)-based PoS. Tendermint is based on Byzantine fault-tolerant PoS design, CTFG is chain-based PoS design, and CFFG is a mix of the two.

The CAP theory in computer science (https://en.wikipedia.org/wiki/CAP_theorem) returns the impossibility of providing more than 2 beat 3 guarantees in distributed data systems: availability, consistency, and partition fault tolerance. Chain-based PoS algorithms tend to choose high availability over high consistency, because high availability means that all transactions can be processed, but at the expense of consistent state replication throughout the network. BFT-based ones, on the other hand, tend to choose high consistency.

Proof of Rights and interests based on BTF

Byzantine fault-tolerant consensus algorithm originates from more than 30 years of rich research. Tendermint (2014) is the first PoS adaptation of the practical Byzantine fault tolerance (PBFT) algorithm introduced by Castro and Liskov in 1999. The PoS protocol based on BFT pseudo-randomly arranges a verifier to propose a block in the process of multiple rounds of voting. However, the commit and finalization of the block depends on the majority-- the verifier of 2 of the verifiers, 2 of all verifiers, signs the submitted block. Several rounds of signatures may be required before the block is finalised. The BFT system can only tolerate the failure of 1amp 3, which includes failure or malicious attack.

Tendermint core

Tendermint mainly includes two main technologies: blockchain consensus engine and general application interface. The consensus engine is called the Tendermint core module, which ensures that the same transactions are recorded in the same order in each machine. The application interface is called Application Block Link Interface (ABCI), which allows transactions to be processed by programs written in any programming language.

In the core module, Tendermint works on the basis of circular voting mechanism, which is also the principle of consensus protocol. A round is divided into three processing steps: the verifier proposes a block, sends the submission intention, and submits a new block after signing. This mechanism provides a secure state replicator for atomic broadcasting and adds a layer of responsibility-security failures can be completely attributed to Tendermint.

The Tendermint consensus algorithm starts from the set of verifiers. Verifiers maintain a full copy of the block chain and can use the public key to identify the verifier. They take turns to propose a block at each new block height. In each round of voting, only one verifier can propose a block and sign it with the corresponding private key of the verifier, so that if an error occurs, the verifier responsible for it can be found. The remaining verifiers then need to vote on each proposal, which needs to be signed with their own private key. These make up a round. However, it may be because the async of the network takes several rounds to submit a new block.

The verifier may fail when submitting the block for several reasons: the current proposal may be offline, or the network may encounter a delay. Tendermint allows the verifier to be skipped (that is, when it is a verifier's turn to block, but the verifier does not). The verifier waits for a short period of time to receive the entire block proposed by the proposer (the verifier of this round of blocks) before moving to the next round of voting. This dependence on timeouts makes Tendermint a weak synchronous protocol rather than an asynchronous protocol. However, the remaining protocols are asynchronous, and the verifier will process things only if it receives a verifier set message of more than 2gambit 3. Because of this, Tendermint needs most verifiers to be 100% operational, and if one or more verifiers are offline or offline, the network will stop running.

Assuming that the verifier less than 1x3 is Byzantium, Tendermint guarantees that security will never be breached-that is, the verifier (2x3 or above) will never commit conflicting blocks at the same height. As a result, Temdermint-based blockchains never fork.

So far, Tendermint's design decisions have indeed put security and immutability above flexibility. There is a high probability in the real world that the system will actually stop running and participants will need to restart the system after an update on some software by an out-of-agreement organization.

At a time when only a few people in the digital cryptocurrency community understand Casper and why it is valuable, Tendermint lays the foundation for Casper research. The insight is: if a chain itself is highly fault-tolerant, then you can rely on the chain to make a good decision about who will produce the block, but if the chain itself is unreliable, then you are caught up in the problem of chickens and eggs, which is the disaster of all other consensus algorithms before.

This design decision is considered inferior to usability-first protocols such as Ethernet Square and Bitcoin. The trade-off in Bitcoin is that if its network is split, Bitcoin loses its security in the event of various attacks. This is actually an immutable theory, that is, when your confidence interval is 100%, then you follow the right chain, and you will use this chain to choose who will produce the next block. but once you move to an unsafe chain, there is no clear path back to the right chain.

Explicit attributes of Tendermint

Provable activity

Security threshold: 1 verifier of Universe 3

Public / private chain compatibility

Immediate final certainty: 1-3 seconds, depending on the number of verifiers

Consistency first

Consensus Security in weakly synchronized Networks

Proof of Rights and interests based on chain

The chain-based proof of interest mimics the consensus algorithm of workload proof, in which the protocol allows pseudo-randomly selected verifiers to generate a new block. the new block is a hash join (including the hash value of the previous block) to the parent block of the previous longest chain. Chain-based PoS relies heavily on synchronous networks and usually gives priority to availability over consistency. Casper (s) is an adaptation of the core idea of Tendermint for environments that tend to be active rather than secure.

CFFG

CTFG is a clear PoS construct, but CFFG is a PoS-- that overrides the existing Ethernet Square PoW proposal mechanism, which combines PoW and PoS, and is implemented by Vitalik Buterin.

Neither Bitcoin nor Ethernet Square's PoW consensus protocol will make a "final" decision, and blocks may potentially be reorganized to some of the heights of past blocks. It can only be called "final" when the block has no chance to be modified. Because the workload certificate does not provide such a guarantee of modification, it is considered to be consensus unsafe. On the contrary, the final certainty probability of the block becomes higher and higher as we continue to lengthen the chain. In order to increase the desired final certainty and 51% attack resistance for the Etaifang block chain, the logic implemented by CFFG provides this effect perfectly.

CFFG will be launched in a number of steps to gradually transition from Taifang's PoW security mode to PoS security mode in a conservative way. The first iteration of Casper will be to implement the hybrid PoW/PoS protocol discussed here, and the last iteration of Casper is likely to learn from the lessons of CFFG and CTFG and move towards a complete PoS protocol.

CFFG is a hybrid of chain-based PoS and BFT-based PoS because it absorbs the ideas of both. Its modular coverage design makes it easier to update the current PoW chain because it is a more conservative approach to upgrading the system to a completely different consensus mode.

The application logic of Casper exists inside the intelligent contract. To be a validator in Casper, you must have an ETH and store the ETH in a Casper smart contract as a leveraged interest. In the first iteration of Casper, the block proposal mechanism is retained: it still uses the Nakamoto PoW consensus, and miners can create blocks. However, in order to finalize the block, Casper's PoS coverage takes control and has its own verifier to vote after the PoW miners.

The most important part of Casper's PoS consensus is the checkpoints. When Casper evaluates the final certainty when 50 chunks are incremented, it is called a checkpoint, and every 50 chunk fragments is called an epoch. The verifier triggers this process when a vote message is sent in each cycle.

It takes two cycles to finalize the checkpoint before one cycle, that is, two rounds of voting. For example, when verifiers (that is, most of them) of more than 2amp 3 vote for a checkpoint c, the checkpoint is said to have been "tried". In the next cycle, when most people vote for checkpoint c, two things happen: c becomes tried and c has been finalised. C this cycle also represents the final cycle (LFE).

Recall that the finalization of a block requires two conditions:

Most (more than 2amp 3) verifiers voted for Block 1 at cycle 1, so Block 1 was tried.

Most of the verifiers (more than 2amp 3) voted for Block 2 at cycle 2, which is a subblock of Block 1, so Block 1 is finalized at cycle 2.

In an ideal execution, the finalization of a block follows the following steps:

Block 1 2 → 3 vote → trial Block 1 → 2 + 3 vote Block 2 → final Block 1

Where block 2 is a sub-block of block 1

When a checkpoint is finalized, the verifier is paid. However, if there are two final checkpoints branching at the same height, the security is compromised, the condition of abatement is reached, and the deposit of at least 1 hand 3 will be reduced. Evidence of misattribution can be broadcast to PoW miners as a transaction when security is breached. PoW then divides the evidence transaction into a block for mining, and the verifier who submits the evidence will receive the finder's fee. When this happens, the guilty verifier signed in the conflict block will be subtracted from both chains.

Now what happens if a miner makes a brute force attack? Now Casper's final blockchain prevents PoW attackers from rewriting history beyond the latest checkpoint with 51% or more computing power. Therefore, the Casper protocol provides security. Unlike CTFG, because CFFG is a layer of coverage on different proposal mechanisms, Casper cannot guarantee activity, because activity depends on the proposal mechanism.

Verifiers are inspired to gather on the chain of authority because they will be punished if they continue to vote on different chains. The formation of slasher 2.0 allows verifiers to be punished not only for double voting but also for voting on incorrect chains. However, this also creates a "discouraging" dilemma, because the verifier is worried that if there is a fork and he is not sure which one is the authority, and then the wrong vote will be reduced, so he chooses to withdraw from the vote.

Explicit attributes of CFFG

Finalization: finalization in more than 20 minutes. Every 50 blocks (a cycle), the block is finally transformed to prevent PoW mining from profiteering attacks.

Consensus security

Provable activity

Priority availability

CTFG

CTFG is the correct Construction of Vlad Zamfir (CBC) consensus protocol designed to combat the real-world environment of oligopoly. CTFG is the PoS adaptation of GHOS (https://eprint.iacr.org/2013/881.pdf) or GHOST protocol in workload proof, which is used for its bifurcation selection rules. The guiding design principles behind CTFG are based on encryption economics, using formal methods designed to achieve security assessment. Unlike the CFFG hybrid agreement described in detail earlier, CTFG is a pure proof of interest concept.

"Casper started out as a simple 'friendly ghost', an adaptation of GHOST for PoS, and a perfect incentive for cartels to become 'non-cartel' verifiers."

Chapter 5 of the History of Vlad Zamfir,Casper

Similar to workload proof, CTFG makes tradeoffs between consistency and availability. In particular, when the blocks are not finalized, the deeper they are in the chain, the safer they will be. CTFG is similar to CFFG in that the processing of chain headers is always much faster than that of block finalization.

The biggest difference between Casper's PoS proposal mechanism and Tendermint proposal mechanism is that compared with pseudo-random selection of leaders, the verifier of the former can propose blocks based on the blocks they see.

A unique feature provided by Casper is parameterized security thresholds. Similar to using six confirmations in Bitcoin to determine the final state of an economy, "evaluating Security" in CTFG provides a verifier with a different security threshold from other verifiers. The design goal of Casper is to allow verifiers to choose their own fault tolerance threshold when the network maintains low PoS overhead.

The core advantage of Casper over Tendermint is that the network can accommodate a certain number of verifiers at any time. Because chunks in Tendermint need to be finalized when they are created, the confirmation time for chunks should be shorter. In order to achieve a short block time, there needs to be a limit on the number of verifiers that Tendermint PoS can accommodate. Since both CTFG and CFFG do not require security when the block is created, the ethernet network can accommodate a little more verifiers than the cosmos can accommodate 100 verifiers.

Explicit attributes of CTFG

Availability. Casper nodes can fork before they reach a consensus.

Asynchronous security

Existence. Casper's decision can survive partial synchronization, but not asynchrony.

Cartel resistance. The whole premise of Casper is based on resisting oligopoly attackers, so no collusion verifier can go beyond the agreement.

Security. Depends on the evaluation security threshold of each verifier

At this point, I believe you have a deeper understanding of "what is the core of Tendermint". You might as well do it in practice. Here is the website, more related content can enter the relevant channels to inquire, follow us, continue to learn!

Welcome to subscribe "Shulou Technology Information " to get latest news, interesting things and hot topics in the IT industry, and controls the hottest and latest Internet news, technology news and IT industry trends.