Digital currency bottom-up compilation in Casper Blockchain development application

Blockchain Enthusiast (qq:53016353)
Betting consensus

Casper introduced a fundamentally new concept to the open economic consensus as its foundation: betting consensus. The core idea of a betting consensus is simple: provide the validator with an opportunity to bet which block will be finalized for the verification person. The betting on a block x here is a deal, in all chunks of the world where X is processed, the reward is given to the authenticator (the reward is "printed" out of thin air, and thus the "with the agreement"), whereas in the world where all block x is not processed, the authenticator is charged a fine of Z-currency (the penalty is destroyed).

(a world) should be understood here as a possible state of the future of the blockchain. )

This is a worthwhile transaction only if you believe that chunk X is likely to be dealt with in a world that people care about. However, the next interesting part of the economy is recursion: the world that people care about-the state that the user's client is showing when they want to know their account balance or the state of the contract-is based on what chunk of the block they are betting on. As a result, each validator has the incentive to bet on other people's bets as they expect, driving the process toward convergence.

A helpful analogy is a proof-of-work consensus-it looks very unique in itself and can actually be a special sub-model of betting consensus. The reasons are as follows: When you are mining based on a block, you are spending the electricity cost per second of E in exchange for the probability of the block p per second, and in all of your out-of-the-box fork to obtain the R-Currency, in the other fork is not a penny.

Therefore, every second, in your mining chain you can get the expected income of P*R-E, suffer the loss of e in other chains; so your mining options can be understood as betting that your chain has a e:p*r-e relative probability (odds) to win. For example, suppose P equals one out of 10,000, R is 25 currency is approximately equal to $10000, and E is $0.007, then your expected yield per second on the winning chain is 0.000001 * 10000-0.007 = 0.003, your loss in the failure chain is 0.007 of the cost of electricity, so you are betting your own mining chain has a 7:3 relative probability (or 70% probability) to win. Note that the workload proves to meet the requirements of the above mentioned economic recursion: the user's client calculates its account balance by processing the chain that has the greatest amount of work.

Betting consensus can be seen as a framework that contains a specific view of the workload proof, and is also suitable for other types of consensus agreements to promote convergence of economic game. For example, in the traditional Byzantine fault-tolerant consensus protocol, the concept of "pre-votes" and "pre-commits" is usually preceded by a final "commit" of a result, and in the model of betting consensus we can turn each stage into a bet, In this way, participants in the later stages have greater assurance that the participants at the previous stage "really mean that."

Betting consensus can also be used to motivate the right behavior of the human consensus outside the chain (Out-of-band human consensus) if necessary to overcome extreme situations like the 51% attack. If someone buys more than half of the coins in a POS chain and attacks, then the community simply negotiates a patch that allows the client to ignore the attacker's fork, automatically allowing the attacker and his partners to lose all their coins. A very ambitious goal is to allow the online nodes to automatically generate such bifurcation decisions-if successful, an undervalued but important conclusion in traditional fault-tolerant research-under strong synchronization assumptions, even if almost all of the nodes are trying to attack the system, the remaining nodes can still reach a consensus- can also be incorporated into the framework of the betting consensus.

In the context of betting consensus, different consensus agreements differ only in one thing: who, at what odds, how many bets can be cast. The proof of work only provides a bet: the relative probability of a e:p*r-e in the winning chain contains your own block. In the generalized betting consensus, based on a mechanism known as the scoring rule (scoring rule), we can essentially offer an infinite variety of bets: a note with a minimum of 1:1 on the pressure, a minimum of 1.000001:1 on the pressure, and a minimum note on 1.000002:1, so continue.

Participants can still choose the exact size of these tiny marginal bets at each probability level, but in general this technique allows us to detect a fairly accurate probability reading that the validator thinks a block will be confirmed. If the verifier thinks that a 90% probability of a block will be confirmed, then they will accept all bets with a relative probability of less than 9:1, rejecting a bet with a relative probability of more than 9:1, and the agreement can be based on this point to accurately conclude that the probability that the block will be confirmed is 90% "view". In fact, the display principle (Revelation principle) tells us that we can ask the verifier to give them a signature message that gives them a "view" of the probability of a block being confirmed, allowing the agreement to calculate bets on behalf of the authenticator.

