Zatwierdzenia tokenów: uprawnienia, których ciągle udzielasz

Za każdym razem, gdy korzystasz z aplikacji DeFi — swap na DEX-ie, depozyt na rynku pożyczek, mostkowanie ERC-20 — niemal na pewno udzieliłeś zatwierdzenia tokenu. Większość użytkowników podpisuje je w kilka sekund i o nich zapomina. A jednak ta pojedyncza transakcja approve jest jedną z najbardziej brzemiennych w skutkach rzeczy, jakie robisz na Ethereum: oddaje smart contractowi stałe pozwolenie na ruch twoich tokenów, często bez kolejnego potwierdzenia. Ten przewodnik wyjaśnia, czym jest zatwierdzenie tokenu, dlaczego dAppy o nie proszą, jakie ryzyko niosą nieograniczone allowance i co to wszystko oznacza, gdy podpisujesz zatwierdzenia przez SSP.

Dlaczego zatwierdzenia w ogóle istnieją

Tokeny ERC-20 nie są przechowywane "w" twoim portfelu tak jak ETH. Kontrakt tokenu ERC-20 jest księgą rachunkową: mapowaniem adresów na salda. Gdy trzymasz 1000 USDC, w łańcuchu istnieje w rzeczywistości wiersz w kontrakcie USDC mówiący, że twój adres posiada 1000 jednostek.

Ponieważ saldo żyje wewnątrz kontraktu tokenu, tylko ten kontrakt może je przesunąć. Gdy wysyłasz USDC do znajomego, twój portfel wywołuje bezpośrednio funkcję transfer tokenu.

Ale DEX, w którym inny kontrakt (router) musi ściągnąć USDC z twojego adresu, by wykonać swap, nie może po prostu sięgnąć do kontraktu tokenu i wziąć twojego salda. ERC-20 rozwiązuje to dwustopniowym wzorcem delegacji:

1. Ty wywołujesz approve(spender, amount) na kontrakcie tokenu. To ustawia allowance: zapis, że spender jest uprawniony do przesuwania do amount twoich tokenów.
2. Spender później wywołuje transferFrom(yourAddress, destination, amount) na kontrakcie tokenu. Kontrakt sprawdza allowance, zmniejsza go i przesuwa tokeny.

Zatwierdzenie jest kluczem. Bez niego router w ogóle nie może dotknąć twoich USDC.

Co właściwie udzielasz

Przeczytaj approve(spender, amount) dosłownie. Mówisz kontraktowi ERC-20: "ten adres może wypłacić do tej liczby moich tokenów, w dowolnym momencie, w dowolnej liczbie transakcji, dopóki tego nie zmienię."

Wynika z tego kilka rzeczy:

• Stałe pozwolenie, a nie jednorazowa akcja. Raz udzielone, spender nie potrzebuje twojego podpisu ponownie, by ściągać tokeny, dopóki allowance nie zostanie wykorzystany lub odwołany.
• Per token. Zatwierdzenie routera DEX dla USDC nie pozwala mu dotknąć twojego DAI; potrzebne jest osobne zatwierdzenie dla DAI.
• Per spender. Inny kontrakt — nawet z tej samej dAppy — ma własny allowance.
• Bez terminu ważności. ERC-20 nie ma wbudowanego deadline'u. Allowance ustawiony w 2023 jest aktywny w 2026, o ile nie został wykorzystany lub odwołany.

Każdy allowance możesz sprawdzić w eksploratorze bloków takim jak etherscan, odczytując funkcję widoku allowance(owner, spender) kontraktu tokenu.

Wzorzec nieskończonego allowance

Skoro zatwierdzenia są na kwotę, dlaczego niemal każdy DEX prosi cię o ogromną liczbę — zwykle 2^256 - 1, wyświetlaną jako "unlimited" lub MaxUint256 — zamiast o sam wymieniany właśnie nominał?

Odpowiedzią jest UX i gas. Gdyby DEX prosił o świeży allowance równy wielkości transakcji przy każdym swapie, płaciłbyś za transakcję zatwierdzenia za każdym razem i potwierdzałbyś dwie transakcje za to, co odczuwasz jako jedną akcję. Poproszenie o nieograniczony allowance raz pozwala ci później swobodnie wymieniać przy jednej transakcji na jeden trade.

