Dla początkujących

Jedno z najczęściej wracających do mnie pytań wiąże się z problemami związanymi z importem seeda metamask i “brakiem” wcześniejszych kont. Najczęściej taka sytuacja wynika z braku zrozumienia. Dlatego dzisiaj nad tym zrozumieniem popracujemy.

Metamask jest portfelem HD

Najczęściej wspominane wcześniej problemy dotyczą Metamaska. Dlatego, że jest on najpopularniejszym portfelem Ethereum. Ale standard jego działania w kontekście zarządzania adresami jest wykorzystywany w większości portfeli dla większości sieci.

Standard ten nazywa się Hierarchical Deterministic (HD) Wallet. 

Standard ten powstał początkowo dla Bitcoina. Który przypomnijmy nie korzysta z modelu kont (accounts), jak Ethereum, tylko UTXO. Gdzie rekomendowane jest, ze względów na anonimowość i bezpieczeństwo, wykorzystywanie nowych adresów dla każdej transakcji. A aby było to możliwe, to portfel musi mieć umiejętność łatwego tworzenia taki adresów. Przy czym użytkownik po zmianie portfela musi mieć znowu dostęp do zarządzania środkami na tych wszystkich adresach.

I tutaj wchodzą całe na biało portfele deterministyczne. Które z otrzymanego bądź wygenerowanego seeda tworzą tak zwany master private key. Główny klucz prywatny, z którego następnie można właściwie w nieskończoność tworzyć kolejne klucze prywatne. A co za tym idzie, także adresy. Co jest super ważne, to deterministyczny charakter tego procesu. Kolejne klucze prywatne zawsze będą generowane w takiej samej kolejności.

Mamy już rozkminiony determinizm, teraz o co chodzi z tą hierarchicznością? Mianowicie portfele HD mają tą przewagę nad zwykłymi portfelami deterministycznymi, że nie potrzebują wygenerować wszystkich kluczy prywatnych, aby poznać adresy odpowiadających im kont. Tak jak generowany jest master private key, tak samo generowane jest master public key (główny klucz prywatny). Pozwala on na określenie listy wszystkich adresów kontrolowanych przez seeda, bez ujawnianie tego seeda czy którekolwiek z kluczy prywatnych. W Bitcoinie taki klucz publiczny nazywa się xpub. Jest on szczególnie przydatny, w kwestiach do odczytu. Np. gdy chcemy wszystkie swoje adresy Bitcoina monitorować jakimś narzedziem analitycznym czy też do rozliczeń podatkowych. Wtedy nie musimy ufać takiemu narzędzi podając mu nasze seedy. Tylko podajemy xpub, dzięki którego narzędzie poznaje nasze adresy, bez możliwości uzyskania dostępu do środków tam zgromadzonych. Co jest jeszcze ważne, to po samych adresach nie można stwierdzić, czy pochodzą one z tego samego seeda. 

Jak Metamask importuje portfele z seeda? 

Przyjrzymy się teraz procesowi, jaki się dzieje, gdy podajemy Metamaskowi swój seed do zaimportowania. Pozwoli nam to zrozumieć sporo sytuacji, w których w innym przypadku byśmy panikowali, że Metamask nam nie zaimportował adresu i straciliśmy środki.

W pierwszym kroku Metamask z seed tworzy sobie główny klucz prywatny. Następnie będzie po kolei generował z niego kolejne adresy, do momentu aż pierwszy napotkany adres będzie miał zerowe saldo ETH. Metamask uzna, że jest to adres nieużywany i najprawdopodobniej nigdy go nie utworzyłeś. Nie warto więc importować ani jego ani żadnego z kolejnych adresów. Tutaj zwróćmy uwagę, że Metamask sprawdza saldo ETH na Ethereum. Nie interesuje go, czy są tam może jakieś tokeny. Nie sprawdza też balansów na innych sieciach.

Tak więc MM kończy dodawanie adresów, kto napotka pierwszy adres, który uzna za nie używany. Będą to adresy na których nie ma ETH na sieci Ethereum. Nawet jeśli będą tam jakieś tokeny bądź korzystaliśmy z tego adresu na innych sieciach EVM. 

Zdarzyć się mogą przypadki, gdy na liście naszych adresów adres uznawany za nie używany będzie przed kolejnymi używanymi. Wtedy te kolejne adresy, nawet z saldem ETH, nie zostaną automatycznie dodane. Jak rozwiązać taką sytuację?

Tutaj wracamy do determinizmu. Metamask z tego samego seed będzie tworzył takie same adresy w takiej samej kolejności. Dlatego po prostu korzystamy potrzebną ilość razy z opcji Dodaj konto (Create account)

W wyniku tego zaimportujemy też adresy znajdujące się także po tym, który został uznany, za nieużywany.

Portfele sprzętowe i zaimportowane konta

Miejmy świadomość, że zakładanie portfela i import nowego seeda pozwoli nam na dostęp jedynie do adresów pochodzących z tego seeda. Jeśli na poprzednim Metamasku korzystaliśmy również z portfela sprzętowego, to teraz musimy go na nowo połączyć (opcja nr 1 na powyższym screenie).

Podobnie jeśli importowaliśmy kolejne konta za pomocą klucza prywatnego bądź pliku JSON, to będziemy musieli zrobić to ponownie (opcja numer 2).

Adres zaimportowany, ale zniknęły moje tokeny

