ERC-7484：模块化智能账户的安全模块注册中心

ERC-7484是以太坊改进提案，旨在为模块化智能账户和去中心化身份系统提供安全保障。它定义了模块注册中心和注册适配器的标准框架，通过链上认证来验证模块的安全性，并支持可验证凭证的撤销状态检查。该提案通过标准化接口，增强了互操作性、透明度和信任，从而促进安全、互操作和创新的解决方案。

介绍

以太坊区块链随着账户抽象和模块化智能账户的引入而获得了显著发展，这些账户已通过 ERC-7579 进行了标准化。这些账户允许开发者通过即插即用的模块扩展功能，从而实现高级身份验证、自动交易或合规性检查等功能。然而，模块化系统的灵活性带来了安全风险，因为未经验证的或恶意模块可能会危及账户的完整性。ERC-7484 由 Konrad Kopp 和 zeroknots 于 2023 年 8 月提出，通过标准化模块注册表和注册表适配器来解决这一挑战，以在集成之前验证模块的安全性。本文深入探讨了 ERC-7484，涵盖了其目的、技术实施、用例、代码示例及其在模块化智能账户和去中心化身份系统中的作用。

什么是 ERC-7484？

ERC-7484 是一项以太坊改进提案 (EIP)，它定义了一个标准化的框架，用于在符合 ERC-7579 的模块化智能账户中安全地集成模块。它引入了两个主要组成部分：模块注册表，它存储关于模块安全性的链上证明；以及注册表适配器，它使智能账户能够查询和验证这些证明。除了智能账户外，ERC-7484 还通过提供用于检查可验证凭证 (VC) 吊销状态的接口来支持去中心化身份系统，从而与 Web3 中的自我主权身份 (SSI) 原则保持一致。

ERC-7484 的目标

  1. 安全模块集成：确保智能账户仅集成经过验证、值得信赖的模块。
  2. 标准化接口：为注册表和适配器提供一致的接口，以增强互操作性。
  3. 支持去中心化身份：实现对可验证凭证状态的无需信任的验证。
  4. 透明度和信任：使用链上证明来创建模块或凭证可信度的可验证记录。

双重目的

ERC-7484 服务于两个不同但相关的目的：

  • 模块化智能账户：标准化注册表以验证模块安全性。
  • 可验证凭证：提供用于检查去中心化身份系统中凭证吊销状态的接口。

为什么需要 ERC-7484

模块化智能账户中的挑战

ERC-7579 使开发者能够创建模块化智能账户，这些账户可以集成第三方模块以扩展功能。然而，这种可组合性带来了风险：

  • 恶意模块：模块可能包含窃取资金或操纵账户行为的代码。
  • 未经审计的模块：未经验证的模块可能存在攻击者可以利用的漏洞。
  • 不一致的验证：如果没有标准，每个智能账户实现可能会使用不同的安全检查，从而导致碎片化。

去中心化身份中的挑战

在 Web3 中，可验证凭证 (VC) 用于去中心化身份，例如 KYC 文档或认证。与中心化系统不同，没有单一机构来管理凭证吊销。这就需要：

  • 一种标准化的、无需信任的机制来检查凭证是否被吊销。
  • 跨不同去中心化身份框架的互操作性。

ERC-7484 通过提供统一的框架来安全地集成模块和验证凭证状态，从而应对了这些挑战。

ERC-7484 的核心概念

适用于模块化智能账户

  1. 模块：一个独立的智能合约，它为智能账户添加功能（例如，一个质押模块或一个多重签名验证器）。
  2. 证明：由证明者对模块的安全性、功能或合规性进行的链上断言。
  3. 证明者：审核模块并提交证明的实体（例如，安全审计员、DAO 或受信任的组织）。
  4. 模块注册表：一个智能合约，它存储证明并提供查询函数来检查模块的可信度。
  5. 注册表适配器：智能账户中的一个组件，它查询注册表并根据预定义的标准验证证明。

适用于可验证凭证

  1. 可验证凭证 (VC)：一个基于 JSON 的、可通过加密方式验证的凭证（例如，KYC 证书）。
  2. 凭证 ID：VC 的唯一标识符（通常是一个哈希值）。
  3. 吊销状态：一个布尔值，指示 VC 有效还是已吊销。
  4. 发行者：发行 VC 并管理其吊销状态的实体。
  5. 状态注册表：一个实现 ERC-7484 接口的智能合约，用于检查 VC 吊销状态。

