DREP Chain A Novel Sharding Infrastructure Technical Whitepaer

Transcription

1 DREP Chain A Novel Sharding Infrastructure Technical Whitepaer DREP foundation V1.0.1 June 18, 2018 Abstract We present DREP chain, a novel scale-out blockchain protocol without compromising decentralization or security. On the basis of Sharding, DREP chain conducts a mutually independent governance mechanism for the two-layer structure as well as within shards. DREP chain architecture is comprised of a main chain and shard chains separately in PoS and modified PBFT scheme, and varied in assigned smart contracts, so as to optimize scalability in parallel and significantly decrease coupling between chains. Both in-shard and cross-shard transactions are committed atomically or eventually aborted. DREP chain provides a PBFT-based four-phase commit protocol for crossshard transactions, which guarantees both atomicity and security. I. INTRODUCTION The fundamental limitation of scalability becomes the bottleneck of the blockchainpenetration rate in all walks of life. Diversified approaches to modify consensus mechanism or protocol parameters, finally turn out not effective, even sacrifice either permission-less decentralization or sustainable security. DREP chain is based on Sharding, the technology to divide nodes into multiple subsets (shards), which process the different groups of transactions in parallel. Besides, when more validators participate in, the processing capacity will be increased horizontally. As a result, a growing number of nodes can scale up the transaction rate, instead of aggravating the processing load. In addition, DREP keeps the data stored and managed in shards separately, namely statesharding, which eases the burden of each node to store transactions, execute smart contracts and maintain normal operation. For further improvement of processing efficiency, DREP chain conducts a comparatively independent governance structure, in which the upper-level chain and shards execute the assigned smart contracts, and achieve different consensus correspondingly. In order to guarantee the processing speed and prevent Sybil-attacks, the main chain adopts Proof-of-Stake scheme. While shards will adopt a modified PBFT, on the one hand, to improve speed for less miners in shards; on the other hand, to reduce the traffic and processing overhead, because modified PBFT removes pairwise communication among nodes within a shard, and avoids transmitting a mass of signature information. As a result, the simplified communication with governor and utilization of multi-signature reduce the message volume remarkably. Innovatively, DREP chain adopts a PBFTbased four-phase commit mechanisms to guarantee the atomicity. Aimed at reducing the cost of achieving consensus in cross-shard transactions, we harness the integrated techniques of PBFT scheme and multi-signature mechanism, and overcome the shortages of two-phase commit protocol. II. PHILOSOPHY DREP s design philosophy is to build a fully distributed system to allow for higher throughput and lower cost per transaction, while still providing for a decentralized, trustless, auditable system. A. Sharding Techniques The key point of sharding is dividing the mining network into smaller groups, each of which processes transactions in parallel with each other. Such group is called a shard.

2 In the existing sharding techniques of blockchains, transactions are assigned to a shard according to a consensus which varies among different implementations. Each shard processes the transactions assigned to them and then generates a corresponding block comprised of all of the processed transactions. Furthermore, the transaction process in a single shard is parallel to the ones in other shards. Therefore, the speed of transaction processes can be significantly improved, in that if one shard can process m transactions per second, then n shards can process m n transactions per second. However, the existing sharding techniques of blockchains always have each node in each shard store and maintain all the blocks, even including the blocks which are not generated by the shard itself. Consequently a node may store and maintain a lot of data it no longer needs, which could cause an extremely high storage overhead. The following proposed designs will further explain how DREP mitigate these problems. B. DREP Chain s Structure The DREP chain proposes a novel blockchain structure, in which the entire chain is divided into two levels, the high level called the main chain and the low level comprised of the shard chains. Each node is assigned to a specified shard, maintaining the data both on the main chain and on its assigned shard chain. Note that 1) all nodes maintain the same main chain, 2) the nodes in the same shard maintain the same shard chain, and ) the nodes in different shards maintain different shard chains. Different shards process different transactions. A transaction is thus assigned to a specific shard. It is also classified into two categories according to whether its assigned shard interacts with other shards when processing such transaction. An in-shard transaction refers to a transaction that does not call any function of a smart contract outside its assigned shard. Such transaction is processed in a relatively smooth and swift way in its assigned shard and there exists no interactions between different shards. A cross-shard transaction refers to a transaction that has to call a function of a smart contract outside its assigned shard. In such case, there exists interactions between different shards. To process such cross-shard transaction, different shards need to work together, such as forwarding a transaction to other shards and waiting for the result. However, such interactions could interrupt the transaction processes in other shards, and thus decrease the parallelization of transaction process. Therefore, we propose DREP Chain s sharding to address the possible disturbing crossshard transactions. C. DREP Chain s Sharding The DREP chain is designed to divide the smart contracts into different shards according to their addresses. Specifically, the DREP chain classifies a transaction according to the address of such transaction s smart contract, and then forwards such transaction to its corresponding shard for processing. Additionally, a smart contract in a specific shard may still need to interact with another smart contract in another shard. Thus the DREP chain provides a secure and efficient mechanism for such interaction. Such practice has the following advantages over other sharding techniques: 1) Higher parallelization: It is evidently faster and more efficient for different shards to process their own transactions and have few interactions with each other. 2) Lower storage overhead: Since each shard only needs to store the data of its assigned smart contracts instead of all the smart contracts running on the whole blockchain, the storage overhead would be lower. ) Higher independency: A specific shard does not need to engage with other shards, so the whole system has a higher independency, which improves the speed of the DREP chain. It is noteworthy that there also exists certain special smart contracts from which a large number of other smart contracts are based on and will interact with, such as the DREP token ledger and the smart contract containing the sharding consensus. For a better performance, such smart contracts have to run on the main chain, which, however, does not bring a high storage overhead to the nodes because there are not many of such smart contracts. D. System Features The DREP chain has the following features:

