今天就实施 EIP-7730 , 让硬件钱包不再盲签

最近 Bybit 价值 15 亿美元的黑客攻击暴露了 Web3 生态系统中的一个关键漏洞，而社区多年来一直忽视了这个问题。虽然 Bybit 被入侵的供应链以及未能验证另一个设备上的签名是直接原因，但这一事件凸显了影响所有钱包用户的更广泛的安全挑战，而不仅仅是大型交易所。

作为业内专业人士，我们必须扪心自问，普通用户是否掌握了足够的信息来安全地验证他们的交易？令人不安的事实是，并没有。目前期望用户在多个设备上交叉检查签名是不现实的，不利于主流采用。很少有用户（如果有的话）在签署交易之前，会使用多种验证方法来例行验证 calldata。我们之前在我们的托管稳定币 rekt 测试中探讨了这些钱包 UX 限制，我们在其中强调了当前验证期望对于普通用户来说是多么不现实。

在这篇文章中，我们将演示 dapp 开发者如何使用 EIP-7730 帮助保护他们的用户免受盲签问题的影响，EIP-7730 使硬件钱包能够解码交易，并允许用户了解他们真正签署的内容。

我们认为，支持 EIP-7730 的 dapp 将比其竞争对手具有巨大的优势。随着涉及盲签的高调黑客攻击数量的增加，用户将要求他们选择交互的 dapp 提供更高的安全保证。

为什么盲签会造成不可能的安全负担

考虑一下用户需要为每笔交易遵循的安全步骤：

1. 验证交易的 calldata 与其主工作站上的预期操作相匹配
2. 确认其工作站上的交易哈希与硬件钱包上的哈希匹配
3. 在单独的工作站上交叉检查交易哈希及其解码的 calldata 是否与其预期操作相对应

虽然理论上是安全的，但这种多设备验证过程会给普通用户带来难以克服的摩擦，需要花费几分钟才能在多个设备上严格交叉检查每笔交易。如果我们期望 dapp 实现主流采用，安全性就不能以可用性为代价。

盲签的问题

核心问题在于盲签：要求用户签署他们无法有意义地解释的数据。发生这种情况是因为钱包缺乏将交易数据解码为人类可读格式所需的特定于协议的知识。每个 DeFi 协议都有其独特的智能合约接口和参数结构，但如果没有明确的解释说明，钱包就无法理解这些技术参数的实际含义。你会在不阅读内容的情况下签署法律合同吗？然而，在 Web3 中，用户经常签署以难以理解的字符串形式出现的加密哈希：

0x3b812a5cf28be8e4787e1d1d4d513744966d8684da2f9a61187a79607c1b9fca

用户求助于此，因为在与某些协议交互时，他们通常别无选择。大多数钱包实现都提供原始签名作为一种据称更好的选择，你可以在其中签署非解码格式的信息。例如：

0x0000000000000000000000008c1ed7e19abaa9f23c476da86dc1577f1ef401f50000000000000000000000007a250d5630b4cf539739df2c5dacb4c659f2488dffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff0000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000000063ae3c1f

但是，为了做出明智的签名决策，用户需要了解关键的交易细节：转移、交换或存入的确切资金额、目标地址、正在执行的操作类型、任何相关的风险（如滑点容差或委托权限）等等。如果没有这些详细信息，用户实际上是信任其工作站向其硬件钱包发送无恶意交易，从而对可能受到攻击的系统产生危险的依赖性。

这使我们回到了最初的盲签问题：用户签署他们无法验证或理解的数据表示。

EIP-712 的进步，但还不够

最初引入 EIP-712 专门用于解决盲签问题，它提供了一种标准化的方式，让应用程序在签名之前向用户呈现结构化的、人类可读的数据。该标准的工作原理是定义一种结构化数据格式，钱包可以解释和显示该格式，从而使用户可以看到有组织的字段，如代币数量、接收者地址和操作类型，而不是原始的加密数据。该协议通过要求应用程序同时提供原始交易数据和一个描述每条数据代表什么内容的结构化模式来实现这一点，从而使钱包能够向用户呈现有意义的信息。

该标准允许用户验证他们正在签名的单个字段，理论上可以实现“明文签名”而不是盲签。

图1：没有EIP-712的 Metamask 签名请求（左）和有 EIP-712 的 Metamask 签名请求（右）

虽然 EIP-712 通过在许多协议中标准化结构化数据签名代表了重大进展，但它仍然在关键方面存在不足。Bybit 黑客攻击清楚地表明了这些局限性。尽管支持 EIP-712，但交易数据仍然过于复杂，无法进行人工验证。在被破坏的交易中，签名输入的一些参数被更改，最关键的是操作类型从 0（正常调用）更改为 1（委托调用），以及目标地址。

这里是被签名后泄露的信息：

图2：Etherscan 上被泄露的 Bybit 黑客签名交易

操作类型的这种细微差别完全改变了交易的行为，允许攻击者在 Safe 合约的上下文中执行恶意代码。当面对无法提供人类可读上下文的十六进制编码值时，大多数用户几乎不可能检测到这些技术细节。

