Token Incentivized Sidechains

Published on 2018 Oct 23 00:00:01
Last Updated on 2018 Oct 25 16:43:23

Abstract

In this paper we describe a cryptoeconomic design to build secure sidechain applications, Token Incentivized Sidechains (TIS), which are protected by native staking tokens specific to each sidechain.

The design is modeled after Token Curated Registries (TCRs), invented by Mike Goldin. However, the design described in this paper is based on non-subjective voting to derive consensus on a sidechain.

The system described in this paper extends the TCR model to the non-subjective task of arriving at consensus on application-specific sidechains.

The design properties described in this paper are also based on the Plasma white paper by Joseph Poon and Vitalik Buterin. In the Plasma white paper they are described as "Persistent Decentralized Autonomous Blockchains" in the Plasma white paper (Section 2.5).

TIS are also different from DappChains in that they promote a specific set of techniques to create incentives that are meant to ensure safety and reliability of the sidechain.

Token Curated Registries

Token Curated Registries are lists of things that are curated by the registry’s native token holders. A native token is needed in order to incentivize token holders to do a good job of curating the registry list.

The key crypto economic concept of TCRs is that a native registry-specific token is needed to incentivize the curators to do a good job curating the registry.

If a non-native token is used to curate the registry, then token holders have no incentive to keep a well-curated list. The reason for this is that token holders are incentivized by keeping the value of their tokens high. If a non-native token were to be used the value of that token does not directly reflect the value of the work being done by the curators.

Application-Specific Sidechains

Blockchains such as Ethereum have a limited number of transactions per second that they can support. Furthermore, Ethereum applications are fully public, thus most high-performance enterprise applications cannot be built directly on Ethereum.

The new generation of technology to enable developers to overpass these limitations are called sidechains.

Another well-understood concept for building private, scalable decentralized applications are called state channels. The primary limitation of state channels is that only payment-based applications can be built.

With sidechains, however, developers are able to build applications with generalized state transitions that do much more than just payments. Example applications include social networks, games, and much more.

Sidechains provide the flexibility that state channels do not. This is why in this paper we focus solely on sidechains because of this flexibility.

Sidechains have a limitation in that each sidechain must run exactly one application. This is enables the sidechain to run code specific only to that sidechain and avoids the noisy-neighbor problem in typical blockchain applications. In the Plasma whitepaper, for example, sidechains are described as being application-specific which run and operate separately from other sidechains.

Example of sidechain applications from the Plasma white paper:

Verifier Registry

First there is a registry of known verifiers which lives on-chain. It can be a Proof-of-Authority registry (default), or it can be other types of registries including Token Curated Registries (TCR). The Verifier Registry holds information about the sidechain's verifiers, mainly their status (active, inactive, etc.)

Only verifiers which are in the registry may participate in proof-of-stake consensus. Ideally, for sidechain applications, those verifiers are a consortium of known entities. For example, in digital advertising, they'd be the bodies in charge of overseeing the industry. This enables the formation of consortium systems to bring trust to specific industries.

Banking: Staking and Payment Tokens

In TIS applications we define to use two types of tokens to create proper incentives: a staking token and a stable payment token.

The staking token is used to derive consensus and its value is meant to reflect the value provided by the functioning application. It also creates an incentive for verifiers and token buyers who want the value of their staking tokens to increase.

The stable payment token is used to charge fees within a TIS. Typically, a sidechain will charge for transaction fees. However, more complex behaviors can be implemented. For example, a decentralized social network may charge fees to share messages. Verifiers collect the fees to pay for the costs of operating hardware. In TIS applications, there is no need to create a native payment token. Usage of DAI, or other stable tokens is recommended.

The overall benefits of a two token system are:

The specific benefits of the staking and payment tokens are:

Network Incentives

TIS applications have particular properties to create the proper network incentives for high-throughput and safe operation of the application.

Event Signatures

Participants digitally sign events and send them to one or more verifiers of a sidechain.

Inclusion Guarantee

A participant is incentivized to send their messages to avoid censorship of their events. If a participant sends the event to one node, their message may be censored. The more nodes a participant sends their signed messages.

Gossiping

Because verifiers are incentivized to be in consensus, they digitally sign which messages they received and gossip them among each other.

Proof-of-Stake Consensus

TIS applications are protected by economic forces through the usage of Proof-of-Stake voting with a native application-specific staking token. On attacker would have to buy out a majority of the staked token market. The incentives with TIS applications is that the verifiers are incentivized to always arrive at correct consensus - otherwise the value of the staking token would plummet because the sidechain would become useless.

