Re: Proxying Ledgers

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:  http://34.208.7.206/ContractsPage.aspx

Feel free to create and add contracts.

Andrew B. Brown
(512) 947-8282
http://KidsCourtyard.com


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

> 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.
>>
>
>