Decentralized Sidechains as a ServiceDRAFT VERSION

https://elph.com

1

CONTENTS

1 Introduction 31.1 Sidechains as a solution . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 31.2 Elph: Sidechain as a Service . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 3

1.2.1 Features . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 4

2 Network Participants 4

3 Architecture 53.1 Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 53.2 Sidechain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 5

3.2.1 Core . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.2.1.1 Chain Architecture . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 63.2.1.2 Peer-to-Peer Communication . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 7

3.2.2 Consensus Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.2.2.1 Block Consensus . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 73.2.2.2 Throughput Threshold Test . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 83.2.2.3 Fault Tolerance . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 8

3.2.3 Ethereum Bridge . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2.3.1 Bridge Overview . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 93.2.3.2 Ethereum Proxy Contract . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2.3.3 Ethereum to Sidechain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 103.2.3.4 Sidechain to Ethereum . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 10

3.3 Orchestrator . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.3.1 Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 11

3.3.1.1 Validator Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 113.3.1.2 Sidechain Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 12

3.3.2 Marketplace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 133.3.3 Rewards Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

3.3.3.1 Rewards . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 143.3.3.2 Penalties . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 14

4 Developer Flow 154.1 Step 1: Register Sidechain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.2 Step 2: Deploy and Run Sidechain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 154.3 Step 3: Deploy Apps on Sidechain . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5 Token Mechanics Summary 155.1 Validator Registry . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155.2 Validator Marketplace . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.2.1 Payment mechanism for developers . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 155.2.2 Incentivize Validator policing . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 15

5.3 Powering Consensus Engine . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165.3.1 Slashing Methodology . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 165.3.2 Delegated Proof-of-Stake . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . . 16

6 Conclusion 16

2

Elph DSaaShello@elph.com

Genesis Labs, Inc.

In this paper, we describe a fully decentralized service to provision layer-2 sidechains. It performs as a platform for Developersto deploy highly scalable and customizable sidechains for their applications, secured by a shared network of resources providedby Validators in a fully decentralized setting. In particular, this paper:

1. Introduces the Elph Platform and its associated application programming interface that:• Allows Developers to create configurable sidechains through a verifiable marketplace.• Allows Validators to participate in securing the deployed blockchains through a Proof-of-Stake incentive model.

2. Details the technical architecture of the system, including the sidechain architecture, consensus model, proxy mechanismfor interoperability with Ethereum, as well as the Orchestrator component responsible for powering the marketplacebetween developers and validators and the rewards engine as a standardized payment mechanism.

3. Formalizes the token economics model based on the ELPH token to economically incentivize all network participants.

1. INTRODUCTION

Over the last five years, we have seen a significantgrowth in the number of blockchain companies, eachboasting a blockchain with a slightly unique set offeatures catered to optimize different security andperformance characteristics [1]. These blockchains aretypically built to either power a cryptocurrency or offera platform for general decentralized computation thatunlocks a very broad range of applications.

Ethereum, for example, touts its blockchain as "theworld computer," offering a platform for anyone to writearbitrary Turing-complete smart contracts in theory [2].In practice, however, the high transaction fees and lowtransaction throughput—caused by limitations of theunderlying blockchain itself [3]—effectively restricts thetypes of applications that can be built. For this reason,developers have increasingly looked towards sidechainsas a viable alternative [4].

1.1. Sidechains as a solution

A sidechain allows developers to customize ablockchain’s parameters for the needs of their ap-plication, while still maintaining security guaranteesand some degree of interoperability with a parentblockchain (e.g., Ethereum). Developers can choosebetween different degrees of scalability, decentraliza-tion and security, while taking factors like transactionthroughput and fees into consideration. Moreover,by connecting a sidechain to Ethereum, applicationsbuilt on the sidechain can inherit the large user base

who already have assets there (e.g., ETH and ERC20tokens).

However, there are challenges associated with deployinga custom sidechain, namely:

1. Developing a custom sidechain requires monumen-tal engineering effort.

2. Ensuring security of the sidechain is complicatedand requires constant maintenance.

3. An application’s needs can evolve, requiringpotentially significant changes to the underlyingsidechain.

In an ideal world, developers should be able to just focuson building rich, user-friendly apps without worryingabout the underlying sidechain technology.

1.2. Elph: Sidechain as a Service

Elph handles all the technical complexities of building,deploying, and maintaining sidechains, so developersdon’t have to. By focusing development effortexclusively on providing sidechains as a service, Elphcan efficiently develop and update all sidechains atonce to add new features or protect against attacks,providing value at the infrastructure layer. A benefitto one sidechain translates to the same benefit for allsidechains.

We have summarized why Elph is a compellingalternative to building custom sidechains from scratchat a high level, and we now switch focus to the different

3

Network Layer

Blockchain Protocol

App A

Network Layer

Blockchain Protocol

App B

Network Layer

Blockchain Protocol

App C

Elph Platform

App A App B App C

FIGURE 1: Elph abstracts away the blockchain logic and P2P networking, so developers don’t have to think aboutit.

features that Elph provides.

1.2.1. Features

Elph offers an easy way for developers to spin up acustom sidechain in just a few clicks. Developers cancustomize the:

1. Sidechain network: how nodes in the sidechainnetwork achieve consensus to secure the chain,which nodes are allowed to participate, etc.

2. Blockchain parameters: the block size, blocktimes, fee model, etc. to control transaction costsand speed.

3. Hardware resources: the number of nodes re-quested, the desired computational power requiredfor the sidechain, and other considerations such aserror rate and uptime.

