Spark 的一个关键要求是，必须有一定阈值的 Spark 运营商共同合作才能授权交易。该协议的设计确保钱包始终可以确信这一阈值的运营商参与了交易的授权和完成过程，而不必信任单个 Spark 运营商的诚实行为。

​
分布式撤销密钥

我们使用一种称为分布式密钥生成（DKG）的加密过程，实现共享密钥集的分发。每个交易的 SOs 都经历一个过程来生成共享密钥，该密钥映射到撤销公钥，使得需要组合这些密钥分享的阈值才能派生出底层撤销密钥。Spark 使用撤销密钥来可验证地使交易的旧版本失效并防止双重支付。当钱包构建交易时，它与状态链运营商设置一个共同约定的撤销承诺。通过利用 DKG，钱包和 SOs 可以就撤销密钥达成一致，而无需任何个体完全访问该密钥，直到达到 SOs 合作的阈值。
DKG
当钱包请求 StartTokenTransaction() 时，单个 SO 选择一个未使用的先前生成的 DKG 密钥，并告知所有其他 SOs 也为生成的 TTXO 预留该密钥。然后它将该预留的公钥返回给钱包。当钱包随后调用每个 SO 运营商的 Sign() 时，每个 SO 运营商都有机会验证与每个输出关联的撤销公钥确实与之前预留的值匹配，从而验证撤销密钥输出不是由单个 SO 单方面选择的，并且派生撤销密钥的唯一方式是从 SO 集合中收集阈值数量的密钥分享。然后，钱包能够与每个 SO 单独验证与交易输出关联的撤销公钥确实与撤销密钥分享匹配，只有当阈值数量的 SO 释放其密钥分享时，钱包才能派生出这个密钥分享。诚实的 SO 只有在钱包能够证明（通过签名）它能够花费该输出时才会释放此密钥分享。

​
Spark 运营商签名冗余

在 Spark 上执行代币交易时，Spark 运营商代表了交易执行的集体”见证”。我们扩展了 LRC-20 节点实现，要求对于给定的 Spark 交易，发送资金的钱包指定的 SOs 的完整阈值已签署最终代币交易并将其提供给 LRC-20 Gossip 网络。这通过两种机制实现。首先，在构建 PartialTokenTransaction 时，钱包指定了预期参与代币交易授权的已知 Spark 运营商列表。这锁定了组成 Spark 实体的预期 SOs。其次，在签名时，钱包与每个 SO 单独通信，获取其各自授权交易并在其视角中使交易不可逆的签名。这使钱包能够知道这些 SO 的阈值实际上已按预期签署了交易。有了这些签名，钱包就能向更广泛的 LRC-20 gossip 网络证明它拥有 SO 见证者的阈值，这些见证者已授权代币的转移和/或发行。通过由钱包预先确定 SO 集合并硬编码在实际钱包签名的交易中，并且还让钱包单独检索每个 SO 签名，钱包、SO 集合和 LRC-20 Gossip 网络现在都拥有必要的签名，以表明完整阈值的 SOs 已参与并签署了资金的移动。

​
提款保证金

单方面退出交易要求钱包以聪为单位提供保证金，一旦满足锁定时间等待期，就可以恢复。这提供了经济上的抑制作用，防止恶意实体向链上广播大量 Spark 交易来攻击协议。这一要求的缺点是，持有大量叶子的钱包可能面临单方面退出到 L1 的潜在高额前期成本风险。钱包可以通过主动使用合并自转账来保持其拥有的 TTXO 集合较小，从而减轻这种风险。

​
监视塔冗余

监视塔对于防止通过尝试向 L1 广播被撤销的 TTXOs 进行欺骗至关重要。因此，拥有冗余监视塔至关重要。出于这个原因，SE 中的每个 SO 都将运行自己的监视塔。因此，只需要一个诚实的 SO 就可以防止被撤销输出的广播。此外，值得注意的是，运营商有动力运行监视塔，不仅是为了帮助维护网络的无信任性，还因为如果他们是最快使用其撤销密钥将资金转移到钱包的运营商，他们将能够索取欺诈者的保证金。最后，如果代币持有者寻求额外的安全层，他们可以通过订阅来自 LRC-20 节点的更新来运行自己的监视塔，尽管对于大多数用户来说，这可能是不必要的。