Phê duyệt token: những quyền bạn liên tục cấp

Mỗi lần bạn tương tác với một ứng dụng DeFi — hoán đổi trên một DEX, gửi tiền vào thị trường vay, bắc cầu một ERC-20 — gần như chắc chắn bạn đã cấp một phê duyệt token. Hầu hết người dùng ký các giao dịch này trong vài giây rồi quên đi. Tuy nhiên, giao dịch approve đơn lẻ đó là một trong những việc có hệ quả nhất bạn làm trên Ethereum: nó trao cho smart contract quyền vĩnh viễn để di chuyển token của bạn, thường không cần xác nhận thêm. Bài hướng dẫn này giải thích phê duyệt token là gì, vì sao các dApp yêu cầu chúng, rủi ro của allowance không giới hạn và tất cả điều này có ý nghĩa gì khi bạn ký phê duyệt qua SSP.

Vì sao có phê duyệt

Token ERC-20 không được lưu "trong" ví của bạn theo cách ETH được lưu. Một hợp đồng token ERC-20 là một sổ cái: một ánh xạ từ các địa chỉ sang số dư. Khi bạn nắm giữ 1.000 USDC, thứ thực sự tồn tại on-chain là một dòng trong hợp đồng USDC nói rằng địa chỉ của bạn sở hữu 1.000 đơn vị.

Vì số dư nằm bên trong hợp đồng token, chỉ hợp đồng đó mới có thể di chuyển nó. Khi bạn gửi USDC cho một người bạn, ví của bạn gọi trực tiếp hàm transfer của token.

Nhưng một DEX, nơi một hợp đồng khác (router) cần rút USDC từ địa chỉ của bạn để thực hiện hoán đổi, không thể thò tay vào hợp đồng token và lấy số dư của bạn. ERC-20 giải quyết điều này bằng mô hình ủy quyền hai bước:

1. Bạn gọi approve(spender, amount) trên hợp đồng token. Nó thiết lập một allowance: một bản ghi rằng spender được phép di chuyển tối đa amount token của bạn.
2. Spender sau đó gọi transferFrom(yourAddress, destination, amount) trên hợp đồng token. Hợp đồng kiểm tra allowance, giảm nó và di chuyển token.

Phê duyệt là chìa khóa. Không có nó, router không thể chạm vào USDC của bạn.

Bạn đang cấp gì thực sự

Hãy đọc approve(spender, amount) theo nghĩa đen. Bạn đang nói với hợp đồng ERC-20: "địa chỉ này có thể rút tối đa số token này của tôi, vào bất kỳ lúc nào, trong bất kỳ số giao dịch nào, cho đến khi tôi thay đổi."

Từ đó suy ra một số điều:

• Quyền vĩnh viễn, không phải hành động một lần. Một khi được cấp, spender không cần chữ ký của bạn nữa để rút token cho đến khi allowance bị tiêu hết hoặc bị thu hồi.
• Theo từng token. Phê duyệt router DEX cho USDC không cho phép nó chạm vào DAI của bạn; bạn cần một phê duyệt riêng cho DAI.
• Theo từng spender. Một hợp đồng khác — kể cả từ cùng một dApp — có allowance riêng.
• Không hết hạn. ERC-20 không có thời hạn tích hợp sẵn. Một allowance được đặt năm 2023 vẫn còn hiệu lực năm 2026 trừ khi đã được tiêu hết hoặc thu hồi.

Bạn có thể kiểm tra mọi allowance trên một trình duyệt block như etherscan bằng cách đọc hàm view allowance(owner, spender) của hợp đồng token.

Mô hình allowance vô hạn

Nếu phê duyệt là theo số tiền, vì sao gần như mọi DEX lại hỏi bạn một con số khổng lồ — thường là 2^256 - 1, hiển thị là "unlimited" hoặc MaxUint256 — thay vì đúng số bạn đang hoán đổi?

Câu trả lời là UX và gas. Nếu một DEX yêu cầu một allowance mới bằng kích thước giao dịch cho mỗi swap, bạn sẽ trả một giao dịch phê duyệt mỗi lần và phải xác nhận hai giao dịch cho thứ cảm giác như một hành động. Yêu cầu một allowance không giới hạn một lần cho phép bạn sau đó hoán đổi tự do với một giao dịch cho mỗi trade.