Elph is designed in a way that allows developersto deploy application-specific sidechains that meet awide array of requirements, while still maintainingcompatibility with Ethereum. It facilitates the transferof Ethereum assets and the execution of Ethereumsmart contracts on the sidechain without significantmodification.

2. NETWORK PARTICIPANTS

There are three network participants that play a rolein the Elph Network: Validators, developers andmaintainers. Each participant contributes somethingthat increases the value of the network and also receivessomething in return for their contribution. We outlineboth in the table below:

NetworkParticipant

Value gained Value offered

Developer Sidechain de-ployment fortheir specificdApp

Create a dAppfor others to use

Validator Fees from thedeveloper forsecuring thesidechain

Participate inthe consensusdecisions on thesidechain

Maintainer A percentage ofa rewards dis-pensation event

Participate inongoing main-tenance anddevelopmentof the ElphNetwork

The network’s structure works in an incentive loop.Developers want granular control on the numberof Validators available to them as well as thefeatures needed for their unique application needs, likegeographic location, Validator error rate, minimumnumber of Validators, etc. In this regard, they pay feesto specific Validators, assigned through a marketplace,for the sidechain associated with their dApp.

Validators are incentivized to carry out their responsi-bilities appropriately not only to draw as much profitas possible from developers but also because they stakeELPH tokens on the "root contract" on the parentchain in order to participate in the consensus build-ing process on the sidechain. Staking economically in-centivizes them to behave judiciously or risk losing thefunds locked up in the contract.

4

Orchestrator

Developer

Sidechain A Sidechain B Sidechain C

Validators

FIGURE 2: A Developer interacts with Orchestrator to deploy and run sidechains, which then assigns a set ofValidators for each sidechain through a marketplace. The Validators then secure the sidechain and periodically

interact with Orchestrator to collect rewards and pass inter-sidechain messages.

3. ARCHITECTURE

3.1. Overview

Elph lets developers deploy sidechains and buildapplications on top of them, where each sidechain isEthereum-compatible and customized by the developerfor the unique requirements of their application. Elph’sdecentralized network handles the supporting hardwareinfrastructure, so developers don’t have to. At a highlevel, the architecture consists of two main components.First is a network of sidechains, where each sidechainhas a distinct set of Validators tasked with securelyrunning a specific developer’s dApp. The secondis an Orchestrator component, a smart contracton Ethereum, which is responsible for managing andcoordinating all network participants in the form of amarketplace. It also functions as a hub that the networkof sidechains connect to in order to communicate witheach other. The rest of this section details how thesetwo core components concretely work in context of thesystem.

3.2. Sidechain

A sidechain is spun up for a distinct dApp. Eachsidechain in the sidechain network is attached to theEthereum parent chain through a two-way peg thatallows for secure interoperability of assets between the

parent blockchain and the sidechain. The assets movedonto the sidechain can be sent to other participants andmoved back to the parent blockchain at any time safelyand without the participants incurring a loss of funds.In order to satisfy this constraint, the Validator nodessecure the sidechain by achieving consensus on both(1) the events on the parent chain to be reflected onthe sidechain and vice versa, as well as (2) the validtransactions to include in each subsequent block in thesidechain.

These Validators form a distributed system of trustlessnodes that collectively need to be Byzantine FaultTolerant—that is, the system needs to function asdesired and reach consensus despite malicious nodesor delays and failures in message propagation [5]. Inorder to tolerate such faults—akin to the ByzantineGenerals’ Problem in distributed systems literature—anefficient model with resilient state machine replicationis required for honest nodes to achieve consensus [6].More formally, the desired model has to maintain boththe following properties:

• Liveness: the network continues to make progressin spite of a capped number of failing or maliciousnodes.

• Safety : the honest nodes eventually reachconsensus through a range of network conditions.

5

Validator A

Validator C

Validator B

Validator D

Block NBlock N - 1

Block Producer

FIGURE 3: Validators communicate with each otheras part of PBFT to ensure consensus is reached on a

block.

There has been a significant amount of researchon consensus techniques that demonstrate practicalfeasibility when utilized in production level distributedsystems. The Practical Byzantine Fault Tolerance(PBFT) replication algorithm [7] is one such techniquethat exhibits high performance characteristics inasynchronous settings. In the PBFT model, nodes areordered in sequence with one node being designatedas the leader and the others being categorized asbackup nodes. The nodes communicate with eachother over multiple phases through a "gossip protocol"(more details in the "Node Communication" sectionbelow) to prove message origin authenticity as wellas message content correctness. The end goal isthat given less than a third of the nodes are faulty,the remaining honest nodes can come to the correctconsensus decision and maintain the properties ofliveness and safety. The salient point here is that thenodes are deterministic and start in the same state,and because the honest nodes come to an agreementon the order of the record each time, the model isable to provide instant transaction finality. In other

words, once a proposed block is agreed upon by thenodes, the block is final without the need for severaladditional confirmations (not the case in Proof-of-Work based consensus). Our first implementationis modeled off of the Tendermint implementation [8](with some of its concepts described in the relevantsections below to provide more context to the reader).In the meanwhile, we are exploring optimizations(some described in subsequent sections) and alternateconsensus algorithms (e.g., asynchronous consensusalgorithms like Honey Badger [9]) in accordance withdevelopers’ needs.

At a higher level, this consensus model is utilized as partof a Proof-of-Stake (PoS) system [10], which requiresValidators to "stake" an amount of their tokens so asto have a chance of being selected to produce / validateblocks of transactions and get rewarded for doing so.Staking is the action of putting up a collateral of tokensas a security deposit for the right to validate in this PoSsystem. The more a user stakes, the higher the chanceof being selected to participate in the network as theywould have more "skin in the game" and would be lessincentivized to behave maliciously.