3 Figure 1. The structure of the DREP chain 1) A novel two-level structure: The DREP chain has two levels, the high level (the main chain) and the low level (comprised of the shard chains). The most fundamental smart contracts run on the main chain whereas others runs on their assigned shard chains. Such structure makes the data stored in any chain totally isolated from the ones stored in other chains, which significantly decreases coupling between chains and thus improves the scalability of the network. 2) Four-phase commit protocol: Both inshard and cross-shard transactions are committed atomically or eventually aborted. The DREP chain provides a PBFT-based four-phase commit protocol for cross-shard transactions, which guarantees both atomicity and security. ) Higher speed: In consideration of not only the speed and the security, but also the scale of the chain, we have adopted two types of consensus protocols in the DREP chain, the Proof-of- Stake protocol in the main chain and the PBFT protocol in the shard chains. Each protocol will improve the speed of its corresponding chain. 4) Higher independency: Unlike the existing sharding techniques where each node is informed of every transaction, the DREP chain divide the entire chain into smaller shards according to the addresses of the smart contracts. Therefore, the nodes in a specific shard only need to know the transactions of the assigned smart contracts. 5) Lower overhead: Since the DREP chain divide the entire chain into smaller shards according to the addresses of the smart contracts, each node only need to store the data of its assigned smart contracts instead of the data of the whole DREP chain and thus gains a lower memory and storage overhead. A. Accounts III. TERMINOLOGIES The DREP chain is an account-based system. There are two types of accounts: the common accounts and the smart contract accounts. A common account is created by generating an private/public key whereas a smart contract account is created by another account. B. Addresses Each account is assigned an address, which is a 180-bit integer. For formal verification, the account address will be illustrated in a mathematical format. Let A denote an address. Then A Integer A 0 The address for a common account is based on the account s private/public key: A = hash(pk(s))

