Liveness模块 - Optimism

几乎所有大规模的加密货币公司都使用多重签名（multisig）来管理其运营和升级。这些多重签名共同持有约 数千亿美元的资产，但它们的重要性远不止于此，因为这些多重签名对于其加密协议的运作至关重要。如果多重签名丢失，协议很可能也会丢失。

将密钥丢失给黑客不是唯一的风险。也可能在字面意义上丢失密钥。硬件钱包可能会被放错地方或在事故中损坏。PIN 码可能会被遗忘或意外地从密码管理器中删除。硬件钱包可以通过口令恢复，但存储这些口令本身就是一个重大风险，而且并非每个人都安全地存储它们。

在 Optimism，我们开发了一个简单的 Gnosis Safe liveness module，我们相信该模块可以针对多重签名密钥丢失的风险提供良好的保证。使用此模块，多重签名的所有者可以拥有更平衡的安全模型，并在晚上睡得更好。

在本文中，我们将解释我们的 liveness module 的工作原理。它是开源且免费使用的，我们希望整个行业因此而更加安全。

背景和要求

Gnosis Safe Multisigs 配置为一组所有者地址，其中一定数量的地址可以通过 safe 合约签名并执行交易。

Multisig liveness 意味着多重签名能够在特定时间内达成共识并执行一项声明“此多重签名处于活动状态”的交易——这就是我们想要保证的。

如果足够少的签名者（total - threshold + 1）永久阻止其达成共识，则多重签名将无法保持活动状态。例如，这可能是由于密钥意外丢失或被敌对势力盗窃而发生的。

我们首次尝试多重签名liveness 解决方案（1, 2）未能阻止恶意签名者拒绝签名。他们可以选择仅签署证明liveness的交易，同时阻止推进多重签名实际利益的交易。

我们的第一次尝试对于签名者来说也很不方便，因为他们必须定期表明他们处于控制之中，否则将被认为无行为能力并从多重签名所有者集合中删除。在许多多重签名中，总是有一些很少行动的签名者，但可以作为更活跃签名者的便捷备份。

让我们看看我们是如何解决这个问题的。

解决方案

Gnosis Safes 允许签名者使用 modules 和 guards 来增强或限制其功能。

Safe 签名者可以启用模块，以预先批准从 Safe 执行的某些操作，并在非签名者触发时执行。该模块实现了一些功能，非签名者调用它，Safe 执行该操作。

也可以在 Safe 上启用 guard，以在 Safe 执行交易之前或之后执行其他操作或强制执行条件。这就像为 Safe 执行交易添加要求。

我们最初的liveness guard 和 module 会删除未能单独显示liveness的签名者。除此之外，如果 safe 中的所有者数量低于定义的最低水平，则所有所有者都将被删除，并且多重签名的唯一控制权将转移给后备所有者。

合适的后备所有者将是具有更强安全保证的其他多重签名。它们可以是同一公司中的其他多重签名，专门为此目的维护的外部多重签名，或由愿意提供此服务并被认为非常值得信赖的其他组织处理的多重签名。

我们的新解决方案仅使用此后备所有者作为其唯一机制，并且这样做，它从个人liveness 的概念转换为多重签名liveness 的概念，这更容易管理。

我们没有为签名者保留liveness 注册表，而是为多重签名本身实施了一个简单的质询-响应机制。可以挑战多重签名以显示liveness，或者换句话说，可以询问“你还活着吗？”。

/// @notice Challenges an enabled safe.
/// @param _safe The Safe address to challenge.
    function challenge(Safe _safe) external {
        // Check if the calling safe has configuration set
        _assertModuleConfigured(_safe);

        // Check that the module is still enabled on the target Safe.
        _assertModuleEnabled(_safe);

        // Check that the caller is the fallback owner
        if (msg.sender != _livenessSafeConfiguration[_safe].fallbackOwner) {
            revert LivenessModule2_UnauthorizedCaller();
        }

        // Check that no challenge already exists
        if (challengeStartTime[_safe] != 0) {
            revert LivenessModule2_ChallengeAlreadyExists();
        }

        // Set the challenge start time and emit the event
        challengeStartTime[_safe] = block.timestamp;
        emit ChallengeStarted(address(_safe), block.timestamp);
    }

    /// @notice Responds to a challenge for an enabled safe, canceling it.
    function respond() external {
        Safe callingSafe = Safe(payable(msg.sender));

        // Check if the calling safe has configuration set.
        _assertModuleConfigured(callingSafe);

        // Check that this module is enabled on the calling Safe.
        _assertModuleEnabled(callingSafe);

        // Check that a challenge exists
        uint256 startTime = challengeStartTime[callingSafe];
        if (startTime == 0) {
            revert LivenessModule2_ChallengeDoesNotExist();
        }

        // Cancel the challenge without checking if response period has expired
        // This allows the Safe to respond at any time, providing more flexibility
        _cancelChallenge(callingSafe);
}

