{"content":{"title":"分片常见问题解答","body":"# 分片常见问题解答\r\n\r\n目前，所有区块链协议中每个节点都存储整个状态（账户余额、合约代码和存储等）并处理所有交易。这提供了大量的安全性，但极大地限制了可扩展性：一个区块链的交易处理能力不能超过单个节点的处理能力。这在很大程度上导致比特币的处理能力限制在约3-7笔交易每秒，以太坊则为7-15笔交易每秒。\r\n\r\n然而，这提出了一个问题：是否有方法创建一种新机制，只有一小部分节点来验证每笔交易？只要有足够多的节点验证每笔交易，以确保系统仍然具有高度安全性，但是验证者集的比例足够小，以便系统可以并行处理许多交易，我们是否可以将交易处理分配给较小的节点组，以大幅提高区块链的总吞吐量？\r\n\r\n**内容**\r\n\r\n  * [解决问题的那些显而易见但有缺陷的方法有哪些？](#what-are-some-trivial-but-flawed-ways-of-solving-the-problem)\r\n  * [这听起来像是存在某种可扩展性的三难困境，这种三难困境是什么？我们能打破它吗？](#this-sounds-like-theres-some-kind-of-scalability-trilemma-at-play-what-is-this-trilemma-and-can-we-break-through-it)\r\n  * [哪些适度简单但仅部分解决可扩展性问题的方法存在？](#what-are-some-moderately-simple-but-only-partial-ways-of-solving-the-scalability-problem)\r\n  * [那些不试图“分片”的方法呢？](#what-about-approaches-that-do-not-try-to-shard-anything)\r\n  * [Plasma、状态通道和其他二层技术如何与三难困境相适应？](#how-does-plasma-state-channels-and-other-layer-2-technologies-fit-into-the-trilemma)\r\n  * [状态大小、历史、加密经济学，哎呀！在深入探讨之前先定义这些术语吧！](#state-size-history-cryptoeconomics-oh-my-define-some-of-these-terms-before-we-move-further)\r\n  * [分片背后的基本思想是什么？](#what-is-the-basic-idea-behind-sharding)\r\n  * [分片区块链的基本设计可能是什么样子？](#what-might-a-basic-design-of-a-sharded-blockchain-look-like)\r\n  * [这里面有哪些挑战？](#what-are-the-challenges-here)\r\n  * [但是 CAP 定理不是意味着完全安全的分布式系统是不可能的，所以分片是徒劳的吗？](#but-doesnt-the-cap-theorem-mean-that-fully-secure-distributed-systems-are-impossible-and-so-sharding-is-futile)\r\n  * [我们操作的安全模型是什么？](#what-are-the-security-models-that-we-are-operating-under)\r\n  * [如何在无协调大多数模型中解决单片接管攻击？](#how-can-we-solve-the-single-shard-takeover-attack-in-an-uncoordinated-majority-model)\r\n  * [你究竟如何在工作量证明和权益证明中进行采样？](#how-do-you-actually-do-this-sampling-in-proof-of-work-and-in-proof-of-stake)\r\n  * [随机采样的随机性是如何产生的？](#how-is-the-randomness-for-random-sampling-generated)\r\n  * [提高或降低采样频率有什么权衡？](#what-are-the-tradeoffs-in-making-sampling-more-or-less-frequent)\r\n  * [我们可以迫使更多状态保留在用户端，以便交易可以在不要求验证者持有所有状态数据的情况下进行验证吗？](#can-we-force-more-of-the-state-to-be-held-user-side-so-that-transactions-can-be-validated-without-requiring-validators-to-hold-all-state-data)\r\n  * [我们可以将数据和执行分开，以便在不增加执行状态的节点轮换开销的情况下，从快速打乱数据验证中获得安全性吗？](#can-we-split-data-and-execution-so-that-we-get-the-security-from-rapid-shuffling-data-validation-without-the-overhead-of-shuffling-the-nodes-that-perform-state-execution)\r\n  * [SNARKs 和 STARKs 能否提供帮助？](#can-snarks-and-starks-help)\r\n  * [我们如何促进跨片间通信？](#how-can-we-facilitate-cross-shard-communication)\r\n  * [什么是列车和酒店问题？](#what-is-the-train-and-hotel-problem)\r\n  * [在贿赂攻击者或协调选择模型中，关于通过随机采样进行分片的担忧是什么？](#what-are-the-concerns-about-sharding-through-random-sampling-in-a-bribing-attacker-or-coordinated-choice-model)\r\n  * [我们如何改善这一点？](#how-can-we-improve-on-this)\r\n  * [数据可用性问题是什么，我们如何使用擦除代码来解决它？](#what-is-the-data-availability-problem-and-how-can-we-use-erasure-codes-to-solve-it)\r\n  * [我们能否于某种花哨的加密累加器方案中移除解决数据可用性的需要？](#can-we-remove-the-need-to-solve-data-availability-with-some-kind-of-fancy-cryptographic-accumulator-scheme)\r\n  * [所以这意味着我们实际上可以创建可扩展的分片区块链，其中任何不良事件发生的代价与整个验证者集的规模成正比？](#so-this-means-that-we-can-actually-create-scalable-sharded-blockchains-where-the-cost-of-making-anything-bad-happen-is-proportional-to-the-size-of-the-entire-validator-set)\r\n  * [让我们倒退一下。如果我们有瞬时洗牌，实际上需要这些复杂性吗？难道瞬时洗牌不意味着每个分片直接从全局验证者池中拉取验证者，因此就像一个区块链一道，分片实际上并未引入任何新的复杂性吗？](#lets-walk-back-a-bit-do-we-actually-need-any-of-this-complexity-if-we-have-instant-shuffling-doesnt-instant-shuffling-basically-mean-that-each-shard-directly-pulls-validators-from-the-global-validator-pool-so-it-operates-just-like-a-blockchain-and-so-sharding-doesnt-actually-introduce-any-new-complexities)\r\n  * [你提到的透明分片。 我12岁，这是什么？](#you-mentioned-transparent-sharding-im-12-years-old-and-what-is-this)\r\n  * [这有什么优缺点？](#what-are-some-advantages-and-disadvantages-of-this)\r\n  * [如何实现同步的跨片信息？](#how-would-synchronous-cross-shard-messages-work)\r\n  * [那么半异步消息呢？](#what-about-semi-asynchronous-messages)\r\n  * [什么是有保障的跨片调用？](#what-are-guaranteed-cross-shard-calls)\r\n  * [等一下，如果攻击者同时从每个分片向分片X发送跨片调用怎么办？将所有这些调用及时包括在内不是在数学上不可能吗？](#wait-but-what-if-an-attacker-sends-a-cross-shard-call-from-every-shard-into-shard-x-at-the-same-time-wouldnt-it-be-mathematically-impossible-to-include-all-of-these-calls-in-time)\r\n  * [凝固气体？这听起来对跨片操作以及可靠的片内调度都很有趣](#congealed-gas-this-sounds-interesting-for-not-just-cross-shard-operations-but-also-reliable-intra-shard-scheduling)\r\n  * [有保障的调度，片内和跨片，是否有助于对抗试图审查交易的多数合谋？](#does-guaranteed-scheduling-both-intra-shard-and-cross-shard-help-against-majority-collusions-trying-to-censor-transactions)\r\n  * [分片区块链能否更好地处理网络分区？](#could-sharded-blockchains-do-a-better-job-of-dealing-with-network-partitions)\r\n  * [推动可扩展性超过 n = O(c^2) 存在哪些独特挑战？](#what-are-the-unique-challenges-of-pushing-scaling-past-n--oc%5C%5E2)\r\n  * [那么异构分片呢？](#what-about-heterogeneous-sharding)\r\n  * [脚注](#footnotes)\r\n\r\n## 解决问题的那些显而易见但有缺陷的方法有哪些？\r\n\r\n“简单解决方案”主要分为三个类。第一种是放弃对单个区块链的扩展，而是假设应用程序将在许多不同的链间分割。这大大提高了吞吐量，但以安全为代价：使用这种方法实现的吞吐量增加了N倍，同时安全性下降了N倍，因为1/N大小的资源级别就足以攻击任何单个链。因此，对于N值超出小范围而言，这种方式无疑是不可行的。\r\n\r\n第二种方法是简单地增加区块大小限制。这种方法在某些情况下可能有效，且确实可能是正确的处方，因为区块大小可能更多地受限于政治因素而非现实的技术考虑。然而，无论对任何单一案例的看法如何，这种方法不可避免地会有其局限性：如果走得太远，那么运行在消费级硬件上的节点将退出，网络将开始完全依赖于仅有的一小部分运行区块链的超级计算机，这可能导致极大的中心化风险。\r\n\r\n第三种是“合并挖矿”，这种技术存在多个链，但所有链共享同样的算力（或在权益证明系统中的权益）。目前，Namecoin通过这种方式从比特币区块链获取了大量安全性。如果所有矿工都参与，理论上可以在不妥协安全性的情况下将吞吐量增加N倍。然而，这同样存在一个问题，即它使每个矿工的计算和存储负担增加了N倍，因此，实际上这种解决方案只不过是块大小增加的隐蔽形式。\r\n\r\n## 这听起来像是存在某种可扩展性的三难困境，这种三难困境是什么？我们能打破它吗？\r\n\r\n三难困境宣称，区块链系统最多只能同时具备以下三种特性中的两种：\r\n\r\n  * **去中心化**（定义为系统能够在每个参与者仅有O(c)资源（即常规笔记本电脑或小型VPS）的情况下运行）\r\n  * **可扩展性**（定义为能够处理O(n) > O(c)交易）\r\n  * **安全性**（定义为能抵抗资源高达O(n)的攻击者）\r\n\r\n在本文件的其余部分，我们将继续使用**c**作为每个节点可用计算资源的大小（包括计算、带宽和存储），使用**n**作为某种抽象意义上的生态系统规模；我们假设交易负载、状态大小和一种加密货币的市值都与**n**成正比。可扩展性的关键挑战在于找到一种方法以确保三者在基础层面上实现。\r\n\r\n## 哪些适度简单但仅部分解决可扩展性问题的方法存在？\r\n\r\n许多分片提案（例如[NUS的Loi Luu等人的早期BFT分片提案](https://www.comp.nus.edu.sg/~loiluu/papers/elastico.pdf)，以及[Zilliqa中类似理论的更多应用](https://docs.zilliqa.com/whitepaper.pdf)，还包括[此Merklix树](http://www.deadalnix.me/2016/11/06/using-merklix-tree-to-shard-block-validation)[1](#ftnt_ref1)为比特币提出的方案）试图仅对交易处理或仅对状态进行分片，而不干扰对方[2](#ftnt_ref2)。这些努力可能会导致某种效率的提升，但它们碰到的根本问题在于它们只解决了两者中的一个瓶颈。我们希望能够在不强制每个节点成为超级计算机或要求每个节点存储一个TB状态数据的情况下，处理10,000条以上的交易，这需要一种综合性解决方案，使状态存储、交易处理甚至在节点中下载和重新广播交易的负载都能在节点间分配。特别是，P2P网络还需要进行修改，以确保不是每个节点都从其他节点接收所有信息。\r\n\r\n## 那些不试图“分片”的方法呢？\r\n\r\n[Bitcoin-NG](http://hackingdistributed.com/2015/10/14/bitcoin-ng/)可以通过采用一种替代区块链设计 somewhat 地提高可扩展性，这样当节点花费大量CPU时间验证区块时，网络就会更安全。在简单的工作量证明（PoW）区块链中，如果容量增加到超过约5%的节点 CPU时间用于验证区块，则存在很高的中心化风险，达成共识的安全性会减弱；Bitcoin-NG的设计缓解了这个问题。然而，这只能以大约5-50倍的恒定因子提高交易的可扩展性[3](#ftnt_ref3),[4](#ftnt_ref4)，并未提高状态的可扩展性。值得注意的是，Bitcoin-NG类型的方法与分片并不相互排斥，这两者实际上可以同时实现。\r\n\r\n基于通道的策略（闪电网络、Raiden等）可以通过恒定因子提高交易容量，但不能提升状态存储，并且还是存在自己独特的一系列权衡和局限，特别涉及拒绝服务攻击。通过分片（加其它技术）进行链上扩展与通过通道进行链下扩展显然是必要且互补的。\r\n\r\n还存在一些使用先进加密技术的方法，例如[妙猫（Mimblewimble）](https://scalingbitcoin.org/papers/mimblewimble.txt)和基于ZK-SNARK的策略（如[Coda](https://codaprotocol.com/)），来解决可扩展性问题中的一个特定部分：初始完整节点同步。如果节点没有检验从创世开始的整个历史，节点可以验证当前状态的加密证明，确认其确实来自这个历史。这些方法确实解决了一个合法的问题，但它们并不能替代分片，因为它们并没有消除节点实时维持链上所需下载和验证大量数据的必要。\r\n\r\n## Plasma、状态通道和其他二层技术如何与三难困境相适应？\r\n\r\n在对[Plasma](https://www.plasma.io/)子链的大规模攻击中，所有Redis用户都需回撤至根链。如果Plasma有O(N)用户，则需要O(N)交易，因此需要O（N/C）来处理所有的回撤请求。如果回撤延迟固定为某个D（即简单实现），那么一旦N > C * D，则区块链中就没有足够的空间及时处理所有回撤，因此该系统将不安全；在这种模式下，Plasma只能被视为提高可扩展性（或许是相当大的常量因子）。如果回撤延迟是灵活的，因此在有许多回撤请求时会自动延长，那么随着N的持续增长，攻击者能迫使每个人的资金被锁定的时间延长，因此系统的“安全”水平在某种意义上进一步降低，因为延长的访问拒绝可以被视为安全的失败，不过这还不如完全丧失访问。尽管如此，这种权衡与其他解决方案有很大不同，且显然是相对温和的权衡。因此，Plasma子链无疑是对现状的一大改善。\r\n\r\n请注意，有一种设计是这样的：“假设有一个恶意操作者（最坏情况下），该系统会降级为链上的代币。恶意操作者不能窃取资金，也不能使人们在任何有意义的时间内丧失资金。”—https://ethresear.ch/t/roll-up-roll-back-snark-side-chain-17000-tps/3675。有关相关信息请参见[这里](https://twitter.com/PhABCD/status/1090090236380626944)。\r\n\r\n[状态通道](http://www.jeffcoleman.ca/state-channels/)具有类似的特性，但在通用性和最终性速度之间有不同的权衡。其他二层技术包括[TrueBit](https://people.cs.uchicago.edu/~teutsch/papers/truebit.pdf)通过链外交互验证执行和[Raiden](https://raiden.network/)，它是另一家从事状态通道工作的机构。[权益证明](https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ)与Casper（Layer1）也可以提升扩展性—它更加去中心化，不需要能够进行矿工的计算机，这导致中心化矿场和机构化矿池，随着难度和区块链状态的增大小而演变。\r\n\r\n分片不同于状态通道和Plasma，因为定期随机指定公证员对合并（类似区块，但在阶段1没有EVM状态转移功能）的有效性进行投票，然后在主链上确认这些合并，确认过程通过主链的分片管理合约进行。在阶段五（详细信息请参见[路线图](https://github.com/ethereum/wiki/wiki/Sharding-roadmap)），分片与主链紧密结合，因此如果任一个分片或主链无效，整个网络将无效。每种机制之间还有其他差异，但从高层次看，Plasma、状态通道和Truebit是无限期链外的，通过智能合约的主链第2层连接，并能够从主链中拉取，而分片则定期通过协议共识与主链关联。\r\n\r\n还请参见[Vlad的这些推文](https://twitter.com/VladZamfir/status/1001447804219346945)。\r\n\r\n## 状态大小、历史、加密经济学，哎呀！在深入探讨之前先定义这些术语吧！\r\n\r\n  * **状态**：表示系统“当前状态”的一组信息；在最简单的模型中，判断交易是否有效以及交易的影响应该仅依赖于状态。状态数据的例子包括比特币中的UTXO集，以太坊中的余额+非重复计数+代码+存储，以及Namecoin中的域名注册条目。\r\n  * **历史**：自创世以来发生的所有交易的有序列表。在简单模型中，当前状态应为创世状态和历史的确定性函数。\r\n  * **交易**：进入历史的对象。在实际操作中，交易表示某个用户想要进行的操作，并且它是经过加密签名的。在某些系统中，交易被称为**blob**，以强调在这些系统中这些对象可能包含任意数据，并且在并非所有情况下代表在协议中执行的操作尝试。\r\n  * **状态转移函数**：一个将状态作为输入、应用交易并输出新的状态的函数。涉及的计算可能包含从交易指定的账户中增加和减少余额、验证数字签名以及执行合约代码。\r\n  * **Merkle树**：一种加密哈希树结构，可以存储大量数据，验证每一项数据的真实性只需O(log(n))的空间和时间。有关详细信息，请参见[这里](https://easythereentropy.wordpress.com/2014/06/04/understanding-the-ethereum-trie)。在以太坊中，每个区块的交易集以及状态都存储在Merkle树中，树的根被承诺在区块中。\r\n  * **收据**：代表交易某个影响的对象，虽然并不直接存储在状态中，但仍存储在Merkle树中，并被承诺在区块头或状态的特殊位置，以便在后续能够有效证明其存在，即使一个节点并不给与全部数据。以太坊中的日志是收据；在分片模型中，收据用于促进异步跨片间通信。\r\n  * **轻客户端**：一种与区块链互动的方式，只需非常少的计算资源（我们称之为O(1)，虽然在某些情况下O(log(c))也可能准确），只需默认跟踪链的区块头，并通过按需请求和验证与相关数据的Merkle证明，获取任何与交易、状态或收据相关的信息。\r\n  * **状态根**：表示状态的Merkle树的根哈希[5](#ftnt_ref5)\r\n\r\n![](https://img.learnblockchain.cn/2025/02/21/image02.png)\r\n\r\n## 分片背后的基本思想是什么？\r\n\r\n我们将状态和历史分割为K = O(n / c) 个分区，称其为“分片”。例如，以太坊上的一种分片方案可能将所有以0x00开头的地址分到一个分片，将以0x01开头的地址分到另一个分片，依此类推。在分片的最简单形式中，每个分片也有自己的交易历史，某个分片k中的交易影响限制在分片k的状态上。一个简单的例子是一个多资产区块链，其中存在K个分片，每个分片存储与一个特定资产相关的余额并处理交易。在更复杂的分片形式中，还包含某种跨片通信能力，其中一个分片上的交易可以触发其他分片上的事件。\r\n\r\n## 分片区块链的基本设计可能是什么样子？\r\n\r\n一种简单的方法如下。为了简化，此设计仅跟踪数据blob；不尝试处理状态转移函数。\r\n\r\n存在一组**验证者**（即权益证明节点），随机获得创建**分片块**的权利。在每个**时隙**（例如8秒的时间段）中，对于每个`k`在`[0...999]`中，将随机选择一个验证者，并给出创建“分片`k`”上区块的权利，其中可能包含至多32KB的数据。此外，对于每个`k`，还会选择100个验证者作为**验证者**。区块的头和至少67个验证者的签名可以作为对象发布，包含在“主链”（也称为**信标链**）中。\r\n\r\n注意现在在这样的系统中可能存在几种“级别”的节点：\r\n\r\n  * **超级完整节点** - 下载信标链和每个在信标链中引用的分片块的完整数据。\r\n  * **顶级节点** - 仅处理信标链块，包括分片块的头和签名，但不下载所有分片块的数据。\r\n  * **单片节点** - 作为顶级节点工作，但还完整下载并验证其关心的特定分片上的每个合并。\r\n  * **轻节点** - 仅下载和验证主链块的区块头；除非需要读取某个特定分片状态的特定条目，在这种情况下它将下载该分片最新合并头的Merkle分支，并从那里下载所需值的Merkle证明。\r\n\r\n## 这里面有哪些挑战？\r\n\r\n  * **单片接管攻击** - 如果攻击者接管负责为某个特定区块进行验证的大多数验证者怎么办？是阻止任何合并获得足够的签名，还是提交无效的合并？\r\n  * **状态转移执行** - 单片接管攻击通常用随机采样方案来防止，但这样的方案也使得验证者更难计算状态根，因为他们不能获得最新的状态信息，用于所有可能被分配到的分片。我们该如何确保轻客户端仍然能够获得关于状态的准确信息？\r\n  * **欺诈检测** - 如果确实有无效的合并或状态声明被提出，节点（包括轻节点）该如何可靠地被告知以便能够发现欺诈并在其确实构成欺诈时拒绝该合并？\r\n  * **跨片通信** - 上述设计不支持任何跨片通信。我们该如何安全地添加跨片通信？\r\n  * **数据可用性问题** - 作为欺诈检测的一个子集，数据缺失的具体情况又该如何处理？\r\n  * **超二次分片** - 在特殊情况下当n > c²时，在上述简单设计中会有超过O(c)的合并头，一个普通节点甚至无法处理仅顶级块。因此，交易与顶级区块头之间需要更多的间接选择（即我们需要“次级分片”）。最简单和最佳的方法是什么？\r\n\r\n然而，交易的效果可能依赖于_在其他分片上早前发生的事件_；一个典型的例子是资金转移，其中可以通过首先创建一个“借方”交易，在分片i中销毁硬币，然后创建一个“贷方”交易，在分片j中生成硬币，将借方交易所创建的收据视为证明credit的合法性。\r\n\r\n## 但是CAP定理不是意味着完全安全的分布式系统是不可能的，所以分片是徒劳的吗？\r\n\r\nCAP定理是关于_分布式共识_的一个结果；简单来说：“在发生网络分区的情况下，你必须选择一致性或可用性，不能同时拥有两者。”直观的论点也很简单：如果网络一分为二，在一半我发送了交易“将我的10个币发送给A”，而在另一半我发送了交易“将我的10个币发送给B”，那么系统要么不可用，因为其中一个或两个交易无法处理，要么不一致，因为网络的一个半看到第一笔交易已完成，另一个半看到第二笔交易已完成。注意，CAP定理与可扩展性无关；它适用于节点需要就某个值达成一致的任何情况，而不考虑他们达成一致的数据量。所有现有的去中心化系统在可用性和一致性之间找到了某种妥协；在这方面，分片并没有让事情变得根本更加困难。\r\n\r\n## 我们操作的安全模型是什么？\r\n\r\n有几种竞争模型评估区块链设计的安全性：\r\n\r\n  * **诚实大多数**（或诚实超级多数）：我们假设有一组验证者及其中最多50%（或33%或25%）受攻击者控制，且剩余的验证者诚实地遵循协议。诚实大多数模型可以有**非自适应**或**自适应**对手；如果对手可以快速选择哪个部分验证者集“腐败”，则为自适应，如果对手只能提前很长时间做出这个选择，则为非自适应。注意，对于公证委员会，诚实大多数假设可能更高，有一个[61%的诚实假设](https://ethresear.ch/t/registrations-shard-count-and-shuffling/2129/7?u=jamesray1)。\r\n  * **无协调大多数**：我们假设所有验证者在博弈论意义上都是理性的（除了攻击者，攻击者是希望以某种方式使网络失败），但不超过某个比例（通常在25%到50%之间）能够协调他们的行动。\r\n  * **协调选择**：我们假设大多数或所有验证者被同一方控制，或者完全有能力就某种其间经济上最优的选择进行协调。我们可以谈论**联邦的成本**（或他们的赢利）来实现一些不良结果。\r\n  * **贿赂攻击者模型**：我们取无协调大多数模型，但将攻击者放在协议外，他们能通过贿赂改变参与者的行为。攻击者的模型有一个**预算**，这是他们愿意支付的最大金额，并且我们可以谈论他们的**成本**，他们_最终支付_来扰乱协议平衡的金额。\r\n\r\n比特币工作量证明通过[Eyal和Sirer的自私挖矿修正](https://arxiv.org/abs/1311.0243)在诚实大多数假设下稳健到50%，在无协调大多数假设下稳健到~23.21%。[Schellingcoin](https://blog.ethereum.org/2014/03/28/schellingcoin-a-minimal-trust-universal-data-feed/)在诚实大多数和无协调大多数假设下稳健到50%，在协调选择模型中有ε（即略多于零的）攻击成本，并且在贿赂攻击者模型中由于[P + epsilon攻击](https://blog.ethereum.org/2015/01/28/p-epsilon-attack/)而有P + ε预算需求和ε攻击成本。\r\n\r\n混合模型也存在；例如，即使在协调选择和贿赂攻击者模型中，通常会做一个**诚实少数假设**，即某一部分（或许是1-15%）的验证者将不论激励如何都以利他主义行事。我们还可以讨论由50%-99%验证者组成的联盟尝试破坏协议或伤害其他验证者；例如，在工作量证明中，51%的联盟可以通过拒绝包含所有其他矿工的区块来将其收益翻倍。\r\n\r\n诚实大多数模型可以说是高度不现实的，而且已经在实践中被证明不成立，例如比特币的[SPV挖矿分叉](https://www.reddit.com/r/Bitcoin/comments/3c305f/if_you_are_using_any_wallet_other_than_bitcoin/csrsrf9/)就是一个实践例子。它的推理过于严苛：例如，诚实大多数模型意味着诚实矿工愿意自愿燃烧他们自己的钱，如果这样做能以某种方式惩罚攻击者。无协调大多数假设可能是现实的；此外，还有一个中间模型，其中大多数节点是诚实的，但有预算，因此如果他们开始损失太多，就会关闭。\r\n\r\n贿赂攻击者模型在某些情况下被批评为过于对抗性，尽管其支持者争辩说，如果一个协议是在考虑贿赂攻击者模型时设计的，那么它应该能够大大降低共识的成本，因为51%的攻击成为一种可以恢复的事件。我们将在无协调大多数和贿赂攻击者模型的上下文中评估分片。贿赂攻击者模型类似于最大自适应对手模型，除了对手有额外的能力可以请求所有节点的私有信息；这一点尤其重要，例如[Algorand](https://people.csail.mit.edu/nickolai/papers/gilad-algorand.pdf)在自适应对手模型下是安全的，但在贿赂攻击者模型下不安全，因为它依赖私有信息进行随机选择。\r\n\r\n## 如何在无协调大多数模型中解决单片接管攻击？\r\n\r\n简而言之，随机采样。每个分片被分配一定数量的公证员（例如150），在每个分片上批准合并的公证员从该分片的样本中抽取。样本可以半频繁地（例如每12小时一次）或最大频繁地洗牌（即没有真正独立的随机采样过程，每个区块从全球池中随机选择公证员进行各分片）。\r\n\r\n采样可以是显式的，如选择特定大小的“委员会”并要求他们就某些合并的有效性和可用性进行投票，或是隐式的，如在“最长链”协议中节点被伪随机分配到构建特定合并，并期望“向回验证”其所在合并的N个祖先。\r\n\r\n结果是，即使在任何特定时间只有少数节点在每个分片上验证和创建块，安全程度在诚实或无协调大多数模型下其实并不比每个节点都参与验证和创建块要低。原因很简单：如果假设全球集合中有约67%的诚实超级多数，如果样本大小为150，则有 99.999%的概率满足诚实多数条件。如果假设全球集合中的诚实超级多数为75%，那么概率将增加到99.999999998%（有关计算细节，请参见[这里](https://en.wikipedia.org/wiki/Binomial_distribution)）。\r\n\r\n因此，至少在诚实/无协调大多数的设置下，我们可以得到：* **去中心化**（每个节点仅存储 O(c) 数据，因为它在 O(c) 分片中是轻客户端，因此存储 O(1) * O(c) = O(c) 数据块头，以及与其当前分配的一个或多个分片相关的 O(c) 数据，这些数据对应于最近的历史记录）\r\n  * **可扩展性**（有 O(c) 个分片，每个分片有 O(c) 的容量，最大容量为 n = O(c^2)）\r\n  * **安全性**（攻击者需要控制至少 ~33% 的 O(n) 大小的验证者池才能有机会接管网络）。\r\n\r\n在贿赂攻击者模型（或“非常非常自适应对手”模型）中，事情没有那么简单，但我们稍后会讨论这一点。请注意，由于抽样的不完美，安全阈值确实从 50% 降低到 ~30-40%，但对于可能实现 100-1000 倍的可扩展性且不失去去中心化，这仍然是一个令人惊讶的低安全损失。\r\n\r\n## 如何在工作量证明和权益证明中执行这个抽样？\r\n\r\n在权益证明中，这很简单。已经有一个“活动验证者集”，其状态被跟踪，可以直接从该集进行抽样。要么在协议内运行一个算法，为每个分片选择 150 个验证者，或者每个验证者独立运行一个算法，使用一个共同的随机源来（可证明地）确定他们在任何给定时间所在的分片。请注意，抽样分配是“强制性的”非常重要；验证者没有选择进入哪个分片的权利。如果验证者可以选择，那么少量总股份的攻击者可以将其股份集中在一个分片上并攻击它，从而消除系统的安全性。\r\n\r\n在工作量证明中，这就更困难了，因为在“直接”工作量证明方案中，无法阻止矿工将其工作成果应用于特定分片。可能可以使用 [文件访问证明](https://www.microsoft.com/en-us/research/publication/permacoin-repurposing-bitcoin-work-for-data-preservation/) 的形式将个别矿工锁定到单个分片上，但很难确保矿工不能快速下载或生成可以用于其他分片的数据，从而规避这样的机制。已知的最佳方法是通过 Dominic Williams 发明的一种称为“拼图塔”的技术，矿工首先在一个共同的链上执行工作量证明，然后将他们引入一个类似权益证明的验证者池，并且验证者池的采样就像在权益证明的情况下那样。\r\n\r\n一种可能的中间路线可能如下所示。矿工可以花费大量（O(c) 大小）的工作来创建一个新的“加密身份”。工作量证明解决方案的确切值决定了他们必须在哪个分片上创建下一个块。他们可以花费 O(1) 大小的工作来在该分片上创建一个块，然后该工作量证明解决方案的值决定了他们可以下一个工作在哪个分片上，依此类推[8](#ftnt_ref8)。请注意，这所有的方法在某种程度上都使得工作量证明“有状态”；这种需求是根本性的。\r\n\r\n## 随机抽样的随机性是如何生成的？\r\n\r\n首先，重要的是要注意，即使随机数生成高度易受利用，这对协议也不是致命的缺陷；相反，这仅意味着存在中等到高的中心化激励。原因在于，由于随机性选择相对较大的样本，很难将随机性偏向超过某种程度。\r\n\r\n展示这一点最简单的方法是通过上述 [二项分布](https://en.wikipedia.org/wiki/Binomial_distribution)；如果一个人希望避免一个大小为 N 的样本被攻击者腐蚀超过 50%，而攻击者拥有 p% 的全球股份池，则攻击者在一轮中能获得这种多数的概率为：\r\n\r\n![](https://img.learnblockchain.cn/2025/02/21/image00.gif)\r\n\r\n这是实际概率的表格，适用于不同的 N 和 p 值：\r\n\r\n< |  N = 50  |  N = 100  |  N = 150  |  N = 250   \r\n---|---|---|---|---  \r\np = 0.4  |  0.0978  |  0.0271  |  0.0082  |  0.0009   \r\np = 0.33  |  0.0108  |  0.0004  |  1.83 * 10-5  |  3.98 * 10-8   \r\np = 0.25  |  0.0001  |  6.63 * 10-8 |  4.11 * 10-11 |  1.81 * 10-17   \r\np = 0.2  |  2.09 * 10-6 |  2.14 * 10-11 |  2.50 * 10-16 |  3.96 * 10-26  \r\n  \r\n因此，对于 N >= 150，任何给定随机种子导致侧重于攻击者的样本的机会非常小[11](#ftnt_ref11),[12](#ftnt_ref12)。从随机性的安全性角度，这意味着攻击者需要在选择随机值时拥有非常大的自由度，以彻底破坏抽样过程。大多数在权益证明随机性上的脆弱性并不允许攻击者简单地选择种子；在最坏的情况下，它们给攻击者提供多个机会，从众多伪随机生成的选项中选择最有利的种子。如果对此非常担心，可以简单地将 N 设置为更大的值，并在生成随机性的时候加入一个适度困难的密钥导出功能，以便找到使随机性足够偏向的办法所需的计算步骤超过 2100。\r\n\r\n现在，让我们看看试图以边际方式影响随机性的攻击风险，以追求利润而不是完全接管。例如，假设存在一个算法，可以伪随机地从某个非常大的集合中选择 1000 个验证者（每个验证者获得 1 美元的奖励），攻击者有 10% 的股份，因此攻击者的平均“诚实”收入为 100，而攻击者以 1 美元的成本可以操纵随机性进行“重新掷骰”（而且攻击者可以做无限多次）。\r\n\r\n根据 [中心极限定理](https://en.wikipedia.org/wiki/Central_limit_theorem)，样本数量的标准差，以及基于数学中的其他已知结果，N 个随机样本的期望最大值稍低于 M + S * sqrt(2 * log(N))，其中 M 是平均值，S 是标准差。因此，操纵随机性并有效地重新掷骰（即增加 N）所获得的回报急剧下降，例如在没有重试时，你的期望回报是 100 美元，重试一次是 105.5 美元，两次是 108.5 美元，三次是 110.3 美元，四次是 111.6 美元，五次是 112.6 美元，六次是 113.5 美元。因此，在进行五次重试后，这不再值得。因此，一个拥有 10% 股份的经济动机攻击者将（社会上浪费地）花费 5 美元获取 13 美元的额外收入，净收益 8 美元。\r\n\r\n然而，这种逻辑假设了一轮重新掷骰是昂贵的。许多较旧的权益证明算法具有“股份磨损”脆弱性，其中重新掷骰仅意味着在自己的计算机上进行本地计算；具有此脆弱性的算法在分片上下文中肯定是不可接受的。较新的算法（见于 [权益证明 FAQ](https://github.com/ethereum/wiki/wiki/Proof-of-Stake-FAQ) 中的“验证者选择”部分）具有这种特性，重新掷骰只能通过自愿放弃自己的区块创建过程中的位置来进行，这意味着放弃奖励和费用。减轻边际经济动机攻击对样本选择影响的最佳方法是寻找提高此成本的方法。一种通过 N 轮投票将成本增加 sqrt(N) 的方法是 Iddo Bentov 提出的 [多数比特方法](https://arxiv.org/pdf/1406.5694.pdf).\r\n\r\n另一种不可被少数联盟利用的随机数生成形式是由 Dominic Williams 研究并倡导的确定性阈值签名方法。这里的策略是使用 [确定性阈值签名](https://eprint.iacr.org/2002/081.pdf) 来生成用于选择样本的随机种子。确定性阈值签名具有这样的特性，即哪怕参与者中的某些提供其数据，只要参与者中至少有 ⅔ 诚实参与，该值都保证是相同的。这种方法显然不能被经济利用，并且完全抵抗所有形式的股份磨损，但它有几个弱点：\r\n\r\n  * **它依赖于更复杂的加密技术**（特别是椭圆曲线和配对）。其他方法仅依赖于共同哈希算法的随机预言机假设。\r\n  * **当许多验证者离线时，它无法正常工作**。公共区块链的期望目标是能够在网络的大部分节点同时消失时幸存，只要其余多数节点是诚实的；确定性阈值签名模式在此时无法提供此属性。\r\n  * **在贿赂攻击者或协调多数模型中并不安全**，在此模型中超过 67% 的验证者处于共谋状态。上述证明的权益证明 FAQ 中描述的其他方法依然使得操纵随机性变得昂贵，因为来自所有验证者的数据被混合到种子中，进行任何操纵需要完全共谋或完全排除其他验证者。\r\n\r\n有人可能会争辩说，确定性阈值签名方法在一致性偏好背景下工作得更好，而其他方法在可用性偏好背景下工作得更好。\r\n\r\n## 增加或减少抽样频率有哪些权衡？\r\n\r\n选择频率影响对手如何适应协议而仍然能够安全抵御他们的能力；例如，如果你认为适应攻击（例如，不诚实的验证者发现自己属于同一抽样带而聚集在一起并勾结）可以在 6 小时内发生，但不会少于，那么你会认为 4 小时的抽样时间是可以接受的，但 12 小时则不可以。这是一个支持尽可能快速进行抽样的论点。\r\n\r\n抽样每个块一次的主要挑战在于重洗带来很高的开销。具体来说，验证一个分片的区块需要知道该分片的状态，因此每次验证者重新洗牌后，验证者都需要下载他们所在的新分片的整个状态。这需要一个强有力的状态大小控制政策（即经济上确保状态的大小不会过大，无论是通过删除旧帐户、限制创建新帐户的速率或两者结合）以及较长的重新洗牌时间才能良好运作。\r\n\r\n目前，Parity 客户端大约需要 2-8 小时通过“波动同步”下载并验证整个以太坊状态快照，这表明重洗周期几天而不短是安全的；也许通过 [存储租金](https://ethresear.ch/t/a-simple-and-principled-way-to-compute-rent-fees/1455) 压缩状态大小可以稍微缩短这个时间，但即便如此，重洗周期仍需要较长，这可能使系统对自适应对手易受攻击。\r\n\r\n然而，有一些方法可以完全避免这种权衡，在每个分片中仅用几分钟的警告选择下一个合成作者，但不增加难以高比例下载状态的开销。这是通过将状态存储的责任，甚至可能是状态执行的责任，完全转移出合成者，从而让用户或交互验证协议承担起这一角色。\r\n\r\n## 我们能否强制更多状态由用户端持有，以便对交易的验证不要求验证者持有所有状态数据？\r\n\r\n请参阅：https://ethresear.ch/t/the-stateless-client-concept/172\r\n\r\n这里的技术通常涉及要求用户存储状态数据，并在他们发送的每个交易中提供梅克尔证明。一笔交易将与一个正确执行的梅克尔证明（或“见证”）一起发送，这个证明将允许仅具有状态根的节点计算新的状态根。这个正确执行的证明将由需要遍历以访问和验证交易所需验证状态信息的 trie 子集构成；由于梅克尔证明的大小为 O(log(n))，对访问恒定数量对象的交易的证明也将为 O(log(n))。\r\n\r\n![](https://img.learnblockchain.cn/2025/02/21/image03.png)  \r\n\r\n以纯形式实现这个方案有两个缺陷。首先，它引入 O(log(n)) 的开销（实际情况是 ~10-30 倍），尽管有人可以争辩说，这个O(log(n)) 的开销并没有看起来那么糟糕，因为它确保验证者始终可以将状态数据保存在内存中，因此无需处理访问硬盘的开销[9](#ftnt_ref9)。其次，当交易所访问的地址是静态时，它可以轻松应用，但如果相关地址是动态的 - 也就是说，如果交易执行的代码为 `read(f(read(x)))`，其某种状态读取的地址依赖于其他状态读取的执行结果。在这种情况下，发送交易者认为他们在发送交易时交易将要读取的地址，可能与交易被纳入区块时实际读取的地址不同，因此梅克尔证明可能不足[10](#ftnt_ref10)。\r\n\r\n这可以通过访问列表来解决（考虑：账户列表和存储 trie 子集），指定静态指定交易可以访问哪些数据，因此当矿工接收到带有见证的交易时，他们可以确定该见证包含交易可能访问或修改的所有数据。然而，这会损害审查抗性，使得类似于 [尝试 DAO 软分叉](http://hackingdistributed.com/2016/07/05/eth-is-more-resilient-to-censorship/) 的攻击变得可能。\r\n\r\n## 我们能否将数据和执行分开，以便从快速洗牌的状态验证中获得安全性，又不会增加进行状态执行的节点洗牌的开销？\r\n\r\n可以。我们可以创建一个协议，将验证者分成三种不同激励角色（使得这些激励没有重叠）：**提议者或合成者，即生产者**，**公证人**和 **执行者**。生产者负责简单地构建成块链；而公证人验证合并数据的可用性。生产者不需要验证任何状态相关的内容（例如，某人尝试发送 ETH 是否有足够的资金）。执行者将公证者一致同意的合并链视为给定，然后按顺序执行合并中的交易并计算状态。如果合并中包含的任何交易无效，执行者将简单地跳过它。这样，验证可用性的验证者可以立即重新洗牌，而执行者可以保持在一个分片中。\r\n\r\n将有一个轻客户端协议，允许轻客户端基于执行者的签名证明来确定状态是什么，但此协议不是简单的多数投票共识。相反，该协议是一个类似于 Truebit 的交互式游戏，如果存在严重分歧，那么轻客户端会自己执行具体的合并或合并的部分。因此，即使在分片中 90% 的执行者被腐蚀，轻客户端仍然可以准确地查看状态，从而更加安全地允许执行者非常不频繁地重新洗牌，甚至永久特定于分片。\r\n\r\n选择_什么进入_合并确实需要知道该合并的状态，因为这是了解交易费实际支付方法的最实用方式，但这可以通过进一步分开合并者（同意历史）和提议者（提议单个合并）的角色来解决，并在这两种类型的参与者之间创建市场；更多的讨论请参见 [这里](https://ethresear.ch/t/separating-proposing-and-confirmation-of-collations/1000)。然而，这种方法之后被发现是有缺陷的，如 [此分析所述](https://ethresear.ch/t/exploring-the-proposer-collator-split/1632/)。\r\n\r\n## SNARKs 和 STARKs 可以提供帮助吗？\r\n\r\n可以！可以创建第二层协议，在其中使用 [SNARK](https://learnblockchain.cn/article/10960)、[STARK](https://learnblockchain.cn/article/10959) 或类似的简洁零知识证明方案来证明分片链的状态根，并可以因这一证明的创建者而获得奖励。但需要注意的是，分片链在首先同意哪些数据被纳入分片链上仍然是必要的。\r\n\r\n## 我们如何促进跨分片通信？\r\n\r\n最容易满足的情况是，有非常多个应用程序，单独来说并不具有太多用户，而且这些应用程序仅偶尔且松散地相互交互；在这种情况下，应用程序可以生活在不同的分片上，并通过收据进行跨分片通信。\r\n\r\n这通常涉及将每笔交易分解为“借记”和“贷记”。例如，假设我们有一笔交易，其中 M 分片上的账户 A 希望向 N 分片上的账户 B 发送 100 个硬币。步骤如下所示：\r\n\r\n  1. 在 M 分片上发送一笔交易，该交易（i）将 A 的余额减少 100 个硬币，（ii）创建一个收据。收据是一个对象，不直接保存在状态中，但可以通过梅克尔证明验证生成了此收据的事实。\r\n  2. 等待第一笔交易被纳入（有时需要等待最终确定；这取决于系统）。\r\n  3. 在 N 分片上发送一笔交易，其中包括 (1) 中收据的梅克尔证明。该交易还检查 N 分片的状态，以确保该收据是“未花费”；如果是，则将 B 的余额增加 100 个硬币，并在状态中保存已花费此收据信息。\r\n  4. 可选择，(3) 中的交易还保存一个收据，这可以进一步用于进行 M 分片中原始操作成功的附加操作。\r\n\r\n![](https://img.learnblockchain.cn/2025/02/21/image01.png)\r\n\r\n在更复杂的分片形式中，交易在某些情况下可能会产生跨多个分片的效果，并可能同步请求来自多个分片的状态的数据。\r\n\r\n## 什么是火车与酒店问题？\r\n\r\n以下示例出自 Andrew Miller。假设一个用户想要购买火车票和预订酒店，并希望确保操作是原子的——要么两个预订都成功，要么都失败。如果火车票和酒店预订应用在同一个分片上，这很简单：创建一个尝试同时进行两个预订的交易，并在除了两个预订都成功的情况下引发异常并回滚所有内容。但如果这两个操作在不同的分片中，这就不那么容易了；即使没有密码经济学/去中心化的顾虑，这基本上就是 [原子数据库事务](https://en.wikipedia.org/wiki/Atomicity_\\(database_systems\\)) 的难题。\r\n\r\n仅通过异步消息的最简单解决方案是首先预订火车，然后预订酒店，然后一旦两者都预订成功就确认这两个预订；预订机制将防止其他任何人再进行预订（或者至少将确保有足够的名额开放以允许所有预订确认）一段时间。然而，这意味着该机制依赖于额外的安全假设：即跨分片的消息可以在固定时间内被包含在其他分片。\r\n\r\n使用跨分片同步交易，问题变得容易，但创建能够执行跨分片原子同步交易的分片解决方案的挑战显然是复杂的；请参阅 Vlad Zamfir [讨论合并区块](https://www.youtube.com/watch?v=GNGbd_RbrzE)的演示。\r\n\r\n另一种解决方案是让合约本身可以在不同分片间移动；请参阅提议的 [跨分片锁定方案](https://ethresear.ch/t/cross-shard-locking-scheme-1/1269)，以及 [该提议](https://ethresear.ch/t/cross-shard-contract-yanking/1450)，其中合约可以从一个分片“转移”到另一个分片，使得通常位于不同分片中的两个合约可以暂时移动到同一分片，在此时可以在它们之间进行同步操作。\r\n\r\n## 关于通过随机抽样进行分片的贿赂攻击者或协调选择模型存在什么顾虑？\r\n\r\n在贿赂攻击者或协调选择模型中，验证者随机抽样并没有太大的意义：无论样本是什么，攻击者要么可以贿赂大多数样本以使其随意作为攻击者所愿，要么攻击者直接控制样本的大部分，并可以低成本（精确地说，O(c) 成本）指示样本执行任意操作。\r\n\r\n在这一点上，攻击者具备针对该样本进行 51% 攻击的能力。更严重的威胁是存在跨分片蔓延的风险：如果攻击者使得一个分片的状态受到腐蚀，攻击者可以开始将无尽的资金发送到其他分片并进行其他跨分片的恶作剧。总体而言，贿赂攻击者或协调选择模型的安全性并没有比简单产生 O(c) 小币种的安全性更好。\r\n\r\n## 我们如何改进呢？\r\n\r\n在状态执行的背景下，我们可以使用不依赖随机抽样多数投票的交互验证协议，即使90%的参与者存在缺陷仍然能够给出正确的结果；请参见 [Truebit](https://people.cs.uchicago.edu/~teutsch/papers/truebit.pdf) 以便了解这样如何做到。至于数据可用性，问题更复杂，尽管可以与多数投票结合使用几种策略来解决它。\r\n\r\n## 数据可用性问题是什么，我们如何使用纠删码来解决它？\r\n\r\n参见 https://github.com/ethereum/research/wiki/A-note-on-data-availability-and-erasure-coding\r\n\r\n## 我们能否通过某种花哨的密码累加器方案消除解决数据可用性的需求？\r\n\r\n不能。假设存在一种方案，其中存在一个对象 S 表示状态（S 可能是一个哈希值），也可能存在个别用户持有的辅助信息（“见证”），可以证明存在状态对象（例如，S 是梅克尔根，见证是分支，当然其它构建像 RSA 累加器也存在）。存在一种更新协议，某些数据被广播，并且这些数据会改变 S 以改变状态的内容，同时可能也会改变见证。\r\n\r\n假设某个用户拥有状态中的 N 个对象的见证，而 M 个对象被更新。在接收更新信息后，用户可以检查所有 N 个对象的新状态，从而查看其中 M 个对象被更新。因此，更新信息本身至少编码了 ~M * log(N) 位的信息。因此，每个人为了通过收到应用 M 笔交易的效果，所需的更新信息大小必须是 O(M) 的。[14](#ftnt_ref14)\r\n\r\n## 因此这意味着我们实际上可以创建可扩展的分片区块链，使得造成任何坏事发生的成本与整个验证者集的大小成正比？\r\n\r\n有一种微不足道的攻击，攻击者可以始终释放 O(c) 资本来暂时降低一个分片的质量：通过发送具有高交易费用的交易来对其进行垃圾邮件，迫使合法用户出价高于你以获取进入资格。这种攻击是不可避免的；你可以通过灵活的Gas限制来进行补偿，甚至可以尝试“透明分片”方案，尝试根据使用情况自动重新分配节点到分片，但如果某个特定应用程序是不可并行的，阿姆达尔法则保证你无能为力。打开的攻击（提醒一下：它仅在 Zamfir 模式下有效，不在诚实/非协调的多数中实现）可以说不比交易垃圾邮件攻击严重。因此，我们已达到了单个分片安全性的已知极限，没有必要再进行更多尝试。\r\n\r\n## 让我们回过头来。如果我们有瞬时洗牌，我们是否真的需要任何复杂性？难道瞬时洗牌基本上意味着每个分片直接从全球验证者池中拉取验证者，从而运作就像一个区块链，因此分片实际上没有引入额外的复杂性？\r\n\r\n有一点。首先，值得注意的是，在贿赂攻击者模型中，即使没有分片的工作量证明和简单的权益证明，安全性也都很低；一个区块在经济上直到 O(n) 时间后才算真正“最终确认”（因为如果只过了一些区块，那么替代链的经济成本只需源于在相关区块之前开始双重挫夺）。Casper 通过添加最终机制来解决这个问题，因此经济安全边际立即增加到最大限度。在分片链中，如果我们希望获得经济上的最终确认，那么我们需要提出一整套理由来解释一个验证者为何愿意基于一个随机样本向一条链做出强有力的声明，而该验证者自己则确信贿赂攻击者和协调选择模型可能是正确的，因此随机样本可能潜在的被腐蚀。\r\n\r\n## 你提到过透明分片。我12岁，这个是什么？\r\n\r\n基本上，我们不直接向开发者展示“分片”的概念，也不将状态对象永久分配到特定分片上。相反，协议具有一个持续内置的负载均衡过程，能够在分片间进行对象的移动。如果某个分片变得过大或消耗太多Gas，则可以将其对半分割；如果两个分片变得太小并且彼此交互频繁，则可以将其合并；如果所有分片都变得太小，则可以删除一个分片，并将其内容迁移到其他几个分片中，等等。\r\n\r\n想象一下，如果唐纳德·特朗普意识到人们在纽约与伦敦之间旅行的频率很高，但中间有一个海洋，他可以简单地拿出剪刀，剪掉海洋，把美国东海岸和西欧粘合在一起，然后把大西洋放到南极旁边——这就有点像那样。\r\n\r\n## 这种做法的优缺点是什么？\r\n\r\n  * 开发者不再需要考虑分片\r\n  * 分片可以手动调整以应对Gas价格的变化，而无需依赖市场机制以提高某些分片的Gas价格。\r\n  * 不再有可靠共同存在的概念：如果两个合约被放置在同一个分片中以便彼此交互，则分片变化可能会将它们分开。\r\n  * 更复杂的协议\r\n\r\n通过引入“顺序域”的概念，可以缓解共同存在的问题，在该概念下，合约可以指定它们位于同一顺序域中，这样在它们间的同步通信将始终是可能的。在这种模型下，分片可以被视为一起验证的一组顺序域，而顺序域可以在协议判断这合理的情况下在分片之间重新平衡。\r\n\r\n## 跨分片同步消息将如何工作？\r\n\r\n如果你将交易记录视为已经结算，并只是计算状态转换函数，那么这个过程将更为简易。酡有几种方法；一种相对简单的方法可以描述为：\r\n\r\n  * 一笔交易可以指定一个它能操作的分片集合。\r\n  * 为了使这笔交易有效，它必须在示出的所有分片中以相同的区块高度被包含。\r\n  * 在区块内，交易必须根据其哈希排序（这确保了执行的规范顺序）\r\n\r\n位于分片 X 的客户端如果看到一个交易包含分片 (X, Y)，需要从分片 Y 请求一个梅克尔证明以验证 (i) 该交易在 Y 分片中的存在，以及 (ii) 该交易将需要访问的数据在 y 分片的预先状态是什么。然后，它执行该交易并提交执行结果。请注意，如果每个区块中有多笔交易与许多不同的“区块配对”，这个过程可能极其低效；出于这个原因，可能更为最佳的是简单要求区块指定姐妹分片，计算也随后能以每区块的效率变得更加高效。这就是这种机制可能如何工作的一种基础；可以想象出更复杂的设计。然而，在新设计中，确保不出现低成本拒绝服务攻击，以影响状态计算的时间是非常重要的。\r\n\r\n## 半异步消息呢？\r\n\r\nVlad Zamfir 创建了一种方案，通过该方案，异步消息仍可解决“预订火车和酒店”问题。其原则如下。状态跟踪最近做出的所有操作，以及由任何给定操作触发的操作的图（包括跨分片操作）。如果某个操作被撤销，则会创建一个收据，该收据可以用于撤销其他分片的操作效果；这些撤销可能会触发自己的撤销，依此类推。这个观点是，如果某种机制的撤销消息传播能够比其他类型的消息速度快上一倍，那么在 K 轮内完成的复杂跨分片交易可以在另外 K 轮内部撤销。\r\n\r\n这个方案所引入的开销可能尚未受到充分研究；可能存在引发二次复杂执行脆弱性的最坏情况。很显然，如果交易之间的效果彼此分开越多，这种机制的开销就越小；或许可以通过优惠的Gas费用规则奖励这种孤立执行。总而言之，这是一项对先进分片而言最有前景的研究方向之一。\r\n\r\n## 什么是有保证跨分片调用？\r\n\r\n分片中的一大挑战是，当发出调用时，默认情况下并没有任何基于协议提供的保障，确保该调用创建的任何异步操作将在特定的时间框架内执行，甚至会被执行；相反，需依靠某个方在目标分片内发送交易来触发收据。这对于许多应用来说是可以的，但在某些情况下可能就会出现问题，原因如下：\r\n\r\n  * 可能不清楚哪一方被合理激励去触发特定的收据。如果发送交易使得众多参与者受益，则可能会出现 **公地悲剧** 效应，导致各方希望等到其他人发送交易（即玩“打鸡”游戏），或者根本决定发送交易对他们来说不值得酬金。\r\n  * **跨分片的Gas价格可能会波动**，在某些情况下，进行操作的第一部分使得用户“履行”该操作，但用户可能必须以明显更高的Gas价格进行后续操作。这可能由于拒绝服务攻击和其相关的 **骚扰** 等形式而加剧。\r\n  * 某些应用依赖于跨分片消息的“延迟”存在上限（例如火车与酒店的例子）。缺乏确保，某些应用不得不设定 **无效的宽裕** 安全边际。\r\n\r\n可以尝试提出一个系统，其中在某个分片中创建的异步消息将在其目标分片自动触发效应，而不管时间跨度是多少。但是，这需要每个分片上的所有客户端在计算状态转换函数时，主动检查所有其他分片，这合理地认为是一种低效源。已知的最佳折衷办法是：当在高度为 `height_a` 的 A 分片中产生的收据在高度为 `height_b` 的 B 分片中被包含时，如果两个区块高度之间的差异超过 `MAX_HEIGHT`，那么在区块的 A 分片中创建的区块从 `height_a + MAX_HEIGHT + 1` 到 `height_b - 1` 的所有验证者将被惩罚，而该惩罚将呈指数增加。这部分惩罚作为奖励颁发给最后纳入该区块的验证者。这保持状态转移函数的简单性，同时仍然强烈激励正确行为。\r\n\r\n## 等等，如果一名攻击者同时从每个分片向 X 分片发送跨分片调用，会不会因此而在数学上不可能同时将所有这些调用包含在内？\r\n\r\n确实；这是个问题。一种提议的解决方案是，为了实现从 A 分片到 B 分片的跨分片调用，调用方必须预先购买“凝结 B 分片的Gas”（这是通过在 B 区块中进行交易来完成，并在 B 中记录）。凝结 B 分片的Gas具有很高的贬损速度：一旦有序，它在每个区块内损失为 k 的剩余效力的 1/k。A 分片中的交易可以将凝结的 B 分片Gas与它创建的收据一起发送，且可以不收费地用于 B 分片。B 分块为这些交易的类型分配额外的Gas空间。请注意，由于贬损规则，对于给定分片，一次最多可以存在 GAS_LIMIT * k 的凝结Gas，在 k 个区块内肯定可以填充（事实上，由于贬损，加更快，但我们可能需要这重新工，因此假如不太适合则更丑陋）。如果太多的验证者恶意未能包含收据，我们可以通过豁免挤满其区块的收据空间的验证者来平衡惩罚，这样他们可以尽可能多地填满那些可能最古老的收据。\r\n\r\n在该预购买机制下，想要执行跨分片操作的用户将首先预先购买所有包含该操作的分片的Gas，超额购买以考虑到Gas贬损。如果该操作产生的收据触发的操作在 B 分片中消耗 100000 Gas，则用户应该预购 100000 * e（即 271818）的 B 分片凝结Gas。如果该操作又将在 C 分片中消耗 100000 Gas（例如，两级间接），则用户需要预购 100000 * e^2（即 738906）的 C 分片凝结Gas。注意一旦这些采购得到确认，并且用户启动主要操作，用户可以放心，除非验证者主动损失了大量的收据未纳入处罚，否则他们将不受价格波动影响。\r\n\r\n## 凝结的Gas？这听起来不仅对跨分片操作有趣，对可靠内分片调度也是如此\r\n\r\n确实；你可以在 A 分片中内部购买凝结的 A 分片Gas，并在 A 分片中发出严格的跨分片调用。然而，请注意该方案仅支持非常短时间间隔内的调度，并且调度不会精确到区块；它只是保证在某段时间内内发生。\r\n\r\n## 保证调度，无论是内分片还是跨分片，是否能帮助抵御试图审查信息的多数勾结交易？\r\n\r\n可以。如果用户无法进入交易，因为共谋验证者在过滤该交易且不接受任何包含它的区块，则该用户可以发送一系列触发链式协议的保证调度消息，最终消息则将在 EVM 内部重构交易及执行它。因此，阻止此类规避技术几乎是不可能的，除非完全关闭保证调度特性，并显著限制整个协议；因此，恶意验证者并不易做到这一点。\r\n\r\n## 经历网络分区的分片区块链能够更好地工作吗？\r\n\r\n本文档中描述的方案加上非分片区块链没有较好的改进；实际上，每个分片将最终将一些节点置于分割的两侧。有呼吁（例如来自 [IPFS 的 Juan Benet](https://www.youtube.com/watch?v=cU-n_m-snxQ)）致力于构建可扩展网络以实现网络拆分成分片并尽可能继续在网络分区条件下运行，但实现这一目标的密码经济存在不小的挑战。\r\n\r\n一个主要挑战是，如果我们想要基于位置的分片，以便地理网络分区最小化地影响分片内的凝聚力（作为副作用，具有非常低的内部分片延时并因此快速的区块时间），那么我们需要在验证者选择参与哪个分片处有办法。这是危险的，因为这允许在诚实/非协调的多数模型中，更大类的攻击增多，并且在 Zamfir 模式中，各类产生更低成本的攻击增多。基于地理分区安全的分片与通过随机抽样实现效率的分片是根本不同的。第二，关于应用程序如何组织还需要更多思考。上述所描述的分片区块链中的一个可能模型是每个“应用”位于一些分片上（至少对于小型应用）；然而，如果我们希望这些应用本身具有分区抗性，那就意味着所有应用在某种程度上都需要跨分片。\r\n\r\n解决此问题的一种可能方案是创建一个提供两种类型分片的平台——一些分片是更高安全性的“全球”分片，随机选取，而其他分片则是较低安全性的“本地”分片，可能具有超快的块时间和较低的交易费用。极低安全性的分片甚至可以用于数据发布和消息发送。\r\n\r\n## 将扩展推向 n = O(c^2) 的独特挑战是什么？\r\n\r\n有几个考虑因素。首先，算法需要从两层算法转换为可堆叠的 n 层算法；这虽然可行，但复杂。第二，n / c（即网络的总计算负荷与单个节点的容量之间的比率）这个值恰好接近两个常量：首先，如果用块来衡量，持续时间为几个小时，这是一个可以接受的“最高安全确认时间”，其次，奖励与存款之间的比例（早期计算表明的 Casper 存款规模为 32 ETH，区块奖励为 0.05 ETH）。这意味着如果奖励和惩罚在某个分片上严重强化，为了维持攻击，代价将是 O(n) 的规模。\r\n\r\n超过 c^2 可能会进一步削弱系统可以提供的安全性保证，并允许攻击者以中等成本在某些方式攻击单个分片，但仍然应该有可能防止无效状态被最终确定，防止最终确定的状态被撤销，除非攻击者愿意支付 O(n) 的成本。然而，收益是巨大的——一个超二次分片的区块链可以作为几乎所有去中心化应用的通用工具，并可以维持交易费用，使其使用几乎是免费的。\r\n\r\n## 异构分片呢？\r\n\r\n抽象执行引擎或允许多个执行引擎的存在，意味着每个分片可以有不同的执行引擎。由于 Casper CBC 可以探索完整的 [权衡三角形](https://github.com/ethereum/cbc-casper/wiki/FAQ#what-is-the-tradeoff-triangle)，因此可以将每个分片的共识引擎的参数更改为三角形的任何点。然而，CBC Casper 目前尚未实现，而异构分片在这个阶段只是一种想法；其工作原理的具体细节尚未设计或实施。一些分片可以优化以实现快速的最终性和高吞吐量，对于例如 EFTPOS 交易等应用非常重要，而大多数可能实现最终性、吞吐量和去中心化（验证节点数量）之间的适度或合理水平，高故障率的应用例如种子网络、以隐私为重点的电子邮件（例如 Proton mail）等，可能会优化高去中心化、低最终性和高吞吐量等。另见 https://twitter.com/VladZamfir/status/932320997021171712 和 https://ethresear.ch/t/heterogeneous-sharding/1979/2。\r\n\r\n## 脚注\r\n\r\n  1. Merklix tree == Merkle Patricia tree\r\n\r\n  2. NUS 组的后续提案确实管理了状态分片；它们通过我在本文后面的章节中描述的收据和状态压缩技术实现这一点。（这是 Vitalik Buterin 作为这个维基的创作者所写。）\r\n\r\n  3. 在这里谨慎的原因是。有理由特别注意，如果攻击者提出的最坏情况交易的处理时间与块空间开销（字节、气体等）之间的比率明显高于通常水平，那么系统会经历非常低的性能，因此需要有安全系数来应对这种可能性。在传统区块链中，块处理仅占区块时间的 ~1-5% 这一事实主要用于保护中心化风险，但同时也起到了保护拒绝服务风险的双重作用。在比特币的具体情况下，其当前已知的最坏情况[已知的二次执行漏洞](https://bitcoin.org/en/bitcoin-core/capacity-increases-faq#size-bump) 可以说现在将任何扩展限制在 ~5-10 倍，而在以太坊的情况下，虽然所有已知漏洞在拒绝服务攻击后正在或已经被移除，但在小规模上仍存在进一步不一致的风险。在 Bitcoin NG 中，之前的需求被移除，但后者的需求仍然存在。\r\n\r\n  4. 需要谨慎的进一步原因是，状态大小的增加对应于吞吐量的减少，因为节点会发现越来越难以在 RAM 中保持状态数据，因此需要越来越多的磁盘访问，通常具有 O(log(n)) 访问时间的数据库需要的访问时间会变得更长。这是以太坊上一次拒绝服务攻击中的一个重要教训，攻击通过创建空账户使状态膨胀了 ~10 GB，从而间接通过强迫进一步的状态访问转到磁盘而非 RAM 来减慢了处理速度。\r\n\r\n  5. 在分片区块链中，可能不必对单个全局状态进行同步达成共识，因此协议从未要求节点试图计算全局状态根；事实上，在后面的章节中提出的协议中，每个分片都有其自己的状态，对于每个分片都有一个机制，用于提交该分片的状态根，这表示该分片的状态。\r\n\r\n  6. #MEGA\r\n\r\n  7. 如果一个不可扩展的区块链升级为可扩展区块链，作者推荐的路径是旧链的状态应简单地成为新链中的一个分片。\r\n\r\n  8. 为了使这一点安全，必须满足一些额外条件；特别是，工作证明必须是不可外包的，以防止攻击者确定某个特定分片可用的_其他矿工身份_并对其进行挖矿。\r\n\r\n  9. 最近的以太坊拒绝服务攻击证明了硬盘访问是区块链可扩展性的主要瓶颈。\r\n\r\n  10. 你可能会问：那么为什么验证者不即时获取 Merkle 证明呢？答案是：因为这样做的往返时间约为 ~100-1000ms，而在此时间内执行整个复杂的交易可能是不可接受的。\r\n\r\n  11. 一个结合了小样本的正常效率和大样本更强健能力的混合解决方案是多层采样方案：在 50 个节点之间进行共识，需要 80% 的一致同意才能向前推进，只有在该共识未能达成时才回退到 250 节点的样本。N = 50，80% 阈值的失败率在对抗攻击者p = 0.4 时仅为 8.92 * 10-9，因此在诚实或未协调的大多数模型下，这不会影响安全性。\r\n\r\n  12. 给出的概率针对的是一个单独的分片；然而，随机种子影响 O(c) 的分片，攻击者可能潜在地控制它们中的任何一个。如果我们想要同时查看 O(c) 的分片，那么有两种情况。首先，如果打磨过程受到计算限制，那么这一事实根本不改变计算，因为尽管每轮现在有 O(c) 的成功机会，但检查成功仍花费 O(c) 的工作量。其次，如果打磨过程受到经济限制，那么这确实需要相对更高的安全系数（将 N 增加 10-20 应该足够），不过重要的是要注意，攻击者在以利润为导向的操控攻击中的目标是增加他们在所有分片中的参与，因此这也是我们已经在调查的情况。\r\n\r\n  13. 请参见 [Parity's Polkadotpaper](https://github.com/polkadot-io/polkadotpaper/raw/master/PolkaDotPaper.pdf) 以获取更多关于其“渔民”概念的描述。有关 Polkadot 的最新信息和代码，请参见 [这里](https://github.com/paritytech/polkadot)。\r\n\r\n  14. 感谢 Justin Drake 提及加密累加器，以及提供对线性批处理不可能性证明的[这篇论文](https://eprint.iacr.org/2009/612.pdf)。另见此主题： https://ethresear.ch/t/accumulators-scalability-of-utxo-blockchains-and-data-availability/176\r\n\r\n与分片以及更一般的可扩展性和研究相关的进一步阅读，可在[这里](https://github.com/ethereum/wiki/wiki/Sharding-introduction-R&D-compendium)和[这里](https://github.com/ethereum/wiki/wiki/R&D)获取。\r\n\r\n>- 原文链接： [vitalik.eth.limo/general...]()\r\n>- 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～"},"author":{"user":"https://learnblockchain.cn/people/71","address":null},"history":null,"timestamp":1740632047,"version":1}