Jeżeli adres się zgadza, to wszystko jest w porządku. Możesz się upewnić co do tego, przeglądać swój adres w block explorerze. Najprawdopodobniej będziesz musiał ręcznie dodać tokeny do Metamask (szczególnie na innych sieciach niż Ethereum). Pomocne w tym będzie poniższe nagranie:

Zweryfikuj, czy import zadziała

W teorii wszystko powinno działać, w praktyce sporo w internecie lamentów, że to nie działa i ludzie tracą dostęp do swoich środków. Najcześciej jest to tylko wrażenie, wynikające z ich zrozumienia i niewiedzy. Ty już teraz wiesz i rozumiesz. To teraz sprawdź, czy to działa?

Zainstaluj sobie drugą przeglądarkę bądź stwórz kolejny profil użytkownika w Chrome. Następnie zainstaluj sobie tam Metamaska i zaimportuj swój seed. I korzystając z przedstawionej wiedzy, czy jesteś w stanie na nowym profilu mieć dostęp do tych samych adresów.

Co jeśli nie? 

Po pierwsze primo jeszcze raz przeczytaj ten tekst i upewnij się:

  1. Czy metamask nie skończył dodawania adresów, na adresie który uznał za nieużywany. Spróbuj dodać nowe konto, aby dodawać kolejne adresy
  2. Czy nie panikujesz, bo MM nie pokazuje Ci pewnych assetów. Upewnji się na block explorerze o ich istnieniu. A następnie zaimportuj je do MM
  3. Przeanalizuj wszystkie punkty z artykułu supportu Metamask na temat problemów z importem

Jeśli mimo wszystko jesteś świadkiem sytuacji, że MM odtwarza tylko część adresów bądź adresy są w ogóle totalnie inne, to zabezpiecz się na dotychczasowym MM exportując klucze prywatne do adresów, których nie udało się zaimportować.  Instrukcję jak to zrobić znajdziesz w pomocy Metamaska. Dzięki temu będziesz mógł ten adres potem zaimportować w innych portfelach ręcznie z klucza prywatnego.

Jednym z największych dylematów w krypto jest kwestia, jak skalować sieci, zachowując jednocześnie ich decentralizację. Obecnie przyjęta odpowiedź brzmi: nie specjalnie się da. I w tym momencie, całe na biało, wchodzi zero knowledge proofs.

Na czym polega blockchain trilemma?

Blockchain trilemma opowiada o dylemacie, przed którym stają wszyscy twórcy sieci krypto. Każda z nich charakteryzuje się trzema głównymi przymiotami:

  • Bezpieczeństwo
  • Decentralizacja
  • Skalowalność

Bezpieczeństwo określa jak trudno jest dokonać złowrogich działań w sieci. Na przykład przejąć czyjeś saldo czy dokonać niezgodnej z protokołem transakcji. Na jego czele stoją kryptografia oraz mechanizmy utrzymania konsensusu. Dwa najpopularniejsze z nich to Proof of Work (PoW) oraz Proof of Stake (PoS). W PoW bezpieczeństwo sieci jest wprost zależne od wielkości mocy obliczeniowej poświęconej do jej zabezpieczania. A w PoS do ilości kapitału poświęconego temu samemu celowi.

Decentralizacja. To chyba najciekawszy i zarazem najistotniejszy z przymiotów krypto. Najistotniejszy, bowiem to z niego wynikają najważniejsze innowacje krypto: pełna otwartość sieci, wolność i samostanowienie jej uczestników, odporność na cenzurę oraz brak potrzeby zaufania do stron trzecich. To jest unikalna wartość Bitcoina i krypto. Już wcześniej mieliśmy sieci finansowe, które były bezpieczne i skalowalne. Nie mieliśmy jednak sieci zdecentralizowanych, w których nikt, poza samym użytkownikiem, nie ma kontroli nad jego środkami i działaniami. Jest to też ciekawa własność, ponieważ nie jest ona jednoznacznie mierzalna. Można tutaj stosować różne wskaźniki, które mogą zaciemniać obraz sytuacji. 

No i finalnie mamy skalowalność. Czyli zdolność sieci do szybkiego przetwarzania jak największej ilości transakcji. Oczywiście chcemy jak najwięcej, jak najszybciej. Najlepiej do tego jeszcze jak najtaniej.

No i w tym miejscu jest najlepszy moment aby przedstawić głównego bohatera tej sekcji. Zwanego jako Blockchain Trilemma. Mówi on, że spośród tych trzech cech (bezpieczeństwo, decentralizacja oraz skalowalność) nie da się osiągnąć wszystkich na raz. 

Obrazowo można to przedstawić jako trójkąt, którego wierzchołkami są trzy wspomniane cechy:

I teraz my tworząc, rozwijając dany projekt musimy postawić kropkę gdzieś w środku tego trójkąta. Siłą rzeczy nie może ona jednocześnie znajdować się w bliskiej odległości do wszystkich wierzchołków.

To zjawisko, ten trilemmat nie wynika z tego, że twórcy protokołów umówili się, że można wybrać tylko maksymalnie 2 z 3. Albo że bóg tak chciał. Wynika to z zależności pomiędzy tymi sieciami.