Thanks to the magic calculus, we can get a simple function that calculates the total reward and the total penalty at each probability level, and the result is mathematically equivalent to the sum of the infinite set of bets formed on all probability levels based on the validation of the person's confidence. A simple example is s (p) = P (1-p) and f (p) = (p/(1-p)) ^2/2, here S calculates if you are betting on events that can get rewarded, F calculates if no penalty has occurred for you.

The generalized form of betting consensus has an important advantage. In the case of workload, the "economic weight" behind a given chunk only increases linearly over time: if a block has 6 acknowledgments, then it takes the miner about 6 times times the cost of a block bonus (in equilibrium), and if a block has 600 acknowledgments, the cost of withdrawing it is 600 times times the amount of the block reward. In a generalized betting consensus, the economic weight that validates a person's investment in a block can be exponentially increased: if most other validators are willing to bet 10:1, you might want to risk betting at 20:1, and once almost everyone increases to 20:1, you might jump to 40:1 or higher. Therefore, a block is likely to be in a few minutes, depending on how much courage the authenticator has (and the size of the excitation provided by the agreement), to achieve a "quasi-final determination" state, in which all margin of the authenticator is to support this block of bets.

At a height of 50000 feet: The blockchain is a predictive market for itself. chunks, chains, consensus and tug of war

Another unique thing about Casper is that its consensus is that it is agreed by block (By-block) rather than by chain (By-chain): The consensus process at a certain height is independent of all other heights of block state decisions. This mechanism does lead to a degree of inefficiency-in particular, a bet must express the validator's opinion of each block of height, not just the head block of the chain-but it is easy to implement a betting strategy for betting consensus under this model, and it has the advantage of being friendly to high-speed blockchain: theoretically, The block time in this model can even be more block than the network propagation time, because the blocks can be created independently of each other, although there is an obvious attached condition, that is, the final determination of the block will still take some time.

In a chain-based consensus, we can think of the consensus process as positive infinity and negative infinity at each fork point of the tug-of-war game, each fork of the "state value" meaning is the right-hand side of the longest chain of the number of chunks minus the left longest chain of chunks:

In order to find the "right chain" we just start from the Origin block (Genesis Block), at each fork, if the state value is negative, move to the left, and vice versa to the right. The economic incentive here is clear: once the state value is positive, there is a strong economic pressure to force it toward positive infinity, albeit slowly. If the state value becomes negative, there is strong economic pressure to force it to infinity.

By the way, in this framework, the core idea of the ghost scoring rule becomes a natural standardizing: instead of calculating the state value only by the length of the longest chain, calculate the number of the split-sided blocks:

There is also this tug-of-war game in a block-based consensus, but the "state value" is simply a number that can be arbitrarily increased or decreased by some operation of the protocol. At each height, if the status value is positive, the client processes the block, and if it is negative, it is not processed. Note Although the workload proves to be a chain-based consensus, it is not necessary: it is easy to imagine an agreement in which a block containing a valid proof of work does not refer to the parent block, but rather a +1 or 1 vote for all chunks in its own history. + 1 votes are awarded only if the block being invested is processed, and 1 votes are rewarded only if the block being invested is not processed:

However, such a design does not work well in the proof of workload because it is simple: if you need to vote for every historical height, the number of votes that will be required increases over time, and the system can be shut down quickly. In the betting consensus, because the tug-of-war game can be at the point of the speed of convergence to the final determination, the cost of voting is much easier to bear.

A counter-intuitive result of this mechanism is that a block can remain unconfirmed after the block is finalized. This looks like a big efficiency issue, because if a block state of 10 blocks is constantly changing, each change will cause the state transfer of the 10 blocks to be recalculated, but in fact the same thing happens in the chain-to-chain consensus, and a block consensus can actually provide more information to the user: If their deal is confirmed and finalized in the No. 20101 block, and they know that regardless of what the No. 20100 block is, the deal has a definite result, and the result they care about is that it has been finalized, Even part of the history before the result is not. The consensus algorithm that is reached by chain will never have this nature. So how does the Casper work?

