Category: Tenx (PAY)

A Q3 UPDATE ON COMIT: HOW TO ROUTE THROUGH A NETWORK OF BLOCKCHAINS

Julian Hosp, Co-founder and President at TenX

After our successful token sale in Q2 of 2017 and our roadmap for the upcoming years, I wanted to give you an update in Q3 on what our progress at TenX has been on COMIT so far. Most of the team’s focus after the token sale has been on developing the TenX product, adding currencies, scaling operations and securing partnerships. Since our plan is to have a basic version of COMIT to test on out in Q4 and a working system in Q1 2018, we have around a few people on the project itself already and planning on adding way more until the end of the year.

COMIT protocol by TenX

In this article I will focus on a rather high level view, while we will be publishing a paper a bit later this year to lay out some of the specifics.

If you haven’t read about COMIT, I would highly recommend you read the official whitepaper that I co-authored in 2016, read these 2 blog posts and watch a video on it:

  • Why connecting all blockchains is the key to mass adoption
  • 3 technical requirements to connect blockchains without a token

90-minute presentation on COMIT:

For this update, I will assume you understand the contents of the listed articles and video.

For COMIT to go live and be ready to be mass used, 3 crucial things need to be solved:

  1. Definition of the routing protocol
  2. Price Discovery
  3. Liquidity

We are pretty confident we have solutions to all 3 of them, so let me show you how they work.

ROUTING

The process of routing defines how a transaction finds a path through a network from node A to B via an arbitrary amount of intermediate nodes. In the Internet, it is for example the process of how your browser finds the information of the website you just tried to open. How this works in COMIT is defined by the CRP — the COMIT Routing Protocol.

Routing protocols can be classified in several different categories. For now, we focus on decentralised protocols only:

  1. Proactive Routing
  2. Reactive Routing
  3. Hybrid Routing: A mix of 1 and 2

Option 1 is Proactive Routing. The routing protocol Flare which is used in the Lightning Network is based on this type of routing.

Within this routing category, each node maintains its own local routing table which contains the information of adjacent nodes (i.e., nodes it has a channel to). This information is PROACTIVELY broadcasted to its neighbours in a regular interval or whenever new information is available. Hence, if a node A wants to send money to node D it can look up the routing path in its local routing table.This is an illustration from a Lightning Network whitepaper:

Source: http://bitfury.com/content/5-white-papers-research/whitepaper_flare_an_approach_to_routing_in_lightning_network_7_7_2016.pdf

This form of routing has 3 excellent upsides that are crucial to a successful network:

  1. Speed
  2. Security
  3. Cost

It would also allow for something called Onion Routing, meaning that only the first and last node actually know who has been sending something to whom, while all the intermediate nodes just forward it to the next. There is more privacy in such a system, however it has been shown that in cases where every node broadcasts the transaction onto the blockchain in similar timeframes, clues of the routing can be deducted by the entire network.

The major downside of such a proactive routing protocol is its limited scalability. Since every node needs to know all the other nodes, there are certain limits. In the Lightning Network whitepaper, they estimate it at around 100,000 nodes, which is quite impressive, but considering that we will probably have trillions of things connecting into such a network (humans and machines together), it might be a great start but rather a small drop onto a hot stone.

Option 2 is Reactive Routing of which a prominent example is Ad hoc On-Demand Distance Vector (AODV) Routing.

In such a system, no node has an overview of a “perfect” network but simply tries to trust its surrounding “neighbours”, who then trust their “neighbours” and so on. Such a protocol consists of 2 main functions: route discovery and route maintenance.

At an initial glance, such a system might appear to be super slow, prone to attacks and quite confused, as the number of possibilities to get from 1 point to another would be n^n, where n is the number of nodes.

Source: https://www.ijser.org/paper/Survey-on-Proactive-and-Reactive-Protocols-in-MANETs.html

However, when adding a few mechanisms to adapt some functionalities, such a reactive system could have great upsides, especially when talking about flexibility and adaptability. That is also why such reactive networks are being used for so called mobile ad hoc networks (MANET), which are continuously self-configuring, infrastructure-less network of mobile devices connected wirelessly.

So how could this be achieved? By combining benefits of option 1 and 2, while NOT BEING CENTRALISED as many other solutions have suggested, but rather by setting certain rules that each node can then apply. Effectively we are talking about reputation management. If every node knows the reputation of every other node and understands who to trust and who not to trust, none of this would be necessary. Since that is not the case and we have to assume the existence of malicious nodes, we have to find solutions for:

  1. Spam / Flood protection
  2. Number of Maximum Hops
  3. Channel Opening Times

SPAM / FLOOD PROTECTION is there to avoid malicious nodes to send or forward endless requests into the network, which would flood the network and cause it to clog up. Bitcoin uses mining fees as a spam protection, IOTA’s tangle uses nonce-calculations and systems like the Interledger Project by Ripple assumes perfect knowledge, similar to Lightning. For COMIT we did not want to use any of these, as there are attached downsides we did not want to have.

So we were conceiving a more dynamic spam protection, which would work in 2 parts:

  1. Forwards
  2. Backwards

In a forward spam protection, a node sends a certain number of requests to any given node and if it notices, that these requests never reach their final destinations, it stops sending requests to that node after a certain amount of attempts within a certain time frame. For example, if it tries 100 times within a minute and nothing happened, it stops talking to that node for an hour. Then it starts trying again and if it does not work either, it stops talking to it for a day and if it then tries again and it still does not work, it stops talking to it for a week. After 4 or 5 of such rounds it would completely stop talking to such a node as it could assume either the other node itself, or the network it is part of, is malicious.

