Uniswap 团队在去年十一月的时候公布了两个新合约，在 DEX 生态中抛出了一个新的组合，试着透过一站式的高度整合提供更好的用户体验，其中 Permit2 合约是达成这个目标的一个重要基础，本文将针对 Permit2 的设计与实作进行探讨。
ERC20 授权痛点
用户在面对新的 Dapp 时，通常会面临以下几个关于 ERC20 代币授权的痛点
每个 Dapp 及每个 Token 都需要独立授权，意味着用户要发送授权交易到区块链，步骤繁琐且消耗手续费
为求方便，每次授权通常都给最大值 (uint256 max)
Dapp 合约若有漏洞被开采，用户需要尽快 revoke 授权，否则可能会丢失资产
为了解决上述问题，开发者提出 EIP-2612 使用 Permit 签名的形式来取代呼叫 approve()，此设计可以有效解决以上痛点，但许多市场主流的代币已经相当古老，而且合约是不可升级的设计，因此该方式并没有办法立即解决眼前的议题。
然而事情其实还是有转圆的馀地，虽然原生的代币不支援 permit，但如果能够先授权给一个独立的新合约，由该合约来做 permit 签章验证，那麽是否就达到了相同的目的？于是有了 Permit2 的诞生。
Permit2 — 外挂式的 Permit
Uniswap 的 Permit2 合约最主要的目是在解决 ERC20 授权的痛点，同时兼容无法升级的老旧代币合约。作法上主要是以一个外挂式的 permit 合约来实现，并具备以下特色
支援任意 ERC20 token，不论该 Token 本身是否支援 permit
支援 EIP-1271，合约钱包能够验证签章
支援 batch 呼叫
透过 nonce 机制允许用户 cancel 已经签出去的 pending permit
Permit2 实作
Permit2 继承了两个子合约，分别为 SignatureTransfer 及AllowanceTransfer。用户最一开始需要先授权代币给 Permit2 合约，而未来的代币转帐就可以由 Permit2 来进行验签及管理。
Permit2 定义了签章内容的各式资料结构，原则上都与 EIP-2612 中所定义的栏位大同小异，因此不另外做介绍。
SignatureTransfer (signature-based transfers)
用户可以提供一次性的转帐 permit 签章给 Dapp 使用，Dapp 合约呼叫 Permit2 进行转帐时夹带用户的 permit 签章，这类的场景即是由 SignatureTransfer 负责。
合约介面主要就是带入 transfer 相关参数以及 permit 签名，值得一提的是 witness 这个栏位，实际作用是一个保留给 Dapp 使用的签章栏位，可用于区分订单 id 或者是 swap hash，避免 permit 被恶意抢跑，例如我签了 100 USDC 的 permit 目的是想要 swap 换成 WETH，结果一个攻击者拿着我的 permit 签章执行了另一个 USDC <-> DOGE 的 swap。这部分主要看串接合约的实作逻辑来决定要如何利用 bytes32 witness 这个栏位。
AllowanceTransfer (signature-based approvals)
transfer with permit 的使用场景需要用户每一次都在线做 permit 签名，不过这样在线的要求对于有些应用场景并不适合，因此 Permit2 仍支援原本 ERC20 授权的使用场景，也就是用户先授权一个额度，拥有授权的合约可以直接呼叫 transferFrom()，而 AllowanceTransfer 作法上的差异主要是用户可以不用发交易呼叫 approve()，而是透过签章验证的方式来做额度授权。
介面的设计其实类似于 EIP-2612 的概念，除了基本的授权与转帐以外，也支援 cancel 以及归零的呼叫。
/// @notice legacy ERC20 approve function
function approve(address token, address spender, uint160 amount, uint48 expiration) external;
/// @notice approve with permit (single/batch)
function permit(address owner, PermitSingle memory permitSingle, bytes calldata signature) external;
function permit(address owner, PermitBatch memory permitBatch, bytes calldata signature) external;
/// @notice legacy ERC20 transferFrom function (single/batch)
function transferFrom(address from, address to, uint160 amount, address token) external;
function transferFrom(AllowanceTransferDetails[] calldata transferDetails) external;
/// @notice set allowance amount to zero
function lockdown(TokenSpenderPair[] calldata approvals) external;
/// @notice overwrite nonce to cancel pending permits
function invalidateNonces(address token, address spender, uint48 newNonce) external;
Uniswap 主导优势
其实类似于 Permit2 的设计概念存在许久，也有被一些 DEX 采用，不过 Permit2 在一开始的设定就是希望能成为代币授权的託管合约，并且能够广泛被各个 Dapp 串接使用，要能达成这个目的的前提是能够得到多数用户的信任与授权，而 Uniswap 在行业裡的角色实质上是有能力做到这样的号召力，一同发表的 Universal Router 就已经整合了 Pertmi2 合约，换句话说，用户若要使用新的 Universal Router，就需要先授权 Permit2 合约，拥有越多用户的代币授权，则越能够吸引其他 Dapp 来串接。
除此之外，若要乘载大量用户的代币授权，合约安全势必是一大信任的关键，Permit2 承袭了 Uniswap 的风格，采用不可升级的设计，同时由 Chainsecurity 与 ABDK 完成审计，并且附上完善的文件与 SDK，也发布了 bounty program，是相当成熟的开源合约。
过去 CEX 託管了用户的资产，有鉴于近期 FTX 事件及一连串的连锁效应，许多用户开始对中心化託管产生了不信任，而此时对于握有用户 token approval 的 DEX 则是绝佳的发挥机会，我认为，让用户跳脱传统中心化託管的模式，同时与用户体验及成本取得一个平衡，是 DEX 往下发展的一个重要的基石。
