Re: Proxying Ledgers

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