CycLedger: A Scalable and Secure Parallel Protocol for Distributed Ledger via Sharding

01/19/2020 ∙ by Mengqian Zhang, et al. ∙ Shanghai Jiao Tong University Peking University 0

Traditional public distributed ledgers have not been able to scale-out well and work efficiently. Sharding is deemed as a promising way to solve this problem. By partitioning all nodes into small committees and letting them work in parallel, we can significantly lower the amount of communication and computation, reduce the overhead on each node's storage, as well as enhance the throughput of distributed ledger. Existing sharding-based protocols still suffer from several serious drawbacks. The first thing is that all honest nodes must connect well with each other, which demands a huge number of communication channels in the network. Moreover, previous protocols have face great loss in efficiency in the case where the honesty of each committee's leader is in question. At the same time, no explicit incentive is provided for nodes to actively participate in the protocol. We present CycLedger, a scalable and secure parallel protocol for distributed ledger via sharding. Our protocol selects a leader and a partial set for each committee, who are in charge of maintaining intra-shard consensus and communicating with other committees, to reduce the amortized complexity of communication, computation and storage on all nodes. We introduce a novel commitment scheme between committees and a recovery procedure to prevent the system from crashing even when leaders of committees are malicious. To add incentive for the network, we use the concept of reputation, which measures each node's computing power. As nodes with higher reputation receive more rewards, there is an encouragement for nodes with strong computing ability to work honestly so as to gain reputation. In this way, we strike out a new path to establish scalability, security and incentive for the sharding-based distributed ledger.



There are no comments yet.


page 1

This week in AI

Get the week's most popular data science and artificial intelligence research sent straight to your inbox every Saturday.

I Introduction

The blockchain revolution has established a milestone with Nakamoto’s Bitcoin[1] during the long search for a dreaming digital currency. It maintains the distributed database in a decentralized manner and has achieved a certain maturity to provide the electronic community with a service that captures most important features of cash: secure, anonymity, easy to carry, easy to change hand, and exchangeable across a nation’s boundaries. At the same time, Bitcoin realizes the tamperproof of transactions.

Unfortunately, the transaction throughput of Bitcoin does not perform well. The throughput of Bitcoin is 3 to 4 orders of magnitude away from those centralized payment-processors like Visa. Specifically, Bitcoin can process 3.3-7 transactions per second in 2016[26] while Visa can handle more than 24,000 transactions per second[27]. Low scalability of Bitcoin is seen as an important factor causing this displeasing result.

Sharding is a famous technique in building “scale-out” database by separating the whole state into multiple shards and making them work concurrently. Inspired by this idea, sharding is also used to benefit distributed ledgers in these years. When nodes are partitioned and the whole work is parallelized, a high processing capacity can be achieved as the number of participants in the network increases. However, most sharding-based protocols cannot maintain high efficiency when committee leaders betray[3] [4]. They also fail to give an explicit incentive for nodes to join the protocol and behave honestly.

We present CycLedger, a fully decentralized payment-processor which provides scalability over the amount of nodes and provable security. Specifically, we expect our protocol to remain robust when the honesty of leaders in each committee is in question. This is a problem that remains unsolved up till now. At the same time, we hope there is enough encouragement for an honest node to participate in our protocol. Meanwhile, scalability can be realized via sharding nodes into concurrent committees as previous works have shown[2] [3] [4].

To obtain a high security under the existence of dishonest leaders, we assume there are no more than 1/3 malicious nodes at any time during the execution of our protocol, which is the best result achieved so far in sharding blockchains[4] [5]

. Meanwhile, an adversary can corrupt any nodes as he likes, but such corruption attempts need some time to take effect. For each committee, we select its members in a pseudorandom manner so that with overwhelming probability, there are more than 1/2 honest validators in a committee. Furthermore, we construct a partial set in each committee. Members in this set supervise leader’s behaviour and act as alternates when the latter is confirmed to be vicious. By setting the size of each partial set to an appropriately large number, we ensure that only with tiny probability there is no honest nodes in a partial set. Finally, we design a recovery procedure to select a new leader when the original one is dishonest. Concretely, when a leader is found to violate the restriction of the protocol, he will be evicted and a node in the partial set will take his place. By introducing digital signature and semi-commitments between committees, we can guarantee that a non-void block can be successfully generated in each round with high probability.

To provide validators with enough incentive to enter our network, we introduce the concept of reputation to CycLedger. We hope one’s reputation could be a good reflection of his computing power so that when we partition the total revenue according to nodes’ reputation, we can give more payment to those honest nodes who pay more contribution to access transactions, hence attracting them to stay in the network. To achieve this goal, we consider one’s vote on a certain set of transactions. The more similar his vote is with the final decision, the more reputation he gains. In this way, as nodes with higher computational resource can process more transactions correctly within a given time, they will obtain a higher accumulated reputation, consequently, winning more reward than other nodes.

The convenience reputation provides us is that we can sort out those nodes with strong computing ability simply by looking at all nodes’ reputation. Thus, we can put those nodes with better reputation to higher position to reach a greater efficiency in accessing transactions. In CycLedger, those nodes with the best reputation are selected as leaders of each round, hoping they can use their abundant computational resources to bring more transactions into a block. In this way, a promotion on throughput is expected to see in CycLedger.

This paper is organized as follows. In Section II, we review previous works which are relevant with our protocol. In Section III, we state the network and threat models we use, define the problems we aim to solve, and give an overview on CycLedger. We elaborate our main protocol in Section IV. After that, we give the analysis on the security and incentive of our protocol in Section V and Section VII, respectively. Finally, we make a conclusion in Section IX.

Ii Background and Related Work

Elastico OmniLedger RapidChain CycLedger
Fail Probability within a Round
Decentralization no always-honest party an honest client an honest reference committee no always-honest party
High Efficiency w.r.t Dishonest Leaders
Burden on Connection heavy heavy heavy light
  • : total amount of nodes in the network : amount of committees : amount of nodes in a committee, we mention that .

  • : size of a partial set. Usually is set to be no less than 40.

  • When computing complexity, it is assumed that a cross-shard transaction be relative with all committees.

