Zgody tokenów i allowance: jak sprawdzić i cofnąć ERC-20

Połączenie z witryną zwykle pozwala aplikacji zobaczyć publiczny adres i poprosić o podpis. Samo w sobie nie daje prawa do przenoszenia wszystkich tokenów ERC-20. Allowance jest zapisywana osobno w kontrakcie tokena. MetaMask również rozróżnia odłączenie dapp od cofnięcia zgód na tokeny.

Allowance ERC-20 dotyczy kontraktu tokena, sieci, adresu właściciela i adresu spendera. Zgoda na Ethereum nie jest zgodą na token o tej samej nazwie w Polygon ani na inny token. Pamiętanie tylko „zgodziłem się na tę witrynę” może ukryć, który token i sieć nadal mają aktywne uprawnienie.

Ten poradnik opisuje approve, allowance i transferFrom ERC-20 w Ethereum i zgodnych sieciach. Transfery natywnego ETH, NFT-owe setApprovalForAll, inne standardy i połączenie portfela do logowania działają inaczej. Informacje o kopii zapasowej kluczy znajdziesz w poradniku seed phrase i odzyskiwania portfela.

Właściciel może wywołać approve(spender, amount) w kontrakcie tokena, aby pozwolić wskazanemu spenderowi wykorzystać określoną ilość. transferFrom pozwala spenderowi przenieść tokeny w imieniu właściciela. Dlatego approve zwykle nie zmienia od razu salda, ale późniejsze wywołanie kontraktu może zużyć allowance. Tak działa standard ERC-20.

Przykład: portfel ma 300 tokenów i daje routerowi allowance 80. W typowym ERC-20 efektywny limit to mniejsza z wartości: pozostała allowance albo saldo. Zgoda może dotyczyć więcej niż jednej transakcji; kontrakt może wielokrotnie wywołać transferFrom. Nadużycie zatwierdzonego kontraktu lub ścieżki jego wywołania może przenieść tokeny w nieoczekiwany sposób. Warto też sprawdzić niestandardowe zachowanie tokena.

Zgoda to zwykle transakcja w łańcuchu skierowana do kontraktu tokena i może kosztować opłatę sieciową. Niektóre aplikacje rozdzielają zgodę i swap; inne łączą podpisane uprawnienie z późniejszą transakcją. Sprawdź, co portfel faktycznie prosi podpisać i jaka sieć jest wybrana, a nie tylko etykietę „Approve”.

Etykieta „Unlimited” często oznacza allowance bliską maksymalnej wartości całkowitej tokena. Nie tworzy nieskończonych tokenów i nie przenosi salda w chwili zatwierdzenia. Spender może jednak później wykorzystać pozostałe uprawnienie wobec tokenów tego samego typu, które trafią do tego portfela w tej samej sieci. Niektóre implementacje nie zmniejszają maksymalnej allowance po użyciu, więc sprawdź zachowanie tokena.

Aplikacja może prosić o szeroki limit, by ograniczyć ponowne zgody, ale wygodę i ryzyko należy rozpatrywać łącznie. Luka lub nadużycie kontroli nad kontraktem spendera może sprawić, że stara zgoda zostanie wykorzystana później. Poradnik Ethereum.org o cofnięciu zgód wyjaśnia, dlaczego szeroka allowance może mieć znaczenie nawet po zwróceniu aktywów do portfela.

Mniejszy limit nie usuwa wszystkich zagrożeń. Zgoda na fałszywy token lub błędnego spendera może spowodować stratę nawet przy małej kwocie; ponowne zatwierdzanie każdej operacji też oznacza opłaty i okazje do pomyłki. Uwzględnij planowaną ilość, częstotliwość użycia, zaufanie do kontraktu i możliwość ponownego sprawdzenia uprawnienia.

Przed podpisem sprawdź cztery rzeczy: czy wybrana sieć zgadza się z instrukcją aplikacji; czy adres kontraktu tokena jest poprawny, a nie tylko jego symbol; czy adres spendera odpowiada oficjalnym dokumentom lub weryfikowalnym danym kontraktu; oraz czy limit pasuje do planowanej czynności, zamiast pozostawiać szerokie uprawnienie na długo.

Nie łącz portfela przez link z prywatnej wiadomości, kod QR, czatu pomocy ani niezweryfikowanej reklamy. Strona phishingowa może naśladować prawdziwą aplikację. Zacznij od zapisanego oficjalnego adresu lub dokumentacji projektu. Znana nazwa kontraktu nie dowodzi, że adres jest poprawny; znacznik weryfikacji w eksploratorze nie gwarantuje bezpieczeństwa.

Sprzętowy signer może oddzielić klucz prywatny od zwykłej przeglądarki, ale nie ocenia, czy spender i kwota są bezpieczne. Jeśli urządzenie nie pokazuje żądania w zrozumiały sposób, zatrzymaj się i sprawdź oficjalne objaśnienie dostawcy portfela. Mniej widocznych szczegółów oznacza mniej możliwości weryfikacji.

Niektóre tokeny ERC-20 obsługują ERC-2612 permit. Zamiast wysyłać zwykłą transakcję approve, właściciel podpisuje typed data; inna strona może przesłać ten podpis, aby ustawić allowance. Standardowa wiadomość zawiera właściciela, spendera, wartość, nonce i deadline oraz domenę wiążącą podpis z siecią i kontraktem.