4 where s is the account s private key, pk(s) returns the public key of such account, and the result is finally hashed to the address. The address for a contract account is based on the address of its creator and the number of the transactions the creator account has sent: A = hash(a n) where A is the address of the creator s account, and n is the number of the transactions the creator account has sent. C. States Each account is associated with an account state, which is actually a key-value map. Such a map maps a string to a union of Object and a map of the same type. It stores everything associated with its corresponding account, such as the account s token and some other values stored by it. In the DREP s ecosystem, the other values mainly refer to reputation values, which comprises of the two key elements reputation value and platform tokens in the reputation quantifying and monetizing mechanism. For formal verification, the states will be illustrated in the following mathematical format: S String Comp Comp Object S As for a normal account, its state only maps a string to an object, such as the account s tokens and other information. As for a contract account, its state maps a string to not only an object similar to a normal account, but also a map of the same type, which records the information stored by other accounts. To store and maintain the states of all the accounts, the DREP chain divides a whole account state into several smaller sub-states, each substate stored in the main chain or a shard. Each node in the network maintains an account substate with respect to a specific smart contract. Therefore, an account s whole state (global state) is the union of all the sub-states. S G = i Shards Specifically, the DREP chain does not store the account s global states. Instead, it stores the S i account sub-states in different places depending on the smart contracts the sub-states belong to. If the smart contract is maintained in a specific shard, then all the nodes within the shard store all the sub-states of such smart contract. If the smart contract is maintained in the main chain, then all the nodes in the DREP network store all the sub-states of such smart contract. D. Transaction In the DREP chain, almost everything has to be changed by a transaction. Besides the traditional information such as the version number, the destination account address, the transfer value, etc., a DREP s transaction also contains two special data, its parent transaction IDs and a nonce value. The parent transactions refer to a list of transactions, the previous one proposing the latter one, similar to a call stack of a function. The nonce value indicates the number of transactions sent by this transaction s sender. A transaction can be regarded as a transition between states. In formal verification, a transaction T can be regarded as a function taking a state as a parameter and returning a new state: T S S Furthermore, if a transaction is processed, we say that a transition occurs from the previous state S 1 to the current state S 2, where S 2 = T(S 1 ) E. Governance Contract c o n t r a c t G o v e r n a n c e C o n t r a c t { / Get t h e c o n f i g u r a t i o n s o f t h e whole c h a i n. / f u n c t i o n g e t C o n f i g ( ) p u b l i c r e t u r n s ( Config ) ; / J o i n t h e network. I f s u c c e s s, t h e f u n c t i o n r e t u r n s t h e shard i n f o. / f u n c t i o n j o i n ( L o c a l C o n f i g l o c a l C o n f i g ) p u b l i c r e t u r n s ( S h a r d I n f o ) ; / Quit t h e network. / f u n c t i o n q u i t ( )

5 p u b l i c r e t u r n s ( b ool ) ; / Report an e r r o r, such as a unreached node or a b y z a n t i n e node. / f u n c t i o n r e p o r t E r r o r ( E r r o r I n f o e r r o r I n f o ) p u b l i c r e t u r n s ( b ool ) ; / A s s i g n t h e t r a n s a c t i o n. I f s u c c e s s, t h e f u n c t i o n r e t u r n s t h e i n f o o f t h e a s s i g n e d shard. / f u n c t i o n a s s i g n T r a n s a c t i o n ( T r a n s a c t i o n t r a n s a c t i o n ) p u b l i c r e t u r n s ( S h a r d I n f o ) ; There exists a special smart contract in the DREP chain, which is called the governance contract. The governance contract acts as the leader of the whole chain, providing the others with the configurations, the transaction assignments and the information of each shard. Specifically, it provides the following functions: 1) Chain configurations: Such configurations includes the current epoch, the number of blocks in each epoch, the shard number and the number of the nodes in each shard. 2) Node assignment: When a node joins the network, the governance contract determines the shard such node will be assigned to. ) Shard information: A node may inquire from the governance contract the information of a specific shard, such as the shard governor, the miners and other nodes in the shard. 4) Shard management: When a node joins the network, exits, or is detected as the byzantine node by others, the governance contract has to store the record for later use. 5) Transaction assignment: When a transaction is proposed, the governance contract assigns it to a specific shard. A. Nodes IV. STRUCTURE 1) Node type: There are two types of nodes in the DREP chain: the miner nodes and the common nodes. A miner node is elected at a specific time of each mining epoch and is responsible for generating and validating blocks according to the consensus protocol. A common node is a node that fails in the election and thus only needs to store blocks and maintain chains. 2) Node storage: Each node in the DREP chain runs two blockchains: one is the main chain and the other one is the shard chain (i.e. the chain generated by such node s assigned shard). For formal verification, the storages will also be illustrated in a mathematical format. Let C m denote the main chain and C si denote the i- th shard chain, then the whole chain C can be denoted as the following: C = C m C S0 C S1 = C m i Shards C Si Each node also maintains a table which records the IP addresses, the public keys and the shard IDs of other nodes. One may be concerned about the performance of a node running two chains. The main chain adopts the Proof-of-Stake consensus, which may cost a high overhead, But the shard chain adopts the PBFT consensus, which costs a very low overhead. B. Shards Since the network is divided into several smaller shards, a node has to be assigned to a shard according to the consensus protocol. No node is independent of any shard. Specifically, when a node joins the network, it has to call a registry function of the governance contract, and then the function assigns it to a specific shard and returns an ID and the other information about the shard to it. To assign a node to a shard, the governance contract needs to know the node s account address, IP address and public key. To increase the randomness, it also takes into consideration the current state of the whole chain and adopts a complicated SHA-256 function. shardid = hash(pk IP A)%shardNum For instance, the DREP chain is divided into 100 shards and each shard includes 20 miners.