Non-Subjective Voting

Proof-of-stake consensus can be thought of as non-subjective voting of a particular state. One of the key concerns with Token Curated Registries are its subjectivity. In TIS, verifiers place the sidechain’s native token at stake and come to a consensus (vote) on the non-subjective state of the sidechain. The non-subjective state of a sidechain is the state root which represents all the state transitions that occurred within a given time period (since the last consensus round.)

Blind Voting

Verifiers participate in blind voting in order to avoid cheating verifiers. Verifiers are meant to process messages and run the sidechain's application code. They are to do work to be properly rewarded through fees for that work.

Block Signatures

The verifiers sign off on the validity and the availability of block headers and block data. The signatures are available on-chain for checking and validation from other framework smart contracts. This is different from typical plasma sidechains, in those systems a centralized single operator is used which is why you need fraud proofs.

Generalized State Transitions

Plasma allows two key mechanisms: safe mass-exits and challenging state root through on-chain fraud proofs. On-chain fraud proofs, however, are currently limited to applications whose state transitions can be replicated in on-chain smart contracts.

Plasma fraud-proofs work with single-operator sidechains because if the operator submits invalid states, those states can be challenged on-chain.

However, because generalized state transitions cannot be challenged on-chain, an off-chain consensus mechanism is needed to avoid invalid states from being accepted. With off-chain consensus, even though state transitions cannot be challenged on-chain it would take 2/3rd of verifiers to be fraudulent in order for invalid states to be accepted. Thus, the more verifiers there exist in the network the safer the network is. Note that without sharding, the more verifiers in the network the slower it becomes.

Writing Sidechain Apps

In TIS, a sidechain _is_ an application. Sidechain application can be written in any programming language using traditional web2 tools. Developers and companies can turn existing applications into decentralized sidechains to unlock trust in any industry.

Project 8 includes an Sidechain Development Kit (SDK) which is used to abstract communication with the rootchain.

Example Apps

Lucidity aims to create the development tools to build the next generation of decentralized applications. Developers should not generally have to deal with building complex smart contracts for building fun user applications.

Some examples cited in the Plasma white paper are:

Plasma Bank

Using an automated 2-way peg within a smart contract, funds are deposited to a smart contract and the corresponding tokens are then minted and usable on the sidechain. The root funds are non-custodial as they do not actually belong to any individual entity, but rather belong to the smart contract.

In Plasma Bank, a Sparse Merkle Tree is used within the application to keep track of account balances. The code within a sidechain application may alter account balances based on its own internal logic. The Merkelized balances are then added to the consensus as part of the state root.

In a smart contract in the root chain, in order to withdraw funds from within the sidechain a Merkle proof must be submitted which proves the balance against the latest safe state of the sidechain application.

The Merkle proofs are generated by full nodes who retrieve block transactions and recreate state transitions to be able to generate the proofs necessary for fund withdrawals.

Cryptoeconomic Properties

Many core elements of reflect TCR design properties, TIS are meant to fulfill all aspects of Mike's Cryptosystems Manifesto.

"A token must work as a necessary element of a self-sustaining system which is a public utility."

TIS require native tokens because token holder's stake is directly tied to the value being provided by the sidechain application. "The price of Bitcoin will not be responsive to reduced demand for it in the application…".

"A token is a necessary element of a system if the use of any other in its place would damage the system’s normal functioning."

The use of any other non-native staking token will remove the incentive for verifiers to continue to submit true states. Like TCRs, a token whose utility is to maintain the correctness and usefulness of the sidechain application will see its value and demand fluctuate with the quality of the sidechain application.

"A system is self-sustaining if it would continue to function normally in the indefinite absence of its creators."

With Plasma Proof-of-Stake verifiers are penalized for not consistently and continuously achieving consensus. Plasma MVP ensures that participants are able to withdraw their funds from the sidechain should the verifiers fail to come to consensus.

Verifiers run decentrally and together form a decentralized consortium sidechain application.

"A system is a public utility if it is permissionless, rent-free, and does something useful."

TISs do not inherently require this last point. It is up to the sidechain application's design to require Proof-of-Authority (w/ delegation) or be a fully open system such as Ethereum.

These design attributes are also described as "Persistent Decentralized Autonomous Blockchains" in the Plasma white paper (Section 2.5).

Resources

https://adtoken.com/uploads/white-paper.pdf

https://medium.com/@ilovebagels/token-curated-registries-1-0-61a232f8dac7

http://plasma.io/plasma.pdf