TABLE I: A Comparison of CycLedger with Previous Sharding Blockchain Protocols

Ii-a Sharding-based Blockchains

In traditional blockchain protocols, all nodes in the network have to reach a consensus on a certain set of transactions. This scheme will cause a very low throughput as only a rather fixed amount of transactions are included in a block regardless of the number of nodes in the network. An alternative way is to partition nodes into parallel committees and let each committee maintain the status of a fixed group of users. Under this method, the amount of transactions is proportional to the number of committees rather a constant. This technique is known as sharding and is considered as the best way to help blockchain scale well in literature.

RSCoin[16] implements a centralized monetary system via sharding, yet it is not decentralized and cannot transplant to distributed ledgers. Elastico[2]

is the first sharding-based protocol for public blockchains which can tolerate up to a fraction of 1/4 of malicious parties yet it has a very weak security guarantee as the randomness in each epoch of the protocol can be biased by the

Adversary. Meanwhile, Elastico’s small committees (only about 100 nodes in a committee) cause a high probability to fail under a 1/4 adversary, which cannot be released in a PoW system[18]. Specifically, when there are 16 shards, the failure probability is 97% over only 6 epochs[3]. OmniLedger[3] also allows the adversary to take control of at most 25% of the validators as well as assuming the adversary to be mildly-adaptive, yet it depends on the assumption that there is a never-absent honest client to schedule the leader’s interaction when handling cross-shard transactions. RapidChain[4] enhances the efficiency of sharding-based blockchain protocols in a large scale, but the protocol guarantees high efficiency only when leaders of each committee are honest, an unrealistic assumption in practice. Concretely, in expectation, there are a proportion of 1/3 leaders that are malicious in a round. Under this condition, cross-shard transactions may hardly be included in a block. Further more, the protocol does not have an explicit incentive for nodes to participate in. At the same time, all the above postulate a well connection between any pair of honest nodes, which causes a huge burden in creating connection channels.

We give a comparison of CycLedger with previous sharding blockchain protocols on several aspects in table I.

Ii-B Distributed Randomness Generation and Cryptographic Sortition

It has been a critical and difficult task in blockchain to come up with a random number each round (step, slot, epoch). Most protocols use an external cryptographic hash function to carry out this task. Algorand[8] makes use of verifiable random functions (VRFs)[12]. It requires the seed of the current round, the round number as well as the leader’s secret key, to produce next round’s seed and a proof of it. In this way, when the leader is honest, the seed can be pseudorandom and unpredictable. Yet, the seed can be biased when the leader is malicious. Ouroboros[7] takes usage of Publicly Verifiable Secret Sharing (PVSS) scheme[13][14] to generate a random seed. This scheme is now known as a secure way to distributedly generate a random number and is also used in OmniLedger[3]. However, OmniLedger deploys RandHound[15] to generate the Common Reference String (CRS). Therefore, the protocol can only allow a 1/3 proportion of malicious nodes in each committee. At the same time, an honest client is also required in RandHound. Other protocols[9][11] use an external cryptographic hash function, which takes an unpredictable and tamper-resistant value (for example, some values contained in previous blocks) as input. The output of the function is seen as the randomness of an epoch. The randomness is achieved by the pseudorandomness of the hash function.

The technique of cryptographic sortition is widely used in blockchain protocols to select a small set of validators pseudorandomly. In Algorand[8], a node’s VRF hash value on a given input is the ticket to enter the committee. At the same time, VRF also provides a proof so that everyone can verify if one is really selected. We mention that many protocols[9][11] now use this scheme to ensure pseudorandomness, verifiability and unpredictability without loss of efficiency. There are some other protocols utilizing different mechanisms. For example, the Sleepy Model[10] only uses pseudorandom functions while Ouroboros[7] randomly generates several coins and uses the Follow-the-Satoshi (FTS) algorithm[28] to find their owners who are deemed as leaders. Yet these methods are either lack of security or not quite efficient.

Ii-C Reputation and Blockchain

The open, anonymous and decentralized environment of Peer-to-Peer(P2P) systems brings significant advantages, such as the strong expansibility and load balancing. But in the meantime, it provides great convenience for the self-interested and malicious users to take strategic behaviors, which could lead to the inefficiency or even failure of the system. For example, current P2P file-sharing networks suffer from the rifeness of inauthentic contents[20]. Reputation, regarded as a tool to record the action of users, has been widely used in the collaborative P2P applications to solve this problem. By designing a proper metric and corresponding algorithm, it could help the aforementioned file-sharing system effectively to identify malicious peers[21], avoid undesirable contents[22] [23] and drive cooperation among strategic users[24].

Inspired by the success of reputation in many other P2P systems, some researches try to introduce it into the area of blockchain. Nojoumian et al.[25] proposes a new framework for the PoW-based blockchain, in which each miner has a public reputation value reflecting his historical mining behaviour. One’s reputation influences his opportunity to participate in future minings, thus, for their long-term interests, miners are encouraged to avoid dishonest mining strategies in this model. Repchain[5] first introduces reputation into the sharding-based system. The reputation scheme is designed to characterize validators’ honesty and activeness, based on their decisions on the transactions list. Repchain uses the accumulated reputation values for the balanced sharding, leader selections and transaction fee distributions. It is claimed that the schema provides a high incentive for validators to work hard and honestly, as well as improves the system performance. However, building a committee with the help of reputation reduces its randomness. That is, it indeed trades security for better incentives.

Iii Model, Problem Definition and Overview

Iii-a Notation

CycLedger works in rounds. In each round , suppose there are ( is changing as changes, but to make notation simpler, we use instead of ) nodes in the network and each of them has a reputation which changes as the protocol executes. We use a Public-Key Infrastructure (PKI) to give each of them a public/secret key pair (). An honest-majority referee committee is selected to manage nodes’ identities, produce next round’s randomness and propose round ’s block . At the same time, all other nodes are partitioned into committees which we denote as . Note that we require each committee an honest majority. Therefore, in our protocol, we would like the size of each committee to be in expectation. Readers should mention that . Each committee, excluding the referee committee, includes a leader, potential leaders and members. All potential leaders in form the partial set of , which is denoted as . It should be ensured that there is at least one honest node in each partial set and in practice, can be an appropriate value, like 40. Fig. 1 demonstrates the hierarchical structure of different nodes and committees.

