Przewodnik dla początkujących po TON: konta, tokeny i bezpieczeństwo
Kontekst
TON (The Open Network) to zdecentralizowana platforma blockchain początkowo zaprojektowana i opracowana przez zespół Telegram. TON ma na celu zapewnienie wysokowydajnej i skalowalnej platformy blockchain do obsługi zdecentralizowanych aplikacji na dużą skalę (DApps) i inteligentnych kontraktów.
TON jest wyjątkowy, ponieważ jest łatwy w użyciu, głęboko zintegrowany z Telegramem, umożliwiając zwykłym ludziom łatwe korzystanie z tokenów. Jednocześnie jest złożony, z architekturą, która różni się od innych blockchainów, i wykorzystuje niebędący głównym nurtem język inteligentnych kontraktów o nazwie FunC.
Dzisiaj omówimy charakterystykę TON i bezpieczeństwo zasobów użytkowników z perspektywy kont, tokenów i transakcji.
Charakterystyka TON
Generowanie kont
Metoda generowania adresu konta w TON różni się od większości blockchainów; jest to adres inteligentnego kontraktu. Po pierwsze, wszystko zaczyna się od klucza prywatnego. TON wykorzystuje przede wszystkim algorytm Ed25519 do generowania klucza publicznego, a proces ten wygląda następująco:
Istnieją dwie formy klucza publicznego: jedna to surowy klucz publiczny obliczony na podstawie klucza prywatnego, który wygląda następująco:
E39ECDA0A7B0C60A7107EC43967829DBE8BC356A49B9DFC6186B3EAC74B5477D
Drugi to „upiększony” klucz publiczny, który zawiera pewne informacje i bity kontrolne i wygląda następująco:
Pubjns2gp7DGCnEH7EOWeCnb6Lw1akm538YYaz6sdLVHfRB2
Jeśli myślisz, że samo uzyskanie klucza publicznego pozwoli ci uzyskać adres konta, tak jak w Ethereum, to się mylisz. Samo posiadanie klucza publicznego użytkownika nie wystarczy do obliczenia adresu konta użytkownika.
Jak wspomniano, adres konta użytkownika jest adresem inteligentnego kontraktu, ale jak można wdrożyć inteligentny kontrakt bez posiadania konta?
Prawidłowa kolejność to najpierw obliczenie adresu, otrzymanie pewnej początkowej ilości tokenów, a następnie wdrożenie kontraktu. Proces obliczania adresu konta przedstawiono na poniższym diagramie:
Adres użytkownika również występuje w wielu formach. Po pierwsze, istnieje nieprzetworzona forma, która wygląda następująco:
0:b4c1b2ede12aa76f4a44353944258bcc8f99e9c7c474711a152c78b43218e296
Następnie dostępny jest przyjazny dla użytkownika formularz, który wygląda następująco:
Sieć główna:
- Odbicie:
EQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilkPX - Bez możliwości odbicia:
UQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilh4S
Testnet:
- Odbicie:
kQC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0Mhjilvhd - Bez możliwości odbicia:
0QC0wbLt4Sqnb0pENTlEJYvMj5npx8R0cRoVLHi0MhjilqWY
Uważnie obserwując te adresy, można zauważyć, że różnią się one tylko kilkoma pierwszymi i ostatnimi znakami, a środkowe account_id jest takie samo.
Nadal jednak nie widzimy związku między kluczem publicznym a adresem konta.
Sekret tkwi w initial data na początku, który zawiera klucz publiczny użytkownika, pozwalając mu kontrolować kontrakt portfela. workchainId jest łatwy do zrozumienia; TON nie jest tylko pojedynczym łańcuchem, ale składa się z wielu odłamków.
Każdy shard jest częścią całej sieci, obsługującą określone konta i transakcje. Aby zlokalizować inteligentne kontrakty i zarządzać nimi, konieczne jest określenie, w którym shardzie się znajdują. Jaka jest różnica między Bounceable a Non-bounceable?
Odnosi się to do sposobu działania inteligentnych kontraktów, ale spójrzmy dalej.
Umowa portfela
Poniżej znajduje się fragment kodu źródłowego kontraktu portfela użytkownika. Pokazuje on, że po otrzymaniu wiadomości od użytkownika odczytuje on cztery parametry: stored_seqno, stored_subwallet, public_key i plugins:
wallet-v4-code.fc
() recv_external(slice in_msg) impure {
var signature = in_msg~load_bits(512);
var cs = in_msg;
var (subwallet_id, valid_until, msg_seqno) = (cs~load_uint(32), cs~load_uint(32), cs~load_uint(32));
throw_if(36, valid_until <= now());
var ds = get_data().begin_parse();
var (stored_seqno, stored_subwallet, public_key, plugins) = (ds~load_uint(32), ds~load_uint(32), ds~load_uint(256), ds~load_dict()); ;;##The Initial Data
ds.end_parse();
throw_unless(33, msg_seqno == stored_seqno);
throw_unless(34, subwallet_id == stored_subwallet);
throw_unless(35, check_signature(slice_hash(in_msg), signature, public_key));
//...
}Rzeczywiście, gdy ta umowa portfela użytkownika jest wdrażana, wymaga pewnych parametrów początkowych, w tym 256-bitowego public_key. Gwarantuje to, że każdy użytkownik ma unikalny adres kontraktu, nawet jeśli używa tego samego kodu kontraktu.
Każda transakcja zainicjowana przez użytkownika musi zostać podpisana kluczem in_msg, a następnie zweryfikowana przez kontrakt portfela (check_signature), po czym kontrakt wykona operacje na blockchainie. Z tego możemy wywnioskować, że klucz publiczny użytkownika może odpowiadać wielu adresom portfela.
Wdrożenie różnych kontraktów portfela lub użycie innych danych inicjalizacyjnych spowoduje, że adresy kontraktów będą zupełnie inne.
Token Jetton
Token reprezentuje aktywa na blockchainie, co czyni go podstawowym elementem, który musimy zrozumieć. Jetton jest standardową formą tokenów TON i składa się z dwóch kontraktów: Jetton-minter i Jetton-wallet.
Po wydaniu tokena tworzony jest kontrakt Jetton-minter. Ta inicjalizacja kontraktu rejestruje informacje, takie jak całkowita podaż tokenów, administrator, kod portfela i inne szczegóły.
Gdy tokeny są dystrybuowane do użytkowników, kontrakt Minter wdraża kontrakt portfela dla każdego użytkownika. Podczas inicjalizacji kontraktu rejestruje saldo użytkownika, własność, adres kontraktu tokena Minter, kod portfela użytkownika i inne istotne informacje. Każdy użytkownik ma indywidualnie wdrożony kontrakt.
Ważne jest, aby pamiętać, że utworzona tutaj umowa jest umową portfela do zarządzania określonymi tokenami Jetton, która różni się od umowy portfela konta użytkownika. Zarejestrowane tutaj owner_address to adres portfela konta użytkownika.
Gdy użytkownik Alice przekazuje tokeny użytkownikowi Bob, relacja wywołania jest następująca:
Alice podpisuje transakcję za pośrednictwem aplikacji poza łańcuchem i wysyła polecenie operacyjne za pośrednictwem kontraktu portfela. Polecenia te będą dalej wywoływać jej portfel tokenów w celu wykonania transferu. Gdy portfel tokenów Boba otrzyma tokeny, powiadamia o tym kontrakt portfela Boba (adres właściciela portfela Jetton Boba).
Jeśli podczas transakcji pozostaną jakieś resztki gazu, zostaną one zwrócone na odpowiedni adres, zwykle na umowę konta Alice.
Poniżej znajduje się przykład transferu tokena Jetton analizowanego przez przeglądarkę Tonviewer:
Podczas gdy transfer ERC20 wymaga tylko jednego wywołania kontraktu, transfer tokena Jetton wymaga co najmniej czterech wywołań kontraktu. Metoda ta ma na celu umożliwienie współbieżności w łańcuchu, poprawiając wydajność transakcji.
Transakcje
Gdy na koncie TON wystąpi określone zdarzenie, uruchamia ono transakcję. Najczęstszym zdarzeniem jest „otrzymanie wiadomości”. Transakcja zawiera następujące elementy:
- Przychodząca wiadomość, która początkowo uruchamia kontrakt (z dostępnymi specjalnymi metodami wyzwalania).
- Działania związane z umową wynikające z przychodzącego komunikatu, takie jak aktualizacja magazynu umowy (opcjonalnie).
- Wiadomości wychodzące wysyłane do innych uczestników (opcjonalnie).
Istnieje kilka kluczowych cech, o których należy pamiętać w odniesieniu do transakcji:
- Asynchroniczny: Transakcje TON nie są wykonywane w jednym wywołaniu; mogą one wymagać przekazywania wiadomości do wielu różnych inteligentnych kontraktów w celu wykonania serii wywołań. Ze względu na różny routing w łańcuchach sharded, TON nie może zagwarantować kolejności dostarczania wiadomości między wieloma inteligentnymi kontraktami.
- Opłaty: Asynchroniczny charakter transakcji stanowi wyzwanie przy szacowaniu zużytych opłat. Dlatego portfele często wysyłają dodatkowy token jako opłatę podczas inicjowania transakcji. Jeśli wywołany kontrakt ma dobry mechanizm obsługi opłat, pozostałe opłaty zostaną zwrócone do portfela użytkownika. Użytkownicy mogą zauważyć, że liczba tokenów w ich portfelach nagle spada, a następnie ponownie rośnie po kilku minutach, co jest spowodowane tym mechanizmem.
- Odbicie: Bounce to mechanizm obsługi błędów w kontraktach. Jeśli wywoływana umowa nie istnieje lub wyrzuca błąd, a transakcja jest ustawiona jako możliwa do odrzucenia, wiadomość o odrzuceniu zostanie zwrócona do wywołującej umowy. Na przykład, jeśli użytkownik zainicjuje przelew i wystąpi błąd podczas procesu, wiadomość odbijająca jest konieczna, aby umowa portfela użytkownika mogła przywrócić saldo. Prawie wszystkie wewnętrzne wiadomości wysyłane między inteligentnymi kontraktami powinny być możliwe do odbicia, co oznacza, że powinny mieć ustawiony bit „bounce”.
Bezpieczeństwo aktywów
TON ma wiele funkcji, które mogą prowadzić do problemów z bezpieczeństwem, więc użytkownicy muszą być świadomi niektórych typowych pułapek.
Atak polegający na potrącaniu opłat
Jak wspomniano, portfele często muszą wysyłać niewielką dodatkową opłatę, aby zapobiec niepowodzeniu transakcji, co stanowi okazję dla atakujących. Jeśli jesteś użytkownikiem portfela TON, być może spotkałeś się z sytuacją, w której Twój portfel często otrzymuje różne NFT lub tokeny.
Początkowo mogą one wydawać się zrzutami śmieciowych tokenów, ale po sprawdzeniu szczegółów transakcji okazuje się, że można je sprzedać za znaczną kwotę pieniędzy. Kiedy jednak próbujesz zainicjować transakcję, zauważasz, że wymagana opłata jest niezwykle wysoka (1 TON). W tym momencie należy zachować ostrożność, ponieważ może to być oszustwo związane z opłatami.
Atakujący tworzą starannie spreparowaną umowę tokena, która powoduje, że portfel szacuje zbyt wysoką opłatę za przelew, ale w rzeczywistości tylko opłata jest wstrzymywana i nie jest wysyłana żadna wiadomość przelewu.
Phishing pierwszej i ostatniej cyfry
Wyłudzanie pierwszych i ostatnich cyfr nie jest unikalne dla TON; ten atak phishingowy istnieje na wielu głównych blockchainach. Atakujący generują fałszywe konto dla każdego adresu użytkownika w sieci z tymi samymi pierwszymi i ostatnimi cyframi.
Gdy użytkownik inicjuje przelew, atakujący wysyła również mały przelew, następujący po transakcji użytkownika, aby pozostawić zapis w historii transakcji użytkownika. Gdy użytkownik-odbiorca chce odesłać tokeny, może skopiować adres ze swojej historii transakcji, który może być adresem atakującego, co prowadzi do przelewu na niewłaściwy adres. Atakujący dokładnie wykorzystał zachowanie użytkownika.
Komentarz Phishing
Podczas przesyłania tokenów w TON użytkownicy mogą dodać komentarz, aby opisać transakcję. Ta funkcja jest często używana podczas dokonywania wpłat na giełdach, gdzie giełdy zwykle wymagają od użytkowników podania swojego identyfikatora użytkownika w komentarzu do wpłaty. Funkcja ta jest jednak często wykorzystywana przez złośliwe podmioty, które piszą fałszywe informacje w komentarzach, aby ukraść aktywa użytkowników. Na przykład:
Użytkownicy powinni zachować szczególną ostrożność w przypadku NFT „Anonimowy numer Telegrama”. Jeśli użytkownik aktywuje swoje konto Telegram za pomocą anonimowego numeru Telegram, ale nie włączy weryfikacji dwuetapowej, a ten NFT zostanie wyłudzony, haker może bezpośrednio zalogować się na docelowe konto Telegram i kontynuować kradzież aktywów i oszukańcze działania.
Podatności inteligentnych kontraktów
Luki w zabezpieczeniach inteligentnych kontraktów mogą prowadzić do utraty środków przechowywanych w kontrakcie. Użytkownicy powinni wybierać projekty, które przeszły dokładny audyt. Inteligentne kontrakty TON są głównie programowane przy użyciu języka FunC, chociaż niektóre używają bardziej zaawansowanego Tact lub niższego poziomu Fift.
Wszystkie te języki są bardzo oryginalne. Nowe języki programowania niosą ze sobą nowe zagrożenia bezpieczeństwa, szczególnie dla programistów, którzy muszą ćwiczyć bezpieczne nawyki kodowania, opanować najlepsze praktyki bezpieczeństwa i przejść rygorystyczne audyty bezpieczeństwa przed wdrożeniem do środowiska produkcyjnego. Ze względu na ograniczoną ilość miejsca, niniejszy artykuł nie będzie szczegółowo omawiał bezpieczeństwa kontraktów.
Atak fałszywych depozytów
Użytkownicy portfeli lub giełd powinni być świadomi fałszywych ataków depozytowych, które zwykle przybierają dwie formy:
- Fałszywe tokeny: Atakujący wydaje token z metadanymi identycznymi z tokenem docelowym. Jeśli zautomatyzowany program depozytowy nie sprawdzi, czy token pochodzi z właściwego kontraktu górniczego, może to prowadzić do nieprawidłowych depozytów.
- Odbicie: Proces transferu TON wymaga relacji wywołania między umowami portfela dwóch użytkowników. Jeśli umowa portfela odbiorcy nie istnieje, a transakcja jest ustawiona jako możliwa do odrzucenia, wiadomość zostanie odrzucona, a oryginalne środki, pomniejszone o opłatę, zostaną zwrócone nadawcy. Osoby zainteresowane szczegółami mogą zapoznać się z naszym poprzednim artykułem na temat fałszywych depozytów.
Wnioski
W tym artykule przedstawiono kilka podstawowych zasad technicznych TON z perspektywy tworzenia kluczy i portfeli, form tokenów i charakterystyki transakcji. Zbadano również potencjalne kwestie bezpieczeństwa podczas korzystania z TON, mając nadzieję, że zainspiruje to do nauki.