FuelTS 项目中合约工厂部署方法的存储槽集成问题分析

问题背景

在 FuelTS 项目中，当使用自动生成的合约工厂类(如 MyContractFactory)进行合约部署时，存在一个关于存储槽(storage slots)集成的技术问题。存储槽是智能合约中用于持久化存储数据的关键机制，在合约部署时需要正确配置。

当前行为分析

目前系统存在三种部署方式，但表现不一致：

1. 标准部署方式
   使用 factory.deploy() 方法时，存储槽能够被正确集成到部署过程中。

2. 创建交易部署方式
   使用 factory.deployAsCreateTx() 方法时，存储槽不会被自动包含。

3. Blob交易部署方式
   使用 factory.deployAsBlobTx() 方法时，同样存在存储槽缺失的问题。

这种不一致性会导致开发者在使用不同部署方法时遇到意外的行为差异，特别是当合约依赖初始化存储状态时。

技术原因探究

问题的根源在于类型生成(typegen)系统对合约工厂类的实现方式。目前只有标准的 deploy 方法被特殊处理以包含存储槽信息，而其他两种部署方法则直接继承了基础 ContractFactory 类的默认实现，没有集成存储槽逻辑。

解决方案比较

项目团队提出了两种可能的解决方案：

方案一：方法级别重写

在类型生成的合约工厂类中，显式重写所有部署方法(deployAsCreateTx 和 deployAsBlobTx)，就像目前对 deploy 方法所做的那样。

优点：

• 实现直接明确
• 与现有模式一致

缺点：

• 需要在多个地方重复相似逻辑
• 增加类型生成系统的复杂性

方案二：属性集中管理

在基础 ContractFactory 类中引入一个受保护属性 _deployOptions，由派生类(如类型生成的工厂类)覆盖此属性来提供默认部署选项。所有部署方法都会自动合并这些选项。

优点：

• 逻辑集中，减少重复
• 更符合面向对象设计原则
• 易于扩展新的部署选项

缺点：

• 需要修改基础类结构
• 改变现有设计模式

推荐实现方案

基于软件工程的最佳实践，方案二更为优雅和可维护。它通过以下方式改进系统设计：

1. 在基础 ContractFactory 类中：

protected _deployOptions: DeployContractOptions = {};
private getDeployOptions(deployOptions) {
  return mergeDeepRight(this._deployOptions, deployOptions);
}

2. 所有部署方法统一使用合并后的选项：

async deploy(deployOptions) {
  const options = this.getDeployOptions(deployOptions);
  // 部署逻辑...
}

3. 在生成的工厂类中简单覆盖默认选项：

export class MyContractFactory extends ContractFactory {
  protected _deployOptions: DeployContractOptions = {
    storageSlots: MyContract.storageSlots
  };
}

这种设计不仅解决了当前问题，还为未来可能的部署选项扩展提供了良好的框架。

对开发者的影响

采用方案二后，开发者将获得以下好处：

1. 所有部署方法行为一致
2. 无需关心底层存储槽集成细节
3. 统一的选项合并机制
4. 清晰的扩展点用于自定义部署行为

总结

FuelTS 项目中合约工厂的存储槽集成问题揭示了类型生成系统与基础架构之间需要更好的协调。通过采用集中式的部署选项管理方案，不仅可以解决当前问题，还能为系统未来的演进奠定更坚实的基础。这种改进体现了良好的软件设计原则，包括DRY(不要重复自己)原则和开闭原则(对扩展开放，对修改关闭)。