Permit 函数（EIP-2612）

什么是 Permit 函数（EIP-2612）？

Permit 函数由 EIP-2612 定义，是 ERC-20 代币的一项扩展。它允许代币所有者通过签署链下消息来授权支出方，而不必另外发送链上授权交易。

在加密货币领域，这项功能十分重要，因为它能让代币授权流程更顺畅、成本更低，也更容易与其他智能合约操作结合。

官方EIP-2612 规范说明，该标准为 ERC-20 增加了一个名为

的新函数。该函数通过签名消息（而非 ）修改 allowance 映射。

简单来说，EIP-2612 允许用户在钱包中签署消息，以此表示：“我授权这个智能合约使用一定数量的我的代币。”

之后，其他账户或合约可以将这份已签署的授权提交到链上。

这意味着代币所有者不必亲自发送授权交易。

这也意味着，代币所有者可能不必仅仅为了授权 ERC-20 代币支出而持有该链的原生 Gas 代币。

Permit 函数本身不会转移代币。

它只会设置 allowance，之后可通过

或其他会使用已授权额度的合约流程来使用该额度。

这一区别至关重要，因为授权支出方与向其转账并不是一回事。

更准确地说，permit 是一种签名授权；提交签名后，它会在链上更新 ERC-20 的 allowance 状态。

Permit 函数要点

• • EIP-2612 为 ERC-20 代币增加了
    permit
    、
    nonces
    和
    DOMAIN_SEPARATOR
    。
  • Permit 函数允许用户通过链下签名授权 ERC-20 代币支出。
  • 签名消息遵循 EIP-712 类型化结构化数据规则。
  • permit 会修改 allowance，但本身不会转移代币。
  • Nonce 可防止同一份 permit 签名被重复使用。
  • 截止时间会限制已签署的 permit 有效时长。
  • Permit 可改善用户体验，但不会消除授权风险或签名钓鱼风险。

EIP-2612 的创建原因

ERC-20 代币采用一种授权机制，允许一个地址授权另一个地址代其支出代币。

原始的 ERC-20 标准定义了

、 和 等函数。

这种授权机制使代币能够在钱包、智能合约、支付系统、交易界面、借贷协议、质押合约以及其他去中心化应用中重复使用。

但是，常规 ERC-20 授权流程通常需要两笔链上交易。

第一笔是

授权交易。

第二笔是实际使用已授权代币的智能合约操作。

这会给用户带来不便：用户需要支付两次 Gas、等待两次确认，并理解两个不同的钱包提示。

此外，持有 ERC-20 代币、却没有足够原生 Gas 代币来提交授权交易的用户也会遇到问题。

EIP-2612 通过支持签名授权来解决这一特定问题。

代币所有者在链下签署 permit，之后由其他方将其提交到链上。

这样，智能合约流程就能更高效地结合授权和实际操作。

例如，用户可以签署 permit，然后由合约在单笔交易流程中使用该 permit 并转移代币。

这并不意味着网络层面的交易免费。

仍然有人需要支付 Gas，才能将 permit 提交到链上。

其优势在于，支付 Gas 的人不一定是代币所有者。

Permit 函数的工作原理

EIP-2612 的核心函数形式如下：

。

是签署授权的代币持有者。

是将获得 allowance 的地址。

是获准支出的代币数量。

是 permit 可使用的最晚时间。

、 和 是加密签名的组成部分。

提交 permit 时，代币合约会检查签名是否有效。

合约还会检查截止时间是否已过。

合约会检查签名消息中的 nonce 是否与所有者当前的 nonce 匹配。

如果所有必要检查均通过，合约就会将

设置为获准额度。

随后，合约会递增所有者的 nonce，确保同一份签名无法重复使用。

合约还会触发

事件，使该流程符合 ERC-20 授权机制的预期。

这一流程将钱包签名转化为链上的 allowance 更新。

EIP-2612 的 3 个主要函数

EIP-2612 要求符合标准的代币在 ERC-20 基础上增加 3 个函数。

第一个是

。

函数会验证已签署的授权并更新 allowance。