ERC-7484 的工作原理

模块化智能账户工作流程

  1. 模块开发：开发者创建并部署一个模块。
  2. 提交证明：受信任的证明者审核该模块并将证明提交到模块注册表。
  3. 注册表查询：智能账户的注册表适配器查询模块注册表以获取有关该模块的证明。
  4. 验证：适配器检查模块是否满足安全标准（例如，来自受信任的证明者的最少数量的证明）。
  5. 集成：如果已验证，则智能账户启用该模块；否则，它拒绝该模块。

可验证凭证工作流程

  1. 凭证颁发：发行者创建一个 VC 并将其注册到符合 ERC-7484 的状态注册表中。
  2. 吊销：如果凭证失效（例如，由于欺诈），则发行者在注册表中将其标记为已吊销。
  3. 状态检查：DApp 或服务查询注册表，以使用其凭证 ID 检查 VC 的吊销状态。
  4. 决策：根据状态，DApp 允许或拒绝用户的操作（例如，访问 DeFi 协议）。

验证流程

  • 单个证明者流程：智能账户信任单个证明者对模块或凭证的证明。
  • 多个证明者流程：需要来自多个受信任实体的证明以增强安全性。

技术实现

以下是 ERC-7484 的两种用例的详细实现，并带有代码片段来说明这些概念。

1. 智能账户的模块注册表

模块注册表接口

模块注册表存储证明并提供查询模块状态的函数。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

interface IModuleRegistry {
    // 事件
    event AttestationCreated(address indexed module, address indexed attester, bytes32 schema, bytes data);
    event AttestationRevoked(address indexed module, address indexed attester, bytes32 schema);
    // 用于存储证明数据的结构体
    struct AttestationData {
        address attester;
        bytes32 schema;
        bytes data;
        uint256 expiry;
    }
    // 添加一个证明
    function attest(address module, bytes32 schema, bytes calldata data, uint256 expiry) external;
    // 撤销一个证明
    function revokeAttestation(address module, bytes32 schema) external;
    // 获取模块的所有证明
    function getAttestations(address module) external view returns (AttestationData[] memory);
    // 检查模块是否被特定的证明者证明
    function isAttested(address module, address attester, bytes32 schema) external view returns (bool);
    // 检查单个证明者
    function check(address module, address attester) external view returns (bool);
    // 检查多个证明者
    function checkN(address module, address[] calldata attesters) external view returns (bool);
}

解释:

  • AttestationData: 存储关于证明的详细信息，包括证明者、模式（例如，“securityAuditPassed”）、数据和到期时间。
  • attest: 允许证明者提交证明。
  • revokeAttestation: 允许证明者撤销他们的证明。
  • getAttestations: 返回模块的所有证明。
  • isAttested: 检查特定的证明者是否已证明模块的给定模式。
  • check 和 checkN: 分别验证来自一个或多个证明者的证明。

模块注册表实现

模块注册表的一个简化实现：

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract ModuleRegistry is IModuleRegistry {
    mapping(address => AttestationData[]) private moduleAttestations;
    function attest(address module, bytes32 schema, bytes calldata data, uint256 expiry) external override {
        require(module != address(0), "Invalid module address"); // 无效的模块地址
        require(expiry == 0 || expiry > block.timestamp, "Invalid expiry"); // 无效的到期时间
        moduleAttestations[module].push(AttestationData({
            attester: msg.sender,
            schema: schema,
            data: data,
            expiry: expiry
        }));
        emit AttestationCreated(module, msg.sender, schema, data);
    }
    function revokeAttestation(address module, bytes32 schema) external override {
        for (uint256 i = 0; i < moduleAttestations[module].length; i++) {
            if (moduleAttestations[module][i].attester == msg.sender && moduleAttestations[module][i].schema == schema) {
                moduleAttestations[module][i] = moduleAttestations[module][moduleAttestations[module].length - 1];
                moduleAttestations[module].pop();
                emit AttestationRevoked(module, msg.sender, schema);
                break;
            }
        }
    }
    function getAttestations(address module) external view override returns (AttestationData[] memory) {
        return moduleAttestations[module];
    }
    function isAttested(address module, address attester, bytes32 schema) external view override returns (bool) {
        for (uint256 i = 0; i < moduleAttestations[module].length; i++) {
            AttestationData memory attestation = moduleAttestations[module][i];
            if (attestation.attester == attester && attestation.schema == schema && (attestation.expiry == 0 || attestation.expiry > block.timestamp)) {
                return true;
            }
        }
        return false;
    }
    function check(address module, address attester) external view override returns (bool) {
        return isAttested(module, attester, keccak256("securityAuditPassed"));
    }
    function checkN(address module, address[] calldata attesters) external view override returns (bool) {
        for (uint256 i = 0; i < attesters.length; i++) {
            if (!isAttested(module, attesters[i], keccak256("securityAuditPassed"))) {
                return false;
            }
        }
        return true;
    }
}