6 C. Mining As is mentioned in the previous sections, the DREP chain is divided into two levels, a high level called the main chain and the low level comprised of several shard chains. During the mining process, each level adopts a distinct consensus according to its own requirement. 1) Main chain mining: As for the main chain, all the nodes in the network participate in the mining. To prevent Sybil attacks, the main chain adopts a Proof-of-Stake consensus, which will be discussed later. 2) Shard chain mining: As for the shard chain, the mining process is divided into several epochs. The epoch e stars from 0, when the genesis block is created. It is increased by 1 after a number of blocks are generated. Each shard has 20 miners and takes turns to become the governor. The mining process goes as follows: (1) The governor generates a block and sends it to other miners. (2) The miner then validates it and sends it back to the governor. () After collecting the responses from more than 2 of miners, the governor confirms the block. (4) The governor sends the confirmation to the miners for a second validation. (5) Each miner validates it and sends the validation back to the governor. (6) After the governor collects the responses from more than 2 of miners, the block is added into the blockchain. (7) the governor s next miner becomes the new governor. Since a PBFT consensus is not Sybil-attackresistant unless all the participants has been identified, we propose a modified PBFT consensus in which a Proof-of-Stake-based mechanism is adopted to generate the identified participants. The generation process is stated as follows. ) Miner generation: When generating the first 100 blocks, the shard chain adopts the Proof-of-Stake consensus. Let ndenote the node number of a shard. Each node maintains two arrays a[0..n 1] and b[0..n 1], where a[i] indicates the number of the generated blocks by the i-th node and b[i] records the time when the i-th node generated the a[i]-th node. Once a block is generated by Node i and broadcast to other nodes, each node validates it and then updates the corresponding elements in a and b / / Update t h e number. a [ i ] = a [ i ] +1; / / Update t h e t i m e. b [ i ] = now ( ) ; After 100 blocks are generated, each node regards the top 20 nodes who have generated the most blocks as the miners. If two nodes generate the same number of blocks, the one who reaches the number earlier wins. The 20 nodes take turns to generate a block. / S o r t t h e data by bubble s o r t i n g f o r s i m p l i c i t y. / f o r ( i = 1 ; i <= n ; ++ i ) { f o r ( j = n ; j >= i + 1 ; j ) { i f ( a [ j 1]<a [ j ] a [ j 1]==a [ j ] && b [ j 1]>b [ j ] ) { swap ( i d [ j 1], i d [ j ] ) ; swap ( a [ j 1], a [ j ] ) ; swap ( b [ j 1], b [ j ] ) ; return i d [ ] ; 4) PBFT consensus: The remaining blocks in Epoch e are generated according the PBFT consensus. Specifically, all the miner nodes of a shard have a governor, who is responsible for collecting all the transactions from all the nodes within the shard and then generating a block. The other miner nodes are responsible for validating and signing the block. After more than 2 of the miners validate and sign the block, the block is confirmed and then broadcast to all of the nodes within the shard. There may also exists some byzantine nodes which could harm the network by dropping or modifying messages and sending different messages to honest nodes. The DREP chain assumes that at any time the mining network has a fraction of byzantine nodes which is at most 1. 4 The detailed mining process will be discussed in the following chapter.

7 Figure 2. PBFT consensus D. Transaction Processes When a transaction is proposed, it is broadcast in the network and then confirmed. In a PoSbased network, we assume that all states in each node remain the same. Although forks exist, the principle is similar. Meanwhile, in a PBFT-based network, if more than 2 of the nodes reach a consensus on a transaction and update the states stored in them, then the transaction is confirmed and the state in the network is updated (The non-consistent states in the minor nodes are ignored). Therefore, we have the following two lemmas whose formal proof will be released in our future technical report. Furthermore, for formal verification, the two lemmas will also be illustrated in a mathematical format. Lemma 1. In a PoS-based network, if several nodes, say Node 0, 1, 2,..., k, have reached a consensus on a transaction T, and updated their states S i = C(S i ) i {0, 1,..., k S i = S j i, j {0, 1,..., k i j S i = S j i, j {0, 1,..., k i j then the state of the whole network is updated S N = C(S N ) Lemma 2. In a PBFT-based network, if several nodes, say Node 0, 1, 2,..., k, have reached a consensus on a transaction T, and updated their states S i = C(S i ) i {0, 1,..., k S i = S j i, j {0, 1,..., k i j S i = S j i, j {0, 1,..., k i j and the node number is more than 2 of the total node number of the whole network k > 2 n then the state of the whole network is updated S N = C(S N ) Now let us focus on the details of transaction processes. When a transaction is proposed by a node, it first checks the governance contract for the assigned shard. The process varies in the following three cases. 1) Main chain transaction.: If the node is told that the transaction should be processed on the main chain, then it broadcasts the transaction to all the other nodes, each broadcasting it further. After each node receives a number of transactions, all of the nodes in the main chain start to generate a block and package all the received transactions into the block. The main chain adopts the Proof-of-Stake consensus, which forces each node to solve a puzzle H(H(B prev ), A, t) balance(a) m where H is a hash function and balance(a) is the balance of the account. Correctness proof. The proof here is straightforward. We apply Lemma 1, and after a transaction is comfirmed, the state of the network has been transitioned: S N = C(S N ) 2) In-shard transaction: If the transaction is assigned to a shard, then the node broadcasts the transaction to some of the nodes within the assigned shard. After receiving the transaction, the nodes broadcast it to other nodes within the shard. After a specified period, the shard s governor packages all the received transactions into a block and broadcasts the block to the other nodes within the shard. Each node validates the block and signs it with its private key. After more

8 Figure. Transaction processes in the DREP chain than 2 of the nodes validate and sign the block, the block is confirmed. The block contains a bitmap B which identifies the public keys of the signers. B[i] = 1 if the i-th member of the shard has signed the block. The shard chain adopts the PBFT consensus as the basis consensus protocol and runs two rounds of EC-Schnorr multisignatures. (1) Pre-prepare phase: The governor distributes a block to all the other nodes within the shard. (2) Prepare phase: All the other nodes validate and sign the block and the governor collects responses from more than 2 of the nodes. The governor also maintains the bitmap of the nodes that signed the block. () Commit phase: To ensure that more than 2 of the nodes know that more than 2 of the nodes have validated and signed the block, the DREP chain runs another round of validation. The multisignature from the first round is broadcast to all the nodes, and each node validates and signs the message. At the end of the three phases, the consensus is considered to be reached on the block proposed by the governor. / / Pre p r e p a r e phase On g o v e r n o r : nodeset = getnodeset ( ) ; f o r node i n nodeset : send ( block, node ) ; endfor / / Prepare phase f o r each node : bool v a l i d = v a l i d a t e ( b l o c k ) ; i f (! v a l i d ) e x i t ; s i g n ( b l o c k ) ; send ( governor, b l o c k ) ; endfor On g o v e r n o r : v a l i d = 0 ; bitmap = new Bitmap ; do : from = r e c e i v e ( b l o c k ) ; i f ( b l o c k. v a l i d ) v a l i d = v a l i d + 1 ; bitmap [ from ] = 1 ; e n d I f u n t i l ( v a l i d >= nodeset. s i z e ( ) 2 / ; b l o c k. add ( bitmap ) ; / / Commit phase On g o v e r n o r : f o r node i n nodeset : send ( block, node ) ; endfor commit = 0 ; do : r e c e i v e ( b l o c k ) ; i f ( b l o c k. commit ) commit = commit + 1 ; e n d I f u n t i l ( commit >= nodeset. s i z e ( ) 2 / ) ; f o r each node : bool commit = v a l i d a t e ( b l o c k. g e t S i g n a t u r e s ( ) ) ; i f (! commit ) e x i t ; s i g n ( b l o c k. g e t S i g n a t u r e s ( ) ) ;

9 send ( governor, b l o c k ) ; endfor Correctness proof. The proof here is straightforward. We apply 2, and after a transaction is confirmed, the state of the network has been transitioned: S N = C(S N ) ) Cross-shard transaction: As for crossshard transactions, the DREP chain provides a secure and efficient mechanism. According to our sharding protocol, a cross-shard transaction occurs when a transaction processed in a shard (original shard) needs to call a function of a smart contract in another shard (target shard). Similar to the two-phase commit We propose a PBFT-based four-phase commit protocol for such case: (1) Request phase: A node in the original shard signs the request and sends it to the governor in the original shard. Meanwhile the other nodes in the same shard will also send the same request to the governor. The governor collects the requests from all the nodes and maintains a bitmap of the nodes who sign the request. Once it has received the requests from more than 2 of the nodes, it sends the request and the multisignature (with the bitmap of the nodes who sign the request) to the governor of the target shard. (2) Response phase: The governor in the target shards broadcasts the request to all the nodes in the target shard. All the other nodes validate and sign the block. The signature is generated by EC-Schnorr multisignature. Meanwhile, the governor collects responses from more than 2 of the nodes. It also maintains the bitmap of the nodes that signed the response. After that, the governor in the target shard sends the result back to the governor in the original shard. () Validation phase: After the governor in the original shard receives the result, it broadcasts it to all the nodes in the original shard. Each node validates and signs the result. After that, it sends the result and the signature back to the to the governor. The signature is generated by EC-Schnorr multisignature. After receiving the responses from more than 2 of the nodes, the governor sends the governor in the target shard the result and the multisignature with a bitmap of the nodes that signed the result. (4) Commit phase: To ensure that more than 2 of the nodes in the target shard know that more than 2 of the nodes in the original shard have validated and signed the block, the target shard runs another round of validation. The result and the multisignature from the target shard is broadcast to all the nodes, and each node validates and signs the message. This phase is necessary because all the nodes in the target shard needs to know that more than 2 of the nodes in the original shard have agreed with this cross-shard transaction. There are more cases we should pay attention to: (1) There is a nonce value in each transaction for double-spend check. A node in the target shard has to check the value when it receives a transaction. (2) After sending out a request, the node in the original shard has to set a timeout. It has to regard the request as failed after it waits for the response until the specified time has elapsed. () A node in the DREP chain has the public keys of all nodes in the network. Therefore, a node in the target chain may validate the multisignature from the original chain and vice versa. Correctness proof. For simplicity, we have eliminated some complicated cases here and will release a complete proof in our future technical report. Suppose the sender is Node k, the request is r, and the transaction C is divided into three phases: C 1 before r, C 2 in r and C after r. (1) Before a request r is sent to the target shard, the sender s state S k = C 1(S k ). (2) After the request r is processed, the target

10 shard state S N t = C 2 (S Nt ) because of Lemma 2. () After the request r is returned, the sender s state S k = C (S k ) (4) For the other node in the original shard, S i = C (S i) i {0, 1,..., j (5) Apply Lemma 2, S N o = C (C 2 (S No )) then the state of the network has been transitioned. Therefore, the states of both shards have been transitioned correctly, and we thus regard the transaction as processed correctly. On a node i n t h e o r i g i n a l s h a r d : g o v e r n o r = g e t G o v e r n o r ( ) ; send ( t r a n s a c t i o n, g o v e r n o r ) ; r e s p o n s e = w a i t F o r R e s p o n s e ( node ) ; i f (! r e s p o n s e. s u c c e s s ) e x i t ; bool v a l i d = v a l i d a t e ( r e s p o n s e, p u b l i c K e y s ) ; i f (! v a l i d ) e x i t ; r e s u l t = r e s p o n s e. r e s u l t ; tmp = s i g n ( r e s p o n s e, p r i v a t e K e y ) ; send ( tmp, g o v e r n o r ) ; On t h e g o v e r n o r i n t h e o r i g i n a l s h a r d : cache = new HashMap ( ) ; nodes = new HashMap ( ) ; ( t r a n s a c t i o n, s e n d e r ) = r e c e i v e ( ) ; i f ( cache. e x i s t ( t r a n s a c t i o n ) ) { nodes. g e t ( t r a n s a c t i o n ). add ( s e n d e r ) ; e l s e { cache. p u t ( t r a n s a c t i o n ) ; tmp = new A r r a y L i s t ( ) ; tmp. add ( s e n d e r ) ; nodes. p u t ( t r a n s a c t i o n, tmp ) ; i d = g e t S h a r d I d ( t r a n s a c t i o n ) ; s h a r d I n f o = g o v e r n a n c e C o n t r a c t. g e t S h a r d I n f o ( i d ) ; s h a r d G o v e r n o r = s h a r d I n f o. g e t G o v e r n o r ( ) ; send ( t r a n s a c t i o n, s h a r d G o v e r n o r ) ; r e s p o n s e = w a i t F o r R e s p o n s e ( s h a r d G o v e r n o r ) ; nodeset = nodes. g e t ( t r a n s a c t i o n ) ; f o r node i n nodeset { send ( node, r e s u l t ) ; v a l i d = 0 ; do { r e s p o n s e = r e c e i v e ( ) ; i f ( r e s p o n s e. v a l i d a t e d ) v a l i d = v a l i d + 1 ; u n t i l ( v a l i d >= nodeset. s i z e ( ) 2 / ) ; send ( shardgovernor, r e s p o n s e ) ; On t h e g o v e r n o r i n t h e t a r g e t s h a r d : ( t r a n s a c t i o n, s o u r c e ) = r e c e i v e ( ) ; nodeset = getnodes ( ) ; f o r ( node i n NodeSet ) { send ( t r a n s a c t i o n, node ) ; do { r e s p o n s e = r e c e i v e ( ) ; i f ( r e s p o n s e. v a l i d a t e d ) v a l i d = v a l i d + 1 ; u n t i l ( v a l i d >= nodeset. s i z e ( ) 2 / ) ; send ( source, r e s p o n s e ) ; r e s p o n s e = r e c e i v e ( ) ; f o r ( node i n NodeSet ) { send ( r e s p o n s e, node ) ; do { r e s p o n s e = r e c e i v e ( ) ; i f ( r e s p o n s e. v a l i d a t e d ) v a l i d = v a l i d + 1 ; u n t i l ( v a l i d >= nodeset. s i z e ( ) 2 / ) ; On a node i n t h e t a r g e t s h a r d : g o v e r n o r = g e t G o v e r n o r ( ) ; t r a n s a c t i o n = r e c e i v e ( ) ; r e s u l t = p r o c e s s ( t r a n s a c t i o n ) ; send ( governor, r e s u l t ) ; r e s p o n s e = r e c e i v e ( ) ; i f (! r e s p o n s e. v a l i d a t e d ) { e x i t ; tmp = s i g n ( r e s p o n s e, p r i v a t e K e y ) ; send ( governor, tmp ) ; V. SECURITY This section discusses several issues regarding security. A. Sybil Attacks The DREP chain is Sybil-attack-resistant in that:

11 (1) The main chain adopts a Proof-of-Stake consensus which is a common and universal practice to prevent Sybil attacks. (2) The shard chain adopts a PBFT consensus. To prevent Sybil attacks, in each epoch, all nodes run PoS-based mining to compete for PBFT-based miner election. After the election, all miners are regarded as identified and then start to participate in the next PBFTbased mining. B. Scalability The DREP chain is highly scalable in that, all the blockchain configurations are stored in the governance contract and can be modified for scaling. At the beginning, the DREP chain is divided into 100 shards and each shard contains 20 miners. The block generation speeds are 1 block per 0 seconds in the main chain and 1 block per second in the shard chain. When we need to increase the shard numbers, the shard assignment algorithm has to be carefully rewritten to minimize the cost of resharding: (1) If the earlier shards remain the same and do not need to be rearranged, then the algorithm has to assign the transactions of the earlier smart contracts to the same shards and the ones of the new smart contracts to the new shards. (2) If the earlier shards need to be rearranged, then the DREP chain has to minimize the cost of data transfer between different shards. C. Double Spending Each transaction has a nonce value indicating the number of transactions sent by the transaction s sender. Such values are stored in all the nodes in the corresponding chains. The DREP chain uses such values to prevent double spending. (1) As for the main chain, if a node receives a transaction with a wrong nonce value, then such transaction is rejected. (2) As for in-shard transactions, it is the same with the main chain. () As for cross-shard transactions, the case in the original chain is the same with the main chain, but we should pay more attention to the case in the target chain. The nodes in the target chain check the nonce value not only to prevent double spending, but also to record the transaction in order to avoid sending duplicate requests. D. Reentries and Dead Locks With respect to cross-shard transactions, one may worry about reentries and dead locks. In our algorithms, we use a special PBFTbased communication between different shards. Also, when a node processes a cross-shard transactions and then waits for a response from the target shard, it still can process other transactions if the transaction s parent transaction is being processed by the node itself. Therefore the reentry problem can be resolved. Furthermore, each node sets a timeout when sending a request to other shards, which is also a good practice to prevent dead locks. E. Atomicity The traditional distributed systems adopt a two-phase commit protocol to guarantee the atomicity of a transaction and the state consistency between different nodes. The DREP chain does not adopt such practice in cross-shard transactions, in that such protocol has to make all the nodes reach a consensus, which results in a high overhead. However, we adopt a PBFT-based four-phase commit mechanisms to guarantee the atomicity. Since atomicity is a relative concept, if differs in different aspects when one judges whether a transaction is atomic. By formal methods, we can prove that the mechanisms in the system is atomic. VI. CONCLUSION DREP Foundation has been devoting to provide a high-performance infrastructure and assorted tools to enhance the diversity and the flexibility of decentralized applications. In this paper, we demonstrate the main architecture and some innovative attributes of DREP chain. As a novel state-sharding structure, DREP chain consists of an efficient two-layer design, highly independent governance mechanism, as well as more secure and cost-saving cross-shard transactions.

12 REFERENCES [1] M. Castro and B. Liskov, Practical Byzantine Fault Tolerance, in Proceedings of the Third Symposium on Operating Systems Design and Implementation, ser. OSDI 99. Berkeley, CA, USA: USENIX Association, 1999, pp [2] C. Schnorr, Efficient signature generation by smart cards, J. Cryptol- ogy, vol. 4, no., pp , [] D. J. Bernstein, Multi-user Schnorr Security, Revisited, IACR Cryptology eprint Archive, vol. 2015, p. 996, [Online]. Available: [4] A. Poelstra, Schnorr Signatures are Non-Malleable in the Random Oracle Model, [5] S. Micali, K. Ohta, and L. Reyzin, Accountablesubgroup Multisigna- tures: Extended Abstract, in Proceedings of the 8th ACM Conference on Computer and Communications Security, ser. CCS 01. New York, NY, USA: ACM, 2001, pp [6] M. Al-Bassam, A. Sonnino, S. Bano, D. Hrycyszyn, and G. Danezis. Chainspace: A Sharded Smart Contracts Platform. arxiv preprint arxiv: , [7] M. K. Franklin and H. Zhang. A Framework for Unique Ring Signatures. IACR Cryptology eprint Archive, 2012:577, [8] J. R. Douceur. The Sybil Attack. In 1st International Workshop on Peer-to-Peer Systems (IPTPS), Mar [9] A. Gervais, G. Karame, S. Capkun, and V. Capkun. Is Bitcoin a decentralized currency IEEE security and privacy, 12():54 60, [10] R. Guerraoui. Non-blocking atomic commit in asynchronous distributed systems with failure detectors. Distributed Computing, 15(1):17 25, [14] E. Kokoris-Kogias, P. Jovanovic, L. Gasser, N. Gailly, E. Syta, B. Ford. OmniLedger: A Secure, Scale-Out, Decentralized Ledger via Sharding, The ZILLIQA Team. The ZILLIQA Technical Whitepaper, Version 0.1, Aug, 2017 [15] E. Heilman,A. Kendler,A. Zohar,and S. Goldberg. EclipseAttackson Bitcoin s Peer-to-Peer Network, in 24th USENIX Security Symposium (USENIX Security 15). Washington, D.C.: USENIX Association, 2015, pp [16] S. Gilbert and N. Lynch, Brewer s Conjecture and the Feasibility of Consistent Available Partition-Tolerant Web Services, In ACM SIGACT News, 2002, p [17] M. Michels and P. Horster. On the Risk of Disruption in Several Multiparty Signature Schemes, in Proceedings of the International Con- ference on the Theory and Applications of Cryptology and Information Security: Advances in Cryptology, ser. ASIACRYPT 96. UK: Springer-Verlag, 1996, pp [18] S. Nakamoto, Bitcoin: A peer-to-peer electronic cash system, [19] R. Pass and E. Shi. Hybrid Consensus: Efficient Consensus in the Permissionless Model. Cryptology eprint Archive, Report 2016/917, [20] J. Poon and T. Dryja. The Bitcoin Lightning Network: Scalable Off- Chain Instant Payments, Jan [21] Satoshi. Unspent Transaction Output Set, Feb [22] Y. Lewenberg, Y. Sompolinsky, and A. Zohar. Inclusive block chain protocols. In International Conference on Financial Cryptography and Data Security, pages Springer, [2] Wikipedia. Two-phase commit protocol, commit protocol. [11] T. Hanke and D. Williams. Intoducing Random Beascons Using Threshold Relay Chains, Sept [12] A. Kiayias, A. Russell, B. David, and R. Oliynykov. Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol. Cryptology eprint Archive, Report 2016/889, [1] C. Cachin. Architecture of the Hyperledger blockchain fabric. In Workshop on Distributed Cryptocurrencies and Consensus Ledgers, 2016.