Fig. 1: Hierarchical structure.

In addition, with overwhelming probability, each round is successfully terminated ( all expected operations are finished) within a fixed time .

Iii-B Network Model

We assume the well connection within a committee while leaders of each committee are connected to each other. Further more, we assume that all honest nodes have connection to every honest node in referee committee . This requires a far less amount of reliable connection channels than other works[2][3][4][5] in which they require a well connection between any pair of honest nodes. At the same time, like existing works[3][4], we assume synchronous communication only within a committee ( every message sent by an honest node to another can be received within a maximal delay of ) which is realistic in real world as a committee only consists of a thousand or even less nodes. With regards to other connections, we only need to assume partially-synchronous channels[3][6][19].

Iii-C Threat Model

As we use digital signatures in reaching consensus as RapidChain[4] and RepChain[5] do, we may assume the existence of a probabilistic polynomial-time Adversary which takes control of less than 1/3 part of total nodes. Corrupted nodes can collude with each other and act out arbitrary behaviors like sending wrong messages or simply pretending to be offline. The adversary can change the order of messages sent by honest nodes with respect to the restriction given in our network model, just like what is assumed in classical Byzantine protocols[19]. Other nodes, which are known as honest nodes, do everything the protocol instructs and nothing exceeding the regulation. At the same time, we allow the adversary to be mildly-adaptive, which means that he is allowed to corrupt a set of nodes at the start of any round. Yet, such corruption attempts require at least a round’s time to take effect. Also, we assume all nodes in the network have access to an external random oracle which is collision-resistant as well as a Verifiable Random Function(VRF) scheme.

Iii-D Problem Definition

We assume that a large set of transactions are continuously sent to our network by external users. Users are almost equally divided into shards. The status(including users’ identity and Unspent Transaction Outputs(UTXOs)) of each shard is maintained by the corresponding committee. All processors have access to an external authentication function to verify whether a transaction is legitimate, the sum of all inputs of the transaction is no less than the sum of all outputs. Our goal is similar to [2][4] but slightly different. We seek for a protocol which, with given set of transactions as input, outputs a subset, , such that the following properties hold:

  • Security. In each round, the protocol fails at a probability no more than , where is the security parameter.

  • Validity. Each transaction in passes the verification, .

  • Scalability. grows quasi-linearly with .

  • Incentive. Honest nodes have incentive to execute the protocol within the given restriction.

We mention that CycLedger differs from previous protocols [2][3][4] as there is an explicit incentive design in it.

Iii-E Protocol Overview

Roughly, in each round , our protocol consists of the following phases:

  • Committee Configuration. As the referee committee , leaders and partial sets of round are already determined in the previous round, in this phase, all other verified nodes are grouped and committees are formed.

  • Semi-Commitment Exchanging. Every leader constructs a semi-commitment of the list of members in his committee and sends it to , the partial set of his committee and all other leaders. Here, instead of both binding and hiding, we only need the computational binding property of a commitment. And that is why it is called a semi-commitment. Loosely speaking, a semi-commitment can be used to detect a leader when he tries to cheat in the phase of achieving inter-committee consensus.

  • Intra-committee Consensus. In this phase, honest nodes within a committee reach an agreement on those transactions whose inputs and outputs all belong to the shard they are responsible of.

  • Inter-committee Consensus. In short, all honest nodes reach agreement on the set of cross-shard transactions (, those transactions whose inputs and outputs do not belong to the same shard) that can be included in the block of the current round. To achieve the goal, several steps are required, which will be discussed later in detail. After an agreement is reached, all leaders submit all transactions(including intra-shard ones and cross-shard ones) that are verified by his committee members to .

  • Reputation Updating. Reputation is an important indicator for each node in CycLedger. Higher a node’s reputation, more reward he will get. After the consensus phases, the reputation of all member in a committee is updated according to their votes.

  • Referee Committee, Leaders and Partial Sets Selection. We use a Proof-of-work(PoW) process to figure out those nodes who will participate in the next round. After that, referee committee and partial sets in round are uniformly selected while leaders in the next round are selected with respect to the updated reputation. At the same time, produces the randomness for the next round.

  • Block Generation and Propagation. After receiving all transactions, verifies, packs the legitimate ones as well as next round’s randomness , next round’s participants, nodes’ updated reputation, and the identity of all members in , all leaders and partial set members in the block , and releases it to all nodes. All nodes in a committee reach a consensus on the UTXOs they are in charge of after seeing , and the leader will send them to .

Fig. 2 shows how it works when a transaction is submitted.

Fig. 2: CycLedger architecture overview: (1) When someone submits a transaction (tx, for short), (2) the transaction will be sent to the corresponding shard, which is in the charge of committee 1. (3a) If the inputs and outputs of the transaction all belong to committee 1, they themselves reach an intra-committee consensus on it. (3b) Otherwise, they reach an inter-committee consensus with the help of other committees. (4) After that, the verified transaction will be sent to the referee committee, who verifies and packs it into the block.

Iv Main Protocol

Iv-a Committee Configuration

To begin with, we propose a cryptographic sortition mechanism using Verifiable Random Function (VRF) scheme. Except for the selected leaders, referee committee and partial sets, a undetermined node can find out the committee he belongs to via this scheme.

The node’s public/secret key pair ;
The Round’s number and randomness of the round .
A committee ID and a proof which can be used to verify that the node is in .
3:return .
Algorithm 1 Cryptographic Sortition

For nodes selected as the committee’s leader or partial set member :

  1. Initially, he maintains a list, and puts his own and into it.

  2. When receiving a from node , first he uses the VRF proof node provides to check whether node is in this committee. If the proof can pass the verification, , offer the list to node , and add into the list.

