Fuel项目交易格式中输入输出及见证数据大小限制的优化探讨

在Fuel区块链项目中，当前交易格式对输入(inputs)、输出(outputs)和见证数据(witnesses)的数量设置了单字节(1 byte)的限制，这意味着每个交易最多只能包含255个输入、255个输出和255个见证数据。这种限制在某些场景下可能会成为性能瓶颈，特别是在需要处理大量状态变更的交易中。

当前限制的影响分析

单字节限制意味着：

• 每个交易最多只能包含255个输入项
• 每个交易最多只能包含255个输出项
• 每个交易最多只能包含255个见证数据

这种限制在以下场景中可能成为问题：

1. 当区块生产者需要在一个交易中处理大量基于谓词(predicate)的状态变更时
2. 在进行签名聚合等操作时，这些操作码通常只能在单个交易环境中工作
3. 需要批量处理大量资产转移的场景

提议的改进方案

技术团队提出了将限制从1字节(255)扩展到2字节(65,535)的改进方案。这一变更将显著提高系统的吞吐能力，允许单个交易处理更大规模的操作。

技术挑战与考量

然而，这一改进并非没有挑战：

1. 性能影响：现有代码库中部分实现假设数量不会超过255，使用了非最优的实现方式。扩展后可能需要优化这些部分。

2. 基准测试影响：当前的基准测试假设单个交易生成的收据(receipts)不会超过255个，这一假设需要重新评估。

3. 兼容性问题：现有工具和合约可能假设交易在255个资产后结束，变更可能导致兼容性问题。

4. 内存占用：在最坏情况下，交易可能需要预留约2.5MB的内存空间，这对每个谓词/脚本来说可能过大，需要引入动态tx_offset支持。

5. 安全风险：扩展后可能增加DoS攻击风险，因为攻击者可以构造包含大量(65,535个)输入的交易，其中只有最后一个输入无效，迫使节点验证所有输入后才能拒绝交易。

渐进式改进建议

考虑到上述挑战，技术团队提出了渐进式改进方案：

1. 首先在交易格式中将字段类型从u8改为u16，但暂时保持255的实际限制
2. 在VM层面实施限制约束
3. 待系统其他部分(如工具链、合约等)做好准备后，再逐步提高实际限制

这种渐进式方法可以：

• 保持现有执行假设不变
• 为未来提升限制做好准备
• 降低变更带来的风险
• 给予生态系统适应时间

相关字段调整

为实现这一改进，还需要调整以下相关字段：

• witness_index需要从u8改为u16
• input_index需要从u8改为u16

总结

Fuel项目通过逐步扩展交易格式中关键字段的大小限制，为未来处理更大规模的交易做好准备，同时采用渐进式策略确保系统稳定性和兼容性。这一改进将显著提升系统处理批量操作的能力，为更复杂的应用场景提供支持。