Ky obits 2018
25 comments
Bitcoin ethereum price graph
Announcing World Trade Francs: The Official Ethereum Stablecoin 01st April, Ethereum scalability research and development subsidy programs 02nd January, 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 10 minutes, and the other has an estimated block time of 17 seconds, then what exactly does that mean? What is the equivalent of six confirmations on the minute blockchain on the 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 complex schemes have?
The answer 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:. Reality is a mix between the three; however, we can glean many insights by examining the three models separately and seeing what happens in each one.
Let us first start off by looking at the normal case. Here, there are no attackers, and all miners simply want to happily sing together and get along while they continue progressively extending the blockchain. Now, the question we want to answer is this: Then, this person sends a double-spend transaction trying to revert their original transaction eg.
What is the probability that the original transaction, and not the double-spend, will end up in the final blockchain? One way to relax the model is to assume a small percentage of attackers; if the block time is extremely 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. Hence, once the attacker broadcasts their double-spend, it will be accepted in any newly 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 complex: The first step to getting to that state is getting included in a block in the first place.
The probability that this will take place after k seconds is pretty well established:. Unfortunately, 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 first approximation that it is a The possibilities are likely mathematically intractable, so we will just take the lazy shortcut and simulate them:.
The results can be understood mathematically. At 17 seconds ie. Hence, we can see that faster blockchains do have a slight disadvantage because of the higher influence of network latency, but if we do a fair comparison ie. 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 start off assuming that a transaction has been confirmed for k blocks, and that the attacker, who is also a miner, now tries to start a fork of the blockchain.
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 fast block times, we do have to make an adjustment because the stale rates are higher, and we do this in the above graph: Hence, the faster blockchain does allow the probability of non-reversion to reach 1 much faster.
One other argument that may be raised is that the reduced cost of attacking a blockchain for a short amount of time over a long amount of time means that attacks against fast blockchains may happen more frequently; however, this only slightly mitigates fast blockchains' advantage. For example, if attacks happen 10x more often, then this means that we need to be comfortable with, for example, a We can also approach the subject of attackers from the other side: 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 answer is simple assuming a block reward of 1 coin per second 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 roughly 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. The probability that we will have "enough" security margin after a given number of seconds is exactly equivalent to a chart that we already saw earlier:.
Now, let us suppose that the desired security margin is worth between four and five times the smaller block reward; 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 reward:. Here, we can see that fast blocks no longer provide an unambiguous benefit; in the short term they actually hurt your chances of getting more security, though that is compensated by better performance 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 fast blocks it is pretty much certain that you will get what you need within 7 to 14 minutes.
Now, let us keep increasing the desired security margin further:. As you can see, as the desired security margin gets very high, it no longer really 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 dominant, at least at the margin, or ii most transactions are small to medium sized, and so actually do benefit from the greater predictability of small 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 simple: 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, faster 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 faster 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 pushed closer toward zero by introducing novel mechanisms. What I am hoping to disprove here is simply the claim, repeated by some, that fast block times provide no benefit whatsoever because if each block is fifty times faster then each block is fifty times less secure.
A recent interesting proposal presented at the Scaling Bitcoin conference in Montreal is the idea of splitting blocks into two types: The theory is that we can get very fast blocks without the centralization risks by essentially electing a dictator only once every on average ten minutes, for those ten minutes, and allowing 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 new set of microblocks, a Slasher -style algorithm is used where the dictator can be punished if they get caught:.
This is certainly an improvement over plain old ten-minute blocks. However, it is not nearly as effective as simply having regular blocks come once every ten seconds.
The reasoning is simple. Under the economically-bounded attacker model, it actually does offer the same probabilities of assurances as the ten-second model. Under the BFT model, however, it fails: In reality, which can be modeled as a hybrid between the economic and BFT scenarios, we can say that even though second microblocks and second real blocks have the same security margin, in the second microblock case "collusion" is easier as within the 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 key blocks, but taking this approach to its logical conclusion will likely lead to reinventing full-on Slasher-style proof of stake, albeit with a proof of work issuance model attached. However, the general approach of segregating leader election and transaction processing does have one major benefit: Was it indirectly targeted at the Bitcoin situation?
And how much of this applies to Ethereum in particular? I agree with that Bitcoin must do something with the block time. This is a big opportunity for altcoins. Bitcoin is starting to become something like our governments: How the introduction of PoS will influence the security and the block time at Ethereum? I like the concept of PoS as it involve more nodes to the blockchain.
With PoW, no one runs a node without dedicated hardware. IMO, it is a waste of resource if the PoS is effective enough. I would like to see all your graphs with rescaled x-axis: If the goal is a private enough world wide fast and secure electronic currency perhaps there is a much simpler way to do it. What am I missing? Banks trust each other available information, regulation, insurance, etc. They knows that there is a very little chance for cheating. If we want to be safe we must assume that there will be bad actors.
The blockchain solves a big part of this problem. If there would be a simpler way to achieve the same result, we would already use it. Any news about this: You may use these HTML tags and attributes: The Official Ethereum Stablecoin 01st April, Ethereum scalability research and development subsidy programs 02nd January, Author William Mougayar Posted at 3: Author Zer0CT Posted at 5: Thanks for the explanation!
Author altsheets Posted at 2: Looking forward to seeing the differences. Any news about that? Author Samantha Atkins Posted at Author Zer0CT Posted at 4: