以太坊之上，数据存储需求急剧增加，跟着这种情况，技术社区针对怎样高效并且经济地去处理大量数据，正在展开非常激烈的讨论。
数据验证的规模挑战
在那时，也就是网络里的验证节点数量达到九十万档次的时候，每一个节点仅仅需要对总数据当中极小的那一部分负责存储以及验证。这样做能够把负载给分散开来，然而面临的困难在于怎么样保障所有的节点都能够高效率地去验证那些被分割开来的数据。目前存在的方案要求节点针对整个数据块开展随机采样，如此一来就会迫使区块生产者临时去生成数量众多的额外数据以便能够满足验证的需求。
这种数据扩展进程直接左右区块的生成速率，每一回确认都得等候额外的数据被缔造以及传播，进而在系统层面导入了明显的延迟。特别是在网络拥堵之际，这成了限制交易吞吐量的一个潜在阻碍 。
列采样的效率优势
存在一种改进的思路，此思路是从数据的列维度展开采样，并非采用传统的行采样方式。具体来讲，对于每个验证节点而言，可以从每一列当中随机抽取出一个数据单元来进行检查。而这种方法的关键之处在于，所需用到的重建数据能够事先做好准备。交易发送方能够在提交数据之前就计算出必要的验证证明。
所以，验证节点用不着临时去请求或者是生成全新的数据，能够直接凭借预先计算好的证明把校验给完成。这样的一种转变，将数据准备方面的计算负担从区块生产者那儿转到了交易发送者之上，致使区块生产这个过程不会再因为这个而被拖累变慢，进而提高了网络整体的效率。
Gas成本的不确定性
这个系统目前面对的另外一个关键难题，是数据处理成本没办法预测。单个交易能够携带理论上会无限增长的数据量，这时为它计算精准的手续费，相当困难。费用模型要涉及从存储到验证的所有环节，可无限变量让它难以稳定定价。
给开发者带来实际困扰的是这种不确定性，他们在部署合约或者执行复杂操作之前，没办法准确预估到底最终需要支付的Gas费用会是多少，进而增加了开发风险以及用户的使用成本，一个不透明的成本体系会对生态应用的大规模采用造成阻碍。
代码优化的现实障碍
以长远视角来看，不稳定的数据规模对底层技术的演进路径产生了影响，举例而言，当计划把某些核心组件运用更高效的EVM原生代码进行重写之际，开发者遭遇了挑战，倘若输入数据的大小不存在固定上限，那么他们要设计出既安全又高度优化的执行代码路径便会存在困难。
对于开发者来说，理想的做法是针对常见的数据规格，像是256位呀，或者2048位之类的，去编写快速处理路径，而把比较慢的通用方案仅仅保留给罕见的大数据量这种情况。要是没有明确的上限，那么这种分层优化策略就没办法可靠地实施，有可能致使所有情况都只能采用效率比较低的通用路径。
极端情况的处理
一个主要副作用，有可能会是新提案所带来的，即极少数超大规模的单次合约部署，或许无法满足新的数据上限所需要求。这类部署，一般都是涉及复杂的去中心化应用的，或者是包含大量初始数据的智能合约。它们，可能得重新去设计架构，又或者是被拆分成多个连续的部署步骤 。
这类情形极为罕见，然而确实是存在的情况呢。技术进行升级之时需要把所有用户运用情况都考虑进去呀。假设方案显得过于刚性呐，那或许会在不经意间对某些创新性应用的部署造成阻碍哟，所以在开展设计之时候得提供充足的灵活性或者过渡的方案呀。
费用机制的重新平衡
存在一个根本矛盾，那就是当前以太坊的数据费用机制，执行交易的Gas成本变为数据存储总成本主要部分，这致使即便网络持续减低数据存储自身费用，用户总支出却未显著减少，原因在于执行成本依旧居高不下 。
在现有的机制情形当中，数据存储所需的费用会持续不断地下降，一直下降到一个极低的数值，当处于这个极低数值的时候，它将会完全地丧失掉调节市场供需的作用。为了对这种情况有所防范，新提案引入了一个和执行Gas价格相互挂钩的最低保留价格。这样做能够确保数据存储部分始终都保有基础价值，进而使得整体的费用结构变得更加稳定，更加具有可预测性。
从开发者以及用户的角度来看，那个稳定且具备可预测性的网络费用环境，是不是会比去追求那种极致的单次交易低价显得更为重要呢？
© 版权声明
文章版权归作者所有，未经允许请勿转载。
