Hàm Permit (EIP-2612)

Hàm Permit (EIP-2612) là gì?

Hàm Permit, được định nghĩa trong EIP-2612, là phần mở rộng của token ERC-20, cho phép chủ sở hữu token phê duyệt một bên chi tiêu bằng cách ký thông điệp off-chain thay vì gửi một giao dịch phê duyệt on-chain riêng biệt.

Trong lĩnh vực crypto, tính năng này rất hữu ích vì giúp việc phê duyệt token thuận tiện, ít tốn kém và dễ kết hợp hơn với các thao tác khác của hợp đồng thông minh.

Đặc tả EIP-2612 chính thức giải thích rằng tiêu chuẩn này mở rộng ERC-20 bằng một hàm mới có tên

. Hàm này thay đổi ánh xạ allowance thông qua thông điệp đã ký thay vì thông qua .

Nói đơn giản, EIP-2612 cho phép người dùng ký thông điệp trong ví để xác nhận: “Tôi phê duyệt cho hợp đồng thông minh này chi tiêu số lượng token của tôi như đã chỉ định”.

Sau đó, một tài khoản hoặc hợp đồng khác có thể gửi yêu cầu phê duyệt đã ký đó lên on-chain.

Điều này có nghĩa là chủ sở hữu token không cần trực tiếp gửi giao dịch phê duyệt.

Chủ sở hữu token cũng có thể không cần nắm giữ token gas gốc của mạng chỉ để phê duyệt việc chi tiêu token ERC-20.

Bản thân hàm Permit không chuyển token.

Hàm này chỉ thiết lập allowance, sau đó allowance có thể được sử dụng bởi

hoặc một luồng xử lý khác của hợp đồng có sử dụng allowance đã phê duyệt.

Điểm khác biệt này rất quan trọng vì phê duyệt một bên chi tiêu không đồng nghĩa với việc gửi token cho bên đó.

Có thể hiểu permit là một ủy quyền đã ký, giúp cập nhật trạng thái allowance của ERC-20 on-chain sau khi chữ ký được gửi lên.

Điểm chính về hàm Permit

• • EIP-2612 bổ sung
    permit
    ,
    nonces
    và
    DOMAIN_SEPARATOR
    cho token ERC-20.
  • Hàm Permit cho phép người dùng phê duyệt việc chi tiêu ERC-20 bằng chữ ký off-chain.
  • Thông điệp đã ký tuân theo quy tắc dữ liệu có cấu trúc định kiểu của EIP-712.
  • Permit thay đổi allowance nhưng không tự chuyển token.
  • Nonce ngăn chữ ký permit bị sử dụng lại.
  • Deadline giới hạn thời gian hiệu lực của permit đã ký.
  • Permit cải thiện trải nghiệm người dùng nhưng không loại bỏ rủi ro phê duyệt hoặc rủi ro phishing chữ ký.

Vì sao EIP-2612 được tạo ra?

Token ERC-20 sử dụng mô hình phê duyệt, cho phép một địa chỉ ủy quyền cho địa chỉ khác chi tiêu token thay mặt mình.

Tiêu chuẩn ERC-20 ban đầu định nghĩa các hàm như

, và .

Mô hình phê duyệt này giúp token có thể được sử dụng với nhiều loại ví, hợp đồng thông minh, hệ thống thanh toán, giao diện giao dịch, giao thức cho vay, hợp đồng staking và các ứng dụng phi tập trung khác.

Tuy nhiên, quy trình phê duyệt ERC-20 thông thường thường yêu cầu hai giao dịch on-chain.

Giao dịch đầu tiên là giao dịch

.

Giao dịch thứ hai là thao tác thực tế của hợp đồng thông minh sử dụng các token đã được phê duyệt.

Điều này gây bất tiện cho người dùng vì họ phải trả phí gas hai lần, chờ hai lần xác nhận và xử lý hai yêu cầu riêng biệt trong ví.

Quy trình này cũng gây khó khăn cho người dùng có token ERC-20 nhưng không có token gas gốc cần thiết để gửi giao dịch phê duyệt.

EIP-2612 giải quyết vấn đề cụ thể này bằng cách cho phép phê duyệt thông qua thông điệp đã ký.

Chủ sở hữu token ký permit off-chain, sau đó một bên khác có thể gửi permit đó lên on-chain.

Nhờ vậy, luồng thao tác của hợp đồng thông minh có thể kết hợp bước phê duyệt và thao tác chính hiệu quả hơn.

Ví dụ, người dùng có thể ký permit, sau đó hợp đồng sử dụng permit đó và chuyển token trong một luồng giao dịch duy nhất.

Điều này không giúp giao dịch miễn phí ở cấp mạng lưới.

Vẫn có người phải trả phí gas để gửi permit lên on-chain.

Lợi ích là người trả phí gas không nhất thiết phải là chủ sở hữu token.

