原文作者：ChuanLin
原文来源：A&TCapital
01、引子
Vitalik?于?2022?年?11?月?5?日发布了更新后的以太坊路线图，相比于之前?2021?年?12?月?2?日发布的路线图，其中即将到来的?TheSurge?阶段的更新无疑是最值得关注的。
如下图所示，这一阶段的更新明显添加了更多细节——我们可以明显看到，为了实现“基本的?Rollup?扩容”，以太坊社区提出了?EIP-4844?：Proto-Danksharding。这个提案将于?2023?年?5?月到?6?月初落地，届时?Rollup?的费用花费将降低?100?倍，这将非常大的优化以太坊L2的用户体验。如此大的优化，势必会成为Web3社区讨论和关注的焦点。
原来以太坊相关的问题在哪？EIP-4844?是用什么思路和方案解决这一问题的？本文就将帮助大家简明扼要的理解?EIP-4844?。
如果你希望跟上以太坊底层的架构更新，实时跟上社区的讨论，就请不要错过本文！
02、正文
一、EIP-4844?起源：数据可用性引起的L2费用瓶颈
1.1当前有关L2与L1数据交互的基本情况
当前以太坊L2大多以?Rollup?为基本的技术路线，Vitalik?更是将以太坊的更新用”ARollup-CentricRoadmap“描述，可见?Rollup?基本已经一统L2江湖。
而?Rollup?运行的基本原理，是将一捆交易在以太坊主链外执行，执行完后将执行结果和交易数据本身经过压缩后发回到L1上，以便其他人去验证交易结果的正确性。显然，如果其他人没有办法读取数据，那就无法完成验证。因此让其他人能够获取交易原始数据这一点非常重要，它也被称为“数据可用性”。
而受限于以太坊当前的架构，L2向L1的传输的数据，是储存在交易的?Calldata?里面的。然而，Calldata?在最初以太坊设计的时候只是一个智能合约函数调用的参数，是所有节点必须同步下载的数据。如果?Calldata?膨胀，将造成以太坊网络节点的高负载，因此?Calldata?的费用是比较昂贵的。这也是造成当前L2费用的主要因素。
1.2问题的改进思路
读者不妨思考一下，如果让你来针对这个问题设计优化方案，你会朝哪个方向去做改进？
其实我们可以观察到，L2的交易压缩数据的上传，只是为了让它能够被其他人所下载验证，并不需要被L1所执行。而?Calldata?费用之所以高，是因为它作为一个函数调用的参数，是默认可能被L1执行的，因此需要全网的节点进行同步。
这就造成了一种不匹配：打个比方，就像我明明只想把数据传个网盘，让有需要的其他人在一段时间内能够去下载；结果，你却把我的数据做了个我并不需要的全网广播同步，强制所有人必须在限定时间内完成下载，然后反过来因为这个服务向我收取高昂的费用。这明显是不合适、需要改进的。
那怎么改进呢？我们可以把L2传过来的数据单独设计一个数据类型，把它和L1的?Calldata?分开。这种数据类型只需要满足能在一定时间内被有需要的其他人所访问下载即可，无需做全网的同步。实际上，这点也被众多以太坊技术社区的成员所想到了。
EIP-4844?的改进，其实就是围绕着这个脉络进行的。
二、EIP-4844?的核心：带?Blob?的交易
如果用一句话来概括?EIP-4844?究竟做了什么，那就是：引入了”携带?blob?的交易“这一新的交易类型。Blob?就是上文提到的，为L2的数据传输所专门设计的数据类型。
因此，将有关?blob?的细节理解清楚，就可以说基本搞明白了?EIP-4844?。
2.1Blob?的本体：一个用于放置L2压缩数据的“大数据块“，存在共识层的节点中
Blob?这个名字，其实是?BinaryLargeObject?的简称，直译”二进制大数据块“。它被设计出来，就是为了承载L2的原始交易压缩数据，相当于之前L2的这些数据放到?Calldata，现在就放到?Blob?里面。相比于?Calldata，Blob?的数据大小可以非常大，高达?125?KB。
Blob?是由共识层的节点进行存储的，而不是像?Calldata?那样在会直接上主链，这也带来了?Blob?的两个核心特点：
不能像?Calldata?那样被?EVM?所读取
有生命周期，在?30?天之后将被删除
更细节一点的来说，Blob?本身，是一个由?4096?个元素所构成的向量。这个向量每个维度都是一个可以非常大的数字，取值范围在?0?到?52435875175126190479447740508185965837690552500527637822603658699938581184513?之间——这个非常大的数字是一个质数，它是和椭圆曲线密码学算法相关的。
而这个向量的每个维度的数字，可以把它看做是一个不高于?4096?阶的有限域多项式的各个系数，比如第?i?维的数字就是?w^i?前面的系数，其中?w?为常数且满足?w^?4096=1?。这个结构设计，是为了方便?KZG?多项式承诺的生成。
2.2与?Blob?相关的架构设计：Sidecar
在理解?Blob?架构之前，先需要说明一个概念：ExecutionPayload。在以太坊合并之后，分出了?ConsensysLayer?和?ExecutionLayer，它们分别负责两个主要功能:前者负责PoS共识，后者执行EVM。而?ExecutionPayload?可以简单认为是?EL?层里面普通的L1交易。
Blob?和现在以太坊架构的融合，可以类比为摩托车本体和摩托车挎斗之间的关系，就像这样：
Sidecar是一个官方比喻。它的含义，其实就是?Blob?的运转虽然依赖于主链，但某种程度上也平行于主链、具备相当的独立性。
如下图所示，接下来就让我们来过一遍?Blob?相关的执行流程，以更好的理解这一比喻：
首先，L2Sequencer?确定交易，将交易的结果和相关证明和数据包传到L1的交易池中
L1的节点看到了交易，它会在新的区块提议里面执行相关交易并进行广播；但在广播的时候，它会把?Blob?分离出来留在共识层?CL?中，并不会把它放到执行层的新区块里面
其它L1节点会收到了新的区块提议和交易结果。如果它们有需要成为L2验证者，它们可以去?BlobsSidecar?下载相关的数据。
下图是从另一个角度对?Blob?生命周期的阐述，我们可以清晰地看到?blob?数据不会上L1主链，只会存在共识层节点之中，并且它有着不一样的生命周期。
因此，这也不难理解为什么?Blob?无法被?EVM，也就是L1的智能合约所直接读取：能被读取的都是被传到执行层的东西，既然?Blob?仅仅留在共识层，那么肯定就没有这个功能了。而事实上，这种分离，也正是?Rollup?费用能因此降低的原因。
2.3Blob?的存储：新的?FeeMarket
前文提到，Blob?数据将存在共识层节点之中，并且具备生命周期。但显然这种服务也不是免费的，因此它将会带来一个独立于L1Gas?费的新费用市场，这也是?Vitalik?所倡导的?Multi-dimensionalFeeMarket。这个?FeeMarket?的相关细节还在迭代完善之中，详见?Github?的相关讨论与更新：https://github.com/ethereum/EIPs/pull/5707?
另外，如果节点层面只能短期存储这些数据，那么如何实现长期的储存呢？对此，Vitalik?表示解决方案其实很多。因为这里的安全假设要求不高，是”?1ofN?信任模型“，只需有人能够完成真实数据的存储即可。在大的存储硬件只需要?20?美元每?TB?的当下，每年?2.5?TB?的数据存储对于有心人而言只是小问题。另外，其它各种去中心化存储解决方案也会是一种选择，不过?Vitalik?在这里并没有提到具体的项目。
三、EIP-4844?的影响
在架构层面，EIP-4844?引入了新的交易类型Blob-carryingTransaction，这是以太坊第一次为L2单独构建数据层，也是之后?FullDanksharding?实现的第一步。
在经济模型层面，EIP-4844?将为?blob?引入新的?FeeMarket，这也会是以太坊迈向?Multi-dimensionalMarket?的第一步。
在用户体验层面，用户最直观的感知就是L2费用的大幅降低，这个底层的重要改进，将为L2以及其应用层的爆发提供重要基础。
四、EIP-4844?后的展望：FullyDanksharding
目前，EIP-4844?已经明确包含在以太坊上海升级系列之中，按照目前社区成员给出的时间表，预计将于明年?5?月至六月初完成。
而?EIP-4844?只是”Proto-Danksharding“，意为?Danksharding?的原型。完整版?Danksharing?的构想如下图所示，每个节点都可以直接通过数据可用性采样，实现对L2数据正确性的实时验证。这将会进一步提高L2的安全性和性能。
郑重声明： 本文版权归原作者所有， 转载文章仅为传播更多信息之目的， 如作者信息标记有误， 请第一时间联系我们修改或删除， 多谢。