To naprawdę wygodne. Jest też naprawdę bardziej ryzykowne. Nieograniczony allowance oznacza, że kontrakt spendera ma prawo opróżnić cały twój obecny stan tego tokenu — i każde przyszłe saldo — w dowolnym momencie, bez żadnego dodatkowego podpisu z twojej strony.

Dla znanego, zaudytowanego, niezmiennego kontraktu praktyczne ryzyko jest zwykle niskie. Dla świeżo wdrożonej dAppy, upgradeable'a proxy lub nieznanego kontraktu nieograniczony allowance to znacznie szersza powierzchnia niż transakcja, którą zamierzałeś.

Prawdziwe ryzyko: stały klucz do twoich tokenów

Zagrożenie zatwierdzeń nie tkwi w samej transakcji approve. Tkwi w tym, co dzieje się potem. Rozważ kilka scenariuszy:

• Kontrakt spendera ma błąd. Atakujący eksploituje jego logikę transferFrom i każdy portfel z niezerowym allowance zostaje opróżniony.
• Kontrakt spendera jest upgradeable. Ten, kto kontroluje klucze upgrade, wdraża nową logikę, która ściąga tokeny z każdego, kto ma aktywny allowance.
• Zatwierdziłeś złośliwy klon. Strona phishingowa naśladowała URL prawdziwej dAppy, a kontrakt, który zatwierdziłeś, od początku był kontrolowany przez atakującego.
• Klucze podpisujące spendera zostały skompromitowane. Oficjalny kontrakt jest w porządku; portfel operatora nie, a allowance są wykonywane przez intruza.

W każdym przypadku w momencie opróżnienia nic nie podpisujesz. Zatwierdzenie udzielone tygodnie wcześniej jest jedyną autoryzacją, jakiej potrzebuje atakujący. "Zatwierdzaj tylko to, czego potrzebujesz, i odwołuj to, czego już nie używasz" to nie paranoja; to ta sama zasada, co nie zostawianie zapasowych kluczy do domu każdemu fachowcowi, którego kiedykolwiek zatrudniłeś.

Jak zatwierdzenia po cichu się nawarstwiają

Portfel aktywny w DeFi przez rok-dwa zgromadził dziesiątki zatwierdzeń: każdy DEX, każdy agregator, każdy depozyt na rynku pożyczek, każdy marketplace NFT, każdy most. Użytkownicy niemal nigdy nie wracają, by odwoływać. W rezultacie powstaje długi ogon stałych pozwoleń, wiele z nich nieograniczonych, wiele udzielonych kontraktom, z którymi użytkownik już nie wchodzi w interakcję.

To cicha powierzchnia ataku. Nie pokazuje się w żadnej pojedynczej transakcji; jest skumulowanym osadem normalnego użytkowania. Audyt i przycinanie tej listy to jeden z najskuteczniejszych nawyków bezpieczeństwa w samokastodii — następny artykuł pokazuje dokładnie jak w odwoływanie zatwierdzeń tokenów z SSP.

Nowszy wzorzec: EIP-2612 permit

ERC-20 wyprzedza dużą część współczesnego DeFi, a dwutransakcyjny taniec approve-potem-swap od dawna uznawany jest za niewygodny. EIP-2612 wprowadził alternatywę dla tokenów, które się na nią piszą: zamiast wysyłać transakcję approve w łańcuchu, użytkownik podpisuje wiadomość off-chain (permit) autoryzującą konkretnego spendera, kwotę i deadline. dAppa wysyła ten podpis razem ze swapem w pojedynczej transakcji.

permit jest oszczędny gas-owo, ograniczony zakresowo (niesie jawną kwotę i wygaśnięcie) i trudniejszy do pozostawienia wiszący, bo deadline wymusza wygaśnięcie. Nie każdy ERC-20 to wspiera — USDC i DAI tak, wiele starszych tokenów nie — ale tam, gdzie jest dostępny, jest zwykle bezpieczniejszy niż długoterminowy approve allowance. Mimo to same podpisy permit także mogą być przedmiotem phishingu: złośliwa strona prosząca cię o "zalogowanie się" może podsunąć pod spodem permit. Czytaj, co podpisujesz.

