链下工作者的角色
Role of off-chain workers
我正在尝试建立一个关于链下工作者在 substrate 中的角色的心智模型。更大的图景似乎是他们在底层节点内移动逻辑，否则由 oracles 完成，触发预定义的事务。我特别想到了两个用例：
1：验证文件格式：传入的交易提出了一个可通过 url 或 ipfs 哈希访问的文件，它的格式需要验证。链下工作人员获取文件，断言格式（大小、编码、内容等），如果正确则提交另一笔交易说它是有效的。
2：密钥生成：假设有一个单独的服务与底层节点一起分发，它管理每个实例的密钥。节点 A 运行 通过参与者 A、B 和 C 之间的这种外部服务进行密钥共享算法（如 Shamir 的秘密共享），然后进行交易，在链上创建组 (A,B,C)。此交易触发该组中的所有节点 运行 链下工作人员，调用他们的本地密钥存储来验证是否拥有密钥。他们之后都可以在链上标记它。
据我理解，区块执行后每个节点都会触发链下工作者。在前一个用例中，这将导致大量事务只验证一个文件，并且没有任何东西可以保证这些文件的正确性。就文件的有效性达成共识的好方法是什么？如果没有像 staking 这样的经济激励，这是否也可行？如果代币在网络中没有价值，例如在企业设置中，就会有问题。这甚至是链下工作人员的正确用例吗？第二个例子不应该有这样的问题，我们只需要各方验证是否有密钥。
上面的思路错在哪里，为什么？
As far as I understand it correctly, off-chain workers are triggered in every node after block execution.
是也不是。它有一个 CLI 标志。在撰写本文时，它说：
--offchain-worker <ENABLED>
Should execute offchain workers on every block.
By default it's only enabled for nodes that are authoring new blocks. [default: WhenValidating] [possible
values: Always, Never, WhenValidating]
In the former use case, this would result in lots of transactions validating just one file, and nothing guarantees the correctness of these.
我认为接收函数（又名 Call）有责任处理和激励这一点。例如，可能有奖励机会来验证地址。但是，如果它已经被另一笔交易提交，你将被罚没（或者即使没有，你也需要支付一些交易费用，但没有任何费用）。在这种情况下，您可以假设并非所有参与者都会提交交易。他们只会在有改进的机会时才会这样做，这应该由您的潜在 reward/slash 方案来描述。
Is this even the right use case for off-chain workers?
我不是这方面的专家，但我认为至少验证示例是一个很好的示例。这只是找到一个好的激励+反垃圾邮件削减的问题。
我对第二个例子不太熟悉，所以不做评论。
我正在尝试建立一个关于链下工作者在 substrate 中的角色的心智模型。更大的图景似乎是他们在底层节点内移动逻辑，否则由 oracles 完成，触发预定义的事务。我特别想到了两个用例：
1：验证文件格式：传入的交易提出了一个可通过 url 或 ipfs 哈希访问的文件，它的格式需要验证。链下工作人员获取文件，断言格式（大小、编码、内容等），如果正确则提交另一笔交易说它是有效的。
2：密钥生成：假设有一个单独的服务与底层节点一起分发，它管理每个实例的密钥。节点 A 运行 通过参与者 A、B 和 C 之间的这种外部服务进行密钥共享算法（如 Shamir 的秘密共享），然后进行交易，在链上创建组 (A,B,C)。此交易触发该组中的所有节点 运行 链下工作人员，调用他们的本地密钥存储来验证是否拥有密钥。他们之后都可以在链上标记它。
据我理解，区块执行后每个节点都会触发链下工作者。在前一个用例中，这将导致大量事务只验证一个文件，并且没有任何东西可以保证这些文件的正确性。就文件的有效性达成共识的好方法是什么？如果没有像 staking 这样的经济激励，这是否也可行？如果代币在网络中没有价值，例如在企业设置中，就会有问题。这甚至是链下工作人员的正确用例吗？第二个例子不应该有这样的问题，我们只需要各方验证是否有密钥。
上面的思路错在哪里，为什么？
As far as I understand it correctly, off-chain workers are triggered in every node after block execution.
是也不是。它有一个 CLI 标志。在撰写本文时，它说：
--offchain-worker <ENABLED>
Should execute offchain workers on every block.
By default it's only enabled for nodes that are authoring new blocks. [default: WhenValidating] [possible
values: Always, Never, WhenValidating]
In the former use case, this would result in lots of transactions validating just one file, and nothing guarantees the correctness of these.
我认为接收函数（又名 Call）有责任处理和激励这一点。例如，可能有奖励机会来验证地址。但是，如果它已经被另一笔交易提交，你将被罚没（或者即使没有，你也需要支付一些交易费用，但没有任何费用）。在这种情况下，您可以假设并非所有参与者都会提交交易。他们只会在有改进的机会时才会这样做，这应该由您的潜在 reward/slash 方案来描述。
Is this even the right use case for off-chain workers?
我不是这方面的专家，但我认为至少验证示例是一个很好的示例。这只是找到一个好的激励+反垃圾邮件削减的问题。
我对第二个例子不太熟悉，所以不做评论。