1. CoinON官网首页
  2. 新闻
  3. 头条

LXDAO：坎昆升级技术详解

Bob鲍师傅 • • 头条 • 阅读 130

以太坊完成了升级，引入了EIP-4844，也称为Proto-Danksharding，旨在提高基于以太坊rollup的可扩展性。升级将于2024年1月17日在测试环境开始，为以太坊的完整扩容方案Danksharding做好准备。升级包括引入新的blob交易和KZG证明系统，每个区块最多支持6个blob，未来可扩展到64个。升级后，以太坊将成为所有Layer2的DA层，履行安全守护者的角色，推动更多的DAPP在Layer2层开发。

摘要由 Mars AI 生成

本摘要由 Mars AI 模型生成，其生成内容的准确性、完整性还处于迭代更新阶段。

TL;DR

在以太坊完成上海升级后，以太坊已成功从 PoW 过渡到了 PoS 协议。以太坊路线图中的另一个大的升级是 EIP-4844，也被称之为 Ptoto-Danksharding，这次升级旨在提高基于以太坊 rollup 的可扩展性，将于 2024 年 1 月 17 日开始在测试环境升级。这次升级也为以太坊的完整扩容方案 Danksharding 做好了准备工作。本文将介绍坎昆升级的内容，并对其中关键升级 EIP-4844 进行深入分析，同时也分析了 EIP-4844 升级所带来的影响。

本文中代码使用 geth（执行层）和 prysm（共识层）的实现。

# 01坎昆升级简介

坎昆升级最近有了新的进展，确定会在 2024 升级，测试环境将在 1 月 17 日进行，主网升级预计会在 2024 年的 3-4 月。作为以太坊生态的下一个主要叙事，这次升级肯定会得到很大的关注。

坎昆（Cancun）是墨西哥的一个城市，也是 Devcon3 的举办地，作为以太坊升级的传统，这次执行层的升级代号就是 Cancun。这次升级还会涉及到共识层的升级，共识层的升级代号是 Deneb，完整的升级代号是这两个代号的结合：Dencun = Deneb + Cancun。

这次升级包含的内容很多，执行层和共识层分别需要实施的 EIP 如下：

  • 执行层
  • EIP-1153
  • EIP-4788
  • EIP-4844
  • EIP-5656
  • EIP-6780
  • EIP-7516

  • 共识层
  • EIP-4788
  • EIP-4844
  • EIP-7044
  • EIP-7045
  • EIP-7514

这次升级的主角就是 EIP-4844，其他的升级要么是为它服务，要么是一些小修小补。在本文中，我们重点来研究 EIP-4844 升级的细节，以及升级之后带来的影响。

EIP-4844 也被称之为 Proto-Danksharding，这个名字来源于 Protolambda 和 Dankrad Feist 两位研究员。以太坊最终的数据扩展方案是 Danksharding，EIP-4844 是 DankSharding 的前置升级。这次升级主要的目的是提升 rollup 层的可扩展性，并且为后续的 DankSharding 升级做好准备。

# 02

理解坎昆升级，你需要知道

2.1 数据可用性（DA）

在区块链中，不要信任，要验证是一个基本的原则。每个区块链节点都可以保存完整的数据，可以通过重新执行交易来确定所有数据的真实性，通过独立地验证这些数据，就不用管其他的节点是否在作恶。

数据可用性是指在验证区块是否正确时，所需要的数据能够公开可获取。对于当前的以太坊架构来说，这很容易做到，因为每个节点都可以保存所有的数据，缺少数据的区块会被丢弃，对于所有的节点来说，数据是可用的，这是区块链的一个特性，数据可用性是区块链的安全保障。

对于 Layer2 rollup，能证明区块合法有效的数据都会上传到以太坊，它们的数据可用性需要依靠以太坊来保证。

这样就带来了两个问题：

  • 所有的 Layer2 都向以太坊提交数据，会让 gas fee 持续保持在高位
  • 以太坊本身的存储能力有限，制约了 Layer2 的发展

以太坊需要一种不牺牲数据可用性，同时又能让 Layer2 向以太坊用更低的成本提交更多交易的方案，让 Layer2 的潜力发挥出来。