The sidechain architecture is divided into 3 primarycomponents: (1) the Core, which stores the chaindata, as well as receives and processes transactions, (2)the Consensus Engine, which ensures the transactionsare processed correctly by achieving consensus amongmultiple peers, and (3) the Ethereum Bridge, whichrelays messages between the sidechain and theEthereum blockchain.

3.2.1. Core

3.2.1.1. Chain Architecture

The sidechain follows an account-based model, main-taining user account balances and other state informa-tion in a compact manner, in a similar vein as Ethereum[2]. In particular, the sidechain has a set of Merkle Pa-tricia tries responsible for maintaining the core stateassociated with it.

At a high level, each sidechain is a transaction-basedstate machine that triggers state updates as a result ofincoming transactions. During this entire process, thedata that needs to be stored presents itself as either (1)permanent data (i.e. immutable transactions) or (2)in-flux data (i.e. balances that are subject to change

6

based on the transactions in-play), demanding differentstorage requirements.

Data is stored in a Merkle Patricia trie to takeadvantage of the data structure’s properties for compactstorage representation [11]. The transaction data, statedata, contract data, and transaction receipts are allstored in separate Patricia tries. These tries willbe implemented using LevelDB [12] for fast key-valueretrieval. Depending on the data, certain rules apply:

• The transaction trie, newly created for each block,is unmodifiable, with respect to the transactioncontents and the ordering of the transactionswithin the block.

• The state trie, keyed by account address, isglobal and constantly updated as transactions areprocessed. For example, the balance of a user isone of the values that may be updated accordinglyhere.

• The contract storage trie holds the contract dataand is associated with each different user account(its root hash is stored in the state trie).

• The receipt trie contains the outcome data that isthe result of executing transactions.

The sidechain processes incoming transactions concur-rently and updates its set of trie data structures ac-cordingly. The root hashes of these tries (which pro-vide cryptographic proofs of the content in the trie) arepackaged in the headers of each block, which is thenlinked to the prior block through a block hash, effec-tively forming the sidechain for a specific dApp.

3.2.1.2. Peer-to-Peer Communication

The Validator nodes constantly exchange messagesbetween each other in order to process transactions aswell as reach consensus. Exchanging messages needs tobe done in a secure fashion, both from the perspectiveof peer identity (key) as well as data integrity,or else consensus (with at least two-thirds honestValidator nodes) cannot be guaranteed. In this regard,communication across nodes in this distributed networkis based off a peer-to-peer gossip protocol. Each ofthe nodes runs a standard authenticated key exchangewith Diffie-Hellman operations used as the basis for keyagreement [13]. This allows two parties to be mutuallyauthenticated and have a shared secret between themto encrypt further communication. This entails explicittwo-way confirmation and prevents session keys from

being exposed in compromised situations.

Prior to being broadcasted to peers, transactions arevalidated and added to an internal mempool in the formof an ordered linked list. This data structure allows forread and write operations to be safely executed acrossmultiple processes. The transactions are multicasted topeer nodes to also be added to their internal mempools.Block producers propose a new block composed oftransactions in their mempool by including the Merkleroot hash of independent chunks of the block in theproposal message. Validators use the hash to determinewhether the block is valid or not. After the blockis committed to the chain, the transactions in themempool can be removed accordingly from the nodes.

There is scope for reducing the communication overheadin the gossiping mechanism described above, which isO(n2) in run time, requiring peers to verify messageintegrity across each communication channel betweenthem. Employing an aggregate-signature scheme [14,15, 16] in order to reduce the run time to O(n) andincrease scalability as more peer nodes are added to thesidechain is a viable extension we are exploring.

3.2.2. Consensus Engine

3.2.2.1. Block Consensus

We introduce a high-level overview of the PBFTconsensus algorithm, which will be used in ourbase implementation rollout, while we further explorealternate constructions like asynchronous consensusalgorithms based on developer needs.

1. The Block Producer generates a block using thetransactions in its mempool and sends a proposalmessage to the other Validators. Validator nodeswait a short period of time (based on their owninternal clocks) in order to receive a block proposalfrom the Block Producer. If the time elapses,the Validators can vote to move forth to the nextround.

2. (Note: the rest of these voting phases are fullyasynchronous.) After each Validator node receivesthe proposal message, it can broadcast a pre-votemessage or a nil vote (if it deems a block is invalidor timeout occurs) and waits to hear the pre-votesfrom the other nodes on the sidechain.

3. If a node receives a pre-vote from more than two-thirds of the nodes for a block, it then broadcasts

7

a pre-commit vote, else it signs a nil vote. Thisessentially indicates whether the nodes are readyto commit a block or not.

4. If more than two-thirds nodes pre-commit forthe block, a block is committed at the currentblock height, else there is no commit. It’s atthis point that state on the sidechain can beupdated accordingly based on the content of thetransactions accordingly.

5. During this flow, explicit locking rules are followedto ensure that two blocks cannot be committed atthe same height.

3.2.2.2. Throughput Threshold Test

One of the features a developer can choose whenrequesting a Validator for their sidechain is thethroughput threshold of the node, correlated with theamount of resources the machine has to dedicate to workon the sidechain. In this regard, another responsibilityof the Validators is to verify (by reaching consensus)whether the Block Producer node met its statedthroughput threshold claimed during registration (i.e.difficulty level specified in the feature specifications).The Block Producer is presented with a "Proof-of-work"based problem to solve to demonstrate the machinemeets a certain throughput threshold requirement (ontop of having to propose a block).

