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.
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..
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.
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.
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.
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.
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.