For any other node :

  1. Find the committee he belongs to using Algorithm 1.

  2. Send his , VRF value and VRF proof to the corresponding leader and partial set members whose addresses are presented in block .

  3. When node receives a list from a partial set member or the leader, he delivers his to all unconnected committee members in the list.

  4. When receives a from an unconnected node , first he checks if node is in the same committee according to the given proof. If , node keep both .

By executing this program on each node, all committees could be self-organized in parallel. In expectation, each committee contains nodes.

Each node gets a Public Key List about his committee.


4:upon event
5:if then
7: to
8:return S

Other node:

5: to Leader and Partial Set members
6:upon event from Leader or Partial Set members
8: to new members in S
9:upon event
10:if then
12:return S
Algorithm 2 Committee Configuration

Iv-B Semi-Commitment Exchanging

This phase starts at a given time after the first phase starts.

To begin with, we present Algorithm 4, which works efficiently to reach agreement inside a committee. We give a demonstration of its process in Fig. 3.

A committee leader with his public key ;
The committee with honest majority and all members’ public/secret key pairs;
An initial information selected by leader .
A publicly verifiable message .
1:The leader sends initial information to every member with his signature on it;
2:When a committee member receives the message with , he signs it with his public key and broadcasts the message with both the leader’s and his signature to each member of the committee;
3:Everyone can verify if is signed by at least half of members in the committee. If yes, sends with all signatures he received back to the leader; else, an honest node in partial set will discover that the leader has sent different messages to different participants, , the leader is malicious. He executes a recovery procedure to evict the leader and elect a new one, and repeat the previous steps;
4:return which is a consensus.
Algorithm 3 Consensus inside a Committee
The members public key list
The message
A consensus on message
A signature list prove for


4: to all members in
5:upon event from member
8:if then
9:  return


4:upon event from Leader
6: to all members in
7:upon event from member
10:if then
11:  return ,
Algorithm 4 Consensus inside a Committee
  1. First of all, each committee’s leader computes the committee’s semi-commitment via the external hash function :

    Then he transmits it to everyone in . Meanwhile, he should also deliver the whole list to the partial set together with his signature.

  2. After every member in obtains semi-commitments from all committees, all honest nodes in use Algorithm 3 to reach an agreement on the semi-commitment of each committee. (As there is no leader in , they will start from the second step in Algorithm 3.) After that, they deliver the set of semi-commitments to all leaders and partial sets.

  3. When a partial set member gets the semi-commitment from , he verifies whether his committee’s semi-commitment corresponds with the list he maintains.

The members public key list
A commitment list from other committee.


4: to all members in partial set
5:upon event from member
7:if then
8:   to all members in
9:upon event from
12:  return

Partial set member:

1:upon event from Leader
2:if then
4:upon event from
7:  return

Referee member:

1:upon event from Leader in committee
2:if then
3:   to all leader and partial sets members
5:  Start Leader Changing program
Algorithm 5 Commitment Exchange

Iv-C Intra-committee Consensus

Fig. 3: A demonstration of Algorithm 3.
  1. At the beginning, after receiving some constant amount of transactions from external users, each committee ’s leader creates a whose inputs are all within the shard they are in charge of. That is, they could verify these transactions by themselves.

  2. The leader broadcasts his to everyone in the committee.

  3. After receiving , every member votes on each of the listed transactions using , or . When an honest node is lack of computation power and fails to judge a transaction within the given time, he should vote . After this, he forwards the voting list back to the leader with his signature on it.

  4. After the leader obtains all voting lists, he picks up the set of transactions with more than half of , which is named as . Then he bales all transactions in a set together with everyone’s vote named as . The leader runs Algorithm 3 twice to reach consensus on both and .

  5. Finally, the leader sends with at least half members’ certification to , together with a public key list of the committee .


The transaction list
The transaction decision set including valid transaction list and the set of voting list.
2: to all members
3:upon event from member
5:if then
7:   to members in
8:  return

Other Member:

1:upon event from Leader
3: to leader
4:upon event from other member
Algorithm 6 Intra-committee Consensus

Iv-D Inter-committee Consensus

For those transactions whose inputs scatter across multiple shards, we use the commitment scheme introduced before to ensure the security of cross-shard communication.

Consider those transactions which are handled by yet charged by . First of all, should list the set of transactions whose inputs are related with and broadcast it to all members in committee . We call this list . Once an agreement on the list is reached in by Algorithm 3, the leader sends the consensus on to and .

When receives the query from , he transmits it to his committee members within a given latency. Then every member of votes on and forwards it back to with his own signature. After that, the leader packs all votes, runs Algorithm 3 to reach a voting agreement in the committee and sends the consensus result back to .

Iv-E Reputation Updating

Once reaching the agreement on a voting of a (either an inner-committee list or a cross-committee one), the leader grades everyone in this committee. As previously described, contains marked votes, , all members’ opinion on the validity of listed transactions. On the vote, someone marks for those transactions he agrees, for disagreed and for the left. Facing the votes of all members, the leader scores each member according to the proximity between his opinion and the majority opinion.

Let +1, -1 and 0 represent , and respectively. Suppose the amount of transactions to be determined is . Then we have a

-dimensional vector space and transactions are axes of the space. Considering from this aspect, a vote can be seen as a vector in this space. Let

denote the vote of member , where is the member ’s opinion on the transaction. We use the cosine of the angle between two vectors to measure the proximity of two corresponding opinions. In other words, we define the

of one node as the cosine similarity between its voting vector and the resulting vector, which is determined by the majority algorithm and denoted by

. Let denote the member ’s score. We have


Owing to the random generation of each committee and the design of Algorithm 3, the majority result could reflect honest members’ view. Thus when computing the scores, it is directly regarded as the ground truth. The main idea is, the closer one’s opinion stands with the consensus, the higher grade he will get. Specially, if a member has exactly the same answers with the consentaneous results, he would be rewarded the highest score, i.e., +1. On the contrary, if a member replies with completely opposing opinions, he will be given the lowest score, which is -1.

After computing all scores, the leader assembles them into a . Then he broadcasts and the original to all committee members, waiting for the consensus by Algorithm 3. In this process, each honest member should sign on the . If successful, the leader sends the agreement to , together with other relevant certification information. Then updates their reputation by simply adding the listed score.

