我正在尝试构建脱链工人在底物中的作用的心理模型。更大的图景似乎是它们将逻辑转移到基板节点内部，否则由oracle来完成，从而触发预定义的事务。我专门在考虑两个用例：
1：验证文件格式：传入事务提议一个可通过url或ipfs哈希访问的文件，并且其格式需要验证。一名脱链工作人员获取文件，声明格式（大小，编码，内容等），如果正确，则提交另一笔交易，表明其有效。
2：密钥生成：假设存在与基板节点一起分发的单独服务，该服务为每个实例管理密钥。节点A通过参与者A，B和C之间的外部服务运行密钥共享算法（如Shamir的秘密共享），然后进行交易以在链上创建组（A，B，C）。此事务触发该组中的所有节点运行脱链工作器，调用其本地密钥库以验证是否具有密钥。他们都可以随后在链上对其进行标记。
据我正确理解，区块执行后，每个节点上都会触发脱链工作程序。在前一个用例中，这将导致大量事务仅验证一个文件，而没有任何保证这些文件正确性的方法。在文件有效性上达成共识的好方法是什么？如果没有像赌注这样的经济激励措施，这是否有可能？令牌在网络中（例如在企业设置中）没有价值将是有问题的。对于链下工人来说，这是否甚至是正确的用例？第二个示例不应受到此类问题的困扰，我们只需要各方验证是否具有密钥即可。
上述思考过程在哪里出错，为什么？
答案 0 :(得分：1)
据我所知，在执行块之后，每个节点都会触发脱链工作程序。
是，不是。有一个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]
在前一个用例中，这将导致大量事务仅验证一个文件，而不能保证这些文件的正确性。
我认为接收功能（也称为Call）有责任处理和激励这一点。例如，可能会有奖励机会来验证地址。但是，如果已经通过另一笔交易提交了该笔交易，您将被大幅削减（或者即使没有，您也确实支付了一些交易费，一无所获）。在这种情况下，您可以假设并非所有参与者都将提交交易。他们只有在有改进的机会时才这样做，这应该由您的潜在奖励/削减方案来描述。
对于链下工人来说，这是否是正确的用例？
我在这里不是专家，但是我认为至少验证示例是一个很好的示例。这只是寻找良好的激励措施和大幅减少垃圾邮件的问题。
我不太熟悉第二个示例，因此对此没有评论。