签名者可能在其钱包中看到的 EIP-712 数据结构表示略有不同。虽然像 Trezor Model T 这样的某些硬件钱包确实支持 EIP-712 并且可以显示结构化消息，但该标准并未解决以人类可读格式呈现嵌套操作的挑战。钱包将需要专门的知识，即“data”参数表示需要进一步解码的 calldata 操作。

即使在 MetaMask 等界面中并排比较时，原始交易和篡改后的交易看起来也足够相似，用户很容易将两者混淆，而无需深入了解基础参数的技术知识。最关键的更改（操作类型切换到委托调用）在没有专门知识的情况下尤其难以识别。

这突出表明，虽然 EIP-712 提供了结构，但这些复杂的交易必须进一步解码为真正的人类可读格式。如果没有这种额外的解释层，用户仍然有效地盲目签署他们无法有意义地验证的数据。

硬件钱包提供了一个不完整的解决方案

笔记本电脑、手机和计算机都可能被入侵。硬件钱包更安全，因为它们的设计目的只是用于签署交易并保护密钥的安全。它们被入侵的可能性最小。但是，虽然计算机可以显示丰富的用户界面，但硬件钱包具有非常简单和最小化的 UX，无法通过请求签名的网站进行修改。但是，硬件钱包没有解码除最简单交易之外的任何内容的能力。这是因为它们缺乏解码调用特定合约函数时将发生什么情况所需的语义信息。例如，在普通 ERC-20 上调用 transferFrom 函数的结果可能与在实现 fee-on-transfer 的合约上调用 transferFrom 的结果不同。 一些硬件钱包制造商（如 Ledger）试图通过专用插件来解决此问题。在与受支持的协议（如 Paraswap）交互时，用户可以将特定的应用程序下载到他们的硬件钱包中，从而使他们能够直接在其安全设备上查看交易详细信息，从而绕过计算机上的任何被破坏的信息。 然而，这种方法面临着一个关键的采用差距。在数百个 DeFi 应用程序中，只有不到 200 个具有专用的 Ledger 应用程序 1，其中许多是简单的钱包而不是 dapp。主要的 DeFi 协议明显缺失。

这种有限采用的一个重要因素是开发这些插件所需的巨额投资。由于需要大量的时间和财务资源，协议团队通常会避免创建硬件钱包集成。开发、测试和维护这些专门的应用程序需要专门的工程技术人才，并且需要持续支持市场上每个硬件钱包，许多协议宁愿将这些资源分配给功能开发、流动性激励或其他增长计划。但是，此成本效益计算未能正确权衡盲签的关键安全影响。

EIP-7730 及以后的发展方向

幸运的是，一个有希望的解决方案即将出现。EIP-7730 代表了一项关键举措，旨在通过以最小的协议实施负担实现真正的“明文签名”来消除盲签。

这种方法大大提高了交易验证的效率。由于硬件设备可以通过关于显示什么以及如何显示的明确指令直接解析每条消息的内容，因此用户可以看到人类可读的信息，而不是加密乱码。想象一下看到以下技术数据：

uint256 amountIn: 500000000000000000
uint256 amountOutMin: 800000000
uint256 slippageBps: 100
uint256 deadline: 1715157000

在你的硬件钱包屏幕上转换为：将 0.5 ETH 兑换为最低 800 USDC（1% 滑点保护）- 有效期至 2024 年 5 月 8 日上午 8:30。 清晰度的这种改进通过将技术参数转换为用户实际理解的概念来实现真正知情的同意。

关键的安全优势在于，此信息出现在完全隔离的硬件设备上，不会因恶意软件而受到攻击，除非利用硬件钱包本身的漏洞。

用户可以更加确信他们在硬件钱包上看到的内容正是他们正在签署的内容。任何被破坏的供应链或工作站都无法篡改交易，而不会更改其语义描述。如果描述与他们的期望不符，他们可以简单地拒绝交易。

EIP-7730 颠覆游戏规则的原因在于开发人员实施起来非常简单。协议无需开发复杂的硬件钱包集成，只需提供一个 JSON 文件即可将其合约列入设备注册表的白名单。这种标准化的方法极大地降低了技术壁垒，从而阻碍了安全签名实践的广泛采用。从协议的角度来看，整个实施过程可以简单到提交一个带有适当 JSON 文件的拉取请求。

EIP-7730 的实际应用

为了演示 EIP-7730 的实施是多么简单，让我们逐步创建一个基本代币兑换功能的 JSON 清单。考虑以下来自 Uniswap V3 的 Solidity 函数：

function swapTokensForExactTokens(
    uint amountOut,
    uint amountInMax,
    address[] calldata path,
    address to,
    uint deadline
) external returns (uint[] memory amounts);

使用 EIP-712，用户将在其钱包上看到结构化的但仍然是技术性的数据：

Domain: Uniswap V3 Router 2
amountOut: 800000000
amountInMax: 800000000000000000000
path: [0xa0b86991c6218b36c1d19d4a2e9eb0ce3606eb48,\
0x6b175474e89094c44da98b954eedeac495271d0f]
to: 0x742d35Cc6634C0532925a3b8D5c5E3e7e7e7e7e7
deadline: 1715157000