第二个是

。

函数会返回某个所有者地址当前的 nonce。

第三个是

。

函数会返回 EIP-712 域分隔符，用于将签名限定到特定代币合约和签名域。

这 3 个函数相互配合。

permit 签名用于定义授权内容。

Nonce 用于防止重放。

域分隔符有助于将签名绑定到正确的合约和链环境。

如果缺少这些配套机制，permit 签名就更容易被滥用或在错误的环境中重放。

什么是 Allowance？

Allowance 是所有者授权支出方使用的 ERC-20 代币数量。

例如，如果 Alice 授权某个智能合约支出 100 个代币，那么 Alice 对该智能合约的 allowance 就是 100 个代币。

之后，支出方可以调用

，根据代币合约和应用流程转移不超过获准额度的代币。

Permit 函数不会取消 allowance 机制。

它改变的是创建 allowance 的方式。

EIP-2612 不再要求代币所有者直接调用

，而是允许所有者签署一条消息，授权更新 allowance。

这种方式在保留熟悉的 ERC-20 allowance 模型兼容性的同时，提升了易用性。

用户仍应谨慎管理 allowance，因为获批的支出方可能在获准额度内转移代币。

无限额 permit 授权虽然方便，但如果支出方合约存在恶意行为、遭到入侵或被用户误解，也可能导致重大损失。

Permit 函数与 Approve 函数

传统的

函数由代币所有者通过链上交易直接调用。

Permit 函数则由代币所有者通过链下签名授权，之后由其他方提交到链上。

使用

时，代币所有者必须为授权交易支付 Gas。

使用

时，代币所有者只需签署消息，之后可由中继者、应用或支出方支付 Gas 并提交该消息。

使用

时，授权操作会直接与 关联。

使用

时，授权操作则与所有者经过验证的签名关联。

两者最终可能产生相同的 allowance 更新，但用户体验有所不同。

因此，EIP-2612 常被描述为支持免 Gas 授权。

更准确地说，它允许代币所有者无需亲自发送授权交易。

区块链仍然需要交易和 Gas 才能更新状态。

EIP-712 对 Permit 的重要性

EIP-2612 使用基于 EIP-712 的类型化结构化数据。

EIP-712 是一种对结构化数据进行哈希和签名的标准，避免用户签署难以理解的字节字符串。

这很重要，因为钱包用户需要了解自己签署的内容。

原始十六进制签名请求可能令人困惑，也可能带来危险。

类型化签名可以更清晰地显示 owner、spender、value、nonce 和 deadline 等字段。

EIP-712 还使用域分隔符。

域分隔符有助于区分不同的签名环境。

对于 EIP-2612，域通常包含代币名称、版本、链 ID 和验证合约地址等信息。

这种设计有助于防止用于某个代币或链的签名在其他环境中生效。

EIP-712 本身指出，它并不单独提供重放保护。

EIP-2612 通过每个所有者各自的 nonce 增加了重放保护。

Nonce 与重放保护

Nonce 是一个只使用一次的数字。

在 EIP-2612 中，代币合约会跟踪每个所有者地址的 nonce。

用户签署 permit 时，签名数据会包含所有者当前的 nonce。

permit 成功使用后，代币合约会递增该 nonce。

如果有人尝试再次提交同一份 permit，nonce 就不再匹配。

因此，重复使用的签名会失效。

Nonce 保护至关重要，因为签名可能被复制。

如果没有 nonce 保护，支出方或攻击者可能会重复使用同一份已签署的 permit。

可靠的 permit 实现必须将 nonce 纳入签名消息，并且只在 permit 成功后更新 nonce。

对用户而言，实际含义很简单。

有效的 permit 签名应只能使用一次，而不是永久有效。

截止时间与签名过期

参数会限制 permit 签名的可用时长。

如果当前区块时间戳晚于截止时间，permit 就应当失效。

这可以避免旧签名在用户原本无意授权的很久以后仍被提交。

较短的截止时间可缩短提交时间窗口，从而降低风险。

