redbellyblockchain

The Red Belly Experiments

In this paper, we present the largest experiment of a blockchain system to date. To achieve scalability across 1000 servers in more than 10 countries located on four different continents, we drastically revisited Byzantine fault tolerant blockchains and verification of signatures. The resulting blockchain, called the Red Belly Blockchain (RBBC), commits more than a hundred thousand transactions issued by permissionless nodes, that are grouped into blocks within few seconds through a partially synchronous consensus run by permissioned nodes. It prevents double spending by guaranteeing that a unique block is decided at any given index of the chain in a deterministic way. 

redbellyblockchain

The Balance Attack

We present the Balance Attack that can lead an adversary to double spend coins in proof-of-work blockchains. The Balance Attack bridges the gap between attacks that require to partition the network and attacks that require high mining power as it shows that one needs less mining power if it can delay network messages longer. We show that the attack succeeds with high probability even when the adversary has a less than half of the mining power. We also analyze theoretically the probability of success of the attack depending on the (i) difficulty of the crypto-puzzle that the proof-of-work solves, (ii) the network delay that the attacker introduces and (iii) the mining power of the attacker. 

ComChain: Community Blockchains

As an alternative to the energy greedy proof-of-work, new blockchains constrain the set of participants whose selection is debatable. These blockchains typically allow a fixed consortium of machines to decide upon new transaction blocks. In this paper, we introduce the community blockchain that bridges the gap between these public blockchains and constrained blockchains. The idea is to allow potentially all participants to decide upon “some” block while restricting the set of participants deciding upon “one” block. We also propose an implementation called ComChain that builds upon the Red Belly Blockchain, the fastest blockchain we are aware of. It runs a consensus among the existing community to elect a new community. This reconfiguration speeds up as the number of removed nodes increases.

The Blockchain as a Software Connector

Blockchain is an emerging technology for decentralized and transactional data sharing across a large network of untrusted participants. It enables new forms of distributed software architectures, where components can find agreements on their shared states without trusting a central integration point or any particular participating components. Considering the blockchain as a software connector helps make explicitly important architectural considerations on the resulting performance and quality attributes (for example, security, privacy, scalability and sustainability) of the system. Based on our experience in several projects using blockchain, in this paper we provide rationales to support the architectural decision on whether to employ a decentralized blockchain as opposed to other software solutions, like traditional shared data storage. Additionally, we explore specific implications of using the blockchain as a software connector including design trade-offs regarding quality attributes..

The Blockchain Anomaly

Most popular blockchain solutions, like Bitcoin, rely on proof-of-work, guaranteeing that the output of the consensus is agreed upon with high probability. However, this probability depends on the delivery of messages and that the computational power of the system is sufficiently scattered among pools of nodes in the network so that no pool can mine more blocks faster than the crowd. 
In this paper, we present the Blockchain Anomaly, an execution that we experienced when building our private chain at NICTA/Data61. 

On Availability for Blockchain-Based Systems

In this paper, we identify the availability limitations of two mainstream blockchains, Ethereum and Bitcoin. We demonstrate that while read availability of blockchains is typically high, write availability - for transaction management - is actually low. For Ethereum, we collected 6 million transactions over a period of 97 days. First, we measured the time for transactions to commit as required by the applications. Second, we observed that some transactions never commit, due to the inherent blockchain design. Third and perhaps even more dramatically, we identify the consequences of the lack of built-in options for explicit abort or retry that can maintain the application in an uncertain state, where transactions remain pending (neither aborted nor committed) for an unknown duration. 

Impact of Man-In-The-Middle Attacks on Ethereum

In this paper, we study the public Ethereum blockchain as well as a consortium and private blockchains and quantify the feasibility of man-in-the-middle and double spending attacks against them. To this end, we list important properties of the Ethereum public blockchain topology, we deploy VMs with constrained CPU quantum to mimic the top-10 mining pools of Ethereum and we attack them, by first partitionning the network through BGP hijacking or ARP spoofing before issuing a Balance Attack to steal coins.

Evaluating Blockchains for IoT

As proof-of-work blockchains are inherently energy greedy and offer probabilistic guarantees, blockchains based on Byzantine consensus appear as a promising technology to track billions of connected devices. In this paper, we evaluate the performance of prominent blockchains that solve the classic Byzantine consensus problem. Our results show that while offering reasonable throughput their performance usually do not scale to tens of devices and drops dramatically as the number of devices increases. 

DBFT: Efficient Byzantine Consensus

This paper introduces a deterministic Byzantine consensus algorithm that relies on a new weak coordinator. As opposed to previous algorithms that cannot terminate in the presence of a faulty or slow coordinator, our algorithm can terminate even when its coordinator is faulty, hence the name weak coordinator. The key idea is to allow processes to complete asynchronous rounds as soon as they receive a threshold of messages, instead of having to wait for a message from a coordinator that may be slow.