RapidChain：全分片技术提升区块链性能与可扩展性

需积分: 45 112 浏览量更新于2024-07-15 收藏 1.06MB PDF 举报

RapidChain: Scaling Blockchain via Full Sharding 是一篇由 Mahdi Zamani、Mahnush Movahedi 和 Mariana Raykova 合著的研究论文，发表于 dl.acm.org。本文旨在探讨如何通过全分片（full sharding）技术来解决当前区块链协议在性能和可扩展性方面的局限性。区块链技术的核心挑战在于处理大量交易时的性能瓶颈和存储需求，传统的单链设计往往限制了系统的扩展性，因为它将所有节点的工作负载集中在单一网络中。全分片的核心思想是将交易处理的负担分散到多个较小的节点组（或称为“分片”）中。这些分片并行工作，从而极大地提高了处理效率。然而，目前基于分片的区块链协议存在一个关键问题：每笔交易仍需要线性的通信量，即与参与者的数量成正比。这导致了即使使用了分片技术，系统在可扩展性上也仅能达到部分潜力，因为通信开销仍然是制约因素。论文作者指出，这种线性依赖限制了交易吞吐量和延迟的提升，使得分片的优势未能充分发挥。此外，现有的分片区块链协议在安全方面也有待改进。它们要么具有较低的容错能力，例如只能容忍1/8或1/4的节点故障，这意味着对网络的稳定性有较高要求；要么依赖于强有力的假设，如信任设置，这些假设在实际应用中可能难以实现。为了克服这些问题，RapidChain提出了一个全新的架构，旨在减少每笔交易的通信需求，同时提供更强的安全保障。这可能包括采用更有效的共识机制、提高分片间的协调效率，以及设计能够抵抗恶意攻击的分片策略。通过这些改进，RapidChain的目标是打破现有协议的瓶颈，为区块链技术开辟一条通向更高性能和更大规模网络的道路。 RapidChain的研究提供了一种潜在的解决方案，旨在通过优化分片技术，降低每个节点的计算、通信和存储负担，同时增强系统的安全性，以推动区块链技术迈入一个新的发展阶段。这篇论文对于理解区块链可扩展性和安全性之间的平衡，以及如何设计未来的分布式账本系统具有重要意义。

which node to target until it participates in the BA? protocol with other committee members. Algo-

rand replaces committee members with new members in every step of BA? to avoid targeted attacks

on the committee members by a fully-adaptive adversary. Unfortunately, the randomness used in

each VRF invocation (i.e., the VRF seed) can be biased by the adversary; the protocol proposes a

look-back mechanism to ensure strong synchrony and hence unbiased seeds, which unfortunately,

results in a problematic situation known as the “nothing at stake” problem [32]. To solve the biased

coin problem, Dﬁnity[33] propose a new VRF protocol based on non-interactive threshold signature

scheme with uniqueness property.

Assuming a trusted genesis block, Solida [4] elects nodes onto a committee using their solutions to

PoWs puzzles that are revealed in every round via 2t + 1 committee member signatures to avoid pre-

computation (and withholding) attacks. To ﬁll every slot in the ledger, a reconﬁgurable Byzantine

consensus protocol is used, where a consensus decision is made on either a batch of transactions or a

reconﬁguration event. The latter records membership change in the committee and allows replacing

at most one member in every event by ranking candidates by their PoW solutions. The protocol

allows the winning candidate to lead the reconﬁguration consensus itself avoiding corrupt internal

leaders to intentionally delay the reconﬁguration events in order to buy time for other corrupt nodes

in the PoW process.

2.2 Sharding-Based Consensus

Unlike Bitcoin, a sharding-based blockchain protocol can increase its transaction processing power

with the number of participants joining the network by allowing multiple committees of nodes

process incoming transactions in parallel. Thus, the total number of transaction processed in each

consensus round by the entire protocol is multiplied by the number of committees. While there are

multiple exciting, parallel work on sharding-based blockchain protocols such as [64, 65], we only

study results that focus on handling sharding in the Bitcoin transaction model.

2.2.1 RSCoin

Danezis and Meiklejohn [22] propose RSCoin, a sharding-based technique to make centrally-banked

cryptocurrencies scalable. While RSCoin describes an interesting approach to combine a central-

ized monetary supply with a distributed network to introduce transparency and pseudonymity to

the traditional banking system, its blockchain protocol is not decentralized as it relies on a trusted

source of randomness for sharding of validator nodes (called mintettes) and auditing of transactions.

Moreover, RSCoin relies on a two-phase commit protocol executed within each shard which, unfor-

tunately, is not Byzantine fault tolerant and can result in double-spending attacks by a colluding

adversary.

2.2.2 Elastico

Luu et al. [47] propose Elastico, the ﬁrst sharding-based consensus protocol for public blockchains.

In every consensus epoch, each participant solves a PoW puzzle based on an epoch randomness

obtained from the last state of the blockchain. The PoW’s least-signiﬁcant bits are used to determine

the committees which coordinate with each other to process transactions.

While Elastico can improve the throughput and latency of Bitcoin by several orders of magni-

