Danksharding
Sharding 是以太坊技术蓝图中的最后一块拼图，而Danksharding 是最新一个Sharding 的设计提案，比之前的设计都来的更简洁。更多关于Danksharding 的介绍可以参考：
Rollup 的主要成本之一为上传资料的成本，而在Sharding 推出后，Rollup 势必得改用Sharding 的交易资料格式（也称作Blob）来上传资料，因为会比目前用calldata 的方式便宜很多。
而这也代表未来Rollup 仍免不了要做一次系统更新：将资料上传方式从calldata 改成Blob。那我们短期可以做的就是：(1) 降低calldata 成本，也就是上一篇提到的EIP-4488，及(2) 让Rollup 提早切换至新资料格式（Blob），这样未来就不必再做一次系统更新，而这就是EIP-4844 Proto-Danksharding 在做的。
所以其实可以把Proto-Danksharding 理解成一个提前为Sharding 做准备，又能同时在中短期内大幅降低Rollup 成本，一石二鸟的解方。
Eth 2.0 CL/EL 的调整
在实作Sharding 的过程中，以太坊包含Consensus Layer (CL)及Execution Layer (EL) 的客户端都会需要进行升级。而身为在为Sharding 提前做准备的Proto-Danksharding 除了引进新的Shard Blob Transaction 格式外，还顺便更新了CL 及EL 的架构及实作。
在EL 这一端，包含Blob 的Fee Market（Blob 有独立的手续费市场，后面会介绍）、新的Opcode 及Precompile 合约、P2P 网路的新资料格式及EL/CL之间的沟通验证机制等等，基本上Sharding 会需要的EL 改动都已涵盖在这个EIP 当中。
在CL 这一端，包含保存及传递Blob 的资料（Blob 资料只在CL 间传递，不经过EL）、引进资料可用性的接口等等，大部分Sharding 会需要的CL 改动都已涵盖在这个EIP 当中。
Blob Sidecar 及相容DAS 的接口
Blob 资料是在Consensus Layer 间传递，但它不是被编码成区块的其中一部分，而是另外以称为「Sidecar」的形式传送，也就是区块资料和Blob 资料会是走两个不同的资料通道。
为什么要这样做？为什么不把Blob 资料编码成区块的一部分一起传送就好？这是为了能向前兼容Sharding 的设计所做的调整。未来Sharding 中Blob 资料会比现在还大上很多倍，也因此节点将不会下载完整的Blob 资料（所以不该编码成区块的一部分，否则会需要下载完整资料），而是透过 Data Availability Sampling 的方式一起来确保资料是可用的，并且节点会加入检查资料可用性的接口（is_data_available），用来确认资料是否可用。
这个EIP 引进了Sidecar 这个设计，提早让节点适应新的模式并能做一些效能的监测。目前节点都还是会下载完整的Blob 资料，所以接口会依是否有完整Blob 资料来回传True/False，未来在DAS 中则是会透过Sampling 及在P2P 网路沟通的结果来回传True/False。
剩下的Sharding 会需要但还没实作的部分包含（几乎都是最上面的Danksharding 介绍文章提到的技术）：
- 2 Dimension KZG commitments
- Data Availability Sampling (DAS) 的实作
- Proposer-Builder Separation (PBS)
- Proof of Custody 机制
多维度手续费市场
Blob 资料量很大但又不会被合约存取，而且具有有效储存期限，要给它订个公平合理的Gas 值也不容易。例如如果订一个固定Gas 值，那有可能会被攻击者利用来放一堆无意义资料，造成节点磁碟空间的负担。因此这个EIP 引进一个新的资源计算维度，让原本的EIP-1559 变成一个多维度的EIP-1559。
在这个多维度的1559 中，原本的Max Gas Per Block 及Target Gas Per Block 还是存在，只是又多了一组新的Max 及Target，也就是给Blob 资料的Max 及Target。目前设计中，Target 为每个区块8 个Blob，Max 为16 个。
Blob 维度中变动的是Gas 大小
当前1559 中随着机制变动的是 BASE_FEE，而在Blob 维度中随着机制变动的则是Blob 的 Gas 大小。如果Blob 数量超过Target Blob 数量，则Blob 的gas 大小会以指数成长！
注：Blob 的收费单位还是Gas，并没有新增一个计价单位，而且也是并入原本的Gas 消耗一起计算。
不一样的数据参考来源
当前1559 机制里所参考的是「上一个区块的Gas 消耗量」，而Blob 的维度中，数据参考来源是「历史总Blob 数」，差别主要也就是考量的是短时间周期的影响还是长时间周期的影响。
Blob Gas 计算方式
如果历史总Blob 数（以 total_blobs 代称）小于预期Blob 数（预期Blob 数为预期均值乘上区块总数，以 target_blobs 代称），则Blob 的Gas 为 0（基本上就是不收费），否则Gas 为 2**((total_blobs — target_blobs) / 64)，即当 total_blobs 增长太快超过 target_blobs 时，Blob 的Gas 大小将指数增长直到其降回低于 target_blobs。
注：64 为 GASPRICE_UPDATE_FRACTION_PER_BLOB 这个系统参数当前设定的值，有可能会改变。
每个区块结束系统都会去更新 total_blobs 值，且更新的 total_blobs值不能低于 target_blobs值（即 new_total_blobs = max(old_total_blobs, target_blobs），以避免过去一段时间都没Blob 导致接下来的一段时间里Blob Gas 都为零。
详细的算法可以参考这里。
Block Builder 该如何挑选交易？
两种交易，两种不同限制
Block Builder 是否会需要跑复杂的演算法来计算最优的一般交易及Blob 交易的组合？原本单维度的手续费市场Block Builder 只需要按照手续费高低来收入交易，但在多维度手续费市场里Block Builder 要面对两种变数、两种限制来找出手续费最高的组合，也就是背包问题（Knapsack Problem）。
Vitalik 目前推测是不用的，有几个原因：
- EIP-1559 的设计确保在大部分的时候是不会碰到上限的，因此大部分的时间Block Builder 都可以直接选择收入他们能接受的所有交易（但不代表每笔交易都会收入，Block Builder 还是会考量收入一笔交易是否划算）
- 这份分析也显示，尽可能收入交易的策略与使用最佳解算法（背包问题算法）的策略，在收益上差距并不大（收益为纯手续费收入，不包含MEV）
- MEV 会是最大的收入来源，而不是单纯交易本身手续费的收入。而MEV 都会是由更专业的角色去计算，他们本身就具备足够的知识和经验去算出最优组合。另外Proposer-Builder Separation 也能透过分工来避免Block Proposer 因为这些MEV 收入与竞争导致变得中心化— Proposer 赚的是Block Builder 的竞标费用而不是MEV。
兼容问题与挑战
Web3 API 存取不到Blob
Blob 会在CL 之间的P2P 网路传递，也就是EL 节点基本上不会存取到Blob，也因此是没办法透过web3 API 来拿到Blob 资料的。
Mempool 的DoS 风险
因为Blob 的Gas 消耗会变动，导致一个Blob 交易可能在某个时间点还是可以收入的，但后面就因为Gas 消耗超过指定的Gas Limit 而被判定为无法被收入而丢弃。为了避免有人利用这个机制来攻击Mempool，EIP 里建议只广播交易里指定的Gas Limit 至少是当前Blob Gas 最小值两倍的交易。
注：攻击方式为送很多笔Gas Price 很低，且Gas Limit 设得很接近当前Blob Gas 值的Blob 交易，这些交易会被视为合法因此散播到网路中其他节点，占据Mempool，但没多久就因为Blob Gas 值上升导致这些交易被丢弃。
另外因为Blob 本身资料量很大，所以攻击者可以送具有相同Nonce 值的多笔Blob 交易，并且每一笔新的都比前一笔的手续费多上10%，因此其他节点会一直接收每一笔新的交易，也就表示每一笔Blob 交易都会被广播到网路中每个角落，因此对网路造成负担。不过其实当前用一笔普通交易并塞满大量无意义的calldata 就能做到一样的攻击效果。EIP 建议如果这个情况变严重的话，可以考虑把Replacement 交易的手续费门槛由10% 调升至100%，也就是新的同Nonce 值交易的手续费要高过旧的一倍，节点才会接受并广播出去。
资料大小对磁碟大小需求的影响
EIP-4488 及Proto-Danksharding 都会造成一个效果是：长期下来平均每一个slot（即每12 秒）会有1MB 大小的传输需求，一年下来就是2.5 TB 的大小，远比目前Ethereum 每年新增的资料大小还大上许多。
如果EIP-4488 被采用了，那 EIP-4444：清除节点历史数据的手段就必须被纳入，来避免硬碟空间需求暴增。
如果Proto-Danksharding 被采用了，CL 节点可以透过定期清除旧的Blob 资料方式来避免硬碟需求暴增（不管EIP-4444 有没有被纳入）。
这两种方式都能将硬碟需求降至一年数百GB。不过Sharding 迟早会来，届时资料大小将会再大上许多，像是EIP-4444 这样的手段还是无可避免。
目前这个EIP 还在持续讨论及实作中
这个EIP 还有许多要测试和讨论的部分，包含测试网、多维度手续费市场、KZG 套件库、P2P 网路传送Blob 资料的测试及优化等等。
这一份文档里有这个EIP 的定期会议的议程及讨论内容。
责任编辑：MK
微信扫一扫 
