Architecture
Following some discussion on the weekly call and some previous efforts within the Java implementation project it seemed useful to have some kind of big-picture view of the way the various pieces of this project fit together (or at least how they were intended to when we last discussed it). This page is an attempt to capture this, both to explain the purpose of the many components that have been written but also to guide further work in other languages.
In the images below I have used some conventions:
- The dotted line admin boundary indicates that everything inside it is run by a single entity.
- The blue blocks are services/applications running inside that admin boundary.
- The white blocks are "components/modules" within the application/service
- The black arrows non-specific messages
- The colored arrows are messages using a specific protocol
The images are a guide. They are not accurate UML diagrams, class diagrams or anything of that sort they simply map out some pieces of the architecture so that different deployment configurations can be easily compared.
Early on in the project the goal was to define a standard interface for "ledgers" which would abstract away the functions of a particular ledger and expose the functions required of a sender, receiver or connector. Given that the technology of choice for the majority of contributors at the time was Javascript, this was done in Javascript and described in IL-RFC 4 the Javascript Ledger Plugin Interface.
Subsequently a number of Javascript plugins have been developed that expose this interface including:
- ilp-plugin-bells for the reference Five Bells Ledger
- ilp-plugin-xrp-paychan for XRP using Payment Channels
- ilp-plugin-xrp-escrow for XRP using XRP Escrow
- ilp-plugin-ethereum for Ethereum
- ilp-plugin-bitcoin-paychan for Bitcoin using payment channels
- ilp-plugin-virtual for establishing a "Virtual" ledger between two nodes
- ilp-plugin-chain for Chain
- ilp-plugin-lightning for Bitcoin/Litecoin lightning networks
These plugins can be used directly within any Javascript project such as an ILP client or a connector and such a deployment usually looks something like this:
As new implementations roll-out in new languages it is likely that plugin's will be developed for those stacks.
The single-stack/plug-in architecture is limiting in that it is difficult to re-use these ledger integrations in other stacks.
Fortunately we recently we came to consensus on a common wire protocol to use between nodes called the Bilateral Transfer Protocol (BTP). This protocol can also be used as an RPC protocol from a node to a stand-alone ledger adaptor.
This architecture allows for two different deployment scenarios without the need for a "virtual" ledger plugin as there is no assumption that a ledger exists between the two nodes. Rather, if a ledger does exist then an adaptor can be deployed to adapt BTP for that ledger.
This also makes it easier for new implementations to be developed that are not bound to the Javascript interface, but to deploy the Javascript plugins within a ledger adaptor that runs as a stand-alone service and exposes a BTP interface.
New implementations are encouraged to natively support BTP and can run alongside a ledger adaptor such as Frog in the BTP Toolbox which can load ledger plugins as required and wrap these in a BTP interface.
That is not to say that new implementations should not also implement ledger integrations if they wish.
The ideal way to peer two nodes on the Interledger, if they do not share a common ledger that supports conditional-payments, is through a direct BTP connection as follows
This direct model is also appropriate when using payment channels as the two nodes will maintain an internal record of the state of the channel and also a connection to the ledger under-writing the channel.
TODO: Payment Channel Image