In a backward spam protection, the same applies, just in regards to how many requests any node receives from any other nodes. If it receives a hundred requests within a minute but never a true payment, it stops talking to that node for an hour and so on.

With such a dynamic spam protection, the network could grow and shape its form over and over again, while learning whom to trust and whom not to trust.

In addition to such protections, a MAXIMUM NUMBER OF HOPS will be implemented, where after this number is surpassed, the route discovery stops and returns a fail. This means, it was not possible to find an adequate route from a sender to a receiver (despite of abiding to the spam protection rules).

This would avoid endless searches and excessive flooding that pile up and start clogging the system. For example, in the Internet the maximum TTL (time to live) is 255, however most recommendations go towards 64. With more experience in COMIT, we will be able to improve and adapt such a hop limit over time so that payment requests can be sent and die out at an optimum level.

The third feature is ADEQUATE CHANNEL OPENING TIMES. When connecting hashed time-lock contracts (HTLCs) the time-lock (maximum time a channel stays open) of an upstream channel (closer to the sender) has to be longer, than that of a more downstream channel (closer to the receiver), as otherwise the sender could collapse the channel and steal the funds before they ever arrive at the receiver. This number is tightly connected to the hop limit, as it would go down by 1 from one node to the next:

Combining all these 3 features of spam protection, hop limit and channel opening times and adding them to a reactive not only proactive network, is the key to an effective COMIT Routing Protocol (CRP) that is not only highly effective in price, cost and speed, but can also withstand DDOS attacks. We have been working extensively on the definitions and we will release the exact terms of the CRP in Q4 2017, but for now we mostly wanted to explain what the thinking was that went into all that.

Aside of the routing, the second piece of the puzzle to solve is that of PRICE DISCOVERY:

  1. What are the exchange rates?
  2. What are the fees?
  3. What is the optimal route?

Obviously a lot of that is tightly connected to the CRP, however there are a few extra thoughts that go into proper price discovery:

The initial number of “pings” or attempts to find a route is automatically optimised due to a spam protection. Therefore, a sender cannot try every route. Most nodes in the network however, will have “learned” the most optimal route for price, speed and security over time.

This knowledge allows for good “price comparison” and therefore for price discovery over time. Initially this time might take a bit, but the more sophisticated the network gets, the faster price discovery can become.

In theory, COMIT can live without fees, however it is up to the nodes to charge a small fee to act as a hop. These nodes thereby are in competition and an equilibrium will be found quite fast. Since such a network is not centralised, the price movement would not be as fast as a centralised network and constant arbitraging balances out price differences.

Just like traditional ETFs (Exchange Traded Funds) get stabilised through arbitrage, such functionalities within COMIT would lead to stabilise prices of cryptocurrencies as a whole. Price movements would still be possible, but crazy peaks or lows would start to disappear. This will have a positive effect on the reputation of cryptocurrencies as a means to store value and would therefore lead to more cryptocurrency mass adoption.

The third and last piece to COMIT is LIQUIDITY in the network. Payment Channels need to be filled with currency in order for one node being able to forward a payment to the next. Initially we see us at TenX as a main liquidity provider. Part of the reason why we received contributions of around 200,000 ETH during our token sale in June 2017, was exactly to being able to provide this initial liquidity and we feel confident we are capable of doing so. It is fair to assume however that quite rapidly, others, who intend to put their stored cryptocurrencies to use, will join force and the network’s liquidity will increase exponentially.

The rough timeline going forward is still the same as laid out in the original whitepapers, so I just want to highlight a few of the important key points:

  • Q2 2017: TenX tokensale
  • Q3 2017: Forming together a “COMIT team” (Join us, if you are interested!)
  • Q4 2017: Releasing the COMIT Routing Protocol and provide first libraries
  • Q1 2018: First Decentralised Exchange based on COMIT with TenX serving as a liquidity provider (LP)
  • Q2 2018: Small multi-hops between major blockchains possible / other LPs join
  • Q3 2018: More complex multi-hops possible / CRP gets further optimised
  • Q4 2018: Offering complete access to COMIT that gets optimised on an ongoing basis

We at TenX believe that blockchain technologies and cryptocurrency payments are the way of payments in the future. In order to make such payments possible for all consumers with maximum convenience, it is our mission to connect blockchains in the background through COMIT in the most agnostic way possible while offering the user an easy-to-use plug-and-play interface on the frontend, so she has instant access to any of her blockchain assets at the touch of a button.

In the long run, it is our vision for COMIT to become the financial rails that are connecting literally any financial asset. Then, any asset on any blockchain, be it real estate, gold a cryptocurrency or anything else, to be as spendable as a $100 bill in your pocket and by you being able to pay, without having to think of how you actually paid, because you know, that the payment provider took care of it for you by running all its services on COMIT in a machine-learning type manner.

If you are interested in working on changing the world with us, join the COMIT core team, drop us an email at [email protected] and include your CV and GitHub profile. Show us your strong “tech-architectural” background in Rust, research capabilities or experience in network-style aspects and we would be glad to call you as part of our team.

TenX is a Singapore-based Blockchain company that makes any blockchain asset spendable instantly by offering a debit card payment system to its users on the frontend and by connecting any blockchain at the backend through COMIT.

COMIT is an open source project that connects any blockchain without creating an extra token. Whitepaper: www.comit.network

For regular updates

Follow TenX on Facebook
Follow TenX on Twitter
Subscribe to the TenX subreddit
Subscribe to TenX on YouTube


A Q3 UPDATE ON COMIT: HOW TO ROUTE THROUGH A NETWORK OF BLOCKCHAINS was originally published in TenX on Medium, where people are continuing the conversation by highlighting and responding to this story.

This article was originally published on: The TenX Blog on