Financial institutions worldwide are exploring the possibilities for faster, cheaper, more transparent processing of global payments in near real time offered by distributed software solutions, including blockchains and distributed ledgers. Because this is a new field of study, these technologies are often misunderstood or mischaracterized.
I want to clear up some basic misconceptions about one such system, Ripple in particular, the meme that the entire project is intended to remain centralized under the control of Ripple Labs, the company that develops the protocol, and/or its partner financial institutions. I will assume the reader has a rudimentary understanding of Bitcoin, the most well-known decentralized cryptocurrency. Through this lens, I will explain how Ripple is different, with the clear design goal of evolving out of the centralized monopoly which its critics currently focus on.
A good place to start understanding the breadth of current options is with the widely read and much-discussed paper by Tim Swanson, the cryptocurrency consultant. Tim classified distributed ledgers as either "permissioned" or "permissionless" by virtue of whether the servers running the network have been identified and vetted by participants, making them accountable for the veracity of authentications they perform. The paper was largely panned by Bitcoin maximalists. These purists are always quick to dismiss distributed ledgers not secured by censorship-resistant proof of work the trustless, synchronous, incentivized security method that Bitcoin pioneered as simply universal spreadsheets, compared to the supposed panacea of Bitcoin where the only trust required is "in the math." In this case, they are incensed by Tim's assertion that distributed ledgers requiring "permission" are the only viable option for commercial entities rather than Bitcoin, a permissionless, decentralized network.
The Bitcoiners' objections to one side, I would assert that Tim's basic premise that distributed ledgers can only be put in a binary classification of "permissioned" or "permissionless" is exactly the paradigm Ripple aims to undo.
I do agree with Tim that "permissioned" seems to be a core requirement for the ongoing adoption of distributed ledgers and other blockchain models by many established financial institutions, fintech providers as well as corporate and federal treasuries. Where Ripple diverges is by providing the ability for every participant to "choose your own permissions."
This architecture is permissioned in one sense and permissionless in another. It allows anyone to participate (permissionless) and allows everyone to individually select the transaction validators they have evaluated, trust or perhaps have contracted with (permissioned). Ripple also provides a technical mechanism which allows validators' status to be changed in response to their behavior, including potential attacks, without creating "forks," or competing versions of the ledger.
This is a unique capability which derives from Ripple's consensus algorithm, designed to deliberately sacrifice "liveness," i.e. always confirming transactions in the consensus round it was submitted with, in favor of "correctness" only ever confirming correct transactions. Another critical, technical difference is that Ripple is not a "blockchain," it is a "ledgerchain." This feature enables a decentralized market to exist within the protocol and is a key economic component to the total functionality of Ripple as a cross-border payment rail and global marketplace for capital float.
Furthermore, Ripple Labs has designed the protocol with robust security and compliance features similar to familiar current banking regulations. There are also security tools (vetted, audited and mandated by the Financial Crimes Enforcement Network as part of a legal settlement) which provide a layer of compliance beyond simply providing a gated environment. These further security assurances and regulatory precedent are unmatched in the cryptocurrency world.
Ripple's novel consensus algorithm allows for a softer set of rules to govern the participant permissioning process. The rule set makes it possible to participate nominally without any trust or permission required whatsoever, but also empowers actual network growth and scalability by allowing all participants to extend and revoke trust or permission to any partners they wish to include with meaningful contributions to transaction processing within their selected quorum. The decision to extend or revoke trust can be based on any multitude of parameters, but would most likely revolve around past performance, contractual obligations, business relationships, a change in credit rating, political or economic upheaval or could be in response to the potential presence of an attack or other legitimate or even arbitrary reasons. David Schwartz, Ripple's chief cryptographer, has predicted that publishers will materialize to monitor, catalogue and rate validators to help participants make educated decisions on whom to include in their quorum.
Ripple achieves this capability with a unique solution to the Byzantine General's Problem of coming to consensus on possible transactions. At the core of the Ripple protocol is a decision algorithm which purposefully makes it easier to reject potentially erroneous or malicious transactions without doing so permanently.
Ripple uses a sequential, rolling series of exceptionally fast, computationally controlled voting rounds which either pass the transactions up to the next round or keep them back to be reviewed again perpetually. With each round of voting the majority requirement for agreement among the known, trusted validators listed by each node its UNL, or unique node list increases by 10%. The threshold starts at 50% and progresses up until 80% of nodes in a list have given the thumbs up, at which point the transaction is permanently committed to the distributed ledger kept on every server. By letting questionable transactions persist in "limbo," Ripple's architects purposefully chose to sacrifice immediate processing of possibly wrong transactions in favor of slightly delayed processing of exclusively correct transactions. The consensus rounds in Ripple are very fast, generally five to 10 seconds, a timeframe which is long enough to keep global synchronicity, but fast enough that letting controversial transactions go through additional vetting rounds does not incur delays of significance.
Should an attack surface, like that envisioned in Bitcoin developer Peter Todd's partial analysis of Ripple, two features he failed to consider would prevent the attack from succeeding.
The first is the flexibility of the consensus algorithm to hold transactions in limbo without forking the ledger between disagreeing validators. Perpetually stuck transactions are visible, alerting network operators to identify misbehaving nodes and resolve the hang-up, either by delisting nodes for running an incompatible or perhaps tampered-with protocol, or by repairing the nodes should they be malfunctioning or compromised.
The second feature that would thwart a hypothetical attack is the validator manifest. This security feature allows a validator to use a permanent master key to globally reset its private/public key pair should it be compromised. Imagine if someone stole your wallet but you could change all your various account numbers and passwords in one go. Just as the thief couldn't ring up charges on your credit card for very long, an attacker would have very little time to use a stolen private key to sign Ripple transactions. Ripple attempts to distribute the power to make and break the trust relationships that are needed to keep the network cohesive. This remarkable endeavor means that monitoring network topology, and developing tools to ensure sufficient overlap between unique groups or cliques operating on the network, are still works in progress. Ripple Labs had been developing a smart contract platform called Codius, which seemed clearly intended to function as a safe, automated tool to incentivize and maintain the sufficient overlaps in the decentralized topology, ensuring continued connectivity of the network. But as it became clear the scope of a generic product for smart contracts was much broader and diverse than the decentralization Ripple sought witness the massive scope creep of the Ethereum project Ripple Labs shuttered the project in favor of focusing on other ways to achieve decentralization. One such way is provided by dedicated hosting cloud platforms, utilizing containers and other new solutions.
Ripple Labs' holistic intent is to build what it calls "the Internet of value." To do so, the firm needs much more that what a mere "blockchain" can offer. It needs a ledgerchain, which stores data of the entire state of the decentralized ledger with every consensus round chained to each ledger which came before it. Every seven seconds, there's a new panoramic snapshot of the landscape. In Bitcoin, by contrast, one can see the big picture only by examining the entire blockchain, the complete history of every transaction and its unspent outputs. This is a painstaking process to which whole companies are devoted.
Ripple's ability to store ledger state delivers the capability for partial payments, negative balances, trade offers and counterparty IOUs with every consensus round, a trove of data which offers substantial capabilities and features. Most crucial is an embedded decentralized market for assets, whether counterparty IOUs for pegged assets like dollars or yen or the integral token XRP, which is the only asset on the network with no counterparty. The goal is to build a market for float, where market makers, hedge funds and other investors can offer their capital to function as the float that businesses, governments, and individuals need to send transactions cross-border, cross-system, and cross-rail to any system gateway on the Internet.
The parameters and characteristics designed into this system of counterparty IOUs are also critical to Ripple's ability to function, given the current regulatory requirements of value transfer and political realities. Monitoring and freezing capabilities have been incorporated into Ripple for individual IOU accounts as well as entire currencies (except the native token) to comply with anti-money-laundering and anti-terror-financing laws. These features allow banks to operate as gateways with every bit of functionality they are used to having with their own account systems. This is perhaps why Ripple is the one of the first cryptocurrencies to have interacted and functioned directly with banks' own back-end systems.
With transparent accounting and tracing, Ripple enables rapid modeling of potential fraud and money laundering and other real-time risk assessment tools. Ripple still has to address the quintessential dilemma of public ledgers yielding transparency at expense of privacy. Securing identity still promises to be the key to the future of finance and may be necessary to secure comprehensive financial inclusion.
In closing: Ripple aims to offer a kind of "soft permissioning" where any entity, corporation or government can join in running a validating server which processes transactions. But each actor is individually capable of deciding which other servers to trust with full voting rights in validating transactions. This creates a meta-layer of control which is absolutely decentralized by assigning every single participant the ability to choose its own quorum of validators. The concept of gated quorums voting on transaction sets isn't new or revolutionary and most critics latch onto this concept as evidence Ripple will remain centralized. I believe the critical innovations the Ripple team has developed are key steps to enable diversified, decentralized voting quorums to coexist in a real-time, global, permissionless, and stable topology on the future Internet of value.
Thomas Sean Kelleher is a technologist and architect in Kailua, Hawaii.
Corrected July 31, 2015 at 11:15AM: This post is adapted from a comment the author wrote on XRPTalk, a forum for users of the Ripple network. We are publishing it as a rebuttal of sorts to criticisms of the Ripple protocol made by regular BankThink contributor Chris DeRose in a recent post. Kelleher has a small holding of XRP, the native digital currency of Ripple, but he does not work for Ripple Labs.