在中短期、甚至长期来说，rollup 是以太坊唯一的去信任扩容解决方案。数月以来，L1 上的交易费变得如此高，以至于我们迫切需要做些什么来促进整个生态系统向 rollup 迁移。Rollup 已经为许多以太坊用户极大地降低了交易费: ?根据 L2 交易费监测网站 l2fees.info 显示，Optimism 和 Arbitrum 的交易费比以太坊基础层的交易费要低大约 3-8 倍；而 ZK-rollup 拥有更好的数据压缩并且不需要打包签名，费用与基础层相比要低 40-100 倍。
然而，即便有所扩容，这样的费用对于用户来说也还是太昂贵了。关于该问题早就已经写过文章，解决目前形式 rollup 不足的长期解决方案为添加数据分片，这将为 rollup 增加约 1-2 MB/秒的专用数据空间。本文档描述了对该方案的实用操作方法，从而尽快为 rollup 释放充足的数据空间，并逐渐增加额外的空间和提高安全性。
第一步：调整交易 calldata 以实现扩容
目前现有的 rollup 需要使用交易 calldata。因此，如果我们想在不需要 rollup 团队做任何额外工作的情况下，短期内提高 rollup 的吞吐量并降低成本，我们应该仅需要降低交易 calldata 的成本。目前区块的平均大小还远不足以大到威胁网络的稳定性，因此可以安全地完成这一操作，尽管可能需要一些额外的逻辑来防止一些极度危险的边缘情况。
请阅读：EIP 4488，或者另外一个 EIP (更简单但效果更温和) — EIP 4490。
理论上，EIP 4488 可以把 rollup 的数据可用空间最大增加到 ~1 MB/slot 并且成本降低大约 5 倍。这一步骤比下文提到的步骤可以更快地实施。
同时，我们可以开始开展一些工作以推出“专用”分片。以完整的形式实现专用分片可能需要很长时间，但我们可以做的是一片一片地实现，并从每一个分片中获益。要实现的首个自然分片是分片规范中的“业务逻辑”，但想要避免网络中的大部分困难，需要将初始分片数量维持在非常少的水平上 (例如 4 个分片)。每个分片将在自己的子网络中进行广播。验证者将默认信任委员会；但是如果他们愿意，他们也可以选择留在每个子网络中。并且只有当他们看到信标区块确认的任意分片区块的完整主体时，才会接受这个信标区块。
分片规范本身并不是特别困难；这是个和最近发布的 Altair 硬分叉规模差不多的样板代码更改 (Altair 信标更改规范文件有 728 行代码，而分片信标更改规范文件有 888 行代码)。所以我们有理由相信它可以在 Altair 实现和部署的时间框架内实现。
EOS创始人BM提议在EOS推出去中心化的自治机构DAC，用于创建代币和流动性:1月7日消息，EOS创始人BM（Daniel Larimer）发文提议使EOS成为DAC的DAC。据介绍，DAC为DAO的原语，即去中心化的自治机构（Company, Community, Country, Coop, Church, Corporation, Collective）。每个DAC都有一个或多个代币以及管理这些代币的治理流程。
BM提议更新eosio.token合约并部署新合约eosio.symbol，用于代币符号名称。将做市商构建到eosio.token合约中，可以让代币合约轻松地将其他代币的费用转换为 EOS。
BM表示，通过提议的更改，EOS将拥有一个原生的、社区管理的、去中心化的交易所，支持用户发行的代币，而无需部署任何合约，也无需编写任何代码。[2022/1/7 8:32:29]
为了使得分片数据能够真正被 rollup 使用，rollup 需要能够对分片数据进行证明。有两个选项：
1. 添加BEACONBLOCKROOT操作码；rollup 将添加这个代码以验证植根于信标链历史区块根中的默克尔证明。
2. 添加未来证明的状态和历史访问预编译 (future-proof state and history access precompiles)，这样的话，如果承诺机制 (commitment scheme) 在未来发生变化，rollup 就不需要更改其代码。
这将使 rollup 的数据空间增加到大约2 MB/slot(每个分片扩展 250 KB * 4 个分片，再加上第一步中已扩展的 calldata)
将活跃分片的数量从 4 个增加至 64 个。现在分片数据将进入子网络中，因此到这时，P2P 层必须已经足够坚韧，可以将分片分成数量更多的子网络。其中数据可用性的安全性将基于诚实的大多数，即依赖于委员会的安全性。
这将使得 rollup 的数据空间提高到大约 16 MB/slot (每个分片扩展 250 KB * 64 个分片)；我们假设此时 rollup 已经从执行链中迁移出来。
添加数据可用性采样，以确保提高安全水平，即使在遭遇大多数不诚实行为的攻击下，也能保护用户的资产。数据可用性采样可以分阶段推出：首先，以非强制的方式让网络进行测试；然后添加了 DAS 才能接受信标区块；甚至可能先在某些客户端上实现。
一旦完全引进了数据可用性采样，分片就完成发布了。
分片机制下的 Optimistic 和 ZK rollups
分片世界和目前状况的一个主要区别是，在分片世界中，一笔向智能合约提交 rollup 区块的交易中将不可能包含 rollup 数据。相反，数据发布步骤和 rollup 区块提交步骤将不得不分开：首先，在数据发布步骤中将数据发布至链 (发布到分片里)；然后在提交步骤中，提交其区块头以及基础数据的证明。
Optimism 和 Arbitrum 的 rollup 区块提交已经使用了上面所说的两步设计，所以这对它们来说只是一个小小的代码修改。
但对于 ZK-rollup 来说，事情就有点棘手了，因为提交交易需要提供一个可以直接在数据上运行的证明。它们可以做一个 ZK-SNARK 的证明，证明分片中的数据与信标链上的承诺相符，但这样很昂贵。幸好有更便宜的替代品。
如果 ZK-SNARK 是一个基于 BLS12-381 的 PLONK 证明，那么它们可以直接将分片数据承诺作为一个输入。BLS12-381 分片数据承诺是一个 KZG 承诺，与 PLONK 中的承诺类型相同，因此它可以直接作为一个公共输入传入证明中。
如果 ZK-SNARK 使用不同的方案 (甚至只是一个拥有更强的信任设置的 BLS12-381 PLONK)，它可以包含自己对于数据的承诺，并使用等价证明来验证证明中的承诺和信标链中的承诺是对相同数据的承诺。
增加数据空间的一个必要共同条件是，移除以太坊核心协议负责永久保有其达成共识的所有数据这个属性。数据量太大，根本不需要这样做。例如：EIP-4488 导致理论上链的最大容量为大约 1,262,861 字节/ slot (12秒)，或大约 3.0 TB 每年，尽管实际上，一开始更可能是大约 250—1000 GB 每年
4 个分片 ( 1 MB 每个 slot) 会每年增加额外 (几乎可以确定) 大约 2.5 TB 的数据
64 个分片 ( 16 MB 每个 slot) 导致每年总共需要 (几乎可以确定) 大约 40 TB 的存储
大多数用户的硬盘大小在 256 GB 到 2 TB 之间，1 TB 似乎是中位数。下图是一组区块链研究员的内部调查数据：
这意味着尽管用户今天可以负担得起运行一个节点，但如果这个路线图的任何部分没有进一步的修改，用户将会负担不起。大得多的驱动器是可以买到的，但用户将不得不特地去购买它们，这大大增加了运行一个节点的复杂性。这方面的主要解决方案是 EIP 4444 (译者注：可参阅《引介 EIP-4444：对执行层客户端的历史数据设限》)，它使得节点运行者不再负责存储超过 1 年的区块或收据。在分片方面，这个期限可能会进一步缩短，节点将只负责它们积极参与的子网上的分片。
这就留下一个问题：如果以太坊核心协议将不再存储这些数据，那么谁来存储？
首先，重要的是要记住即使有了分片，数据量也不会变得异常地大。是的，每年 40 TB 的数据量的确是个人运行“一般”消费级硬件难以负荷的。但是，对于愿意投入资源和工作到存储数据的个人来说，这是可以接受的。在 Best Buy 的一个 48 TB 硬盘售价 1729 美元，这里的 14 TB 硬盘售价大约 420 美元。运行一个 32 个 ETH 验证者 slot 的人可以用质押奖励来支付存储实现分片后的整个区块链的开销。因此，从账面上看，没有人会存储分片的历史数据以致完全没有人知道这些数据，这种情况似乎是不可能的。
那么谁将存储这些数据呢？以下是一些可能的想法：
自愿存储的个人和机构
区块浏览器 (etherchain.org、etherscan.io、amberdata.io…) 肯定会存储所有的数据，因为提供这些数据给用户是它们的商业模式。
Rollup DAO 对存储并提供与它们的 Rollup 相关的历史数据的参与者进行提名与支付。
历史数据可以通过 torrents 上传和共享
客户端可以自愿选择各自存储任意 0.05% 的链历史数据 (因为使用纠删码，你需要很多客户端同时离线才能丢失哪怕一个片段的数据)。
门户网络 (Portal Network) 里的客户端可以存储任意部分的链历史数据，门户网络会自动把数据请求导向拥有这些数据的节点。
历史数据的存储可以得到协议内的激励
像 TheGraph 这种协议可以创建有激励的市场，其中的客户端给提供历史数据 (有默克尔证明确保其正确性）的服务器付费。这就给运行存储历史数据的服务器的个人和机构提供激励，做到按需提供。
其中一些解决方案 (自愿的个人和机构、区块浏览器) 已经存在了。特别是 p2p torrent，是由大型自愿者驱动的生态来存储大量 TB 级内容的很好的例子。剩下的基于协议的解决方案更强大，因为它们提供激励，但它们需要更长的开发时间。从长远来看，通过这些第二层协议来访问历史数据会比今天通过以太坊协议更高效。
作者 | Vitalik Buterin
原文链接：https://notes.ethereum.org/@vbuterin/data_sharding_roadmap
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。