W3C home > Mailing lists > Public > public-interledger@w3.org > March 2017

Re: Proxying Ledgers

From: Andrew Bransford Brown <andrewbb@gmail.com>
Date: Wed, 22 Mar 2017 17:14:01 -0400
Message-ID: <CAPS+YF+ULsg0Z6QkQ1bnXTSPJyX0DEfdrFBXU-twSpKHsT-71A@mail.gmail.com>
To: Michiel de Jong <michiel@ripple.com>
Cc: Interledger Community Group <public-interledger@w3.org>
A common language to describe transactions:  The words and steps need
careful review to develop a common language (and protocol) for any
transaction or contract:

Feel free to create and add contracts.

Andrew B. Brown
(512) 947-8282

On Tue, Mar 21, 2017 at 7:14 AM, Andrew Bransford Brown <andrewbb@gmail.com>

> Hi Michiel,
> I have a system that will do exactly what you require.  It was designed to
> handle exchanges, settlements, and transaction coordination,  plus smart
> contracts.  So, it can do a proxy ledger too.
> Core functionality was finished last week.
> Andrew
> On Mon, Mar 20, 2017 at 9:52 AM, Michiel de Jong <michiel@ripple.com>
> wrote:
>> 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 Wednesday, 22 March 2017 21:14:34 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 22 March 2017 21:14:35 UTC