Interledger is an open protocol suite for the exchange of payments
across different ledgers (banks, blockchains, crypto currencies, etc.). It is a
standard way of bridging financial systems. Like Internet Protocol (IP), it
routes “packets of money” across independent payments networks. The Interledger
architecture consists of three types of nodes, a sender, a receiver, and a
connector. As their names suggest, the sender initiates a payment request for
the receiver, and the request is routed through various connectors.
The Interledger protocol suite is divided into
layers of protocols each with different responsibilities. The Ledger protocols
represent the existing money systems that Interledger connects to. The
Interledger Protocol (ILP) is the core protocol of the entire suite. Its
packets pass through all participants in the chain, from the sender, through
the connectors, to the receiver. ILP is compatible with any type of currency
and underlying ledger systems. The Transport layer protocols are used for
end-to-end communication between senders and receivers. The protocols at the
application layer communicate details outside of the minimum information that
is needed to complete a payment.
The protocols used in the Transport and
Interledger layers are specified in ASN.1, a standardized syntax notation to
define message structures and encodings in a platform-independent way.
Interledger messages are encoded according to the ASN.1 Octet Encoding Rules
(OER). Using ASN.1 to define and encode protocol messages allows Interledger
applications to interoperate irrespective of their choice of platform and
programming language. OER encodings are simple, compact, and very easy to
parse. ASN.1 tools - commercially licensed as well as open source - are
available to assist with implementation.
Interledger uses advanced features of ASN.1 to
make future upgrades of the protocols extremely easy to incorporate and fully
backward compatible. For example, if Interledger adds another message type to BilateralTransferProtocolPacket (see the ASN.1 excerpt below), they will
only need to define the message and add it to CallSet, without worrying about backward compatibility.
CALL
::= CLASS {
&typeId UInt8 UNIQUE,
&Type
} WITH
SYNTAX {&typeId &Type}
CallSet
CALL ::= {
{1 Response} |
{2 Error} |
{3 Prepare} |
{4 Fulfill} |
{5 Reject} |
{6 Message} |
{7 Transfer} |
{8 NewMessageType}
}
BilateralTransferProtocolPacket
::= SEQUENCE {
-- One byte type ID
type CALL.&typeId
({CallSet}),
-- Used to associate
requests and corresponding responses
requestId UInt32,
-- Length-prefixed main data
data CALL.&Type
({CallSet}{@type})
}
NewMessageType
::= SEQUENCE {
-- Add message fields here
}
The OSS ASN.1 Tools can be used to implement the
Transport and Interledger layer protocols. The Interledger ASN.1 specification
is passed to the ASN.1 compiler to generate programming language specific
structures or classes. The compiler generated code along with the high
performance OSS ASN.1 runtime libraries are used to create applications for
the sender, the receiver, and the connectors. ASN-1Step, a GUI based
product, can be used to view, create, and modify Interledger messages.
The OSS ASN.1 Tools include a sample Interledger
program which demonstrates how the implementer of Interledger Bilateral
Transfer Protocol (BTP) can use the Tools to serialize and parse BTP messages.
The sample simulates the communication between two BTP peers and implements two
scenarios, a) a payment request is successfully processed, and b) a payment
request is rejected because it’s expired.
Please visit OSS website to find more
information about the OSS ASN.1 products, to download a trial, and/or to access the
online documentation. If you have any
questions about using the OSS ASN.1 products in Interledger applications,
please contact info@oss.com.
No comments:
Post a Comment