可扩展的 `Safe` 架构

本文档概述了一个*可扩展的* `Safe` 架构，旨在增加 `Safe` 的新型集成/应用。

以下指导原则已被严格采用：

1. `SafeProxy` 的状态绝对不能被修改，以确保最大程度的安全性。
2. 架构内不使用 `delegatecall`。

用例

目前，与 `safe` 的交互只能通过以下方式进行：

1. `owners` 通过 `execTransaction`；或
2. 授权的 `module` 通过 `execTransactionFromModule`；或
3. 希望验证 `signature` (ERC-1271) 的第三方。

此修订后的架构旨在实现的用例包括：

1. 在 `SafeProxy` 上任意方法调用。例如，这将使其在理论上可以通过实现 ERC20 方法将 `SafeProxy` 转换为 ERC20 代币。
2. 授权第三方合约代表 `Safe` 验证特定域的 EIP-712 签名。例如，可以将 CoW Protocol EIP-712 域委托给一个合约，该合约验证所有将任何 ERC20 代币出售为 ETH 的签名，即最大化 ETH :rocket:

当前架构

任何 _未_在 `Safe` 单例中实现的方法调用的执行路径如下：

```mermaid flowchart TD A[SafeProxy] -->|delegatecall| B[Safe - `FallbackManager`] B -->|call| C[CompatibilityFallbackHandler] ```

`CompatibilityFallbackHandler` 提供：

1. 使用批准的哈希或阈值签名的 ERC-1271 签名。
2. ERC721 / ERC1155 等的各种代币回调。

如果开发人员希望扩展 `Safe` 的功能，他们必须替换 `CompatibilityFallbackHandler`，这需要大量繁重的工作，并且要小心不要删除任何现有功能，以免破坏 `Safe`（现有基础架构的某些部分需要使用阈值签名，并且某些应用程序正在使用批准的哈希，例如 CoW Protocol dapp）。

开发人员可以*扩展* `CompatibilityFallbackHandler`，但是如果可以简单地为任意单个方法指定自定义处理程序，则可以使它变得更加容易。 这就是 `ExtensibleFallbackHandler` 的用武之地。

`ExtensibleFallbackHandler`

此处理程序替换 `CompatibilityFallbackHandler`，但保留与以下内容的向后兼容性：

1. ERC-1271 `Safe` 批准的哈希/阈值签名。
2. 代币回调。
3. ERC165。

除了向后兼容性之外，用户还可以：

1. 为自定义方法指定一个处理程序。
2. 为自定义方法指定一组处理程序，并指示 `Safe` 现在支持一个接口。
3. 为 EIP-712 域指定一个自定义验证器。

自定义方法

安全要求：

\* `Safe` 应确定（基于 setter 中的授权），自定义方法是否为 `view`（即，自定义方法是否可以在调用时修改状态）。

执行路径：

```mermaid flowchart TD A[SafeProxy] -->|delegatecall| B[Safe - `FallbackManager`] B -->|call| C[ExtensibleFallbackHandler] C -->|call| D[IFallbackMethod] C -->|staticcall| E[IStaticFallbackMethod] ```

自定义 EIP-712 验证器

用户要求：

1. 自定义验证器必须能够接受任意的、特定于实现的 `bytes` 有效负载。

安全要求：

\* `EIP-712` 域分隔符必须对照 `hash` 进行检查，以确保域分隔符和 `ISafeSignatureVerifier` 之间存在 1:1 的关系。

`isValidSignature(bytes32,bytes)` 的执行路径：

```mermaid flowchart TD A[SafeProxy] -->|delegatecall| B[Safe - `FallbackManager`] B -->|call| C[ExtensibleFallbackHandler - `SignatureVerifierMuxer`] C --> D[Approved Hash] C --> E[Threshold Signature] C -->|call| F[ISafeSignatureVerifier] ```

`signature` 的编码

\ `approvedhash` - `signature` 设置为零长度 `bytes`。 \* `threshold` - `signature` 是 65 字节的倍数（对于 `r`，`s`，`v`）。 \ `custom`（即 `ISafeSignatureVerifier`）- `signature` 是一个 ABI 编码的函数调用 `safeSignature(bytes32,bytes32,bytes32,bytes)`，其中元组等效于 `(bytes32 domainSeparator, bytes32 typeHash, bytes32 encodeData, bytes payload)`。 ABI 编码的函数调用中的 `4bytes` 选择器用于触发自定义签名者。

自定义验证器验证

在 `SignatureVerifierMuxer` 调用自定义验证器之前，它必须将 `domainSeparator` 与 `hash` 匹配。 因此，这意味着如果从 `SignatureVerifierMuxer` 调用，则 `typeHash` 和 `encodeData` 可以在 `ISafeSignatureVerifier` 中被信任。

`ISafeSignatureVerifier`

安全要求：

\* 实现可以重新断言 `_hash = h(abi.encodePacked("\x19\x01", domainSeparator, h(typeHash || encodeData)))`。

存储

自定义方法处理程序和自定义域验证器的存储包含在 `ExtensibleFallbackhandler` 部署中。 因此，对 `Safe` 的 `fallbackHandler` 的任何更新实际上都会“重置” `Safe` 的自定义方法/域验证器。

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