较长的截止时间则更方便，因为签名可使用更久。

无限期或非常遥远的截止时间可能带来风险，因为除非签名已被使用、失效或通过 nonce 机制被替换，否则该签名授权可能会长期有效。

钱包显示类型化 permit 数据时，用户应留意截止时间。

除非有明确理由，开发者应避免设置过宽的截止时间。

应用应以用户能够理解的方式说明截止时间的含义。

域分隔符与链环境

域分隔符是 EIP-712 签名的重要组成部分。

对于 EIP-2612，它有助于将 permit 绑定到特定代币合约和域。

常见的域会包含代币名称、代币版本、链 ID 和验证合约地址。

这可以降低针对一个合约签署的 permit 被重放到另一个合约上的风险。

它也能降低在一条链上签署的 permit 被用于另一条链的风险。

不过，域分隔符的安全性取决于实现是否正确。

如果代币合约使用不完整的域分隔符，重放风险可能会增加。

如果链 ID 发生变化，或合约部署在多个网络上，开发者必须仔细考虑如何区分签名。

对用户而言，域分隔符通常隐藏在钱包界面之后。

对开发者而言，这是安全实现 permit 时最重要的细节之一。

免 Gas 授权说明

“免 Gas 授权”这一说法可能令人困惑。

EIP-2612 不会让 Ethereum 或 EVM 交易变成免费交易。

它允许代币所有者通过签署消息授权支出，而不必发送交易。

之后，中继者、应用、智能合约或支出方可以将已签署的 permit 提交到链上并支付 Gas。

这对持有 ERC-20 代币、但没有足够原生 Gas 代币来授权代币支出的用户有所帮助。

它也能帮助应用实现更顺畅的单步操作体验。

例如，用户可以签署 permit，然后完成充值、支付或代币操作，而无需先手动发送单独的授权交易。

用户体验看起来更简单，但区块链仍会通过链上交易记录状态变更。

开发者应清楚说明这一点，否则用户可能会误以为签名消息不会产生任何后果。

有人提交 permit 后，签名就可能产生实际的链上后果。

EIP-2612 在加密领域的常见用途

EIP-2612 常用于去中心化金融和代币应用。

借贷协议可以使用 permit，让用户在一个流程中授权并存入抵押品。

质押合约可以使用 permit，让用户无需单独发送授权交易即可授权质押代币。

支付应用可以使用 permit，让付款人通过更顺畅的结账流程授权代币转移。

钱包可以使用 permit，减少常见 ERC-20 操作所需的交易步骤。

中继服务可以代用户支付 Gas，并通过其他方式收回费用。

智能合约可以将 permit 与

结合起来，使授权和代币转移在同一交易流程中完成。

这种模式可以减少用户操作失败的情况，因为无需先单独挖出授权交易再执行主要操作。

它也能减少困惑，因为应用可以引导用户完成一个组合流程。

其主要优势不只是节省 Gas。

更重要的是，它降低了代币授权的操作门槛。

Permit 函数与账户抽象

有时会将 Permit 函数与账户抽象一同讨论，因为两者都能改善钱包用户体验。

Permit 允许 ERC-20 代币所有者通过签名授权更新 allowance。

账户抽象旨在让加密账户更具可编程性和灵活性。

它们是不同的工具，但目标相似。

两者都试图降低区块链交互的门槛。

Permit 专注于代币授权。

账户抽象则更广泛地关注账户如何授权操作以及如何支付操作费用。

加密应用可以在同一产品设计中使用这两种方案。

例如，钱包或智能账户系统可以支持交易赞助，同时使用兼容 permit 的代币授权。

用户不必了解每个技术层，但开发者必须正确实现各个层。

Permit 函数的安全风险

对用户影响最大的风险是签名钓鱼。

恶意网站可能要求用户签署一份授权危险支出方的 permit。

由于 permit 签名并非普通的代币转账，有些用户可能会误以为它无害。

这种想法很危险。

Permit 可以授权支出方之后转移代币。

签署前，用户应查看支出方地址、代币数量、代币名称和截止时间。