Co to oznacza wewnątrz SSP

SSP to samokastodialny portfel multisig 2-z-2: każda transakcja on-chain jest współpodpisywana przez rozszerzenie SSP w przeglądarce i aplikację mobilną SSP Key. Na Ethereum i sieciach EVM wspieranych przez SSP (Polygon, Base, BNB Smart Chain, Avalanche) jest to zaimplementowane jako smart account ERC-4337 z agregowanym podpisem Schnorr — ale na warstwie aplikacji zatwierdzenie wygląda jak każda inna transakcja.

Kilka rzeczy do zapamiętania:

• Zatwierdzenie to transakcja, którą twoje 2-z-2 musi współpodpisać. Gdy dAppa prosi o approve, SSP pokazuje to jak każdą inną tx. Widzisz adres spendera i żądaną kwotę na obu urządzeniach przed potwierdzeniem.
• Raz udzielone, spender nie potrzebuje już SSP, by działać. Multisig chroni moment zatwierdzenia, nie stałe pozwolenie później. Jeśli udzielisz nieograniczonego allowance złośliwemu kontraktowi, multisig nie uchroni cię przed późniejszym opróżnieniem.
• Patrz na adres spendera. dAppy czasem aktualizują routery; jeśli spender na ekranie zatwierdzenia nie zgadza się z oczekiwanym kontraktem, zatrzymaj się i zweryfikuj.
• Zatwierdzenia inicjowane przez WalletConnect wyglądają tak samo. Czy dAppa pyta cię w swojej stronie, czy przez WalletConnect, przepływ i ryzyko są identyczne.

Nawyki, które warto wyrobić

Kilka konkretnych praktyk utrzymuje powierzchnię zatwierdzeń pod kontrolą:

• Wybieraj najmniejszy roboczy allowance. Gdy dAppa daje wybór między "dokładną kwotą" a "unlimited", dokładna kwota to bezpieczniejsza domyślna opcja dla kontraktów, których nie używasz regularnie.
• Traktuj nieograniczone zatwierdzenia jako zobowiązania. Rezerwuj je dla małego zestawu kontraktów, którym ufasz i z których korzystasz często. Dla całej reszty — ograniczaj zakres.
• Audytuj okresowo. Raz na kwartał wypisz aktywne zatwierdzenia w każdej sieci i odwołaj wszystko, czego już nie używasz. Narzędzia takie jak revoke.cash czynią to rutyną.
• Bądź ostrożny wobec nieznanych dApp. Nowy protokół bez historii audytów proszący o nieograniczony allowance to najbardziej ryzykowna kombinacja w DeFi.
• Chroń klucze udzielające zatwierdzeń. Multisig SSP podnosi poprzeczkę, ale standardowa higiena nadal obowiązuje — zobacz dobre praktyki dla frazy seed.

Model mentalny do wyniesienia

Zatwierdzenie tokenu nie jest kliknięciem; jest kluczem. Każdy zostaje w zamku, dopóki go nie wyjmiesz, i każdy daje jego posiadaczowi zdolność przesunięcia tokenów, których jeszcze nie zarobiłeś. Używane z rozwagą allowance to instalacja sanitarna, dzięki której DeFi w ogóle działa. Traktowane jak jednorazowe kliknięcia, są powolnym narastaniem ryzyk, o których zapomniałeś, że je wziąłeś.

Zrozum pozwolenie, którego udzielasz, preferuj ograniczone zakresem dotacje, kiedy dAppa na to pozwala, i przycinaj swoje stałe zatwierdzenia według harmonogramu. Po głębsze szczegóły protokołu kanonicznym odniesieniem jest dokumentacja standardu ERC-20 na ethereum.org. Nowy w korzystaniu z SSP na Ethereum? Nasz przewodnik Ethereum w SSP omawia podstawy.