Proxying Ledgers

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.