Iv-F Referee Committee, Leaders and Partial Sets Selection

Participants in distributedly generate next round’s seed via a random beacon generator. Here, the SCRAPE[14] scheme is preferred as it guarantees the pseudorandomess and unbiasness of the seed even when the Adversary takes control of almost half of total node. The nodes who want to participate in the next round need to solve a PoW puzzle in advance and the difficulty of the puzzle is equal to everyone. Each node who solves his own problem is supposed to deliver the solution to the referee committee and the latter will record his identity. As a result, by the end of the round , knows all next round’s participants . chooses nodes with the highest reputation as new leaders in round . After that, based on randomness , determines the next referee committee and partial sets in the next round . For example, a member in can see if the following inequality holds for a node :

where can be or . A new for either can be proposed every round as the amount of nodes in the network changes. If a node is selected as a partial set member, a member in can calculate to find out which partial set he belongs to.

Iv-G Block Generation and Propagation

Each time members receive a from a leader, they check the validity of its signature. By the end of the round, the referee committee comes to an agreement using Algorithm 3 on the set of valid s and pack them up, together with all participants of next round , their reputations , the elected referee committee , leaders and partial sets as a block . By releasing it to the whole network, all nodes could obtain the contained information. After seeing the proposed block , each committee member traverses all transactions packed in it. In this process, members need to delete the used ones from their local UTXO lists and append the newly generated outputs that they are responsible for. Meanwhile, limited by the package size or other reasons, there may be some unpacked valid transactions within each committee, which form a Remaining TX list. Then the leader of each committee runs Algorithm 3 to reach a consensus on the final UTXO List and Remaining TX List, and sends them to . Next, binds these lists with the Committee ID and forwards them to the corresponding new partial sets. Up to this point, all committees have finished their tasks.

After that, a node obtains part of transaction fee based on his reputation. The sum of all nodes’ revenue equals to the fee of all transactions admitted in this round. Considering that one’s reputation may be negative, we first map the reputation to a positive number using a monotone function . Then rewards are distributed proportionally to the mapped value. Specifically, the function is designed as follows, and Fig. 4 visualizes it. The reputation of will be updated by in the next round.

Fig. 4: The monotone function mapping reputation to a positive number.

The monotone increasing function and proportional distribution ensures that whoever works more gets more. According to (2), . Thus, nodes whose reputation is zero (e.g., nodes who always vote Unknown) could still get little rewards. By contrast, the negative reputation is mapped to near zero, which means the corresponding nodes can hardly obtain revenue. Under this reward mechanism, it is better to do nothing rather than do something bad, thus encouraging the malicious nodes to turn over a new leaf.

V Security Analysis

In this section, we provide a comprehensive discussion on the security of our protocol, showing that CycLedger is highly secure with overwhelming probability.

V-a Security on Randomness

In CycLedger, we use the SCRAPE scheme[14] within to distributedly generate a random string. This scheme is based on the skill of Publicly Verifiable Secret Sharing (PVSS) and has guaranteed that as long as at least half of nodes in are honest, the output random string is pseudorandom and unpredictable. At the same time, comparing with RandHound[15], an honest leader is not required in the execution of SCRAPE. That is to say, all participants in the protocol behave equally. This feature suits the construction of the referee committee well as is the only committee without a leader. As we can see in the following analysis, each committee has more than half of honest nodes with high probability, hence, we assert that the randomness produced by SCRAPE with is reliable.

V-B Security on Committee Configuration

We say a committee is secure when more than half of nodes are honest. Recall that committees are organized uniformly except leaders. Here, we denote the amount of malicious nodes in a committee by

. We consider the tail bound of hypergeometric distribution which gives the following result:



is the Kullback-Leibler divergence. Here

and , thus,


When we set the expected amount of participants in a committee , we can derive that the probability that a committee is insecure is less than , which is negligible of .

Fig. 5 visualizes (4). Namely, it shows the probability of failure calculated using the hypergeometric distribution to uniformly sample a committee when the population of the whole network is 2000. The amount of malicious nodes is exactly less than one third of the whole, i.e., 666.

Fig. 5: Probability of failure in sampling one committee from a population of 2000 nodes in CycLedger. The amount of malicious nodes is set to 666.

Particularly, when , the error probability for a single committee is less than . Applying union bound, when is less than 20, the error probability is no more than .

V-C Security on Partial Sets

Recall that the size of partial set is set to 40. We say a partial set is secure when at least one node in the set is honest. We have assumed that more than 2/3 players are honest, thus the probability that a partial set is insecure at most:

Associated with Union Bound, when the number of committees is 20, the probability that at least one partial set is insecure is no more than .

V-D Security on Semi-Commitments

Recall that we use the hash of the member list as a semi-commitment of the members. To start with, we show that satisfies the computational binding property.

Claim 1.

When is modeled as a collision-resistant hash function (CRHF), satisfies the computational binding property. That is, once the semi-commitment is released, a probabilistic-polynomial-time malicious leader cannot forge another member list which corresponds to the same semi-commitment with non-negligible probability.


The computational binding property can be directly derived from the definition of a CRHF. ∎

With the above claim, we come up with the following theorem.

Theorem 2.

A malicious leader cannot deceive an honest leader by forging a member list of his committee as long as has an honest majority.


There are only two opportunities when a betrayer can lie to a loyalist on the member list. The first chance is when he tries to broadcast the semi-commitment. However, because all members in , as well as the partial set members of the committee, see the exact member list, any false hash on the list will be perceived. Thus the liar will be detected. The second chance for the malicious leader is when the semi-commitment is revealed. Yet, according to the Claim 1, a misleading behaviour will not take effect in this phase. ∎

We emphasize that the hiding property of a commitment is not necessary for our protocol. For a vicious leader, even if he figures out the members of a committee in the semi-commitment exchanging phase, he can do nothing under our threat model as the adversary cannot get control of an honest node immediately.

