为了更有效地打包 Solana 区块，Anza 工程师 Tao Zhu 提议对 Solana 协议进行核心更改。该修正案（在 Solana 改进文档 (SIMD) 0172 中列出）针对 Solana 的“计算预算”计划，该计划是为了防止计算浪费而引入的。Zhu 认为这会导致 Solana 区块空间的使用效率低下。
虽然似乎有相当广泛的共识认为应该改变计算预算计划，但一些 Solana 开发人员认为 SIMD-0172 还不够。从本质上讲，该提案触动了 Solana 工程中的一个熟悉的共鸣——在构建快速、廉价且在整个网络中共享状态的区块链的同时处理数据的问题。
计算预算是一行代码，它决定了一笔交易可以使用多少个计算单元（Solana 原生的计算资源度量）。不同的交易执行不同的操作，因此它们占用的计算单元数量也不同。但 Solana 不希望浪费的交易增加它已经需要跟踪的大量数据，因此默认情况下交易的限制为 200,000 个计算单元。
这意味着每个 Solana 区块（最多包含 4800 万个 CU）将为具有默认计算预算的交易节省价值 200,000 个 CU 的空间。
在朱看来，问题在于 200,000 往往被高估了。通常，交易创建者不会要求更精确的计算预算，因此区块本质上是预留了空白空间。（值得一提的是，我看了看我最近的 SOL 转移，它使用了 86,000 个 CU）。
相反，朱希望在 10 个时期（大约 20 天）内将默认的 200,000 CU 降至零。然后，交易者将需要请求更精确的计算量。
因此，Solana 区块中的 4800 万 CU 将能够包含更多交易，这意味着将向验证者支付更多费用。这对于验证者来说是一个好消息，正如我们之前所报道的，他们最近过得并不轻松。
并非所有人都对朱提出的解决方案感到兴奋。基本上，即使计算预算默认为零，交易仍然需要包含计算预算的指令。
这些指令计入事务中可包含的最大 1232 字节（数据量度） 。据一位开发人员估计，计算预算指令占总数的 4% 。
这方面倾向于将计算预算移至事务头，这与指令分开，并且可以占用更少的字节。
朱先生表示， Solana 可能会完全放弃计算预算计划，但那是以后的事了。并不是每个人都对此感到兴奋。
一位 Solana 开发人员写道：“添加临时修复只会给开发人员带来更多痛苦。”