注册表适配器

注册表适配器查询模块注册表并强制执行安全标准。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract RegistryAdapter {
    IModuleRegistry public registry;
    uint256 public minAttestations;
    address[] public trustedAttesters;
    constructor(address _registry, uint256 _minAttestations, address[] memory _trustedAttesters) {
        registry = IModuleRegistry(_registry);
        minAttestations = _minAttestations;
        trustedAttesters = _trustedAttesters;
    }
    function validateModule(address module) external view returns (bool) {
        // 检查模块是否有足够的证明
        uint256 validAttestations = 0;
        for (uint256 i = 0; i < trustedAttesters.length; i++) {
            if (registry.check(module, trustedAttesters[i])) {
                validAttestations++;
            }
        }
        return validAttestations >= minAttestations;
    }
}

智能账户集成

智能账户使用适配器来验证模块。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract SmartAccount {
    RegistryAdapter public adapter;
    mapping(address => bool) public enabledModules;
    constructor(address _adapter) {
        adapter = RegistryAdapter(_adapter);
    }
    function enableModule(address module) external {
        require(adapter.validateModule(module), "Module not verified"); // 模块未验证
        enabledModules[module] = true;
    }
    function executeModuleFunction(address module, bytes calldata data) external {
        require(enabledModules[module], "Module not enabled"); // 模块未启用
        (bool success,) = module.delegatecall(data);
        require(success, "Module execution failed"); // 模块执行失败
    }
}

2. 可验证凭证状态注册表

VC 的 ERC-7484 接口

用于检查 VC 吊销状态的接口非常简洁但功能强大。

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

interface IERC7484 {
    function isRevoked(bytes32 credentialId) external view returns (bool);
}

凭证状态注册表实现

用于管理 VC 吊销状态的基本实现：

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.0;

contract CredentialStatusRegistry is IERC7484 {
    address public issuer;
    mapping(bytes32 => bool) private revoked;
    modifier onlyIssuer() {
        require(msg.sender == issuer, "Not authorized"); // 未授权
        _;
    }
    constructor() {
        issuer = msg.sender;
    }
    function revokeCredential(bytes32 credentialId) external onlyIssuer {
        revoked[credentialId] = true;
    }
    function isRevoked(bytes32 credentialId) external view override returns (bool) {
        return revoked[credentialId];
    }
}

前端集成 (Ethers.js)

DApp 可以使用 Ethers.js 检查 VC 状态：

import { ethers } from "ethers";

const contractAddress = "0xYourContractAddress";
const abi = ["function isRevoked(bytes32 credentialId) external view returns (bool)"];
const provider = new ethers.providers.JsonRpcProvider("<https://rpc.sepolia.org>");
const contract = new ethers.Contract(contractAddress, abi, provider);
async function checkCredentialStatus(vcId: string) {
    const credentialHash = ethers.utils.keccak256(ethers.utils.toUtf8Bytes(vcId));
    const revoked = await contract.isRevoked(credentialHash);
    console.log(`Credential is ${revoked ? "revoked" : "valid"}`); // 凭证是 ${revoked ? "已吊销" : "有效"}
    return !revoked;
}

用例

1. 模块化智能账户

  • 安全审计：审计员在彻底审查后证明模块的安全性。
  • 合规性：遵守法规（例如，AML/KYC）的模块由相关机构证明。
  • 功能兼容性：证明表明了受支持的接口，确保了兼容性。
  • 声誉系统：随着时间的推移，具有积极使用历史的模块会获得证明。
  • DAO 治理：DAO 证明经过审查的模块可供社区使用。

示例：质押模块