Here we introduce the novel leader re-selection procedure in CycLedger. The program is invoked when an honest partial set member notices that his leader is malicious or participants of notice that some leader is vicious. In the semi-commitment case, the event happens when a loyal party ( or a partial set member) discovers inconsistency between the member list he owns and the one the leader claims.

If a partial set member wants to accuse his leader, he would broadcast his witness to all members in the committee and ask them to vote on the impeachment. Here, a witness is a pair of messages where should be sent and signed by the leader. We say a witness is valid if and only if the pair can derive dishonest behaviours of the leader. If the proposal is passed by more than half of the validators, the prosecutor will forward the voting result as well as his witness to everyone in the referee committee.

When validators in reach an agreement that a committee leader is malicious, everyone in starts Algorithm 7 to re-select a committee leader.

The committee and the partial set ;
A new leader and a set of signatures on it which can be used to verify that he is the new leader.
1:Everyone chooses as the new leader when was proved to be a malicious member and evicted;
2:Everyone signs on the new leader’s and sends it to the new leader;
3:return .
Algorithm 7 Leader Re-selection

Fig. 6 shows the above process. Afterwhile, the new leader needs to make a new semi-commitment of the committee via the semi-commitment exchanging protocol. When a participant of receives the new semi-commitment, he should tell every committee leader this new semi-commitment and leader’s address, so that cross-shard transaction handling may start safely.

Now we claim that the given procedure is both complete and sound:

Claim 3.

A malicious leader will always be detected and thus evicted via the leader re-selection procedure, as long as has an honest majority.


Note that there is at least one honest node in any partial set. Therefore, as a leader’s action is always monitored by the partial set during the execution of the whole protocol (see further analysis in later subsections), any irregular behaviour from the leader will be detected and a witness will be inevitably grasped by the honest partial set member. At the same time, as the evidence is signed by the ”criminal” himself, no erroneous judgement will occur. ∎

Claim 4.

An honest leader will never be framed up by a malicious partial set member, as long as has an honest majority.


We mention that a witness is valid if and only if the first part of it is a message signed by the leader himself. With respect to the security of the digital signature scheme, a vicious partial set member cannot counterfeit an evidence as the latter has to be a leader’s signed message. Therefore, a loyal leader will never be unjustly accused. ∎

As proved above, the probability that more than half members in are malicious is negligible. Thus, we claim that our recovering procedure remains complete and sound with high probability.

Fig. 6: This figure shows an example of the reporting mechanism and leader re-selection, where is the Referee Committee, is a partial set member, and are two committee members.

V-E Security on Intra-committee Consensus

If the leader provides different members with different messages in the first step of Algorithm 3, an honest member who notices this can suspect that the leader is dishonest. By showing the warning and leader’s signature, other members can verify that the leader indeed behaved outside the restriction.

V-F Security on Inter-committee Consensus

If the leader is witnessed to imitate the cross-shard transactions or conceal them, a partial set member can challenge the leader’s honesty by checking signatures from members of the sending committee. We need to notice that a member can only judge the leader is malicious when he can ensure his leader conceals the transaction set to him. That is, a member in does not receive transactions from after a time since he receives the transaction set from , the leader of the other committee. Here, is the delay of communication.

Vi Performance Analysis

We claim that our protocol is efficient in intra-shard and cross-shard transactions processing as we introduce leaders and commitments. Yet, our protocol suffers the efficiency curse of commitment exchanging and block generation and propagation. However, we point out that the heavy overheads are only afforded by of each round.

Recall that we use to denote the number of nodes in the network, to denote the number of committees and to denote the expected amount of participants in a committee.

Vi-a Complexity of Committee Configuration

In this phase, all members in any committee except will recognize each other, which imposes a communication, computation and storage complexity of for all common members. For leaders and partial set members, the communication complexity is multiplied by as each of them has to deliver pieces of information to the applying participant.

Vi-B Complexity of Commitment Exchanging

For any leader, he is obliged to produce the commitment of his own committee and note down commitments from all other committees. Thus, the computation complexity is while the storage complexity is . Yet, members in has to suffer from the huge transportation overhead of as they have to propagate all commitments to all committees as intermediary.

Vi-C Complexity of Reaching Intra-committee Consensus

To reach consensus on a set of information with constant size, one in a committee has to broadcast the set with his signature to all members in a committee, which causes a communication complexity of . For leaders and partial set members, they have to store the information with at least half of members’ to acknowledge the set, thus, a storage complexity of is induced. At the same time, common members only need to keep his own opinion in reserve.

Vi-D Complexity of Block Generation and Propagation

To propose a block whose size is and broadcast it to all committees, an communicating burden and an storage overhead are inevitable for any participant in , which lowers the efficiency of our protocol on a large scale. Yet, this expense also exists in almost all previous protocols. At the same time, for any other attender, the storage complexity is only , as he only needs to maintain the paticipants, transactions and UTXOs within the committee he belongs to.

We summarize the theoretical analysis on the performance of CycLedger in Table II.

Communication & Computation / Storage Complexity Common Members Leaders & Partial Set Members Members
Committee Configuration -
Commitment Exchanging -
Intra-committee Consensus
Inter-committee Consensus
Reputation Updating
Key Member Selection - -
Block Generation & Broadcasting
  • : total amount of nodes in the network : amount of committees : amount of nodes in a committee, we mention again that .

TABLE II: Communication, Computation & Storage Complexity of CycLedger

Vii Incentive Analysis

Besides security, reputation is also a highlight of CycLedger. When introducing the concept of reputation to our protocol, there are two main problems: what reputation reflects and how reputation works. In this section, we give a discussion on the incentive of our protocol, by analysing these two problems.

Vii-a Incentive on Reputation

In general, reputation is expected to reflect the honest computational resources of each node in CycLedger.

The most basic task of nodes in each committee, in short, is to give opinions on the validation of requested transactions. One’s reputation is a reflection on his behaviours. For a newly joined node, based on his blank work experience, the reputation will start from zero. However, as long as he begins to work, the reputation will match his behaviour. Specifically, for an honest node with more computing resources, he could make more correct judgements on the validation of transactions, thus, earning a higher reputation. While for the malicious nodes, reputation is closely related to his evilness, or in other words, the honest computational resources he really contributes.