EIP-4844 是这个方案的前半部分，通过增加一种新的 blob 交易，blob 交易中的数据存储成本更低，Layer2 可以将交易打包，通过 blob 交易提交到以太坊，从而增加并发、降低成本。但 EIP-4844 带来的提升是有限的，因为 blob 数据依然会传播到所有的节点，会给节点带来很大的存储和网络成本，所以这次升级中，每个区块只能支持 6 个 blob。

以太坊

Dankshrding 是这个方案的后半部分，在完成 DankSharding 之后，每个区块链支持的 blob 可能会到 64 个，这样 Layer2 基本就没有什么限制了。但在这个升级之后，大多以太坊节点就不可能独立的存储这些数据了，大多数人承担不了网络和存储成本。如果节点不能完整的存储数据，那么数据 DA 要怎么来保证呢？

以太坊

检查数据可用性的方式有很多种，但 DAS（Data availability sampling）是最去中心化的一种，DankSharding 中使用的也是这种。通过 DAS，完整的数据不用在节点之间传播，只需要随机检查部分数据的 KZG 证明就可以保证数据的可用性。

基于同样的原因，只有区块链的 Builder 需要获取所有的数据，创建好区块之后，其他的 Proposer 不用下载全部的数据，只需要通过 DAS 来验证区块是否有效，这个功能升级就是 PBS（Proposer-builder separation）。除了提高数据的处理效率，其他的 Proposer 也看不到交易的内容，这在一定程度还增加了抗审查能力。

2.2 KZG

KZG（Kate Zaverucha Goldberg）是一种零知识证明系统，EIP-4844 中引入了 KZG，作为 blob 验证和证明生成的一部分。每一个 blob 都会生成一个对应的 KZG commitment，为后续的 DankSharding 升级做准备。

在 EIP-4844 升级后，blob 数据还是会在各个节点之间传播。但是在完全的 DankSharding 升级之后，blob 的数据量大量增加，节点之间不能再全量地同步 blob 数据。节点之间会通过 KZG 和 DAS 来检查数据的 DA，这是 DankSharding 实现的基础。

# 03

Blast 与 L2

EIP-4844 升级中已经完成的工作：

  • 实现 blob 交易以及 blob 数据的 KZG 处理
  • 实现执行层&共识层逻辑，以及执行层和共识层交互接口的修改
  • blob 交易自动调整 gas 的机制

在完全实施 DankSharding 之前，还需要完成的工作：

  • DAS 实施
  • PBS 实施

EIP-4844 完成了后续 DankSharding 升级中的大部分基础工作。剩下的升级，只需要通过升级共识层来完成，不需要执行层和 rollup 的参与，用户和开发者对后续的升级无感。

3.1 blob 交易详解

在 blob 交易出现之前，Layer2 的交易数据通过 calldata 来存储，calldata 是合约调用中传入的函数参数，是只读的，并且会被永久存储到链上，blob 交易中的数据存储在额外的空间中，并且在一段时间后被删除。

blob 存储和 calldata 的区别：

以太坊

EIP- 4844 在执行层增加了 blob 的交易类型：

