如何理解Vitalik Buterin新文对以太坊的扩容思考？有人说Vitalik给Blob铭文喊单，离大谱。那么Blob 数据包如何工作？坎昆升级后Blob空间为啥得不到高效利用？DAS数据可用性采样是为分片做准备？
在我看来，坎昆升级后性能够用了，Vitalik是对Rollup发展忧心忡忡。Why？接下来，我来谈谈我的理解：
在多次解释之前，Blob是一种直接可被共识层调取的临时数据包，直接好处是，EVM在执行交易时可以不访问Blob数据，因此产生较低的执行层计算费用。
当前平台一系列因素，一个Blob大小为128kb，一个批次给主网的交易最多携带两个Blob，考虑情况下，一个主网区块最终目标是承载16MB大约128个Blob数据包。
为了使Rollup项目具备最优性价比，可以使用Blob空间存储成本、TPS交易容量、Blob主网节点存储等因素作为主要考虑因素，以达到最大化的效益。
以Optimism为例，目前一天大约50万笔交易，平均每2分钱Batch一次交易到主网，一次携带1个Blob数据包。为什么带一个Blob个数就这么多用不完，当然也可以携带两个，那每个Blob的容量都不会满，却额外增加了存储费用，没必要。
当随着Rollup链下交易量的提升，比如每天要处理5,000万笔交易怎么办呢？1、Compress压缩每笔Batch的交易量，尽可能让Blob空间内容量大量的交易；2、增加Blob数量；3、缩短Batch交易的频次；
由于主网区块承载数据量受Gas Limit以及存储成本的影响，1个Slot区块128个Blob是理想状态，目前用不到那么多。Optimism每2分钟才会生成1个，留给layer2项目方提升TPS，扩大市场用户量和生态繁荣度的空间还有很大很大。
因此，坎昆升级后一段时间内，Rollup在使用Blob的数量、频次以及Blob空间竞价使用等方面并不“卷”。
之所以Vitalik提Blobscription铭文是因为，这类打铭文能短暂增加交易量导致Blob使用需求增加，因此会扩大体积，用铭文做例子可以更深刻理解Blob的工作机制，Vitalik真正想表达的内容和铭文并没有太大关系。
因为理论情况下，若有layer2项目方高频次且高容量向主网Batch交易，且每次把Blob区块拉满，只要它愿意承担高额的伪造交易Batch成本就会影响其他layer2对Blob的正常使用，但目前情况下，就像有人买算力对BTC进行51%硬分叉攻击一样，理论上可行，但实际缺乏利益动机。
Blob的引入目标是为了减负EVM，而提升节点的运维能力，无疑为Rollup量身订做的方案。显然，当下并没有被高效使用，二层使用Gas费用会在“较低”区间稳定很长一段时间。这会给layer2市场长时间的“增兵屯粮”黄金发展窗口。
3）那么，假使有一天layer2市场繁荣到一定程度，每天Batch到主网的交易成巨量，目前Blob数据包不够用怎么办？以太坊早已给出了解决方案：采用数据可用性抽样技术（DAS）：
简单理解，就是把原先需要一个节点存储的数据可以同时分布在多个节点内，比如，每个节点存储全部Blob数据的1/8，8个节点组成一个小组来满足DA能力，相当于把目前的Blob存储容量又扩大了8倍。这其实也是未来Sharding分片阶段要做的事情。
但目前Vitalik多次来重申这个，饶有韵味，似乎在告诫广大layer2项目方：不要总抱怨以太坊DA能力贵，以你们现在TPS容量都没把Blob数据包的能力开发到极致，赶紧加大火力搞生态，扩大用户和交易量吧，别总想着DA出逃搞一键发链的花活。
后边，Vitalik又补充了一句，认为目前核心rollup中，只有Arbitrum 达到了Stage 1，虽然DeGate、Fuel等达到了Stage2，但他们还没有被更广泛群体熟悉。Stage2是Rollup安全性的最终目标，极少数Rollup达到了Stage 1 ，而大部分Rollup都在Stage 0阶段，可见Rollup行业的发展着实让Vitalik忧心忡忡啊。
4）其实，单纯就扩容瓶颈问题而言，Rollup layer2方案可提升性能的空间还很大。
1、通过数据压缩更高效地使用Blob空间，OP-Rollup目前有专门的Compressor组件来进行此工作，ZK-Rollup本身链下压缩SNARK/STARK证明向主网submit就是在“压缩”；
2、尽可能降低layer2对主网的依赖，在特殊情况下才使用乐观证明技术来保障L2安全，比如，Plasma大部分数据都在链上，但是在存提款场景都是主网发生，因此主网可以承诺其安全性。
这意味着，layer2应该只考虑把存提款这类重要操作才和主网强关联，这样即减轻了主网负担，又增强了L2自身性能。之前谈并行EVM时提到的Sequencer“并行处理”能力，在链下筛选、分类预处理大量的交易，以及Metis推行的混合Rollup，正常交易走OP-Rollup，特殊提款请求走ZK Route等等都有类似的考虑。
