Geekly Articles each Day
⬆️ ⬇️

Proof-of-Stake: Inside View



There are many philistine articles and discussions on the Internet, but there is not enough information on the merits. At a certain moment, it became clear to the author that the mechanics and the many safety related nuances are not completely understood even by many cryptocurrency developers. This was revealed in the real case of porting the implementation of PoS for one of the cryptocurrencies and in further publishing information about the vulnerabilities found by third-party experts.

This article will be useful to all developers who have already encountered PoS vulnerabilities or who are still to come.



Horror under the cut.



Bit of history



The birth of the Proof-of-Stake (PoS) in Peercoin after the discussion at one of the forums in 2011, the subsequent use of the Novaoin and further distribution in the PIVX and other Bitcoin forks is traced on the Internet. The rather primitive PoS-logic was brought to the module kernel.h / kernel.cpp , which wanders through forks in the form of various Frankensteins.



The PoS algorithm has gone through several stages of development, someone gives them versions. Now the PoS options are divided for natural reasons, DPoS appeared. One of the most advanced solutions is the Casper protocol in Ethereum.



Any blockchain needs block generation and for someone there must be the right to build a new block. If the author does this in a blockchain like the Git version control system without much competition, then in cryptocurrencies there is a fierce struggle for the block reward within the Proof-of-Work (PoW) - finding such a combination of variable input parameters by selecting deterministic target (mining, mining).



PoS replaces Proof-of-Work (PoW) in order to avoid wasting resources on mining. Instead, all input parameters are strictly set with a constant characteristic based on the existing savings of the coin holders. Therefore, PoW is required as a starting point for PoS, if you do not resort to different variants of the initial pledged enrichment of the coin's creators.



What for?



Saving energy is about as important for developers and coin holders as limiting greenhouse gas emissions for producers and consumers. Cruel truth in another:



  1. PoW-based projects are subject to so-called. "51 percent attacks": attackers can throw more power, create a parallel chain, and then suddenly publish it with a different movement of coins on the accounts (ie, double waste)
  2. PoW miners need to cover their costs and invest in building capacity - this is a direct outflow of capital from projects,
  3. savers want to maintain their purchasing power by self-capitalizing themselves, rather than looking at natural inflation.


On a live example: in November-December 2018 there were attempts to attack; then in December and February there was an excitement like on the most profitable coin for mining on video cards; the rate sank from 2+ to 0.5 USD; after switching to PoS, the rate went up to 1 USD in a week and the inflow of investments increased.





Technical points



Attention: in this context, we are talking about the "traditional" PoS in the form as it is in Peercoin, PIVX and their forks.



It is necessary to understand that there is no centralization and accounting of "points". In this embodiment, the same principle of luck works as in PoW.



1. Terminology



Terminology is relatively common, but its implementation has different nuances:





2. Anatomy



Generation process:



  1. Find all utxo that meet the requirements of Stake Input.
  2. Find Stake Modifier.
  3. Multiply the PoW Target by the amount of Stake Input.

    • in ppm in fact - so the 1 MH PoW hash experimentally goes out to be equal to one coin.
  4. We Stake Hash = H(Stake Modifier, Stake Block Time, UTXO output index, UTXO txid, Current Block Time) .

    • variable parameter only current block time
  5. If Stake Hash >= Stake Target , then we try to pick up the Current Block Time in the allowed interval.

    • consider the possibility of an overflow of Stake Target when multiplying by the amount of Stake Input, depending on the implementation.
  6. We put Coinbase at tx [0], and CoinStake at tx [1].

    • The beneficiary of Coinbase is the same script (address) as that of Stake Input.
  7. Sign the block.


2.1. Block time:



It is easy to see that a scam over time can provide some benefits. Standard consensus limits the lower and upper limits.



The lower ones always set the average block time for the last N blocks, usually over 11. This is the tolerance for time inaccuracy on the generating nodes.



The historic upper limit was set for PoW with a finger at the sky at 2 o'clock. Increasing the intervals reduces the complexity and makes the branch less attractive - so there is no point. But for PoS there is a sense.



PIVX and others limit future time to a maximum of 3 minutes. Some put a more rigid restriction, but this creates problems for users. Some PoS implementations have decided to change the minimum intervals of the Current Block Time from one second to 15-16 seconds.



2.2. Stake Modifier:



Stake Modifier was conceived as a means to obscure the prediction and construction of the chain in advance, but something went wrong ...



There are various ways to calculate it: the last bits of block hashes at the ends of progressively specified time intervals, [bad times] poorly predictable values ​​from previous blocks, etc. In some places it looks more like obfuscation of a code than something imputed.



In the original, a gap of 64 intervals is taken. This gap is progressively divided into 64 unequal parts. Borders are rounded to minutes. Existing blocks are selected along the borders and one last bit is taken from them. So it turns out the number in 64-bit, something similar to Nonce.



The interval in Peercon is 20 minutes, but the guys from PIVX decided that the interval of 1 minute, rounded to the minute, is what the doctor prescribed.