deadline w ERC-2612 to ostatnia chwila, w której można przesłać podpisany permit. Nie oznacza, że allowance ustawiona poprawnie automatycznie wygaśnie o tej porze. Uprawnienie może pozostać, dopóki nie zostanie użyte, zmienione lub cofnięte. Niektóre tokeny mają inne warianty permit albo dodatkowe terminy; nie zakładaj, że każde żądanie „permit” działa według ERC-2612.

Podpis może pozwolić innemu kontu opłacić transakcję, ale nie jest przez to nieszkodliwym potwierdzeniem logowania. Jeśli portfel nie pokazuje jasno tokena, spendera, wartości i warunków czasowych albo dane nie zgadzają się z opisem aplikacji, odrzuć prośbę i sprawdź oficjalne dokumenty. Nieprzesłany jeszcze podpis ktoś inny może przesłać przed deadline.

Wylogowanie lub odłączenie portfela zmienia sesję przeglądarki albo uprawnienie połączenia. Allowance ERC-20 zapisana już w kontrakcie tokena może pozostać aktywna. Cofnięcie allowance nie usuwa też publicznego adresu znanego witrynie ani historii transakcji. Poradnik MetaMask o odłączaniu opisuje różnicę.

Cofnięcie zwykle wymaga transakcji on-chain ustawiającej allowance dla danego tokena i spendera na zero. Transakcja kosztuje opłatę sieciową, a stare uprawnienie może działać do jej potwierdzenia. Potem odśwież listę zgód lub odczytaj kontrakt ponownie i sprawdź zero dla tego samego portfela, sieci, tokena i spendera. MetaMask i Ethereum.org opisują sprawdzanie według sieci; zweryfikuj oficjalną domenę i wybraną sieć.

Każda sieć przechowuje własny stan. Wyzerowanie allowance na Ethereum nie zmienia automatycznie zgody na ten sam token w innej sieci. Sprawdź każde konto, kontrakt tokena, spendera i odpowiednią sieć, a wynik zweryfikuj po potwierdzeniu transakcji. Narzędzie do cofania zgód nie potrzebuje seed phrase ani klucza prywatnego.

Po potwierdzeniu allowance równej zero to uprawnienie nie pozwala na nowe transferFrom. Nie cofa jednak zakończonych transferów, nie odzyskuje tokenów od odbiorcy ani nie usuwa uprawnień innych kontraktów. Jeśli podejrzany spender już przeniósł tokeny, samo cofnięcie nie gwarantuje ich odzyskania.

Jeśli klucz prywatny portfela wyciekł, atakujący nadal może podpisywać transakcje innymi sposobami. Zgody dla innych spenderów lub tokenów, uprawnienia operatora NFT, podpisy permit i uprawnienia specyficzne dla kontraktów mogą również pozostać aktywne. Wynik interpretuj tylko w zakresie portfela i sieci, które sprawdziłeś.

Po cofnięciu kolejny swap, depozyt lub wykup może wymagać nowej zgody. Wcześniej sprawdź, czy oczekująca transakcja albo aktywna pozycja korzysta z tego uprawnienia; w razie potrzeby zajrzyj do oficjalnej pomocy protokołu. Wiedz, co zmieni się przy następnym działaniu.

Standard ERC-20 zaleca interfejsom wyzerować niezerową allowance przed zastąpieniem jej inną niezerową wartością. Jeśli transakcja spendera zostanie włączona między starą a nową zgodą, może on wykorzystać więcej, niż użytkownik zakładał. Przy zmianie ze 100 na 25 spender może użyć starych 100 przed zapisaniem nowych 25, a potem wykorzystać także nowe 25.

Najpierw ustawienie zera i jego potwierdzenie zmniejsza ryzyko jednoczesnej dostępności starych i nowych wartości, ale nie cofa użycia starej allowance przed potwierdzeniem zerowej transakcji. Oba kroki mogą kosztować opłaty, a tokeny zachowują się różnie. Postępuj zgodnie z bezpieczną procedurą opisaną przez portfel lub token i poczekaj na potwierdzenie.

Jeśli nie znasz obecnej allowance, przed zmianą odczytaj kontrakt tokena w wybranej sieci. Jeśli portfel pokazuje pustą lub nieoczekiwaną wartość, upewnij się, że nie patrzysz na inną sieć albo adres. Zgadzać się muszą zarówno adres właściciela, jak i kontrakt tokena.

1. Potwierdź oficjalną domenę projektu i wybraną sieć.
2. Sprawdź adresy kontraktu tokena i spendera; porównaj limit z ilością potrzebną do działania.
3. Przeczytaj rzeczywistą transakcję lub typed data wyświetlane przez portfel. Nie podpisuj niezrozumiałej prośby.
4. Sprawdź spenderów, których już nie używasz lub którym nie ufasz, w odpowiedniej sieci; w razie potrzeby wyzeruj allowance i potwierdź wynik.
5. Porównując portfele, sprawdź obsługiwane sieci, czytelność zgód oraz jasność instrukcji aktualizacji i odzyskiwania.

Portfel sprzętowy jest jedną z opcji przechowywania klucza i kontroli podpisu, a nie gwarancją bezpieczeństwa kontraktu ani blokadą przed zgodą na szeroki limit. Samodzielnie sprawdź spendera, token, sieć i kwotę. Wiedza, że allowance może trwać niezależnie od połączenia z witryną, pomaga porównać funkcje bezpieczeństwa portfela i ich rzeczywiste ograniczenia.