Im bardziej skalowalną sieć będziemy chcieli zrobić, tym większe będą nasze wymagania technologiczne (moc obliczeniowa, przestrzeń dyskowa, jakość połączenia internetowa) wobec uczestników i walidatorów sieci. A im trudniej o spełnienie tych warunków, tym mniej uczestników i tym większa kontrola (centralizacja) w rękach tych istniejących. Wtedy oni z własnej inicjatywy (bądź w wyniku żądań regulatorów) mogą złamać główne pryncypia sieci (odporność na cenzurę, wprowadzenie niezgodnej z protokołem transakcji czy zamrożenie czyjegoś salda). Czyli z wynikającej z technologii i decentralizacji pewności, że nikt nie wykona niepożądanych działań przechodzimy w stronę ufności, że nikt tego nie zrobi (chociaż są tacy, którzy mogą). Widzimy więc, że kompromisy w stosunku do decentralizacji rzutują też na bezpieczeństwie sieci i zgromadzonych w niej środków.

Z tych powodów, główne kryptowaluty, które wyrosły z etosu wolnościowego, takie jak Bitcoin i Ethereum podjęły decyzję, że nie będą one poświęcać swojej decentralizacji na rzecz skalowalności. A problem ten rozwiążą na tak zwanych drugich warstwach (ang. Layer 2). Lightning Network dla Bitcoina czy roll-upy dla Etheruem.

Mamy też młodsze projekty, gdzie etos krypto w dużej mierze został zastąpiony pieniędzmi od funduszy VC i ich rządzą dobrego zysku. W celu wyróżnienia się na rynku i przeciągnięcia dużej rzeszy użytkowników często optymalizują one architekturę swoich sieci właśnie pod kątem skalowalności. Przykładami takich sieci mogą być chociażby BNB Chain, FLOW czy Solana.

No cóż, skoro nie można mieć wszystkiego, to projekty i ich użytkownicy muszą wybierać (i płacić za to cenę), co jest dla nich ważniejsze.

Czym są zero knowledge proofs?

Teraz przejdziemy do szybkiego omówienia drugiego bohatera naszego artykułu. A jest nim kryptografia zero knowledge proofs (ZK, ZK-proofs. ZKP).

Jest to stosunkowo świeża dziedzina kryptografii, które oferuje nam niesamowite, trochę magiczne przymioty. Trochę jak mechanika kwantowa. Gdy się czyta opis, jak to działa, to zdrowy rozsądek podpowiada, że to nie powinno tak działać. A jednak tak działa.

No to przyjrzyjmy się temu, w jaki sposób działa ZK-proofs.

Jak wskazuje sama nazwa, opiera się ono o dowody (proofs). Dowody, którymi jedna strona (twórca dowodu), jest w stanie zagwarantować drugij stronie (weryfikatorowi) prawdziwość danego stwierdzenia, bez ujawniania żadnych informacji związanych z tym stwierdzeniem. W wyniku takiego dowodu, weryfikator może mieć pewność, że coś jest prawdziwe. Nie poznając żadnych przesłanek ku temu prowadzących. Nie rozszerzając swojej wiedzy na ten temat (stąd zero knowledge).

Przełóżmy to na przykład z życia codziennego.

Załóżmy, że udajesz się do sklepu, aby zakupić alkohol. Zgodnie z literą polskiego prawa, aby to zrobić, musisz mieć powyżej 18 lat. Sprzedawca widzą Cię, chce to zweryfikować.

W świecie dzisiejszym prosi Cię więc o okazanie dowodu osobistego. Po czym sprawdza na nim datę Twojego urodzenia. Przy okazji mogąc poznać inne Twoje dane osobowe (imię, nazwisko, PESEL) nie mające totalnie żadnego związku z przeprowadzanym właśnie procesem weryfikacji wieku.

Natomiast w świecie masowego wykorzystania ZK, Ty nie pokazujesz sprzedawcy swojego dowodu osobistego. Zamiast tego, na jego podstawie tworzysz proof (dowód na podstawie dowodu ;), który pozwala sprzedawcy mieć pewność, że jesteś pełnoletni. Bez ujawniania mu żadnych Twoich danych osobowych. Z datą urodzenia włącznie.

Brzmi trochę jak magia, przyznasz. Ale podobno to matematyka.

W tym miejscu warto jeszcze wspomnieć o tym, że wyliczenie takiego dowodu, może być dość kosztowne w kontekście wykorzystania mocy obliczeniowej. Ale za to same dowody są dość małe i tanie (jeśli chodzi o moc obliczeniową) do zweryfikowania. Mając tego świadomość pora przejść do kolejnej sekcji, w której zero knowledge pozamiata blockchain trilemma. 

ZK – autostrada do tysięcy transakcji na sekundę w zdecentralizowany sposób?

Przyjrzyjmy się teraz temu, w jaki sposób przymioty zk-proofs mogą pomóc nam wyjść z ograniczającego pudełka blockchain trilemma.

Jeśli chcemy wykonywać więcej transakcji na sekundę, to siłą rzeczy:

  1. Potrzebujemy większej mocy obliczeniowej, do przeprocesowania tych transakcji. Zwłaszcza w kontekście wykonywania smart contractów
  2. Stworzymy większą ilość danych, które najpierw musimy sprawie rozpropagować po wszystkich uczestnikach sieci, a potem wszyscy oni muszą przechowywać wszystkie te dane na wieki wieków.

Zacznijmy od mocy obliczeniowej. Bo tutaj mogą się dziać najwspanialsze rzeczy.