Hàm Permit hoạt động như thế nào?

Hàm cốt lõi của EIP-2612 có cấu trúc như sau:

.

là chủ sở hữu token ký phê duyệt.

là địa chỉ sẽ nhận allowance.

là số lượng token được phê duyệt để chi tiêu.

là thời điểm muộn nhất mà permit có thể được sử dụng.

Các giá trị

, và là những thành phần của chữ ký mật mã.

Khi permit được gửi lên, hợp đồng token sẽ kiểm tra tính hợp lệ của chữ ký.

Hợp đồng cũng kiểm tra xem deadline đã qua hay chưa.

Hợp đồng kiểm tra nonce trong thông điệp đã ký có khớp với nonce hiện tại của chủ sở hữu hay không.

Nếu tất cả điều kiện kiểm tra đều đạt, hợp đồng sẽ đặt

bằng giá trị đã phê duyệt.

Sau đó, hợp đồng tăng nonce của chủ sở hữu để chữ ký đó không thể được sử dụng lại.

Hợp đồng cũng phát ra sự kiện

, giúp hành vi này phù hợp với cách hoạt động phê duyệt dự kiến của ERC-20.

Quy trình này biến chữ ký ví thành một lần cập nhật allowance on-chain.

Ba hàm chính trong EIP-2612

EIP-2612 yêu cầu các token tuân thủ tiêu chuẩn bổ sung ba hàm bên cạnh ERC-20.

Hàm đầu tiên là

.

Hàm

xác minh một phê duyệt đã ký và cập nhật allowance.

Hàm thứ hai là

.

Hàm

trả về nonce hiện tại của một địa chỉ chủ sở hữu.

Hàm thứ ba là

.

Hàm

trả về dấu phân tách miền EIP-712, giúp gắn chữ ký với một hợp đồng token và miền ký cụ thể.

Ba hàm này phối hợp với nhau.

Chữ ký permit xác định nội dung phê duyệt.

Nonce ngăn chặn việc phát lại chữ ký.

Dấu phân tách miền giúp gắn chữ ký với đúng hợp đồng và ngữ cảnh blockchain.

Nếu thiếu các thành phần hỗ trợ này, chữ ký permit sẽ dễ bị sử dụng sai hoặc phát lại trong sai ngữ cảnh hơn nhiều.

Allowance là gì?

Allowance là số lượng token ERC-20 mà chủ sở hữu đã phê duyệt cho một bên chi tiêu sử dụng.

Ví dụ, nếu Alice phê duyệt cho một hợp đồng thông minh chi tiêu 100 token, allowance từ Alice cho hợp đồng đó sẽ là 100 token.

Sau đó, bên chi tiêu có thể gọi

để chuyển tối đa số token đã được phê duyệt, tùy thuộc vào hợp đồng token và luồng xử lý của ứng dụng.

Hàm Permit không loại bỏ hệ thống allowance.

Hàm này thay đổi cách tạo allowance.

Thay vì yêu cầu chủ sở hữu token trực tiếp gọi

, EIP-2612 cho phép chủ sở hữu ký thông điệp ủy quyền cập nhật allowance.

Cách này cải thiện tính tiện dụng mà vẫn tương thích với mô hình allowance quen thuộc của ERC-20.

Người dùng vẫn cần thận trọng với allowance vì bên chi tiêu được phê duyệt có thể chuyển token trong giới hạn cho phép.

Permit phê duyệt không giới hạn có thể thuận tiện, nhưng cũng có thể gây tổn thất lớn nếu hợp đồng của bên chi tiêu độc hại, bị xâm phạm hoặc bị người dùng hiểu nhầm.

Hàm Permit và hàm Approve

Hàm

truyền thống được chủ sở hữu token gọi trực tiếp thông qua một giao dịch on-chain.

Hàm Permit được chủ sở hữu token ủy quyền bằng chữ ký off-chain và sau đó một bên khác gửi lên on-chain.

Với

, chủ sở hữu token phải trả phí gas cho giao dịch phê duyệt.

Với

, chủ sở hữu token ký thông điệp, còn relayer, ứng dụng hoặc bên chi tiêu có thể trả phí gas để gửi thông điệp đó.

Với

, thao tác phê duyệt được gắn trực tiếp với .

Với

, thao tác phê duyệt gắn với chữ ký đã xác minh của chủ sở hữu.

Kết quả cập nhật allowance có thể giống nhau, nhưng trải nghiệm người dùng khác nhau.

Đây là lý do EIP-2612 thường được mô tả là cho phép phê duyệt không tốn gas.

Nói chính xác hơn, tiêu chuẩn này cho phép phê duyệt mà chủ sở hữu token không cần gửi giao dịch phê duyệt.

Blockchain vẫn cần một giao dịch và phí gas để cập nhật trạng thái.

