签名：区块链钱包安全的新挑战
与传统的中心化服务不同，区块链钱包并不直接持有用户的资产，只管理与区块链交互的关键凭证——私钥。当用户进行一笔交易时，需要使用私钥进行交易签名，一旦私钥泄露或丢失，资产将面临损失的风险。
签名的现状
区块链的早期，签名相对简单且风险较低，钱包主要的安全问题在于如何安全地存储私钥。随着 DeFi 和 NFT 等应用场景的兴起，链上交互变得越来越复杂。由于每一个 DApp 项目都有独特的签名交互方式，再加上多链多网络的维度，对于大多数人来说，理解各种复杂的签名交互背后的信息变得困难。
这也导致了钱包安全的新挑战，本身签名的规范多，解析困难，把面向开发者的结构化数据解析为普通用户可以理解的信息的挑战更大，还存在因为签名展示的不清晰导致的各种潜在攻击手段，如盲签名和签名钓鱼等。就在最近，Web3 反诈骗平台 Scam Sniffer 监测到有用户通过因为 Perimit 授权被钓鱼攻击，导致被盗 10 万 USDC。
在探索签名挑战的解决方案之前，理解各种签名方式至关重要。
签名的方式
为了使各应用能与区块链无缝交互，如读取区块数据或发送交易，必须有一个统一的连接标准。拿以太坊举例，以太坊的每个客户端都采纳了统一的 JSON-RPC 规范。
在这个规范中，与签名相关的接口有：eth_sendTransaction、eth_sign 等。从技术的视角，签名可分为两大类：链下签名和链上签名。根据具体签名应用场景，它们又可细分为签名登录 、签名授权、签名转账及签名合约互动等。
如何避免签名风险
不同的签名场景潜藏着不同的风险，特别是当签名过程复杂或不明确时，盲目签名可能导致资产损失。对钱包而言，「所见即所签」是解决盲签问题的关键原则，用户签署的内容应与他们所看到和预期的完全相符。为了实施这一原则，钱包要确保的是准确展示每一笔签名包含的可读信息，而不是向用户展示 16 进制的 RLP 编码，只有这样用户才能理解签名信息和风险。
此外，在非常规的操作中，智能的风险警示机制也至关重要。接下来，我们将分别针对这些场景，探讨潜在风险及其应对策略。
签名登录场景
1. eth_sign
以太坊最早的离线签名方式，目前已经不推荐使用。因为无法解析签名信息，非常容易被风险网站利用，伪造风险交易，而导致资产被盗。最简单方式，遇到无法解析展示的盲签名信息，直接拒绝签名，因为 eth_sign 签名无法做到所见即所签，所以社区衍生出 eth_personal_sign 和 EIP-712 等标准，让签名可视化。
2. eth_personal_sign
eth_personal_sign 是可读的离线签名方式，通常用于网站验证用户身份，签名登录网站，钱包需要清晰的展示签名的信息和来源网站的详情。为了展示更多的登录网站的信息，目前 ERC-4361「Sign In With Ethereum 」登录网络的标准支持范围也非常广，进一步提升了 eth_personal_sign 的安全性。
3. eth_signTypedData
遵循 EIP-712 标准，对于结构化数据进行 Hash 或签名，推荐离线签名的方式。慢雾有提到signTypedData_v4 也存在潜在的安全问题，虽然签名信息展示很清晰，但可能是钓鱼网站发起的一模一样的签名请求，后续会被滥用。
所以，对于钱包来说，不仅要支持解析 signTypedData 结构化数据，还需要显示签名来源的应用名称和 URL、交互的历史记录。对于非标准的 EIP-712 钱包，应该也有智能的风险提示。
签名转账场景
转账是钱包最大的用例，这中间涉及到以太坊原生代币 ETH 的转账，以及 ERC-20、ERC-721 标准的代币转账，像是慢雾开发的 MistTrack 等其他安全工具有提供相关的风险地址标签，需要钱包智能地帮助用户拦截或展示相关风险提示，避免更多人受骗。
除此之外，转账还存在一些非常规的场景，比如说转账到合约地址：正常钱包转账都是给 EOA 普通账户，如果收款地址为合约地址，需要特别注意，往往存在风险，当然也可能为合约钱包地址。对于钱包来说，如果可以智能的识别地址是普通地址还是合约地址，并针对合约地址增加特别的标签提示，可以帮助用户提高安全意识。
签名授权场景
1. Approve 授权
Approve 操作代表授权代币转账权限给目标合约以便自动完成交易，常用于 DEX 交易授权，对于钱包来说，需要支持展示授权详情，并且支持修改授权额度和时间，避免因为无限授权额度，导致资金风险敞口变大，建议每次只授权需要交易的数量。
针对 Approve 授权是给一个 EOA 个人地址的场景，需要注意此操作存在极高的钓鱼诈骗行为，Approve 更多是授权给智能合约地址，授权给个人地址属于非常规的行为，需要钱包能够智能识别这种场景并提供相关的风险提示。
2. Permit 授权
Permit 是在 EIP-2612 中提出的一个优化方案，用于改进 ERC-20 标准代币的交互方式。使用ERC-20 标准下进行 Approve 代币授权，需要支付 ETH 作为 Gas 费用。而通过 Permit 的方法，用户可以在链下私钥授权生成一个签名，拥有这个签名的人（如智能合约）可以直接调用 Permit 功能，从而进行代币转移，无需用户再支付 Approve 授权的 Gas 费用。
然而，EIP-2612 是 ERC-20 的扩展，所以 Permit 功能仅适用于新代币，现有的 ERC-20 代币无法从中受益。为了解决这个问题，Uniswap 提出了 Permit2 的标准，思路调用 ERC-20 Approve 来授权 Permit2 合约的操作权限。
慢雾提到，Permit 比 Approve 授权钓鱼更加危险，毕竟只要窃取到了签名就获得了授权。例如 DEX 里的挂单功能，只需要用户对某个消息进行签名，用户就可以在不支付Gas 的情况下将资产委托给 DEX 处理，但如果这个 DEX 是个钓鱼网站，伪造了恶意消息让用户签名，用户的资产就有可能丢失。Permit 签名作为链下行为，用户也很难注意到自己的签名是否已经泄露。
对于钱包来说，不仅需要可以解析 Permit 签名信息，为了避免钓鱼网站，也需要清晰展示来源网站，通过 Logo 和 URL，帮助用户判断其是否经过社区认证，是不是存在未知风险。
签名合约交互的场景
像是 Uniswap、Sushi、Tokenlon、OpenSea 和跨链桥等常见 DApp ，钱包也需要支持所见即所签，可以展示交易完成后预计的代币数量增加和减少的变化情况，帮助用户判断该笔交互是否符合预期，也可以从根源避免出现零元购的风险。
最后
我们探讨了各种签名应用场景的潜在风险和应对策略，但值得注意的是，这只是冰山一角，实际上还有许多其他的风险尚未提及。
在区块链世界中，新的技术和应用不断涌现，带来了新的挑战和风险。无论是作为钱包开发者还是用户，都需要保持关注，理解并应对这些风险，以便更好地利用区块链技术带来的便利。