W rozproszonych (w tym zdecentralizowanych) sieciach każda transakcja jest przetwarzana przez wszystkich uczestników sieci. Siłą rzeczy musimy więc tutaj równać do najsłabszych. Skoro każdy ma przetworzyć wszystko, to musimy zadbać o to, aby wszystko nie przekraczało zasobów sprzętowych tych najsłabszych. W przypadku sieci zdecentralizowanych sieci jak Bitcoin czy Ethereum ta poprzeczka zawieszona jest naprawdę nisko. Stąd mamy kilka czy kilkanaście transakcji na sekundę. Natomiast sieci, które nie bawią się w grę o decentralizację, takie jak ICP czy Solana, mogą wymagać od swoich uczestników wysokiej jakości farm serwerów, które są zdolne do przetwarzania tysięcy transakcji na sekundę.

Tutaj warto jeszcze wspomnieć, że transakcja transakcji nierówna. Mamy więc do czynienia ze stosunkowo prostymi i małymi transakcjami przesyłu wartości. Mamy też większe i wymagające większej mocy obliczeniowej transakcje korzystające na raz z wielu protokołów DeFi. Czy w końcu mamy znacząco większe transakcje, które w ogóle nie istnieją w praktyce, bo są na tyle duże i skomplikowane, że nie zdążyły by się wykonać w ciągu jednego bloku. Co znacząco ogranicza możliwości tego, co jest do zrobienia on chain.

To teraz zobacz to. Nasz przykład z potwierdzaniem pełnoletności. Zk-proof na to liczymy na boku i przedstawiamy pani w sklepie. Mówiąc językiem on chain, jest to transakcja, która weryfikuje naszą pełnoletności. Za pomocą zk-proof możemy udowodnić, że przeprowadziliśmy sprawdzanie naszego wieku na podstawie przyjętego algorytmu i że dla naszych danych (których nie ujawniamy) wyszło, że jesteśmy pełnoletni.

To teraz to zgeneralizujmy. Zk-proofs pozwalają nam udowodnić, że dokonaliśmy dowolnych obliczeń, zgodnie z przewidzianym algorytmem i wyszło nam to i to. I teraz te obliczenia, jak i dowód zk-proof na nie, my możemy sobie policzyć na boku (off-chain). Natomiast do sieci (on-chain) przesyłamy dowód na to. I każdy uczestnik sieci jest w stanie to szybko zweryfikować przy wykorzystaniu niewielkiej mocy obliczeniowej. A to oznacza, że nie każdy musi liczyć wszystko. Tylko każdy sobie liczy transakcje sam i do sieci przesyła jedynie dowód, co mu wyszło. Który każdy może szybko i sprawnie zweryfikować. 

No i teraz przechodzimy do punktu drugiego. Powiedzmy, że narobimy sobie dużo tych transakcji i dowodów na nie. No to one niestety zajmują miejsce. Co powoduje dwa wyzwania: szybka synchronizacja bieżąca danych między uczestnikami oraz potrzebę ich późniejszego przechowywania. I tutaj zk-proofs, szczególnie w tym drugim aspekcie, równiez może być bardzo pomocne. Tutaj wiele zależy od implementacji, ale są możliwe sytuacje:

  1. W jednym dowodzie zamieszczamy wiele transakcji, a rozmiar dowodu nie jest liniowo zależny od ilości i wielkości transakcji, które udowadnia. A być może nawet ma stałą wielkość niezależnie od ilości udowadnia nych transakcji (jak funkcje hashujące)
  2. Dowody można w sobie zagnieżdżać. W dowodzie umieszczać dowody, że dowiedliśmy wcześniej co innego. Co przy niektórych implementacjach pozwala tworzyć blockchain o stałej, małej wielkości. 

Bonus w postaci prywatności

Wróćmy jeszcze na chwilę do naszego przykładu, z potwierdzaniem pełnoletności w sklepie. Jeśli skorzystamy tam z ZK, to osiągniemy zamierzony efekt (potwierdzenie pełnoletności) bez ujawniania żadnych informacji o sobie. Wliczając w to naszą datę urodzenia.

To samo jest prawdziwe w kontekście transakcji krypto. Tworząc dowód zk-proof możemy dowieść, że dana transakcja jest całkowicie poprawna z protokołem, jednocześnie nie ujawniając żadnych informacji na jej temat. Nie wiadomo co, kto, komu i ile, ale wiadomo, że jest to poprawna transakcja, która może być uwzględniona w sieci. Co daje nam bardzo duży poziom prywatność. 

I właśnie prywatność jest kontekstem, w którym to zero knowledge po raz pierwszy zagościło w świecie krypto. Będąc podstawą projektów prywatnościowych, takich jak chociażby ZCash.

Wysoki poziom choćby opcjonalnej prywatności jest jednym z kluczowych aspektów masowej adopcji krypto. W większości tradycyjnych branż, wliczając w to sektor finansowy, radykalna transparentność, jaką oferują publiczne sieci blockchain, nie jest cechą pożądaną. W naprawdę sporej przestrzeni, zarówno życia biznesowego, jak i prywatnego, nie chcemy, aby cały świat oglądał nasze posunięcia w czasie rzeczywistym. A rozwiązania oparte o zk-proofs oferują nam możliwość zachowania prywatności naszych transakcji.

Poznaj projekty oparte o zk-proofs

Na koniec parę słów o projektach, implementujących zero knowledge w świecie krypto.

Jak już wcześniej wspomniałem, w pierwszej kolejności były to projekty prywatnościowe. Takie jak Firo (dawniej znany pod nazwą ZCoin) czy ZCash.

