Re: Blockchains and interledger (left-over question from the workshop)

> This is definitely useful for me (and probably other devs). Is there
somewhere a more formal descriptions of this separation of concerns?

Not yet, but we're working on some new documentation which will likely
include it.

> Maybe a targeted API (functionality, responsibility, ...) per layer could
be useful...

Yeah, right now the layers align nicely to the different five-bells-*
projects, so those projects' APIs could be the starting points for the
respective layers.

On Thu, Mar 3, 2016 at 12:55 AM, Dimitri De Jonghe <dimi@ascribe.io> wrote:

> Thanks for your detailed reply
>
>
>> Tying up liquidity incurs a fee that is freely chosen by the connector.
>> Connectors can create an appropriate pricing policy that prevents liquidity
>> starvation. The subject of fee policies does get fairly involved, because
>> there are many optimizations, but if you want to merely show the overall
>> feasibility of the system, you can imagine a fee policy where the fee is
>> inversely proportional to the remaining liquidity between two assets. In
>> that model lowering the available liquidity by 50% costs twice as much each
>> time. Since transfers time out, the cost of the attack is linear with time
>> as well. Since additional capital is attracted by the increased fee level,
>> the cost of the attack rises over time.
>>
>> In that model, an attacker can succeed in (possibly significantly)
>> increase fee levels at a realistic cost. Using the BAR model (see the
>> Interledger paper) we can say that rational actors (e.g. competing
>> connectors) would not do this attack, because the fees they would earn will
>> always be lower than the fees they would be charged. But Byzantine actors
>> could perform this attack.
>>
>> Indeed, it is clear that connectors will choose their "trusted" set of
> ledgers to create accounts on, as they take most of the risk. The risk in
> turn may be accounted for by incurring liquidity fees and so on. Most
> probably, these fees will be proportional to the unreliability of the
> ledger, hence they are factored out in time by the pathfinder.
>
>
>> Note that we are essentially creating a modular standard:
>>
>> - The bottom layer is the escrow layer. Any system that supports the
>> crypto-condition-based escrow can be made to securely participate in an ILP
>> transaction.
>> - The next layer is the ledger layer. Ledgers should have a consistent
>> API, but can be agnostic as to what type of flow (Universal, Atomic from
>> the paper, Optimistic, etc.) is being used.
>> - The next layer is the connector layer. Connectors do need to know what
>> type of flow is being used (Universal, Atomic, etc.), but don't care about
>> how the path is constructed.
>> - The next layer is the pathfinding layer. Pathfinding
>> (five-bells-pathfind) does need to construct the path, but doesn't care
>> which order that payments are set up, how retries are performed etc.
>> - The next layer is the orchestration layer. Orchestrators
>> (five-bells-sender) does need to have ways to do retries and track the
>> state of the payment, but doesn't care about the use case and how recipient
>> information is exchanged.
>> - The next layer is the use case layer. Applications need a way to
>> exchange the receipt condition, recipient account identifier and source or
>> destination amount, but otherwise don't care about the layers below.
>>
>>
> This is definitely useful for me (and probably other devs). Is there
> somewhere a more formal descriptions of this separation of concerns? Maybe
> a targeted API (functionality, responsibility, ...) per layer could be
> useful...
>