- From: Michiel de Jong <michiel@ripple.com>
- Date: Mon, 20 Mar 2017 14:52:02 +0100
- To: public-interledger@w3.org
- Message-ID: <CA+Rq6=Af8mbUU8ee4ZBpXBQFaYUHwU3oGdLbLudG4vqQAnCYkg@mail.gmail.com>
Hi all, So far we mainly considered subscription-based ledgers, where the recipient of a transfer needs to be connected to the ledger 24 hours a day, for instance by keeping a websocket open. I think this is a big burden on both the user and the ledger, and would like to propose an alternative: get rid of subscriptions, and use a "proxying ledger" instead. It acts as a proxy between Alice and Bob, and the whole interaction of forwarding an ILP transaction is reduced to one http request, where the ledger acts as a proxy between Alice and Bob: Alice -> Ledger: "please put part of my ledger balance on hold for the purpose of paying Bob, this crypto-condition, this expiry time, this amount". Ledger -> Bob: "Alice sent this message: <Alice's message>, and I (the ledger) have put the appropriate amount from Alice's balance on hold for you" Bob responds -> Ledger: "here is the fulfillment" Ledger responds -> Alice: "Bob responded with: <Bob's message>. Judging by my clock, he was on time, and so he has been paid." A proxying ledger consists of two components: a proxy and a database. The proxy has three tasks: 1) reassure Bob that Alice has put enough money from her balance on hold for him. 2) judge if Bob's fulfillment message was on time or too late. 3) deliver Bob's fulfillment message back to Alice. The database keeps track of each account's balance, as well as for each account, if any money has been put on hold, and if so, for which purpose (recipient, amount, cryptocondition, expiry). Holds can be kept in memory, since they will only live for, typically, less than 30 seconds. Writing to disk is only needed after a transfer is successfully fulfilled (this is actually also true for subscription-based ledgers). There's no need to keep track of accounts that have zero balance; Alice can spontaneously pay Bob at his "pay me" URL, and if Bob accepts the payment, that will be his account's funding balance at the ledger. Bob should of course be wary of payments from ledgers he doesn't trust, but he can trust >=1 ledgers using just one endpoint. I also considered the architecture where Alice obtains a signed proof-of-reservation from the ledger, and sends this to Bob out-of-band; the proxy would then only be used in the Bob-to-Alice direction, to judge if Bob's fulfillment was on time; that would have slightly different advantages in terms of scalability and robustness. Instead of subscribing to a WebSocket, Bob now needs to run a webserver. Part of the task of delivering the message to Bob is thus taken away from the ledger. Curious what people think of this design! :) Cheers, Michiel.
Received on Monday, 20 March 2017 13:57:55 UTC