const ( LegacyTxType = 0x00 AccessListTxType = 0x01 DynamicFeeTxType = 0x02 BlobTxType = 0x03 // 新增的 blob 交易)

blob 的交易结构如下:

//geth core/types/tx_blob.go type BlobTx struct { //…

BlobHashes [][]byte // 相比于 EIP-1559 的交易，多了一个 Sidecar 参数 Sidecar *BlobTxSidecar `rlp:”-“`

//…}

// Sidecar 结构type BlobTxSidecar struct { Blobs []kzg4844.Blob // Blobs needed by the blob pool Commitments []kzg4844.Commitment // Commitments needed by the blob pool Proofs []kzg4844.Proof // Proofs needed by the blob pool}

// 每个 blob 原始数据最大 128 kbtype Blob [131072]byte

// 生成的 KZG commitment，占 48 字节type Commitment [48]byte

type Proof [48]byte

相比于 EIP-1559 交易，多了一个 Sidecar 参数，其中存放的就是就是 blob 数据，这些 blob 不会被打包进入执行层的区块。其中每个 blob sidecar 包含三部分数据，包括 blob 的原始数据和经过 KZG 处理之后的数据，BlobHashes 中存储 Sidesar 中 Commitments 的 hash 值。

blob 交易中，blob 数据存储部分的价格是单独计算的，而且会随之前区块 blob 的使用情况而变动，如果上一个区块中 blob 的使用超过了 blob 最大限制的 50%，那么费用就会上调，如果低于 50%，那么费用就会降低：

//geth core/types/transaction.go func CalcBlobFee(excessBlobGas uint64) *big.Int { return fakeExponential(minBlobGasPrice, new(big.Int).SetUint64(excessBlobGas), blobGaspriceUpdateFraction)}

// fakeExponential approximates factor * e ** (numerator / denominator) using// Taylor expansion.func fakeExponential(factor, numerator, denominator *big.Int) *big.Int { var ( output = new(big.Int) accum = new(big.Int).Mul(factor, denominator) ) for i := 1; accum.Sign() > 0; i++ { output.Add(output, accum)

accum.Mul(accum, numerator) accum.Div(accum, denominator) accum.Div(accum, big.NewInt(int64(i))) } return output.Div(output, denominator)}

计算一笔交易中 blob gas 的最大限制：

//geth core/types/transaction.gofunc (tx *BlobTx) blobGas() uint64 { return params.BlobTxBlobGasPerBlob * uint64(len(tx.BlobHashes)) }

计算最终交易的花费：

//geth core/types/transaction.gofunc (tx *Transaction) Cost() *big.Int { total := new(big.Int).Mul(tx.GasPrice(), new(big.Int).SetUint64(tx.Gas())) if tx.Type() == BlobTxType { total.Add(total, new(big.Int).Mul(tx.BlobGasFeeCap(), new(big.Int).SetUint64(tx.BlobGas()))) } total.Add(total, tx.Value()) return total}

最终一笔 blob 交易的开销由三部分组成：交易 gas fee + 发送的 value + blob fee。

在 EIP-4844 的升级中，每个区块中携带的 blob 数量不超过 6 个。后续完成 DankSharding 升级之后，每个区块上 blob 的数量可以扩展到 64 个。

执行层并不会存储这些 blob 数据，会在构建区块的时候，通过 API 将 Blob 数据传输到共识层：

// geth beacon/engine/types.gotype ExecutionPayloadEnvelope struct { ExecutionPayload *ExecutableData `json:”executionPayload” gencodec:”required”` BlockValue *big.Int `json:”blockValue” gencodec:”required”` BlobsBundle *BlobsBundleV1 `json:”blobsBundle”` Override bool `json:”shouldOverrideBuilder”`}

type BlobsBundleV1 struct { Commitments []hexutil.Bytes `json:”commitments”` Proofs []hexutil.Bytes `json:”proofs”` Blobs []hexutil.Bytes `json:”blobs”`}

共识层收到这些交易之后，会将 blob 的 KZG commitment 打包到链上，而将 blob 原始数据分开存储：

// prysm type BeaconBlockBody struct { //… blobKzgCommitments [][]byte // blob 的 Kzg 数据}

共识层会负责验证 Blob 数据的可用性，验证的逻辑都被封装在 isDataAvailable 方法中。目前的实现是先验证本地数据库中是否可以找到完整的 blob 数据，如果找不到，那就通过特定的渠道去获取，直到获取成功或者报错。后续 Danksharding 升级完成后，那么通过也会通过这个方法来实现 DAS 验证，减少对其他模块的影响。

// prysm/beacon-chain/blockchainfunc (s *Service) isDataAvailable(ctx context.Context, root [32]byte, signed interfaces.ReadOnlySignedBeaconBlock) error { //…}

在 EIP-4844 的升级后，blob 数据还是会通过 gossip 协议广播到所有的节点，在完全升级到 Danksharding 之后，会通过 DAS 来验证数据的完整性，而不用下载完整的数据。

总结一下，新增的 blob 交易允许用户将一些数据放到 blob 中，blob 数据不会在执行层存储， EVM 也无法读取到这些数据，这些数据会被直接放到共识层存储，然后广播给其他的共识层节点。

