Settlement Architecture

[adrianhopebailie]

Based on comments from @ekrenzke, @kincaid and @austin_king both here and on the other Ledger Adapter Interface thread, I think we should not try to abstract the Settlement Engine → Ledger Adaptor interface.

1. It’s complex and the complexity is probably not warranted at this time
2. It’s hard to get the abstraction right
3. Worst case scenario is that some code is re-used between different ledger specific settlement engines and this is extracted into stand-alone libraries

As I said on that thread I’d advocate for standardising on the interface I proposed above as:

@adrianhopebailie

Settlement Engine → Connector

• getBalance (get the current balance of the clearing account, i.e. ILP balance)
• setBalance (update the current balance of the clearing account, apply a delta)
• sendData (send a message to the Settlement Engine on the peer)
• receiveData (accept a message from the Settlement Engine on the other peer)

This can be optimised (now or when it’s deemed to be required) by supplementing getBalance with a subscribeToBalanceChanges that allows the SE to get a stream of balance updates from the connector instead of polling.

I am confident that concerns about the volume of updates that will be sent can be alleviated using a debounced stream however I think this is a premature optimisation.