Blockchains augmented with an Event based architecture

Receive regular Event Updates

What is it?

Programmable node such as Ethereum and non programmable nodes such as Bitcoin can be transformed into augmented nodes to support an event driven interface

Blockchain and Interblockchain Augmented Nodes

At the core of our technology stands the blockchain Augmented Node. The latter adds an event driven interface to the already bundled request-response interface. At first, at the beginning of our developement, we started with a single blockchain augmented node but, very soon, we came with the concept of a single interface to multiple augmented nodes, the interblockchain Augmented Nodes.

The Interblockchain Augmented Nodes are at the core of our technical strategy. On the one hand, event monitors are monitoring each blockchains, and, on the other hand, event handlers are receiving and processing these events. Events subscriptions and publications are aggregated into a single interface. Hence, on top of the most popular blockchains representing 80% of the total cryptocurrencies capitalization, we transform the current architecture based on request-response into an event-driven one. All this through a single interface. in the following sections we present new possibilities offered by this type of architecture. But above all, this newly introduced architecture simplifies software's structure and reduces development costs.

The Interblockchain Augmented Nodes:
A single interface to several Blockchain Augmented Nodes

The Event Handlers:
Receives blockchains events and transform them into actions

The Interblockchain Event Handlers

Event handlers, after registration to an Interblockchain Augmented node, receive events sent by the unified Interblockchain interface. To do so, the event handlers, at first, subscribe to the event stream with a HTTP-REST POST to the unified event monitor. Event generated by blockchains are sent to each subscribed event handler.

The Interblockchain architecture opens new possibilies to actual blockchains, being programmable (ex: Ethereum) or not (ex: Bitcoin). For example, a payment confirmation event can, trigger an event in a wallet, or send an email to notify about a transaction received, or updadte a merchant's local ledger for accounting, or send a command to the internet of things.

What does it do?

Event handlers register their endpoint to a Blockchain Event Server. When an event occurs in the blockchain, the Blockchain Event Server sends an event message to each subscribed event handler. For the moment, only two types of events are fired:

  • Inclusion of a transaction into the Mempool. This means that the transaction is in the miners queue waiting to be processed.
  • Transaction confirmation. After a certain number of confirmations, a transaction is considered as included into the blockchain.

Use case: Token migration from one blockchain to another

A special case of event handler is a piece of code able to move tokens from one blockchain to another. For example, to move bitcoins from its slow network with expensive fees to a less expensive and a much faster network. Some newly introduced blockchains make the promise of being as fast as Visa or Mastercard.
Thus, a bitcoin can then be moved from the bitcoin network to a faster and more agile network and being incarnated in the latter as an iBitcoin (iBTC). The iBTC is created with the same parameters as Bitcoin, parameters such as a limit of 21 million tokens.

What makes the iBTC to get the same value as Bitcoin

To keep the bitcoin (BTC) value the proxy Bitcoin (iBTC) has to allow iBTC to be redeemed back as BTC. Morevover, it sould allow any iBTC recipiants to be able to redeem back the iBTC as a BTC. For example Alice move some BTC to the alt blockchain, because EOS made the clainm to be as fast as Visa and because the early results show it is a lot faster than Ethereum, let's say that Alice move her Bitcoins to the EOS network. Shen then spend some of it to buy shoes in an online store and buy a new tablet, again, online. Now, two (2) merchants possess iBTC. They can redeem back their iBTC to the original Bitcoin network and get their BTC.

Use case: Blockchain payment and the internet of things

More and more, new intelligent devices are entering the marketplace: camera remotely controlled, home automation managed by mobile applications, etc. Most of these devices are, in fact, small web servers or, to be more precise, HTTP servers offering a REST programming interface. This type of interface allows these devices to be managed and controlled remotely on the internet. Among these devices, intelligent locks. These locks are small REST services able to receive requests to set a PIN people can enter on a small keypad. This PIN is active for a limited period of time. The main usage of this intelligent lock would be for a renting application to receive a payment in cryptocurrency and when this payment is finally confirmed, set, remotely, an intelligent lock for a temporary tenant.

