Filecoin最新官方新闻：Filecoin虚拟机官宣！存储+计算=起飞！

Filecoin将分阶段推出EVM兼容的Filecoin虚拟机

11月12日消息，Filecoin将推出Filecoin虚拟机（FVM），为Filecoin网络引入智能合约的可编程性。FVM原生代码语言为WASM（WebAssembly），使得Web2的开发者能够更快地投入Web3的开发，此外，FVM还将首先实现EVM（以太坊虚拟机）兼容，Solidity开发者可以更快地在Filecoin上部署智能合约。FVM将分阶段上线，首阶段预计在2021年第4季度在Filecoin主网上推出不可编程的FVM，只运行系统角色（systemactors）。第二阶段引入协议分叉（2022年第1季度），在开发者可编程之前引入准备性调整，包括Gas机制和架构调整。随后的两个阶段将引入可编程性，重新设计系统角色和更深层次的协议变化，使其更容易针对系统角色进行编程，预计2022年第2季度完成。

Filecoin虚拟机（FVM）官宣！

Filecoin虚拟机的目标是让用户能够在Filecoin区块链上配置个人智能合约。FVM使Filecoin区块链拥有与Ethereum虚拟机智能合约通用的可编程性和兼容性。Filecoin Orbit的与会者是世界上首批了解FVM、FVM愿景、FVM将解锁的数千个机会、FVM的实施路线图以及如何[加入FVM] 的人

绿色Filecoin

Juan表示：“不要满足于零——Filecoin可以也应该以10倍的绿色环保为目标，净碳排放量应为-1,000。”

我们正在策划各种活动、捐赠以及相关支持，推动Filecoin真切对环境有益，并在整个网络中跟踪环境方面的影响。加入Filecoin Slack上的#fil-green话题，做第一个发现新机会的人吧！或者告诉我们您认为需要在Github上的此领域构建什么？

Filecoin 是一种基于区块链机制的分布式存储网络。Filecoin存储提供商可以选择为网络提供存储容量，从而通过定期生成证明他们提供指定容量的加密证明来赚取 Filecoin 加密货币 (FIL) 的单位。此外，Filecoin 使各方能够通过 Filecoin 区块链上共享分类账中记录的交易来交换 FIL 货币。然而，Filecoin 并没有使用 Nakamoto 风格的工作证明来维持链上的共识，而是使用存储本身的证明：矿工在共识协议中的权力与其提供的存储量成正比。

Filecoin 区块链不仅维护 FIL 交易和账户的分类账，还实现了 Filecoin VM，这是一种复制状态机，在网络参与者之间执行各种加密合约和市场机制。这些合约包括存储交易，其中客户向矿工支付 FIL 货币以换取存储客户请求的特定文件数据。通过 Filecoin VM 的分布式实现，记录在链上的存储交易和其他合约机制会随着时间的推移继续进行处理，而不需要来自原始各方（例如请求数据存储的客户端）的进一步交互。

虚拟机

Filecoin 区块链中的 Actor 相当于以太坊虚拟机中的智能合约。

Filecoin 虚拟机 (VM) 是负责执行所有参与者代码的系统组件。在 Filecoin VM 上执行 actor（即链上执行）会产生 gas 成本。

在 Filecoin VM 上应用（即执行）的任何操作都会以状态树的形式产生输出（下面讨论）。最新的状态树是 Filecoin 区块链中的当前事实来源。该国树是由CID，其存储在IPLD店鉴定。

虚拟机参与者接口

如上所述，Actors 相当于以太坊虚拟机中的智能合约的 Filecoin。因此，Actor 是系统的核心组件。Filecoin 区块链当前状态的任何更改都必须通过 actor 方法调用来触发。

本小节描述了Actors 和 Filecoin 虚拟机之间的接口。这意味着下面描述的大部分内容并不严格属于 VM。相反，它是位于 VM 和 Actors 逻辑之间接口上的逻辑。

总共有十一 (11) 种类型的内置Actor，并非所有类型都与 VM 交互。一些 Actor 不会调用对区块链状态树的更改，因此不需要与 VM 的接口。我们稍后将在系统参与者小节中讨论所有系统参与者的详细信息。

该演员地址是通过散列发送者的公钥和创建随机数生成稳定的地址。它应该在跨链重组时保持稳定。该演员ID地址，另一方面，是紧凑的，但可以在链重新组织的情况下更改自动递增地址。也就是说，在创建之后，actor 应该使用一个actor address。

该ActorState结构由参与者的余额（就该参与者持有的代币而言）以及一组用于查询、检查和与链状态交互的状态方法组成。