对于内容不清楚、出乎意料或由未知网站提出的签名请求，用户应拒绝。

另一项风险是无限额授权。

如果用户签署的 permit 额度非常大，支出方就可能获得该代币 allowance 的广泛支出权限。

第三项风险是实现错误。

如果代币合约未正确处理 nonce、域分隔、签名恢复或截止时间，签名就可能被重放，或在本应失效时仍被接受。

第四项风险是用户界面造成的困惑。

如果钱包没有清晰显示类型化数据，用户可能会签署自己并不理解的授权。

Permit 提升了易用性，但也让签名安全教育更加重要。

Permit 不会消除授权风险

EIP-2612 改变了授权方式，但并未改变授权支出方所带来的基本风险。

如果支出方是恶意的、遭到入侵，或获得了过多 allowance，用户仍可能损失代币。

Permit 授权的权限可能与普通

交易同样大。

区别在于，授权最初以签名形式产生，而不是由代币所有者发送交易。

因此，用户应像谨慎对待授权交易一样谨慎对待 permit 签名。

除非用户完全信任支出方并了解相关风险，否则应避免签署无限额 permit。

不再需要的 allowance 应予以撤销。

用户可以使用不同钱包分别进行高风险 dApp 交互和长期持有。

授权有价值的代币前，用户应通过可信来源核实合约地址。

Permit 与抢先交易

任何持有 permit 签名的人都可以提交该签名。

因此，使用 permit 时需要特别考虑抢先交易。

如果用户签署 permit 并将其发送给某个应用，看到该签名的其他方可能会抢先提交。

很多情况下，这只会消耗该 permit，并设置用户原本希望设置的相同 allowance。

但是，如果应用预期 permit 与另一项操作同时执行，抢先提交 permit 可能会导致之后的组合交易失败，因为 nonce 已经改变。

开发者应设计能够妥善处理这种情况的流程。

智能合约通常可以检查预期 allowance 是否已经可用；如果可用，就继续执行，而不是无故失败。

用户界面也应清楚说明 permit 流程失败的原因。

用户需要记住，已签署的 permit 在使用或过期前都可以被转交使用。

除非信任相关流程，否则不要分享已签署的 permit 数据。

开发者实施注意事项

开发者应严格遵循 EIP-2612 规范。

permit 类型哈希应与预期的签名结构一致。

摘要应使用 EIP-712 编码，并包含域分隔符和 permit 结构体哈希。

合约应拒绝已过期的 permit。

合约应拒绝无效签名。

如果恢复出的签署者不是所有者，合约应拒绝该 permit。

合约应拒绝不适当的零地址所有者情形。

permit 成功执行后，合约应递增所有者的 nonce。

Allowance 更新后，合约应触发标准

事件。

在可行的情况下，开发者应使用经过充分审查的库。

OpenZeppelin 的 ERC20Permit 文档提供了 Solidity 项目中广泛使用的一种实现模式。

OpenZeppelin 也记录了其他环境中的 ERC-20 Permit 用法，例如 Stylus 的 ERC-20 Permit。

即使使用库，开发者仍应仔细测试代币的具体行为。

Permit 函数与元交易

元交易是一种更广泛的模式：用户签署消息，然后由其他方代用户提交交易。

EIP-2612 可视为一种专注于授权的特定签名模式。

它并未将所有代币操作都扩展为签名操作。

它只为 ERC-20 allowance 的签名授权制定了标准。

这种有限的适用范围是有意为之。

较为精简的标准更容易采用，也更便于在钱包、合约和应用之间集成。

如果开发者需要签名转账、批量操作或自定义 Gas 赞助，可能还需要其他合约或标准。

Permit 之所以实用，是因为它解决了一个常见问题，同时不必改变整个 ERC-20 模型。

它可以补充元交易系统，而不是取代所有此类系统。

Permit 函数与代币转账

Permit 不是转账。

转账会将代币从一个地址转移到另一个地址。

Permit 会更新一个地址授予另一个地址的 allowance。

这意味着，用户签署 permit 后，代币仍可留在同一个钱包中，直到支出方使用该 allowance。