3.2 blob 如何影响 gas fee

理论上来说，EIP-4844 升级肯定会降低 Layer2 的 gas fee。因为 blob 的存储费用会比 calldata 更低，而且一个 blob 中可以容纳更多的交易，但实际的情况却会更复杂。

EIP-4844 升级中，每个区块的中最多可以挂 6 个 blob。但 blob 的费用是动态调整的，如果前一个区块中的 blob 数量超过了最大值的 50%，也就是 3 个，那么当前这个区块的 blob fee 就会上涨 12.5%，如果低于 50%，这个区块的 blob fee 就会下降 12.5%，所以最后每个区块中的 blob 数量会维持在最大容量的 50% 左右。

对于 Layer2 来说，理论上 gas fee 会降低到十分之一甚至更低，但是如果链上交易繁忙，多个 rollup 同时向以太坊提交数据，那么 blob fee 也会暴涨，很难准确地估计升级之后的 gas fee，这样取决于当时的网络情况。只有等到 DankSharding 完全升级，每个以太坊区块可以支持到 64 个 blob 时才能解决。

另外，一个 blob 的大小是 128kb，大小不能改变，对于交易的提交方来说，即使没有这么多数据，也需要付出一个完整 blob 的成本。如果一个 Layer2 上的交易量没有这么大，有可能使用 calldata 的成本会更低。当然也有可能多个交易量不大的 Layer2 会将数据合并后再使用 blob 交易提交。

EIP-4844 升级肯定会降低 Layer2 的 gas fee，但是也会因为网络和 blob 交易的使用情况让 gas fee 有比较大的波动。

3.3 blob 数据如何存储

EIP-4844 的升级某种程度上与比特币的隔离见证（Segwit）升级有点类似，通过额外存储提升区块链的容量，而不用大区块的升级方案。这些额外多出来的数据也需要合适的存储方式，否则会增加节点的存储成本，降低以太坊网络的去中心化程度。

在 EIP-4844 升级之后，每个区块中可以有 6 个 blob，如果按照 50% 利用率，每天最多可以有 21600 个 blob，每天会新增 2.7G 的数据，这样会给节点带来很大的存储成本。所以这些数据在一定周期之后会从节点上删除，转而使用链下存储，包括 Layer2 rollup 自身、BitTorrent、区块链浏览器、Ethereum portal network、The Graph、个人等等。

特别是在 DankSharding 完全实现之后，每年可能会增加 40TB 的数据，单个节点上想要存储这些数据基本是不可能的，所以会采用定期删除，但是能按需找回的方案。

# 04

坎昆升级的影响

以太坊的坎昆升级和后续的 DankSharding 升级本质上是在给以太坊扩容，在完成扩容的同时，又没有采用大区块的方式，以太坊的区块还是会在 1M 以内，这有利于以太坊的长期发展，可以让以太坊在长时间内保持较高的去中心化程度。

坎昆升级可以提升 Layer2 交易的吞吐量以及降低 gas fee，甚至有望将 Layer2 的 gas fe 降低到当前十分之一的水平，各种大规模的应用就有可能开始爆发，可以将更多的 Web2 用户带入 Web3，当然这个情况更可能在 DankSharding 完全升级之后出现。

以太坊

同时 EIP-4844 的升级，也是对模块化区块链的肯定，这也会继续利好模块化区块链的发展。完成这次升级之后，以太坊的职能将会加速转变，越来越多的 DAPP 会在 Layer2 层开发，用户也会直接使用 Layer2，以太坊将会成为所有 Layer2 的 DA 层，成为整个 EVM 生态安全的守护者。

# 05总结

EIP-4844 本身并不是一个颠覆性的升级，对以太坊的用户来说改变并不多，以太坊还是很慢而且很贵。而各种 rollup 方案则会从从中受益，可以说这次升级就是为 rollup 所准备的。EIP-4844 的升级会让以太坊走向模块化区块链的方向，等到 Danksharding 升级完成之后，以太坊主网就成了 Layer2 的 DA 层，Layer2 就成了执行层，负责性能的提升，后续模块化的方案应该会不断出现。