The end goal for the Block Producer is to present ahash below a target number which is calculated basedon the difficulty it claims it can handle. Proof-of-workrequires brute forcing all possible nonces in order tofind a hash smaller than the target hash [17]. All theother Validators will inspect the block produced to seeif the Block Producer successfully completed the proof-of-work challenge or not. Note that a block can stillbe produced even if the difficulty challenge was notsuccessfully met.

3.2.2.3. Fault Tolerance

Each round of consensus, Validator nodes are orderedsequentially and a leader is chosen in a round-robinfashion, tasked with the responsibility of being a BlockProducer. All other Validator nodes are responsible forvalidating the correctness of the blocks being produced.A Validator node over the course of the consensusrounds can either go offline or behave maliciously.

1. In the offline case, a node can quickly come back

online and continue to participate. Note that eachnode maintains a complete list of all transactionsand are all consistent because the transactioncommits are done atomically. In order to recoverfrom a crash, the state machine can leveragethe logging mechanism on each node so that aValidator can efficiently return to the last step priorto a crash and continue, thereby maintaining allsystem invariants.

2. In the malicious case, the other Validator nodesneed to come to consensus on the Validator’smisbehavior and boot off that node. The way thisis done is by including a special instruction in theform of a transaction to replace the Validator(s)at the end of all the regular transactions prior tocommitting the block. The honest nodes all reachconsensus on booting off the Validator and theblock is committed across all these nodes. Anynode is economically incentivized to report thismisbehavior to the Ethereum parent chain contract(see the subsequent "Consensus" section for moredetails) in exchange for being rewarded a bounty(on top of getting a portion of the slashed tokensfrom the faulty Validator for being an honestValidator). Once a new node is assigned and priorto it participating on the side chain, it will queryseeds for other peer nodes on the sidechain, fast-sync with them to catch up to the current blockheight and the system will continue as intended.

3. The extreme case is when the system comes toa halt (for instance, more than a third of theValidators crash) and progress cannot be made. Inthis case, reads are still permissible but no newtransactions can be committed to the ledger. Thedisaster recovery plan here is to get the remaininghonest nodes to spin up a separate sidechainaltogether for the application.

Validators are all monitoring each other to makesure that they all stay online and are behavingcorrectly. This monitoring is done continuously everyround of consensus. Based on what happens in theconsensus rounds, Validators (1) immediately informthe Orchestrator contract on Ethereum about a faultynode (to request for new Validator node) and (2)periodically make a contract call detailing the actualperformance of a Validator to eventually be used duringthe sidechain-validators matchmaking process.

The two cases of communication are as follows:

1. Misconduct by a Validator node results in an

8

immediate call to the Ethereum contract from oneof the other honest Validators (the assumption hereis that flow won’t happen too often and thereforegas costs are within reason).• Slashing rules are applied such that the faulty

Validator loses their stake and it is distributedto the honest nodes and maintainers. See"Token Mechanics Summary" section formore details.

2. If there is no misconduct from the nodes, a batchedcontract call is made each day to the Orchestratorsmart contract. This includes:• Number of total rounds of block production a

Validator participated in.• Throughput Threshold: # of times PoW

challenge was met• Error Rate: # of times a Validator was

incorrect in consensus decision• These statistics are used to update state on

the Ethereum parent chain contract, whichis used to distribute rewards appropriatelyas well as to keep historical context asto how ’trustworthy’ a Validator node is(decision point for developers in choosingfuture Validators).

This type of update necessitates a mechanism for thesmart contract to be able to tell that two-thirds ofthe Validators have reached consensus on transactionforwarded from the sidechain. In this regard, multi-party ownership is conveyed through a thresholdsignature scheme based on Schnorr signatures [18, 19],which the smart contract can rely on to verify that theappropriate number of Validators (identified by publickey) have vouched for the transaction.

An alternate approach worth further research intois whether a state channel [20] should be used toconvey updates regarding validator performance on thesidechain to the parent chain smart contract instead.On Ethereum, state can be locked via a multisignatureor smart contract, requiring a specific group ofvalidators to agree to update it. On the sidechain,validators can update the state amongst themselves asthey wish by constructing and signing transactions untilabsolutely necessary to relay information in the statechannel back to the parent chain, at which point thechannel is closed and the state on Ethereum is updatedand unlocked. Note that as validators join or leave thesidechain, a new state channel must be established eachtime.

3.2.3. Ethereum Bridge

The Ethereum bridge facilitates interoperability be-tween sidechain and Ethereum, which means that anyapplication built on top of an Elph sidechain can trans-fer Ethereum assets (ETH, ERC20, ERC721, etc.) backand forth. The next few sections explains how theEthereum bridge works in detail.

dApp

dApp dApp

Ethereum

dApp

Bridge

Sidechain A Sidechain B

Bridge

ETH / Tokens

FIGURE 4: Ethereum bridge enables EthereumdApps and those on the Elph sidechain to transfer

assets back and forth.

3.2.3.1. Bridge Overview

Each Validator runs an Elph node as well as a trustedfull Ethereum node (or at least be able to connect toa trusted Ethereum node). Since the node is fully insync with the Ethereum blockchain, it has visibilityinto broadcasted events and the latest state of theEthereum network, as well as the ability to verify andsend transactions on it.

9

Sidechain Sidechain

Proxy ContractProxy Contract

Smart Contract Smart Contract

Contract Call

Contract Call

Logs / Events

Ethereum Transactions

Ethereum