Đó là thực sự thuận tiện. Nó cũng thực sự rủi ro hơn. Một allowance không giới hạn nghĩa là hợp đồng spender được phép rút sạch toàn bộ số dư hiện tại của bạn cho token đó — và mọi số dư trong tương lai — vào bất kỳ thời điểm nào, mà bạn không ký gì thêm.

Đối với một hợp đồng nổi tiếng, đã được audit, bất biến, rủi ro thực tế thường thấp. Đối với một dApp vừa deploy, một proxy có thể nâng cấp hoặc một hợp đồng bạn chưa nghe đến, một allowance không giới hạn là một bề mặt rộng hơn rất nhiều so với giao dịch bạn dự định.

Rủi ro thật sự: một chìa khóa thường trực vào token của bạn

Mối nguy của phê duyệt không nằm ở bản thân giao dịch phê duyệt. Nó nằm ở những gì xảy ra sau đó. Hãy xem xét vài kịch bản:

• Hợp đồng spender có lỗi. Kẻ tấn công khai thác logic transferFrom của nó, và mọi ví có allowance khác không bị rút sạch.
• Hợp đồng spender có thể nâng cấp. Người kiểm soát khóa nâng cấp triển khai logic mới rút token từ bất cứ ai có allowance đang hoạt động.
• Bạn đã phê duyệt một bản sao độc hại. Một trang lừa đảo bắt chước URL của một dApp thật, và hợp đồng bạn phê duyệt vốn đã do kẻ tấn công kiểm soát ngay từ đầu.
• Khóa ký của spender bị xâm phạm. Hợp đồng chính thức vẫn ổn; ví của vận hành viên thì không, và các allowance bị một kẻ xâm nhập sử dụng.

Trong mọi trường hợp, bạn không ký gì khi việc rút diễn ra. Phê duyệt bạn đã cấp vài tuần trước là sự ủy quyền duy nhất kẻ tấn công cần. "Chỉ phê duyệt những gì bạn cần và thu hồi những gì bạn không còn dùng" không phải là hoang tưởng; nó cùng nguyên tắc với việc không để lại chìa khóa dự phòng cho mọi thợ thầu bạn từng thuê.

Phê duyệt âm thầm tích lũy như thế nào

Một ví hoạt động một, hai năm trong DeFi đã tích lũy hàng chục phê duyệt: mỗi DEX, mỗi aggregator, mỗi lần gửi vào thị trường vay, mỗi marketplace NFT, mỗi cây cầu. Người dùng gần như không bao giờ quay lại để thu hồi. Kết quả là một cái đuôi dài các quyền vĩnh viễn, nhiều cái không giới hạn, nhiều cái được cấp cho những hợp đồng mà người dùng không còn tương tác.

Đó là bề mặt tấn công thầm lặng. Nó không xuất hiện trong bất kỳ giao dịch đơn lẻ nào; nó là cặn bã tích lũy của việc sử dụng bình thường. Kiểm toán và cắt tỉa danh sách đó là một trong những thói quen bảo mật hiệu quả nhất trong tự lưu ký — bài tiếp theo trong loạt chỉ ra chính xác cách làm trong thu hồi phê duyệt token từ SSP.

Một mô hình mới hơn: EIP-2612 permit

ERC-20 ra đời trước phần lớn DeFi hiện đại, và điệu nhảy hai giao dịch approve-rồi-swap từ lâu đã bị xem là vụng về. EIP-2612 giới thiệu một lựa chọn thay thế cho các token chọn tham gia: thay vì gửi một giao dịch approve on-chain, người dùng ký một thông điệp off-chain (một permit) cấp quyền cho một spender, số lượng và hạn chót cụ thể. dApp gửi chữ ký đó cùng với swap trong một giao dịch duy nhất.

permit tiết kiệm gas, có phạm vi (mang một số lượng và hạn chót rõ ràng) và khó để bỏ lại lủng lẳng vì hạn chót buộc nó phải hết hạn. Không phải mọi ERC-20 đều hỗ trợ — USDC và DAI có, nhiều token cũ hơn thì không — nhưng nơi có sẵn, nó thường an toàn hơn một allowance approve lâu dài. Tuy vậy, bản thân chữ ký permit cũng có thể bị lừa đảo: một trang độc hại yêu cầu bạn "đăng nhập" có thể giấu một permit bên dưới. Đọc kỹ thứ bạn đang ký.