转载声明：本文 由CoinON抓取收录，观点仅代表作者本人，不代表CoinON资讯立场，CoinON不对所包含内容的准确性、可靠性或完整性提供任何明示或暗示的保证。若以此作为投资依据，请自行承担全部责任。

声明：图文来源于网络，如有侵权请联系删除

风险提示：投资有风险，入市需谨慎。本资讯不作为投资理财建议。

赞 (0)
打赏 微信扫一扫 微信扫一扫
Bob鲍师傅Bob鲍师傅
0
上一篇 2024年1月25日 上午2:23
下一篇 2024年1月25日 上午2:23

相关推荐

LXDAO：坎昆升级技术详解

星期四 2024-01-25 2:23:47

TL;DR

在以太坊完成上海升级后，以太坊已成功从 PoW 过渡到了 PoS 协议。以太坊路线图中的另一个大的升级是 EIP-4844，也被称之为 Ptoto-Danksharding，这次升级旨在提高基于以太坊 rollup 的可扩展性，将于 2024 年 1 月 17 日开始在测试环境升级。这次升级也为以太坊的完整扩容方案 Danksharding 做好了准备工作。本文将介绍坎昆升级的内容，并对其中关键升级 EIP-4844 进行深入分析，同时也分析了 EIP-4844 升级所带来的影响。

本文中代码使用 geth（执行层）和 prysm（共识层）的实现。

# 01坎昆升级简介

坎昆升级最近有了新的进展，确定会在 2024 升级，测试环境将在 1 月 17 日进行，主网升级预计会在 2024 年的 3-4 月。作为以太坊生态的下一个主要叙事，这次升级肯定会得到很大的关注。

坎昆（Cancun）是墨西哥的一个城市，也是 Devcon3 的举办地，作为以太坊升级的传统，这次执行层的升级代号就是 Cancun。这次升级还会涉及到共识层的升级，共识层的升级代号是 Deneb，完整的升级代号是这两个代号的结合：Dencun = Deneb + Cancun。

这次升级包含的内容很多，执行层和共识层分别需要实施的 EIP 如下：

  • 执行层
  • EIP-1153
  • EIP-4788
  • EIP-4844
  • EIP-5656
  • EIP-6780
  • EIP-7516

  • 共识层
  • EIP-4788
  • EIP-4844
  • EIP-7044
  • EIP-7045
  • EIP-7514

这次升级的主角就是 EIP-4844，其他的升级要么是为它服务，要么是一些小修小补。在本文中，我们重点来研究 EIP-4844 升级的细节，以及升级之后带来的影响。

EIP-4844 也被称之为 Proto-Danksharding，这个名字来源于 Protolambda 和 Dankrad Feist 两位研究员。以太坊最终的数据扩展方案是 Danksharding，EIP-4844 是 DankSharding 的前置升级。这次升级主要的目的是提升 rollup 层的可扩展性，并且为后续的 DankSharding 升级做好准备。

# 02

理解坎昆升级，你需要知道

2.1 数据可用性（DA）

在区块链中，不要信任，要验证是一个基本的原则。每个区块链节点都可以保存完整的数据，可以通过重新执行交易来确定所有数据的真实性，通过独立地验证这些数据，就不用管其他的节点是否在作恶。

数据可用性是指在验证区块是否正确时，所需要的数据能够公开可获取。对于当前的以太坊架构来说，这很容易做到，因为每个节点都可以保存所有的数据，缺少数据的区块会被丢弃，对于所有的节点来说，数据是可用的，这是区块链的一个特性，数据可用性是区块链的安全保障。

对于 Layer2 rollup，能证明区块合法有效的数据都会上传到以太坊，它们的数据可用性需要依靠以太坊来保证。

这样就带来了两个问题：

  • 所有的 Layer2 都向以太坊提交数据，会让 gas fee 持续保持在高位
  • 以太坊本身的存储能力有限，制约了 Layer2 的发展

以太坊需要一种不牺牲数据可用性，同时又能让 Layer2 向以太坊用更低的成本提交更多交易的方案，让 Layer2 的潜力发挥出来。

