Bachelor Informatica
Structuring Sidechains for
Se-cure and Scalable
Decentral-ized Applications
Lucas Swaak
June 17, 2019
Supervisor(s): Dr. Sander van Splunter, Elric Milon (ABN AMRO)
Inf
orma
tica
—
Universiteit
v
an
Ams
terd
am
Abstract
Blockchain technology is changing the current application infrastructure. Decentralized applications are competing with traditional centralized client-server models. The current state of blockchain technology is defined by a trilemma consisting of three pillars: security, level of decentralization, and scalability. It is the scalability pillar that is currently limiting blockchain innovation. Therefore the research presented in this thesis focuses on blockchain scalability. One of the prominent proposed blockchain scalability solutions is sidechaining. Sidechaining technology enables decentralized applications to run on a network of inde-pendent blockchains called sidechains. Sidechaining technology has proven to increase the performance and scalability of decentralized applications. However, sidechaining is still an immature technology and therefore actively being researched.
This thesis aims to contribute to this active field of research by giving insight into security and complexity implications that arise from the usage of sidechaining technology. First, this thesis proposes a network structure that can be used to structure a decentralized application implemented on a network of sidechains. In this radial tree network structure, consensus mechanism properties are dependent on the value of assets secured by a sidechain. Next, to illustrate and validate this network structure, it is applied to a strategy game implementation on a sidechain: DAppHeroes. The experiments conducted in this thesis analyze security and complexity regarding the proposed network structure and the DAppHeroes implementation. This thesis argues that using sidechaining technology without taking additional mea-sures can negatively influence the security and complexity of decentralized applications. However, the framework proposed in this thesis offers a way of structuring decentralized applications on a network of sidechains to decrease security threats and complexity pitfalls whilst maintaining high performance and scalability.
Contents
1 Introduction 7
1.1 Current State of Blockchain Technology . . . 8
1.2 Research Question . . . 9 1.3 Thesis Organization . . . 9 2 Theoretical background 11 2.1 Blockchain Technology . . . 11 2.1.1 Network Layer . . . 11 2.1.2 Blockchain Layer . . . 11 2.1.3 Application Layer . . . 12 2.2 Ethereum . . . 12 2.2.1 Ethereum EVM . . . 12 2.2.2 Smart Contracts . . . 13 2.2.3 Consensus Mechanisms . . . 13 2.2.4 Tokens . . . 14 2.2.5 Security . . . 15
2.3 Scalability Issues of Current Blockchain Implementations . . . 15
2.4 Sidechaining . . . 16 2.4.1 Consensus Mechanisms . . . 17 2.4.2 Opportunities . . . 17 2.4.3 Vulnerabilities . . . 18 2.4.4 Conclusion . . . 19 3 Sidechaining Technologies 21 3.1 Loom . . . 21
3.1.1 Delegated Proof of Stake . . . 21
3.2 Plasma Cash . . . 22 3.2.1 Consensus . . . 23 3.2.2 Block Creation . . . 23 3.2.3 Token Transfers . . . 25 3.2.4 Exits . . . 26 3.2.5 Mass Exits . . . 28 3.3 Conclusion . . . 29
4 Network Structure Design for Secure Nested Sidechaining 31 4.1 DAppHeroes: a Strategy Game on a Sidechain . . . 31
4.1.1 Tech Stack . . . 32
4.2 Proposed Network Structure . . . 32
4.2.1 DAppHeroes Network Structure . . . 33
4.2.2 Opportunities . . . 34
4.2.3 Vulnerabilities . . . 34
4.2.4 Conclusion . . . 35
5 Experiments 37 5.1 Plasma Cash . . . 37 5.1.1 Method . . . 37 5.1.2 Results . . . 38 5.1.3 Discussion . . . 39 5.2 DAppHeroes . . . 40 5.2.1 Method . . . 40 5.2.2 Results . . . 40 5.2.3 Discussion . . . 41 5.3 Conclusion . . . 41 6 Conclusions 43 6.1 Results . . . 43 6.2 Conclusion . . . 44
6.3 Discussion & Future Research . . . 45
Appendices 51
CHAPTER 1
Introduction
Running DApps (decentralized applications) on a blockchain is taking over current application infrastructures. However, current blockchain technology has proven to lack the scalability to handle high throughput applications (like a payment network) [20]. A current field of research regarding these scalability problems lies in sidechaining: running a blockchain on top of another blockchain. A blockchain is a growing list of records recorded in blocks. This list of blocks acts as a distributed ledger and contains a record of every transaction made on that blockchain. Nowa-days, blockchain technology is best known for being the underlying structure of cryptocurrencies like Bitcoin [26]. Apart from these cryptocurrencies, blockchain technology has a wide range of other application areas:
Figure 1.1: Application areas of blockchain technology [19].
Take for example ownership. Blockchain technology offers an infrastructure on which users can own any type of digital asset. Decentralized blockchain implementations, like Ethereum, eliminate the need for a central authority controlling digital assets. Digital assets are not just limited to cryptocurrencies. Take for example an online card trading game. In a decentralized implementation, cards would be represented as digital tokens. These tokens can be transferred to other users just like traditional cryptocurrencies. Game rules can be decentralized by imple-menting them in the form of smart contracts [9]. A smart contract is a self-executing digital contract enforcing the terms of agreement between two or more parties as stated in the source code of that contract. By implementing the card trading game on a blockchain like Ethereum, each node hosting the game validates if card trading is done fairly. Blockchain technology has a wide range of application areas and is changing the infrastructure of owning assets online.
1.1
Current State of Blockchain Technology
Ethereum co-founder Vitalik Buterin defined a trilemma describing the current state of blockchain technology [6]. This trilemma consists of three pillars: security, the level of decentralization, and scalability. Buterin states that it is extremely difficult to implement a blockchain that excels at all three pillars.
Security
When creating a blockchain application, it is of great importance that assets owned by its users are handled in a secure way. Blockchain based applications utilize powerful cryptography, ensuring a secure digital identity reference for its users. Furthermore, blockchain applications which are distributed across nodes in a network are harder to attack because the network does not have a single point of failure. However, security challenges still arise when implementing blockchain applications. In their survey of blockchain security issues and challenges [22], Lin et al. zoom in on the current state of blockchain security. The main issue blockchain implementations encounter today lies in majority attacks (51% attacks), in which nodes in the network join forces in order to take control over a blockchain application.
Level Of Decentralization
In today’s digital society, a great deal of the assets people own are handled online. Take for example the banking system. Online banking has almost completely taken over cash. However, there is still a central authority (the bank) in charge of handling online transactions made by its customers. When a bank goes bankrupt, people lose both their money and trust in the bank. The mistrust in governments or big corporations handling valuable information without any control from its customers is growing [1]. This is where decentralized applications come into place. Blockchain technology offers a way of managing assets without a central authority controlling them. Users can play an active role in validating transactions on the blockchain shifting the power to the users instead of the government or big corporations.
A majority of current blockchain applications, like Bitcoin [26], promise decentralization. However, a survey on the level of decentralization of Bitcoin [17] has proven that Bitcoin shows limits on decentralization. This mainly has to do with the fact that miners benefit from com-bining their resources into big mining pools. These mining pools are controlled by a central authority decreasing the level of decentralization of the overall network. In order to reach true decentralization, consensus mechanisms will have to be adjusted or replaced.
Scalability
The biggest challenge blockchain applications face today is scalability. Take for example the Ethereum platform. A quote by Ethereum co-founder Vitalik Buterin accurately summarizes the current state of scalability of the Ethereum platform: “Right Now It Can Process 15 Trans-actions Per Second. Really, We Need 100,000”1. Today’s online applications often need to be able to handle thousands or even millions of users and process their data nearly instantaneously. This lack in throughput is a heavily researched area of improvement for blockchain implementa-tions. One of the solutions to the scalability problems of blockchain applications is sidechaining. Sidechaining technology allows a blockchain to run independently on top of another blockchain. This sidechaining structure allows for multiple sidechains to form a tree like network in which each sidechain can define its own consensus mechanism increasing throughput and scalability.
The research presented in this thesis is written in the context of Blue Student Lab: a cooper-ation between the University of Amsterdam and ABN AMRO. The research has been conducted at ABN AMRO’s blockchain innovation lab, which, among other activities, researches cutting edge blockchain innovations. Within this context, this thesis focuses on sidechaining as a solution to the blockchain scalability problem.
1.2
Research Question
Past research ([30], [31], [4], [14]) has proven the increase in scalability and performance that can be gained by using sidechaining technology. However, the majority of this research does not go into great detail on the impacts of sidechaining technology on complexity and security.
A great deal of applications to which side chaining technology is applicable today (like com-peting with Visa’s payment network) rely on a multi-client network. In this multi-client network, a user has to be able to send a transaction to any other user in the network. Therefore, the re-search presented in this thesis focuses on using sidechaining technology for transaction networks able to handle a large number of users. This thesis explores how applying a sidechaining network structure influences the level of complexity and security of a blockchain application. This thesis thus aims to answer the following research question:
How does the usage of sidechaining technology impact the complexity and security of a decen-tralized application?
To answer this question, I have formulated the following sub questions: • Q1.1: How scalable are current blockchain applications?
• Q1.2: How can a decentralized application using sidechaining technology be structured in a secure and efficient way?
• Q1.2.1: How does the usage of the network structure proposed by Q1.2 affect com-plexity?
• Q1.2.2: How does the usage of the network structure proposed by Q1.2 affect security? In order to conduct this research, a network structure is proposed that can be used to struc-ture a network of sidechains in a secure and efficient manner. Next, this network strucstruc-ture is analyzed and applied to a strategy game implemented on a sidechain (DAppHeroes). The proposed network structure offers insight into the complexity issues arising from the usage of sidechaining technology and the level of security needed per layer in the network. Furthermore, the experiments conducted in this thesis continue building on the security analysis by testing the level of security of the technologies used by the proposed network structure and the strategy game implementation.
1.3
Thesis Organization
Chapter 2 focuses on the theoretical background needed as a foundation to answer the research question. Firstly, a literature survey on blockchain technology and its current scalability is conducted. This literature survey is used to answer Q1.1. Secondly, a literature survey on sidechaining technology is conducted. This literature survey provides background knowledge needed to understand the workings of the sidechaining implementations explained in chapter 3. Chapter 3 offers an overview of the sidechaining technologies used in the proposed network structure and strategy game implementation: Loom and Plasma Cash. In chapter 4, a network structure is proposed which can be used to structure a network of sidechains in a secure and efficient manner. This network structure is applied to a strategy game implementation on a sidechain in order to analyze its impacts on security and complexity. Chapter 5 describes exper-iments that continue building on the security and complexity analysis regarding the proposed network structure and the strategy game implementation. Chapters 4 & 5 answer Q1.2 (and therefore Q1.2.1 & Q1.2.2). Finally, chapter 6 presents the overall results obtained in this thesis and draws a conclusion. This chapter is concluded with a discussion and recommendations for future research regarding sidechaining technology.
In conclusion, the main goal of this thesis is to give insight into the impact that sidechaining technology has on the complexity and security of a decentralized application. The method to achieve this insight is the design of a network structure which can be applied to decentralized applications implemented on a network of sidechains. In order to gain insight into the security and complexity impacts this proposed network structure imposes, it is applied to a strategy game implemented on a sidechain.
CHAPTER 2
Theoretical background
2.1
Blockchain Technology
As mentioned above, a blockchain is a growing list of records (blocks). Blocks contain transactions made on the blockchain. The consensus mechanism decides what user(s) get the privilege of adding these blocks to the blockchain. The workings of blockchain technology can be described by defining the following layers: a network layer, a blockchain layer, and an application layer.
2.1.1
Network Layer
Blockchain implementations use a peer-to-peer network layer as underlying infrastructure. As opposed to a traditional client-server model, where a central authority stores and manages all data, in a peer-to-peer network this governing role is executed by assigned nodes in the network. Depending on the blockchain implementation, this governing role is distributed among all nodes in the network or among selected validator nodes. Each validator node in the network stores an identical copy of the information contained in that network. Blockchain technology utilizes this peer-to-peer structure to provide its participants with a distributed ledger. This distributed ledger is used to record transactions between two users in the network. Each node in the peer-to-peer network is equal, however, they can have different roles within the network. A node can, for example, be a full node or a lightweight node. A full node stores a copy of the full blockchain. A lightweight node uses a full node as intermediary and only stores the latest block headers. Full nodes require significantly more computing power than lightweight nodes. Full nodes and lightweight nodes cooperate to provide a valid record of transactions for every user who wants to access a blockchain [2].
2.1.2
Blockchain Layer
The blockchain layer consists of the following two main components: a consensus mechanism, and state transition functions [2].
Consensus Mechanisms
According to Antonopoulos et al. [2], consensus regarding blockchain technology can be seen as a system of strict rules without rulers. Consensus mechanisms are put in place to distribute block creation among validator nodes. The rules defined in the consensus mechanism are designed to incentivize validators to behave fairly. By reaching consensus, every user in the distributed network is assured to have access to the same valid record of transactions. A great deal of research is currently being done on consensus mechanisms, as the performance of a blockchain is strongly dependent on it.
An important part of the consensus mechanism is the mining process. It is this process that defines how validators verify and add blocks to a blockchain obeying the rules defined by the consensus mechanism. Contained in these blocks are the transactions that happened on the
network. The consensus mechanism decides which nodes in the network get to add new blocks to the blockchain and collect the fees and/or rewards connected to successful block addition. The consensus mechanism and mining process as defined by Ethereum are described in section 2.2.
State Transition Functions
Transactions are signed messages that trigger a change of state of the blockchain. The state machine is in charge of handling these state changes. State changes can be triggered by the transfer of assets, like Bitcoin [26], from one user to another. However, a change of state can also be instigated by a number of other transactions. In Ethereum [6] for example, the state can be changed by invoking methods on a smart contract. The Ethereum state machine and smart contracts are explained in more detail in section 2.2. Validated transactions are included in a block and added to the blockchain. In an open blockchain implementation like Bitcoin, all transactions are visible for every user. Furthermore, transactions are immutable, meaning that once they are completed, they can not be altered.
2.1.3
Application Layer
The layer visible for blockchain application end-users is the application layer. Applications running on the blockchain application layer are called decentralized applications (DApps). These applications are backed by the consensus and security mechanisms implemented by the blockchain they are running on. An example of an application that is particularly suited to be implemented as a DApp is an auction app. In this auction app users can sell digital assets. Other users are able to place bids on the digital assets up for auction. By implementing this auction app on a blockchain, the governance of the app is distributed across its validator(s). The level of decentralization of the auction app is strongly dependent on the consensus mechanism used. The most used blockchain implementation used for creating DApps is Ethereum [6].
2.2
Ethereum
Ethereum [6] is one of the leading technologies utilizing a blockchain in today’s market. Ethereum is known for its smart contract functionality. It is this smart contract based functionality that makes the Ethereum platform extremely flexible and adaptable for a wide range of applications. Ethereum developed its own cryptocurrency called Ether. However, Ethereum does not limit itself to this cryptocurrency. Users on the Ethereum network have the ability to create their own assets in the form of tokens. A token defines something ownable, like a digital trading card. Tokens are explained in more detail in section 2.2.4. When using the same layer analogy as in the previous section, the Ethereum blockchain layer can be divided in three core mechanisms: the Ethereum Virtual Machine (EVM), smart contracts, and the consensus mechanism.
2.2.1
Ethereum EVM
In essence, the Ethereum network can be seen as a transaction-based state machine [2]. This means that whenever a transaction is completed on the network, the Ethereum state has to be changed in order to keep nodes up-to-date. The challenge that arises here is the need to change the state for every node hosting the blockchain to assure that each node is accessing the same record of transactions. This is where the Ethereum Virtual Machine (EVM) comes into place. The EVM handles state transitions in the blockchain. State transitions are invoked by users creating, accepting, and ordering transactions. When a transaction invokes smart contract code execution, the EVM is triggered to compute a valid state transition and update the Ethereum state. In order for a smart contract to trigger state transitions on the EVM, it has to be compiled to EVM bytecode. Each Ethereum node runs an instance of the EVM. Whenever a state transition is handled by the EVM, each node hosting the blockchain has to execute the
2.2.2
Smart Contracts
The term smart contract is somewhat misleading because it is does not necessarily just represent a contract, but rather an immutable computer program that runs deterministically in the context of the Ethereum Virtual Machine (EVM). Smart contracts serve as an agreement between users on a blockchain. When running a certain application on the Ethereum platform, each user has to obey the rules stated in the smart contract(s) defining this application [9]. According to Antonopoulos et al. [2], Smart contracts have the following characteristics :
• Smart contracts are immutable, meaning that once deployed, a smart contract can not be altered.
• Smart contracts are deterministic, meaning input given to a smart contract will always be processed the same way.
• Smart contracts operate within the EVM context. This context is limited, meaning smart contracts can only access their own state, the context of the transaction that consulted the smart contract, and information about most recent blocks.
Smart contracts are executed when a transaction invokes the smart contract or when it gets called by another smart contract. Smart contracts can be written in a number of programming languages. The programming language used in this thesis is Solidity [35].
The workings of a smart contract can best be explained by an example. Say you want to implement a dice rolling game on Ethereum. A smart contract can be deployed handling both the game logic and the transfer of assets to the winning player. If Alice and Bob want to play a game betting 1 Ether each, they both transfer 1 Ether to the smart contract. These assets are frozen by the smart contract until the game is over. Alice and Bob invoke a function on the smart contract rolling a dice. The smart contract determines who won, and based on the result, transfers the 2 Ether to the winning player. Instead of a single controlling entity (like a casino), the betting game is validated by one or more validators, depending on the consensus mechanism.
2.2.3
Consensus Mechanisms
As mentioned in the previous section, consensus mechanisms are used to ensure that all par-ticipants in the network agree on a system-wide state. It is important for all nodes to reach consensus on which blocks are legitimate and therefore can be added to the blockchain in order to make sure every node in the network uses the same blockchain. The consensus mechanism used by Ethereum is based on proof-of-work (PoW) [18]. However, due to scaling issues, Ethereum is planning to transition to a consensus mechanism based on proof-of-stake (PoS) [21].
Proof-of-Work (PoW)
In a Proof-of-Work based consensus mechanism, miners have to solve computationally complex problems as part of the competition to add a new block to the blockchain. Miners are incentivized to partake in this competition because of the rewards attached to the successful creation of a block. A block creator is rewarded with the fees associated to the transactions included in a block and an additional reward in the form of Ether. Furthermore, miners are incentivized to behave fairly because of the energy costs associated to solving the computationally complex problems. When a node behaves maliciously, it risks to waste the money spent on electricity and mining gear needed to participate in mining. This balance of risk and reward incentivizes nodes to behave fairly [2]. The PoW mechanism used by Ethereum is called Ethash. The computationally complex problem Ethash uses includes the analysis of a directed acyclic graph (DAG) [6].
Proof Of Stake (PoS)
In a Proof-of-Stake mechanism, a node can become a validator by staking part of its assets. These staked assets are frozen and serve as an incentive mechanism to behave fairly. If a val-idator behaves unfairly it loses part of its stake. Block creators are chosen by a lottery. This lottery can be seen as a wheel of fortune. In this wheel of fortune, the size of a validator’s slice
is dependent on the validator’s stake. The higher the amount staked, the higher the chances of getting elected to create a new block. In order to assure valid blocks, validators take turns voting for the next valid block [2]. Validators who vote for blocks that are eventually rejected by the majority lose part of their stake. Validators who vote for blocks that are eventually accepted by the majority get rewarded. In this way, validators are incentivized to vote for valid blocks. After each voting process, the wheel of fortune is turned and a validator is elected to create the new block.
Transferring from a system where miners have to use computing power to a system where a miner simply has to stake some assets drastically decreases the time and energy usage for a miner to add a block. It is this gain in performance that makes the PoS consensus mechanism suitable for highly-scalable DApps.
2.2.4
Tokens
On top of Ethereum’s own cryptocurrency (Ether), Ethereum also supports tokens. Tokens can represent anything that can be owned [7]. Take for example CryptoKitties. CryptoKitties1 is a
game centered around collectible creatures called CryptoKitties. In this game, each CryptoKitty is represented by a token. Tokens, thus dramatically broaden the application possibilities of decentralized applications. Especially for decentralized games, tokens are particularly useful as they can represent game components such as unique tradable cards. The two main token standards used in this thesis are: ERC-20 and ERC-721 [23].
ERC-20
ERC-20 is a token standard used to describe fungible tokens [12]. Using the ERC-20 standard, a user can define a class of identical tokens. The ERC-20 standard defines the following function-ality: a function to get the total supply of a certain token, a function to see how much of a token a user owns, and functions to safely transfer tokens from one user to another. ERC-20 tokens can either have a fixed total supply or can be mintable. The total supply of mintable ERC-20 tokens can be increased at any time, simply by minting new amounts of that token. The ERC-20 standard can best be described by an example. Say you implement a game in which users can own gold coins. All gold coins issued by the game are identical and thus interchangeable. In this situation an ERC-20 token could be created representing a gold coin. The implementer can chose to define a total supply, or can chose to make it a mintable token. Players can transfer their gold coins to other players and vice-versa.
ERC-721
ERC-721 [13] is a token standard used to describe non-fungible tokens. The functions defined in the standard are similar to that of the 20 token. However, the main difference with ERC-20 is that ERC-721 tokens are unique (the total supply is always 1). Each ERC-721 token is assigned a unique ID making them non-fungible. ERC-721 tokens can be explained by extending the game described above to allow users to own a unique sword. Each sword would now be represented by its own ERC-721 token with a unique ID associated to it. Because each sword is now unique, attributes like striking-power, can be associated to it. Now, when a player trades his sword for another, he obtains a different sword with potentially different attributes.
1
2.2.5
Security
Security regarding the Ethereum platform can be divided in two focuses: an Ethereum platform related focus and a focus related to the smart contracts operating on top of that network.
Ethereum Platform
Ethereum’s security is strongly dependent on the consensus mechanism used. It is the consensus mechanism that incentivizes validators to behave fairly. As described above, Ethereum provides its miners with a reward when they successfully validate and mine a block. When a network increases in popularity, more people will start mining blocks in order to profit from these rewards. Ethereum, being a self-regulating network, will adjust the difficulty of mining to maintain an average mining rate of 1 block every 12 seconds [9]. When the market price of a cryptocurrency drops, miners will leave the network because they are not making as high of a profit anymore. Fewer miners results in a higher vulnerability for attacks because there are fewer nodes validating the blockchain.
Smart Contracts
Security mechanisms regarding smart contracts are heavily dependent on the programming lan-guage they were written in and the actual implementation itself. When writing smart contracts, developers have to make sure their code is secure through both manual and automatic code analysis. A step by step guide on creating safe smart contracts is written by Delmolino et al. [10]. In the survey of attacks on Ethereum smart contracts conducted by Nicola Atzei et al. [3], 6 out of 12 vulnerabilities originated from smart contract implementations. The reason that smart contracts impose a security vulnerability is their design. Smart contracts are designed to facilitate the possibility of creating any kind of application on a blockchain. This flexibility is one of the core principles of Ethereum, but also means higher vulnerability for attacks because the contracts are as safe as their creator makes them. An example of an attack on smart contracts is the DAO (distributed autonomous organization) attack. The DAO was built as decentralized crowd-funding platform running on smart contracts and raised more than $117 Million [32]. In 2016, a hacker managed to steal $70 million worth of Ether from the DAO smart contract because of flaws in the smart contract’s code [24].
2.3
Scalability Issues of Current Blockchain Implementations
As discussed in the introduction, the main challenge today’s blockchain applications face is scalability. Ethereum uses a control mechanism to keep the blockchain decentralized and secure. The three main factors in place for this control mechanism are: fixed block sizes, transaction fees, and a proof of work consensus mechanism. These three factors assure a safe, valid and decentralized blockchain, but also have negative influence on the scalability of Ethereum.
Fixed Block Size
Fixed block sizes limit scalability [20]. Say, for example, we want Bitcoin to be able to handle the same number of transactions as the Visa payment network. At its peak, the Visa payment network was able to handle 47.000 transactions per second [36]. According to Poon et al. [31], in order for Bitcoin to match this rate, a capacity of 8 gigabytes per Bitcoin block, every 10 minutes is needed. These numbers result in a growth of over 400 terabytes of data per year, which have to be distributed to every full node in the Bitcoin network. Only nodes with sufficient resources will be able to handle these large amounts of data. Smaller nodes will have to trust the limited number of big nodes in order to access the current state of the blockchain. With only a few big nodes hosting the blockchain, the promise of decentralization is not fully adhered to. Thus, the reason many blockchain implementations have a fixed block size, is to ensure that every node is able to cooperate on that blockchain.
Transaction Fees
In order to incentivize miners to add blocks containing transactions to the blockchain, the trans-action fee was introduced. However, for large volumes of transtrans-actions, these transtrans-action fees can become expensive. Say for example, Alice wants to send 1 million transactions of 1 Ether to Bob. If the transaction fee is set at 0.0001 Ether, this adds up to a total transaction cost of 100 Ether. Compared to the transaction costs of sending just one transaction of 1 million Ether, the costs are considerably higher.
Proof of Work
A vast number of today’s blockchain implementations use a proof of work [18] consensus mecha-nism in order to ensure an accurate record of transactions. However, this proof of work mechamecha-nism results in more energy consumption and longer block addition times and thus higher costs [5]. These consequences negatively influence the scalability of blockchain applications using a proof of work mechanism.
2.4
Sidechaining
In order for the Ethereum platform to be able to handle big multi-user DApps, scalability so-lutions will have to be put in place. One of the prominently proposed scalability soso-lutions is sidechaining. Sidechaining technology uses a secondary layer operating on top of a blockchain (the parent chain). This secondary layer can be described as a blockchain operating on top of another blockchain. A sidechain is connected to its parent chain using a two-way peg [4], meaning assets (like Ether) are interchangeable between the parent and child chain. This inter-connectivity allows for a tree network of sidechains originating from the root Ethereum chain. Users can transfer their assets onto a sidechain, and make transactions to other users on that same sidechain. When the user is done transferring assets on the sidechain, he/she can exit back to the parent chain with his/her new balance. Sidechains run independent from their parent chain, meaning the parent chain does not have to be consulted on every transaction. To stay in sync with the parent chain, sidechains send periodic state updates. By using this structure, the only transaction costs that have to be paid on the parent chain are the ones for the state updates and the exit and entry transactions. Sidechains are independent, meaning they are responsible for their own security and consensus mechanisms [4]. The fact that sidechains are connected to their parent chain allows users to exit a sidechain at any point in time and fall back on the security of the parent chain. The workings of a sidechain are illustrated by the following figure:
Figure 2.1: Workings of a sidechain operating on top of its parent chain. In this figure, the parent chain can ether represent the Ethereum root chain or another sidechain.
2.4.1
Consensus Mechanisms
As mentioned above, sidechains are responsible for their own consensus mechanisms. Past re-search ([5], [18]) has concluded that the PoW consensus mechanism is one of the factors negatively influencing scalability. Therefore most sidechaining implementations explore alternative consen-sus mechanisms like Proof of Authority [28] or Proof of Stake [5]. Each sidechain needs to have block producers and validators. The process of validating and adding blocks is strongly depen-dent on the consensus mechanism used. The consensus mechanism used in the proposed network structure and the strategy game implementation described in this thesis is explained in section 3.1.1.
2.4.2
Opportunities
The independence of sidechains is a strong enabler for blockchain technology. First and foremost, it allows for faster transactions. There are two main mechanisms that influence transaction speed: the consensus mechanism, and block mining frequency. As mentioned above, sidechains are independent, meaning they have control over these two mechanisms. The combination of a more efficient consensus mechanism, and a higher block mining frequency, results in higher potential throughput (transactions/second).
Secondly, sidechains allow for cheaper transactions. Depending on the sidechain implemen-tation used, transaction-fees can be very small or even non-existent. This has to do with the fact that sidechains are in charge of their own consensus mechanisms and therefore can define their own transaction costs. Users can be incentivized to behave fairly in ways other than just transaction fees. Punishments on fraudulent behaviour, for example, can be an incentive for users to behave fairly.
Lastly, sidechain implementations allow for better scalability. Apart from the higher through-put that can be reached, sidechaining networks can grow indefinitely. Sidechains can have child chains (in the form of another sidechain) of their own. Nested sidechains can form a hierarchical tree network in which each node can handle transactions independently. At the root of this tree lies the root chain, for example the Ethereum main network. In theory, this tree of sidechains can grow indefinitely and thus is able to handle a significantly higher number of transactions per second compared to a traditional blockchain. The following figure displays a tree of sidechains:
2.4.3
Vulnerabilities
The usage of sidechaining technology results in a number of deficiencies. These deficiencies arise in three main areas: the consensus mechanism, fraudulent transfers, and complexity.
Consensus Mechanism
Security vulnerabilities mainly arise from the fact that sidechains are responsible for their own consensus mechanism [4]. Sidechain implementations with a weak security due to an insufficient consensus mechanism are more susceptible to fraudulent transfers.
Another area that complicates ensuring a valid record of transactions is validation. Depending on the consensus mechanism used, trust has to be put in a single validating entity, or a number of validator nodes in the network. These validators need to be motivated to monitor transactions. Ethereum motivates its miners to validate and create blocks by offering a reward in the form of Ether on top of collected transaction fees. However, Ether rewards are not possible on sidechains as Ether can not be created on a sidechain. Transactions fees being the only profit from mining blocks might not be enough for nodes to partake in the mining process. Furthermore, users on a sidechain need to be motivated to actively monitor transactions. The Plasma sidechaining framework [30], for example, uses a combination of fees and bonds as an incentivize for validators to behave fairly. Users are incentivized to actively monitor transactions as Plasma rewards the unmasking of fraudulent validators.
Fraudulent transfers
Sidechain implementations need to have mechanisms in place that prevent users from exiting the sidechain with funds that are not theirs. Say, for example, that Bob transfers 5 Ether to a sidechain. After his funds have been released on the sidechain he transfers 2.5 Ether to Alice, who is using that same sidechain. Bob can now request to exit the sidechain claiming he has his original balance of 5 Ether using his initial deposit onto the sidechain as proof of his ownership. Bob is withholding the transaction of 2.5 Ether he made to Alice. When creating a sidechain implementation, fraud proof mechanisms need to be put in place to prevent these kinds of fraudulent transfers. The next chapter will provide an in-depth description of how the Loom sidechaining framework deals with fraudulent transactions.
Complexity
According to Back et al. [4], sidechains introduce complexity on the following two levels: the level of assets, and the network level.
When looking at assets, sidechaining contributes significantly to the complexity of the blockchain application. Assets have a nomadic nature meaning they tend to have histories on multiple sidechains. Keeping track of assets hopping sidechains adds a new layer of complexity. In or-der to be able to validate cross-sidechain transactions, additional validation mechanisms have to be put in place. This can for example be done by labeling each asset with the chain it was transferred from.
On a network level, having a tree of multiple, independent blockchains will result in added complexity. A more in-depth explanation of the added cross-chain functionality needed is give in chapter 3. Furthermore, exiting back to the main chain can be a time-consuming process when trying to exit from a deeply rooted node. An exit transaction will only transfer you assets back to the parent chain. In order to exit back to the root chain, an exit transaction has to be issued for each parent in the path to the root chain. Each exit transaction has a challenge period associated to it who’s length is defined by the sidechain itself. This challenge period allows other users to challenge the exit transaction and prevent fraudulent behaviour. When wanting to exit all the way back to the root chain, the challenge period of each parent node along the path to the root has to have passed. For example, in figure 2.3 below, when issuing an exit transaction from node G back to the root chain, path G-C-A-ROOT (the highlighted path figure 2.3a) has to be taken with a challenge period on each exit.
This problem also arises when wanting to hop between leaf nodes. Say we want to transfer assets from node G to node J in figure 2.3 below. The path G-C-A-ROOT-B-F-J (the highlighted path in figure 2.3b) has to be taken with a challenge period on each exit. In deeply rooted trees the total challenge period can become extensive.
(a) Path required to exit from node G to the root. (b) Path required to exit from node G to node J.
Figure 2.3: Visualization of paths required on exits.
Lastly, the mapping of accounts between the main chain and the sidechain adds a layer of complexity. In current sidechain implementations, in order to transfer assets from your main account (e.g., an Ethereum account) to a sidechain account, the addresses of these two accounts need to be mapped to each other [23].
2.4.4
Conclusion
Sidechaining introduces a promising and efficient way of making blockchain systems more scal-able. The main characteristics contributing to this theoretical unlimited scalability are their independence and ability to form a tree network. However, these characteristics also create room for error with regards to security and complexity. The usage of sidechains results in a constant trade-off between performance and security. This is why sidechaining is a heavily researched field, and the majority of current sidechaining implementations are still under development. The sidechaining platform used to analyze the proposed network structure and conduct the experi-ments presented in this thesis is Loom [23]. An in-depth review of the inner workings of Loom which uses Plasma Cash as linking mechanism is giving in the next chapter.
CHAPTER 3
Sidechaining Technologies
This chapter describes the sidechaining technologies used for the proposed sidechain network structure and the strategy game implementation. For the strategy game implemented in this thesis (DAppHeroes), Loom [23] is used as a sidechaining framework because of its suitability for game implementations and Plasma Cash compatibility. Loom is particularly suitable for game implementations because of its support for ERC-20 and ERC-721 tokens. Furthermore, Loom developers are working on a framework for highly scalable games deployed on a network of sidechains which is discussed in chapter 4.
3.1
Loom
Loom is a platform providing its users with the functionality to deploy sidechains. Loom is the first Ethereum scaling solution to be live in production and focuses on large-scale games and social apps [23]. At the core of Loom lies an SDK (software development kit) allowing users to deploy sidechains in a safe and efficient manner. Sidechains created with the Loom platform are called DAppChains and use the Ethereum platform as their root chain. As described above, sidechains can define their own consensus mechanisms. The consensus mechanism used by the Loom DAppChains is Delegated Proof of Stake (DPoS).
3.1.1
Delegated Proof of Stake
As explained in section 2.2.3, in a traditional proof of stake implementation, block creators are chosen by a wheel of fortune construction with the chance of being chosen dependent on the amount staked. The more a node in the network has staked, the higher the chance of being chosen to add and validate new blocks [21]. When a node gets caught validating an invalid block, it loses part of its stake. The risk of losing stake on fraudulent behaviour incentivizes validators to vote for valid blocks.
Delegated Proof of Stake [11] was created by blockchain engineer Daniel Larimer and builds on the original Proof of Stake consensus mechanism. The main difference with traditional PoS is the fact that block creators are elected instead of being pseudo-randomly selected by a wheel of fortune construction. The number of validators is capped (usually around 20) and validators get to add new blocks in a round-robin fashion. On the Loom network, a user is capable of running 2 types of nodes: validator nodes (witnesses) & delegator nodes.
Witnesses
Witnesses are nodes that have been elected by the other nodes in the network to validate and add new blocks. Witnesses benefit by collecting transaction fees associated to the blocks they add. The validation mechanism Loom uses is explained in section 3.2.2. The number of witnesses is capped to a fixed number (21-101, depending on the implementation) [33]. The voting process is continuous resulting in the witnesses always being at risk of losing their position and thus
potential profits and reputation. This risk of losing profit and reputation incentivizes validators to behave fairly. Just like in traditional PoS, each witness votes for the next valid block to be added. When a witness is caught behaving unfairly, it loses part of its stake. Witnesses get to create new blocks in a round-robin fashion, meaning block creation is equally distributed among the elected witnesses. In essence, the DPoS system is centralized because the validation and creation of blocks is controlled by the small group of witnesses. However, because of the continuous voting process, this centralized authority is controlled by voting delegators and power shifts whenever a witness behaves maliciously [33].
Delegators
Delegators support witnesses in securing the sidechain. In contrast to witnesses, delegators do not have to be online all the time as they have a controlling function and do not create blocks. Both users and nodes hosting the sidechain can become a delegator. Delegators have the power to elect witnesses. Each election round, each delegator votes for a witness by proxying (delegat-ing) part of its stake to a trusted witness [23]. The more a delegator has staked, the more voting power it has. In this way, even nodes with low stake can be elected to validate blocks as long they obtain enough votes from high-stake nodes. Delegators can also choose to delegate their voting power to other nodes in the network. A validator node cannot vote for itself directly. However, it can create a delegator on the sidechain, transfer assets to that delegator and vote for its own validator node indirectly. After the voting process has taken place, the nodes that collected the most delegated stake win and become witnesses. Delegators get to reallocate their votes every election round, giving them the possibility to remove malicious witnesses from the validator pool.
Compared to traditional PoS, an increase in performance can by gained by using DPoS [11]. This increase in performance arises because in DPoS, a limited amount of witnesses validate blocks instead of all validator nodes in the network. Furthermore, in DPoS, the process of choos-ing the next block creator is a matter of who’s next in the round robin line instead turnchoos-ing a wheel of fortune containing all nodes in the network. Performance-wise, choosing from a smaller group of validators is easier to handle. In a DPoS implementation, delegators constantly re-elect witnesses to assure the most secure and best performing validators possible with the available nodes. However, DPoS falls short in terms of level of decentralization as it requires trust as-sumptions regarding the elected group of witnesses [33].
The consensus mechanism described above offers on-chain security and consensus. However security between two linked sidechains is not guaranteed by on-chain consensus mechanisms. This is why the Loom Developers decided to collaborate with Ethereum co-founder Vitalik Buterin and his team to incorporate one of their sidechaining building blocks: Plasma Cash [30] into the Loom network. Plasma Cash offers a linking mechanism between two sidechains or between a sidechain and the root chain [16].
3.2
Plasma Cash
Plasma is a framework for building scalable blockchain applications on sidechains created by Lightning Network co-founder Joseph Poon and Ethereum co-founder Vitalik Buterin [30]. Plasma Cash is part of this framework and defines a linking mechanism assuring valid transactions to and from these sidechains. The main security promise provided by Plasma Cash is that tokens can always be redeemed on the root chain [16].
The Plasma Cash smart contracts allow a node to mint (create) a token on the Ethereum main chain along with its value in Ether as denomination. This minting mechanism turns an arbitrary amount of Ether into a token. The main property Plasma Cash uses in order to assure safe transfer of tokens is the use of unique serial numbers for each token on the sidechain. These unique serial numbers make the tokens easy to track. According to the Plasma Cash specifications [16], these unique ID’s result in the following benefits:
1. Sharded client-side validation: participants on the sidechain only need to monitor their own tokens. This decreases the load on individual participants meaning higher throughput (transactions per second) and scalability.
2. No two phase send: Plasma Cash only uses a confirmation signature sent by the receiving user after he/she has validated the history of the token. Once a transaction is validated and included in a block on the parent-chain, it can be spent immediately.
3. Support for all tokens: a unique ID can be assigned to any type of token without the need for additional complexity.
4. Minor mass exit mitigation: mass exits are less likely to happen because a malicious user must submit an exit transaction for each token he is trying to steal. Mass exits are explained in more detail later on in this section.
An implication of the Plasma Cash framework arises when trying to mint (create) a very small token. When a token’s value is very low, the transaction costs of redeeming that token from the main Ethereum chain will be higher than the value of the token itself. Therefore, extremely low value tokens are not suitable to transfer to a sidechain connected to the Ethereum main net with a Plasma Cash link. However, it is possible to mint (create) new tokens on a sidechain. These minted tokens represent no value on the root Ethereum chain but can still represent value on a sidechain.
Entering a Sidechain
Entering a sidechain requires a user on the Ethereum main chain to deposit the assets he/she would like to transfer to the Plasma Cash smart contract. Say Alice wants to transfer a token worth 5 Ether to a Loom sidechain. Alice sends the 5 Ether to the Plasma Cash smart contract. A new block including that transaction is added to main chain. The Plasma Cash smart contract assigns a unique ID to Alice’s 5 Ether creating the token. This creation process is called minting. The Plasma Cash contract also creates a valid block on the sidechain releasing Alice’s token on the sidechain. This mechanism prevents Alice from spending her 5 Ether on the main chain as those assets are locked in the Plasma Cash smart contract and will only be released in the event of a valid exit.
3.2.1
Consensus
The original Plasma framework proposes a Proof of Authority (PoA) mechanism in which block validation and creation are done by a single centralized authority called the Plasma Operator [30]. Loom on the other hand, replaces this Proof of Authority operator by a delegated proof of stake (DPoS) mechanism. By using the DPoS mechanism, the centralized operator is replaced by a limited number of elected validators (usually around 20) called witnesses. This DPoS mechanism is more decentralized than the single PoA operator, but still not truly decentralized because of the limited amount of validators. This centralization thus results in the need to implement additional security mechanisms to prevent unfair behaviour from validators. Fair behaviour is enforced by a mechanism that enables sidechain participants to challenge malicious users and validators [16]. This challenge mechanism is explained in more detail later on in this section. According to the Plasma Cash specifications [16], security mechanisms must be put in place for the following events: block creation, token transfers, and exits (leaving the sidechain withdrawing your assets back to the parent chain).
3.2.2
Block Creation
As explained in the previous section, block creation on a Loom sidechain is done by the elected witnesses in a round-robin fashion. In order to validate the transactions included in the blocks validators add, a proof-of-(non)existence mechanism is used called merkle proofs [8].
Merkle Proofs
A key concept used in block validation on a Loom sidechain is a technique called merkle proofs. These merkle proofs are based on hash trees called merkle trees. In a merkle tree, each leaf node is labelled with the hash of the data it contains. In the Loom infrastructure, this data consists of transactions. Each non-leaf node computes its hash based on the hash of its children nodes concatenated from left to right [8]. This results in the root of the tree being a hash computed based on the hashes of all other nodes in the tree. Using this structure, the existence of a node can be proven by providing all the sibling nodes needed to recompute the root hash. An example of a simple merkle proof is illustrated in figure 3.1a below. This figure illustrates the merkle proof of existence for leaf node A. Using the highlighted nodes (A, H(B), H(H(C) + H(D)) in figure 3.1a, the original root hash can be recomputed meaning that A is indeed part of the tree. Merkle proofs are efficient because a proof only requires the relevant nodes, and not the entire tree.
In blockchain technology, it can also be necessary to prove some data is not included in a tree: proof-of-non-existence. An example use case would be providing proof that a certain token was not spent. In the standard merkle tree structure described above, one would have to provide the entire tree in order to prove non-existence. This is inefficient because merkle trees can grow to be very big. Sparse merkle trees [15] were introduced to solve this problem. In a sparse merkle tree, each data entry is indexed and placed at the corresponding position in the tree. In the case of block creation on a Loom sidechain, a data entry consists of a token and its transaction history. This data entry is indexed using the unique ID assigned to each token on a sidechain. This mechanism allows nodes in the tree to be empty (null) if the data entry corresponding to that position in the tree does not exist. Proving existence still follows the same principal as proof-of-existence in a standard merkle tree.
For proof-of-non-existence one simply needs to provide proof that the node at the position of the assumed to be non-existent node does not contain a data entry and therefore equals null. Figure 3.1b below illustrates this proof-of-non-existence mechanism. The leaf nodes represent the letters A, B, C & D. Say you want to prove that C is non-existent meaning the leaf at position C is null. Using the highlighted nodes in figure 3.1b, assuming that C is null, the root hash can be reconstructed. The assumption that C is null proves to be true meaning that C is indeed non-existent.
In conclusion, sparse merkle trees provide an efficient way of proving if a certain data entry exists or not. In essence, the nodes in the tree represent key-value pares. In the Loom sidechaining implementation, the key would be a token ID and the value would be its transaction history. These sparse merkle trees can thus be used to prove the validity of a transaction made on the sidechain.
Block Creation
Transactions included on blocks are sent in the following form:
[[prev hash, prev block, (targetblock?), token id, new owner], signature]
Every time a transaction is sent, it must be included in the merkle-tree at the correct index (the token ID). It is this merkle-tree that validators use to validate blocks. A transaction spending a certain token is valid when that transaction is included in the merkle tree at the position corresponding to the token ID. This validity is proven using a proof-of-existence described above. Every time a new transaction occurs on the sidechain, it gets added to a block. Say a transaction gets added to block N, then the root of block N corresponds to the root of the sparse merkle tree of N-depth. Periodically, the current block’s root hash is submitted to the parent chain as a state update to assure connected sidechains are in sync [16]. In other words, the parent chain only stores block hashes corresponding to the root of a sparse merkle tree instead of full blocks. This sparse merkle tree contains the transactions on the sidechain. In this way, staying in sync with the parent chain is a lightweight process and the parent chain does not have to be consulted on every transaction.
Each user can access the transaction history of the sidechain at any point in time in order to actively validate transactions. A Merkle tree, gives an overview of every token active on the sidechain, including all transactions that token was included in [30]. Block creators use these merkle-trees to validate the blocks they are adding to the sidechain.
3.2.3
Token Transfers
Whenever a user on a Loom sidechain sends a token to another user, the sending user must provide the receiver with a full history of the token he/she is sending. This enables the receiving party to validate the token’s history. This history consists of:
1. A merkle-proof-of-existence for every block on the sidechain containing a transaction in which that token was spent.
2. A merkle-proof-of-non-existence for every block on the sidechain in which that token was not spent.
Using this history, the receiver of the token checks the token for validity. If the token turns out to be valid, the recipient sends a confirmation to the sender and is able to spend the token. If the transaction turns out to be invalid, the receiver can challenge the transaction.
This validation mechanism can be explained using a simple example illustrated in figure 3.2 below. Say Alice owns a token on the sidechain included in block 1. Alice decides to transfer this token to Bob. Bob verifies the token’s history and the transaction is included in block 2. In the meantime some other transaction(s) on the sidechain not involving Bob’s token create block 3. Eventually, Bob transfers his token to Charlie. Charlie validates that the token was included in blocks 1 & 2 and also validates that the token was not included in a transaction in block 3. Now Charlie is sure the coin was not double spent and accepts the transaction which gets included in block 4.
3.2.4
Exits
An exit is the mechanism used by Plasma Cash which allows participants on a Loom sidechain to safely exit the sidechain and transfer their assets back to the parent chain. This is also where the main challenge concerning security lies: what if a user tries to exit with a token that is not theirs? The mechanism assuring valid exits consist of two main components: bonds and challenges.
Whenever a user wants to issue an exit transaction, a bond has to be paid to the Plasma Cash smart contract. This bond can be seen as a loan that gets transferred back to the user when his/her exit turns out to be valid. On top of this bond, the exiting user has to submit a merkle tree including the last two transactions the token he/she is trying to exit was included in. However, the usage of a bond and a merkle proof is not enough to assure valid exits, as the exiting user can submit an outdated merkle-tree as proof of ownership of a token that is not theirs. In order to assure validity, Plasma Cash introduces a mechanism called challenging.
Any participant on the network is able to challenge an exit transaction within a certain dispute period (usually a week) [30]. This challenge consists of a merkle proof, proving the exiting user is behaving maliciously. For example, a user trying to exit with a token that has already been spent can be challenged by providing a merkle-proof containing the transaction of that token being spent. Whenever a challenger successfully invalidates an exit, the challenger receives a reward in the form of the bond paid by the exiter when the exit was initialized. This thus means that a user loses its exit bond when fraudulent behaviour is detected. The reward for proving fraudulent behaviour incentivizes participants on the sidechain to actively monitor transactions.
Challenges can be non-interactive and interactive. A non-interactive challenge offers a hard proof of the invalidity of an exit and immediately cancels the exit. An exit challenged by an interactive challenge can still be valid and allows the exiting user to respond with a proof invalidating the challenge. If this proof cannot be given, the exit is invalid and is therefore cancelled.
The Plasma Cash specification [16] lists three main challenges with regards to exits: exiting with an already spent token, exiting with a double spent token, and exiting with invalid token history. These challenges are explained using the following three examples:
Example 1
Figure 3.3 below shows a participant on a sidechain (Alice) trying to exit with a token she has already spent:
Figure 3.3: A malicious user trying to exit with an already spent token [16].
This situation is described by the following steps:
1. The transaction of Alice receiving the token is included in block 3. She transfers the token to Bob. This transfer is included in block 4.
3. Bob challenges the exit by providing a merkle-tree containing the transaction included in block 4 of Alice sending the token to him. The exit is invalidated and Bob receives Alice’s bond as a reward.
Alice is able to provide older merkle-tree proofs because on every state update, a block hash corresponding to the root of a sparse merkle-tree containing the current transaction history is submitted to the parent chain. Alice can simply provide a merkle tree of a previous state update as proof of ownership. However, all other users can also access all merkle-trees, including the newest merkle-tree that invalidates the exit as described above.
Example 2
Figure 3.4 below shows a participant on a sidechain (Charlie) trying to exit with a transaction of a double spent token.
Figure 3.4: A malicious user trying to exit with a double spent token [16].
This situation is described by the following steps:
1. Alice is a witness (part of the validator pool) and owns a token. Yhe transaction of her receiving that token is recorded in block 2.
2. Alice transfers the token to both Bob and Charlie (double spend). She can do so because she was voted a witness and has the authority to create blocks. The transfer to Bob is included in block 3 and the transfer to Charlie is included in block 4.
3. Charlie tries to exit providing block 4 as his proof of ownership.
4. Bob challenges the exit providing a merkle-tree containing the transaction included in block 3 in which he received the token from Alice.
5. Seeing that block 3 was included before block 4, Charlie’s exit is invalidated.
6. Alice is caught double spending and she loses part of her stake. She is also likely not to be voted as a witness in the next election round because of her fraudulent behaviour.
The example described above sheds light on an important security mechanism: whenever the chain needs to be validated, blocks are processed in the order that they were added. In this way, in the case of a double spend, a valid block that occurred before the block including the double spend is able to proof invalidity.
Example 3
Figure 3.5 below shows a participant on a sidechain trying to exit with invalid token history containing an invalid transaction. This invalid transaction was added by a malicious witness (validator). In this example, Bob, Charlie and Dylan conspire against Alice in order to steal her token.
Figure 3.5: A user trying to exit with an invalid token history [16].
This situation is described by the following steps:
1. Alice owns a token. The transaction of her receiving the token is included in block 2.
2. A malicious validator includes an invalid spend in block 3 transferring the token to Bob without Alice’s consent.
3. Bob receives the token, ignores the invalid history and sends a confirmation. He then transfers the token to Charlie. This transaction is included in block 4.
4. Charlie also ignores the invalid history and transfers the token to Dylan. The transaction is included in block 5.
5. Dylan also ignores token’s history and he tries to steal the token. He issues an exit trans-action providing a merkle-tree containing the transtrans-actions in block 4 & 5 as his proof of ownership.
6. Alice notices her token being claimed and issues an interactive challenge providing a merkle-tree containing the transactions included in blocks 1 & 2, being the last valid transactions of that token.
7. The exiting user is obliged to respond with a proof of a valid child of the transaction included in block 2. This valid child does not exist, as the transaction in block 3 is invalid. The exit is proven invalid and Alice receives the bond payed by Dylan. Furthermore, the malicious validator loses part of its stake as a penalty for his unfair behaviour.
This mechanism also works for blocks being withheld. In this case, when the exiting user is chal-lenged to provide a valid child of the transaction included in block 2, the transaction included in block 3 is still invalid as it was never included in the blockchain, making the exit invalid.
In the examples described above, the users trying to exit the sidechain were not part of the elected validator pool. Malicious validators pose a serious threat to a sidechain because they have the authority to add blocks to the blockchain. An example attack from a validator would be to include a block claiming the ownership of one or more tokens owned by other users on the sidechain, and then exit the sidechain claiming these tokens on the main chain. Currently the security mechanism in place for this threat is called a mass exit, in which all other participants exit the chain providing proof that the validator was behaving unfairly.
3.2.5
Mass Exits
The mass exit mechanism can best be explained by an example. Say Alice and Bob are partici-pants on a sidechain and Charlie is a validator elected by the DPoS consensus mechanism. Bob
token transfers to and from the sidechain contains 11 Ether. The following situation illustrates the workings of a mass exit:
1. Once on the sidechain, Alice transfers token B to Bob. The transaction from Alice to Bob was proven to be valid and has been included in a block. At this point Alice owns token C and Bob owns tokens A & B.
2. At some point Charlie decides to abuse his validator privileges and he adds a block to the sidechain giving him (unfair) ownership of tokens A, B & C. Charlie issues an exit transaction and a challenge period is initiated to allow other users to challenge Charlie’s exit.
3. During this challenge period, both Alice and Bob notice Charlie is claiming to own their tokens as they are actively monitoring the transactions on the sidechain. Both Alice and Bob (and in the case of a larger network, all other participants) decide to exit creating a mass exit.
4. The Plasma Cash contract handles exits based on the order of transactions included in the exits. The first transactions the Plasma Cash contract encounters are included in Alice’s exit. This exit contains the transactions proving Alice’s ownership of tokens B & C and the transaction of token B from her to Bob. This exit thus provides proof that Alice was left with token C worth 5 Ether, so the Plasma Cash contract automatically transfers 5 Ether back to Alice.
5. Next, Bob’s exit is handled. His exit includes the transaction proving his ownership of token A and the transaction of him receiving token B. This exit provides proof that Bob now owns 2 tokens (A & B), worth 6 Ether in total, so the Plasma Cash contract automatically transfers 6 Ether back to Bob.
6. Next the Plasma Cash contract encounters the exit issued by the malicious validator con-taining the transactions of him claiming to own tokens A, B & C. However, there is no Ether left in the Plasma Cash smart contract, as the exits issued by Bob and Alice were already validated and Ether has already been re-distributed. The malicious validator does not receive the 11 Ether he claimed to own and is punished by not getting his exit bond back.
The fact that the Plasma Cash contract handles exits in the order of transactions included in it, thus prevents malicious validators from stealing funds. However, the mass exit solution is a costly and inefficient solution as it leaves the sidechain without participants. In order for a mass exit to work, every participant needs to have enough incentive to actually leave the sidechain, which is not always the case. The fact that Plasma Cash assigns a unique token ID to each token transferred to the sidechain makes mass exits slightly less probable because a malicious validator has to issue an exit transaction for each token he/she wishes to steal. In this way, stealing a large number of tokens becomes an expensive operation [16]. The probability of a mass exit is also lowered because of the bond that needs to be paid when issuing an exit transaction. The risk of losing this bond incentivizes validators not to funnel tokens they do not own to themselves.
3.3
Conclusion
The Loom platform offers an efficient and secure scaling solution for decentralized applications. The incorporation of Plasma Cash links results in a framework that is particularly useful for nested sidechaining implementations. The main benefits from using the Loom framework are scalability, efficient block creation by using DPoS, efficient validation by using merkle proofs, and the assurance of being able to fall back on the root chain security by issuing an exit. However, the main challenges that arise from using the Loom platform concern centralized validators and the inefficient mass exit mechanism. The Loom platform is still under development and therefore these issues are actively being researched.
CHAPTER 4
Network Structure Design for Secure
Nested Sidechaining
The previous chapter explored sidechaining as a scaling solution for blockchain technology. In order to review the impact sidechaining has on security and complexity of decentralized applica-tions, this thesis proposes a framework that can be used to structure a network of sidechains in a secure and efficient manner. In order to review the possibilities and vulnerabilities regarding this proposed network structure, it is applied to a strategy game implemented on a Loom sidechain: DAppHeroes.
4.1
DAppHeroes: a Strategy Game on a Sidechain
DAppHeroes1 is a multiplayer strategy game implemented on a Loom sidechain. To join the game, a player creates a hero. This hero has the following attributes: name, level, number of wins, attack, defense, health and DAppHeroe coins. A newly created hero starts at level 1 with 1 attack, 1 defense, and 100 health. DAppHero coins can be purchased with Ether or earned by winning staked matches. The main game features implemented are: a battle arena and a marketplace. Screen-shots of DAppHeroes gameplay are illustrated in appendix A.
Battle Arena
Players can enter the battle arena and attack other players. Only players present in the battle arena can be attacked. When two players agree on battling each other, a turn based battle is launched. Each turn, a player can decide to either attack or use a potion. The damage done by a hit is calculated by the attacking player’s attack level and the defending player’s defense level. The battle is over when one of the players is out of health. By winning a battle, a player gains xp used to level up. Players can also chose to stake DAppHero coins on their battle which the winner will receive when the battle is over. Attack and defense levels can increase by purchasing items from the market place.
Market Place
In the market place, players can buy and sell items. These items are represented by non-fungible ERC-721 tokens meaning they are unique. Items can be bought with fungible ERC-20 DAppHero coins. Each item has certain attributes assigned to it. For example, a sword will increase a player’s attack level by 20 as long as the player owns that token. Potion tokens will temporarily increase a player’s skills during battle. A health potion, for example, will increase the player’s health by 10.
