A new era is emerging in the world of distributed computing with the growing popularity of blockchains (shared, replicated and distributed ledgers) and the associated databases as a way of integrating inter-organizational work. Originally, the concept of a distributed ledger was invented as the underlying technology of the cryptocurrency Bitcoin. But the adoption and further adaptation of it for use in the commercial or permissioned environments is what is of utmost interest to me and hence will be the focus of this tutorial. Computer companies like IBM and Microsoft, and many key players in different vertical industry segments have recognized the applicability of blockchains in environments other than cryptocurrencies. IBM did some pioneering work by architecting and implementing Fabric, and then open sourcing it. Now Fabric is being enhanced via the Hyperledger Consortium as part of The Linux Foundation. A few of the other efforts include Enterprise Ethereum, R3 Corda and BigchainDB.

While there is no standard in the blockchain space currently, all the ongoing efforts involve some combination of database, transaction, encryption, consensus and other distributed systems technologies. Some of the application areas in which blockchain pilots are being carried out are: smart contracts, supply chain management, know your customer, derivatives processing and provenance management. In this talk, I will survey some of the ongoing blockchain projects with respect to their architectures in general and their approaches to some specific technical areas. I will focus on how the functionality of traditional and modern data stores are being utilized or not utilized in the different blockchain projects. I will also distinguish how traditional distributed database management systems have handled replication and how blockchain systems do it. Since most of the blockchain efforts are still in a nascent state, the time is right for database and other distributed systems researchers and practitioners to get more deeply involved to focus on the numerous open problems.

The XRP Ledger is a decentralized cryptographic ledger powered by a network of peer-to-peer servers. The XRP Ledger is the home of XRP, a decentralized digital asset built for payments and a source of liquidity that bridges different currencies worldwide.

What sets the XRP Ledger apart is its unique consensus algorithm that does not require the time and energy of “mining,” the way other such systems do. Instead of “proof of work” or even “proof of stake,” the XRP Ledger’s consensus algorithm uses a system where every participant has an overlapping set of “trusted validators” and those trusted validators efficiently agree on which transactions happen in what order. As of early 2018, the Bitcoin network uses more electricity per transaction than a US family home uses in an entire day, and confirming the transaction takes hours. In comparison, a single XRP transaction uses a negligible amount of electricity, and takes less than 4 or 5 seconds to confirm.

Abstractly, the XRP Ledger is a replicated state machine. The replicated state is the ledger maintained by each node in the network (both validator and tracking) and state transitions correspond to transactions submitted by clients of the network. Once validator nodes agree on sets of transactions to apply to the state, the XRP Ledger protocol specifies deterministic rules for ordering transactions within each set and how to apply transactions to generate the new ledger state. Thus, the role of the XRP Ledger Consensus Protocol (LCP) is only to make the network reach agreement on sets of transactions even in the presence of faulty or malicious participants (Byzantine), guaranteeing that every node generates a consistent ledger.

While several consensus algorithms exist for the Byzantine Generals Problem, specifically as it pertains to distributed payment systems, many suffer from high latency induced by the requirement that all nodes within the network communicate synchronously. XRP Ledger consensus algorithm that circumvents this requirement by utilizing collectively-trusted subnetworks within the larger network, where the “trust” required of these subnetworks is in fact minimal and can be further reduced with principled choice of the member nodes. In addition minimal connectivity is required to maintain agreement throughout the whole network. The result is a low-latency consensus algorithm which still maintains robustness in the face of Byzantine failures.