# Ryan Fugger´s Ripple (2003/2004) in a computationally decentralized way

This is a suggested architecture for a true P2P implementation of Ryan Fugger´s money system Ripple, and a working codebase for it. The foundation of the architecture is guaranteed single-hop consensus. The premise is that single-hop consensus is required to manage multi-hop agreements where all exchanges are only ever over a single-hop. An overview of how single-hop consensus has been the "missing puzzle piece" is given in the "whitepaper" in README.md.

## Documentation of the codebase

### Minimalism as the guiding principle

This codebase is a single account server. It has minimal concurrency and is single-threaded for most operations. Reading and writing to storage is therefore mostly single-threaded and there is minimal need for mutexes. Signatures are as minimalistic as possible, a simple `sha256(message+secretKey)`. Transport of messages over network uses UDP-R (UDP with retransmission), and counters for replay protection.

Concurrency is used only in the "transport" module, since sending with UDP-R is the only blocking operation. 

Account transactions are separated into those with guaranteed consensus and those without. Those with guaranteed consensus have a priority queue, but are still sent with the same counters as non-consensus transactions. This forces transport data writes to also be concurrent. Therefore, transport data is stored in its own file in storage (and protected by a mutex).

Pathfinding is minimalistic in this architecture. It optimizes for minimal number of queries. It does this by searching in two directions, from both buyer and seller at the same time. To do this, the buyer and seller need a direct communication channel.

Storage is done with "gob". The number of peers, path search objects, pending payments and receipts are all limited to `config.BufferSize` (currently 16).

The server is initialized from a config file that stores the server address (used when sending transactions so the receiver knows what user it was from), the server port, the user's username and the user's secret key.

## Tests

You can use the test module to run tests. You define a number of users in a JSON file together with a sequence of user requests they will send. The test module spins up servers for each user (and you can use remote server too if you prefer).

The scenario [multihop_payment_scenario.json](tests/scenario/multihop_payment_scenario.json) sets up trustlines over two hops and does a payment. It tests the commands `USER_ADD_ACCOUNT`, `USER_SET_TRUSTLINE`, `LOCKSTEP_SET_TRUSTLINE`, `USER_NEW_PAYMENT`, `USER_START_PAYMENT`, `ACCOUNT_FIND_PATH`, `ACCOUNT_PATH_FOUND`, `ACCOUNT_PREPARE_PATH`, `COUNTERPART_COMMIT_PAYMENT`, `LOCKSTEP_COMMIT_PAYMENT`, `COUNTERPART_FINALIZE_PAYMENT` and `LOCKSTEP_FINALIZE_PAYMENT`. 

The scenario [8_users_payment_scenario.json](tests/scenario/8_users_payment_scenario.json) is similar but with more people involved and two payments.