争议如何解决

一个争议有两个部分，而只有其中一个部分做出裁决。

链下层负责收集。它验证每位仲裁员的签名，将一次揭示与该仲裁员先前的承诺进行核对，拒绝来自从未提交承诺的钱包的揭示，丢弃重复项，并复制结果，使每个节点都看到相同的证据。

链负责裁决。它按照自己的规则清点已揭示的投票—— 按 stake 加权，设有已计票数下限，在平局时重开一轮而非打破平局——并转移托管资金。

链下层不清点票数

它曾经这样做过。getDispute 会返回一个由某节点所见揭示推导出的裁决结果，而这在一种值得理解的意义上是错误的，因为这是一种看起来像帮助的错误。

对同一批票数进行两次清点，是分歧的生成器，而非第二种意见。 链会按不同规则重新仲裁，因此它对同一争议可能得出不同的答案——当它这样做时，界面显示一个结果，而资金却遵循另一个。链是托管资金的权威，因此链下的答案不是第二种意见：它是协议做出、随后又用自己的资金加以推翻的一种陈述。

因此 resolution 只由一件事设定：本节点已独立观察到确认的一笔执行交易，其结果随后由该节点从链上的案件账户读取。

当每一份所需的揭示都到位后，案件处于 AwaitingChainExecution。该状态表示链下层已完成其工作，而托管资金尚未转移。它不是「已裁决待执行」——那种措辞会宣称一个节点无权命名的结果。

一个看到某笔交易落地但无法读取其裁决内容的节点保持在 AwaitingChainExecution，并记录它所观察到的签名。链上发生了某件事，而该节点尚不知道是什么；如实说出这一点是诚实的答案，而编造一个裁决去填补空缺正是此规则所要消除的那种失败。

双方可以就一次相互和解达成一致，链下层会直接验证双方的签名。它一拿到该协议就予以记录——那是关于案件的一个真实事实，隐瞒它会向双方隐藏他们自己的决定。

但记录一份协议不等于记录一个裁决。在托管资金实际转移之前，案件像任何其他案件一样处于 AwaitingChainExecution。

这一点很容易弄错，因为与一次裁定不同，这里没有两个节点会以不同方式执行的计算——协议本身就是那两个签名。它仍然必须等待，原因有二：

签名不会转移资金。 一个在资金仍被锁定时被标记为 MutualSettlement 的案件，会告诉双方争议已结束并已付款，而两者皆非事实。
链按其自己的截止期限执行。 它仍然可以自由地对一个双方私下达成一致却从未转达的案件执行一个仲裁结果—— 使两层就同一争议重新陷入矛盾，而这正是整条规则存在所要防止的。

节点所述	展示
`resolution: null`，状态 `AwaitingChainExecution`	案件已裁决或已达成一致；托管资金尚未转移
`resolution` 已设定，附带一个执行签名	结果，以及它来自的交易
已收集揭示，状态无变化	正在收集证据；没有可展示的结果

不要从 getDispute 响应中的揭示推导出一个结果。它们在那里是为了让任何人都能审计链收到了什么，而不是为了让客户端得出自己的裁决——一个清点它们的客户端，已经重新引入了节点已停止产生的那种分歧。

有关规范性表述，请参见 OFS-2400 §16.2 和 §17。