The following shows our current and planned expectations regarding the probable maximum depth of on-chain reorganization. We would not consider transactions within this depth to have an exceptionally high probability of being permanent. These are our own expectations only and do not constitute any type of guarantee. They are derived from theoretical considerations, ongoing empirical data, human factors in contingency planning, and the past experience of our security team. As with all things in the peer-to-peer space, the risk falls entirely on the individual operator.
In the same way as many in the space, we will be monitoring the chain for signs of problems at the protocol level. If we have any reason to suspect that there is a protocol level problem we will update these expectations respectively; updates will be posted on the forums and on the official blog. All those who are interested in our expectations and recommendations would do well to keep up with the blog.
ROAD MAP
Until 08/08/2015 18:00:00 CEST: 6000
As of 08/08/2015 at 18:00:00 CEST, 3000 (approx. 12 hours)
(1 day)
As of 08/09/2015 at 18:00:00 CEST, 1500 (approximately 6 hours)
(Three days)
As of 08/12/2015 at 18:00:00 CEST, 750 (approximately 3 hours)
(Three days)
As of 08/15/2015 at 18:00:00 CEST, 375 (approximately 90 minutes)
(Rest of the Border)
ADDENDUM 2015/08/08: You may be a bit stumped as to the meaning of “chain reorganization depth”. On-chain reorganizations happen when a node on the Ethereum network (one that could belong to you, me, an exchange, a miner, whoever) realizes that what thought was the canonical string turned out not to be. When this happens, the transactions in the last part of your chain (that is, the most recent transactions) are rolled back, and the transactions in the newest replacement are executed instead.
Since Ethereum has a short target block time of 15 seconds, this naturally happens quite often. Because blocks take time to filter through the network, it’s easy for different parts of the network to have a different final block (or two, or maybe even three) in normal operation, since miners often find them at roughly the same time. weather. Same time. This is what we could call short-lived fork. In fact, many of the ommers (né tíos) that you see in Ethereum Network Monitor they were once assumed by some nodes as the final block in the canonical chain.
When a reorganization occurs, or in other words, when the network reaches a more global consensus than it had before and a fork is resolved, the nodes that had the now obsolete chain “reorganize” their chain, discarding the recent and no longer canonical blocks. Transactions are rolled back and others are executed to align with the other path of the fork.
Transactions can be mutually exclusive, like checks; if I have 100, the order is very important since both cannot be paid. This means that a reorganization could result in the reversal of one transaction and the execution of another mutually exclusive transaction. As such, if you are going to take an irreversible action on the back end of a transaction that is on the chain, it is very important to be aware of the risks associated with reorganization.
Generally speaking, the chances of a reshuffle happening drop substantially the further you get from the endgame. That is, the probability that a reorganization will occur that alters the last three blocks is much lower than the probability that only the final block will be altered. This is because the consensus algorithm is constantly striving to come to a common agreement on what the string is. As long as there is no consensus (and therefore potential for a shakeup), it is not in a steady state and will sooner or later collapse into a deal. We call the number of blocks affected by the reorganization the depth of the reorganization.
In general, reorganizations happen automatically and safely; however, anyone making real-world decisions based on on-chain transactions must be aware of the reorganizations that occur, and more importantly, must make a judgment call about how deep a transaction should go on-chain. the apparent string. before they decide it’s him final chain and not simply a temporary branch that will eventually be reverted and resolved. The decision of how deep to hold is, in Bitcoin terms, called the number of confirmations.
Our (somewhat large) expectations of the potential depth of the reorganization (which the confirmation numbers may very well inform) stem from the fact that the protocol is immature, that human factors are involved in any corrective action, and that substantial amounts could be in Game. Basically, it’s the Frontier. There are scenarios, especially those involving adversaries (“51% attackers”) that we have devised where we feel a fairly large number is warranted at this early stage.
Ultimately, of course, we can only advise and inform: The risk of how many “confirmations” to expect (or not) as with all operational decisions, rests with you. Welcome to freedom 🙂