My najcześniej wspominaliśmy o zero knowledgrze w kontekście skalowania Ethereum przy wykorzystaniu drugich warstw. I jednym z rodzajów tego typu sieci są zk-rollups. Gdzie zk jest oczywiście skrótem od zero knowledge. A najpopularniejsze projekty tego typu to zkSync, StarkNet czy Loopring.

My natomiast podczas najbliższego webinaru skupimy się na mniej znanych projektach, które w oparciu m.in o zk-proofs chcą stworzyć rozwiązania pierwszej warstwy nowej generacji. Zapisz się już teraz, aby potem nie żałować, że przegapiłeś.

W przyszłym tygodniu Ethereum w końcu zmienia algorytm konsensusu na Proof of Stake. Niezależnie od tego, czy proces będzie przebiegał sprawnie czy zakończy się spektakularną klęską, to wydarzenie to zapisze się wielkimi literami na kartach (nie tylko) kryptowalutowej historii. Dzisiaj opowiemy sobie o tym, jak się do niego przygotować z perspektywy zwykłego użytkownika krypto.

Czym jest The Merge i przejście na Proof of Stake?

The Merga to znawa procesu, w wyniku którego Ethereum przejdzie finalnie na Proof of Stake. Zmiana konsensusu była zapowiadana od lata (a właściwie to od startu projektu) i jest niezbędna do wprowadzenia kolejnych udoskonaleń związanych ze skalowalnością sieci.

Proces ten na dobre rozpoczął się prawie dwa lata temu. Kiedy to w grudniu 2020 odpalono nowy łańcuch PoS dla Ethereum – Beacon Chain. Przez ten czas łańcuch ten miał do wykonania tylko jedno zadanie. Walidacji bloków i utrzymywanie konsensusu sieci. Nie można tam było nawet przeprowadzać transakcji (za wyjątkiem przyłączenia się do stakingu/walidacji sieci). Do tej pory więc testowano warstwę konsensusu. Podczas nadchodzącego tygodnia zostanie ona połączona z warstwą wykonawczą (transakcje, smart contracty) obecnego łańcucha Ethereum. Który w tym procesie porzuci swoją dotychczasową warstwę konsensusu – Proof of Work. Dość dobrze obrazuje to grafika opublikowana przez Fundację Ethereum:

Sam proces można przyrównać do wymiany silników w odrzutowcu pasażerskim. Podczas lotu. Z pasażerami na pokładzie. Warstwa konsensusu to silniki. Warstwa wykonawcza to kabina, w której siedzą pasażerowie. Część z nich śpi. Część ogląda filmy. Inni ze sobą rozmawiają czy popijają drinki. I nagle, w sposób w teorii niezauważalny, bez międzylądowania, w tym samolocie mają zostać zmienione silniki. A pasażerowie w kabinie mają nawet tego nie odnotować. 

Ale ponieważ proces ten wywołuje spore poruszenie i towarzyszą mu zarówno pewne ryzyka (a co jeśli nowy silnik nie będzie działał?) jak i okazje (co się stanie ze starym silnikiem? Można go zezłomować? Czy mogę na tym zarobić), to nawet jak proces będzie przebiegał sprawnie, to w tym czasie może być gorąco. I dziać się mogą rzeczy, o których nawet fizjonomom się nie śniło.

Jak się do tego przygotować?

Z perspektywy zwykłego użytkownika Ethereum nie trzeba przygotowywać się wcale. Nie trzeba wykonywać żadnych kroków. Można sobie dalej oglądać seriale, popijać drinki czy spać na pokładzie naszego odrzutowca Ethereum.

Ale ponieważ jesteśmy w krypto, to zapewne jesteśmy też pazerni. Słyszeliśmy, że będzie można zarobić na złomowaniu tych starych silników (hard fork). No i oczywiście chcemy z tej okazji skorzystać. Okazję tę opisujemy w kolejnej sekcji.

Miners will be miners i jak na tym zarobić?

No dobra, Ethereum sobie przechodzi na PoS. Ale tam zostaje miliony kart graficznych, które do tej pory kopały Ethereum PoW. Przecież oni nadal potrzebują coś kopać, aby na tym zarabiać. Przecież wszyscy z nich nagle nie zaczną grać na tych kartach w Cyberpunka.

Tak więc górnicy (głównie chińska społeczność) stwierdziła, że będa oni nadal pielęgnować obecny łańcuch Ethereum, dalej z mechanizmem konsensusu Proof of Work. Dlatego będę robić swojego hard forka, który m.in. usunie bombę trudności kopania oraz zmieni ID sieci. Pierwsza zmiana usuwa zbudowany w Ethereum mechanizm parabolicznego wzrostu trudności kopania, która zabezpiecza sieć przed buntem górników przed przejściem na PoS. Drugi sprawia, że ETHW nie będzie dzielił tego samego chain id co Ethereum. Co zapobiega występowaniu kilku problemów, takich jak np. replay attack. Chociaż te zmiany, chociaż zapowiedziane, nie zostały jeszcze (poranek 9 września 2022) wprowadzone do kodu. Jeśli to nie nastąpi, to można się spodziewać, że niektóre (a może większość) giełd nie będzie w ogóle chciało listować ETHW (ponieważ to giełdy są najbardziej narażone na replay attack, który możliwy jest do przeprowadzenia na dwóch sieciach o tym samym chain id). W kontekście naszego bezpieczeństwa, jeśli ETHW nie zmieni swojego chain id to dokładnie takie same transakcje z tej sieci mogą być potem odtworzone na mainnecie Ethereum (i vice versa). Jak naprościej się zabezpieczyć? Ograniczyć korzystanie z ETHW do minimum. To znaczy do ewentualnego przesłania ETHW na giełdę. Upewniając się wcześniej, czy giełda ta daje nam taki sam adres do depozytu zarówno dla ETH, jak i ETHW. Na wypadek, jakby ktoś chciał nas strollować i powtórzyć tą transakcję na mainnecie.

