W3C home > Mailing lists > Public > public-interledger@w3.org > November 2015

Re: Webinar Slides

From: Evan Schwartz <evan@ripple.com>
Date: Tue, 17 Nov 2015 17:32:34 -0800
Message-ID: <CAONA2jVfjPK4MTX_sUA1_m-cZzALVN2MfiRbtFRQoeGtQy8M4g@mail.gmail.com>
To: Melvin Carvalho <melvincarvalho@gmail.com>
Cc: Stefan Thomas <stefan@ripple.com>, Interledger Community Group <public-interledger@w3.org>
It's definitely an interesting thought.

I think cross-ledger trades without a separate connector or notary entity
would work if the ledgers "understand" one another. One of our assumptions
was that we're working with very different ledgers, and that ledgers are
the hardest component to change.

Arguably, cryptographic escrow is the smallest possible change you could
make to ledgers as disparate as Bitcoin (no change needed actually) and
bank ledgers that would enable truly atomic or low-risk interledger
payments.

In Atomic mode you do have a trusted party, but you can make it Byzantine
fault-tolerant by using multiple notaries and a BFT consensus algorithm
between them. In Universal mode there's no trusted party (just one
providing the liquidity on the distant ledger), but the tradeoff is that
the liquidity-provider is taking some risk, for which they'll charge fees.

On Tue, Nov 17, 2015 at 5:26 PM, Melvin Carvalho <melvincarvalho@gmail.com>
wrote:

>
>
> On 18 November 2015 at 02:09, Evan Schwartz <evan@ripple.com> wrote:
>
>> I'd think about it in terms of use cases. If you have a larger payment
>> and need the guarantee that money cannot be lost, it would be worth it to
>> involve notaries. For smaller payments between more disparate parties
>> Universal might make more sense.
>>
>> You're right that atomicity is desirable rather than needed. If there is
>> more risk without it that will show up in higher fees though. In any case,
>> this tradeoff is precisely why there are the two modes.
>>
>
> Got it.  It seems the base assumptions are that INTRA ledger is near
> perfect trust (ie the ledger works and nothing is lost) and INTER ledger is
> low trust.
>
> I probably operate in a strange paradigm where my ledgers are all owned by
> me, and I have perfect trust of myself.
>
> What I'd like to work out in my head first step is cross ledger trades
> with perfect trust, and very little in the way of trusted third parties,
> merely a workflow.  Then to add those trusted third parties as modular
> components to make the system more robust, scalable and suitable for mutli
> trust environments.  This is probably more my own personal style of
> incremental development, and will probably end up in the same place.
>
> Generally pretty happy with the concepts here!
>
>
>>
>> On Tue, Nov 17, 2015 at 5:03 PM, Melvin Carvalho <
>> melvincarvalho@gmail.com> wrote:
>>
>>>
>>>
>>> On 18 November 2015 at 01:40, Stefan Thomas <stefan@ripple.com> wrote:
>>>
>>>> For everyone who missed the webinar on Oct 20th, the slides are now
>>>> available on Slideshare:
>>>>
>>>> http://www.slideshare.net/Interledger/ilp-webinar-102015-55230856
>>>>
>>>
>>> Very good slides.
>>>
>>> Was easier to grok than the paper (though I like the paper too)
>>>
>>> Still not that cemented in my mind yet is the role of the notary vs
>>> universal mode.  At one point I was thinking notaries make sense, then the
>>> next slides I think universal mode makes sense, and notaries dont.  Why use
>>> one and not the other.
>>>
>>> Also slight nit, I would prefer to think of atomicity is "desirable"
>>> rather than "needed", but maybe that's just me ...
>>>
>>>
>>>>
>>>>
>>>> We were also hoping to post a video of the webinar, but unfortunately
>>>> the recording was lost. What we'll probably do is either hold the same
>>>> webinar again or just record the presentation by itself.
>>>>
>>>
>>>
>>
>>
>> --
>> Evan Schwartz | Software Architect | Ripple Labs
>> [image: ripple.com] <http://ripple.com>
>>
>
>


-- 
Evan Schwartz | Software Architect | Ripple Labs
[image: ripple.com] <http://ripple.com>
Received on Wednesday, 18 November 2015 01:33:27 UTC

This archive was generated by hypermail 2.3.1 : Wednesday, 18 November 2015 01:33:28 UTC