In all security reserve-based proof of interest agreements, there is a group of secured validators, which are also recorded in the System state. If you want to bet or perform a key operation in a certain protocol, you must first join this group to ensure that your malicious actions will be punished. Joining and exiting a secured authenticator is a special type of transaction, and the key operation of the agreement, such as betting, is also a type of transaction. Bets can be transferred as separate objects on the network or packaged into chunks.

Based on the abstract spirit of serenity, all logic is implemented through a Casper contract that provides a range of functions such as betting, adding, withdrawing and obtaining consensus information, so we can submit bets or perform other operations by simply invoking the Casper contract. The internal state of the Casper contract looks like this:

This contract records the current set of validators and records 6 key data for each authenticator: the number of the current authenticator's margin for the return address of the authenticator's margin (note that the bet will increase or decrease the value of the validator) verification Code (validation code) the number of the most recent bet Comment form for the last bet's hash validator

The "validation code" concept is another abstract feature of serenity. Other proof-of-interest agreements require the authenticator to use a particular signature verification algorithm, while the Serenity Casper implementation allows the validator to customize a piece of code that accepts a hash and a signature for parameters, returns 0 or 1, and before the bet is accepted, The code can use the signature to verify that the BET's hash is correct. The default validation code is an Elliptic curve signature verification algorithm, you can experiment with other algorithms: Multi-signature, threshold signature (there is the potential to develop into a central pool of funds. ), Lamport signature (can resist quantum computers) and so on.

Each bet must contain a serial number that is 1 larger than the previous bet, and each bet must contain a hash of the last bet. So you can think of a validator's series of bets as a kind of "private chain", so to understand, the validator's opinion is actually the state of the chain. The verifier's opinion is a table that describes the following issues: At each height, the validator considers which is the best state of the root node at each height, the verifier thinks which is the best chunk hash (if there is no chunk hash generated can give 0) how much the probability of the hash corresponding chunk is finally determined

A bet is an object that looks like this:

The key information here is: The number of bets on the last bet of the hash signature comments updated composition of the list

There are three parts to the function of the Casper contract for dealing with bets. First, it verifies the number of bets, the hash of the last bet, and the bet signature. It then uses the new information in the BET to update the validator's comment form. A bet usually has only a few probabilities, chunk hash and State root node update, so the majority of the comment table will not change. Finally, it applies scoring rules to the comments table: If your opinion is to believe that a block has a 99% chance of being finalized, and if the block is finalized in a particular world running on that particular contract, you will get 99 points or you will lose 4900 points.

It is important to note that since this function of the Casper contract is executed as part of the state transfer function, the execution process is completely clear as to what each chunk and state root node is, at least in its own world. Even from the outside world, the verifier of the No. 20125 block to propose and vote does not know whether the No. 20123 block will be finalized, but when the verifier has processed the block, they will know it-or they may be dealing with both worlds, and then decide which one to follow. To prevent the verifier from offering different bets in different worlds, we have a simple and strict clause: if you have two bets, or if you submit a bet that cannot be processed by the Casper contract, you will lose all margin.

Two steps are required to withdraw funds from the authenticator pool. First, you need to submit a bet with a maximum height of-1, which automatically ends the betting chain and starts a four-month countdown (20 blocks/100 seconds on testnet), after which the bettor can withdraw his funds by calling another method, withdraw. Anyone can trigger a withdrawal and the funds will be sent back to the address where the join transaction was sent. Block Proposal

Each chunk contains (i) a number representing the height of the block, (ii) the proposed person's address, (iii) The transaction root node hash and (iv) the proposer's signature. The proposed address of a valid block must be the address of the authenticator who arranges the block at this height, and the signature must be validated by the authenticator's verification code. The commit time of a chunk with a height of N is determined by the formula T = g + n*5, where G is the timestamp of the Origin block. Therefore, in general, a new block appears every 5 seconds.

