A report commissioned by secretive distributed ledger consulting group R3CEV and authored by bitcoin developer Peter Todd has raised questions about the ability of the Ripple protocol to serve the needs of global financial institutions in its current iteration.
The release notably comes at a time when Ripple Labs, the corporate entity overseeing the network, has been increasingly attracting the attention of legacy financial institutions interested in bitcoin and the wider blockchain ecosystem. Ripple Labs has raised $37m to date, and partnered with Commonwealth Bank, Fidor Bank and Western Union.
In a companion report, R3CEV researcher Jo Lang asserts that the intent of the effort is to provide clarity to financial institutions as they conduct due diligence on companies and solutions in the nascent industry.
Though critical of some aspects of the company’s approach, Lang ultimately found that the problems identified in Ripple’s consensus algorithm are not unique to its protocol, writing:
“When taken as a whole, the risks and indirect incentives discussed in this and the companion paper have the potential to position Ripple Labs as a new trusted third party within the global payments landscape.”
The wording of the report suggests that other evaluations will soon follow, all with the intent of providing a deep dive look into the technological capabilities of the industry’s most well-known blockchains and ledgers.
R3CEV’s team is led by former Wall Street financial markets expert and managing partner David Rutter, and the group boasts Perkins Coie senior counsel Jacob Farber, Open Mustard Seed chief architect Patrick Deegan and bitcoin industry critic and pundit Tim Swanson as advisors.
Areas of concern
Although it includes praise for Ripple Labs, the R3 companion report to Todd’s research identified a number of “areas of concern” for large financial institutions regarding the open-source technology offered by the company.
Specifically, R3 highlighted its belief that if more than 20% of Ripple’s network nodes do not agree, the system’s ledger would effectively fork. This issue, the report said, would be compounded at scale due to the differing settlement needs of the financial institutions potentially seeking to use its payment network.
Perhaps most troubling given the decentralizing nature of the technology, R3 concluded Ripple would not likely result in any significant changes to the currently centralized settlement model.
“The highly centralized model that the Ripple Network encourages fails to eliminate any need for a trusted third party but rather creates a new type of third party,” the report reads.
R3 also suggested that the use of a cryptographic token (XRP) by the consensus algorithm effectively creates an “incentive misalignment” that puts it at odds with nodes operating on the Ripple network.
“Ripple still holds the majority of XRP, and it is in their favor for its value to increase,” the report continues. “Ripple justifies XRP as an ‘anti-spam mechanism’ to deter transactions… However, as the volume of transactions increases the server load, transaction speed is slowed while the cost of the transaction and the amount of required XRP continues to increase.”
Ripple’s original founder, Jed McCaleb, has notably been involved in a number of high-profile battles over his ability to sell XRP holdings.
Further, R3 suggested that Ripple lacks a “clearly defined validator incentive” that would encourage the number of nodes on the network overseeing transactions. Ultimately, the report added, financial institutions would have to weigh these pros and cons when seeking to leverage the company’s solutions.
Todd dissects Ripple
In his 16-page analysis, Todd begins by explaining the overall architecture of Ripple, providing an overview of how it has evolved from its original concept of attempting to record debt relationships to a global ledger of transactions and account balances.
After explaining the architecture of Ripple’s ledger, Todd dives into a list of open questions that remain regarding the company’s approach to network consensus.
In particular, he contends that it is not clear how account balances on the Ripple network can be negative, if it supports single payment verification (SPV) or if there is the ability to shard the Ripple blockchain so that it becomes a series of independent, yet interoperable blockchains, an attribute he argued would be beneficial for the protocol’s scalability.
Embedded throughout are insights into how Ripple differs from the bitcoin blockchain, its distributed payment network, such as how the network requires changes to codebase for technology that can be implemented through software elsewhere.
“For instance, while on bitcoin the implementation of multisig was possible without modification to the protocol in Ripple the lack of extension capabilities such as scripting require a consensus-critical change,” Todd writes.
Todd concludes that the blockchain technology underpinning Ripple is “relatively uninteresting”, but that it is currently unclear whether there is the proper alignment of incentives for the network to come to a global consensus on activities carried out on the ledger.
“A key question that should be answered in future work is if the goals of the Ripple system need global consensus at all? If global consensus can be avoided, or at least its use minimized, many of these issues may go away,” he adds.
Attack scenarios
Todd next walks readers through a number of theoretical attacks that could take place against the Ripple protocol, discussing his estimates of the cost, scope, duration and probability of the scenarios.
Those discussed include the risk of a “consensus split”, whereby Ripple is unable to process transactions or a fork is created that allows the attacker to execute invalid transactions. Todd projects that Ripple could survive a consensus split that is either malicious or accidental “fairly quickly”, due to the ability of the bitcoin network to overcome the scenario in 2013.
A “transaction flood” is also discussed, though Todd details how the Ripple protocol’s use of a native token, XRP, could deter such efforts. Any attacker wanting to flood the network would need to purchase XRP to execute the transactions, driving up fees in the short term.
Perhaps the most glaring, Todd’s writing infers, is the damage that could be done due to a “software backdoor”, as he finds that Ripple “does not provide a secure way to download any of their software”.
“This is a serious omission that has lead to significant monetary losses in the past. Ripple Labs should be following industry best-practice by signing git commits and tags as well as PGP signing their Ubuntu packages,” Todd added.
Todd ends by highlighting the potential real-world implications of these attacks in an elaborate scenario involving a dispute between the Russian government and Shell Oil, forecasting how these parties might attempt to achieve their aims through coercion on the network.
Reaction
Reaction of the paper, released on Saturday, has so far been subdued, with some criticism being voiced on XRP Talk, a community forum dedicated to the Ripple protocol.
While concerns were raised, however, the report was viewed by some contributors as “the first serious, non-malicious attempt at pointing out perceived weaknesses in the system”.
Other commenters took issue with the criticism that it is unclear what the incentive is for nodes to participate in the ecosystem and pointed to potential problem areas that are being worked on by the development community.
At press time, Ripple Labs had not issued a response to the paper on its official blog.
Ripple Protocol Consensus Algorithm Review_Peter Todd_May 2015
Node visualization via Shutterstock