One’s reputation determines his profit in each round. Nodes with higher reputation will get more payment after a new block is successfully generated. Owing to the scoring mechanism and reward mechanism, reputation provides enough incentive for nodes to work honestly and as hard as they can. In this way, reputation can be considered as a reflection of the honest computational resources one node contributes.

In CycLedger, leaders have higher workload compared with other members. With this in mind, we directly choose the nodes with the highest reputation as leaders in each round, thus to enhance the performance and throughput of CycLedger even further. In return, leaders obtain some extra reputation as a bonus for their hard work, which means higher revenue. Therefore, leaders will have enough incentive to behave honestly.

It is certain that a high reputation is not once and for all. Recalling the proportional design in our reward mechanism, one’s revenue actually depends on the relative value of his reputation. Thus for each node, not to advance is to go back. No matter one’s reputation is high or not, to be lazy or malicious will lead to lower income. So it appears that the best possible strategy for a node is, to use all his computational resources to work within rules.

Vii-B Punishment on Reputation

Up to this point, we have been focusing on how the reputation motivates nodes to work hard. In this section, we will discuss what if someone, especially a leader, breaks the rules.

Intuitively, the scoring mechanism can be considered as, awarding points for right answers, deducting marks for wrong answers and nothing to happen for no answer. Thus when giving wrong votes, intentionally or unintentionally, the node will face the corresponding decline in reputation. That is, the scoring mechanism itself contains the punishment on reputation.

Moreover, if it is a leader who violates the protocol, there will be more serious penalty. Once a leader is confirmed to have done something bad by the referee committee, his reputation will be decreased to the cube root. Recall that all leaders are selected from nodes with the highest reputation. We believe that the reputation of each leader is larger than 0, including a malicious one’s. Combining this punishment with (2), the mapped value, which is closely related to his revenue, will reduce to about one third of the original mapped value. That is, the higher reputation a leader has, the stronger punishment he will suffer when he behaves maliciously.

Viii Future Works

After that, we introduce two skills which can enhance the efficiency of our protocol.

Viii-a Excluding Low-value Transactions through Extra Communication

Assume and are the leader of committee and , respectively. According to our protocol, if wants to pack transactions which are related to UTXOs managed by , should pack up those transactions while nodes in should run Algorithm 2 to generate a package , then nodes in should also run Algorithm 2 to confirm if is valid. However, in some situation, most transactions in may be invalid, for example, when the network suffers Denial-of-Service (DoS) attack. In this case, this interaction process maybe a waste of computational resource.

Now we want to make transactions chosen by have a high probability to be accepted by so as to enhance the efficiency. One practical way is that leaders can communicate with each other before sending packages. For instance, can ask which transactions are valid, and receives a preference from instead of the agreement of . This extra step of communication does not have any effect more than that may get more information about those transactions he is in charge of. As a result, If is honest and believes in him, there will be less invalid transactions being packaged.

So what if lies? Is he motivated to be truthful? We can set up a mechanism so that if tells lies, he may get punished. To achieve this, can record the response of and then generate a packet by Algorithm 2, including all transactions mentioned by regardless of the validity points out. Thus, if told a transaction is invalid yet accepted by , should be punished, such as a reduction on reputation.

Viii-B Parallelizing Block Generation

In our protocol, is in charge of proposing a block at the end of a round. This causes a huge connection burden on the referee committee. To boost the efficiency, we can have each committee broadcast the block. In detail, after receiving enough authentication on a certain set of transactions from committee participants, a leader can forward the set to for verification. After obtaining permission from the referee committee, the leader can immediately broadcast the block to the whole network. Applying this change to our protocol, we can adopt the schedule proposed by [3] in our protocol. We call two transactions are relevant if they follow one of the following properties:

  1. They use the same UTXO as input;

  2. One transaction spends the output of the other one.

Observe that those irrelevant transactions can be processed in parallel. Thus, a committee can sequentially produce and broadcast blocks within a round. As a result, two transactions satisfying the second property above may both be accepted in the same round. This event never happens in our original protocol as at least one of them will be regarded as illegal. Thus, by using this mechanism, we can enhance the efficiency and reliability of our protocol.

Ix Conclusion