Vì sao EIP-712 quan trọng đối với Permit?

EIP-2612 sử dụng dữ liệu có cấu trúc định kiểu dựa trên EIP-712.

EIP-712 là tiêu chuẩn băm và ký dữ liệu có cấu trúc thay vì ký các chuỗi byte không rõ nội dung.

Điều này quan trọng vì người dùng ví cần hiểu nội dung mình đang ký.

Yêu cầu ký một chuỗi thập lục phân thô có thể gây khó hiểu và nguy hiểm.

Chữ ký định kiểu có thể hiển thị rõ hơn các trường như chủ sở hữu, bên chi tiêu, giá trị, nonce và deadline.

EIP-712 cũng sử dụng dấu phân tách miền.

Dấu phân tách miền giúp phân biệt ngữ cảnh ký này với ngữ cảnh ký khác.

Đối với EIP-2612, miền thường bao gồm thông tin như tên token, phiên bản, chain ID và địa chỉ hợp đồng xác minh.

Thiết kế này giúp ngăn chữ ký dành cho một token hoặc blockchain có hiệu lực trong ngữ cảnh khác.

Bản thân EIP-712 nêu rõ tiêu chuẩn này không cung cấp cơ chế bảo vệ phát lại.

EIP-2612 bổ sung cơ chế bảo vệ phát lại thông qua nonce riêng cho từng chủ sở hữu.

Nonce và cơ chế bảo vệ phát lại

Nonce là một số chỉ được sử dụng một lần.

Trong EIP-2612, hợp đồng token theo dõi nonce của từng địa chỉ chủ sở hữu.

Khi người dùng ký permit, dữ liệu đã ký bao gồm nonce hiện tại của chủ sở hữu.

Khi permit được sử dụng thành công, hợp đồng token sẽ tăng nonce đó.

Nếu ai đó cố gửi lại cùng permit, nonce sẽ không còn khớp.

Vì vậy, chữ ký được sử dụng lại sẽ không hợp lệ.

Cơ chế bảo vệ bằng nonce rất cần thiết vì chữ ký có thể bị sao chép.

Nếu không có cơ chế này, bên chi tiêu hoặc kẻ tấn công có thể sử dụng lại cùng một permit đã ký nhiều lần.

Một triển khai permit tốt phải coi nonce là một phần của thông điệp đã ký và chỉ cập nhật nonce khi permit được thực thi thành công.

Đối với người dùng, ý nghĩa thực tế rất đơn giản.

Chữ ký permit hợp lệ chỉ nên được sử dụng một lần, không phải mãi mãi.

Deadline và thời hạn chữ ký

Tham số

giới hạn thời gian chữ ký permit có thể được sử dụng.

Nếu dấu thời gian của block hiện tại muộn hơn deadline, permit sẽ không hợp lệ.

Cơ chế này bảo vệ người dùng khỏi việc chữ ký cũ bị gửi lên rất lâu sau thời điểm dự kiến sử dụng.

Deadline ngắn có thể giảm rủi ro vì thu hẹp khoảng thời gian được phép gửi chữ ký.

Deadline dài có thể thuận tiện hơn vì chữ ký tiếp tục sử dụng được trong thời gian lâu hơn.

Deadline không giới hạn hoặc ở rất xa có thể tiềm ẩn rủi ro vì phê duyệt đã ký có thể tiếp tục hiệu lực trong thời gian dài, trừ khi được sử dụng, vô hiệu hóa hoặc thay thế thông qua cơ chế nonce.

Người dùng nên chú ý đến deadline khi ví hiển thị dữ liệu permit định kiểu.

Nhà phát triển nên tránh đặt deadline quá dài trừ khi có lý do rõ ràng.

Ứng dụng nên giải thích ý nghĩa của deadline theo cách người dùng dễ hiểu.

Dấu phân tách miền và ngữ cảnh blockchain

Dấu phân tách miền là thành phần quan trọng của việc ký EIP-712.

Trong EIP-2612, thành phần này giúp gắn permit với một hợp đồng token và miền cụ thể.

Một miền thông thường bao gồm tên token, phiên bản token, chain ID và địa chỉ hợp đồng xác minh.

Điều này giảm nguy cơ permit ký cho một hợp đồng bị phát lại với hợp đồng khác.

Nó cũng giảm nguy cơ permit ký trên một blockchain bị sử dụng lại trên blockchain khác.

Tuy nhiên, mức độ an toàn của dấu phân tách miền phụ thuộc vào việc triển khai chính xác.

Nếu hợp đồng token sử dụng dấu phân tách miền không đầy đủ, rủi ro phát lại có thể tăng.

Nếu chain ID thay đổi hoặc hợp đồng được triển khai trên nhiều mạng, nhà phát triển cần cân nhắc kỹ cách phân tách chữ ký.

