Ryan Fugger’s Ripple
Before XRP, the shitcoin, bought it, “Ripple” was used by Ryan Fugger as the name for his project to create a peer-to-peer network of trust channels for money transfer. The basic idea is that Alice trusts Bob personally, Bob trusts Carol personally and Carol trusts David personally, therefore it is possible for Alice to send a payment to David by creating debt across A–B, B–C and C–D. Later either payments in the opposite direction (not necessarily from David to Alice, as the network can have trust relationships to multiple other peers in a complex graph) would maybe clear that debt (or not), but ultimately Bob would expect Alice to pay him in kind to settle the debt, Carol would expect Bob to pay her in kind and David would expect Carol to pay him in kind.
The system above works quite well inside a centralized trusted platform like Fugger’s own Ripplepay website (even when it was supposed to be just proof-of-concept, it ended up being actually used to facilitate payments across small communities), but that cannot scale as participants would all rely on it and ultimately have to blindly trust that platform.1
If a truly peer-to-peer system could be designed, it would have a chance of scaling across the entire society and the ability to enable truly open payments over the internet, an unreachable goal unless you use either a credit card provider, which is bureaucratic, unsafe, expensive, taxable, not private at all and cumbersome – or Bitcoin, which is awesome and excel in all aspects except scalability for day-to-day transactions.
The protocol can take many forms, but essentially it goes like this:
- A finds a route (A–B–C–D) between her and D somehow;
- A “prepares” a payment to B, tells B to do the same with C and so on (to prepare means to give B a conditional IOU that will be valid as long as the full payment completes);
- When the chain of prepared messages reaches D, D somehow “commits” the payment.
- After the commit, A now really does owe B and so on, and D really knows it has been effectively paid by A (in the form of debt from C) so it can ship goods to A.
The step 3 is the point in which the problem of the decentralized commit arises.
Fugger and the original Ripple community failed to solve the problem of the decentralized commit, which is required for such a system to be deployed. Not to blame them, as they’ve recognized the problem (unlike other people that had the same idea later2) and documented many sub-optimal solutions3.
No one thinks about it in these terms, but the Bitcoin Lightning Network is itself a Ripple-like system with an embedded solution to the problem of the decentralized commit.
- You may ask why is it bad to trust a central point if all this is already based on trust relationships between peers. If the platform goes malicious peers can jump out and resolve things on their own! But that’s not so simple, it’s not obvious when the platform will be malicious or not, it’s not clear what to do if the platform deletes data or change history. Ultimately it cannot scale because even if it was very trustworthy you wouldn’t want the entire global economy resting upon Ryan Fugger’s webserver, nor does he want that.
- See, for example, LedgerLoops, Offst and Settle.
- The old Ripple wiki lists the “registry commit method” (which requires trust in a third-party), the “bare commit method” (which is not an atomic commit) and the “blockchain commit method” (which publishes transactions to the Bitcoin blockchain and so does not scale.