EIP-4844 是这个方案的前半部分，通过增加一种新的 blob 交易，blob 交易中的数据存储成本更低，Layer2 可以将交易打包，通过 blob 交易提交到以太坊，从而增加并发、降低成本。但 EIP-4844 带来的提升是有限的，因为 blob 数据依然会传播到所有的节点，会给节点带来很大的存储和网络成本，所以这次升级中，每个区块只能支持 6 个 blob。

以太坊

Dankshrding 是这个方案的后半部分，在完成 DankSharding 之后，每个区块链支持的 blob 可能会到 64 个，这样 Layer2 基本就没有什么限制了。但在这个升级之后，大多以太坊节点就不可能独立的存储这些数据了，大多数人承担不了网络和存储成本。如果节点不能完整的存储数据，那么数据 DA 要怎么来保证呢？

以太坊

检查数据可用性的方式有很多种，但 DAS（Data availability sampling）是最去中心化的一种，DankSharding 中使用的也是这种。通过 DAS，完整的数据不用在节点之间传播，只需要随机检查部分数据的 KZG 证明就可以保证数据的可用性。

基于同样的原因，只有区块链的 Builder 需要获取所有的数据，创建好区块之后，其他的 Proposer 不用下载全部的数据，只需要通过 DAS 来验证区块是否有效，这个功能升级就是 PBS（Proposer-builder separation）。除了提高数据的处理效率，其他的 Proposer 也看不到交易的内容，这在一定程度还增加了抗审查能力。

2.2 KZG

KZG（Kate Zaverucha Goldberg）是一种零知识证明系统，EIP-4844 中引入了 KZG，作为 blob 验证和证明生成的一部分。每一个 blob 都会生成一个对应的 KZG commitment，为后续的 DankSharding 升级做准备。

在 EIP-4844 升级后，blob 数据还是会在各个节点之间传播。但是在完全的 DankSharding 升级之后，blob 的数据量大量增加，节点之间不能再全量地同步 blob 数据。节点之间会通过 KZG 和 DAS 来检查数据的 DA，这是 DankSharding 实现的基础。

# 03

Blast 与 L2

EIP-4844 升级中已经完成的工作：

  • 实现 blob 交易以及 blob 数据的 KZG 处理
  • 实现执行层&共识层逻辑，以及执行层和共识层交互接口的修改
  • blob 交易自动调整 gas 的机制

在完全实施 DankSharding 之前，还需要完成的工作：

  • DAS 实施
  • PBS 实施

EIP-4844 完成了后续 DankSharding 升级中的大部分基础工作。剩下的升级，只需要通过升级共识层来完成，不需要执行层和 rollup 的参与，用户和开发者对后续的升级无感。

3.1 blob 交易详解

在 blob 交易出现之前，Layer2 的交易数据通过 calldata 来存储，calldata 是合约调用中传入的函数参数，是只读的，并且会被永久存储到链上，blob 交易中的数据存储在额外的空间中，并且在一段时间后被删除。

blob 存储和 calldata 的区别：

以太坊

EIP- 4844 在执行层增加了 blob 的交易类型：