Điều này có nghĩa là gì bên trong SSP

SSP là một ví multisig 2-trên-2 tự lưu ký: mọi giao dịch on-chain được đồng ký bởi tiện ích trình duyệt SSP và ứng dụng di động SSP Key. Trên Ethereum và các mạng EVM mà SSP hỗ trợ (Polygon, Base, BNB Smart Chain, Avalanche), điều này được triển khai dưới dạng một smart account ERC-4337 với chữ ký Schnorr tổng hợp — nhưng ở tầng ứng dụng, một phê duyệt trông giống mọi giao dịch khác.

Một vài điều cần ghi nhớ:

• Một phê duyệt là một giao dịch mà 2-trên-2 của bạn phải đồng ký. Khi một dApp yêu cầu approve, SSP hiển thị nó như mọi tx khác. Bạn thấy địa chỉ spender và số lượng yêu cầu trên cả hai thiết bị trước khi xác nhận.
• Một khi được cấp, spender không còn cần SSP để hành động. Multisig bảo vệ khoảnh khắc phê duyệt, không phải quyền vĩnh viễn sau đó. Nếu bạn cấp một allowance không giới hạn cho một hợp đồng độc hại, multisig sẽ không cứu bạn khỏi việc rút sạch sau này.
• Quan sát địa chỉ spender. dApp thỉnh thoảng nâng cấp router; nếu spender trên màn hình phê duyệt không khớp với hợp đồng bạn mong đợi, hãy dừng lại và xác minh.
• Các phê duyệt khởi tạo qua WalletConnect trông giống nhau. Cho dù dApp hỏi bạn ngay trong trang hay qua WalletConnect, luồng và rủi ro là giống hệt.

Những thói quen đáng xây dựng

Một vài thực hành cụ thể giữ cho bề mặt phê duyệt vẫn quản lý được:

• Chọn allowance nhỏ nhất khả thi. Khi một dApp cho lựa chọn giữa "số chính xác" và "unlimited", chọn số chính xác là mặc định an toàn hơn cho các hợp đồng bạn không dùng thường xuyên.
• Coi phê duyệt không giới hạn là cam kết. Dành chúng cho một tập nhỏ các hợp đồng bạn tin tưởng và sử dụng nhiều. Mọi thứ khác, hãy giới hạn phạm vi.
• Kiểm toán định kỳ. Mỗi quý một lần, liệt kê các phê duyệt đang hoạt động của bạn trên từng chuỗi và thu hồi mọi thứ bạn không còn dùng. Công cụ như revoke.cash biến điều này thành thói quen.
• Thận trọng với các dApp lạ. Một giao thức mới không có lịch sử audit yêu cầu allowance không giới hạn là kết hợp rủi ro cao nhất trong DeFi.
• Bảo vệ các khóa cấp phê duyệt. Multisig của SSP nâng tiêu chuẩn lên, nhưng vệ sinh cơ bản vẫn áp dụng — xem thực hành tốt nhất cho cụm từ hạt giống.

Mô hình tinh thần để mang theo

Một phê duyệt token không phải là một cú nhấp; nó là một chiếc chìa khóa. Mỗi chiếc nằm trong ổ cho đến khi bạn rút ra, và mỗi chiếc trao cho người giữ nó khả năng di chuyển những token bạn còn chưa kiếm được. Dùng cẩn thận, allowance là hệ thống ống nước cho phép DeFi vận hành. Bị đối xử như những cú nhấp dùng một lần, chúng là sự tích lũy chậm chạp của các rủi ro mà bạn quên rằng mình đã gánh.

Hiểu quyền bạn đang cấp, ưu tiên cấp có phạm vi nơi dApp cho phép, và tỉa các phê duyệt vĩnh viễn của bạn theo lịch trình. Để biết chi tiết giao thức sâu hơn, tài liệu chuẩn ERC-20 trên ethereum.org là tài liệu tham khảo chuẩn. Mới sử dụng SSP trên Ethereum? Hướng dẫn Ethereum trong SSP của chúng tôi bao quát các kiến thức cơ bản.