The following outlines our existing and anticipated outlooks regarding the maximum probable depth of chain re-organisation. We would not categorize transactions within this depth as having an extraordinarily high likelihood of being permanent. These expectations are solely our own and do not serve as any form of assurance. They are based on theoretical evaluations, ongoing empirical research, human elements in contingency strategies, and the historical experiences of our security personnel. As with everything in the peer-to-peer domain, the responsibility lies entirely with the individual operator.
In a similar manner to many others in the field, we will be observing the chain for any indications of protocol-level complications. Should we have any cause to suspect a protocol level issue we will revise these expectations accordingly; updates will be communicated through the forums and the official blog. All interested parties in our forecasts and recommendations would do well to stay informed via the blog.
ROADMAP
Until 2015/08/08 18:00:00 CEST: 6000
From 2015/08/08 18:00:00 CEST, 3000 (approximately 12 hours)
(1 day)
From 2015/08/09 18:00:00 CEST, 1500 (approximately 6 hours)
(3 days)
From 2015/08/12 18:00:00 CEST, 750 (approximately 3 hours)
(3 days)
From 2015/08/15 18:00:00 CEST, 375 (approximately 90 minutes)
(Rest of Frontier)
ADDENDUM 2015/08/08: You might find yourself slightly confused about the term “chain reorganisation depth.” Chain reorganisations occur when a node within the Ethereum network (which may belong to you, me, an exchange, a miner, or anyone else) realizes that what it believed to be the canonical chain was not actually so. When this transpires, the transactions in the latter segment of its chain (i.e., the latest transactions) are reversed, and instead, the transactions from the newer chain are executed.
With Ethereum’s brief target block time of 15 seconds, this phenomenon occurs quite frequently. Due to the time required for blocks to circulate throughout the network, it is commonplace for different regions of the network to have varying final blocks (or two, or even three) during regular operation since miners often produce them concurrently. This is what we might refer to as temporary forking. In fact, many of the ommers (formerly uncles) that you observe in Ethereum’s network monitor were once thought by some nodes to be the final block in the canonical chain.
When a re-organisation takes place, or in other terms, when the network achieves a more comprehensive consensus than it held previously and a fork is resolved, the nodes that held the now obsolete chain “reorganise” their chain, discarding the recent and no longer canonical blocks. Transactions are reversed and others are executed to align with the other path of the fork.
Transactions can be mutually exclusive, akin to cheques; if I possess 100, the sequence is crucial as they cannot both be honored. This indicates that a reorganisation could lead to the cancellation of one transaction and the execution of another, mutually exclusive transaction. Consequently, if you’re planning to undertake an irreversible action based on a transaction existing in the chain, it’s vital to understand the risks associated with reorganisation.
In general terms, the probability of a reorganisation occurring significantly decreases the further you move away from the end. That is, the likelihood of a reorganisation affecting the final three blocks is considerably lower than the likelihood of one that alters only the final block. This is because the consensus algorithm consistently seeks to achieve a common agreement on what the chain represents. As long as there isn’t a consensus (and therefore the potential for a reorganisation), it remains in an unstable state and will eventually converge into agreement. We refer to the quantity of blocks impacted by the reorganisation as the depth of the reorganisation.
Typically, reorganisations occur automatically and safely; however, anyone making practical decisions based on transactions within the chain must be conscious of reorganisations and, crucially, must determine how far a transaction needs to be entrenched in the apparent chain before they conclude it is the final chain and not just a transient fork that will be iteratively reverted. The determining factor for how deeply to wait is, in Bitcoin terminology, referred to as the number of confirmations.
Our (somewhat extensive) expectations regarding possible reorganisation depth (which may likely influence confirmation numbers) arise from the fact that the protocol is still evolving, that human factors play a role in any corrective measures, and that considerable assets could be at stake. Essentially, it’s the Frontier. There are scenarios, particularly those involving adversaries (“51%” attackers), that we have envisioned where we believe relatively high numbers are indeed justified at this early stage.
In conclusion, we can only provide guidance and information: The decision on how many “confirmations” to await (or not) along with all operational choices, ultimately lies with you. Welcome to freedom 🙂
