Traditional blockchain systems offer a secure way of tracking the ownership of digital assets as long as the attacker does not control a large portion of the overall computational or mining power. They typically require participants to generate a proof-of-work before proposing a block at a given index of the chain. To choose one block among the candidate blocks at the same index, Nakamoto’s consensus, Ghost , and the original Ethereum’s consensus select, respectively, the longest branch, the heaviest subtree and the branch with the most difficult crypto-puzzles. This allows an attacker who can generate proofs-of-work faster than others to double spend by overwriting any given branch. In this article, we present a double spending attack, called the Balance attack, that simply needs to delay some messages. This result sheds new lights on an important, often implicit, assumption of the blockchain, synchrony , under which the transmission delay of any message should be within a known upper bound. We show that the attack succeeds with high probability on the protocols of the two largest blockchain systems in market capitalization, Bitcoin and Ethereum. To quantify the impact of our attack, we replicated the blockchain network run by 50 financial institutions and achieved double spending in less than 20 minutes. Finally, we demonstrate the success of the attack empirically by modifying the geth software and hijacking BGP in a controlled distributed system whose distribution of mining power is set to the distribution observed on the Ethereum main blockchain.

With the recent advent of blockchains, we have witnessed a plethora of blockchain proposals. These proposals range from using work to using time, storage or stake in order to select blocks to be appended to the chain. As a drawback it makes it difficult for the application developer to choose the right blockchain to support their applications. In particular, the scalability and performance one can obtain from a specific blockchain is typically unknown. The claimed results are often obtained in isolation by the developers of the blockchain themselves. The experimental conditions corresponding to these results are generally missing and the lack of details make these results irreproducible.

Blockchain has found applications to track ownership of digital assets. Yet, several blockchains were shown vulnerable to network attacks. It is thus crucial for companies to adopt secure blockchains before moving them to production. In this paper, we present Red Belly Blockchain (RBBC), the first secure blockchain whose throughput scales to hundreds of geodistributed consensus participants. To this end, we drastically revisited Byzantine Fault Tolerant (BFT) blockchains through three contributions: (i) defining the Set Byzantine Con-sensus problem of agreeing on a superblock of all proposed blocks instead of a single block; (ii) adopting a fair leaderless design to offer censorship-resistance guaranteeing the commit of correctly requested transactions; (iii) introducing sharded verification to limit the number of signature verifications without hampering security. We evaluate RBBC on up to 1000 VMs of 3 different types, spread across 4 continents, and under attacks. Although its performance is affected by attacks, RBBC scales in that its throughput increases to hundreds of consensus nodes and achieves 30k TPS throughput and 3 second latency on 1000 VMs, hence improving by 3× both the latency and the throughput of its closest competitor.

Blockchains have captured the attention of many, resulting in an abundance of new systems available for use. However, selecting an appropriate blockchain for an application is challenging due to the lack of comparative information discussing core metrics such as throughput, latency and scalability. Although a number of efforts have been devoted to performance evaluation, there is limited work dedicated to blockchains that are both efficient, due to avoiding complex Proof-of-Work cryptopuzzles, and secure, because they solve consensus deterministically despite Byzantine failures. In this paper, we evaluate the performance of three blockchains that cope with such malicious behaviors, namely Burrow, Quorum and Red Belly Blockchain. To this end, we modified the Hyperledger Caliper benchmark to solve three main limitations: unnecessary overheads, online cryptographic signatures and centralized clients. Our results identify the maximum send rate that Burrow and Quorum can process, and that Red Belly Blockchain can offer an 8-times higher throughput than the other blockchains.

Most blockchain systems are forkable in that they require participants to agree on a chain out of multiple possible branches of blocks. In this paper, we identify a new form of attack, called the Balance attack, against these forkable blockchain systems. The novelty of this attack consists of delaying network communications between multiple subgroups of nodes with balanced mining power. Our theoretical analysis captures the tradeoff between the network delay and the mining power of the attacker needed to double-spend in the GHOST protocol with high probability. We quantify our analysis in the settings of the Ethereum testnet of the R3 consortium where we show that a single machine needs to delay messages for 20 minutes to double spend while a coalition with a third of the mining power would simply need 4 minutes to double spend with 94% of success. We experiment the attack in our private Ethereum chain before arguing for a non-forkable blockchain design to protect against Balance attacks.

Most popular blockchain solutions rely on proof-of-work to guarantee that participants reach consensus on a unique block per index of the chain. As consensus is impossible in the general case, it seems that these blockchain systems require messages are delivered fast and no participant mines faster than the crowd. To date, no experimental settings have however been proposed to demonstrate this hypothesis. In this paper, we identify conditions under which these blockchain systems fail to ensure consensus and present a reproducible execution on our Ethereum private chain. To this end, we introduce the Blockchain Anomaly, the impossibility for the blockchain to guarantee that a committed transaction is not abortable. This anomaly may translate into dramatic consequences for the user of proof-of-work blockchains. Named after the infamous Paxos anomaly, this anomaly makes dependent transactions, like “Bob sends money to Carole after he received money from Alice” impossible and may lead to double spending. We also explain how the anomaly differs from a 51-percent attack and how one could avoid it by adapting the Ethereum implementation or by exploiting smart contracts.