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

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