Tak więc po przejściu na PoS będziemy mieć dwie sieci i dwa Ethery. ETH działające już na PoS oraz ETHW działające cały czas na PoW. W momencie ich rozdzielenia będą one mieć dokładnie takie samy warstwy wykonawcze. Oznacza to, że na obydwu sieciach będziemy mieli taki sama balans ETH(W) oraz wszystkich innych tokenów. 

Dwa razy więcej Etheru i dwa razy więcej każdego tokenu? Zajebiście, brzmi jak dwa razy więcej pieniędzy. No nie do końca. Może brzmieć jak trochę więcej pieniędzy i zaraz sobie opowiemy o tym, jak się po nie schylić.

To że na drugiej sieci (ETHW) dostaniemy kopie naszych tokenów nie oznacza, że będę one warte tyle samo co oryginalne na ETH. To znaczy, w pierwszym bloku, na lokalnych DEXach względem siebie tak. Jednak właściwie wszystkie z nich nie są wspierane na sieci ETHW przez swoich twórców i nie będą mieć płynności na zewnętrznych giełdach. A to oznacza, że każdy będzie się ich pozbywał w celu zdobycia jak największej ilości ETHW. Bowiem ono będzie miało płynność na zewnętrznych CEXach. I pewnie przynajmniej początkowo będzie trzymać jakąś wartość. Natomiast wszystkie tokeny na sieci ETHW będę stosunkowo szybko dążyły w okolice zera (do którego jednak nigdy nie uda im się dojść).
Tak więc mojej perspektywy, aby zarobić na złomowaniu starych silników Ethereum, najlepiej jest mieć w momencie The Merge jak najwięcej Etheru. Aby uzyskać je też na ETHW i trochę zarobić na ich sprzedaży.

Co dla mnie znaczy jak najwięcej? Jak najwięcej bez bawienie się w inżynierię finansową i bez podejmowania dodatkowego ryzyka. Oznacza to przeniesienie ETH z innych sieci oraz wypłatę ich ze smart contractów.

Przenosimy je z innych sieci, ponieważ to balans z Ethereum dostaniemy na ETHW. Nie będą tam uwzględnione Ethery (i tokeny) z innych sieci. Nawet jak są to drugie warstwy Ethereum (jak Arbitrum One czy Optimism). Jeśli jeszcze nie wykonałeś tego kroku, to jest to najlepszy moment. Zostało jeszcze kilka dni do The Merge, więc ceny gasu są pewnie jeszcze znośne. Tutaj uwaga, że oficjalne mosty optymistycznych L2 jak Optimism czy Arbitrum One mogą nam już nie zdążyć przesłać ETH przed Mergem. Ponieważ potrzebuje one kilkudniowego okresu, w którym można kwestionować poprawność transakcji. Dlatego jeśli naszą intencją jest zdążyć przez The Merge, to korzystajmy z mostów, które prześlą nam środki w kilka minut.

Wypłacamy je ze smart contractów, po to aby ETHW mieć bezpośredniu na swoim portfelu i jedną transakcją przesłać je CEX, aby tam je zdumpować. Jeśli dostaniemy ETHW w smart contracie, to bądźmy świadomi, że najprawdopodobniej będziemy w stanie wypłacić go mniej albo i wcale. Tak jak wspomniałem, ludzie (a właściwie to boty) będą wrzucać w pule płynności, zastawy wszystkie inne tokeny, aby wyjąć z nich jak najwięcej ETHW, który jako jedyny może mieć tam jakąś wartość.

Tak więc ja już jakiś czas temu przeniosłem swoje ETH z L2ek na Mainnet Ethereum. I to jest moje jedyne działanie, jakie podejmuje w tym temacie. Nie zastawiam swoich stETH (które nie darzą mi ETHW po drugiej stronie) ani stablecoinów, aby pożyczyć jak najwięcej ETH. Dlaczego? Boję się ryzyk, które mogą się zmaterializować w wyniku potencjalnych anomalii, które opiszę w kolejnej sekcji. Nie jest to też działanie kosztowne (zarówno w cenach gasu, czasu jak i myślenia koncepcynego), więc jest to cena jaką jestem gotów zapłacić, nawet jakby ten fork miał się nie odbyć bądź ETHW miało kosztować nie więcej niż kilka USD.

Nie otwieram też krótkoterminowych pozycji pod to wydarzenie. Hodlerka to jest dziedzina, w której dobrze się czuje. Spekulacje wychodzi mi co najwyżej średnio. I kosztuje zbyt dużo czasu i nerwów. No i dochodzą też wspomniane wyżej i opisane poniżej anomalie

Anomalie towarzyszące The Merge

Ponieważ wszyscy mogą chcieć mieć jak najwięcej ETH na swoich portfelach, to może to rodzić kilka poważnych reperkusji.

Po pierwsze znacząco może ucierpieć płynność. I to zarówno na DEXach, jak i na giełdach scentralizowanych. A mniejsza płynność, to większa podatność na zmienność cenową. Zwłaszcza, gdy po drugiej stronie mamy duże zainteresowanie, niepewność oraz armię spekulantów rozgrywających to krótkoterminowo. 

