Is the Interledger.js plugin architecture the best way to do blockchain/ledger integrations?
Background: What is a plugin?
A library that connects to a specific type of ledger and handles settlement operations, such as sending payment channel updates/claims or on-ledger transfers. Plugins can abstract away different types of bilateral communication methods and the differences between settlement ledgers.
Note: the term “plugin” has most often been used to refer to part of an Interledger SDK that a developer would bundle with an application, rather than a standalone component.
If you aren’t familiar with Interledger plugins, you might want to look at:
- JS Plugins (the ones for XRP and ETH are most complete as of Feb 5, 2019)
- Past discussions related to the plugin interface (mostly to see that there has been a lot of discussion about this part of the Interledger stack)
Is this the right architecture going forward?
- Abstract away different bilateral communication protocols, such as the Bilateral Transfer Protocol (BTP) or ILP-over-HTTP
- Multiple plugins can be loaded into the same connector instance or moneyd
- Each ledger plugin theoretically needs to be re-implemented in every programming language we want to have SDKs for
- The current design was built for the assumption that Interledger peers would settle every ILP packet using a fast settlement mechanism like a payment channel. This does not scale well to multi-instance connector deployments, where the overhead of signing, sending, and verifying payment channel updates/claims may quickly outweigh the benefits to minimizing bilateral credit risk
- JS plugins currently handle fairly complex balance logic, which also needs to be re-implemented for each plugin
External Settlement Engine
- Only need one implementation of a ledger integration in a single programming language
- Possibly more scalable for multi-instance connector deployments (see the section entitled “Separating Clearing and Settlement” in Thoughts on Scaling Interledger Connectors)
- Need to standardize the API other components will use to trigger or react to settlement events
- Should all settlement engines be expected to expose a common HTTP (or other transport) API?
- Should the settlement engine interact directly with the database (as mentioned in the Thoughts on Scaling Interledger Connectors post)? If so, which databases should we support, or are we going to create an abstraction for the database?
- Disruption to what we’re already doing
We could assume that internal plugins are used only to abstract away message transports like BTP and HTTP and separate settlement functionality into a separate service. If we go that route though, we need to define both APIs.
Another idea worth mentioning was Adrian’s suggestion of sending settlement-related messages inside ILP packets. This would simplify the internal “plugin” API down to a single call that sends out an ILP Prepare packet and asynchronously returns either an ILP Fulfill or Reject packet.