A NXT-style random number generator is used to determine who should come out of the block at each height, and inevitably, the missing chunk will also be a source of entropy. The reason behind this scenario is that although this entropy is manipulated, the cost of manipulation is very high: you have to give up creating a block to charge the proceeds of the transaction costs. If it is really necessary, we can also replace the NXT-style random number generator with a Randao-like protocol, further increasing the cost by a few more levels. Validate a person policy

So how do you act as a verifier under the Casper Agreement? The verifier has two main types of activities: out of block and betting. The out block is a process that is independent of all other events: The verifier collects the transactions, and when it is time to take their turn, they create a block, sign it, and send it to the network. The process of betting is more complicated. Currently, the Casper Default Verifier policy is designed to mimic the traditional Byzantine fault tolerance consensus: to see how other validators bet, take 33% values, and move further to 0 or 1.

To implement this strategy, each authenticator collects bets from other validators and keeps that data up to date to keep track of each authenticator's current opinion. If there are no or only a few other validators at a certain height, then we use the following algorithm: if the block of this height does not appear, and the current time is not long before the block should appear, then the estimated probability is 0.5 if the block of this height does not appear, And the time that the block should appear is a long time, then the expected probability is 0.3 if the height of the block has appeared, and on time, then the estimated probability is 0.7 if the height of the block has appeared, but the occurrence of premature or late, the probability is estimated to be 0.3

This process also adds some randomness to prevent the "stuck" scenario, but the basic principles are the same.

If a lot of comments have been posted to a certain height, then we use the following strategy: Set two-thirds the expected higher than probability l;m is the expected median (that is, half of the verifier's valuation is higher than m); Two-thirds the expected lower than the probability H. Setting e (x) is a function that makes X more "extreme", such as moving the value away from 0.5 to 1. A simple example is this piecewise function: E (x) = 0.5 + X/2 if x > 0.5 else X/2. If L > 0.8, then the expected probability is E (L) if H < 0.2, then the expected probability is E (H) Other cases, the expected probability is E (M), but the results can not exceed the [0.15, 0.85] This interval, so less than 67% of the verifier cannot force other verifier to significantly adjust their estimates.

In this strategy, the verifier is free to choose their own risk aversion by changing the shape of E. Choosing an e (x) = 0.99999 function at x > 0.8 is also possible (and likely to produce the same behavior as Tendermint), but it has a higher risk, and if the verifier of a large portion of the secured capital is malicious, they only need a very low cost, It is possible to design a validator that uses the E function to lose all of the margin (the attack strategy is a first-expected probability of 0.9, luring other validators to expect 0.99999, and then abruptly to the expected 0.1, forcing the system to converge to 0). On the other hand, a slow-convergence function can cause the system to be less efficient without being attacked because it will eventually be slower, and the authenticator will need to bet on each height for a longer duration.

Now, how do you determine the current state as a client? The process is basically as follows: First download all the blocks and bets, then use the algorithm above to form their own opinions, but not to announce the comments. It simply observes at each height in order, and if the probability of a block is higher than 0.5, it is processed, otherwise it is skipped. The status that is obtained after processing all the chunks can be displayed as the "current state" of the blockchain. The client can also give a subjective view of "final determination": when each block before the height of k is either higher than 99.999% or less than 0.001%, then the client can assume that the first K blocks have been finalized. Further research

The Casper and generalized betting consensus also requires a lot of research. This includes, in particular, the following: The evidence that shows that even some Byzantine verifier systems can be economically motivated to converge to find the best verifier strategy ensures that there is no loophole in the mechanism of packing bets into chunks to improve efficiency. The current concept prototype (POC1) can simulate the simultaneous operation of approximately 16 validators, ideally this number should be higher (note that the number of validators that the system can process in the production network is approximately the square of the conceptual prototype performance, since the concept prototype runs all nodes on a single machine).