Płynności dla ETH może też zabraknąć w protokołach lokatowo-pożyczkowych. Ludzie mogą pożyczać Ether, aby dostać go więcej po drugiej stronie, a następnie oddać. Z drugiej strony kapitał z lokat ETH może być również wypłacany w tym samym celu. Gdzie w ekstremalnych sytuacjach może dojść do kryzysu płynności (chwilowej nie możliwości wypłaty środków). A przynajmniej tymczasowego wzrostu opłacalności lokat w ETH oraz wzrost kosztów kredytu w tej walucie.

Przenoszenie ETH na Ethereum może sprawić, że zabraknie również płynności na mostach po stronie Mainnetu Ethereum. Zwłaszcza, że oficjalne mosty drugich optymistycznych warstw, które mają największą przepustowość już nie zdążą dostarczyć nam Etheru przed forkiem.
Część z tych operacji, aby obniżyć koszt kapitału, duzi gracze mogą chcieć wykonać tuż przed i tuż po hard forku. Może to wywołać znaczący wzrost cen gasu w tym okresie.

Możemy też spodziewać się, że zarówno protokoły jak i CEXy będą pauzować część aktywności związanych z Etherem. AAVE już w tym tygodniu przegłosowało zapauzowanie pożyczek w ETH do czasu przeprowadzenia merga.

Duże przeciążenie sieci oraz samych giełd może sprawić, że giełdy również będą miały problemy. Czy to z wpłatami/wypłatami czy być może nawet z ogólnym działaniem, jeśli napotkają wzmożony ruch związany z dużym zainteresowanie spekulantów oraz ewentualną dużą zmiennością w tym czasie. A powtórzmy raz jeszcze, to dużej zmienności na ETH może prowadzić ograniczona płynność w tym czasie.

Ja polecam w tym czasie ograniczyć naszą działalność w krypto do minimum. Zadbać też zawczasu o to, aby nasze pozycje w DeFi nie miały problemu z przetrwaniem ewentualnej zawieruchy. 

Jak przygotować się na najgorsze?

Proces przejścia na PoS był planowany, implementowany oraz testowany przez lata. Zanim nastąpi migracja mainnetu ten sam proces przeszły wszystkie testnety Ethereum. Dokonano też kilkanaście tzw. shadow forków samego mainnetu. Wszystko przebiegło dobrze i wszystko wskazuje na to, że tak samo będzie w przyszłym tygodniu.

Jeśli jednak chcesz się przygotować na najgorszy scenariusz, nie powodzenie całego procesu przejścia, to tutaj masz kilka wskazówek:

  • Ethereum nie planuje przestać działać podczas procesu przechodzenia na PoS. Warstwa wykonywania ma cały czas działać. Po prostu w pewnym momencie jeden blok będzie wykopany przez PoW, a kolejny już zwalidowany przez PoS. Przez pierwsze kilka(naście) minut nowy mechanizm konsensusu może poszukiwać swojej finalności, więc najlepiej w tym czasie nie przeprowadzać transakcji (chociaż będzie to możliwe). Natomiast jeśli sieć w ogóle przestała by działać, to może to wywołać chwilową panikę, ale nie zapominajmy o tym, że mamy projekty w TOP10 crypto, którym taka sytuacja zdarza się cyklicznie. I świat się na tym nie skończy
  • Przenoszenie Etheru (czy tokenów czerpiących natywnie wartość z tej sieci) nie specjalnie ma sens i zabezpieczy Cię przed czymkolwiek. Zazwyczaj bowiem po prostu dostaniesz token o takiej samej nazwie, który nie jest jednak respektowany przez sam projekt. A jego wartość pochodzi właśnie ze źródła na Ethereum
  • Jeśli chcesz dmuchać na zimne, to może sensowne jest przeniesienie z Ethereum, tokenów, których źródło wartości jest poza Ethereum. Będą to na przykład zwrapowane tokeny innych waluty (np. WBTC) czy scentralizowane stablecoiny (USDC, USDT, BUSD etc). W przypadku zwrapowanych krypto przechodzimy do natywnej sieci danej krypto. W przypadku scentralizowanych stablecoinów do jednej z oficjalnie wspieranych sieci przez emitenta (dbając o to, aby most z którego korzystamy, dał nam token oficjalnie wspierany przez emitenta).

Co czeka nas po Mergu?

To dokładnie omówiliśmy sobie podczas jednego z ostatnich webinarów. Jego darmowy fragment znajduje się poniżej:

A całość dostępna jest w Krypto Krypcie.

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ść.

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:

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.

Dzisiaj porozmawiamy o projekcie z ekosystemu Terra, który pomoże w zachowaniu naszej prywatności. A także obdaruje nas za jakiś czas airdropem.

Problem

Blockchain ma mnóstwo zalet. Jedną z nich jest transparentność. Oznacza to, że wszystkie transakcje w nim zawarte są dostępne do wglądu dla każdego. Rodzi to za sobą wiele implikacji. Między innymi takie, że różne strony trzecie mogą obserwować nasze transakcje. I być może na ich podstawie podejmować niebezpieczne dla nas kroki. Takie ryzyko może czekać na nas ze strony zawistnych sąsiadów, konkurencji biznesowej czy państwowych organów represji.

