Conventional frameworks (HTTP/SSL/JSON) decentralized Ripple in 3500 lines of Go

[Johan Nygren]

Hi Ripple community,

Over past 3-4 years I developed frameworks ideas to build Ripple on, besides solving multihop coordination last year (the 3-phase commit that combined Ryan's "cancel on timeout" 2-phase with a "finish-on-timeout" 2-phase, to ensure a penalty on each phase an therefore allow Ryan's "penalty rate", a continuous penalty suggested by Ryan in 2006, to be used, see article). They included singlehop atomicity by exact order of events agreed on, where the race condition is solved by agreeing on who is dominant (who caves) and alternating the dominance each counter value. This avoids race conditions in FINALIZE/CLEANUP, and the need for other manual solutions (like in an earlier implementation on https://resilience.me). The framework also included atomic routing, routing over an intermediary that always succeeds, ensured by "reserving" routing slots in permanent storage (so they survive crashes...), here two slot reserved per payment (CANCEL and COMMIT can end om routing at same time in rare scenarios) with up to N max concurrent payments. The framework is 2000 lines of code and separates all underlying functionality from Ripple. It uses conventional tools like HTTP/SSL/JSON. I call it "p2p transactions", p2ptx. Then Ripple is 1500 lines of code on top of it. The "gas" functionality is slightly improved from earlier versions (previously would not forward all gas if few links, here divides evenly, a change inspired by Daniel Levy wanting to run a larger community bank on this realization of Ryan's vision - the Ripple Inter Server Protocol. Such required managing that some node had hundreds of links, so "gas" was adapted for that - and Hi Daniel if you see this). The app has routing fees, avoids need to select multiple paths by the buyer declaring their fee and each intermediary has a minimum they accept. Path finding is bidirectional, which means it involves square root of unidirectional search - 1000 instead of 1 000 000. And the gas prevents spam, routing resources (query flooding wise) are available as long as the cost is high enough to prevents network from exceeding capacity. Payments are anonymous payment identifiers that find a path - usernames of buyer or seller not included in path finding or payment (no reason for it to be).

Could be a bug or two in code. AI was used in the coding. It is based on previous codebases that are bugfree and work well. Historically I prioritized extremely simple "tech stack" (UDP and sha256 MAC) so that I could understand every part of it. Now I move to conventionalism, so that the 99% who say "if you use your own mechanism it is already not worth looking at" can be appealed to - but it wasn't possible for me to start at high abstraction because I wouldn't have been able to reason about every part of it, and not solved, for example, the 3-phase commit (article).

On GIT: https://gitlab.com/bipedaljoe/ripple-p2ptx
A public server + web-UI + source code: https://jipple.xyz

I think this demonstrates a good format for Ripple Inter Server Protocol, a very close match with Ryan's vision but with the recent advances such as 3-phase commit. The codebase might be improvable (it is AI written), but the system architecture is good. Something to collaborate around if anyone's interested in the old 2006 vision succeeding.

Peace, Johan

[Johan Nygren]

Now removed "framework" and "app" separation, cleaner that way.

On https://gitlab.com/bipedaljoe/jipple and https://jipple.org/, with web-UI and public server on https://jipple.xyz.

Everything anyone could have asked for. Peace, Johan