How is this working?

Bob, owning some cryptocurrencies, browses a renting application and sees a nice place to rent for a well deserved vacation. Alice likes it too. Bob and Alice seduced by the location decide to rent the appartment for 2 weeks. They pay with one of the cryptocurrencies supported by interblockchain. For the moment, this could be either Bitcoin, Bitcoin cash, Bitcoin Gold, Litecoin, Ethereum, Ethereum classic. Which, like we said earlier, represents approx. 80% of the total cryptocurrencies capitalization. The address associated to Bob and Alice payment is monitored. This leads to a stream of events fired by the interblockchain Augmented Node and received by the renting application event handler. The application receives the different transaction states occuring during the transaction confirmation process. When a final confirmation event is received by the renting application event handler, it prepares the required JSON object and sends it to the remote intelligent lock. It also send an email to the renter. The JSON object contains the needed information to let the renter unlock it with a PIN valid for a limited period of time. Bob and Alice get an email with the PIN required to enjoy their vacation. Bob and Alice are happy, they found a way to to do something concrete with their cryptocurrencies. But above all, they are very happy to take some vacations in such a nice place.

How is it different from IOTA?

IOTA is a different shared ledger network and it is not a blockchain, it is a Directed Acyclic Graph (DAG). For the moment it doesn't include any smart contract facilities or a mean to execute code to trigger an action in the real world. In its present conception, it stores data, it doesn't control an internet of thing device like we described in the previous paragraph. IOTA stores data. In contrast, the interblockchain system can trigger real world actions like, for instance, connect and set the parameters of an intelligent lock. Moreover, the interblockchain system works with actual blockchains and it can also works with DAG networks such as IOTA.

Use case: Payments on a blockchain

Payments on a blockchain are not so hard even if it seems complicated for new users. Usually, an address is provided by the receiver of funds and the payer sign a transaction to send theses funds. However, behind this appearant simplicity lays several things that need to be set up before.

  • In the case of Bitcoin and Bitcoin like networks, because a transaction can consist of more than one input, it is very hard to know from who or from which address this transaction comes from. A current practice is to create a new address for each transaction from a deterministic heriarchy. This type of structure is made of a hierarchy of public addresses all linked to a single private key.
  • The fund receiver, especially if this reciver is a merchant, needs an accounting recording system. Each transaction needs to be recorded. Usual accounting system are based on a ledger-journal structure. Transactions are recorded into a journal and summarized into a ledger. Transaction are considered as attached to an account receivable ledger entry. They stay as receivable as long as the transaction is not confirmed. When the transaction is confirmed, it then considered as received and recorded as a sale or anything similar.
  • And the least, any accounting system need reporting. If possible a reporting system versatile enough to be able to answer queries.

Use case: Token Exchange

Token doesn't worth the same value on the market. Their value is determined by over the counter (OTC) transactions or by exchanges. In the case of exchanges, the market dynamics of the supply and demand leads to a conversion ratio between a pair of token.

The payment system, which includes a ledger can also be used for an exchange if an order book and a matching engine is added in front and interacts with the Interblockchain ledger. The system workflow would be as follow for a custodian exchange:

  • A user transfer some token to an exchange account
  • The augmented node catches the event and send a payment confirmation event to the ledger. The ledger has now some funds recorded. Two options are possible.
    • The ledger connected to the augmented node is used to record matching order transactions.
    • The ledger connected to the augmented node is separate from the ledger used to record the matching order transactions. Obviously the simpler system is when the ledger attached to the augmented node record the transactions. However, for security purposes, it may be better to separate these two ledger and sync them with a secure communication.
  • The order book records orders and the matching engine matches the bids and the asks. When a match occurs, a transaction is recorded into the ledger. Each account gets a transfer of tokens in their respective ledger account.