One of the most significant sources of misunderstanding regarding blockchain security pertains to the exact impact of block time. If one blockchain has a block interval of 10 minutes, while another has an approximate block duration of 17 seconds, what precisely does that signify? What is the equivalent of six confirmations on the 10-minute blockchain in the context of the 17-second blockchain? Is blockchain security merely a function of time, solely a matter of blocks, or a synthesis of both elements? What security characteristics do more intricate frameworks possess?
Note: this piece will not delve deeply into the risks of centralization tied to rapid block times; these risks are a noteworthy issue and are the primary rationale against reducing block times to just 1 second, despite the associated advantages, and are elaborated upon extensively in this earlier article; the goal of this article is to clarify why fast block times are advantageous at all.
The response truly hinges on the security paradigm we adopt; that is, what attributes of the adversaries are we presuming to exist? Are they rational, byzantine, economically constrained, computationally limited, or capable of bribing ordinary users? Generally, blockchain security evaluations utilize one of three distinct security frameworks:
- Normal-case model: there are no adversaries. Either everyone is benevolent, or everyone is logical yet operates in an uncoordinated manner.
- Byzantine fault tolerance model: a certain proportion of the miners are adversaries, while the majority consist of honest, altruistic individuals.
- Economic model: there exists an attacker with a financial limit of $X, which the attacker can allocate to either acquire their own hardware or to bribe rational users.
Reality is a blend of the three; nonetheless, we can derive numerous insights by analyzing the three models independently and observing the outcomes in each scenario.
The Normal Case
Let’s begin by examining the normal case. In this scenario, there are no adversaries, and all miners are simply eager to collaborate harmoniously as they progressively extend the blockchain. Now, the inquiry we seek to address is this: suppose an individual initiates a transaction, and k seconds pass. Subsequently, this individual issues a double-spend transaction attempting to nullify their initial transaction (for example, if the original transaction transferred $50000 to you, the double-spend reallocates the same $50000 to a different account held by the adversary). What is the likelihood that the original transaction, rather than the double-spend, will be included in the final blockchain?
It’s important to note that if all miners are genuinely kind and altruistic, they will disregard any double-spends that occur subsequent to the original transaction. Thus, the likelihood should approach 100% after a few seconds, irrespective of the block time. One way to adjust the model is to presume a minor fraction of adversaries; if the block time is exceedingly prolonged, then the probability that a transaction gets finalized cannot surpass 1-x, where x represents the fraction of adversaries, before a block is generated. We will explore this in the next section. Another angle is to loosen the altruism assumption and instead address uncoordinated rational behavior; in this context, an adversary seeking to double-spend may incentivize miners to incorporate their double-spend transaction by offering a higher fee (essentially mirroring Peter Todd’s replace-by-fee). Consequently, once the adversary disseminates their double-spend, it will be accepted in any newly constructed block, with the exception of blocks in chains where the original transaction has already been included.
We can integrate this assumption into our inquiry by rendering it a bit more complex: what is the probability that the original transaction has been included in a block that will ultimately compose the final blockchain? The initial step to achieving that condition is being included in a block in the first instance. The probability that this occurs afterk seconds is quite well-defined:
Sadly, achieving placement in a single block does not conclude the matter. Perhaps, when that block is generated, another block is simultaneously created (or, more precisely, created within the parameters of network latency); at that juncture, we can assume, for the sake of rough estimation, that it’s a 50:50 chance as to which of the two blocks the subsequent block will be built upon, and that block will ultimately prevail – or, perhaps, a second block will emerge simultaneously, elongating the contest. Even after two blocks are produced, it’s feasible that a miner has not yet recognized both blocks, leading to that miner fortuitously producing three blocks in succession. The mathematical scenarios may be intractable, so we will adopt a simpler approach and simulate them:
The findings can be interpreted mathematically. At 17 seconds (i.e., 100% of the block interval), the quicker blockchain provides a probability of ~0.56: slightly below the mathematically anticipated 1-1/e ~= 0.632 due to the chance of simultaneous block creation and subsequent one being discarded; at 600 seconds, the slower blockchain yields a probability of 0.629, only marginally less than the expected 0.632 because with 10-minute blocks, the likelihood of two blocks being produced concurrently is quite low. Therefore, it is evident that faster blockchains possess a slight disadvantage due to the greater effect of network latency, but if we conduct a fair assessment (i.e., waiting a specific duration), the probability of the original transaction remaining unaltered on the faster blockchain is considerably larger.
Adversaries
Now, let’s introduce some adversaries into the equation. Assume that a segment X of the network is comprised of adversaries, while the rest 1-X consists of either altruistic or self-serving yet uncoordinated (barring selfish mining implications, up to X it actually does not matter which) miners. The simplest mathematical model to approximate this situation is the weighted random walk. We commence by assuming that a transaction has been confirmed for k blocks, and that the attacker,who is also a miner, now attempts to initiate a fork of the blockchain. From this point, we depict the scenario with a tally of k, signifying that the assailant’s blockchain is k blocks trailing the original chain, and at every interval we notice that there is a likelihood of X that the assailant will create the next block, adjusting the score to k-1 and a probability of 1-X that honest miners operating on the original chain will produce the subsequent block, altering the score to k+1. If we arrive at k = 0, it indicates that the original chain and the attacker’s chain are of equal length, thereby resulting in a victory for the attacker.
From a mathematical perspective, we understand that the chance of the attacker succeeding in such a scenario (assuming x as under other circumstances the attacker could overpower the network regardless of the blockchain specifics) is:
We can merge this with a probability assessment for k (utilizing the Poisson distribution) and derive the overall probability of the attacker achieving victory after a set amount of seconds:
It is important to note that for rapid block intervals, we need to make an adjustment since the stale rates are elevated, and we accomplish this in the graph above: we establish X = 0.25 for the 600s blockchain and X = 0.28 for the 17s blockchain. Consequently, the quicker blockchain does enable the chance of non-reversion to reach 1 at a much quicker pace. Another argument that could be presented is that the diminished cost of assaulting a blockchain for a brief time versus an extended duration indicates that attacks on fast blockchains may occur more frequently; however, this only marginally lessens the advantage of rapid blockchains. For instance, if attacks occur 10x more frequently, then we should be comfortable with, say, a 99.99% chance of non-reversion, if prior we were satisfied with a 99.9% probability of non-reversion. Nevertheless, the likelihood of non-reversion approaches 1 at an exponential rate, and thus only a minimal number of additional confirmations (specifically, around two to five) on the swifter chain is needed to close the divide; therefore, the 17-second blockchain will probably necessitate ten confirmations (~three minutes) to attain a similar level of security within this probability model as six confirmations (~one hour) on the ten-minute blockchain.
Economically Limited Attackers
We can also consider the topic of attackers from an alternative viewpoint: the attacker holds $X to invest, which can be allocated to bribes, nearly unlimited instantaneous hashpower, or any other means. What is the necessary X to reverse a transaction after k seconds? Essentially, this inquiry is equivalent to determining “how much economic investment is required to reverse the number of blocks that will have been generated on top of a transaction after k seconds.” From an expected-value standpoint, the solution is straightforward (assuming a block reward of 1 coin per second in both situations):
When we factor in stale rates, the scenario actually shifts slightly in favor of the longer block time:
However, “what is the anticipated economic security margin after k seconds?” (using “anticipated” in the formal probability-theoretic sense roughly meaning “average”) is not the query that most individuals are posing. Instead, most users are likely interested in securing “sufficient” security margin as swiftly as possible. For instance, if I am utilizing the blockchain to buy a $2 coffee, a security margin of $0.03 (the current bitcoin transaction fee, which an assailant would need to outbid in a replace-by-fee model) is evidently inadequate; on the other hand, a security margin of $5 is definitely sufficient (i.e., very few attacks would occur that expend $5 to steal $2 from you), and a security margin of $50000 doesn’t significantly improve matters. Now, let us adopt this strict binary sufficient/insufficient model and apply it to a situation where the payment is so minimal that one block reward on the rapid blockchain surpasses the cost. The likelihood that we will attain “enough” security margin after a certain number of seconds is precisely equivalent to a chart we previously observed:
Now, let us suppose that the targeted security margin is valued at four to five times the smaller block reward; here, on the smaller chain we must calculate the probability that after k seconds at least five blocks will have been generated, which we can accomplish via the Poisson distribution:
Now, let us assume that the sought security margin is equivalent to the larger block reward:
Here, we can observe that rapid blocks do not offer an indisputable advantage; in the short run, they actually diminish your prospects of acquiring additional security, although this is offset by enhanced performance over the long haul. However, what they do provide is greater predictability; as opposed to an extended exponential curve of possible durations during which you will obtain sufficient security, with fast blocks it is almost certain you will receive what is necessary within 7 to 14 minutes. Now, let us continue to raise the desired security margin further:
As you can see, as the requested security margin becomes exceedingly high, it becomes less significant. Nevertheless, at those levels, you will have to wait a full day for the desired security margin to be accomplished in any situation, and that duration is a length of time that most blockchain users are not willing to endure.practice does not result in delays; therefore, we may infer that either (i) the security economic framework is not the prevailing one, at least on the margins, or (ii) most exchanges are minor to moderate in scale, thus indeed profiting from the enhanced predictability afforded by shorter block intervals.
We must also acknowledge the chance of reversals triggered by unexpected circumstances; for instance, a fork in the blockchain. Nevertheless, even in such instances, the “six confirmations” typically indicated by most platforms fall short, necessitating a day’s wait for true security.
The essence of all this is straightforward: quicker block intervals are advantageous as they furnish greater detail in information. Within the BFT security frameworks, this granularity allows the system to more swiftly align with the “correct” fork over an erroneous one, and in an economic security paradigm, this allows the system to rapidly inform users when an acceptable security threshold has been achieved.
Undoubtedly, quicker block intervals come with their drawbacks; stale rates are perhaps the most significant, necessitating a careful balance between the two – a balance that will require continuous investigation and possibly even innovative strategies to tackle centralization challenges arising from network delays. Some developers might believe that the user ease offered by faster block intervals isn’t worth the risks associated with centralization, and the threshold at which this becomes a concern varies among individuals and can be pushed closer to zero by implementing innovative mechanisms. Here, I aim to refute the assertion, reiterated by some, that rapid block intervals yield no advantage at all, arguing that if each block is fifty times quicker, then each block is fifty times less secure.
Appendix: Eyal and Sirer’s Bitcoin NG
An intriguing recent proposition made at the Scaling Bitcoin conference in Montreal involves the concept of dividing blocks into two categories: (i) infrequent (e.g., 10-minute heartbeat) “key blocks” responsible for selecting the “leader” that generates the subsequent blocks containing transactions, and (ii) frequent (e.g., 10-second heartbeat) “microblocks” that include transactions:
The proposition suggests that we can obtain extremely rapid blocks without the risks of centralization by essentially electing a singular authority only once approximately every ten minutes, during which that authority can produce blocks at a high rate. This authority “should” produce blocks every ten seconds, and if the authority tries to double-spend their own blocks and form a longer set of new microblocks, a Slasher-style algorithm comes into play, allowing for punitive measures against the authority if an offense occurs:
This strategy marks a clear advancement compared to traditional ten-minute blocks. However, it does not nearly match the efficiency of simply having standard blocks generated every ten seconds. The rationale is straightforward. In the model where attackers have economic constraints, it offers the same probability of assurances as the ten-second framework. However, under the BFT model, it falls short: if an attacker possesses 10% of the hashpower, the likelihood that a transaction will reach finality cannot surpass 90% until at least two key blocks are issued. In actual scenarios, which can be viewed as a hybrid of economic and BFT situations, we can conclude that although ten-second microblocks and real blocks share the same security margin, in the case of ten-second microblocks, “collusion” is more feasible since within the ten-minute margin, only a single entity needs to engage in the assault. One potential enhancement to the algorithm could involve having microblock creators alternate during each inter-key-block phase, sourcing from the creators of the previous 100 key blocks, but pursuing this concept to its logical conclusion may result in a complete reinvention of the Slasher-style proof of stake system, albeit incorporating a proof of work issuance model.
Nonetheless, the overall strategy of separating leader election from transaction processing offers a significant advantage: it mitigates centralization risks stemming from sluggish block dissemination (since the propagation time of key blocks does not rely on the size of the content-bearing block), consequently increasing the maximum safe transaction throughput (even surpassing the margins afforded by Ethereum-like uncle mechanisms), and thus, further investigation into such frameworks should undoubtedly be pursued.