In general, in some implementations of the Blackcoin V2 + type, everything is fixed and Stake Modifier is counted from the head, and in Peercoin V03, PIVX, Blackcoin V1 and others from the Stake Input block. The latter almost completely destroys the meaning. There is an assumption that the confusion has gone because of the banal problem of naming variables, further metamorphosis and thoughtless copy-paste. And the author himself rather late discovered the problem while all the attention was focused on protection against DoS. Do not get caught!



2.3. Block signature



Since the block hash no longer serves as proof of work, and anyone can take a signed CoinStake transaction from another block, you need to check that the block was created by the owner of Stake. Therefore, the header is signed with the same private key as CoinStake.



2.4. CoinBase and CoinStake exit script



The same exit scripts, or as the wallet addresses are called, are required to preserve privacy and avoid linking individual addresses in the same wallet.



2.5 What and where?



There are different variations on how to manage the amounts in CoinBase and CoinStake. Logic and motivation in a specific case:



  1. Amounts must be split to avoid even the smallest possible loss of user funds due to processing errors.
  2. CoinBase retains its 100 confirmations, but CoinStake can be spent immediately, which of course leaves the risk of double spending.

    • tying in to the depth of the blocks also contradicts the age requirement for use as Stake Input.
  3. CoinBase and CoinStake should never fall into the mempool, and all transactions based on them should be deleted when the chain is rebuilt.


3. Complete blocks against headers



The entry of a full-fledged node into the network begins with synchronization. In Bitcoin, synchronization is primarily based on block headers, since they contain sufficient information to pre-test compliance with consensus. First, relative small headers are packaged and checked up to 2,000 packs from one third-party node. If the initial test was successful, then all blocks are drawn in parallel from all connected nodes.



Protection against flooding is based on the fact that the local node compares the best known header with what it has and requests the entire chain of headers. As you download, everything is checked by the small cost of disk space and calculations. Chains are compared in their weight based on characteristics such as chainwork , which is the sum of the complexity of each individual unit. To build such a strong alternative chain will require extremely large investments of resources, which makes attacks unpromising.



With PoS, this approach does not work, because to check the blocks, it is required to process complete previous blocks at least up to the minimum age limit of Stake. The implementations reviewed by the author did not pervert, but simply refused to work with the headings.



Therefore, the author implemented a parallel opportunistic downloading of blocks after the headers, which significantly increases the synchronization speed due to the use of all connections. Minor delays occur only if peers are on different circuits - then the connection is broken after a minor timeout, as in the standard scheme. As a minus, the tendency to choose a false chain at the time of synchronization.



By the way, the standard Bitcoin client and its forks dial the minimum standard number of outgoing connections into 8 pieces for quite a long time, if some of them break down for various reasons. This was resolved by asynchronous outgoing connections.



4. Forks, splits and orphans



When competing to create blocks, alternative chains of 1-2 links are relatively commonplace. Longer forks in developed networks naturally occur only during epic failures in consensus due to a programming error or a global Internet break.



Even with separation, there is usually no threat to the integrity of transaction processing, since when blocks are disconnected, all transactions fall back into the mempool and are included in other blocks. Mempool is a temporary repository of transactions after they are created. The mempool itself is saved to disk in recent versions. The reward for the block is destroyed. That is why for awards set the minimum number of confirmations (depth).



It happens that local network segments lose contact with the outside world and continue to mine, assuming a connection to the main network. Such branches are usually not a threat because of their natural weakness.



The main attack of 51% for PoW is already described above - it is extremely resource-intensive, but for PoS it becomes relatively accessible. For this reason, it becomes technically possible to produce many branches from different chain links. One of the classic solutions is to prohibit forks below a certain depth.



The main problem of such protection is the impossibility of nodes from hermit segments to return to the main circuit independently after restarting.



Therefore , an approach was adopted to ban forks over a certain period of time only if the top of the chain is quite young.



With a target interval of blocks of 1 minute, the criterion of the old fork was chosen at 1 hour, which roughly corresponds to 60% of CoinBase confirmations, and the criterion of youth of the crown at 15 minutes is 3+ times higher than the maximum statistical block lag.



5. Block hash and splits



In PoW, the block hash completely covers all the data. It is used to check against the target. In PoS, Stake Hash is a separate value, because it is necessary to exclude the possibility of its selection. This opens up the main threat - the ability to produce an unlimited number of different versions of the block based on the same matched Stake, with which it is easy to flood and put a network or its individual nodes.



Naive approaches to protection generate new even more serious vulnerabilities of the split. One of these approaches in different variations is to allow the use of Stake Input only once. A simple attack is to send different blocks to different nodes, which immediately gives rise to a soft split.



Even more fatally, it is possible to exacerbate it with DoS-ban, which will divide not only the chains, but also the network itself into different segments.



There are other problems - the inability to use Stake from a dropped block.



Therefore , the choke method was chosen as the safest solution - the same Stake can be used no more than once per minute. The logic is simple: an attack can last only in the interval of 1 hour (see the old fork above), for which it is possible to flood no more than 60 blocks. At best, on the next block, the network will already go over to a single chain. In the worst case, with a continuous attack, this will happen in an hour. The probability of the worst case - finding several blocks in a row, melts exponentially.



