为了更好地阅读本文，你需要先了解授权等基本概念。
阅读这篇文章「一文了解代币授权」进行了解。
Permit2 授权简介
Permit2 是 Uniswap 去年发布的授权标准，用于改善传统的 ERC20 代币授权体验，相比 ERC20 授权，更节省 Gas、更安全、更方便管理。本文我们将通过对比传统授权、Permit 授权和 Permit2 授权，探索更详细的 Permit2 的优势和风险所在。
传统授权 VS Permit2 授权
传统授权模式
1. Approve 模式
传统授权通常使用 Approve 方法，要求用户分别进行两步操作：授权和执行。基于 ERC20 标准，Approve 方法使用户能够设定代币的最大转移额度。这样，第三方应用在获得用户授权后，可以转移不超过该设定额度的代币。其中，用户授权和代币转移均为链上交互，需要消耗 Gas 费。
但是，用户在使用新 DApp 进行 Approve 授权时，通常会面临以下痛点：
- 用户体验差：每个 DApp 和 Token 都需要独立授权，意味着用户要将授权交易发送到区块链，步骤繁琐又耗费 Gas 费。
- 最大授权引发安全隐患：为避免反复授权，DApp 通常要求用户授予最大转移权限。但这可能带来若协议被漏洞利用，授权的代币可能被全数取走的风险。
2. Permit 授权模式
为解决上述痛点，开发者推出了 Permit 签名。该方式需进行链下签名和执行两步操作，无需消耗 Gas，节约费用且高效。更重要的是，用户可以一次性设定授权额度和期限，有效应对了原有问题。
最常见的是 Dex 里的挂单功能，如 1inch 有一个 Fusion 功能，让用户对一个消息进行签名，这个消息包含了按某个价格出售多少代币信息，用户就可以在不支付 Gas 的情况下将代币委托给 1inch 处理，然后 1inch 会给用户想购买的币。
但是，Permit 签名需要代币合约实现 Permit 函数，而市场主流的代币已经相当古老，其智能合约是不可升级的设计，无法支持 Permit，因此该设计只能解决新的 ERC20 代币的授权问题，而对于绝大多数我们常用的代币并不可行。
为了解决这个问题，Uniswap 提出了 Permit2 的标准。
Permit2 授权模式
Permit2 签名有授权、链下签名和执行三步。
- 授权给 Permit2 合约：用户为 Permit2 合约授权（仅需首次使用时），后续便由其进行直接管理代币
- 链下签名授权：用户在链下签名，并传给智能合约
- 执行：智能合约验签后，Permit2 触发 transferFrom 完成转账
值得注意的是，用户只需为 Permit2 合约授权一次，后续与其他已集成 Permit2 的智能合约交互时，无需重复授权，只需要后续两步操作。同时，之前的没有实现 Permit 的代币现在通过 Permit2 也能通过签名进行授权。
该模式具有以下优点和风险：
优点
- 兼容任意 ERC20 代币，无论代币本身是否支持
- 在 Permit2 合约中实现统一的代币授权管理
- 授权时间和额度可控，且允许用户撤销待处理的签名许可
- 无需为每次交互重复授权
缺点
- 签名风险：与传统授权（Approve）相比，Permit2 使授权更依赖签名，对签名警惕性较低的用户可能会忽视其内容，增加钓鱼风险
- 签名展示问题：部分钱包可能不支持或不完整展示签名信息，进一步加大了用户误操作风险
- 旧代币钓鱼风险：先前不支持 Permit 的代币通过 Permit2 得以授权，虽方便但增加了钓鱼风险
- 授权时限变数：Permit2 允许设置授权有效期，但因其可自定义，所以实际安全性取决于使用 Permit2 的 DApp 设定
面对新风险，对于钱包来说，不仅需要可以解析 Permit 签名信息，为了避免钓鱼网站，也需要清晰展示来源网站，通过 Logo 和 URL，帮助用户判断是否经过社区认证，是不是未知风险的网站。imToken 2.13.0 版本已支持该功能，可以更新体验。
对于用户，切记不要随意打开来源不明的网站进行操作；确保在官方 DApp 进行交互；谨慎设定授权数量；定期检测授权情况。