On Slow and Quick Block Times
On Slow and Rapid Block Times
One of the largest sources of confusion in the question of blockchain security is the precise effect of the block time. If one blockchain has a block time of ten minutes, and the other has an estimated block time of seventeen seconds, then what exactly does that mean? What is the equivalent of six confirmations on the 10-minute blockchain on the 17-second blockchain? Is blockchain security simply a matter of time, is it a matter of blocks, or a combination of both? What security properties do more elaborate schemes have?
Note: this article will not go into depth on the centralization risks associated with swift block times; centralization risks are a major concern, and are the primary reason not to shove block times all the way down to one 2nd despite the benefits, and are discussed at much more length in this previous article; the purpose of this article is to explain why quick block times are desirable at all.
The response in fact depends crucially on the security model that we are using; that is, what are the properties of the attackers that we are assuming exist? Are they rational, byzantine, economically bounded, computationally bounded, able to bribe ordinary users or not? In general, blockchain security analysis uses one of three different security models:
- Normal-case model: there are no attackers. Either everyone is altruistic, or everyone is rational but acts in an uncoordinated way.
- Byzantine fault tolerance model: a certain percentage of all miners are attackers, and the rest are fair altruistic people.
- Economic model: there is an attacker with a budget of $X which the attacker can spend to either purchase their own hardware or bribe other users, who are rational.
Reality is a mix inbetween the three; however, we can glean many insights by examining the three models separately and observing what happens in each one.
The Normal Case
Let us very first begin off by looking at the normal case. Here, there are no attackers, and all miners simply want to cheerfully sing together and get along while they proceed progressively extending the blockchain. Now, the question we want to response is this: suppose that someone sent a transaction, and k seconds have elapsed. Then, this person sends a double-spend transaction attempting to revert their original transaction (eg. if the original transaction sent $50000 to you, the double-spend spends the same $50000 but directs it into another account possessed by the attacker). What is the probability that the original transaction, and not the double-spend, will end up in the final blockchain?
Note that, if all miners are genuinely nice and altruistic, they will not accept any double-spends that come after the original transaction, and so the probability should treatment 100% after a few seconds, regardless of block time. One way to relieve the model is to assume a puny percentage of attackers; if the block time is utterly long, then the probability that a transaction will be finalized can never exceed 1-x , where x is the percentage of attackers, before a block gets created. We will cover this in the next section. Another treatment is to loosen the altruism assumption and instead discuss uncoordinated rationality; in this case, an attacker attempting to double-spend can bribe miners to include their double-spend transaction by placing a higher fee on it (this is essentially Peter Todd’s replace-by-fee). Hence, once the attacker broadcasts their double-spend, it will be accepted in any freshly created block, except for blocks in chains where the original transaction was already included.
We can incorporate this assumption into our question by making it slightly more sophisticated: what is the probability that the original transaction has been placed in a block that will end up as part of the final blockchain? The very first step to getting to that state is getting included in a block in the very first place. The probability that this will take place after k seconds is pretty well established:
Unluckily, getting into one block is not the end of the story. Perhaps, when that block is created, another block is created at the same time (or, more precisely, within network latency); at that point, we can assume as a very first approximation that it is a 50:50 chance which of those two blocks the next block will be built on, and that block will ultimately “win” – or, perhaps, two blocks will be created once again at the same time, and the contest will repeat itself. Even after two blocks have been created, it’s possible that some miner has not yet seen both blocks, and that miner gets fortunate and created three blocks one after the other. The possibilities are likely mathematically intractable, so we will just take the lazy shortcut and simulate them:
The results can be understood mathematically. At seventeen seconds (ie. 100% of the block time), the swifter blockchain gives a probability of
0.56: slightly smaller than the matheatically predicted 1-1/e
= 0.632 because of the possibility of two blocks being created at the same time and one being discarded; at six hundred seconds, the slower blockchain gives a probability of 0.629, only slightly smaller than the predicted 0.632 because with 10-minute blocks the probability of two blocks being created at the same time is very petite. Hence, we can see that quicker blockchains do have a slight disadvantage because of the higher influence of network latency, but if we do a fair comparison (ie. waiting a particular number of seconds), the probability of non-reversion of the original transaction on the swifter blockchain is much greater.
Now, let’s add some attackers into the picture. Suppose that portion X of the network is taken up by attackers, and the remaining 1-X is made up of either altruistic or selfish but uncoordinated (barring selfish mining considerations, up to X it actually does not matter which) miners. The simplest mathematical model to use to approximate this is the weighted random walk. We begin off assuming that a transaction has been confirmed for k blocks, and that the attacker, who is also a miner, now attempts to commence a fork of the blockchain. From there, we represent the situation with a score of k , meaning that the attacker’s blockchain is k blocks behind the original chain, and at every step make the observation that there is a probability of X that the attacker will make the next block, switching the score to k-1 and a probability of 1-X that fair miners mining on the original chain will make the next block, switching the score to k+1 . If we get to k = zero , that means that the original chain and the attacker’s chain have the same length, and so the attacker wins.
Mathematically, we know that the probability of the attacker winning such a game (assuming x as otherwise the attacker can overwhelm the network no matter what the blockchain parameters are) is:
We can combine this with a probability estimate for k (using the Poisson distribution) and get the net probability of the attacker winning after a given number of seconds:
Note that for rapid block times, we do have to make an adjustment because the stale rates are higher, and we do this in the above graph: we set X = 0.25 for the 600s blockchain and X = 0.28 for the 17s blockchain. Hence, the swifter blockchain does permit the probability of non-reversion to reach one much swifter. One other argument that may be raised is that the diminished cost of attacking a blockchain for a brief amount of time over a long amount of time means that attacks against prompt blockchains may happen more frequently; however, this only slightly mitigates swift blockchains’ advantage. For example, if attacks happen 10x more often, then this means that we need to be convenient with, for example, a 99.99% probability of non-reversion, if before we were convenient with a 99.9% probability of non-reversion. However, the probability of non-reversion approaches one exponentially, and so only a petite number of extra confirmations (to be precise, around two to five) on the quicker chain is required to bridge the gap; hence, the 17-second blockchain will likely require ten confirmations (
three minutes) to achieve a similar degree of security under this probabilistic model to six confirmations (
one hour) on the ten-minute blockchain.
Economically Bounded Attackers
We can also treatment the subject of attackers from the other side: the attacker has $X to spend, and can spend it on bribes, near-infinite instantaneous hashpower, or anything else. How high is the requisite X to revert a transaction after k seconds? Essentially, this question is equivalent to “how much economic expenditure does it take to revert the number of blocks that will have been produced on top of a transaction after k seconds”. From an expected-value point of view, the response is elementary (assuming a block prize of one coin per 2nd in both cases):
If we take into account stale rates, the picture actually turns slightly in favor of the longer block time:
But “what is the expected economic security margin after k seconds” (using “expected” here in the formal probability-theoretic sense where it harshly means “average”) is actually not the question that most people are asking. Instead, the problem that concerns ordinary users is arguably one of them wanting to get “enough” security margin, and wanting to get there as quickly as possible. For example, if I am using the blockchain to purchase a $Two coffee, then a security margin of $0.03 (the current bitcoin transaction fee, which an attacker would need to outbid in a replace-by-fee model) is clearly not enough, but a security margin of $Five is clearly enough (ie. very few attacks would happen that spend $Five to steal $Two from you), and a security margin of $50000 is not much better. Now, let us take this stringent binary enough/not-enough model and apply it to a case where the payment is so petite that one block prize on the quicker blockchain is greater than the cost. The probability that we will have “enough” security margin after a given number of seconds is exactly equivalent to a chart that we already eyed earlier:
Now, let us suppose that the desired security margin is worth inbetween four and five times the smaller block prize; here, on the smaller chain we need to compute the probability that after k seconds at least five blocks will have been produced, which we can do via the Poisson distribution:
Now, let us suppose that the desired security margin is worth as much as the larger block prize:
Here, we can see that quick blocks no longer provide an unambiguous benefit; in the brief term they actually hurt your chances of getting more security, however that is compensated by better spectacle in the long term. However, what they do provide is more predictability; rather than a long exponential curve of possible times at which you will get enough security, with quick blocks it is pretty much certain that you will get what you need within seven to fourteen minutes. Now, let us keep enhancing the desired security margin further:
As you can see, as the desired security margin gets very high, it no longer indeed matters that much. However, at those levels, you have to wait a day for the desired security margin to be achieved in any case, and that is a length of time that most blockchain users in practice do not end up waiting; hence, we can conclude that either (i) the economic model of security is not the one that is superior, at least at the margin, or (ii) most transactions are petite to medium sized, and so actually do benefit from the greater predictability of puny block times.
We should also mention the possibility of reverts due to unforeseen exigencies; for example, a blockchain fork. However, in these cases too, the “six confirmations” used by most sites is not enough, and waiting a day is required in order to be truly safe.
The conclusion of all this is elementary: quicker block times are good because they provide more granularity of information. In the BFT security models, this granularity ensures that the system can more quickly converge on the “correct” fork over an incorrect fork, and in an economic security model this means that the system can more quickly give notification to users of when an acceptable security margin has been reached.
Of course, quicker block times do have their costs; stale rates are perhaps the largest, and it is of course necessary to balance the two – a balance which will require ongoing research, and perhaps even novel approaches to solving centralization problems arising from networking lag. Some developers may have the opinion that the user convenience provided by quicker block times is not worth the risks to centralization, and the point at which this becomes a problem differs for different people, and can be shoved closer toward zero by introducing novel mechanisms. What I am hoping to disprove here is simply the claim, repeated by some, that rapid block times provide no benefit whatsoever because if each block is fifty times swifter then each block is fifty times less secure.
Appendix: Eyal and Sirer’s Bitcoin NG
A latest interesting proposal introduced at the Scaling Bitcoin conference in Montreal is the idea of splitting blocks into two types: (i) infrequent (eg. Ten minute heartbeat) “key blocks” which select the “leader” that creates the next blocks that contain transactions, and (ii) frequent (eg. Ten 2nd heartbeat) “microblocks” which contain transactions:
The theory is that we can get very quick blocks without the centralization risks by essentially electing a dictator only once every (on average) ten minutes, for those ten minutes, and permitting the dictator to produce blocks very quickly. A dictator “should” produce blocks once every ten seconds, and in the case that the dictator attempts to double-spend their own blocks and create a longer fresh set of microblocks, a Slasher-style algorithm is used where the dictator can be disciplined if they get caught:
This is certainly an improvement over plain old ten-minute blocks. However, it is not almost as effective as simply having regular blocks come once every ten seconds. The reasoning is plain. Under the economically-bounded attacker model, it actually does suggest the same probabilities of assurances as the ten-second model. Under the BFT model, however, it fails: if an attacker has 10% hashpower then the probability that a transaction will be final cannot exceed 90% until at least two key blocks are created. In reality, which can be modeled as a hybrid inbetween the economic and BFT scripts, we can say that even however 10-second microblocks and 10-second real blocks have the same security margin, in the 10-second microblock case “collusion” is lighter as within the 10-minute margin only one party needs to participate in the attack. One possible improvement to the algorithm may be to have microblock creators rotate during each inter-key-block phase, taking from the creators of the last one hundred key blocks, but taking this treatment to its logical conclusion will likely lead to reinventing full-on Slasher-style proof of stake, albeit with a proof of work issuance model fastened.
However, the general treatment of segregating leader election and transaction processing does have one major benefit: it reduces centralization risks due to slow block propagation (as key block propagation time does not depend on the size of the content-carrying block), and thus substantially increases the maximum safe transaction throughput (even beyond the margin provided through Ethereum-esque uncle mechanisms), and for this reason further research on such schemes should certainly be done.