Still, there are some moments at which the nodes are vulnerable to moderate flood until full synchronization .



6. Minimum age



For some, this limitation is puzzling, but it is extremely important for network stability, since This parameter is directly related to the maximum length of the alternative network, which the local node can check without serious technical distortions.



As mentioned earlier, the local node must process all blocks before the time boundary of the age in order to be able to verify that Stake Input a) takes place to be b) is indeed UTXO and has not been spent.



Check this is possible only through the functionality of the so-called. CoinView, which is the state of movement of coins at the time of a particular block, is the top of the main chain in the sense of the local node.



The implementation of a complete test of alternative circuits at time intervals or even in a special way saved by the CoinView looks unpromising, since The number of these alternative chains is infinitely large.



Too big a bar for the age qualification of UTXO adversely affects users who want to spend or merge part of their coins.



If you specify this boundary in the depth of the blocks, then a hypothetical stalemate situation is possible to completely stop the circuit due to the fact that there is no suitable UTXO. In the case of units of time, at least some movement occurs.



Therefore , a balanced and working choice in other networks is used at 1 o'clock in absolute time units, and not the depth of the blocks.



7. What is better than N UTXO for the minimum amount or one UTXO with N amount?



Here the analogy suggests itself: that one gun is better with an accuracy of 0.9 or three guns with an accuracy of 0.3, but with probabilities of the order of 1/2 ^ 20, the results of such calculations would seem to be leveled. A little card confuses the qualification of maturity.



The prevailing view that many small transactions find more blocks, probably went from the time when the age of Stake Input was also taken into account for determining the weight. Then the old small transactions really had significant meaning.



At the moment, on the basis of practical experiments and theoretical calculations, grouped in large UTXO amounts bring more blocks. In addition, fewer UTXOs require less CPU. Someone claims the opposite.



So think for yourself.



8. Running Forward



PoS miners naturally a little ahead of the time blocks. This reflects the complexity of the network for the worse. The standard Bitcoin code selects the first block received, regardless of the time specified in it. Most PoS implementations do the same.



Therefore, the logic of the PoS miner has been changed to begin the selection of the average time of the blocks, if the time of the current block has gone ahead. At the same time, before comparing the sequence, the nodes compare the indicated time of the blocks. The PoS miner sends the found block to the network even if it sees that it generates a fork.



In this way, the network is also protected from hypothetical prematurely sent out blocks, whose Stake Input cannot be used in the next 60 seconds with the same Stake Modifier due to DoS protection. As if double punishment for cheating with time.



9. Small checklist



  1. Stake Input must be valid UTXO before fork point:

    • in the case of the main chain, the fork point is the tip,
    • in the case of an alternative circuit, the UTXO after the fork point may result in self-DoS when switching,
    • it goes without saying that UTXO should not be in mempool.
  2. Do not take CoinStake in mempool when rebuilding the main circuit:

    • the same happens with CoinBase,
    • this may destroy the transaction chain (unlikely).
  3. Do not take forks from old blocks, if the top is quite lively.
  4. The age requirement in absolute time units for Stake Input is necessary for stability and security.
  5. Stake Hash should change only from block time.
  6. Stake Modifier should not be tied to a Stake Input block.
  7. Working with block headers requires special processing on the network and during reindexing.
  8. CoinStake is recorded in the local wallet and requires some changes to correctly display orphans.
  9. PoS miners most likely have enough jambs and need to be modified by a file.
  10. Re-index needs some work, because works by analogy with headers - at first it loads and checks only the index of blocks, and then only tries to process the blocks.
  11. If the transition to PoS is not rigidly set, but through spork, then it should be caught on the boot, because sporks are not saved.
  12. Checkpoints in Dash and Bitcoin are almost props and require very serious work.
  13. If the fork of Dash is up to version 0.13, then there are problems with the processing of the master data in the mode of using a simple user.

    • If the client restarts frequently, the network view is distorted.
    • It is better to simply ignore the cache if running in graphical mode.
  14. Change the choice of the best block, taking into account the block time.
  15. Bitcoin .
  16. mempool CoinStake .








. mainnet PoW , , PoS, . PoS Ethereum Casper'.



GPU - — ethminer'. 150-200 GH (ethash). - PoS .



PoS PIVX 2.x " ". - PIVX , , . , PIVX 2.x . Dash 0.12 Bitcoin'.



, PoS . , , .





Documentation



. . whitepaper -.





PoS PIVX Bitcoin/Dash. CoinStake . PoS .



, Stake Modifier Stake Hash , Stake Input . - , - PIVX .





— . :



  1. .
  2. .
  3. — .. , .
  4. , - , .


. spork' , .



, . spork' .



PoS



, - . spork, , .





, .. . , .





testnet, .



testnet 3 1 mainnet, .





PoW , PoS - , 1e6 PoW.



. mainnet Stake Input.



.



PoS



X spork PoS . - , .



. , . .



, , .





Stake Modifier . . PIVX - … , , Ethereum, .





Conclusion



- , . , PoS , . .



: - .



GitHub



')

Source: https://habr.com/ru/post/442862/

More articles:



All Articles