Wprawdzie na blockchainie nie jest znana nasza tożsamość. Jedynie adres naszego portfela. Z którego nie da się bezpośrednio odczytać tożsamości jego posiadacza. Jednak obecne regulacje sprawiają, że jest bardzo duże prawdopodobieństwo, że ujawniliśmy naszą tożsamość w miejscu, które może powiązać je z adresem naszego portfela. Najczęściej będzie to giełda kryptowalut czy platforma launchpadowa, na której przeszliśmy procedurę KYC. Następnie taka instytucja (czy organy nadzoru) może powiązać nasz adres z naszą tożsamością. A z historii transakcji na blockchainie jest w stanie odczytać o nas sporo informacji. Co jeśli nam się to nie podoba?

Rozwiązanie

Rozwiązania są w sumie dwa. Pierwsze z nich to korzystanie z sieci, które mają wbudowane w protokół mechanizmy prywatności transakcji. Przykłady takich sieci to Monero, ZCash czy Secret Network. Więcej na ich temat mówiliśmy podczas webinaru na temat prywatności i anonimowości w krypto.

Niestety zazwyczaj takie sieci mają ograniczone możliwości, szczególnie w kontekście DeFi i zarabiania na nim. Co jeśli chcemy zadbać o prywatność w sieci, która jest miejscem naszych głównych aktywności i zysków? Czy jest taka możliwość? Tak.

Niektóre ekosystemy oferujące obsługę smart contractów oferują specjalne aplikacje, które miksują nasze transakcje z innymi, a tym samym przerywają szlak, po którym można namierzyć naszą transakcję. Wpłacamy środki do wspólnego worka. One sobie tam leżą przez jakiś czas. Następnie je sobie wypłacamy na inny adres. I nie można w prosty, bezpośredni sposób stwierdzić, czyje środki sobie wypłaciliśmy. 

Najpopularniejszym takim mikserem jest Tornado Cash na sieci Ethereum. A my dzisiaj pokażemy sobie odpowiednik z sieci Terra. Nazywa się on Terrnado Cash i działa w następujący sposób:

  • Wpłacamy do Terrnado nasze środki. Podczas przeprowadzania transakcji dostajemy specjalną notkę, która umożliwia potem wypłacenie środków na inny adres.
  • Dajemy naszym coinom poleżeć trochę w mikserze, aby wymieszały się z innymi wpłatami. Utrudni to powiązanie ze sobą naszych transakcji wpłaty i wypłaty
  • Jeśli wpłaciliśmy UST, to podczas “leżakowania” trafia ono na Anchora, gdzie generuje dla nas odsetki
  • Następnie, gdy środki naszym zdaniem poleżakowały dostatecznie długo, to wypłacamy je. Podajemy wtedy notkę wygenerowaną podczas wpłaty oraz adres, na który ma być dokonana wypłata.

Po takiej procedurze połączenie naszej wpłaty i wypłaty jest bardzo utrudnione. Przerywamy więc historię naszych transakcji. No i kwalifikujemy się na airdrop, o którym mowa w ostatniej sekcji tego artykułu.

Jak to sobie przeklikać

Poniżej znajduje się szczegółowa instrukcja wideo, jak sobie w praktyce przeklikać Terrnado:

Podkreślam, że z serwisu nie należy korzystać z portfela zintegrowanego z portfelem sprzętowym Ledger. Nie jest on bowiem w stanie podpisać drugiej transakcji, która generuje dla nas notkę potrzebną do wypłaty środków. Korzystając z ledgera będziemy mogli wpłacić środki, ale nie wygenerujemy notki potrzebnej do ich wypłaty.

Token oraz Airdrop

Większość z Was jest tutaj zapewne dlatego, że Terrnado ma mieć token ($TND) i obiecany jest retrospektywny airdrop dla użytkowników. Najpierw przyjrzymy się tokenowi. Będzie się on nazywał $TND i zastakowany (bondowany) będzie pozwalał na partycypowanie w zyskach protokołu. A protokół ma tak naprawdę trzy produkty (elementy). Pierwszy to umówiony powyżej Anonimizator transakcji. Za korzystanie, z którego płaci się 0,5% fee przy wypłacie. Drugi to sam token. Którego transfer oraz sprzedaż jest obłożona podatkiem (za chwilę sobie to rozpiszemy). Trzeci to Vault, do którego trafiają zyski z dwóch wcześniejszych produktów. I token pozwala nam na partycypowanie w tych zyskach.

Przejdźmy teraz do omówienia opłat i podatków.

Po pierwsze 0,5 wartości wypłaty z Anonimizera trafia do Vaulta projektu. Po drugie transfery i swapy związane z tokenem $TND są obaczone 5 procentowym podatkiem. Oto jak rozdzielane są te procenty:

  • 1 procent ma być spalany, co ma ograniczać ilość tokenów w obiegu
  • 1 procent ma być wykorzystywany do airdropu użytkowników Terrnado
  • 1,5 procenta trafia do puli płynności
  • 1,5 procenta trafia do Vaulta (z czego korzystają stakujący $TND)

Więcej informacji na temat tokenomii (jak i samego działania projektu), znajdziesz w whitepaperze.

Na koniec jest dwa zdania na temat airdropu. Zespół deklaruje późniejsze wynagrodzenie tokenami swoich wczesnych użytkowników. Do tego celu przeznaczone jest 10 procent wszystkich tokenów.

Wejść w posiadanie tokenu będziemy mogli również biorac udział w jednym z IDO, które zespół planuje przeprowadzić na kilku platformach. Na StarTerra zaczyna się ono za kilka dni.