The following shows current and planned expectations regarding the maximum possible chain reorganization depth. We do not consider transactions within this depth very likely to be permanent. This is just our own expectations There is no warranty of any kind.. It is derived from theoretical considerations, ongoing empirical data, the human element of emergency planning, and past experience of the security team. As with everything in the P2P space, the risk lies entirely with the individual operator.
In much the same way as many in the industry, we will be monitoring the chain for signs of protocol-level issues. If there is reason to suspect that there is a protocol level problem We will update these expectations thus; Updates are posted on the forum and official blog. Anyone interested in our expectations and recommendations is encouraged to keep our blog up to date.
roadmap
Until 2015/08/08 18:00:00 CEST: 6000
From 2015/08/08 18:00:00 CEST, 3000 (about 12 hours)
(1 day)
From 2015/08/09 18:00:00 CEST, 1500 (about 6 hours)
(3 days)
From 2015/08/12 18:00:00 CEST, 750 (about 3 hours)
(3 days)
From 2015/08/15 18:00:00 CEST, 375 (about 90 minutes)
(Rest of Frontier)
Addendum 2015/08/08: You may be a little perplexed as to what “chain reorganization depth” means. A chain reorganization occurs when a node on the Ethereum network (which could belong to anyone, you, me, an exchange, a miner, etc.) realizes what it is. thought It turns out that standard chains don’t. When this happens, the transaction later in the chain (i.e. the most recent transaction) is reverted and a new replacement transaction is executed.
Since Ethereum has a short target block time of 15 seconds, this naturally happens often in practice. Because it takes time for blocks to filter through the network, and because miners often find blocks at roughly the same time, under normal operation different parts of the network will have different final blocks (or two, or even three). It’s easy. Same time. This is what we can call temporary fork. In fact, many of the ommers (né uncles) you see are Ethereum network monitor At one time, it was considered by some nodes to be the last block in the canonical chain.
A reorganization occurs, or put another way, when a network reaches a more global consensus than it previously had. fork Once the problem is resolved, the node with the now outdated chain “reconstructs” the chain, discarding the latest and no longer standard blocks. The transaction is reverted and other transactions are executed along the fork’s other paths.
Transactions can be mutually exclusive, like checks. if i have it 100, your order is very important because you cannot pay at the same time. This means that a reconfiguration may cause one transaction to be reverted and another, mutually exclusive transaction to be executed. Therefore, if you want to perform irreversible actions based on transactions on the chain, it is very important to know the risks associated with reconfiguration.
Roughly speaking, the likelihood of a reconfiguration occurring decreases significantly the farther you get from the final result. This means that a reconfiguration that changes the last three blocks is much less likely to occur than if only the last block were changed. This is because the consensus algorithm is constantly trying to come to a common agreement on what the chain is. Unless there is agreement (and therefore the possibility of reorganization), it is not a stable state and sooner or later the agreement will break down. Number of blocks affected by reorganization depth of reorganization.
Typically, reorganization occurs automatically and securely, but anyone making actual decisions based on transactions on the chain must be aware that a reorganization is occurring and, most importantly, must make judgment decisions about how deep the transaction should go into the apparent chain. before they decide critical The chain will eventually revert and be resolved, rather than a temporary fork. The decision on how long to wait is called ‘waiting’ in Bitcoin terminology. number of confirmations.
Our (rather large) expectations about the possible depth of reconstruction (which may very well inform the confirmation figures) stem from the fact that the protocols are immature, the human element is involved in all corrective actions, and significant sums of money may be at risk. It’s basically Frontier. In particular, there is a scenario involving an adversary of our own design (a “51%” attacker) where we feel that a fairly high number is practically guaranteed at this early stage.
Of course, ultimately we can only offer the following advice and information: As with all operational decisions, how much “confirmation” you wait (or don’t wait) is at your own risk. Welcome to freedom 🙂