状态树

状态树是在 Filecoin 区块链上应用的任何操作的执行结果。链上（即 VM）状态数据结构是一个映射（以哈希数组映射树 - HAMT 的形式），它将地址绑定到参与者状态。每次调用 actor 方法时，VM 都会调用当前的状态树函数。

VM 消息 - Actor 方法调用

消息是两个参与者之间的通信单元，因此是状态变化的原始原因。一条消息结合了：

要从发送方转移到接收方的代币金额，以及

带有要在接收器上调用的参数的方法（可选/如果适用）。

Actor 代码可以在处理接收到的消息时向其他 Actor 发送额外的消息。消息是同步处理的，也就是说，actor 在恢复控制之前等待发送的消息完成。

消息的处理消耗计算和存储单元，两者都以 gas 计价。消息的gas 限制提供了处理它所需的计算的上限。消息的发送者以他们确定的 gas 价格为消息执行（包括所有嵌套消息）消耗的 gas 单位付费。区块生产者选择将哪些消息包含在一个区块中，并根据每条消息的 gas 价格和消耗量获得奖励，从而形成一个市场。

消息语法验证

语法上无效的消息不得传输、保留在消息池中或包含在块中。如果收到无效消息，则应将其丢弃并且不再进一步传播。

当单独传输时（在包含在块中之前）SignedMessage，无论使用何种签名方案，消息都被打包为 。有效签名消息的总序列化大小不大于message.MessageMaxSize。

语法上有效的UnsignedMessage：

有一个格式正确的非空To地址，

有一个格式正确的非空From地址，

具有Value不小于零且不大于总令牌供给（2e9 * 1e18），并

有非负GasPrice,

具有GasLimit为至少等于与所述消息的序列字节相关联的气体的消耗，

具有GasLimit不大于区块气体限制网络参数。

应该有几个函数能够从 中提取信息Message struct，例如发件人和收件人地址、要转移的价值、执行消息所需的资金和消息的 CID。

鉴于消息最终应包含在一个块中并添加到区块链中，应根据消息的发送方和接收方、值（应为非负且始终小于循环供应）、gas 价格（同样应该是非负的）并且BlockGasLimitwhich 不应大于区块的 gas 限制。

消息语义验证

语义验证是指需要消息本身之外的信息的验证。

语义上有效的SignedMessage必须携带一个签名，以验证有效负载是否已使用From地址标识的帐户参与者的公钥进行签名。请注意，当From地址是 ID 地址时，必须在块标识的父状态中的发送帐户参与者的状态中查找公钥。

注意：发送actor必须存在于包含消息的块所标识的父状态中。这意味着单个块包含创建新帐户参与者的消息和来自同一参与者的消息是无效的。来自该参与者的第一条消息必须等到下一个纪元。消息池可能会排除来自尚未处于链状态的参与者的消息。

没有进一步的消息语义验证会导致包含该消息的块无效。每个句法有效且正确签名的消息都可以包含在一个块中，并将从执行中产生一个收据。其中MessageReceipt sturct包括以下内容：

但是，消息可能无法执行完成，在这种情况下，它不会触发所需的状态更改。

这种“无消息语义验证”策略的原因是，在消息作为提示集的一部分执行之前，无法知道消息将应用到的状态。一个块生产者不知道在提示集中是否有另一个块将在它之前，从而改变了块的消息将应用于声明的父状态的状态。

例子：

VM 运行时环境（VM 内部）

收据

AMessageReceipt包含顶级消息执行的结果。每个句法有效且正确签名的消息都可以包含在一个块中，并将从执行中产生一个收据。

语法上有效的收据具有：

一个非负ExitCode，

Return仅当退出代码为零时才为非空值，并且

一个非负的GasUsed。

vm/runtime 演员界面

可以在此处找到 Actors 接口实现

vm/runtime 虚拟机实现

Filecoin 虚拟机运行时的 Lotus 实现可以在这里找到

退出代码

有一些常见的运行时退出代码由不同的参与者共享。他们的定义可以在这里找到 。

汽油费

概括

与许多区块链的传统情况一样，Gas 是衡量链上消息操作为执行而消耗多少存储和/或计算资源的单位。在高层次上，它的工作原理如下：消息发送者指定他们愿意支付的最大金额，以便他们的消息被执行并包含在一个块中。这既是根据gas 的总单位数( GasLimit) 来指定的，这通常预计会高于实际值GasUsed，也可以根据每单位gas 的价格(或费用) ( GasFeeCap) 来指定。