实际代币转移通常通过

完成。

这一区别关系到钱包安全。

用户签署 permit 后，可能不会立即看到代币余额发生变化。

这并不意味着该签名没有风险。

支出方之后仍可能有权转移代币。

使用 dApp 后，用户应查看当前有效的 allowance，并撤销不再需要的授权。

Permit 函数与 Permit2

EIP-2612 是代币级标准。

代币合约本身必须实现 permit 函数，该代币才支持 EIP-2612。

其他授权系统可能通过外部合约提供类似 permit 的功能。

这些系统不等同于原生支持 EIP-2612。

这一区别很重要，因为钱包提示、支出方地址、nonce 系统、授权范围和撤销方式都可能不同。

签署类似 permit 的授权时，用户应确认哪个合约将获得权限。

集成 permit 时，开发者应确认代币是否直接支持 EIP-2612，还是需要使用其他授权机制。

将所有签名授权都称为“EIP-2612”可能造成混淆。

EIP-2612 有特定的接口和签名结构。

用户应如何阅读 Permit 签名提示

用户应先检查代币名称。

然后检查支出方地址或请求权限的应用。

接着检查获批额度。

确认额度有限，还是实际上没有上限。

检查截止时间。

确认该请求是否是在自己主动操作后出现。

如果请求是意外出现的，应予以拒绝。

如果网站连续要求签署多份消息，应格外谨慎。

不要签署来自私信链接、虚假客服聊天、可疑广告或未知代币页面的 permit 消息。

请记住，签署 permit 可能赋予另一个地址支出代币的权限。

安全的钱包提示应清晰显示这些字段，但用户不应只依赖界面设计。

Permit 如何改善用户体验

Permit 通过减少所需的链上交易数量来改善用户体验。

它可以省去许多 dApp 流程中的单独授权步骤。

即使用户没有足够的原生 Gas 代币来单独发送授权交易，也可能通过它使用 ERC-20 代币。

它可以帮助应用赞助 Gas，或将授权与其他操作打包处理。

它可以减少用户授权代币后忘记完成第二笔交易所导致的操作失败。

它可以让刚接触链上应用的用户更顺畅地完成入门操作。

这些优势尤其重要，因为 ERC-20 授权是加密领域最常见的操作障碍之一。

不过，授权流程更顺畅并不意味着授权默认更安全。

良好的用户体验还需要清晰的签名提示、谨慎的支出方设计以及便捷的 allowance 管理方式。

使用 EIP-2612 时的常见错误

一个常见错误是认为 permit 会立即转移代币。

Permit 只会更新 allowance。

另一个常见错误是认为免 Gas 授权意味着无人需要支付 Gas。

Permit 仍需要链上交易来更新合约状态。

第三个常见错误是在不了解支出方风险的情况下签署无限额授权。

第四个常见错误是忽略截止时间字段。

第五个常见错误是仅仅因为签名请求看起来不像普通交易，就认为它值得信任。

第六个常见错误是认为所有 ERC-20 代币都支持 EIP-2612。

第七个常见错误是在集成 permit 时，没有针对不同部署测试链 ID、域分隔符和 nonce 行为。

第八个常见错误是认为所有类似 permit 的系统都与 EIP-2612 完全相同。

第九个常见错误是在组合合约流程中，没有处理 permit 被抢先提交的情况。

第十个常见错误是以用户无法理解的方式显示 permit 提示。

用户最佳实践

只在信任的网站和应用上签署 permit 消息。

签署前检查代币、支出方、额度和截止时间。

除非有充分理由，否则避免无限额授权。

尽可能使用较小的授权额度。

撤销不再需要的旧 allowance。

不要签署来自随机链接、虚假客服消息或未知空投页面的 permit 消息。

使用一个钱包进行实验性 dApp 操作，另一个钱包用于长期持有。

仔细查看钱包警告。

不要因为签名没有直接显示 Gas 费用，就认为它是安全的。

请记住，其他人可以在签名过期前提交已签署的 permit。

