Zrozumieć approve
Dzisiejszy artykuł jest dla tych, którzy nie chcą na własnej skórze doświadczyć tajemnicy znikających z portfela tokenów. Reszta może się rozejść.
Spis treści
Kiedy masz styczność z approve?
Za każdym razem, gdy wykonujesz operacje na tokenach w ramach jakiegoś smart contractu na sieci Ethereum bądź pochodnej. Za sieci pochodne uważamy te oparte o Maszynę Wirtualną Ethereum (ang. EVM). Najpopularniejsze z nich to BNB Chain, Polygon, Avalanche, Fantom, Arbitrium, Gnosis Chain, Optimism czy Cronos.
Czyli jak robisz coś tokenami w DeFi na tych sieciach, to zanim to zrobisz musisz wykonać transakcję approve. Czasem dana strona może nazywać ją trochę inaczej, np. Unlock bądź Allow.
Po co to komu?
Po to, aby smart contract mógł operować posiadanymi przez Ciebie tokenami.
Wynika to z tego w jaki sposób działają smart contracty na Ethereum.
Każdy smart contract posiada swój adres. Dokładnie tak samo jak Twój czy mój portfel. I na ten adres takiemu smart contractowi możemy przesłać czy to Ether czy jakiś token ERC-20.
Z tymże wtedy smart contract nie będzie wiedział, co ma z tymi środkami zrobić. Będą one po prostu w nim leżały. Jednak w żaden sposób nie będą one dla nas produktywne. Co więcej, w większości przypadków nie będą one już do wyciągnięcia. Dlatego nigdy nie robimy po prostu transferu tokenów na adres smart contractu.
Zamiast tego wywołujemy jego odpowiednią metodę. Oczywiście nie robimy tego bezpośrednio. Korzystamy z interface’u, który przygotowali dla nas twórcy. Klikamy sobie stronę internetową, która przygotowuje odpowiednią transakcję, prosi nas o jej podpisanie i wysyła do wykonania na blockchain.
Takie metody to zestaw instrukcji do wykonania. Np.wpłać token na lokatę. Często przyjmując parametry, jak adres tokenu czy ilość środków do wpłaty.
Na przykład przesyłamy na Compound transakcję wpłać 1000 DAI na lokatę. Problemem jest to, że chociaż mamy informację o tym które token i w jakiej ilości, to nie mamy tych monet dołączonych do samej transakcji. Smart contract musi je sobie sam wziąść. Ale przecież nie może, bo są w naszym portfelu i tylko my możemy nimi dysponować podpisując transakcje.
I właśnie tutaj wchodzi transakcja Approve cała na biało.
Jest to transakcja zgodna ze standardem tokenów ERC-20. Przypomnijmy, że każdy token to tak naprawdę również po prostu pewien smart contract. Zawierającego metody zgodne ze wspomnianym wcześniej standardem. Jedną z nich jest właśnie Approve. Zezwala one zewnętrznemu adresowi na wyjmowanie środków z naszego portfela bez późniejszego pytania się o zgodę (bo wyrażamy ją z góry podczas przesyłania transakcji Approve). Zgodnie ze specyfikacją ERC-20 transakcja ta przyjmuje następujące parametry (informacje od użytkownika):
- Wydający (ang. Spender) – adres smart contractu, któremu pozwalamy na wyciąganie środków z naszego portfela
- Wartość (ang. Value) – ilość tokenów, która wydający może sobie pobrać z naszego portfela. Może to być z góry określona kwota. Albo dostęp nielimitowany do całego salda danego tokenu w naszym portfelu.
Wracając do naszego przykładu wpłaty 1000 DAI na lokatę. Przyjmijmy, że w naszym portfelu znajduje się 2000 DAI. Gdy udamy się na stronę dAppki z lokatą, to pojawi się opcja Approve. W zależności od serwisu może to być opcja Approve dla kwoty którą chcemy wpłacić (1000 DAI), bądź nielimitowany. Ewentualnie obie opcje do wyboru. Jeśli zdecydujemy się na limitowany do 1000 DAI i potem umieścimy ten kapitał na lokacie, to wyczerpiemy swój limit zezwolenia. Jeśli potem będziemy chcieli dopłacić więcej środków, to trzeba będzie wcześniej wykonać nową transakcję approve. Jeśli damy approve bez limitu, to potem będziemy mogli dopłacić od razu więcej kapitału.
Zalety i zagrożenia Approve bez limitu
Każdy kij ma dwa końce. A moneta orła i reszkę.
W świecie krypto przeciwnymi biegunami spektrum są bezpieczeństwo oraz wygoda (i koszty).
Jeśli popatrzymy tylko pod kątem bezpieczeństwa, to za każdym razem powinliśmy robić approve tylko na kwotę transakcji, którą chcemy wykonać. Dlatego, że dając uprawnienia na więcej, pozwalamy smart contractowi na wyciągnięcie sobie pozostałego salda danego tokenu z naszego portfela. Legitne projekty, które przeszły audyty, mają otwarty kod źródłowy nie mają możliwości dokonania wrogich i szkodliwych dla nas działań. Ale mogą się w nich zdążyć błędy, które do tego dopuszczą. Bądź w nowych wynalazkach celowo będzie zaimplementowana funkcjonalność pozwalająca na pozbawienie nas naszego salda.
Z drugiej strony mamy wygodę i kwestie kosztów (to szczególnie na Ethereum). Nawet w idealnym świecie prawie natychmiastowych i prawie darmowych transakcji przyznanie limitu tylko na określoną kwotę wiąże się z niewygodą kilku kliknięć więcej przy kolejnej wpłacie. W praktyce przy drogich transakcjach i zapchanych sieciach wiąże się z to z dodatkowymi kosztami (nawet kilkanaście dolarów i więcej) oraz czasem oczekiwania na potwierdzenie transakcji (liczonym w minutach).
Jakie więc jest zdroworozsądkowe podejście? Podzielę się z Tobą moim. Ja uznaje, że sprawdzone, działające długotrwale projekty, są godne zaufania. I przydzielam im approve bez limitu. Natomiast do nowych projektów podchodzę dużo bardziej ostrożnie. Przydzielając uprawnienia tylko pod daną kwotę.
Uwaga na airdropy
Chociaż metoda Approve jest częścią standardu ERC-20, to może być ona implementowana w różny sposób. Także w sposób jawnie wrogi wobec użytkowników. Od jakiegoś czasu są dość popularne ataku implementujące wrogie funkcjonalności w metodzie Approve ich tokenu.
I aby ludzie z tego tokenu korzystali, to obdarowywają nim użytkowników poprzez airdropy. Często bezpośrednio na nasze portfele. Zapewniając dla tokenu bazową, pozorną płynność, aby wykazać jego potencjalną wartość.
Wyobraź sobie taką sytuację. Widzisz na swoim portfelu nowy token. Sprawdzasz co to jest i jaką ma cenę na DEXach. Okazuje się, że jest to kilkaset dolarów bądź więcej. WOW, darmowe pieniądze z nieba. Chcesz to jak najszybciej spieniężyć. Dajesz na DEXie approve, aby w drugiej transakcji wykonać swap. Niestety już po pierwszej transakcji z Twojego portfela znikają popularne tokeny o dużej wartości. Jak to możliwe? Co się stało? Przecież to był approve dla sprawdzonego protokołu (np. Uniswapa).
Problem polegał jednak na samej implementacji approve tego tokenu. Gdzie wrzucono również instrukcje, które pozwalały pobrać z naszego portfela również inne tokeny. Dlatego bardzo rozsądnie i ostrożnie podchódź do takich darów z niebios. Przed ich spieniężeniem najlepiej poszukać na jego temat informacji. Pewnym pomysłem może być przesłanie tokenu na oddzielny portfel i dopiero tam dalsza zabawa z nim. Problem polega na tym, że token może też mieć wrogo napisaną metodę transferu i tym też sobie zrobimy krzywdę. Zdrowym nawykiem jest więc nie dotykać tokenów nie wiadomego pochodzenia, o nie wiadomym działaniu i reputacji.
Approve a portfele sprzętowe
Często ludzie myślą, że przytoczone wyżej ryzyka ich nie dotyczą, bo oni korzystają przecież z portfela sprzętowego. Z Ledgera, Trezora bądź innego. Nic bardziej mylnego. Po wykonaniu approve z naszej strony smart contract już nie potrzebuje żadnych zgód i podpisów z naszej strony. Tokeny są już dla niego dostępne. Podpisaliśmy już transakcję approve i żadna kolejna nie jest potrzebna. Niezależnie od tego, z jakiego portfela korzystamy
Wycofywanie zezwoleń
Przyznane uprawnienia do pobrania tokenów można modyfikować bądź je wycofać. Funkcjonalność tą oferują już popularne blockexplorery głównych sieci, specjalne serwisy czy też niektóre portfele. Niektóre z popularnych rozwiązań to:
- Etherscan (dla Ethereum)
- FTMScan (dla Fantoma)
- BSCScan (dla BNB Chain)
- Polygonscan (dla Polygon)
- Arbiscan (dla Arbitrum)
- Snowtrace (dla Avalanche)
- Revoke Cash (wiele sieci)
- Portfel Rabby (wiele sieci)
Dowiedz się więcej w kontekście bezpieczeństwa
Zrozumienie działania approve to niejedyny krytyczny aspekt bezpiecznego korzystania z kryptowalut oraz DeFi. Pozostałem z nich omawialiśmy parę tygodni temu podczas webinaru Ryzyko, bezpieczeństwo, ubezpieczenia.

Ciekawy wpis, dzięki!
Czy na terra też jakoś można / powinno się cofać zezwolenia?
Nie znam takiego serwisu. Gdy rozmawiałem o tym parę miesięcy temu z Tomkiem Kowalczykiem, to na tamten czas szanujące się projekty ustawiały sobie allowance na tyle na ile był potrzebny w danej transakcji