FIGURE 5: Proxy contract for a dApp’s smart contract on Ethereum emits logs to send events to the dAppcontract on the sidechain (left). The sidechain dApp can also send Ethereum transactions back to a dApp’s proxycontract, which checks the validity of the transaction and makes the appropriate contract call to the dApp’s smart

contract.

3.2.3.2. Ethereum Proxy Contract

A proxy contract is a smart contract on Ethereum fora specific dApp involved in transferring assets (ETHand tokens) and reconciling events between the dAppsidechain and Ethereum. This implies that N dAppcontracts on the Ethereum parent chain will haveN corresponding proxy contracts that are used as amedium of communication to the N sidechain dAppcontracts respectively.

The proxy contract relays transactions from Ethereumto the sidechain using logs (contained in block receipts),wherein a merkle proof can be used to prove loggedinstructions. Functions on the proxy contract can logevents that the Validator nodes on the sidechain listento. Similarly, each proxy contract exposes functionsthat can be called from the sidechain to interact withdata on Ethereum, and move assets back to the parentchain.

3.2.3.3. Ethereum to Sidechain

To move assets and state from Ethereum to a sidechain,an end user can simply make a smart contract call thatfreezes the assets on the main chain and emits a log

message. The Validators, who are listening to logs onEthereum, store all the incoming logs in their mempool.Validators will wait until enough additional blocks havebeen mined on Ethereum to simulate finality. TheValidators then add a special transaction to the currentsidechain block, applying the result of the log to thesidechain. For a simple asset transfer example, therecipient’s balance for the asset on the sidechain isincremented accordingly.

3.2.3.4. Sidechain to Ethereum

The exit mechanism—the other direction of goingfrom the sidechain to the Ethereum parent chain—isaccomplished by making a call to the dApp proxycontract to burn assets on the sidechain and unfreezethe corresponding locked-up assets on the other end.

Elph use a threshold signature scheme for Schnorrsignatures (similar to the Validator reporting mecha-nism described in the "Consensus Engine" section) andcrypto-economic incentives to ensure that honest Val-idators are rewarded for facilitating interoperability.

More concretely, when a user initiates a transferof assets from sidechain to Ethereum, the following

10

happens:

1. The current Block Producer includes a specialtransaction in the block, which includes theproposed Ethereum transaction. Validatorsparticipate in the consensus algorithm, and finalizethis block.

2. The transaction to be forwarded to Ethereumrequires Schnorr signatures from at least two-thirdsof the Validators, at which point any one of theValidators can send that transaction to Ethereum.To incentivize Validators to actually pay gas costsand make the smart contract call to send thetransaction, the calling Validator is rewarded witha small bounty from the developer’s depositedamount (for the specific sidechain).

3. The Ethereum smart contract verifies that consen-sus was reached on the transaction by validatingthe signature. This prevents a Validator from send-ing a malicious transaction without the other Val-idators’ verification.

4. Once the smart contract verifies the signatures,it executes the transaction and records that thetransaction is complete. In the asset transferexample, the assets on Ethereum are unlocked andtransferred to the intended recipient.

3.3. Orchestrator

The paper has discussed the inner workings of a singlesidechain in the network up until now. However giventhe system is composed of a network of sidechains, thereis a need for a way to manage the global validator setand maintain auxiliary information about the entirenetwork. The Orchestrator is a smart contract onEthereum that maintains state of all the variousnetwork participants on Elph and coordinates actionsamong them. More specifically, the Orchestratorcontract has the following main responsibilities:

1. Maintain a registry of Validators, developers, andsidechains, as well as any relevant metadata foreach of these entities.

2. Assign Validators to a sidechain through averifiable marketplace, based on the requiredsidechain properties.

3. Reward honest Validators for securing thesidechains and penalize malicious Validators.

The single Orchestrator smart contract is divided intothree sections when explaining to reflect the above

responsibilities: Registry, Marketplace and RewardsEngine.

3.3.1. Registry

The Registry section of the smart contract containsthe data structures to maintain state about thevarious network participants, registered sidechains, andmarketplace. A high level overview of each of these datastructures is described below.

3.3.1.1. Validator Registry

The Validator registry contains all the Validators thathave registered in the smart contract, where registeringinvolves the Validator staking some number of ELPHtokens. The staking is required not only to preventsybil attacks (where a malicious actor can add fakeValidators that they operate), but also to incentivizehonest behavior since a portion of the staked amountcan be slashed in the event of malicious behavior (e.g.,producing incorrect blocks in a sidechain or validatingblocks incorrectly).

The Validator registry is represented as a mappingfrom an Ethereum address to a struct describing theValidator. It encapsulates the following information:

1. Reward Balance: The total amount the Validatorhas been rewarded as a part of compensation orany good behavior that benefits the network. Thisbalance is instantly withdrawable as this balance isnot staked.

2. Sidechain: An identifier to the sidechain theValidator is assigned to, if any. This field isinitially empty, until the Validator is assigned toa sidechain (see the Marketplace section below formore details).

3. Features: A list of properties that describes whata Validator can offer, including the price range theValidator charges:(a) Balance, which indicates the number of

tokens staked (how much "skin in the game"does the Validator have).

(b) Price, at which the Validator expects to bepaid, where the payment is described as anhourly rate, per currency (ELPH token, ETH,Dai [21] stable coins).

(c) Throughput threshold, representing theValidator’s ability to perform complex oper-ations in a short period of time.

11

Orchestrator

MarketplaceRegistry Rewards Engine

ValidatorDeveloper

Register Sidechain

Request Validators for sidechain

Register Validator

Collect Rewards