开发者最佳实践

尽可能使用经过审计且维护良好的 permit 实现。

如果要声称支持 EIP-2612，就应严格遵循其官方接口。

使用 EIP-712 类型化数据，以便钱包清晰显示签名信息。

正确实现域分隔。

按所有者地址跟踪 nonce。

拒绝过期签名。

拒绝无效签署者以及所有者为零地址的情形。

Allowance 更新成功后触发

事件。

设计组合 permit 流程时，应能处理 permit 在主交易之前已被提交的情况。

以通俗易懂的方式向用户显示支出方名称、代币数量和到期详情。

提供清晰的文档，说明用户如何撤销 allowance。

针对不同链 ID、分叉、升级和钱包服务商测试签名。

一句话了解 Permit 函数

EIP-2612 中的 Permit 函数允许 ERC-20 代币所有者通过 EIP-712 签名授权支出方，从而在所有者无需单独发送授权交易的情况下更新链上 allowance。

常见问题

EIP-2612 中的 Permit 函数是什么？

Permit 函数是 ERC-20 的一项扩展，允许代币所有者通过链下签名授权支出方，之后其他方可以将该签名提交到链上。

Permit 会转移代币吗？

不会。Permit 只会设置 allowance，本身不会转移代币。

EIP-2612 有什么用？

EIP-2612 可减少授权操作的阻碍、实现免 Gas 授权体验，并允许应用将授权与其他智能合约操作结合。

使用 permit 时，代币所有者需要支付 Gas 吗？

代币所有者无需发送授权交易，但仍有人必须支付 Gas，才能将已签署的 permit 提交到链上。

Approve 和 permit 有什么区别？

Approve 是由代币所有者发送的链上交易；permit 则是链下签名，可由其他方提交到链上。

EIP-712 与 permit 有什么关系？

EIP-712 提供类型化结构化数据签名，有助于钱包更清晰地显示 permit 详情，并将签名绑定到指定域。

EIP-2612 中的 nonce 是什么？

Nonce 是每个所有者各自使用的数值，可防止同一份 permit 签名被重复使用。

Permit 中的截止时间是什么？

截止时间是 permit 签名的过期时间，超过该时间后签名就不应继续有效。

EIP-2612 安全吗？

正确实现和使用时，EIP-2612 可以是安全的，但用户仍须警惕签名钓鱼、无限额授权、恶意支出方和不清晰的钱包提示。

所有 ERC-20 代币都支持 permit 吗？

不支持。只有实现 EIP-2612 扩展的 ERC-20 代币才支持标准 Permit 函数。

Permit 签名可能被抢先提交吗？

可能。任何持有有效 permit 签名的人都可以在另一笔交易之前提交，因此开发者应设计能够处理这种情况的流程。

用户如何降低 permit 风险？

用户可以核查支出方、限制授权额度、设置较短的截止时间、避开可疑网站，并撤销不再使用的 allowance，以降低 permit 风险。

结语

EIP-2612 中的 Permit 函数是 ERC-20 授权体验方面一项非常实用的改进。

它允许用户通过签名授权代币 allowance，而不必发送单独的授权交易。

这可以减少 Gas 操作障碍、改善 dApp 新手引导、支持交易赞助流程，并让 ERC-20 操作更容易整合到一个用户流程中。

该标准依靠 EIP-712 类型化结构化数据、域分隔、nonce 和截止时间，让签名授权更安全且适用范围更明确。

不过，permit 并不会消除代币 allowance 的基本风险。

已签署的 permit 仍可能赋予支出方实际控制用户代币的权限。

用户应像严肃对待授权交易一样对待 permit 签名。

开发者应谨慎实现该标准，清晰显示签名信息，并妥善处理重放保护、过期签名和 permit 被抢先提交等边缘情况。

正确使用时，EIP-2612 可以让 ERC-20 代币更易使用，同时不改变基于 allowance 的代币支出这一核心机制。

这是一项规模不大却十分重要的标准，能够在兼容更广泛 ERC-20 生态的同时，提升加密应用的实际易用性。