const ( LegacyTxType = 0x00 AccessListTxType = 0x01 DynamicFeeTxType = 0x02 BlobTxType = 0x03 // 新增的 blob 交易)

blob 的交易结构如下:

//geth core/types/tx_blob.go type BlobTx struct { //…

BlobHashes [][]byte // 相比于 EIP-1559 的交易，多了一个 Sidecar 参数 Sidecar *BlobTxSidecar `rlp:”-“`

//…}

// Sidecar 结构type BlobTxSidecar struct { Blobs []kzg4844.Blob // Blobs needed by the blob pool Commitments []kzg4844.Commitment // Commitments needed by the blob pool Proofs []kzg4844.Proof // Proofs needed by the blob pool}

// 每个 blob 原始数据最大 128 kbtype Blob [131072]byte

// 生成的 KZG commitment，占 48 字节type Commitment [48]byte

type Proof [48]byte

相比于 EIP-1559 交易，多了一个 Sidecar 参数，其中存放的就是就是 blob 数据，这些 blob 不会被打包进入执行层的区块。其中每个 blob sidecar 包含三部分数据，包括 blob 的原始数据和经过 KZG 处理之后的数据，BlobHashes 中存储 Sidesar 中 Commitments 的 hash 值。

blob 交易中，blob 数据存储部分的价格是单独计算的，而且会随之前区块 blob 的使用情况而变动，如果上一个区块中 blob 的使用超过了 blob 最大限制的 50%，那么费用就会上调，如果低于 50%，那么费用就会降低：

//geth core/types/transaction.go func CalcBlobFee(excessBlobGas uint64) *big.Int { return fakeExponential(minBlobGasPrice, new(big.Int).SetUint64(excessBlobGas), blobGaspriceUpdateFraction)}

// fakeExponential approximates factor * e ** (numerator / denominator) using// Taylor expansion.func fakeExponential(factor, numerator, denominator *big.Int) *big.Int { var ( output = new(big.Int) accum = new(big.Int).Mul(factor, denominator) ) for i := 1; accum.Sign() > 0; i++ { output.Add(output, accum)

accum.Mul(accum, numerator) accum.Div(accum, denominator) accum.Div(accum, big.NewInt(int64(i))) } return output.Div(output, denominator)}

计算一笔交易中 blob gas 的最大限制：

//geth core/types/transaction.gofunc (tx *BlobTx) blobGas() uint64 { return params.BlobTxBlobGasPerBlob * uint64(len(tx.BlobHashes)) }

计算最终交易的花费：

//geth core/types/transaction.gofunc (tx *Transaction) Cost() *big.Int { total := new(big.Int).Mul(tx.GasPrice(), new(big.Int).SetUint64(tx.Gas())) if tx.Type() == BlobTxType { total.Add(total, new(big.Int).Mul(tx.BlobGasFeeCap(), new(big.Int).SetUint64(tx.BlobGas()))) } total.Add(total, tx.Value()) return total}

最终一笔 blob 交易的开销由三部分组成：交易 gas fee + 发送的 value + blob fee。

在 EIP-4844 的升级中，每个区块中携带的 blob 数量不超过 6 个。后续完成 DankSharding 升级之后，每个区块上 blob 的数量可以扩展到 64 个。

执行层并不会存储这些 blob 数据，会在构建区块的时候，通过 API 将 Blob 数据传输到共识层：

// geth beacon/engine/types.gotype ExecutionPayloadEnvelope struct { ExecutionPayload *ExecutableData `json:”executionPayload” gencodec:”required”` BlockValue *big.Int `json:”blockValue” gencodec:”required”` BlobsBundle *BlobsBundleV1 `json:”blobsBundle”` Override bool `json:”shouldOverrideBuilder”`}

type BlobsBundleV1 struct { Commitments []hexutil.Bytes `json:”commitments”` Proofs []hexutil.Bytes `json:”proofs”` Blobs []hexutil.Bytes `json:”blobs”`}

共识层收到这些交易之后，会将 blob 的 KZG commitment 打包到链上，而将 blob 原始数据分开存储：

// prysm type BeaconBlockBody struct { //… blobKzgCommitments [][]byte // blob 的 Kzg 数据}

共识层会负责验证 Blob 数据的可用性，验证的逻辑都被封装在 isDataAvailable 方法中。目前的实现是先验证本地数据库中是否可以找到完整的 blob 数据，如果找不到，那就通过特定的渠道去获取，直到获取成功或者报错。后续 Danksharding 升级完成后，那么通过也会通过这个方法来实现 DAS 验证，减少对其他模块的影响。

// prysm/beacon-chain/blockchainfunc (s *Service) isDataAvailable(ctx context.Context, root [32]byte, signed interfaces.ReadOnlySignedBeaconBlock) error { //…}

在 EIP-4844 的升级后，blob 数据还是会通过 gossip 协议广播到所有的节点，在完全升级到 Danksharding 之后，会通过 DAS 来验证数据的完整性，而不用下载完整的数据。

总结一下，新增的 blob 交易允许用户将一些数据放到 blob 中，blob 数据不会在执行层存储， EVM 也无法读取到这些数据，这些数据会被直接放到共识层存储，然后广播给其他的共识层节点。