Registered Validators

Registered Sidechains

Maintain Registry

Match validators to Sidechain

Calculate Rewards / Penalties

FIGURE 6: Orchestrator manages registry, matches Validators with sidechains, and handles incentives to keepsidechain running.

(d) Error rate, represented by a percentage thatdescribes the number of times a Validatorproduced an error in the time period it wasassigned to a sidechain and participated in theconsensus algorithm for that sidechain.

4. "Last Staked At": the last time the Validator hadstaked tokens (or renewed its stake). This valueis updated whenever a Validator stakes tokens, orwhen a Validator is assigned to a sidechain.

To register as a Validator and add the staked amount,one calls a registration function on the Orchestratorcontract, with the specified initial stake amount. TheValidator can then increase this amount at any time.Every time a Validator stakes tokens, all the tokens(including any that have been previously staked) arelocked up for a specific amount of time. The lockupperiod is required to prevent sybil attacks and to ensurethat a Validator is sufficiently staked for a deterministicperiod of time, to participate in a sidechain’s consensus

algorithm.

A Validator can withdraw tokens from the smartcontract to the their own Ethereum address, giventhat the tokens are eligible for withdraw - or morespecifically, the lockup period has expired.

3.3.1.2. Sidechain Registry

When a developer wants to deploy and run a sidechain,they must register the sidechain to get a sidechainidentifier, specify the Validator features that thissidechain requires, and add a deposit amount for thissidechain (held in escrow). The Validator features arethen used to match Validators for a given sidechain (seeMarketplace section below for more details), and thedeposit amount for this sidechain is used to compensatethe Validators automatically, without needing thedeveloper to be online.

12

The sidechain registry is represented by a mapping froma sidechain ID to a sidechain struct, encapsulating thefollowing information:

1. Developer: The ethereum address of the developerwho registered this sidechain and deposited assets.

2. Balance: The amount deposited (ELPH tokens,ETH or Dai stable coin) into this sidechain bythe developer, used to pay the Validators the ratespecified by the Validator.

3. Properties: A data structure that describes thenumber of required Validators, and the acceptablerange for various Validator features, used to matchValidators to the sidechain.

To register a sidechain, developer must call aregistration function, with a specified deposit amount.The developer is responsible to always maintainenough deposit amount, to guarantee payment for theValidators for the entire duration the Validator is"hired" for. (See Marketplace for more details). Adeveloper can withdraw any excess amounts at anypoint in time, as long as the leftover balance meets therequirement specified above.

3.3.2. Marketplace

The marketplace section of the Orchestrator contractis responsible for finding Validators for a sidechain. Abasic marketplace for Validators is a function of onlyone dimension (price) so an orderbook mechanism issufficient. However, our system aims to accommodatemultiple dimensions (such as uptime, error rate,and throughput requirements) in the matchmakingprocess, necessitating a generalized, multi-dimensionalmarketplace.

In this regard, developers participate in this "N-dimensional marketplace" by requesting Validators fortheir sidechains, specified by a set of N features. Thisis conceptually similar to an Airbnb-like market, wherefilters like house location, house size, and price arespecified and the user then gets matched up witha filtered list of choices [22]. More concretely, thedeveloper calls the matchmaking function in the smartcontract for a sidechain, which then finds a random setof Validators (weighted by their staked amount as partof a Proof-of-Stake model) that all meet the sidechain’srequired properties.

The random selection process is required to give all

the Validators who satisfy the sidechain’s requiredproperties a fair chance of being chosen. If thematching algorithm is deterministic given the candidateValidators, certain candidates may never be chosen fora sidechain (i.e. if they have a slightly lower stakedamount, slightly higher error rate, etc.) Randomnessin the matchmaking process also has the side effectof preventing the same set of Validators being chosenin perpetuity for a sidechain, making sidechain-basedcollusion attacks more difficult to coordinate. Theapproach to generating verifiable randomness followssuit to some of the existing solutions to this studiedproblem, based on verifiable random functions [23, 24]or RANDAO based approaches [25].

Filter

Random Sampler

All Registered Validators

Suitable candidate validators

Matched subset of candidate validators

Matched validators form sidechain.

FIGURE 7: Developer calls the matchmakingfunction, which 1) Filters Validators that match thesidechain’s requirements, and 2) Randomly samples

from the set of candidate Validators.

13

Validator DeveloperSmart Contract

Register Self

Register SidechainSidechain

Deposited Tokens

Sidechain

Deposited Tokens

Sidechain

Deposited Tokens

Sidechain

Deposited Tokens

Sidechain

Deposited Tokens

Sidechain

Deposited Tokens

Get Tokens

Get Tokens

Get Tokens

Claim Rewards

Claim Rewards

Claim Rewards

Deposit Tokens

Re-deposit Tokens

FIGURE 8: Validators claim rewards periodically, and developers keep adding assets to replenish the sidechain’sbalance.

3.3.3. Rewards Engine

The rewards engine is responsible for collectinginformation about all the Validators, and subsequentlyrewarding/penalizing the Validators based on theinformation.

3.3.3.1. Rewards

The primary form of compensation for the Validatoris a reward paid pro rata (based on the Validator’squoted price) for participating in securing a sidechain.At any point in time, a Validator can call a requestpayment function on the Orchestrator smart contract,

which will calculate the pro rata payment based onwhen the Validator last claimed payment.

3.3.3.2. Penalties

The Validators in a sidechain are responsible for polic-ing each other by reporting dishonest or consistentlyoffline Validators. Validators assigned to sidechains areincentivized to provide information about other misbe-having Validators since:

1. The Validator that exposes a misbehaving Valida-tor gets a small bounty from the developer.

2. The honest Validators receive most of the ELPH

14

tokens that are slashed from the misbehavingValidator’s stake.

4. DEVELOPER FLOW

4.1. Step 1: Register Sidechain

The first step for a developer is to register a sidechainusing the Orchestrator component. In order to registera sidechain, the developer has to deposit assets (ELPHtoken, ETH or Dai stablecoin), which are then usedto automatically pay all the Validators that work tosecure the sidechain. During the registration step, thedeveloper must also specify the sidechain’s requiredproperties.

Most of the configurable options fall under one oftwo categories: parameters of the sidechain itself,and required properties of Validators who secure thesidechain. A developer can specify sidechain parameterssuch as block times (time between each block), andblock size (how many transactions can be processedin each block), in order to balance various trade-offsbetween the level of decentralization of the Validatornetwork securing the sidechain and the maximumtransaction throughput. A developer can also specifythe sidechain’s required properties that Validators mustmeet in order to participate in the sidechain’s consensusalgorithm.

4.2. Step 2: Deploy and Run Sidechain

The second step for a developer is to start thesidechain, which is done by assigning Validators tothe sidechain. The developer uses the Orchestratorto find all the Validators that meet the sidechain’srequired properties. Once the Orchestrator matchesthe Validators with a sidechain, they communicate witheach other and start producing blocks for the sidechain.

4.3. Step 3: Deploy Apps on Sidechain

Once a sidechain is successfully deployed, developerscan deploy their application on top of the sidechain,similar to how an application is deployed on Ethereum.Elph sidechains are designed to be Ethereum compat-ible and support smart contracts originally written forthe Ethereum Virtual Machine (EVM) out of the box.

5. TOKEN MECHANICS SUMMARY

The prior sections in this paper discuss how the Elphtoken is used within the framework of the system,ranging from economic incentives for Validators as partof a Proof-of-State model to a form of payment forValidators. This section concretely summarizes thedifferent use cases for the ELPH token in one place.

5.1. Validator Registry

Validators stake a portion of their ELPH tokens forSTAKE_LOCK_PERIOD_IN_SECONDS, a param-eterizable value modifiable through on-chain gover-nance, on the Ethereum smart contract to enter andstay in the Validator Registry. This allows Validatorsto be chosen for a developer’s dApp sidechain and startearning rewards for consensus work.

5.2. Validator Marketplace

5.2.1. Payment mechanism for developers

Developers deposit assets (ETH or tokens) into theirsidechains, such that each sidechain has at least enoughtokens to pay the Validators for a specified amount oftime. Depositing tokens into a sidechain can be thoughtof as depositing into an escrow, and the sidechainautomatically compensates the Validators the pro rataamount from this deposit, for securing the sidechain. Ifthere are not enough funds deposited in a sidechain topay for the operational costs of the sidechain, the chainis halted until the developer deposits more tokens.

5.2.2. Incentivize Validator policing

Validator nodes are incentivized to police eachother and report faulty Validators by sending atransaction from the sidechain to the Ethereumcontract. Given there is a gas fee associatedwith this action, the system provides a bounty tomake the Validators behave as good actors in thesystem and still take this action. A parameterizablevalue, VALIDATOR_REPORT_PERCENTAGE ofthe developer’s deposited tokens are taken from thedeveloper’s deposited tokens and given to the Validatorwho submitted the misbehavior to Ethereum.

15

5.3. Powering Consensus Engine

5.3.1. Slashing Methodology

Validators (including Block Producers) are penalizedwhen they are on the incorrect side of the consensusdecision.

A parameterizable value, SLASH_RATE_PERCENTis applied across all the misbehaving actorsand the accumulated amount is referred to asthe "slash amount". The maintainers recieveSLASH_AMOUNT_MAINTAINER_PERCENTof the slash amount, the Block Producer receivesSLASH_AMOUNT_BP_PERCENT of the slashamount and the remaining amount is distributedamongst the other honest Validators. In order toweight recent positive behavior more than negativebehavior in the past, smoothing is employed throughan exponential moving average construct in therewards/penalties calculations.

5.3.2. Delegated Proof-of-Stake

As an extension to the initial implementation of thispaper, the goal is to migrate to a Delegated Proof-of-Stake model [26] instead where any external partycan bond tokens to an existing Validator in a sidechainduring the consensus rounds. Any individual withELPH tokens (even one that doesn’t provide noderesources as a Validator) can effectively have a stakein the network through this mechanism and providetangible value from a token economics perspective topositively improve the overall system. This increasesthe overall decentralization of the network and allowsfor more parties to participate in the ELPH network.

6. CONCLUSION

Elph removes the major barrier in building thedecentralized web, by offering a decentralized platformto easily deploy an unbounded number of application-specific sidechains. Each sidechain deployed on Elphis designed to have interoperability with Ethereum,thereby allowing it to take advantage of Ethereum’sexisting users and assets, as well as the growingdeveloper community. The sidechains on Elph,customizable to the requirements of developers, arepowered by a global network of validators that help toensure their overall security in a decentralized setting.Driving this network as a first-class citizen, the ELPH

token provides ongoing crypto-economic incentives forall network participants to participate and benefit fromthis system.

16

REFERENCES

[1] Garrick Hileman and Michel Rauchs. “2017Global Cryptocurrency Benchmarking Study”. In:SSRN Electronic Journal (2017). doi: 10.2139/ssrn.2965436.

