Quant Network recently released the Overledger Network Community Treasury Design paper which compliments the Overledger Network Whitepaper. In this article I will discuss the community treasury design and how it will add additional utility to the QNT token and facilitate the launch of Overledger Network, a horizontally scalable decentralised trusted Network of Networks connecting all DLTs (permissioned, permissionless, current and future) as well as existing networks. Where anyone will be able to run a node and contribute and be rewarded with transaction fees in QNT.
Summary:
The community treasury is a Multi Chain Application (MAPP) operating in a trustless manner with the use of Layer 2 unidirectional payment channels. This enables scalability for payments for transaction fees in QNT with the vast majority of transactions being performed off chain instantly, with only minimal transactions being done on chain such as the opening and closing of channels and random reconciliations). This means despite QNT being a ERC20 token it doesn’t matter about Ethereum’s low tps or high ETH fees.
In addition to the already extensive list of utility the QNT token benefits from as detailed in the Quant Network Utility paper and David’s article here, this utility will be increased further with the community treasury where more QNT will be used / locked in payment channels, further reducing circulating supply:
• There are deposits for Users (to pay fees) as well as small deposits to cover against raising incorrect disputes.
• Gateways operators must have a minimum deposit to join the network which is a license fee (and will be much lower than the original 500 QNT that was planned). They also have a variable deposit where the operators choose how much to stake (which unlike the license fee is returned providing the gateway doesn’t act maliciously / faulty behaviour). The more that is staked the more requests the gateway is authorised to handle. If the gateway returns faulty data / malevolent behaviour, then the deposit gets slashed as punishment to incentivise correct behaviour.
The community treasury design has the benefits of staking where more QNT is being used / locked up in funding payment channels and used for fees paid to gateways increasing demand and reducing circulating supply of QNT, but importantly without the usual major disadvantages associated with staking with proof of stake blockchains, where the rewards and just created by minting new tokens via high inflation increasing supply and diluting existing token holders, which I discussed further in a previous article here.
With QNT there is no inflation, no new tokens are minted, the increase in demand for QNT will need to be purchased from the existing supply of tokens (circulating supply will also reduce as more QNT is locked in payment channels / staked in addition to Enterprise/Community licence fees to access and use the Overledger software). Those that don’t want to run a gateway aren’t punished through dilution of the tokens (in fact everyone benefits from the increased utility demand in QNT) and those that do choose to run a gateway can benefit from additional revenue in QNT from processing functions which they could then use those rewards to further increase the amount of QNT they stake to process even more transactions.
An extremely exciting functionality has been added and will be a breakthrough for the distributed ledger domain with Overledger Network providing a method to establish trust between users not running a node and parties running nodes providing a crucial missing piece in full end to end trust. This is achieved through a game theoretic approach to establish trust where the community treasury allows a user to ask multiple gateways to compute the same function or a corresponding function Check. This approach means that economically rationale gateways will act truthfully, whereas malicious gateways will be slashed and removed from the Overledger Network quickly, enabling users to trust the results provided without running a node themselves, or having to trust a single provider such as Infura who potentially may return faulty information.
The ability for a user to query multiple gateways for functions could also be used for decentralised oracle functionality but also the platform offers huge potential for the likes of Chainlink to be built as a MAPP on Overledger enabling decentralised Oracle functionality to all connected blockchains through Overledger Network whilst benefiting from the layer 2 payment channels for fees (which this benefit could potentially extend to payments to other MAPPs with their own ERC20 token for use with their specific MAPP as well as QNT being used for the underlying Overledger Network fees.)
The Overledger design opens up for so many possibilities, with a few potential examples only scratching the surface below:
- Micropayments from IOT devices to interact with MAPPs utilising payment channels for scalable, low fees as well as integration with Point of Sale systems for instant payments etc.
- Many more projects to be built as MAPPs benefiting from interoperating with multiple blockchains as well as offchain networks and utilising payment channels for fast, cheap payments.
- Along with treaty contracts using Quant’s atomic swap capability this also provides additional functionality for DEXs to be built on Overledger Network
- Offering Treasury-as-a-Service to projects
- Potentially enabling gas fees to be paid by users in QNT to the treasury which is then converted to other tokens as required
A more detailed look at the Community Treasury Design:
Overledger Data Standards
The Overledger Network relies on data standards so that all stakeholders in the network “speak a common language” and inconsistencies in responses can be detected. This data standard is known as the Overledger Data Standard. By having a data standard, data object instances can be compared of the same object type to determine if they are equivalent and confirm the output enabling these to be compared against other gateways enabling a game theoretic model which disincentivises malevolent behaviour and provides trust.
Functions
Users can request functions to be computed by Overledger Gateways. Each function takes as input a data object instance of a specific data object type and returns as output another data object instance of another specific data object type. Functions are organised into four main sets:
1. Private — contains all the functions that use private gateway data, e.g. GET Licence.
2. Compare — contains all the functions that do not use private data and the results from different gateways can be compared for verification purposes, e.g. GET Transaction.
3. Check — contains all the functions that do not use private data but a different function is more appropriate to use for verification purposes, e.g. POST Transaction should be verified not by calling the same function on another gateway but instead by calling GET Transaction.
4. Multi — contains functions that do not utilise private data of an Overledger gateway and do not utilise the current state of a distributed ledger with probabilistic finality. This is the set of functions that we can create multi-gateway payment contracts over.
Creating end to end trust
Distributed ledger networks provide a method to establish trust between different parties where they each run blockchain nodes and can verify transactions providing trust. Despite this, many developers do not run their own blockchain nodes and instead rely on a small number of providers such as Infura and Etherscan in the case of Ethereum for interaction with the Blockchain through their API. Without the end user running a node themselves how do they know if Infura / Etherscan start returning faulty data? Or with permissioned DLT’s where the end user isn’t able to run a node and verify transactions how can they really know that the data the stakeholder returns actually comes from the DLT?
With multi-gateway payment contracts, users not running a DLT node can ask multiple gateways to perform a request where the responses will be compared for verification purposes. Therefore, not only do distributed ledger networks provide a method to establish trust between different parties running different nodes, but the Overledger Network will provide a method to establish trust between users not running a node and parties running nodes providing a crucial missing piece in full end-to-end trust.
This is achieved through a game-theoretic approach to establish trust where the community treasury allows a user to ask multiple gateways to compute the same function or a corresponding function Check. The different gateways are then essentially placed in competition, each correctly responding gateway will be rewarded with a fee, each non-responding gateway will not be paid and each gateway incorrectly responding will be penalised. Gateways are further incentivised to be truthful as the penalty fee from gateways returning incorrect results will be moved to the gateways returning truthful results. This approach means that economically rational gateways will act truthfully, whereas malicious gateways will be slashed and promptly removed from the Overledger Network. This game-theoretic approach is enforced by the treasury and implemented through multi-gateway payment contracts.
Users
Users will each need to deposit an amount of QNT that will be used to pay fees to gateways for processing functions. This deposit will be used to fund a payment channel between the user and the community treasury. Any fees that haven’t been spent when the channel times out / is closed will be returned to the user.
The user also has to deposit a small amount of QNT to cover the cost of any penalties for raising incorrect disputes. This dispute deposit is not expected to be large but is used to disincentivise a user from raising many unnecessary disputes and is returned if no unnecessary disputes are raised.
When a user interacts with the Overledger Network it needs to have decided:
• What function to request be performed from gateways
• What data object instance to pass to the function
• What is the maximum response time for the gateway to return the value from performing the function
• The desired and minimum number of gateways to perform checks / verifications.
• Which metric to use to select which gateways are preferred to process the function request — This can be random, lowest transaction fee, speed, distance, reputation etc. (Regardless of the metric chosen an element of randomness will be introduced into the process so that gateways cannot definitively understand which other gateways may get asked to perform the same function.)
• Which specific gateways to choose for a function in the form of a list of lists.
Gateways
Overledger gateways will be a lightweight single binary in Java to run on any machine windows/Linux/Mac (This can be on your personal PC / Laptop or you could use a Virtual Private Server (VPS) through a cloud hosting provider). The Overledger gateway can then be combined with blockchain nodes to process various functions / transactions.
A Tier 1 Overledger Gateway consists of running the Overledger gateway in addition with 3 or more blockchain nodes (so for example running the Overledger gateway as well as a Bitcoin, Ethereum, and Stellar blockchain node.)
A Tier 2 Overledger Gateway consists of running the Overledger gateway in addition with a single blockchain node (so for example running the Overledger Gateway as well as a Bitcoin node)
A Tier 3 Overledger Gateway consists of just running the Overledger gateway without any additional Blockchain nodes.
To run a gateway there is a minimum deposit required to be paid as a license fee for joining the network (this will be a lot lower than the original 500 QNT that was planned and is not returned.)
There is then an additional variable deposit, which is returned providing the gateway doesn’t act maliciously / returns faulty results. Every time a function request is accepted by the gateway, part of the deposit is locked in the payment channel and is slashed if it returns an incorrect value as punishment for acting maliciously. The more the gateway operator stakes in the variable deposit then the more function requests they can accept, resulting in more fees received and more QNT being locked up.
• Each gateway determines what functions to support which may be restricted by the gateway tier (for example if only running an Overledger gateway with no additional blockchain nodes)
• For each function the gateway implements it specifies the cost of this function.
• The gateway has the option to deny processing a function request if it doesn’t support it, already operating at max capacity or about to go offline / maintenance
There isn’t a requirement for the Overledger gateway to be constantly online, enabling flexibility for users to choose when they want to run the gateway and earn fees for processing requests and contributing to the network, lowering barriers to entry and further scaling and decentralising the network. This would allow users to say host the Overledger gateway on their PC / VM during the day and then turning it off at night if they wanted without getting slashed / punished (although if running blockchain nodes as well then best to aim for higher uptime)
Community Treasury
The community treasury is a multi-chain application (MAPP) and its role is to handle QNT payments flowing from users to the gateways in such a way as to disincentivise faulty behaviour from any user or gateway, and to do so in a manner where it can be held accountable to any observer. For the treasury to operate in a trustless manner as well as overcome the limitations of the speed of the Ethereum Network and reduce any on-chain transaction costs to pay in Ether, layer 2 unidirectional payment channels will be used.
Each payment channel created will hold a certain amount of QNT funded by the creator of the channel and the channel is set to expire after a declared time period after which all unclaimed QNT can be reclaimed by the channel creator. The creator of the channel can increase the amount of QNT and adjust the timeout period for the channel. The receiver in the channel can claim a certain amount of QNT from the channel when certain conditions are met such as provide proof they have received an off-chain transaction sent to them by the creator.
- The Community treasury oversees payments by deciding which users and gateways to establish payment channels with and penalising any malevolent behaviour. Traffic is routed to gateways based upon the metrics the user decides in the request and there will always be an element of randomness so that gateways cannot definitively understand which other gateways may get asked to perform the same function.
• Each function the treasury is overseeing it will determine the dispute fee by a user, verification process used to settle any potential disputes, any commission fees for processing the request and any penalty fees
• The treasury offers time-stamping service for transactions / requests which are used to resolve disputes
How payment channels work
Payment channels are required as the QNT token exists on Ethereum, which has a low number of transactions per second and requires every on-chain transaction to pay fees in Ether. The payment channels are Unidirectional and enable the vast majority of transactions to be processed off-chain instantly without paying ETH fees. There will (at least initially) be two types of layer 2 unidirectional payment channels in use: (1) between users and the community treasury; and (2) between the community treasury and gateways.
In the case of the payment channel between the User and the community treasury, the User deposits an amount of QNT into the trustless payment channel to be used to pay fees to gateways processing functions. The creation of the payment channel is done with an on-chain transaction on Ethereum. Now that the channel has been created the vast majority of transactions for requests from gateways are performed off-chain which are instant and don’t require ETH fees. So rather than have every transaction being recorded on the Ethereum blockchain instead the fees are accumulated until they get to a larger amount which the Community treasury can then claim via posting proof of the off-chain transactions on the Ethereum blockchain and the balance is updated onchain.
This also enables micropayments / streams of payments to be made which otherwise wouldn’t be feasible due to the high average ETH gas-price. The transaction fees in QNT accumulate in a trustless payment channel which can be redeemed in bulk with a single transaction on the Ethereum blockchain. If the channel times-out or is closed by the user then the remaining QNT that hasn’t been spent on fees is returned to the User. Additional occasional on-chain transactions would be to increase the QNT balance of the channel and/or increase the time-out of the channel as well as close the channel.
A payment channel between the Community Treasury (sender) and a gateway (receiver) is used for sending transaction fees in QNT as rewards for correctly performing a function. It is initially funded by the Treasury to an amount that is greater or equal to the fee the gateway operator paid as a license fee and the amount funded by the treasury will continue to be added as it receives funds from the users’ payment channels.
Trustless Escrow Smart Contracts
For a clear separation between fee payments and deductions (slashing) for bad behaviour, payment channels will strictly be used to process QNT fees flowing through the network whereas other smart contracts will be used to handle dispute payments.
For user disputes each user’s dispute deposit into a Trustless Escrow smart contract where the QNT is locked in there until the same time limit as the corresponding User payment channel. If the User doesn’t raise any incorrect disputes then the QNT will be released to the creator / sender. If however the user raised an unnecessary dispute then the Community treasury can redeem QNT from the user.
The Gateways Variable deposit is deposited into a Trustless Escrow smart contract where the QNT is locked in there until the same time limit as the corresponding Gateway payment channel. If the gateway doesn’t act malevolent then the QNT will be released back to the gateway. If however acts malevolent the desposit will be slashed and the QNT claimed by the community treasury.
There will be also a smart-contract for dispute resolution between gateways and the treasury, for example should the treasury fail to pay the correct fee to a gateway for processing a function.
Overall I am extremely excited with this community treasury design, providing even greater utility to an already extensive list as detailed in the Overledger Network paper. It incorporates the benefits of staking with taking more QNT out of circulation but without the usual major disadvantages of high inflation and doesn’t punish those that don’t wish to run a gateway through dilution.
The breakthrough feature of providing trust for a user not running a blockchain node themselves in a secure, scalable and decentralised way (utilising trustless layer 2 payment channels to provide off chain transactions for instant and no fee payments) is also very promising and may well be used by other decentralised networks in the future.
All of this lays the foundation for the rise of the Networks of Networks: interconnecting all DLT Networks, existing off-chain networks and even the Internet itself. Where true, scalable interoperability can be achieved without requiring connected chains to fork their code and imposing limitations, without the overhead, bottleneck and single point of failure of adding another blockchain in the middle. Where it will be quick, easy and free to participate.
Soon the open-source connector standard will be released, enabling any project to connect their blockchain to Overledger Network where all connected projects can benefit from the efforts of each other, to usher in Mass adoption of Blockchain.