PaperlayerView exact revision on arXiv

Source-linked AI summary

RepChain: A Reputation-based Secure, Fast and High Incentive Blockchain System via Sharding

Chenyu Huang, Zeyu Wang, Huangxun Chen, Qiwei Hu, Qian Zhang, Wei Wang, Xia Guan

arXiv:1901.05741v2cs.CRcs.NI

TL;DR

Sharded blockchains need higher throughput and security while accounting for validator heterogeneity and avoiding excessive incentive overhead. RepChain addresses these challenges with reputation-based sharding, a double-chain architecture, and specialized consensus mechanisms, and reports improved throughput and security in its evaluation.

  • Problem

    Existing sharding designs use random-based assignment that does not leverage validator heterogeneity, while reputation-based incentives can impose substantial system overhead.

  • Method

    RepChain uses reputation-based sharding and leader selection with separate transaction and reputation chains, combining synchronous Raft, Byzantine fault tolerance, and collective signing.

  • Results

    RepChain’s evaluation reports throughput rising to 5243 tps after about 8 epochs, compared with 3512 tps without the reputation scheme.

  • Takeaways & Limitations

    Reputation in RepChain is used to improve throughput, balance shard security, and reward greater contributions by honest and competent validators.

Abstract

from arXiv · show

In today's blockchain system, designing a secure and high throughput blockchain on par with a centralized payment system is a difficult task. Sharding is one of the most worthwhile emerging technologies for improving the system throughput while maintain high security level. However, previous sharding related designs have two main limitations: Firstly, the throughput of their random-based sharding system is not high enough as they did not leverage the heterogeneity among validators. Secondly, to design an incentive mechanism to promote cooperation could incur a huge overhead on their system. In this paper, we propose RepChain, a reputation-based secure and fast blockchain system via sharding, which also provides high incentive to stimulate node cooperation. RepChain utilizes reputation to explicitly characterize the heterogeneity among the validators and lay the foundation for the incentive mechanism. We propose a new double-chain architecture which includes transaction chain and reputation chain. For transaction chain, a Raft-based synchronous consensus that can achieve high throughput has been presented. For reputation chain, the synchronous Byzantine fault tolerance that combines collective signing has been utilized to achieve a consensus on both reputation score and the related transaction blocks. It supports a high throughput transaction chain with moderate generation speed. Moreover, we propose a reputation-based sharding and leader selection scheme. To analyze the security of RepChain, we propose a recursive formula to calculate the epoch security within only O(km^2) time. Furthermore, we implement and evaluate RepChain on the Amazon Web Service platform. The results show our solution can enhance both throughout and security level of the existing sharding-based blockchain system.

I. INTRODUCTION

RepChain addresses scalability and incentive challenges in sharded blockchains by using reputation to model validator heterogeneity and support cooperation. Its double-chain design combines fast transaction processing with reputation consensus, while analysis and evaluation assess security and performance.

  • Motivation: Existing blockchains struggle to provide both high throughput and high security, while global consensus keeps validation workload growing without increasing system capacity.Bitcoin and Ethereum are cited as handling 7 and 15 transactions per second, respectively.
  • Challenges: Random or balanced-random sharding can make less-competent validators bottlenecks because practical validators differ in computing capability, bandwidth, and historical behavior.The paper also identifies incentive mechanisms as important for validator activation and retention.
  • Approach: RepChain uses reputation to characterize validator heterogeneity, elect capable shard leaders, balance shard composition, and support a reputation-based reward scheme.The design aims to improve throughput and security while recognizing greater contributions by honest, competent validators.
  • Architecture: Its double-chain architecture separates transaction and reputation chains, using synchronous Raft for fast transaction blocks and Byzantine fault-tolerant consensus with collective signing for reputation consensus.The reputation chain is intended to support a high-throughput transaction chain with moderate generation speed.
  • Evaluation: RepChain contributes reputation-based sharding and leader selection, recursive epoch-security analysis with O(km^2) time complexity, and an Amazon Web Services implementation and evaluation.The paper reports analysis of security, throughput, and incentive mechanisms alongside extensive evaluation.

A. Blockchain Scalability