We present CycLedger, a 1/3-resilient sharding-based distributed ledger protocol with scalability, reliable safety and incentives. By splitting nodes into committees and each committee processes a set of transactions in parallel, we maximize the utilization of computational resource, bringing high throughput to our protocol. We enables every user to trade safely with other users by introducing commitments between committees and a recovery procedure so that the security is guaranteed even when leaders are malicious. Meanwhile, by adopting evaluation on every user’s reputation, our protocol has considerable incentive. At the same time, taking usage of reputation, CycLedger can locate those honest nodes with high computational power. By assigning them to high positions, we may enhance the efficiency of our protocol. Finally, our analysis demonstrates that CycLedger has nice performance and can provide striking security.


  • [1] S. Nakamoto, “Bitcoin: A peer-to-peer electronic cash system,” Available at, 2009.
  • [2] L. Luu, V. Narayanan, C. Zheng, K. Baweja, S. Gilbert and P. Saxena, “A Secure Sharding Protocol For Open Blockchains,” In Proceedings of the 2016 ACM SIGSAC Conference on Computer and Communications Security (CCS), October 2016, pp.17-30.
  • [3] E. Kokoris-Kogias, P. Jovanovic, L. Gasser, N. Gailly, E. Syta and B. Ford, “OmniLedger: A Secure, Scale-Out, Decentralized Ledger via Sharding,” In 2018 IEEE Symposium on Security and Privacy (S&P), May 2018, pp.583-598.
  • [4] M. Zamani, M. Movahedi and M. Raykova, “RapidChain: Scaling Blockchain via Full Sharding,” In Proceedings of the 2018 ACM SIGSAC Conference on Computer and Communications Security(CCS), October 2018, pp.931-948.
  • [5] C. Huang, Z. Wang, H. Chen, Q. Hu, Q. Zhang, W. Wang and X. Guan, “RepChain: A Reputation based Secure, Fast and High Incentive Blockchain System via Sharding,” arXiv preprint arXiv:1901.05741, 2019.
  • [6] M. Castro and B. Liskov, “Practical Byzantine Fault Tolerance,” In Proceedings of the 3rd USENIX Symposium on Operating Systems Design and Implementation (OSDI), February 1999, pp.173-186.
  • [7] A. Kiayias, A. Russell, B. David and R. Oliynykov, “Ouroboros: A Provably Secure Proof-of-Stake Blockchain Protocol,” In Advances in Cryptology - CRYPTO 2017 - 37th Annual International Cryptology Conference, Proceedings, Part I, August 2017, pp.357-388.
  • [8] Y. Gilad, R. Hemo, S. Micali, G. Vlachos and Nickolai Zeldovich, “Algorand: Scaling Byzantine Agreements for Cryptocurrencies,” In Proceedings of the 26th Symposium on Operating Systems Principles(SOSP), October 2017, pp.51-68.
  • [9] B. David, P. Gazi, A. Kiayias and A. Russell, “Ouroboros Praos: An Adaptively-Secure, Semi-synchronous Proof-of-Stake Blockchain,” In Advances in Cryptology - EUROCRYPT 2018 - 37th Annual International Conference on the Theory and Applications of Cryptographic Techniques, Proceedings, Part II, May 2018, pp.66-98.
  • [10] R. Pass and E. Shi, “Sleepy Model of Consensus,” In Advances in Cryptology - ASIACRYPT 2017 - 23rd International Conference on the Theory and Applications of Cryptology and Information Security, Proceedings, Part II, December 2017, pp.380-409.
  • [11] I. Bentov, R. Pass and E. Shi, “Snow White: Provably Secure Proofs of Stake,” IACR Cryptology ePrint Archive:2016/919, 2016.
  • [12] S. Micali, M. O. Rabin and S. P. Vadhan, “Verifiable Random Functions,” In 40th Annual Symposium on Foundations of Computer Science(FOCS), October 1999, pp.120-130.
  • [13] B. Schoenmakers, “A Simple Publicly Verifiable Secret Sharing Scheme and its Application to Electronic Voting,” In Advances in Cryptology - CRYPTO ’99, 19th Annual International Cryptology Conference, Proceedings, August 1999, pp.148-164.
  • [14] I. Cascudo and B. David, “SCRAPE: Scalable Randomness Attested by Public Entities,” In Applied Cryptography and Network Security(ACNS) - 15th International Conference, Proceedings, July 2017, pp.537-556.
  • [15] E. Syta and P. Jovanovic and E. K. Kogias and N. Gailly and L. Gasser and I. Khoffi and M. J. Fischer and B. Ford, “Scalable Bias-Resistant Distributed Randomness,” In 2017 IEEE Symposium on Security and Privacy (S&P), May 2017, pp.444-460.
  • [16] G. Danezis and S. Meiklejohn, “Centrally Banked Cryptocurrencies,” In 23rd Annual Network and Distributed System Security Symposium(NDSS), February 2016.
  • [17] E. Kokoris-Kogias, P. Jovanovic, N. Gailly, I. Khoffi, L. Gasser and B. Ford, “Enhancing Bitcoin Security and Performance with Strong Consistency via Collective Signing,” In 25th USENIX Security Symposium, USENIX Security 16, August 2016, pp.279-296.
  • [18] A. Gervais, G. O. Karame, V. Capkun and S. Capkun, “Is Bitcoin a Decentralized Currency?,” In IEEE Security & Privacy(S&P), 2014, 12(3):54-60.
  • [19] C. Cachin, R. Guerraoui and L. Rodrigues, “Introduction to Reliable and Secure Distributed Programming (2.ed.)”, Springer, 2011.
  • [20] N. Christin, A. S. Weigend and J. Chuang, “Content Availability, Pollution and Poisoning in File Sharing Peer-to-Peer Networks,” In Proceedings of the 6th ACM Conference on Electronic Commerce(EC), June 2005, pp.68-77.
  • [21] S. D. Kamvar, M. T. Schlosser and H. Garcia-Molina, “The Eigentrust Algorithm for Reputation Management in P2P Networks,” In Proceedings of the 12th International Conference on World Wide Web(WWW), May 2003, pp.640-651.
  • [22] K. Walsh and E. G. Sirer, “Experience with an Object Reputation System for Peer-to-Peer Filesharing,” In 3rd USENIX Symposium on Networked Systems Design and Implementation(NSDI), May 2007.
  • [23] E. Damiani, D. C. D. Vimercati, S. Paraboschi, P. Samarati and F. Violante, “A Reputation-based Approach for Choosing Reliable Resources in Peer-to-Peer Networks,” In Proceedings of the 2002 ACM SIGSAC Conference on Computer and Communications Security(CCS), November 2002, pp.207-216.
  • [24] M. Feldman, K. Lai, I. Stoica and J. Chuang, “Robust Incentive Techniques for Peer-to-Peer Networks,” In Proceedings of the 5th ACM Conference on Electronic Commerce(EC), May 2004, pp.102-111.
  • [25] M. Nojoumian, A. Golchubian, L. Njilla, K. Kwiat, and C. Kamhoua, “Incentivizing Blockchain Miners to Avoid Dishonest Mining Strategies by a Reputation-based Paradigm,” In Proceedings of the 2018 IEEE Computing Conference(CC), Volume 2, January 2018, pp.1118-1134.
  • [26] K. Croman, C. Decker, I. Eyal, A. E. Gencer, A. Juels, A. E. Kosba, A. Miller, P. Saxena, E. Shi, E. G. Sirer, D. Song and R. Wattenhofer, “On Scaling Decentralized Blockchains - (A Position Paper),” In Financial Cryptography and Data Security - FC 2016 International Workshops, BITCOIN, VOTING, and WAHC, Revised Selected Papers, February 2016, pp.106-125.
  • [27] Visa. Visa’s transaction per second. Available at run-your-business/small-business-tools/retail.html
  • [28] Cardano. Cardano Settlement Layer Documentation. Leader Selection in Cardano SL. Available at