传统上，GasUsed * GasFeeCap作为奖励去区块生产矿工。该产品的结果被视为消息包含的优先费，即消息按递减顺序排列，最高GasUsed * GasFeeCap的优先，因为它们为矿工带来更多的利润。

然而，据观察，GasUsed * GasFee由于一些原因，这种（支付）策略对于出块矿工来说是有问题的。首先，出块矿工可能会免费包含非常昂贵的消息（就所需的链资源而言），在这种情况下，链本身需要承担成本。其次，消息发送者可以设置任意高的价格，但对于低成本消息（同样，在链资源方面），导致 DoS 漏洞。

为了克服这种情况，Filecoin 区块链定义了一个BaseFee，为每条消息烧毁。其基本原理是，鉴于 Gas 是衡量链上资源消耗的一种指标，与奖励矿工相比，将其燃烧是有意义的。这样，避免了矿工的费用操纵。的BaseFee是动态的，根据网络的拥塞自动调整。这一事实使网络能够抵御垃圾邮件攻击。鉴于 SPAM 攻击期间网络负载增加，由于BaseFee.

最后，GasPremium是发送方包含的优先费，以激励矿工选择最有利可图的消息。换句话说，如果消息发送者希望更快地包含其消息，他们可以设置更高的GasPremium.

参数

GasUsed是为了执行消息而消耗的资源量（或gas单位）的度量。每个单位的气体都以 attoFIL 为单位，因此GasUsed是一个代表消耗能量单位的数字。GasUsed与消息是正确执行还是失败无关。

BaseFee是每次执行消息时要燃烧（发送到不可恢复地址）的每单位 gas（以 attoFIL/gas 单位衡量）的设定价格。的值BaseFee是动态的，并根据当前网络拥塞参数进行调整。例如，当网络超过 5B 的 gas 限制使用量时，BaseFee当 gas 限制使用量低于 5B 时，会增加和相反的情况。的BaseFee施加到每个块应被包括在块本身。应该可以BaseFee从链的头部获取当前的值。的BaseFee每单位适用GasUsed，因此，气体的总量烧制的消息是BaseFee * GasUsed。请注意，BaseFee每个消息都会产生 ，但对于同一块中的所有消息，它的值是相同的。

GasLimit以gas为单位测量并由消息发送者设置。它对允许消息执行在链上消耗的气体量（即气体单位的数量）施加了硬性限制。一条消息会为它触发的每个基本操作消耗 gas，而耗尽 gas 的消息将失败。当消息失败时，由于该消息的执行而发生的对状态的每次修改都会恢复到其先前的状态。无论消息执行是否成功，矿工都将因其执行消息所消耗的资源而获得奖励（见GasPremium下文）。

GasFeeCap是消息发送者愿意为每单位 gas 支付的最高价格（以 attoFIL/gas 单位衡量）。再加上GasLimit，则GasFeeCap是设置一个发件人将一个消息FIL支付的最高金额：发件人是保证信息绝不会令他们超过GasLimit * GasFeeCapattoFIL（不包括任何溢价，该信息包含其收件人）。

GasPremium是消息发送者愿意支付的每单位 gas（以 attoFIL/gas 衡量）的价格（在 之上BaseFee）以“提示”将在区块中包含此消息的矿工。一条消息通常会获得其矿工GasLimit * GasPremiumattoFIL，其中有效GasPremium = GasFeeCap - BaseFee。请注意，GasPremium应用于GasLimit，而不是GasUsed，以使矿工的消息选择更直接。

示例：ComputeGasOverestimationBurn

ComputeGasOverestimationBurn 计算要退还的气体量和要燃烧的气体量结果是（退款，燃烧）

注释和含义

该GasFeeCap应始终比网络的更高BaseFee。如果消息GasFeeCap低于BaseFee，则剩余部分来自矿工（作为惩罚）。这种惩罚适用于矿工，因为他们选择了比网络支付更少的消息BaseFee（即，不包括网络成本）。然而，矿工可能要选择一个消息，其GasFeeCap比小BaseFee，如果同一个发件人在邮件池，其另一条消息GasFeeCap比要大得多BaseFee。回想一下，如果存在多个消息，矿工应该从消息池中挑选发送者的所有消息。理由是第二条消息增加的费用将弥补第一条消息的损失。

如果BaseFee + GasPremium> GasFeeCap，那么矿工可能不会获得全部GasLimit * GasPremium作为他们的奖励。

一条消息被硬约束为花费不超过GasFeeCap * GasLimit。从这个金额中，网络首先BaseFee被支付（燃烧）。之后，最多GasLimit * GasPremium将作为奖励提供给矿工。