3.2 blob 如何影响 gas fee

理论上来说，EIP-4844 升级肯定会降低 Layer2 的 gas fee。因为 blob 的存储费用会比 calldata 更低，而且一个 blob 中可以容纳更多的交易，但实际的情况却会更复杂。

EIP-4844 升级中，每个区块的中最多可以挂 6 个 blob。但 blob 的费用是动态调整的，如果前一个区块中的 blob 数量超过了最大值的 50%，也就是 3 个，那么当前这个区块的 blob fee 就会上涨 12.5%，如果低于 50%，这个区块的 blob fee 就会下降 12.5%，所以最后每个区块中的 blob 数量会维持在最大容量的 50% 左右。

对于 Layer2 来说，理论上 gas fee 会降低到十分之一甚至更低，但是如果链上交易繁忙，多个 rollup 同时向以太坊提交数据，那么 blob fee 也会暴涨，很难准确地估计升级之后的 gas fee，这样取决于当时的网络情况。只有等到 DankSharding 完全升级，每个以太坊区块可以支持到 64 个 blob 时才能解决。

另外，一个 blob 的大小是 128kb，大小不能改变，对于交易的提交方来说，即使没有这么多数据，也需要付出一个完整 blob 的成本。如果一个 Layer2 上的交易量没有这么大，有可能使用 calldata 的成本会更低。当然也有可能多个交易量不大的 Layer2 会将数据合并后再使用 blob 交易提交。

EIP-4844 升级肯定会降低 Layer2 的 gas fee，但是也会因为网络和 blob 交易的使用情况让 gas fee 有比较大的波动。

3.3 blob 数据如何存储

EIP-4844 的升级某种程度上与比特币的隔离见证（Segwit）升级有点类似，通过额外存储提升区块链的容量，而不用大区块的升级方案。这些额外多出来的数据也需要合适的存储方式，否则会增加节点的存储成本，降低以太坊网络的去中心化程度。

在 EIP-4844 升级之后，每个区块中可以有 6 个 blob，如果按照 50% 利用率，每天最多可以有 21600 个 blob，每天会新增 2.7G 的数据，这样会给节点带来很大的存储成本。所以这些数据在一定周期之后会从节点上删除，转而使用链下存储，包括 Layer2 rollup 自身、BitTorrent、区块链浏览器、Ethereum portal network、The Graph、个人等等。

特别是在 DankSharding 完全实现之后，每年可能会增加 40TB 的数据，单个节点上想要存储这些数据基本是不可能的，所以会采用定期删除，但是能按需找回的方案。

# 04

坎昆升级的影响

以太坊的坎昆升级和后续的 DankSharding 升级本质上是在给以太坊扩容，在完成扩容的同时，又没有采用大区块的方式，以太坊的区块还是会在 1M 以内，这有利于以太坊的长期发展，可以让以太坊在长时间内保持较高的去中心化程度。

坎昆升级可以提升 Layer2 交易的吞吐量以及降低 gas fee，甚至有望将 Layer2 的 gas fe 降低到当前十分之一的水平，各种大规模的应用就有可能开始爆发，可以将更多的 Web2 用户带入 Web3，当然这个情况更可能在 DankSharding 完全升级之后出现。

以太坊

同时 EIP-4844 的升级，也是对模块化区块链的肯定，这也会继续利好模块化区块链的发展。完成这次升级之后，以太坊的职能将会加速转变，越来越多的 DAPP 会在 Layer2 层开发，用户也会直接使用 Layer2，以太坊将会成为所有 Layer2 的 DA 层，成为整个 EVM 生态安全的守护者。

# 05总结

EIP-4844 本身并不是一个颠覆性的升级，对以太坊的用户来说改变并不多，以太坊还是很慢而且很贵。而各种 rollup 方案则会从从中受益，可以说这次升级就是为 rollup 所准备的。EIP-4844 的升级会让以太坊走向模块化区块链的方向，等到 Danksharding 升级完成之后，以太坊主网就成了 Layer2 的 DA 层，Layer2 就成了执行层，负责性能的提升，后续模块化的方案应该会不断出现。

主页
快讯
精选
电报