Atomic transactions and atomic routing (good foundation for atomic 3-phase multihop payments)

[Johan Nygren]

Atomic transactions within an "account" in Ripple, between two users who have a trustline, ideally uses a shared counter, and alternating dominance (a "turn bit", peer who has lowest bit value of user identifier is 0 and the other peer is 1, and then counter mod 2). The dominant peer will ignore sends from the other peer if they are also currently sending. ACK/NACK is used as normal. The pending transaction at either peer is stored persistently in storage prior to starting to try and send, and the state transition for their app is done together with counter increment, atomically.

Atomic transactions remove all race conditions in order of events on a Ripple "account" between two users. In Ripple, this might not be a requirement (it works even with uncertain order of events), but for "collateral" on Ripple, both parties want to sign off on the most recent state in the right order, thus they have to agree on an exact order of events, and "Lockstep" as I called it a year ago+ does that (and now it also has ACK/NACK...). More or less, using two counters with atomic transactions (as I did in resilience.c...) or one counter (as I did in ripple.archi and now in p2ptx...) is not a big difference, and one counter you need one counter less and you can easily have both peers sign off on the state to integrate with state channel on Ethereum/Bitcoin etc. An alternative is to have two counters for some things and one for others, but it seems simpler to just always use the stricter case...

Atomic routing, stores any transaction to be routed persistently as well. Since there is a limit to how many transactions can be queued for routing, a node has to reserve capacity for routing in advance. That is, the node routes internally from peer-in to peer-out, and it has to have reserved capacity to do so beforehand to guarantee atomic routing can be done. The app will typically do two phases coordination at least where a "prepare" step involves reserving the route for the commit (or pre-commit in 3-phase...) step. If atomic routing is attempted when the capacity has not been reserved (and the send queue is full), the transaction returns an error to the sender, who then tries to send again (whereas in non-atomic routing the peer is able to return a NACK instead, routing was not guaranteed but "best effort"). Typically, this is harmless, but deadlocks can happen, and that's where the reservation was the solution. If apps simply follow the rule that they reserve capacity beforehand whenever they want to guarantee routing, deadlock never happens.

Atomic routing means manual push routines and tracking of state internally in app to manage send buffer overflow or crashes is not needed (in my resilience.c or older Go Ripple implementation, I instead relied on the manual approach). I would think it simplifies things, even if it may seem to complicate initially. Atomic routing has to be guaranteed regardless, so this just provides a framework that automates it (much like how RAII in C++ is a set of rules that, if  people follow them, avoids complications).

Atomic payments, are with the 3-phase commit that combines Ryan's cancel-on-timeout 2-phase commit with the finish-on-timeout 2-phase commit I used, and in doing so achieves a penalty on all phases such that Ryan's 2006 "gradual penalty" can be used (without a penalty on all phases, the increased duration of the cumulative timeout undermines the timeout as a solution to stuck payment coordination... i.e., the timeout as a solution to start with assumes the timeout is rather short but with a gradual penalty the timeout itself ceases to be the solution, rather the penalty as an social incentive becomes the enforcement).

A framework with atomic transactions and atomic routing is a good foundation for p2p apps including Ripple, "multi-lateral barter" loop clearing, P2P-novation, or anything else.

I demonstrate one here: https://gitlab.com/bipedaljoe/p2p-novation/, where I limited reservations to one per peer, and I am rewriting to allow multiple reservations per peer: https://gitlab.com/bipedaljoe/p2ptx (the "ripple" implementation here was AI quickly writing from me feeding in https://resilience.me/resilience.c to it, it will take a few days to finish it, but I am preparing the framework to support it incl. it now has SendMessage besides just SendTransaction, where messages have no counter and are for volatile memory things like path finding, things where state in a Ripple user-to-user "account" does not have to be synced).

My manual Ripple implementation has worked great for over half a year, anyone has been able to register on https://jipple.net to tests it (with path-based redistribution built-in) or run their own server, it is a multi-server true Ripple Inter Server Protocol implementation... The long term goal was always a framework but it is much easier to start manually, and it is easier to first build and demonstrate a full working system, and to then try and generalize. I did start with framework-focus in 2024 but then settled for the fully manual approach first. Physical circuits is easier than machine language is easier than Assembly is easier than high-level language, so to speak. Going higher up in complexity is harder, not easier. There is much more to oversee, it becomes a much more complex systems. High level is only easy if everything has already been built for you. When building a new type of thing, it is harder to start highest level.

Also, everyone interested in Ripple should study "three-party novation" operation and how all novation can be reduced to it, and how it works with trustlines, and provides the low level in the "peer-to-peer money system" where Ripple/loop clearing is the high level. Here is the coordination rules: https://gitlab.com/bipedaljoe/p2p-novation/-/blob/main/docs/novation-protocol.png. Extremely simple.

Peace, Johan