gas 用完的消息失败，并显示“out of gas”退出代码。GasUsed * BaseFee仍然会被烧毁（在这种情况下GasUsed = GasLimit），并且矿工仍然会得到奖励GasLimit * GasPremium。这假设GasFeeCap > BaseFee + GasPremium.

的低值GasFeeCap可能会导致消息卡在消息池中，因为它在利润方面没有足够的吸引力，任何矿工都可以选择它并将其包含在一个块中。当这种情况发生时，有一个程序来更新，GasFeeCap以便消息对矿工更具吸引力。发送者可以将新消息推送到消息池中（默认情况下，它将传播到其他矿工的消息池），其中：i）旧消息和新消息的标识符相同（例如，相同Nonce）和 ii）GasPremium更新并增加至少 25% 的先前值。

系统参与者

总共有十一 (11) 个内置系统 Actor，但并非所有这些都与 VM 交互。每个参与者都由代码 ID（或 CID）标识。

VM 处理需要两个系统参与者：

在 InitActor，初始化新的参与者和记录网络名称，

在 CronActor，，在每个时间段运行关键功能的调度演员。还有另外两个与 VM 交互的参与者：

负责用户帐户（非单例）的 AccountActor，以及

用于区块奖励和代币归属的 RewardActor（单例）。

不直接与 VM 交互的其余七 (7) 个内置系统 Actor 如下：

StorageMarketActor：负责管理存储和检索交易 [ 市场参与者回购]

StorageMinerActor：负责处理存储挖掘操作并收集证明的actor [ Storage Miner Actor Repo ]

MultisigActor(或Multi-Signature Wallet Actor)：负责处理涉及Filecoin钱包的操作[ Multisig Actor Repo ]

PaymentChannelActor: 负责建立和结算支付渠道相关的资金【 Paych Actor Repo】

StoragePowerActor: 负责跟踪分配给每个存储矿工的存储功率[ Storage Power Actor ]

VerifiedRegistryActor: 负责管理已验证的客户端 [ Verifreg Actor Repo ]

SystemActor: 一般系统actor [ 系统actor repo ]

CronActor

内置于创世状态，CronActor的调度表调用StoragePowerActor和StorageMarketActor为它们维护内部状态并处理延迟事件。它原则上可以在网络升级后调用其他参与者。

发起者

将InitActor有可能创造新的角色，例如，那些进入系统的电源。它维护一个表，将公钥和临时参与者地址解析为他们的规范 ID 地址。不应将无效的 CID 提交到状态树。

请注意，在链重组的情况下，规范 ID 地址不会持续存在。参与者地址或公钥在链重组后仍然存在。

奖励演员

这RewardActor是保存未铸造的 Filecoin 令牌的地方。演员直接将奖励分配给矿工演员，在那里他们被锁定以进行归属。用于当前 epoch 的奖励值在 epoch 结束时通过 cron 滴答更新。

AccountActor

该AccountActor负责用户帐户。帐户参与者不是由 来创建的InitActor，而是由系统调用它们的构造函数。帐户参与者是通过向公钥样式地址发送消息来创建的。地址必须是BLS或SECP，否则会出现退出错误。帐户参与者正在使用新的参与者地址更新状态树。

VM 解释器 - 消息调用（VM 外部）

VM 解释器在该 Tipset 的父状态上编排来自 Tipset 的消息的执行，产生一个新状态和一系列消息接收。这个新状态的 CID 和收据集合的 CID 包含在来自后续 epoch 的块中，这些块必须就这些 CID 达成一致才能形成新的提示集。

每个状态变化都是由消息的执行驱动的。必须执行来自提示集中所有块的消息才能产生下一个状态。来自第一个块的所有消息在提示集中的第二个和后续块的消息之前执行。对于每个块，首先执行 BLS 聚合消息，然后执行 SECP 签名消息。

隐式消息

除了每个块中显式包含的消息之外，每个时期的一些状态更改都是由隐式消息进行的。隐式消息不在节点之间传输，而是由解释器在评估时构建。

对于tipset中的每个块，一个隐式消息：

调用区块生产者的矿工角色来处理（已经验证的）选举 PoSt 提交，作为区块中的第一条消息；

调用奖励actor将区块奖励支付给矿工的所有者账户，作为区块中的最终消息；

对于每个提示集，一个隐式消息：

调用 cron 参与者来处理自动检查和付款，作为提示集中的最终消息。

所有隐式消息都使用From作为可区分系统帐户参与者的地址构造。它们指定的 gas 价格为零，但必须包含在计算中。它们必须成功（退出代码为零）才能计算新状态。隐式消息的收据不包括在收据列表中；只有明确的消息才有明确的收据。