多重签名可以通过执行一个简单的预定调用来取消质询来回答。由于多重签名只有在拥有法定人数时才能执行调用，因此这确保了仍然有足够的密钥受到签名者的控制。如果由于缺乏法定人数而无法在给定的时间内执行此调用，则后备所有者将获得唯一所有权，并使用它将多重签名恢复到活动的集合所有者。

这种简单的机制还解决了恶意所有者仅签署证明liveness 的交易的情况。如果所有者集合中存在恶意签名者，那么将是诚实的所有者拒绝签署对liveness 挑战的回复。由于他们的拒绝，挑战回复将不会被执行，并且后备所有者将像以前一样获得唯一所有权。

// Get current owners
address[] memory owners = _safe.getOwners();

// Remove all owners after the first one
// Note: This loop is safe as real-world Safes have limited owners (typically <
// 10) Gas limits would only be a concern with hundreds/thousands of owners
while (owners.length > 1) {
  _safe.execTransactionFromModule({
    to : address(_safe),
    value : 0,
    operation : Enum.Operation.Call,
    data :
        abi.encodeCall(OwnerManager.removeOwner, (SENTINEL_OWNER, owners[0], 1))
  });
  owners = _safe.getOwners();
}

// Now swap the remaining single owner with the fallback owner
// Note: If the fallback owner would be the only or the last owner in the owners
// list, swapOwner would internally revert in OwnerManager, but we ignore it
// because the final owners list would still be what we want.
_safe.execTransactionFromModule({
  to : address(_safe),
  value : 0,
  operation : Enum.Operation.Call,
  data : abi.encodeCall(OwnerManager.swapOwner,
                        (SENTINEL_OWNER, owners[0],
                         _livenessSafeConfiguration[_safe].fallbackOwner))
});

// Sanity check: verify the fallback owner is now the only owner
address[] memory finalOwners = _safe.getOwners();
if (finalOwners.length != 1 ||
    finalOwners[0] != _livenessSafeConfiguration[_safe].fallbackOwner) {
  revert LivenessModule2_OwnershipTransferFailed();
}

使用模块功能将所有者集合替换为后备所有者

为了避免垃圾邮件攻击，只有后备所有者才能发布挑战。假设后备所有者具有更强的安全保证，并且活着且不恶意。如果后备所有者未能保持任何这些属性，则多重签名可以回复任何恶意挑战，并将恶意后备所有者替换为诚实的后备所有者。

最后，多重签名未能执行交易的原因可能是错误的或配置错误的 guard。即使由后备所有者拥有，这样的故障 guard 仍然会阻止多重签名。因此，liveness 模块在将所有者集合替换为后备所有者时，会删除任何 guard。删除 guard 涉及其自身的风险，可以缓解这些风险。

局限性

安全研究人员将阅读本文，并指出一些明显的局限性。

这种机制仅解决了恶意签名者用于所有者集合中超过一半的法定人数的多重签名的情况，例如 4/7。在法定人数小于所有者集合一半的多重签名中，恶意签名者将尽早达到法定人数，并且能够回应任何挑战。

恶意方从多重签名中获得法定数量的密钥并窃取其所有资产的黑客攻击是头条新闻中出现的情况。但是，还有其他一些情况也可能同样具有灾难性，我们会采取有时繁重的措施来防止这些情况。其中之一仅仅是有太多的所有者不可挽回地丢失了他们的签名密钥。

第二个限制是后备必须具有更强的安全保证，并且不可能在信任链中不断分配更强的后备。最终后备不能具有具有更强安全保证的后备。

但是，实际上，对于两个受到严格保护的多重签名，它们具有完全独立的所有者集合和安全机制，可以互为后备是很好的。这两个最终后备可能是高度信誉良好且防御良好的公共物品组织。

结论

虽然恶意方从多重签名中获得法定数量的密钥并窃取其所有资产的黑客攻击是头条新闻中出现的情况。还有其他一些情况也可能同样具有灾难性，我们会采取有时繁重的措施来防止这些情况。其中之一仅仅是有太多的所有者不可挽回地丢失了他们的签名密钥。

为了在多重签名中实现结构更好的深度防御，在 Optimism，我们提出了一个极其简单的 liveness module 用于 Gnosis Safes，该模块使用后备所有者的概念以及挑战和响应机制来保证在可行的假设下多重签名的liveness。

作为我们致力于促进社区利益的一部分，我们将发布此模块作为公共产品。可以随意按原样使用它，在 fork 中根据你的用例进行定制，或者根据你的需要进行讨论。该模块已由 Spearbit 审核。

创建此模块是 Optimism 多人的共同努力。愿景来自 Kelvin Fichter，代码由 John Mardlin 开发。Josep Bové、Tom Assas、Matt Solomon 和我以其他身份提供了帮助。

在 Optimism，我们一直在寻找有才华的人，他们将帮助我们完成扩展以太坊并构建 Superchain 的使命，突破可能的界限并为复杂的问题找到智能解决方案。如果那是你感兴趣的事情，我们正在招聘。

• 原文链接： optimism.io/blog/livenes...
• 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～