- From: Andrew Bransford Brown <andrewbb@gmail.com>
- Date: Wed, 22 Mar 2017 17:14:01 -0400
- To: Michiel de Jong <michiel@ripple.com>
- Cc: Interledger Community Group <public-interledger@w3.org>
- Message-ID: <CAPS+YF+ULsg0Z6QkQ1bnXTSPJyX0DEfdrFBXU-twSpKHsT-71A@mail.gmail.com>
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. >> > >
Received on Wednesday, 22 March 2017 21:14:34 UTC