Đối với người dùng, dấu phân tách miền thường được ẩn trong giao diện ví.

Đối với nhà phát triển, đây là một trong những chi tiết quan trọng nhất khi triển khai permit an toàn.

Giải thích về phê duyệt không tốn gas

Cụm từ “phê duyệt không tốn gas” có thể gây hiểu nhầm.

EIP-2612 không giúp giao dịch Ethereum hoặc EVM trở nên miễn phí.

Tiêu chuẩn này cho phép chủ sở hữu token phê duyệt việc chi tiêu bằng cách ký thông điệp thay vì gửi giao dịch.

Relayer, ứng dụng, hợp đồng thông minh hoặc bên chi tiêu sau đó có thể gửi permit đã ký lên on-chain và trả phí gas.

Cách này có thể hỗ trợ người dùng có token ERC-20 nhưng không đủ token gas gốc để phê duyệt.

Nó cũng có thể giúp ứng dụng tạo trải nghiệm liền mạch chỉ với một bước.

Ví dụ, người dùng có thể ký permit rồi hoàn tất thao tác nạp tiền, thanh toán hoặc sử dụng token mà không cần tự gửi giao dịch phê duyệt riêng trước đó.

Trải nghiệm người dùng có vẻ đơn giản hơn, nhưng blockchain vẫn ghi nhận thay đổi trạng thái thông qua giao dịch on-chain.

Nhà phát triển cần giải thích rõ điều này vì nếu không, người dùng có thể nghĩ rằng thông điệp đã ký không gây ra hậu quả nào.

Chữ ký permit có thể dẫn đến hậu quả thực tế on-chain sau khi được gửi lên.

Các trường hợp sử dụng EIP-2612 phổ biến trong crypto

EIP-2612 thường được sử dụng trong DeFi và các ứng dụng dựa trên token.

Giao thức cho vay có thể dùng permit để người dùng phê duyệt tài sản thế chấp và nạp tài sản đó trong cùng một quy trình.

Hợp đồng staking có thể dùng permit để người dùng phê duyệt token staking mà không cần giao dịch phê duyệt riêng.

Ứng dụng thanh toán có thể dùng permit để người trả tiền ủy quyền chuyển token qua quy trình thanh toán thuận tiện hơn.

Ví có thể dùng permit để giảm số bước giao dịch trong các thao tác ERC-20 phổ biến.

Dịch vụ relayer có thể dùng permit để trả phí gas thay người dùng và thu hồi chi phí theo cách khác.

Hợp đồng thông minh có thể kết hợp permit với

để việc phê duyệt và chuyển token diễn ra trong cùng một luồng giao dịch.

Cách thức này có thể giảm số lần thao tác thất bại vì bước phê duyệt không cần được đưa vào block riêng trước thao tác chính.

Nó cũng có thể giảm nhầm lẫn vì ứng dụng hướng dẫn người dùng qua một quy trình kết hợp duy nhất.

Lợi ích chính không chỉ là tiết kiệm phí gas.

Lợi ích quan trọng nhất là giảm trở ngại trong quá trình ủy quyền sử dụng token.

Hàm Permit và Account Abstraction

Hàm Permit đôi khi được nhắc đến cùng Account Abstraction vì cả hai đều cải thiện trải nghiệm ví.

Permit cho phép chủ sở hữu token ERC-20 ủy quyền thay đổi allowance thông qua chữ ký.

Account Abstraction hướng đến việc giúp tài khoản crypto có thể lập trình và linh hoạt hơn.

Đây là hai công cụ khác nhau nhưng có mục tiêu tương tự.

Cả hai đều hướng đến việc giảm trở ngại khi tương tác với blockchain.

Permit tập trung vào việc phê duyệt token.

Account Abstraction tập trung rộng hơn vào cách tài khoản ủy quyền và thanh toán cho các thao tác.

Ứng dụng crypto có thể sử dụng cả hai ý tưởng trong cùng một thiết kế sản phẩm.

Ví dụ, ví hoặc hệ thống tài khoản thông minh có thể hỗ trợ giao dịch được tài trợ phí gas, đồng thời sử dụng quy trình phê duyệt token tương thích với permit.

Người dùng không cần hiểu mọi lớp kỹ thuật, nhưng nhà phát triển phải triển khai chính xác từng lớp.

Rủi ro bảo mật của hàm Permit

Rủi ro lớn nhất đối với người dùng là phishing chữ ký.

Trang web độc hại có thể yêu cầu người dùng ký permit phê duyệt cho một bên chi tiêu nguy hiểm.

Vì chữ ký permit không phải là một giao dịch chuyển token thông thường, một số người dùng có thể nghĩ rằng nó vô hại.

Đó là một giả định nguy hiểm.

Permit có thể ủy quyền cho bên chi tiêu chuyển token vào thời điểm sau đó.

