Disclaimer: Please note this article was accurate to the best of my knowledge at the time of writing. This information should not be used as a reference source to make any investment decisions (as is the case with all my articles). The Quant team have removed multiple references surrounding tokenomics of the QNT token, including the original tokenomics paper, the Overledger Network for community paper (which you can find an copy on a 3rd party side here ) and archive of removal of medium articles written by Quant surrounding tokenomics can be found here). For clarification around any topics you should seek clarification from other sources rather than rely on any information found in this article.
In 1973 Vint Cerf invented the protocol that rules them all: TCP/IP. Most people have never heard of it. But it describes the fundamental architecture of the internet, and it made possible Wi-Fi, Ethernet, LANs, the World Wide Web, e-mail, FTP, 3G/4G — as well as all of the inventions built upon those inventions.
So we had multiple networks, in his formulation, all of them packet-switched, but with different characteristics. Some were larger, some went faster, some had packets that got lost, some didn’t. So the question is how can you make all the computers on each of those various networks think they are part of one common network — despite all these variations and diversity.
That was the internet problem.
Sound familiar? Distributed ledger technologies currently face the same problem of running in isolated silo’s. How can you connect all these different blockchains, regardless of what consensus mechanism they use, whether they are permissioned (Hyperledger, Quorum, Corda etc) or permissionless (Bitcoin, Ethereum, Ripple etc), fast or slow, blockchain or DAG (like IOTA) or any future blockchains so that they are part of one common network despite all the variations and diversity?
Wired: So from the beginning, people, including yourself, had a vision of where the internet was going to go. Are you surprised, though, that at this point the IP protocol seems to beat almost anything it comes up against?
Cerf: I’m not surprised at all because we designed it to do that.
This was very conscious. Something we did right at the very beginning, when we were writing the specifications, we wanted to make this a future-proof protocol. And so the tactic that we used to achieve that was to say that the protocol did not know how — the packets of the internet protocol layer didn’t know how they were being carried. And they didn’t care whether it was a satellite link or mobile radio link or an optical fiber or something else.
We were very, very careful to isolate that protocol layer from any detailed knowledge of how it was being carried. Plainly, the software had to know how to inject it into a radio link, or inject it into an optical fiber, or inject it into a satellite connection. But the basic protocol didn’t know how that worked.
And the other thing that we did was to make sure that the network didn’t know what the packets had in them. We didn’t encrypt them to prevent it from knowing — we just didn’t make it have to know anything. It’s just a bag of bits as far as the net was concerned.
We were very successful in these two design features, because every time a new kind of communications technology came along, like frame relay or asynchronous transfer mode or passive optical networking or mobile radio‚ all of these different ways of communicating could carry internet packets.
We would hear people saying, ‘The internet will be replaced by X25,’ or ‘The internet will be replaced by frame relay,’ or ‘The internet will be replaced by APM,’ or ‘The internet will be replaced by add-and-drop multiplexers.’
Of course, the answer is, ‘No, it won’t.’ It just runs on top of everything. And that was by design. I’m actually very proud of the fact that we thought of that and carefully designed that capability into the system.
This is the approach Quant have taken with their Blockchain OS, Overledger to solve Blockchain interoperability. Compared to other Interoperability platforms that are trying to achieve interoperability at the transaction layer by connecting two blockchains via another blockchain, these will be ultimately be made redundant once faster methods are released. Overledger is designed to be future proof by isolating the layers so they don’t care which blockchain is being used, what consensus method etc, each layer is only interested with the data within that same layer. Just as the Internet wasn’t replaced by X25, frame relay, APM etc, Overledger is designed to be future proof as it just runs on top of the Blockchains rather than being a blockchain itself. So, if a new blockchain technology comes out that is capable of 100,000 TPS then it can easily be integrated as Overledger just runs on top of it.
Let’s Dive a bit deeper into the different Layers of Overledger:
Transaction Layer:
This layer stores transactions that are appended, stored or queued on the ledgers. All transactions executed in a specific blockchain are only valid for that ledger. A bitcoin transaction is not valid on the Ethereum network for example and even when some ledgers share the same protocol such as Ethereum’s Main net and Test Net, a transaction on the Ethereum Test Net is not valid on the Ethereum Main Net. Therefore, this layer is represented by different and isolated ledgers and is represented in the image below with each being a different colour.
This layer includes Thin Clients, Full Nodes, and all the operations needed to reach consensus in different blockchain domains to append the transaction to the ledger.
Messaging Layer:
This is a logical layer which extracts all the information about the transactions and messages digests from every single ledger in the Transaction Layer. Information can be transaction data, smart contract or metadata (such as a digest of messages of out-of-chain messages, which i will explain in more detail later in this article). Whereas the transaction layer is split into individual ledgers, the messaging layer is a shared channel where transactions from all ledgers are stored. As the information about the transactions is encapsulated the transaction layer is not aware of the contents of the Messaging layer and so it allows all transactions from all ledgers to be put together.
One of the main challenges of creating a truly scalable, interoperable DLT system that is flexible enough to be adopted for different technological uses is to be able to handle the large amounts of data involved. To that end we have created an adaptable messaging system that has the capability to handle large amounts of data across multiple nodes. The messaging system we have created utilises standard technologies which can be easily integrated into existing systems. This will standardise the back-end technology required to build truly internet scalable applications
Filtering and Ordering Layer:
This layer filters and orders messages from the Messaging layer that are referenced through the digest of out of chain messages. This layer is also responsible for checking that the message meets the application schema and its requirements. For example, an application may accept only transactions from/to a particular address or may need a certain amount of coin to be moved for them to be valid.
It’s basically like each MAPP has a virtual blockchain that takes transactions from all the various ledgers (compared to having to deal with isolated ledgers in the transaction layer) that are referenced via a digest of out of chain messages from the messaging layer and orders them into virtual blocks, known as Verification blocks. There is no order among transactions in the same block and each block can contain messages from different blockchains. The genesis block (first block in the Mapp’s virtual blockchain) contains all the applications configurations / rues on how it is to interact with Overledger. These are configured via the BPI in the application layer.
So let’s take a very basic example say i have a MAPP that is a marketplace that sells Chairs. I have a treaty contract (Multi chain smart contract) when a customer buys a chair with Bitcoin (BTC) it will automatically pay my supplier for the Chair in Ethereum (ETH) and also Send some Ripple (XRP) to the delivery company to deliver the chair from the supplier to the customer.
Bob buys a chair with BTC, once that has been confirmed then ETH and XRP are sent. So the BTC transaction has to happen before the ETH and XRP Transaction. Yet both the ETH and XRP transactions can happen simultaneously
Each user interaction with the MAPP isn’t processed one after another they are processed in parallel for scalability. Also worth noting that with the 2nd block all 8 transactions (4 ETH and 4 XRP) are sent simultaneously.
As other interoperability platforms route the data over the blockchain via a connector they are restricted to only allowing interoperability with 2 blockchains at the same time and are far more restrictive in their approach. Overledger can do operations across multiple blockchains simultaneously without the need for any connector, so doesn’t matter ultimately which currency is used to receive or pay the suppliers / delivery companies for the chair.
If you recall from part one article i explained how the blocks are chained together in a blockchain by adding the Digest (Hash) of the previous block in addition with all the transactions in the new block and then putting it through a hashing function to create a digest for the new block. This is what happens with the Verification Blocks as well. A hash pointer to the Verification Block is then written to the blockchains that form part of the application. The Verification Block is keeping the order across all chains involved in the application of hashes which have been appended after the consensus has been reached.
The Verification Block solves one of the key challenges of creating MApps, namely letting the application determine whether a block has been committed on another chain. For instance, if the application commits a block to the wrong side of a fork and that particular fork is not accepted as part of the consensus mechanism, the Verification Block can detect and prompt the application to take action.
After a given interval the application then re-scans the blockchains involved back to the Verification Block. Any new compliant transactions which have been appended to the blockchains that are part of the application are then appended to the Verification Block, which is updated on the blockchains involved and the process repeats.
Application Layer:
In this layer each Multi-chain Application is isolated from each other and contains the business logic which is independent from the lower component. The MAPP updates the state of the application from the messages from the Filtering and Ordering layer that are specific to the MAPP and have been validated. So for example the state would be updated to reflect the 4 Chairs that were purchased and funds sent to suppliers, delivery company etc.
Multi-chain applications which want to use Overledger will need to define two sets of (mandatory and optional) rules. These rules determine how to interact with the Overledger system and with other users/applications. The application layer takes responsibility for all the other layers by defining the rules and how to interact with the blockchains. Treaty contracts will run in this layer to allow smart contract functionality across multiple blockchains (even for those like BTC which don’t have smart contract functionality)
Applications have the chance to communicate with each other by putting messages on the Messaging Layer. If these messages are compliant with the filtering rules of the other application, they can flow through the Filtering and Ordering Layer to the Application Layer.
So a quick recap:
The transaction layer stores the transactions added to a blockchain and all the relevant components for the blockchain to reach consensus. Each ledger is isolated.
The messaging layer takes the transaction info from the transactions in the transactions layer and places them into the messaging layer (which is shared)
The filtering and ordering layer takes the messages from the messaging layer and filters them based on the rules defined by the MAPP in the application layer and orders them into virtual blocks called a verification block (which the hash of the verification block is written to all the blockchains involved in the transactions)
The application layer takes the messages from the filtering an ordering layer and updates its state. It also defines the rules for how the other layers operate and how to interact with the blockchains. Each MAPP is isolated in this layer.
But Overledger itself is not a blockchain so how can it be trusted? some of you may ask. That’s what i will explain in my next article to show that through the use of cryptography, without restricting the developer to use a single blockchain to provide interoperability and performing complex tasks off chain whilst still having the benefits blockchain brings will enable mass adoption of Distributed Ledger Technology.
Part One — Blockchain Fundamentals
Part Two — The Layers Of Overledger (This article)
Part Three —Verification and the Tokenisation of data
Part Four — Features Overledger provides to MAPPs
Part Five — Creating the Standards for Interoperability
Part Six — The Team behind Overledger and Partners
Part Seven — The QNT Token
Part Eight — Enabling Enterprise Mass Adoption
Value Beyond Speculation — Why Quant has the potential to be an incredible long-term investment
Quant Network Enabling Mass Adoption of Blockchain at a Rapid Pace
Large Enterprise Adoption of Blockchain is happening, enabled by Quant Network’s Overledger
