Ripple xCurrent - Smart Departure From Ripple's Blockchain Legacy
In my role I am frequently asked to comment on and occasionally speak about Ripple's xCurrent 'blockchain solution'. Hm ... this is really tricky one. Yes, name Ripple is usually associated with blockchain technology. Ripple Labs gave us the original RCL blockchain platform and the associated XRP cryptocurrency. Unfortunately, I still hear many high end consultants (mainly from big four consultancies) and prominent blockchain evangelists confidently talking about Ripple xCurrent as the 'blockchain solution'. Being an Electrical Engineer (with major in Computer Science) by training, I always get bothered by these inaccuracies and have a strong desire to set the record straight.
Usually, the most people asking for my opinion and/or clarification on this matter, get initially very surprised (some in complete disbelief!) and then outright disappointed, when I finally explain why Ripple xCurrent, although a very smart technology platform, is not blockchain based at all. Since xCurrent is based on InterLedger Protocol (ILP), my explanation is usually focused on explaining what Ripple ILP is and isn't. After that, xCurrent explanation follows, but is almost always very trivial and quick.
Ripple InterLedger Protocol (ILP)
The traditional distributed ledger technology (a.k.a. BLOCKCHAIN) requires and mandates that all participating network nodes maintain (and 'see') the exact same ledger state in their individual distributed ledger replicas. In every DLT / blockchain implementation (including Ripple's own original Ripple Consensus Ledger or RCL) there is always one common ledger state that is replicated (via consensus reaching algorithm), to each participating node, without reliance on centralized coordination. That common ledger state is always maintained as a list of 'transactional blocks' that are backward linked (i.e. 'chained') via set of hash pointers. Blocks also contain 'proof of work' info (or 'proof of something'), which guarantees committed ledger state immutability (by making it ultra hard and expensive to be modified).
That is not the case with the Ripple ILP implementation though, where there is no such common and replicated ledger state. Quite the opposite - in Ripple ILP, the ledger state that is maintained in each individual node, is inherently different than the ledger state in all other participating nodes . The Ripple ILP implementation therefore, coordinates updates to a set of distributed, inter-dependent and complementary, but mutually different ledger states, as part of an overall integrated end to end financial transaction execution.
Ripple ILP achieves that goal by ensuring that all of the different ledger state updates in participant nodes are coordinated in an atomic way, i.e. all executed in-sync together OR none at all. The ILP relies on Two Phase Commit (2PC) protocol, which was successfully used for several decades as standard method for centralized coordination of transaction updates in traditional distributed database and message queue systems.
The beauty of Ripple ILP is in that it further enhances the robustness and resiliency of the classic 2PC protocol, by requiring cryptographically signed ‘ready to commit’ indications from each of the participating nodes (in 2nd phase of 2PC protocol) and thus completely eliminating need for centralized coordinator. Instead, ILP is relying on distributed Byzantine-Fault-Tolerant (BFT) consensus algorithm between participating nodes, to reliably reach the final decision on whether to commit or abort their individual and incremental ledger state updates, along the transaction path.
Therefore Ripple ILP basically behaves as clever distributed cryptographic escrow solution, which is the direct result of the distributed 2PC coordination of the underlying individual ledger state updates as part of the end to end transaction.
As you can see, no blockchain is involved, as every node (sender, receiver or any of the connector nodes) maintains its own unique database state, which is usually different from other node states. There are no chained blocks, nor need for 'proof of something', period.
What About Ripple xCurrent?
Since Ripple xCurrent is implemented on top of the Ripple ILP, that's pretty much where need for further explanation usually ends for those who get it. xCurrent is nothing but standardized RESTful API layer on top of ILP, provided as part of the overall platform, for ease of integrating ILP into the rest of the enterprise.
For those still unconvinced? Maybe these can help too: