一洼田
每天学习一小节，整体认识进步一大截！
web3行业的发展始终绕不开的一个话题是关于公链的扩容。
因为这关系到公链作为行业底层基础设施支撑上层建筑开发的安全和性能，因此过去以太坊社区提出过多种扩容解决方案。
如：雷电网络、Matic/xdai为侧链的扩容、plasma技术以及最新的rollup技术。
2022 年 9 月 15 日，以太坊成功合并后便将其注意力转到后续的改进提案中：执行层上的上海升级、共识层上的 Capella 升级 。
主要有以下几点：
信标链提款
EOF
EIP-4844
其他 EIP
他们在以太坊中扮演着不同的角色。
信标链提款是上海升级的核心，而 EOF 只有在提款不会受到影响而延迟的情况下才会被纳入到上海升级中。
此外，由于 EIP-4844 可能会影响提款的推进时间，它已经被移出了上海升级的范围。
但是我们都知道 EIP-4844 是以太坊的一个重要改进提案，所以它将是下一次升级 (坎昆升级) 的重心。
以太坊的技术升级其中非常重要的一个技术方案是要实现EIP4844的提案。
实现EIP4844这个方案的分片技术Danksharding。
一旦升级完成将使以太坊的rollup方案的TPS实现质的飞跃。
今天我们将围绕什么是Danksharding 及Danksharding为什么利好L2来展开给大家分享。
Danksharding新技术方案实际上使用了一套新的分片思路去解决以太坊的扩容问题，即围绕着 Layer2 的 Rollup 进行扩容的分片方案。
这套新的分片方案可以在不大量增加节点负担且保证去中心化和安全性的同时解决可扩展性的问题，同时也解决 MEV（矿工最大提取价值）带来的负面影响。
我们可以从下图看到接下来的以太坊升级阶段”The Surge“和”The Scourge“的目标分别为：
在 Rollup 中实现 10 万+的 TPS 和避免 MEV 带来的中心化以及其他协议上的风险。
信息来源：https://www.ethereum.cn/Eth2/annotated-ethereum-roadmap
那么 Danksharding 到底是如何去解决以太坊的扩容问题的呢？
让我们先从 Danksharding 的前置方案 EIP-4844:Proto-Danksharding 开始讲起。
前置方案 EIP-4844:Proto-Danksharding—新的交易类型 Blob
EIP-4844 给以太坊引入了一种新的交易类型—Blob Transcation。
这种新的交易类型 Blob 可以为以太坊提供了一个额外的外挂数据库：
1.一个 Blob 的大小约为 128KB；
2.一个交易可以最多携带两个 Blob-即256KB；
3.每一个区块的 Target Blob 为 8 个-即1MB，最大可承载 16 个 Blob-2MB（Target 的概念在扩容背景中有提及）；
4.Blob 的数据是临时存储的，一段时间后会被清除（目前社区建议为 30 天）。
目前以太坊每个区块平均大小只有 85KB 左右。
Blob 给以太坊带来的额外存储空间是巨大的。
要知道以太坊所有账本的总数据量大小从以太坊诞生至今也只有大约 1TB 左右。
而 Blob 每年可以为以太坊带来 2.5TB~5TB 的额外数据量，是整个以太坊账本数据量的好几倍。
EIP-4844 引入的 Blob 交易可以说是为 Rollup 量身定制的。
Rollup 的数据以 Blob 的形式上传至以太坊，额外的数据空间可以使 Rollup 实现更高的 TPS 和更低的成本，同时也将原本 Rollup 占据的区块空间释放给了更多用户。
由于 Blob 的数据是临时存储的，数据量的暴增并不会对节点的存储性能造成越来越重的负担。
如果只是临时存储一个月的 Blob 数据量的话，从同步的数据量来看每一个区块节点需要多下载 1MB~2MB 的数据量，对于节点的带宽要求来说似乎不是什么负担。
那么从数据的存储量来看，对于节点来说只需要多下载并保存固定的 200~400GB 左右的数据量（一个月的数据量）。
在保证去中心化和安全性的同时只付出了增加一点点节点负担的代价的情况下，换来的 TPS 的提高和成本的降低则是以数十甚至上百倍来计算的。
这对于解决以太坊的可扩展性问题来说简直是绝佳的方案。
如果数据被清除了用户想访问以前的数据怎么办？
首先以太坊共识协议的目的不是为了保证所有历史数据的永远存储。相反，其目的是提供一个高度安全的实时公告板，并为其他去中心化协议留出长期存储空间。
而公告板的存在是为了确保在公告板上发布的数据有足够长的时间停留，任何想要这些数据的用户或者协议，都有足够的时间来抓取数据这些数据并进行保存。
所以保存这些 Blob 数据的职责就交给了其他角色比如 Layer2 的项目方、去中心化存储协议等。
Danksharding
进一步完整扩容方案
EIP-4844 实现了以太坊围绕 Rollup 进行扩容的第一步，但对于以太坊来说 EIP-4844 达到的扩容效果是远远不够的。
完整的 Danksharding 方案将 Blob 可以承载的数据量从每个区块 1~2MB 进一步扩充至 16MB~32MB，并且提出了新的机制出块者-打包者分离（PBS）去解决 MEV 带来的问题。
那么我们需要知道要在 EIP-4844 的基础上继续进行扩容会存在哪些难题：
①、节点负担过大。
我们知道 EIP-4844 中只有 1~2MB 大小的 Blob 对节点增加的负担是完全可以接受的。
但如果将 Blob 的数据量扩大 16 倍至 16~32MB 的话，不管是在数据同步还是数据存储上的负担都会使得节点的负担过大从而以太坊的去中心化程度降低。
②、数据可用性问题。
如果节点不去下载全部的 Blob 数据，就会面临数据可用性问题，因为数据不在链上开放且随时可访问。
比如以太坊节点对 Optimism Rollup 上的某笔交易存疑想发起挑战，但 Optimism Rollup 不交出这段数据，那么拿不到原始数据就无法证明这个交易是有问题的。
所以要解决数据可用性问题就必须确保数据是随时开放且可访问。
那么 Danksharding 是如何解决这些问题的呢？
答案是：数据可用性采样（Data Availability Sampling）
Danksharding 提出了一个方案—数据可用性采样（Data Availability Sampling）来实现降低节点负担的同时也保证了数据可用性。
数据可用性采样（DAS）的思想是将 Blob 中的数据切割成数据碎片，并且让节点由下载 Blob 数据转变为随机抽查 Blob 数据碎片，让 Blob 的数据碎片分散在以太坊的每个节点中。
但是完整的 Blob 数据却保存在整个以太坊账本中，前提是节点需要足够多且去中心化。
举个例子：
比如 Blob 的数据被切割成了 10 个碎片，全网有 100 个节点，每个节点都会随机抽查下载一个数据碎片并且将抽查的碎片编号提交到区块中。
只要一个区块中可以凑齐所有编号的碎片，那么以太坊就会默认这个 Blob 的数据是可用的，只要将碎片拼凑起来就可以还原出原始数据。
但也会有极低的概率出现 100 个节点都没有抽到某一个编号的碎片的情况，这样数据就会缺失，在一定程度上降低了安全性，但在概率上是可以接受的。
Danksharding 为了实现数据可用性采样（DAS）采用了两个技术：
纠删码（Erasure Coding）和 KZG 多项式承诺（KZG Commitment）
纠删码（Erasure Coding）
纠删码（Erasure Coding）是一种编码容错技术，使用纠删码切割数据可以使得所有以太坊节点在只拥有 50% 以上数据碎片的情况下就可以还原出原始数据，这样就大大减少了数据缺失的概率。
具体的实现原理会比较复杂，这里用一个数学公式来举例子大概解释一下原理：[2]
①
首先构造一个函数 f(x) = ax + b，随便取 4 个 x 值
②
设 m = f(0) = b、n = f(1) = a + b，可以得出 a = n – b、b = m
③
再设 p = f(2)、q = f(3)，可以得出 p = 2a + b = 2n – m, q = 3a + b = 3n – 2m
④
然后 m、n、p、q 四个碎片分散在全网的节点中
⑤
根据数学公式，我们只需要找到其中两个碎片就可以算出另外两个碎片是什么
⑥
如果找到 n 和 m，直接可以算出 q=3n-2m 和 p=2n-m
⑦
如果找到 q 和 p，可以将（2p=4n-2m）-（q=3n-2m）得出 2p-q=n 然后就可以直接算出 m 了
简单来说就是纠删码利用数学原理将 Blob 数据切割成很多个数据碎片，以太坊的节点不需要收集所有的数据碎片，只需要收集 50% 以上的碎片就可以还原出 Blob 的原始数据。
这样极大的降低了碎片收集不够的概率，其概率可以忽略不计。
KZG 多项式承诺
（KZG Commitment）
KZG 多项式承诺（KZG Commitment）是一种密码学技术，用来解决纠删码的数据完整性问题。
由于节点只抽查被纠删码进行切割后的数据碎片，节点并不知道这个数据碎片是不是真的来源于 Blob 的原始数据。
所以负责编码的角色还需要生成一个 KZG 多项式承诺来证明这个纠删码的数据碎片确实是原始数据中的一部分。
KZG 的作用有点类似于默克尔树但形状不同，KZG 所有的证明都在同一个多项式上。
Danksharding 通过纠删码和 KZG 多项式承诺实现了数据可用性采样（DAS）使得在 Blob 额外携带数据量扩充至 16MB~32MB 的情况下大幅的降低了节点的负担。
目前以太坊社区还提出了一种叫 2D KZG scheme 的方案去进一步切割数据碎片降低带宽和计算量的要求。
但最终具体使用的算法社区仍在热烈讨论中，包括 DAS 的设计上也在不断地优化完善。
对于以太坊来说数据可用性采样（DAS）解决了实现 Blob 数据量 16MB~32MB 扩容的同时降低了节点的负担，但似乎还存在一个问题：谁来对原始数据进行编码？
如果要对 Blob 原始数据进行编码的话前提是进行编码的节点手里必须有完整的原始数据，要做到这一点的话就会对节点有较高的要求。
那么Danksharding 提出了一个新的机制叫出块者-打包者分离（PBS）、然后去解决 MEV 带来的问题，那么其实这个方案在解决 MEV 问题的同时，其实也解决了编码的问题。
提议者-打包者分离
（Proposer/Builder Separation）
首先我们知道数据可用性采样（DAS）降低了节点验证 Blob 的负担，实现了低配置和去中心化的验证，但创建这个区块的话就需要去拥有完整的 Blob 数据并进行编码处理，这提高了许多对以太坊全节点的要求。
提议者-打包者分离（PBS）则提出将节点分为打包者（Builder）和提议者（Proposer）两个角色，性能高的节点可以成为打包者（Builder），而性能低的节点则成为提议者（Proposer）。
目前以太坊的节点分为两种：全节点和轻节点。全节点需要同步以太坊上所有的数据比如交易列表和区块 Body 等，全节点担任着区块打包和验证出块两个角色。
由于全节点可以看见区块内所有的信息，所以全节点可以对区块的交易进行重新顺序或添加删除来获取 MEV 价值。轻节点则不需要同步所有的数据，只需要同步区块头负责验证出块即可。
在实现提议者-打包者分离（PBS）之后：
性能配置高的节点可以成为打包者（Builder），打包者只需要负责下载 Blob 数据进行编码并创建区块（Block），然后广播给其他的节点来进行抽查。
对于打包者（Builder）来说，因为同步数据量和带宽要求较高，所以会相对中心化。
性能配置较低的节点可以成为提议者（Proposer），提议者只需要验证数据的有效性并创建和广播区块头（Block Header）。
但对于提议者（Proposer）来说，同步数据量和带宽要求较低，所以会去中心化。
PBS 通过将打包和验证的角色进行分离实现了节点的工作分工，让性能配置高的节点负责下载全部数据进行编码分发，让性能配置低的节点来负责抽查验证，那么 MEV 问题是如何解决的呢？
抗审查清单（crList）
由于 PBS 分离了打包和验证的工作，所以对于打包者（Builder）来说其实是拥有了更大的审查交易的能力。
打包者可以故意忽略掉某些交易并且随意排序并插入自己想插入的交易去获取 MEV，但抗审查清单（crList）解决了这些问题。
抗审查清单（crList）的机制：[1]
①
在打包者（Builder）打包区块交易之前，提议者（Proposer）会先公布一个抗审查清单（crList），这个 crList 中包含着 mempool 中的所有交易
②
打包者（Builder）只能选择打包并对 crList 里的交易进行排序，这意味着打包者不能插入自己的私有交易去获取 MEV，也不能去故意拒绝某个交易（除非 Gas limit 满了）
③
打包者（Builder）打包好之后将最终版本的交易列表 Hash 广播给提议者（Proposer），提议者选择其中一个交易列表生成区块头（Block Header）并广播
④
节点同步数据时会从提议者（Proposer）那获取区块头，然后从打包者（Builder）那获取区块 Body，确保区块 Body 是最终选择的版本
通过抗审查清单（crList）解决了像「三明治攻击」这种 MEV 带来的负面影响，节点无法再通过插入私有交易来获取类似的 MEV。
以太坊关于 PBS 具体的实现方案仍在探讨中，目前可能初步实现的方案为双槽 PBS。
双槽 PBS
Two-slot Proposer
-Builder Separation
双槽 PBS 采用竞标的模式来决定出块：[2]
①
打包者（Builder）拿到 crList 后创建交易列表的区块头并出价
②
提议者（Proposer）选择最终竞标成功的区块头和打包者（Builder），提议者无条件获得中标费（不管是否生成有效区块）
③
验证委员会（Committees）确认中标的区块头
④
打包者（Builder）披露中标的区块 Body
⑤
验证委员会（Committees）确认中标的区块 Body 并进行验证投票（通过则出块，如果打包者故意不给区块 Body 则视为区块不存在）
虽然打包者（Builder）仍然可以通过调整交易顺序来获取 MEV，但双槽 PBS 的竞标机制使得这些打包者之间开始 “内卷”。
在大家都要出价竞争出块的情况下，中心化的打包者们通过 MEV 获取的利润就会被不断挤压，最终的利润则会分配给去中心化的提议者（Proposer）们。
这解决了中心化的打包者通过获取 MEV 越来越中心化的问题。
但双槽 PBS 有一个设计缺陷：我们看这个设计的名字中有 “双槽（Two-slot）”，就是有两个插槽 slot。
这意味着在这个方案中进行一次有效的出块时间被延长至了 24 秒（一个 slot=12 秒），如何解决这个问题以太坊社区也一直在热烈讨论中。
总结
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 和更低的成本十分适合链上的高频应用，我们不妨想象可能会诞生出一些 二层的“杀手级应用”到时候伴随二层的发B。
Danksharding 实现的中心化出块+去中心化验证+抗审查将会给以太坊带来一轮全新的公链叙事。
今天的整个分享到这里就结束了，如果您对今天的分享有自己的观点，欢迎在留言区留言，我们共同讨论！
2023年，大家一起撸起袖子加油干，如果您是一个爱好学习的朋友，欢迎看到文章和语音的您加入到我们BNC社区VIP学习中来。
我们社群已经有1000多位的伙伴在持续不断的学习！在社区的不断推动下，相信会带量越来越多的投资者拿到不错的结果。我们共同加油！
好的，今天的分享就到这里，下一期节目再见！
注：本文的后半部分内容引用了推特号菠菜菠菜对于Danksharding 的详解，针对专业的词汇以及技术路线大家不懂得可以去访问以太坊的技术路线详解官网https://www.ethereum.cn/