Người dùng nên kiểm tra địa chỉ bên chi tiêu, số lượng token, tên token và deadline trước khi ký.

Người dùng nên từ chối những chữ ký không rõ ràng, ngoài dự kiến hoặc được yêu cầu bởi trang web không quen thuộc.

Một rủi ro khác là phê duyệt không giới hạn.

Nếu người dùng ký permit với giá trị rất lớn, bên chi tiêu có thể có quyền chi tiêu rộng đối với allowance của token đó.

Rủi ro thứ ba là triển khai sai.

Nếu hợp đồng token xử lý nonce, phân tách miền, khôi phục chữ ký hoặc deadline không chính xác, chữ ký có thể bị phát lại hoặc được chấp nhận dù lẽ ra phải bị từ chối.

Rủi ro thứ tư là giao diện người dùng gây nhầm lẫn.

Nếu ví không hiển thị dữ liệu định kiểu rõ ràng, người dùng có thể ký những phê duyệt mà họ không hiểu.

Permit cải thiện tính tiện dụng, nhưng đồng thời khiến việc hướng dẫn người dùng về chữ ký trở nên quan trọng hơn.

Permit không loại bỏ rủi ro phê duyệt

EIP-2612 thay đổi cách ủy quyền phê duyệt, nhưng không thay đổi rủi ro cơ bản khi phê duyệt một bên chi tiêu.

Nếu bên chi tiêu độc hại, bị xâm phạm hoặc được cấp allowance quá lớn, người dùng vẫn có thể mất token.

Phê duyệt bằng permit có thể mạnh tương đương một giao dịch

thông thường.

Điểm khác biệt là phê duyệt bắt đầu bằng chữ ký thay vì giao dịch do chủ sở hữu token gửi.

Điều này có nghĩa là người dùng nên thận trọng với chữ ký permit như với giao dịch phê duyệt.

Người dùng nên tránh ký permit không giới hạn trừ khi hoàn toàn tin tưởng bên chi tiêu và hiểu rõ rủi ro.

Người dùng nên thu hồi các allowance không còn cần thiết.

Người dùng nên sử dụng ví riêng cho các tương tác dApp có rủi ro cao và ví khác để lưu trữ tài sản dài hạn.

Người dùng nên xác minh địa chỉ hợp đồng qua các nguồn đáng tin cậy trước khi cấp quyền truy cập vào token có giá trị.

Permit và front-running

Bất kỳ ai có thông điệp đã ký đều có thể gửi chữ ký permit.

Điều này tạo ra một vấn đề cần lưu ý về front-running.

Nếu người dùng ký permit và gửi cho ứng dụng, một bên khác nhìn thấy chữ ký có thể gửi permit trước.

Trong nhiều trường hợp, việc này chỉ sử dụng permit và thiết lập cùng allowance mà người dùng dự định cấp.

Tuy nhiên, nếu ứng dụng yêu cầu thực thi permit đồng thời với một thao tác khác, permit bị front-run có thể khiến giao dịch kết hợp sau đó thất bại vì nonce đã thay đổi.

Nhà phát triển nên thiết kế luồng xử lý để ứng phó phù hợp với trường hợp này.

Hợp đồng thông minh thường có thể kiểm tra xem allowance dự kiến đã tồn tại hay chưa rồi tiếp tục thay vì thất bại không cần thiết.

Giao diện người dùng cũng nên giải thích rõ nguyên nhân luồng permit thất bại.

Điểm chính người dùng cần nhớ là permit đã ký có thể được chuyển đi nơi khác cho đến khi được sử dụng hoặc hết hạn.

Không chia sẻ dữ liệu permit đã ký nếu bạn không tin tưởng quy trình đó.

Lưu ý triển khai dành cho nhà phát triển

Nhà phát triển nên tuân thủ chặt chẽ đặc tả EIP-2612.

Type hash của permit phải khớp với cấu trúc đã ký dự kiến.

Digest phải sử dụng mã hóa EIP-712 cùng dấu phân tách miền và hash cấu trúc permit.

Hợp đồng phải từ chối permit đã hết hạn.

Hợp đồng phải từ chối chữ ký không hợp lệ.

Hợp đồng phải từ chối permit nếu người ký được khôi phục không phải chủ sở hữu.

Hợp đồng phải từ chối trường hợp chủ sở hữu là địa chỉ zero không phù hợp.

Hợp đồng phải tăng nonce của chủ sở hữu sau khi thực thi permit thành công.

Hợp đồng phải phát ra sự kiện

tiêu chuẩn sau khi thay đổi allowance.

Khi có thể, nhà phát triển nên sử dụng thư viện đã được đánh giá kỹ lưỡng.

Tài liệu ERC20Permit của OpenZeppelin cung cấp một mô hình triển khai được sử dụng rộng rãi cho các dự án Solidity.

