TC3: Balance logic in plugins

[dino-rodriguez]

Ethereum

• [x] Balance logic in ilp-plugin-ethereum
• [ ] Balance logic for Ethereum peering (might be covered in the above case, but no Ethereum links are being used yet, so this is untested)

Lightning/Bitcoin

• [ ] Balance logic in plugin ilp-plugin-lightning (WIP)
• [ ] Balance logic for Lightning peering (same as Ethereum)

XRP

• [x] Balance logic ilp-plugin-xrp-asym-server
• [ ] Balance logic in ilp-plugin-xrp-asym-client
• [ ] Balance logic in ilp-plugin-xrp-paychan

A possible solution to explore is to move the balance logic down to BTP. This would make BTP stateful though, if we want to persist balances.

This should be done before TC2.

[adrianhopebailie]

What is the high-level design here? Is it documented anywhere?

I assume this simply means:

1. Plugins track the balance for an account
2. Connector can be configured to not track the balance (i.e. will never call sendMoney on the plugin and expects to never handleMoney either.)

[karzak]

You're correct on the high level design. This proposal touches on the rational for the design, and it's now implemented in the ETH and BTC plugins.

[adrianhopebailie]

@karzak That's helpful context, thanks.

The design I have been working on in my head looks something like this:

1. Connectors are not configured with a set of predetermined "accounts". Rather, they will be a stand-alone server listening on a port or socket for incoming connections and will authorize these as they are established. The set of allowed accounts and their config can still be a static but more likely it would be in a DB. The goal is that it is possible to change this data without restarting the whole connector.
2. "Plugins" (more like Settlement Engines in this design) will be standalone services (likely one per settlement mechanism, or more for redundancy and scaling) and will be clients to the connector(s).
3. Plugins will be responsible for tracking balances and can therefor each have different strategies for persistence and state management as required.
4. The interface between the plugins and the connector will be BTP (ideally BTPv3 from the start: https://github.com/interledger/rfcs/issues/484) and only be used to exchange ILP packets (i.e. no sendMoney)

The goal here is to reduce the connector to being effectively a router. It might still do some balance/throughout tracking internally to facilitate smarter routing or security but this would not be for settlement purposes.

The plugins will either be "servers" servicing multiple accounts at a single endpoint or host-to-host connections servicing a single high-volume connection to another connector.

Does that make sense and align with the direction you have in mind?