[2] Gavin Wood. Ethereum: A secure decentralisedgeneralised transaction ledger EIP-150 REVI-SION (759dccd - 2017-08-07). Accessed: 2018-01-03. 2017. url: https://ethereum.github.io/yellowpaper/paper.pdf.

[3] Making Sense of Ethereum’s Layer 2 ScalingSolutions: State Channels, Plasma, and Truebit.https : / / medium . com / l4 - media /making - sense - of - ethereums - layer - 2 -scaling-solutions-state-channels-plasma-and - truebit - 22cb40dcc2f4. (Accessed on12/14/2018).

[4] What Are Sidechains? Extending ProvidingFunctionality to Existing Blockchains. 2018. url:https://blockonomi.com/sidechains/.

[5] M.a. Nasreen, Amal Ganesh, and C. Sunitha.“A Study on Byzantine Fault Tolerance Methodsin Distributed Networks”. In: Procedia ComputerScience 87 (2016), pp. 50–54. doi: 10.1016/j.procs.2016.05.125.

[6] Leslie Lamport, Robert Shostak, and MarshallPease. “The Byzantine Generals Problem”. In:ACM Trans. Program. Lang. Syst. 4.3 (July1982), pp. 382–401. issn: 0164-0925. doi: 10 .1145/357172.357176. url: http://doi.acm.org/10.1145/357172.357176.

[7] Miguel Castro and Barbara Liskov. “PracticalByzantine Fault Tolerance”. In: Proceedings of theThird Symposium on Operating Systems Designand Implementation. OSDI ’99. New Orleans,Louisiana, USA: USENIX Association, 1999,pp. 173–186. isbn: 1-880446-39-1. url: http://dl.acm.org/citation.cfm?id=296806.296824.

[8] Ethan Buchman. Tendermint: Byzantine FaultTolerance in the Age of Blockchains. Accessed:2017-02-06. 2016. url: http : / / atrium . lib .uoguelph . ca / xmlui / bitstream / handle /10214/9769/Buchman_Ethan_201606_MAsc.pdf.

[9] Andrew Miller et al. The Honey Badger of BFTProtocols. Cryptology ePrint Archive, Report2016/199. https://eprint.iacr.org/2016/199. 2016.

[10] Proof of Stake FAQs - ethereum/wiki Wiki.https : / / github . com / ethereum / wiki /

wiki / Proof - of - Stake - FAQs. (Accessed on12/14/2018).

[11] Timothy McCallum. Diving into Ethereum’sworld state - CyberMiles - Medium. https :/ / medium . com / cybermiles / diving - into -ethereums - world - state - c893102030ed.(Accessed on 12/14/2018). Feb. 2018.

[12] Google. google/leveldb. 2018. url: https : / /github.com/google/leveldb.

[13] Whitfield Diffie, Paul C. Van Oorschot, andMichael J. Wiener. “Authentication and authen-ticated key exchanges”. In: Designs, Codes andCryptography 2.2 (1992), 107âĂŞ125. doi: 10 .1007/bf00124891.

[14] Yin Yang. LinBFT: Linear-CommunicationByzantine Fault Tolerance for Public Blockchains.Accessed: 2018-12-14. url: https://arxiv.org/abs/1807.01829.

[15] Xinxin Fan. Scalable Practical Byzantine FaultTolerance with Short-Lived Signature Schemes.Accessed: 2018-12-14. url: https://iotex.io/academics-pbft.pdf.

[16] Bithin Alangot et al. “Reliable Collective Cosign-ing to Scale Blockchain with Strong Consistency”.In: Proceedings 2018 Workshop on DecentralizedIoT Security and Standards (2018). doi: 10 .14722/diss.2018.23005.

[17] Imran Bashir. Mastering blockchain: distributedledger technology, decentralization, and smartcontracts explained. Packt, 2018.

[18] Douglas R. Stinson and Reto Strobl. “ProvablySecure Distributed Schnorr Signatures and a (t,n) Threshold Scheme for Implicit Certificates”. In:Information Security and Privacy. Ed. by VijayVaradharajan and Yi Mu. Berlin, Heidelberg:Springer Berlin Heidelberg, 2001, pp. 417–434.isbn: 978-3-540-47719-8.

[19] Gavin Wood. Polkadot: Vision for a heteroge-neous multi-chain framework. url: https : / /polkadot.network/PolkaDotPaper.pdf.

[20] Liam Horne Jeff Coleman and Li Xuanji. url:https : / / www . counterfactual . com /statechannels/.

[21] Dai - Stability for the blockchain. url: https://makerdao.com/dai.

[22] Jean Folger. The Pros and Cons of Using Airbnb.2018. url: https://www.investopedia.com/articles/personal- finance/032814/pros-and-cons-using-airbnb.asp.

17

[23] Silvio Micali, Salil Vadhan, and Michael Rabin.“Verifiable Random Functions”. In: Proceedings ofthe 40th Annual Symposium on Foundations ofComputer Science. FOCS ’99. Washington, DC,USA: IEEE Computer Society, 1999, pp. 120–.isbn: 0-7695-0409-4. url: http://dl.acm.org/citation.cfm?id=795665.796482.

[24] Alternative blockchains, randomness, economics,and other research topics. https : / / github .com / ethereum / wiki / wiki / Alternative -blockchains, - randomness, - economics, -and - other - research - topics. (Accessed on12/14/2018).

[25] Vitalik Buterin. url: https : / / vitalik . ca /files/randomness.html.

[26] Delegated Proof of Stake: Features and Tradeoffs.2018. url: https://multicoin.capital/2018/03 / 02 / delegated - proof - stake - features -tradeoffs/.

18