OpenZeppelin cũng hướng dẫn cách sử dụng ERC-20 Permit trong các môi trường khác, chẳng hạn như ERC-20 Permit cho Stylus.

Ngay cả khi sử dụng thư viện, nhà phát triển vẫn nên kiểm thử cẩn thận hành vi cụ thể của token.

Hàm Permit và giao dịch meta

Giao dịch meta là một mô hình rộng hơn, trong đó người dùng ký thông điệp và một bên khác gửi giao dịch thay mặt người dùng.

Có thể xem EIP-2612 là một mô hình chữ ký cụ thể tập trung vào phê duyệt.

Tiêu chuẩn này không chuyển mọi thao tác token thành thao tác được ký.

Nó chỉ chuẩn hóa các phê duyệt allowance ERC-20 đã ký.

Phạm vi giới hạn này là có chủ đích.

Một tiêu chuẩn tối giản sẽ dễ được áp dụng và tích hợp hơn trên nhiều ví, hợp đồng và ứng dụng.

Nhà phát triển muốn hỗ trợ chuyển token có chữ ký, thao tác theo lô hoặc tài trợ phí gas tùy chỉnh có thể cần hợp đồng hoặc tiêu chuẩn bổ sung.

Permit hữu ích vì giải quyết một vấn đề phổ biến mà không cần thay đổi toàn bộ mô hình ERC-20.

Nó bổ trợ cho các hệ thống giao dịch meta thay vì thay thế tất cả các hệ thống đó.

Hàm Permit và chuyển token

Permit không phải là một giao dịch chuyển token.

Giao dịch chuyển token đưa token từ địa chỉ này sang địa chỉ khác.

Permit cập nhật allowance mà một địa chỉ cấp cho địa chỉ khác.

Điều này có nghĩa là người dùng có thể ký permit và vẫn giữ token trong cùng ví cho đến khi bên chi tiêu sử dụng allowance.

Việc chuyển token thực tế thường diễn ra thông qua

.

Sự khác biệt này rất quan trọng đối với an toàn của ví.

Số dư token có thể không thay đổi ngay sau khi người dùng ký permit.

Điều đó không có nghĩa chữ ký vô hại.

Bên chi tiêu vẫn có thể được phép chuyển token sau đó.

Người dùng nên kiểm tra các allowance đang hoạt động sau khi sử dụng dApp và thu hồi những phê duyệt không còn cần thiết.

Hàm Permit và Permit2

EIP-2612 là tiêu chuẩn ở cấp token.

Để token hỗ trợ EIP-2612, chính hợp đồng token phải triển khai hàm permit.

Các hệ thống phê duyệt khác có thể cung cấp hành vi tương tự permit thông qua hợp đồng bên ngoài.

Các hệ thống này không giống với hỗ trợ EIP-2612 gốc.

Sự khác biệt này quan trọng vì yêu cầu trong ví, địa chỉ bên chi tiêu, hệ thống nonce, phạm vi phê duyệt và cách thu hồi có thể khác nhau.

Khi ký một phê duyệt tương tự permit, người dùng nên kiểm tra hợp đồng nào đang được cấp quyền.

Khi tích hợp permit, nhà phát triển nên xác minh token có hỗ trợ trực tiếp EIP-2612 hay cần một cơ chế phê duyệt khác.

Gọi mọi phê duyệt có chữ ký là “EIP-2612” có thể gây nhầm lẫn.

EIP-2612 có giao diện và cấu trúc chữ ký cụ thể.

Cách người dùng đọc yêu cầu ký permit

Trước tiên, người dùng nên kiểm tra tên token.

Sau đó, người dùng nên kiểm tra địa chỉ bên chi tiêu hoặc ứng dụng đang yêu cầu quyền.

Người dùng nên kiểm tra số lượng được phê duyệt.

Người dùng nên xác định giá trị có bị giới hạn hay gần như không giới hạn.

Người dùng nên kiểm tra deadline.

Người dùng nên xác minh yêu cầu xuất hiện sau một thao tác có chủ đích.

Người dùng nên từ chối yêu cầu nếu nó xuất hiện ngoài dự kiến.

Người dùng cần đặc biệt thận trọng nếu trang web yêu cầu ký nhiều thông điệp liên tiếp.

Người dùng nên tránh ký thông điệp permit từ các liên kết trong tin nhắn trực tiếp, cuộc trò chuyện hỗ trợ giả mạo, quảng cáo đáng ngờ hoặc trang token không rõ nguồn gốc.

Người dùng cần nhớ rằng ký permit có thể trao cho một địa chỉ khác quyền chi tiêu token.

Yêu cầu trong ví an toàn nên hiển thị các trường này dễ đọc, nhưng người dùng không nên chỉ dựa vào thiết kế giao diện.

Vì sao Permit cải thiện trải nghiệm người dùng?