天然气支付

在大多数情况下，消息的发送者向生成包含该消息的区块的矿工支付gas费用以执行该区块。

每条消息执行的 gas 费用在该消息执行后立即支付到矿工所有者帐户。获得的区块奖励或gas费用都没有任何负担：两者都可以立即花费。

重复消息

由于不同的矿工在同一个 epoch 中生产区块，单个tipset 中的多个区块可能包含相同的消息（由相同的 CID 标识）。发生这种情况时，仅在第一次以提示集的规范顺序遇到该消息时才处理该消息。消息的后续实例将被忽略，并且不会导致任何状态突变、产生收据或向区块生产者支付 gas。

因此总结了tipset的执行顺序：

支付第一个区块的奖励

处理第一个区块的选举职位

第一个块的消息（SECP 之前的 BLS）

为第二个区块支付奖励

处理第二个区块的选举职位

第二个块的消息（在 SECP 之前的 BLS，跳过任何已经遇到的）

[... subsequent blocks ...]

定时滴答

消息有效性和失败

有效块中的每条消息都可以被处理并产生收据（请注意，块有效性意味着所有消息在语法上都是有效的——请参阅 消息语法——并正确签名）。但是，执行可能成功也可能不成功，这取决于应用消息的状态。如果消息执行失败，则相应的收据将携带非零退出代码。

如果消息由于可以合理归因于矿工的原因而失败，包括在父状态下永远不会成功的消息，或者因为发送方缺乏资金来支付最大消息成本，那么矿工将通过销毁来支付罚款天然气费（而不是发送者向区块矿工支付费用）。

消息失败导致的唯一状态更改是：

增加发送者的CallSeqNum，以及从发送者到包含消息的区块矿工的所有者支付 gas 费用；或者

相当于失败消息的gas费用的罚款，由矿工烧掉（发件人CallSeqNum不变）。

如果在之前的状态中，消息执行将失败：

该From演员不存在于该州（矿工受到惩罚），

该From演员是不是帐号演员（的矿工处罚），

该CallSeqNum消息不匹配CallSeqNum的的From演员（的矿工处罚），

的From演员不具有足够的平衡，以覆盖消息的总和Value加上最大气体成本，GasLimit * GasPrice（矿工处罚），

在To演员不存在状态和To地址不是PUBKEY式的地址，

的To演员的情况下（或者隐式地作为帐户创建），但不具有对应于非零的方法MethodNum，

反序列化Params不是一个长度与To演员MethodNum方法的数量相匹配的数组，

反序列化Params对于To参与者MethodNum方法指定的类型无效，

被调用的方法消耗的气体比GasLimit允许的多，

被调用的方法以非零代码（via Runtime.Abort()）退出，或

由于上述任何原因，接收方发送的任何内部消息都失败了。

请注意，如果To参与者在 state 中不存在并且地址是有效H(pubkey)地址，则会将其创建为帐户参与者。

文件币虚拟机

Filecoin 面向用户的大部分功能（支付、存储市场、功率表等）都是通过 Filecoin 虚拟机（Filecoin VM）进行管理的。网络生成一系列区块，并同意哪个区块“链”是正确的。每个块都包含一系列被调用的状态转换messages，以及global state应用这些之后的当前检查点messages。

在global state这里由一组的actors，每一个都有自己的私人state。

Anactor是相当于以太坊智能合约的 Filecoin，它本质上是 Filecoin 网络中的一个“对象”，具有状态和一组可用于与之交互的方法。每个参与者都有一个属于它的 Filecoin 余额，一个state指针，一个code告诉系统它是什么类型的参与者的CID，以及一个nonce跟踪该参与者发送的消息数量的 。

有两种方法可以调用actor. 首先，要作为系统的外部参与者（也就是 Filecoin 的普通用户）调用方法，您必须向message网络发送签名，并向包含您的message. 消息上的签名必须与具有足够 Filecoin 的帐户关联的密钥匹配，以支付消息的执行费用。这里的费用相当于比特币和以太坊的交易费用，它与处理消息所完成的工作成正比（比特币按每字节消息定价，以太坊使用“gas”的概念。我们也使用“gas”） .

其次，actor在调用其方法之一期间，可能会调用另一个actor 上的方法。然而，这种情况唯一可能发生的原因是外部用户消息调用了某个参与者（注意：用户调用的参与者可能会调用另一个参与者，然后调用另一个参与者，执行可以承受的层数去跑）。

感谢您的阅读，如果觉得文章对您有帮助请关注;涵锐科技IPFS

有什么问题可以留言评论！