Transaction security in the blockchain is often interconnected with the problem of the block-finality.
A transaction recipient has to be sure that the transaction won’t be reversed, and the sender is unable to perform a double spend. In the case of fiat currencies, the finality is bounded by law, by making the currency a legal tender. In the designs based on PoW (proof of work), the block is never final.
Satoshi Nakamoto has shown that the probability of a spontaneous short fork of length N>6 blocks is negligible, so that one can claim that Bitcoin has a probabilistic finality. However, researchers have shown that block-finality is actually economic: a transaction is final whenever the cost required for its reversion is greater than the potential profit from the double spend attack.
Sometimes, blockchain experts claim that some blockchains based on PoS (proof of stake) don’t have the problem of block-finality, since blocks in them are “instantly final”. This claim is false. Forking is an inevitable problem of any blockchain, no matter what consensus rules are chosen.
A good example is the recent story with the Steem blockchain.The network community got split into two mutually hostile camps. Despite the consensus rules, the blockchain was forked. Each group maintained its own fork and blocked balances in the wallets of their opponents. Apparently, the fork which followed the rules of the original protocol had lost the duel, since its market cap became less than the market cap of the fork. Thus we can conclude that finality in PoS blockchain has an economic underpinning, similar to that of a PoW blockchain. Developers of Ethereum 2.0 share the same vision.
However, they claim that the slashing mechanism of the Casper protocol not only prevents nothing-at-stake attacks, but makes double-spend attacks more expensive. Nevertheless, complex protocol logic opens the door to more sophisticated double-spend attacks.
Simplified double-spend attack
The simplest form of the double-spend attack on the PoS blockchain for the malicious attacker is to lock into stakes twice as many funds as honest participants have. If the malicious actor B succeeds in doing this in a network similar to Ethereum 2.0, then it’s likely that within that particular shard committee, he will obtain twice as many stakes as have honest validators. So the malicious actor controls the ? of the votes in the shard committee. In Ethereum 2.0 this amount of votes is sufficient to “finalize” the block. Assume that he wants to double spend some amount of coins in that shard. He announces a transaction in which B sends coins to the user A. This transaction gets into the block signed by honest validators. B adds a part of his votes so that the block gets elected.
In the consensus based on PoS, the ? of the votes in the committee has to be affirmative in order to “finalize” the block. According to our assumption, half of attackers’ votes is ? of the votes in the committee. Together with honest validators it adds up to ?. That is a threshold required to “finalize” the block. So A learns that the transaction gets “finalized” and releases commodities to B. Then, B reverts the transaction by creating a fork and validating it using all his votes in the committee. According to the Casper protocol half of B’s stake in the shard that was used in both forks should be slashed. Designers of the Casper protocol claim that this is the cost of the attack.
In this simplified scenario the attacker loses half of his stake in the shard. Also, this amount equals the stake of honest validators in this shard. Assume there are N shards in the network. Then the attacker loses 1/2N of his aggregate stake or 1/N of the total stake of honest stakeholders. So, the more shards in the network the cheaper the double-spend attack for the attacker. If one considers this value as a measure of the network security, then the security drops by the factor of N. Notice that this is not the property that is asserted to be the possible solution of the Scalability Trilemma. However, developers of Ethereum 2.0 claim that the cost of this attack is so big that the factor 1/N doesn’t affect it.
Sophisticated double-spend attacks
The attack scenario described in the previous section is not unique. The malicious actor could perform even more sophisticated double-spend attacks. Authors of the Casper protocol claim that a part of the attackers stake always gets slashed. Is that true? The answer is “no”. Everything that occurs in the network is recorded into the blockchain. If the blockchain doesn’t contain any record of malicious actions, then how might one accuse somebody of engaging in malicious behavior?
In the next version of the double attack, the malicious actor prevents slashing of his stake. In order to slash the stake, honest nodes should include the respective record on the specific chain that is used to coordinate stakeholders. It is called the Beacon chain. If the Beacon chain follows the permissionless PoS consensus, then ? of the validator’s votes are required in order to include the record into the blockchain. Thus as long as the malicious actor controls ? of the Beacon chain committee, he can avoid slashing. If he prevents slashing till the time his stake gets unlocked, then his attack is almost free. The question is: how long should he keep his stake locked?
In the current specification of Ethereum 2.0, the stake is locked for half a year. However, the attacker could launch his attack at the very end of the stake lock interval. A possible fix is setting a time interval before the release, during which time the stake can’t be elected into the shard committee, and then get used in a double-spend attack. However, this countermeasure reduces the cost effectiveness of staking. During this time interval, all affected stakeholders should get compensation for their locked funds. Yet these funds are “deactivated,” and therefore do not participate in block validation. Moreover, the malicious actor can use this fix for his benefit, since he can carefully choose a time for his attack. He can lock his stakes simultaneusly, so that his stakes get “activated” and “deactivated” simultaneously. In contrast, honest stakeholders often have a part of their stake deactivated, and therefore excluded from the validation process. So getting ? of votes in committees becomes even easier.
One may argue that in this version of the attack, honest nodes can observe that ? of the stake at the Beacon chain committee is used to fulfil the attack. They could take actions not listed in the Casper protocol to punish the attacker. A first option would be trying to lock more funds into the stake. The second is to start a new fork. The first option is not a viable case, since the attacker can conduct “censorship.”
He can use his votes in the Beacon chain committee to prevent allocation of new stakes. Thus, he can hold ? of the votes in shard committees for as long as he wants. The second option is viable, however, it is an abuse of the network protocol accepted by participants at the very beginning. If an independent observer attempts to figure out what is going on in the network, based on the data recorded in the blockchain, then he will fail to distinguish malicious actors from honest validators.
Before we put an end to this discussion, let’s consider a modified version of the last attack. The new version is a combination of a long-range attack, and of a nothing-at-stake attack. Once again, the malicious actor uses a part of his stake to fork a shard chain. However, in this case, he doesn’t disclose a new chain to honest nodes. Then he waits until his compromised stake gets unlocked. Now he sells his compromised stake to the reckless participants, halts the honest shard chain using his votes in the committee, and then discloses his fork to other shard participants. According to the protocol, the chain maintained by honest validators should be abandoned. So the modified version of the attack is successful. Notice that the stake used to fork the chain is sold. Thus, the malicious actor has avoided slashing once again. Moreover, in this version of the attack, his stake on the Beacon chain was not compromised.
One may suggest a fix to the modified version of the attack, based on using checkpoints. According to this fix, the chain contains checkpoint blocks that “can’t be reverted.” However, this fix is controversial, since the concept of “checkpoint” doesn’t work in the setting of blockchain. As we know, blocks in the blockchain are never completely finalized. Forking is the natural property of the blockchain, and any fork will have its own “completely finalized checkpoints.” Therefore, the usage of the concept of a “checkpoint” is often confusing and misleading. If the node has to rely on the checkpoint, then it has to rely on “checkpoint providers.” It requires introducing an element of trust into an allegedly trustless network.
Our conclusion is that the attacker who allocated a significant amount of power in the form of stakes can launch devastating attacks in the network, while avoiding slashing mechanics. This form of attack is very similar to a 51% attack that may be carried out in the blockchain based on PoW.
Vinod Manoharan is a technology entrepreneur and the founder and CEO of Jax Multiversal Holdings, holdings company whose portfolio includes online gaming companies, payment gateways and Blockchain technology companies. Manoharan is also the founder of JAX.Network, a tech startup in Ukraine, focused on Blockchain technology and more specifically, solving the infamous Blockchain Scalability Trilemma.
Written in collaboration with Iurii Shyshatskyi, chief scientific officer at JAX.Network.
Follow Us on Twitter Facebook Telegram
Featured Image: Shutterstock/Lopyryev Artem/Kuklos