{"id":22689,"date":"2014-12-06T00:00:00","date_gmt":"2014-12-05T11:00:00","guid":{"rendered":"https:\/\/bravenewcoin.com\/insights\/why-the-stellar-forking-issue-does-not-affect-ripple\/"},"modified":"2023-11-28T23:54:25","modified_gmt":"2023-11-28T10:54:25","slug":"why-the-stellar-forking-issue-does-not-affect-ripple","status":"publish","type":"post","link":"https:\/\/bravenewcoin.com\/insights\/why-the-stellar-forking-issue-does-not-affect-ripple","title":{"rendered":"Ripple Addresses the Stellar Fork"},"content":{"rendered":"

\"ripple<\/p>\n

December the 5th saw\u00a0The Stellar Development Foundation (SDF)\u00a0which maintains Stellar, a network built on a modified version of the Ripple code base, publish a post claiming flaws in the Ripple consensus algorithm. In response, the team at Ripple has released a statement out lining the issues.<\/p>\n

Issue 1: Sacrificing safety over liveness and fault tolerance\u2014potential for double spends<\/strong><\/p>\n

The Fischer Lynch Paterson impossibility result (FLP) states that a deterministic asynchronous consensus system can have at most two of the following three properties: safety (results are valid and identical at all nodes), guaranteed termination or liveness (nodes that don\u2019t fail always produce a result), and fault tolerance (the system can survive the failure of one node at any point). This is a proven result.<\/strong><\/p>\n

Any distributed consensus system on the Internet must sacrifice one of these features.<\/strong><\/p>\n

\n

This is potentially misleading. The FLP result shows that no system can provide those guarantees and reach consensus in bounded time. Real-world implementations of consensus like Paxos and Ripple however use probability to achieve safety, liveness and fault tolerance within a given time limit with very high likelihood. If consensus is not achieved in this timeframe, the algorithm will retry and once again achieve consensus with very high likelihood and so on. In statistical terms, consensus will eventually be reached with\u00a0probability 1<\/a>, satisfying liveness under a probabilistic model. In practice, progress is usually made every round and two or more rounds are very rarely needed. This means that distributed consensus systems like the Ripple network and Google\u2019s Spanner database exist and can provide extremely high availability if configured correctly.<\/p>\n<\/blockquote>\n

The existing Ripple\/Stellar consensus algorithm is implemented in a way that favors fault tolerance and termination over safety<\/strong>.<\/p>\n

\n

This is incorrect. We have not reviewed Stellar\u2019s modified version of Ripple consensus, but as far as the Ripple consensus algorithm is concerned, the protocol provides safety and fault tolerance assuming the validators are configured correctly. For a detailed proof, please see our\u00a0consensus white paper<\/a>.<\/p>\n<\/blockquote>\n

This means it prioritizes ledger closes and availability over everyone actually agreeing on what the ledger is\u2014thus opening up several potential risk scenarios.<\/strong><\/p>\n

\n

This is incorrect. If a quorum cannot be reached, validators will retry until connectivity has been restored.<\/p>\n<\/blockquote>\n

Issue 2: Provable correctness<\/strong><\/p>\n

Prof. David Mazi\u00e8res, head of Stanford\u2019s Secure Computing Group, reviewed the Ripple\/Stellar consensus system and reached the conclusion that the existing algorithm was unlikely to be safe under all circumstances.<\/strong><\/p>\n

\n

We look forward to reading Prof. Mazi\u00e8res\u2019 findings once they are published.<\/p>\n<\/blockquote>\n

Based on these findings, we decided to create a new consensus system with provable correctness.<\/strong><\/p>\n

\n

As mentioned before, a proof of Ripple\u2019s correctness is available in the form of the Ripple\u00a0consensus white paper<\/a>. As Ripple Labs\u2019 chief cryptographer and the original developer of Ripple consensus David Schwartz\u00a0pointed out yesterday<\/a>,\u00a0there cannot be two conflicting majority sets without overlap. For bootstrapping with a small set of trusted validators, it is appropriate to use a crash-recovery fault model, meaning a simple majority such as three out of five is sufficient.\u00a0In other words, it is impossible for the Ripple network to experience an unintentional ledger fork as Stellar\u2019s did because our nodes require votes from a majority of validators. In the future, we will generally recommend a supermajority greater than two thirds to account for Byzantine faults (validators that act arbitrarily or maliciously), but otherwise the same concepts apply. In either case, anyone wishing to join a specific set of mutually consenting validators in the Ripple topology can do so by configuring their local Ripple node appropriately. We recognize the immense task of building the world\u2019s first global consensus graph. It is a hard problem, but not an impossible one. Like the transition from Arpanet to the distributed routing topology of the modern internet, it will require time, education and a great deal of caution. But thanks to our amazing partners and colleagues, we are ready to tackle this challenge. The Ripple network and its distributed ledger have used the Ripple consensus protocol to operate reliably for two years and currently manage $1.4 million in daily volume. We continue to invest in scaling Ripple to support the world\u2019s cross-border transactions with bank partners in the U.S. and Europe actively integrating today.<\/p>\n<\/blockquote>\n

The post by\u00a0Stefan Thomas can be found here<\/a><\/p>\n

Ripple is a universal protocol for money transfer that allows independent payment systems to communicate as easily as email systems do. Ripple provides a shared standard for payments. As with email, no one owns Ripple, and there is no central operator. Ripple is open source software that allows servers all over the world to communicate peer-to-peer financial transactions to one another.<\/p>\n


\n

Ben Ferris has a keen interest in financial markets, new and old. Participates in FOREX and is invested in BTC. Constructive comments are always appreciated.<\/p>\n","protected":false},"excerpt":{"rendered":"

“We take any reports about possible security issues very seriously and after reviewing the information conclude that there is no threat to the continued operation of the Ripple network.” – Ripple<\/p>\n","protected":false},"author":1207,"featured_media":22690,"comment_status":"closed","ping_status":"closed","sticky":false,"template":"","format":"standard","meta":{"footnotes":""},"categories":[1],"tags":[204,360,202],"_links":{"self":[{"href":"https:\/\/bravenewcoin.com\/wp-json\/wp\/v2\/posts\/22689"}],"collection":[{"href":"https:\/\/bravenewcoin.com\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/bravenewcoin.com\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/bravenewcoin.com\/wp-json\/wp\/v2\/users\/1207"}],"replies":[{"embeddable":true,"href":"https:\/\/bravenewcoin.com\/wp-json\/wp\/v2\/comments?post=22689"}],"version-history":[{"count":1,"href":"https:\/\/bravenewcoin.com\/wp-json\/wp\/v2\/posts\/22689\/revisions"}],"predecessor-version":[{"id":41395,"href":"https:\/\/bravenewcoin.com\/wp-json\/wp\/v2\/posts\/22689\/revisions\/41395"}],"wp:featuredmedia":[{"embeddable":true,"href":"https:\/\/bravenewcoin.com\/wp-json\/wp\/v2\/media\/22690"}],"wp:attachment":[{"href":"https:\/\/bravenewcoin.com\/wp-json\/wp\/v2\/media?parent=22689"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/bravenewcoin.com\/wp-json\/wp\/v2\/categories?post=22689"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/bravenewcoin.com\/wp-json\/wp\/v2\/tags?post=22689"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}