Permit cải thiện trải nghiệm người dùng bằng cách giảm số giao dịch on-chain cần thực hiện.

Tính năng này có thể loại bỏ bước phê duyệt riêng trong nhiều luồng thao tác dApp.

Nó có thể giúp người dùng tương tác với token ERC-20 ngay cả khi họ không có đủ token gas gốc để gửi giao dịch phê duyệt riêng.

Nó có thể giúp ứng dụng tài trợ phí gas hoặc gộp bước phê duyệt với một thao tác khác.

Nó có thể giảm các luồng thao tác thất bại do người dùng phê duyệt token rồi quên hoàn tất giao dịch thứ hai.

Nó có thể giúp người mới sử dụng ứng dụng on-chain làm quen dễ dàng hơn.

Những lợi ích này đặc biệt quan trọng vì phê duyệt ERC-20 là một trong những trở ngại phổ biến nhất trong crypto.

Tuy nhiên, phê duyệt thuận tiện hơn không có nghĩa mặc nhiên an toàn hơn.

Trải nghiệm người dùng tốt cần đi kèm yêu cầu ký rõ ràng, thiết kế bên chi tiêu cẩn trọng và công cụ quản lý allowance dễ sử dụng.

Các lỗi thường gặp với EIP-2612

Một lỗi phổ biến là nghĩ permit chuyển token ngay lập tức.

Permit chỉ cập nhật allowance.

Một lỗi thường gặp khác là nghĩ phê duyệt không tốn gas nghĩa là không ai phải trả phí gas.

Permit vẫn cần giao dịch on-chain để cập nhật trạng thái hợp đồng.

Lỗi thứ ba là ký phê duyệt không giới hạn mà không hiểu rủi ro từ bên chi tiêu.

Lỗi thứ tư là bỏ qua trường deadline.

Lỗi thứ năm là tin tưởng yêu cầu chữ ký chỉ vì nó không giống một giao dịch thông thường.

Lỗi thứ sáu là cho rằng mọi token ERC-20 đều hỗ trợ EIP-2612.

Lỗi thứ bảy là tích hợp permit mà không kiểm thử chain ID, dấu phân tách miền và hành vi nonce trên các lần triển khai.

Lỗi thứ tám là coi mọi hệ thống tương tự permit đều giống EIP-2612.

Lỗi thứ chín là không xử lý trường hợp permit bị front-run trong luồng kết hợp của hợp đồng.

Lỗi thứ mười là hiển thị yêu cầu permit theo cách người dùng khó hiểu.

Thực hành tốt dành cho người dùng

Chỉ ký thông điệp permit trên các trang web và ứng dụng mà bạn tin tưởng.

Kiểm tra token, bên chi tiêu, số lượng và deadline trước khi ký.

Tránh phê duyệt không giới hạn trừ khi có lý do chính đáng.

Khi có thể, hãy sử dụng giá trị phê duyệt nhỏ.

Thu hồi các allowance cũ không còn cần thiết.

Không ký thông điệp permit từ liên kết ngẫu nhiên, tin nhắn hỗ trợ giả mạo hoặc trang airdrop không rõ nguồn gốc.

Sử dụng một ví riêng cho các dApp thử nghiệm và một ví khác để lưu trữ tài sản dài hạn.

Kiểm tra kỹ các cảnh báo trong ví.

Đừng cho rằng chữ ký an toàn chỉ vì nó không trực tiếp hiển thị phí gas.

Hãy nhớ rằng người khác có thể gửi permit đã ký sau đó, trước khi permit hết hạn.

Thực hành tốt dành cho nhà phát triển

Khi có thể, hãy sử dụng các triển khai permit đã được kiểm toán và duy trì tốt.

Nếu tuyên bố hỗ trợ EIP-2612, hãy tuân thủ chính xác giao diện EIP-2612 chính thức.

Sử dụng dữ liệu định kiểu EIP-712 để ví có thể hiển thị rõ thông tin cần ký.

Triển khai chính xác cơ chế phân tách miền.

Theo dõi nonce riêng cho từng địa chỉ chủ sở hữu.

Từ chối chữ ký đã hết hạn.

Từ chối người ký không hợp lệ và các trường hợp chủ sở hữu là địa chỉ zero.

Phát ra sự kiện

sau khi cập nhật allowance thành công.

Thiết kế luồng permit kết hợp để xử lý được trường hợp permit được gửi trước giao dịch chính.

Hiển thị tên bên chi tiêu, số lượng token và thông tin hết hạn bằng ngôn ngữ dễ hiểu.

Cung cấp tài liệu dễ tiếp cận về cách người dùng thu hồi allowance.

Kiểm thử chữ ký trên các chain ID, fork, bản nâng cấp và nhà cung cấp ví khác nhau.

Hàm Permit trong một câu