虽然这比原始十六进制数据好，但用户仍然需要：

• 手动将 800000000 转换为 USDC 金额
• 将 800000000000000000 转换为 DAI 金额
• 查找代币地址以了解正在兑换哪些代币
• 将时间戳转换为可读日期
• 验证收件人地址与其钱包是否匹配

使用 EIP-7730，开发人员可以创建一个简单的 JSON 清单，将此技术数据转换为真正的人类可读格式。以下是步骤：

1. 克隆 clear-signing-erc7730-developer-tools repo
2. 转到 /developer-preview 目录
3. 使用 npm i 安装依赖项
4. 创建 JSON 文件并将其添加到注册表文件夹

{
    "context": {
        "$id": "Uniswap v3 Router 2",
        "contract": {
            "deployments": [\
                {\
                    "chainId": 1,\
                    "address": "0x68b3465833fb72A70ecDF485E0e4C7bD8665Fc45"\
                }\
            ],
            "abi": "https://github.com/LedgerHQ/ledger-asset-dapps/blob/211e75ed27de3894f592ca73710fa0b72c3ceeae/ethereum/uniswap/abis/0x68b3465833fb72a70ecdf485e0e4c7bd8665fc45.abi.json"
        }
    },

    "metadata": {
        "owner": "Uniswap",
        "info": {
            "legalName": "Uniswap Labs",
            "url": "https://uniswap.org/"
        }
    },

    "display": {
        "formats": {
            "0x42712a67": {
                "$id": "swapTokensForExactTokens",
                "intent": "Swap tokens",
                "fields": [\
                    {\
                        "path": "amountOut",\
                        "label": "Amount to Receive",\
                        "format": "tokenAmount",\
                        "params": {\
                            "tokenPath": "path.[-1]"\
                        }\
                    },\
                    {\
                        "path": "amountInMax",\
                        "label": "Maximum Amount to Send",\
                        "format": "tokenAmount",\
                        "params": {\
                            "tokenPath": "path.[0]"\
                        }\
                    },\
                    {\
                        "path": "to",\
                        "label": "Recipient of the output tokens",\
                        "format": "addressName",\
                        "params": {\
                            "sources": ["local"]\
                        }\
                    },\
                    {\
                        "path": "deadline",\
                        "label": "Valid until",\
                        "format": "date"\
                    }\
                ]
            }
        }
    }
}

5. 使用 npm run dev 在本地运行

用户现在看到：

图3：实施 EIP-7730 的 Ledger 上的 UX

6. 将 JSON 添加到官方存储库

整个实施过程包括创建此 JSON 文件并将其提交到注册表。没有复杂的集成，没有自定义硬件钱包开发，只有一个简单的清单，可以使你协议的交易具有人类可读性。

这种方法可以扩展到任何协议的复杂性，同时保持相同的简单实现模式，从而使生态系统中每个 dapp 都可以进行安全签名。

立即实施 EIP-7730

在你的协议中消除盲签的途径现在非常简单且易于访问。作为 dapp 开发人员，你只需花费几个小时的实施工作即可显着提高用户的安全性和体验。

入门很简单：

1. 使用 Ledger 的开发工具：Ledger 开发了一个全面的工具，可简化 JSON 清单的创建，网址为 https://get-clear-signed.ledger.com/。此工具将指导你完成整个过程，使 EIP-7730 的实施即使对于没有广泛加密专业知识的团队也可以访问。
2. 提交你的集成：准备好 JSON 清单后，创建一个拉取请求以将其添加到 Ledger 注册表存储库：https://github.com/LedgerHQ/clear-signing-erc7730-registry。此中心化注册表可确保可发现性，同时保持安全标准。请注意，注册表所有权将在未来过渡到基金会运营的模式，类似于以太坊链 ID 列表，从而在去中心化和可发现性之间取得最佳平衡。
3. 专业审查流程：提交后，Ledger 的安全团队将在几天内审查你的清单。此审查可确保你的实施准确地表示交易数据，而不会隐藏关键信息或使用具有误导性的术语。只有非恶意、正常运行的清单才能获得批准。
4. 启动明文签名：批准你的清单后，明文签名功能将立即用于你的协议。你的用户将在其硬件钱包上看到人类可读的交易详细信息。

就这样！你已经通过消除盲签带来的焦虑和恐惧来改变了用户的体验，从而将他们的 Web3 体验从不确定性转变为真正的信心。

虽然 EIP-7730 通过消除盲签显着提高了交易安全性，但黑客最直接的攻击媒介仍然是利用智能合约本身的漏洞。即使具有完美的交易透明度，如果底层协议包含安全缺陷，用户仍然可能会损失资金。

如果你不确定你的智能合约安全状况，Trail of Bits 可以为你提供帮助。我们的团队已经审核了数百个 DeFi 协议，可以在漏洞在生产中被利用之前识别它们。联系我们以了解我们如何帮助你将安全性构建到你的协议中，同时实施 EIP-7730 以实现全面的用户保护。

1 来源：Ledger Live 应用程序 (2025 年 6 月 6 日)

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