Sharding addresses blockchain scalability by distributing transactions across groups that process them in parallel, but existing approaches and reputation systems retain important limitations. RepChain is positioned against these efforts as a sharded design that integrates reputation with scalability concerns.

  • Other Scalability Approaches: Alternative scalability methods have trade-offs: Bitcoin-NG increases per-node computation, while off-chain payment systems generally lack the main chain’s security guarantees.ByzCoin reduces PBFT communication complexity without fundamentally changing PBFT’s scalability limitation.
  • Sharding-based Blockchain: Sharding improves scalability by distributing transactions across shards so they can be processed in parallel.The paper describes total throughput as the product of in-shard throughput and the number of shards.
  • Sharding-based Blockchain: Existing systems use varied approaches, including permissionless BFT sharding, verifiable-random leader selection, synchronous protocols, and asynchronous consensus zones.The cited systems include Elastico, OmniLedger, RapidChain, and Monoxide.
  • Reputation and Blockchain: Prior reputation-based blockchain systems include incentive or credit mechanisms but are not designed to address sharding-based scalability.CertChain is tailored to certifying authorities, while B-IoT and PoT use credit-based proof-of-work systems.
  • Reputation and Blockchain: Reputation based on cumulative work without decay can enable monopoly, collusion, double spending, and barriers for new validators.The passage also states that attackers joining at the beginning could defeat such systems.

C. Threat Model

RepChain assumes a Byzantine adversary controlling fewer than one-third of nodes and models attacks that manipulate validator behavior, shard placement, leadership, or reputation. Its system overview links sharding, consensus, reputation, and synchronization across transaction and reputation chains.

  • Threat Model: The threat model assumes authenticated communication and a Byzantine adversary that corrupts fewer than f = n/3 fixed nodes.Corrupted nodes may collude, send invalid information, or remain silent.
  • Attack Strategies: The considered behavioral attacks are Simple Attack, Camouflage Attack, and Observe-Act Attack.Observe-Act attackers match the reputation distribution of normal validators to increase the chance that malicious nodes occupy one shard.
  • Reputation Attacks: RepChain also considers Self-Promoting and Slandering attacks that respectively inflate malicious validators’ scores or reduce honest validators’ scores.Both attacks are attributed to malicious leaders.
  • System Overview: The system assigns nodes to shards, selects leaders, runs intra-shard consensus, and maintains transaction and reputation blockchains.Cross-shard transactions use an atomic cross-shard protocol, and epoch-end state blocks synchronize reputation scores.
  • System Overview: Reputation scores support leader selection and shard balancing, while the combined components are intended to provide a high-throughput, secure, and high-incentive blockchain.The architecture includes separate transaction and reputation chains.

IV. SYSTEM DESIGN

RepChain’s sharding and leader-selection design aims to make assignment unpredictable, balanced, locally verifiable, and incentive-compatible. Validators are ordered by reputation, assigned to the least-populated shards, and leaders are selected using reputation-weighted randomness.

  • Design Properties: The design targets randomness, balance, uniformity, and incentive as four properties of sharding and leader selection.Balance includes similar total reputation scores and similar proportions of validator types across shards.
  • Sharding: Validators are sorted by cumulative reputation over a sliding window before shard assignment.The cumulative score uses reputation from the previous w epochs, allowing reputation to decay over time.
  • Sharding: Each validator is assigned to a shard with minimum cardinality, with random tie-breaking when multiple shards qualify.The procedure initializes shard and leader sets and uses a seeded random generator.
  • Leader Selection: For leader selection, validators above the shard’s median reputation receive selection chances through a shared random seed and score-based calculation.The validator with the minimum resulting value is selected as leader.
  • Outputs: The resulting sets contain k shards C = {C1, C2, ..., Ck} and k leaders L = {l1, l2, ..., lk}.The algorithm produces one leader for each shard.

B. Consensus

RepChain’s intra-shard consensus uses a synchronous Raft-based transaction chain, while shards store transactions by identity and support cross-shard inputs. The leader coordinates validator decisions to generate transaction blocks.

  • Transactions are assigned to shards by identity prefix, while their input UTXOs may originate from different shards.The shard responsible for an input UTXO is the input shard, and the shard responsible for an output UTXO is the output shard.
  • RepChain constructs a Raft transaction chain and a Byzantine fault tolerance reputation chain within each shard.The synchronous consensus is designed for high throughput and 1/2 resilience within a shard.
  • The communication patterns explicitly cover both honest and malicious leader cases for Raft consensus.
  • The leader sends a transaction list, collects validator decisions, creates a transaction block, and broadcasts the decision set with that block.Validators classify each transaction as Accept, Reject, or Unknown before returning their decisions to the leader.