用户想要向他们的智能账户添加一个质押模块：

  1. 该模块由 ConsenSys、OpenZeppelin 和 Trail of Bits 审计，他们将证明提交到模块注册表。
  2. 智能账户的适配器查询注册表，要求至少三个证明。
  3. 验证后，智能账户启用该模块，允许用户安全地质押代币。

2. 可验证凭证

  • DeFi 中的 KYC：DeFi 协议在允许访问之前验证用户的 KYC 凭证。
  • 认证：教育平台检查数字证书的有效性。
  • 会员系统：DAO 验证会员凭证以获得投票权。
  • 声誉系统：检查用户声誉的凭证是否有效。

示例：DeFi 中的 KYC

  1. KYC 提供商向用户颁发 VC 并在凭证状态注册表中注册。
  2. 如果用户的 KYC 状态发生变化，提供商将吊销该凭证。
  3. DeFi 协议查询注册表，以确保 VC 在授予访问权限之前有效。

ERC-7484 的优势

  • 增强的安全性：通过在链上验证模块和凭证来降低风险。
  • 互操作性：标准化的接口确保了跨实现的兼容性。
  • 透明度：链上证明提供对可信度的可审计记录。
  • 无需许可的创新：开发者可以创建模块或凭证，而用户可以验证其安全性。
  • VC 的隐私：仅公开凭证 ID（哈希值），从而保护用户隐私。

局限性和挑战

  • 证明者信任：依赖受信任的证明者会引入一些中心化风险。
  • Gas 成本：查询注册表和验证证明可能很昂贵，尤其是对于多个证明者。
  • 采用：有效性取决于开发者、证明者和 DApp 的广泛使用。
  • 凭证 ID 生成：ERC-7484 不会标准化凭证 ID 的创建方式，而是留给实施者。
  • 吊销控制：VC 注册表实现决定了谁可以吊销凭证，如果设计不当，可能会导致漏洞。

安全注意事项

  • 证明者选择：智能账户必须仔细选择受信任的证明者并定期审查其可信度。
  • 到期监控：适配器应检查证明到期时间，以确保持续有效。
  • 错误处理：合约应处理边缘情况，例如无效地址或过期证明。
  • 吊销机制：模块和 VC 注册表都必须支持强大的吊销机制，以解决受损的证明或凭证。

与其他标准的比较

  • ERC-7579：标准化模块化智能账户；ERC-7484 通过安全模块验证对其进行扩展。
  • ERC-4337：专注于账户抽象，但缺乏模块安全机制。
  • ERC-20/ERC-721：与智能账户或身份无关，专注于代币。
  • 以太坊证明服务 (EAS)：提供一般的证明框架；ERC-7484 更专注于模块和凭证验证。

未来展望

作为一项草案提案，ERC-7484 受社区反馈和改进的约束。潜在的进展包括：

  • 零知识证明：用于保护隐私的证明和凭证验证。
  • Gas 优化：批量查询或链下证明等技术可降低成本。
  • 与 SSI 框架集成：与 DID、W3C VC 和 zk-proof 系统更紧密地结合。
  • 测试网部署：正在进行的测试以验证标准的稳健性。
  • 社区采用：与 Polygon ID、Gitcoin Passport 和 Zupass 等项目合作，以推动实际应用。

结论

ERC-7484 是以太坊生态系统的一项关键标准，它解决了模块化智能账户和去中心化身份系统中的关键安全和信任挑战。通过标准化模块注册表和注册表适配器，它可以确保安全地集成模块，而其 VC 接口可以实现无需信任的凭证验证。提供的代码片段和用例展示了它的实际适用性，从质押模块到 DeFi 中的 KYC。随着以太坊的账户抽象和 SSI 格局的发展，ERC-7484 将在促进安全、可互操作和创新的解决方案方面发挥至关重要的作用。

  • 原文链接： medium.com/@ankitacode11...
  • 登链社区 AI 助手，为大家转译优秀英文文章，如有翻译不通的地方，还请包涵～
点赞 0
收藏 0
分享
本文参与登链社区写作激励计划 ，好文好收益，欢迎正在阅读的你也加入。

0 条评论

请先 登录 后评论
ankitacode11
ankitacode11
江湖只有他的大名，没有他的介绍。

ankitacode11

如果觉得我的文章对您有用，请随意打赏。你的支持将鼓励我继续创作！