内置 Filecoin 演员们

此存储库包含从 2022 年 7 月 6 日的网络版本 16、时代 1960320 开始，为 Filecoin 网络提供动力的链上内置演员的代码。

这些演员是用 Rust 编写的，并设计在 Filecoin 虚拟机 内部运行。后者有一个参考实现，位于 filecoin-project/ref-fvm。

此存储库的构建过程将每个演员编译成 Wasm 字节码，并生成一个聚合包，供所有客户端导入。此包的结构是标准化的。以下为详细信息。

此代码库已在 FIP-0031 中进行了规范。因此，从网络版本 16 开始，此演员实现是网络唯一认可的。

预 FVM 演员们

以下网络版本（nv16 之前）的演员也在此实现

• nv14 演员以方便测试。
• nv15 演员以启用 nv15=>nv16 升级。

可导入的包

此存储库的主要输出是一个 CARv1 归档，将所有演员的 Wasm 字节码打包到一个文件中，具有以下特性

• CARv1头指向单个根CID。
• 根CID解析为一个DAG-CBOR编码的块，该块定义了一个包含版本号的Manifest类型（目前总是1）以及一个ManifestPayload的CID。
• 以下定义了ManifestPayload（定义如下），它包含在一个DAG-CBOR编码的块中，并定义了一个类型，将actor类型名称与相应的CID关联。
• 所有actor的CID都包含在同一个CARv1存档中，与包含在RAW块中的编译后的Wasm字节码相同。

Manifest 架构

# Manifest is encoded as: [version, CID]
type Manifest struct {
  version Int
  payload &ManifestPayload
} representation tuple

# ManifestPayload is encoded as: [ ["actorkey", CID], ["actorkey", CID], ... ]
#
# It alternatively may be interpreted as:
#   type ManifestPayload {String : &ActorBytecode} representation listpairs
# Or simply as a list of tuples.
type ManifestPayload struct {
  system &ActorBytecode
  init &ActorBytecode
  cron &ActorBytecode
  account &ActorBytecode
  storagepower &ActorBytecode
  storageminer &ActorBytecode
  storagemarket &ActorBytecode
  paymentchannel &ActorBytecode
  multisig &ActorBytecode
  reward &ActorBytecode
  verifiedregistry &ActorBytecode
  datacap &ActorBytecode
  placeholder &ActorBytecode
  evm &ActorBytecode
  eam &ActorBytecode
  ethaccount &ActorBytecode
} representation listpairs

# RAW block
type ActorBytecode bytes

在此存储库中提供了预编译的actor包作为发布二进制文件。在crates.io上的fil_builtin_actors_bundle包将不会被更新。

发布

我们通过更改顶级Cargo.toml文件中的workspace.package.version，同时发布所有actor、运行时和状态抽象。

1. 在顶级Cargo.toml文件中更改workspace.package.version。
2. 在GitHub上创建一个发布。

这将触发GitHub CI的自动打包构建，生成的包将附加到GitHub发布中。

客户端实现说明

获取actor包

有两种选择

1. 从源代码构建。
2. 从GitHub下载预编译的发布包。

从源代码构建说明（选项1）

1. 克隆存储库。
2. 检出相关分支或标记（见以下版本部分）。
3. 从工作区根目录执行make bundle。

包将写入output/builtin-actors.car。

两种选项都支持通过脚本或CI管道进行自动化。

集成actor包

这部分是特定于实现的。选项包括

1. 将包的CARv1字节嵌入到分发的二进制文件中。
2. 启动时下载CARv1文件（带有某种形式的校验和以增加安全性）。

使用ref-fvm加载和使用actors包

一旦实现验证了包的真实性，它应该执行以下操作

1. 将CARv1导入到blockstore。
2. 在内存中保留根CID，按网络版本索引。
3. 将根CID提供给ref-fvm的Machine构造函数，以告诉ref-fvm哪个CodeCID映射到哪个内置actor。

支持多个网络版本

由于每个网络版本可能由不同的actor代码支持，实现应该准备好加载多个actor包，并按网络版本索引它们。

在实例化ref-fvm Machine时，必须传递网络版本和相应的Manifest根CID。

版本控制

一个公平的问题是crate版本控制如何与协议概念ActorVersion相关。我们采用与specs-actors类似的政策

• crate版本中的主版本号与ActorVersion相关。
• 我们通常不使用次要版本；这些始终设置为0。
• 我们努力实现以整数形式表示的主要crate版本，以表示给定网络升级的最终发布。然而，由于无法预测软件工程的某些方面，这不是一个硬性规则，并且可能通过增加补丁号进行进一步发布。

开发版本将使用类似于 -rc（发布候选）的限定符。

以下是一个将此策略应用于 v10 动手人版本谱系的示例

• 不稳定开发版本通过提交哈希引用。
• 稳定开发版本标记为发布候选：10.0.0-rc1，10.0.0-rc2 等。
• 最终发布版本：10.0.0。
• 修补的最终发布版本：10.0.1。
• 修补的最终发布版本：10.0.2。
• 网络升级于 10.0.2 上线。

关于此代码库

与 specs-actors 的关系

此仓库取代了 specs-actors，并履行两个角色

• 内置动手人的可执行规范。
• 内置动手人的规范、可移植实现。

致谢

此代码库最初是从 Forest 客户端 的动手人 v6 实现分叉的，并适应了 FVM 环境。

社区

由于此代码库是所有 Filecoin 客户端实现中的公共资源，它成为所有 Core Dev（无论其身份认同的实现或项目）的汇聚点。

许可

双重许可：通过 MIT、Apache 软件许可 v2，通过 宽松许可栈。

除了 EVM 预编译 测试数据，该数据受 LGPL v3 许可，不包括在 crates 或构建工件中。