Hàm Permit trong EIP-2612 cho phép chủ sở hữu token ERC-20 phê duyệt bên chi tiêu thông qua chữ ký EIP-712, nhờ đó allowance được cập nhật on-chain mà chủ sở hữu không cần gửi giao dịch phê duyệt riêng.

Câu hỏi thường gặp

Hàm Permit trong EIP-2612 là gì?

Hàm Permit là phần mở rộng ERC-20 cho phép chủ sở hữu token phê duyệt bên chi tiêu bằng chữ ký off-chain, sau đó chữ ký này có thể được gửi lên on-chain.

Permit có chuyển token không?

Không, permit chỉ thiết lập allowance và bản thân nó không chuyển token.

Vì sao EIP-2612 hữu ích?

EIP-2612 hữu ích vì giảm trở ngại khi phê duyệt, cho phép trải nghiệm phê duyệt không tốn gas và giúp ứng dụng kết hợp bước phê duyệt với các thao tác khác của hợp đồng thông minh.

Chủ sở hữu token có trả phí gas khi dùng permit không?

Chủ sở hữu token không cần gửi giao dịch phê duyệt, nhưng vẫn có người phải trả phí gas để gửi permit đã ký lên on-chain.

Approve và permit khác nhau như thế nào?

Approve là giao dịch on-chain do chủ sở hữu token gửi, còn permit là chữ ký off-chain mà một bên khác có thể gửi lên on-chain.

EIP-712 liên quan gì đến permit?

EIP-712 cung cấp cơ chế ký dữ liệu có cấu trúc định kiểu, giúp ví hiển thị chi tiết permit rõ hơn và gắn chữ ký với một miền xác định.

Nonce trong EIP-2612 là gì?

Nonce là giá trị riêng cho từng chủ sở hữu, giúp ngăn chữ ký permit bị sử dụng lại.

Deadline trong permit là gì?

Deadline là thời điểm hết hạn, sau đó chữ ký permit không còn hiệu lực.

EIP-2612 có an toàn không?

EIP-2612 có thể an toàn nếu được triển khai và sử dụng đúng cách, nhưng người dùng vẫn cần cảnh giác với phishing chữ ký, phê duyệt không giới hạn, bên chi tiêu độc hại và yêu cầu trong ví không rõ ràng.

Mọi token ERC-20 đều hỗ trợ permit không?

Không, chỉ token ERC-20 triển khai phần mở rộng EIP-2612 mới hỗ trợ hàm Permit tiêu chuẩn.

Chữ ký permit có thể bị front-run không?

Có, bất kỳ ai có chữ ký permit hợp lệ đều có thể gửi chữ ký đó trước một giao dịch khác. Vì vậy, nhà phát triển nên thiết kế luồng xử lý để ứng phó với khả năng này.

Người dùng có thể giảm rủi ro từ permit bằng cách nào?

Người dùng có thể giảm rủi ro bằng cách kiểm tra bên chi tiêu, giới hạn số lượng phê duyệt, sử dụng deadline ngắn, tránh trang web đáng ngờ và thu hồi allowance không còn sử dụng.

Kết luận

Hàm Permit trong EIP-2612 là một trong những cải tiến hữu ích nhất cho trải nghiệm phê duyệt ERC-20.

Hàm này cho phép người dùng ủy quyền allowance token bằng chữ ký thay vì giao dịch phê duyệt riêng.

Cách này có thể giảm trở ngại về phí gas, cải thiện quy trình làm quen với dApp, hỗ trợ các luồng giao dịch được tài trợ phí và giúp kết hợp các thao tác ERC-20 trong một quy trình người dùng dễ thực hiện hơn.

Tiêu chuẩn này dựa vào dữ liệu có cấu trúc định kiểu EIP-712, cơ chế phân tách miền, nonce và deadline để giúp phê duyệt có chữ ký an toàn và cụ thể hơn.

Tuy nhiên, permit không loại bỏ rủi ro cơ bản của allowance token.

Permit đã ký vẫn có thể trao cho bên chi tiêu quyền thực tế đối với token của người dùng.

Người dùng nên xem chữ ký permit nghiêm túc như giao dịch phê duyệt.

Nhà phát triển nên triển khai tiêu chuẩn cẩn trọng, hiển thị thông tin ký rõ ràng và xử lý các trường hợp đặc biệt như bảo vệ phát lại, chữ ký hết hạn và permit bị front-run.

Khi được sử dụng đúng cách, EIP-2612 giúp token ERC-20 dễ sử dụng hơn mà không thay đổi nguyên tắc cốt lõi về việc chi tiêu token dựa trên allowance.

Đây là một tiêu chuẩn nhỏ nhưng quan trọng, giúp ứng dụng crypto dễ sử dụng hơn trên thực tế đồng thời duy trì khả năng tương thích với hệ sinh thái ERC-20 rộng lớn.