tude, it still has several drawbacks: (1) Elastico requires all parties to re-establish their identities

(i.e., solve PoWs) and re-build all committees in “every” epoch. Aside from a relatively large com-

munication overhead, this incurs a signiﬁcant latency that scales linearly with the network size as

the protocol requires more time to solve enough PoWs to ﬁll up all committees; (2) In practice,

Elastico requires a small committee size (about 100 parties) to limit the overhead of running PBFT

in each committee. Unfortunately, this increases the failure probability of the protocol signiﬁcantly

and, using a simple analysis (see [42]), this probability can be as high as 0.97 after only six epochs,

rendering the protocol completely insecure in practice; (3) The randomness used in each epoch of

Elastico can be biased by an adversary, and hence, compromise the committee selection process and

even allow malicious nodes to precompute PoW puzzles; (4) Elastico requires a trusted setup for

generating an initial common randomness that is revealed to all parties at the same time; (5) While

Elastico allows each party to only verify a subset of transactions, it still has to broadcast all blocks

to all parties and requires every party to store the entire ledger; (6) Finally, Elastico can only tol-

erate up to a 1/4 fraction faulty parties even with a high failure probability. Elastico requires this

low resiliency bound to allow practical committee sizes.

2.2.3 OmniLedger

In a more recent work, Kokoris-Kogias et al. [42] propose OmniLedger, a sharding-based distributed

ledger protocol that attempts to ﬁx some of the issues of Elastico. Assuming a slowly-adaptive

adversary that can corrupt up to a 1/4 fraction of the nodes at the beginning of each epoch, the

protocol runs a global reconﬁguration protocol at every epoch (about once a day) to allow new

participants to join the protocol.

The protocol generates identities and assigns participants to committees using a slow iden-

tity blockchain protocol that assumes synchronous channels. A fresh randomness is generated in

each epoch using a bias-resistant random generation protocol that relies on a veriﬁable random

function (VRF) [51] for unpredictable leader election in a way similar to the lottery algorithm

of Algorand [50]. The consensus protocol assumes partially-synchronous channels to achieve fast

consensus using a variant of ByzCoin [41], where the epoch randomness is further used to divide a

committee into smaller groups. The ByzCoin’s design is known to have several security/performance

issues [56, 4], notably that it falls back to all-to-all communication in the Byzantine setting. Unfor-

tunately, due to incomplete (and changing) speciﬁcation of the new scheme, it is unclear how the

new scheme used in OmniLedger can address these issues.

Furthermore, there are several challenges that OmniLedger leaves unsolved: (1) Similar to Elas-

tico, OmniLedger can only tolerate t < n/4 corruptions. In fact, the protocol can only achieve low

latency (less than 10 seconds) when t < n/8; (2) OmniLedger’s consensus protocol requires O(n)

per-node communication as each committee has to gossip multiple messages to all n nodes for each

block of transaction; (3) OmniLedger requires a trusted setup to generate an initial unpredictable

conﬁguration to “seed” the VRF in the ﬁrst epoch. Trivial algorithms for generating such a common

seed require Ω(n

) bits of communication; (4) OmniLedger requires the user to participate actively

in cross-shard transactions which is often a strong assumption for typically light-weight users; (5)

Finally, OmniLedger seems vulnerable to denial-of-service (DoS) attacks by a malicious user who

can lock arbitrary transactions leveraging the atomic cross-shard protocol.

When t < n/4, OmniLedger can achieve a high throughput (i.e., more than 500 tx/sec) only when

an optimistic trust-but-verify approach is used to trade-oﬀ between throughput and transaction

conﬁrmation latency. In this approach, a set of optimistic validators process transactions quickly

providing provisional commitments that are later veriﬁed by a set of core validators. While such

an approach seems useful for special scenarios such as micropayments to quickly process low-stake

small transactions, it can be considered as a high-risk approach in regular payments, especially

due to the lack of ﬁnancial liability mechanisms in today’s decentralized systems. Nevertheless,

any blockchain protocol (including Bitcoin’s) has a transaction conﬁrmation latency that has to be

considered in practice to limit the transaction risk.

剩余37页未读，继续阅读

Brendan:D

粉丝: 0
资源: 3

RapidChain：全分片技术提升区块链性能与可扩展性

Blockchain

aws-java-sdk-autoscaling-1.11.277.jar

api-ms-win-shcore-scaling-l1-1-1.dll

字符间隔.----Tw: 设置单词间隔.----Tz: 设置水平缩放.----TL: 设置Leading.----Tf: 设置文本字体.----Tr: 设置Render(渲

'train': ( "{cmd_mpi:s} nnp-scaling 100 > nnp-scaling-stdout.log 2> nnp-scaling-stdout.err; " "{cmd_mpi:s} nnp-train > nnp-train-stdout.log 2> nnp-train-stdout.err"), 'predict': '{cmd_mpi:s} nnp-dataset 0 > nnp-dataset-stdout.log 2> nnp-dataset-stdout.err'

linux字体大小调节的终端命令

untiyt粒子系统里所有翻译

z-scaling用R语言的计算方式

scaler.fit_transform(train_data.reshape(-1,1)).flatten()

最新资源