1) Intra-shard Consensus:

RepChain generates reputation blocks through Byzantine fault-tolerant consensus and collective signing after intra-shard transaction consensus. Its reputation scheme scores validator behavior using transaction values and behavior-dependent penalties or rewards.

  • Intra-shard Consensus: The reputation block contains confirmed transaction-block hashes and the reputation scores of all validators.The reputation consensus is combined with collective signing to aggregate multiple signatures into one signature for cross-shard validation.
  • Intra-shard Consensus: Warnings from f + 1 honest validators trigger view-change when a leader sends invalid transaction data or omits an honest validator’s decision.The mechanism addresses invalid transaction lists, decision sets, transaction blocks, and reputation-affecting omissions.
  • Intra-shard Consensus: For cross-shard transactions, Atomix uses the collective signature on the reputation block as the proof of acceptance.
  • Reputation Score Calculation: Validator reputation scores are calculated uniformly from the transaction decision set and transaction block after each intra-shard consensus.
  • Reputation Score Calculation: Transaction values weight reputation updates, while scaling factors assign different rewards or penalties to validator behaviors.Dishonest behavior is penalized more heavily than honest behavior is rewarded; Unknown decisions neither increase nor decrease reputation.

2) Reputation Blockchain:

RepChain combines transaction and reputation chains, using consensus mechanisms and recursive security analysis to coordinate fast transaction processing with reputation-aware shard security. Its analysis covers random sharding, observe-act attacks, and camouflage attacks.

  • Double-chain architecture: State blocks synchronize reputation scores and client UTXO sets across shards before the next epoch.Validators generate state blocks through RapidChain consensus with CoSi rather than transmitting the entire blockchain.
  • Double-chain architecture: RepChain’s double-chain architecture separates transaction and reputation blockchains, combining Raft with CoSi and RapidChain consensus for transaction and reputation-block confirmation.The transaction chain is generated quickly with Raft, while the reputation chain confirms reputation blocks and related transaction blocks against Byzantine faults.
  • Epoch security: O(km^2) recursive formulas calculate exact epoch security, improving on prior upper-bound estimation requiring O(mk) time.The formulas count safe allocations while accounting for malicious-validator distributions across shards.
  • Epoch security: For random-based sharding with n = 1800 and k = 8, P(failure) = 1.25553e−07.The failure probability is defined through the proportion of unsafe allocations among all allocations.
  • Epoch security: Observe-act attacks reduce RepChain’s security and performance to random-sharding levels, while the system remains secure enough under the stated calculation.This occurs because malicious validators preserve the same reputation-score distribution as honest validators.
  • Epoch security: Under camouflage attacks, exposed malicious validators receive lower reputation and RepChain is more secure than random sharding.The analysis models exposed and unexposed malicious validators through a recursive safe-allocation formula.

B. Security of Intra-shard Consensus

RepChain establishes intra-shard consensus safety by combining an epoch-security result with Byzantine-tolerant confirmation of reputation and transaction blocks. Raft alone is insufficient for Byzantine safety, so RapidChain’s consensus provides the safety guarantee.

  • Security of Intra-shard Consensus: A shard containing more than half malicious validators is almost impossible, supporting the safety and liveness of intra-shard consensus.The consensus proof relies on the preceding epoch-security analysis.
  • Security of Intra-shard Consensus: Raft cannot guarantee transaction-block safety against Byzantine faults, so RapidChain’s consensus secures reputation blocks and their related transaction blocks.The adding-response round is analyzed to ensure it does not violate RapidChain’s original safety property.

2) Liveness of Intra-shard Consensus:

RepChain combines Raft-based transaction consensus with Byzantine fault tolerance for reputation consensus, while reputation-based leader selection leverages validator capability differences and supports incentives.

  • Liveness of Intra-shard Consensus: Raft consensus eventually produces a valid transaction block because honest leaders can obtain transaction decisions, while malicious leaders trigger timeout-based view changes.The expected round for an honest leader is around two in the worst case.
  • Liveness of Intra-shard Consensus: Byzantine fault tolerance preserves liveness for reputation blocks because honest validators determine acceptance before the response round completes.A malicious leader causes a view change; otherwise, honest validators finish the response.
  • Consensus Complexity: RepChain’s consensus complexity is O(m^2/b) for Raft and O(m^2/b + n) for modified RapidChain consensus with cross-shard communication.The additional O(n) term applies to cross-shard transactions.
  • Performance and Incentives: Reputation-based leadership eases least-capable validators’ workload and gives more capable validators greater leader-selection probability, improving throughput through additional resources.Leaders contribute more bandwidth and computing resources to generate TxList, TxDecSet, and transaction blocks.
  • Performance and Incentives: Rewards combine transaction fees and reputation scores, making honesty more beneficial while a sliding window favors validators contributing continuously.The leader receives half the transaction fee; the remainder is allocated according to current-epoch reputation.

VI. EVALUATION

The evaluation measures RepChain’s performance, scalability, threat-model behavior, heterogeneity-aware throughput, and epoch-transition latency using AWS experiments. Across shard sizes, throughput decreases as latency increases, while shard size 225 provides higher throughput than prior works at comparable latency.

  • Evaluation Scope: RepChain’s evaluation covers performance under different settings, scalability, threat models, validator heterogeneity, and epoch-transition time.The implementation uses Go and collective-signing cryptography libraries.
  • Experimental Setup: The experiments use a globally distributed AWS deployment with 900 instances across US West and US East, totaling 1800 simulated nodes.The deployment places 450 instances in each region.
  • Performance: 15421 tps at shard size 100 decreases to 1485 tps at shard size 450, while latency rises from 20.4s to 146s.The intermediate throughput values are 6853 tps and 4288 tps for shard sizes 225 and 300, respectively.
  • Metrics: The evaluation measures throughput and user-perceived latency, defining latency as the interval from transaction submission until confirmation by an honest node.For RepChain, confirmation occurs when the reputation block is built.
  • Performance: At shard size 225, RepChain has larger throughput than previous works while latency is almost equal to OmniLedger.The passage presents this as evidence that the transaction chain supports high throughput.

C. Scalability

RepChain scales throughput with node count and uses reputation to sustain performance under attacks and heterogeneous validator capabilities. Its comparison emphasizes reputation-based balancing, leadership, incentives, and security, with transition latency increasing as shards grow.

  • Scalability: 1834 tps at 450 nodes rises to 6853 tps at 1800 nodes with shard size 225, indicating linear throughput growth as nodes increase.The intermediate throughputs are 3610 tps and 5333 tps for 900 and 1350 nodes.
  • Threat Models: Under attack models, average throughput is 6104 tps for Camouflage Attack and 5628 tps for Observe-Act Attack.Simple Attack initially reduces performance, but attackers have lower reputation after the third epoch and barely degrade performance thereafter.
  • Throughput Enhancement: After about 8 epochs, reputation-based leader selection raises throughput to an average of 5243 tps, compared with 3512 tps without reputation.Validators’ capabilities follow a uniform distribution from 5% to 100%.
  • Epoch Transition: RepChain’s epoch-transition latency increases from 61.2s at shard size 100 to 242.0s at shard size 450.State-block generation is the most time-consuming of the three transition stages.
  • Comparison with Other Works: Compared with prior systems, RepChain integrates reputation for capability-aware leadership, balanced sharding, and contribution-based rewards.Its comparison reports 5628 tx/s with shard size 225 in the listed configuration.

VII. DISCUSSION

RepChain’s discussion identifies communication latency and attacker models as important constraints, while outlining parameter randomization as a defense against observe-act attacks.

  • A. Information Dispersal Algorithms: TCP messaging among all validators produces relatively high latency that reduces RepChain’s throughput.The paper suggests more efficient information-dispersal algorithms, such as IDA-Gossi, as a possible improvement.
  • B. Slowly Adaptive Attacker: A slowly adaptive attacker can defeat reputation-based blockchain systems when victims are assumed to have the same security level.RepChain instead considers a threat model in which validators may have different security levels.
  • C. Dynamic Parameters: In the worst case, an advanced observe-act attack reduces RepChain’s security to that of random-based solutions.The proposed mitigation dynamically changes the reputation formula, sliding window, and sharding scheme using randomness across epochs.
  • VIII. CONCLUSION: RepChain combines a Raft-based transaction chain with a collectively signed reputation chain and reputation-based sharding and leader selection.The paper reports that its evaluation shows improved throughput and security while providing an incentive mechanism.
Loading 1901.05741v2…