Hacker Dōjo Workshop：
资助金额：120 USDT
Bounty链接：拆解坎昆升级 | Bounties | DoraHacks
创作者：北邮在读硕士 Syshems
本项目由Hacker Dōjo资助，文章转载请联系
Telegram: @DoraDojo0
WeChat: @HackerDojo0
E-mail: hackerdojo0@gmail.com
扩容背景：
- 单个区块的 Gas 有上限。以太坊是按照 Gas 费来规定一个区块的数据量上限的，一个区块最高可以承载 3000 万 GAS 的数据量
- 大区块的代价是牺牲了去中心化。以太坊不希望每个区块的数据量都太大，所以每个区块都有一个 Gas Target（目标 Gas）为 1500 万 Gas 的数据量
- Gas 自动化调节机制。一个区块的 Gas 消耗一旦超过了 Gas Target （也就是 1500 万 Gas），那么下一个区块的基础费用就会贵 12.5%，如果低于的话就会降低基础费用。这样可以在交易高峰时一直增加成本去缓解拥堵，同时在交易低迷时降低成本来吸引更多交易。
历史扩容方案（Layer2+Sharding）：
Layer2：
- Optimism Rollup：假设所有交易都是诚实可信的，把许多笔交易压缩成一笔交易提交给以太坊，在提交后会有一段时间窗口（挑战期-目前是一周），任何人都可以质疑发起挑战来验证交易的真实性，但用户如果要将 OP Rollup 上的 ETH 转到以太坊上则需要等待挑战期结束后才可以得到最终确认。
- ZK Rollup：只需要上传一个零知识证明和最终的状态变化的数据即可，意味着在可扩展性上可以比 OP Rollup 压缩更多的数据，并且也不需要像 OP Rollup 那样等待长达一周的挑战期。但技术上开发难度较大。
分片（Sharding）：
在讲解 Sharding 之前，我们先来回顾下 ETH 的出块过程。
合并后的以太坊从 PoW 转为 PoS ，12 秒出一个块（Slot），6.4 分钟出 32 个区块为一个周期（Epoch）。当矿工质押 32 个 ETH 成为验证节点（Validator）后，信标链就会通过随机算法来选择验证节点作为出块节点来打包区块，每一个区块都会随机选择一次出块节点。同时在每一个周期 Epoch 中，每个区块（Slot）会被分配所有节点数量的 32 分之 1 数量的验证节点组成的 “委员会（Committees）” 委员会需要对每个区块出块节点打包的区块进行验证投票。当出块节点打包区块后，超过三分之二以上的验证节点投票通过即可成功出块。
- Sharding 1.0（已废弃，跳过不影响）
Sharding 1.0，是对 Danksharding 出现之前的以太坊分片设计方案的统称，对此做些大概了解是有必要的。在初始的分片方案 Sharding1.0 的设计理念中，本质上是想实现**「状态分片」**。
状态分片 是区块链技术中的一种分片方式，它只存储部分状态，而不是完整的区块链状态。状态分片可以减少状态储存冗余，是最为理想化的分片方式，但是面临着跨分片通信、数据有效性和数据可用性等一系列挑战。状态分片是按照账户的地址进行分片的，一个特定的分片只会保留一部分状态，而不像是交易分片那样每个节点都保存整个网络中的所有状态。状态分片是区块链底层Layer1扩容方案之一，可以提高整个区块链系统的性能。
以太坊从原本的一条主链被设计为了最多 64 条分片链，通过增加多条新链的方式来实现扩容。在这个方案中，每条分片链负责处理以太坊的数据并交给信标链，信标链则负责整个以太坊的协调，每一条分片链的出块节点和委员会都是由信标链来随机分配，但存在的核心问题就是「****数据同步」****和「不断增长的 MEV 」。
Danksharding（今天的主角）
Danksharding 使用了一套新的分片思路去解决以太坊的扩容问题，即围绕着 Layer2 的 Rollup 进行扩容的分片方案，这套新的分片方案可以在不大量增加节点负担且保证去中心化和安全性的同时解决可扩展性问题，同时也解决了 MEV 带来的负面影响。
EIP-4844：
EIP-4844，也被称为 proto-danksharding 提案。它的主要目的是在不牺牲去中心化的情况下，降低以太坊 Layer2 费用100倍。Proto-danksharding 用于实现构成完整 Danksharding 规范的大部分逻辑和“脚手架”（例如交易格式 Blob Transcation 、验证规则等）
- 一个 Blob 的大小约为 128 KB（平均一个区块是 60~70kb 左右的数据大小）
- 一个交易可以最多携带两个 Blob（256KB）
- 每一个区块的 Target Blob 为 8 个（1MB），最大可承载 16 个 Blob（2MB）
- Blob 不需要像 callData 一样作为 history log 被永久存储（目前社区建议为 30 天）
Blob 给以太坊带来的额外存储空间是巨大的，要知道以太坊所有账本的总数据量大小从以太坊诞生至今也只有大约 1TB 左右，而 Blob 每年可以为以太坊带来 2.5TB~5TB 的额外数据量，是整个以太坊账本数据量的好几倍。
EIP-4844 引入的 Blob 交易可以说是为 Rollup 量身定制的，Rollup 的数据以 Blob 的形式上传至以太坊，额外的数据空间可以使 Rollup 实现更高的 TPS 和更低的成本，同时也将原本 Rollup 占据的区块空间释放给了更多用户。
EIP4844存在的问题：
**节点负担过大：**我们知道 EIP-4844 中只有 1~2MB 大小的 Blob 对节点增加的负担是完全可以接受的，但如果将 Blob 的数据量扩大 16 倍至 16~32MB 的话，不管是在数据同步还是数据存储上的负担都会使得节点的负担过大从而以太坊的去中心化程度降低。
**数据可用性问题：**如果节点不去下载全部的 Blob 数据，就会面临数据可用性问题，因为数据不在链上开放且随时可访问，比如以太坊节点对 Optimism Rollup 上的某笔交易存疑想发起挑战，但 Optimism Rollup 不交出这段数据，那么拿不到原始数据就无法证明这个交易是有问题的，所以要解决数据可用性问题就必须确保数据是随时开放且可访问。
Danksharding扩容方案
完善EIP4844（降低节点负担）& 解决MEV问题（出块者-打包者分离（PBS））
- 数据可用性采样（DAS）
数据可用性采样（DAS）的思想是将 Blob 中的数据切割成数据碎片，并且让节点由下载 Blob 数据转变为随机抽查 Blob 数据碎片，让 Blob 的数据碎片分散在以太坊的每个节点中，但是完整的 Blob 数据却保存在整个以太坊账本中，前提是节点需要足够多且去中心化。
举个例子：比如 Blob 的数据被切割成了 10 个碎片，全网有 100 个节点，每个节点都会随机抽查下载一个数据碎片并且将抽查的碎片编号提交到区块中，只要一个区块中可以凑齐所有编号的碎片，那么以太坊就会默认这个 Blob 的数据是可用的，只要将碎片拼凑起来就可以还原出原始数据。但也会有极低的概率出现 100 个节点都没有抽到某一个编号的碎片的情况，这样数据就会缺失，在一定程度上降低了安全性，但在概率上是可以接受的。
- 纠删码技术
简单来说就是纠删码利用数学原理将 Blob 数据切割成很多个数据碎片，以太坊的节点不需要收集所有的数据碎片，只需要收集 50% 以上的碎片就可以还原出 Blob 的原始数据，这样极大的降低了碎片收集不够的概率，其概率可以忽略不计。
- KZG 多项式承诺
KZG 多项式承诺（KZG Commitment）是一种密码学技术，用来解决纠删码的数据完整性问题。由于节点只抽查被纠删码进行切割后的数据碎片，节点并不知道这个数据碎片是不是真的来源于 Blob 的原始数据，所以负责编码的角色还需要生成一个 KZG 多项式承诺来证明这个纠删码的数据碎片确实是原始数据中的一部分，KZG 的作用有点类似于默克尔树但形状不同，KZG 所有的证明都在同一个多项式上。
- 出块者-打包者分离（PBS）解决打包数据和分发数据的分工问题
对于以太坊来说数据可用性采样（DAS）解决了实现 Blob 数据量 16MB~32MB 扩容的同时降低了节点的负担，但似乎还存在一个问题：谁来对原始数据进行编码？
如果要对 Blob 原始数据进行编码的话前提是进行编码的节点手里必须有完整的原始数据，要做到这一点的话就会对节点有较高的要求。那么菠菜之前提到，Danksharding 提出了一个新的机制**出块者-打包者分离（PBS）**去解决 MEV 带来的问题，那么其实这个方案在解决 MEV 问题的同时，其实也解决了编码的问题。
1、性能配置高的节点可以成为打包者（Builder），打包者只需要负责下载 Blob 数据进行编码并创建区块（Block），然后广播给其他的节点来进行抽查，对于打包者（Builder）来说，因为同步数据量和带宽要求较高，所以会相对中心化。
2、性能配置较低的节点可以成为提议者（Proposer），提议者只需要验证数据的有效性并创建和广播区块头（Block Header），但对于提议者（Proposer）来说，同步数据量和带宽要求较低，所以会去中心化。
- 抗审查清单（crList）限制解决出块者 MEV 的能力
但对于打包者（Builder）来说其实是拥有了更大的审查交易的能力，打包者可以故意忽略掉某些交易并且随意排序并插入自己想插入的交易去获取 MEV，但抗审查清单（crList）解决了这些问题。
抗审查清单（crList）的机制如下：
1、在打包者（Builder）打包区块交易之前，提议者（Proposer）会先公布一个抗审查清单（crList），这个 crList 中包含着 mempool 中的所有交易
2、打包者（Builder）只能选择打包并对 crList 里的交易进行排序，这意味着打包者不能插入自己的私有交易去获取 MEV，也不能去故意拒绝某个交易（除非 Gas limit 满了）
3、打包者（Builder）打包好之后将最终版本的交易列表 Hash 广播给提议者（Proposer），提议者选择其中一个交易列表生成区块头（Block Header）并广播
4、节点同步数据时会从提议者（Proposer）那获取区块头，然后从打包者（Builder）那获取区块 Body，确保区块 Body 是最终选择的版本
总结回顾
Danksharding 为以太坊解决 “区块链不可能三角” 提供了一种变革性的解决方案，即在确保以太坊去中心化和安全性的同时实现可扩展性：
- 通过前置方案 EIP-4844：Proto-Danksharding 引入了新的交易类型 Blob，Blob 携带的 1MB~2MB 额外数据量可以帮助以太坊在 Rollup 上实现更高的 TPS 和更低的成本
- 通过纠删码和 KZG 多项式承诺实现了数据可用性采样（DAS），让节点只需要抽查部分数据碎片即可验证数据的可用性并降低了节点的负担
- 通过实现了数据可用性采样（DAS），Blob 的额外数据量扩充至 16MB~32MB，让扩容效果更上一层楼
- 通过提议者-打包者分离（PBS）将验证-打包区块的工作分离为两个节点角色，实现了打包节点偏去中心化、验证节点去中心化
- 通过抗审查清单（crList）和双槽 PBS 极大降低了 MEV 带来的负面影响问题，打包者无法插入私有交易或审查某一笔交易
如果不出意外的话 Danksharding 的前置方案 EIP-4844 将会在以太坊上海升级之后的坎昆升级中正式落地，在 EIP-4844 方案落地实现后最直接的利好便是 Layer2 中的 Rollup 以及 Rollup 上的生态。更高的 TPS 和更低的成本十分适合链上的高频应用，我们不妨想象可能会诞生出一些 “杀手级应用”。
参考：以太坊新分片方案 Danksharding 及 EIP-4844 万字研报：全新公链叙事已来？白话解读「区块链不可能三角」的变革性解决方案 – Web3Caff Research