Autor: @Web3Mario

Wprowadzenie: Wraz z uruchomieniem Notcoin, największej gry w ekosystemie TON, na Binance i ogromnym efektem bogactwa spowodowanym modelem ekonomicznym tokenów z pełnym obiegiem, TON zyskał dużą uwagę w krótkim czasie. Po rozmowie ze znajomym dowiedziałem się, że próg techniczny TON jest stosunkowo wysoki, a paradygmat programowania DApp bardzo różni się od głównych protokołów sieci publicznych, więc spędziłem trochę czasu na dogłębnym badaniu powiązanych tematów i podzieliłem się z Wami pewnymi spostrzeżeniami. Krótko mówiąc, podstawową koncepcją projektową TON jest rekonstrukcja tradycyjnego protokołu blockchain w sposób „oddolny” i osiągnięcie wysokiej współbieżności i wysokiej skalowalności kosztem interoperacyjności.

Podstawową ideą projektową TON jest wysoka współbieżność i wysoka skalowalność

Można powiedzieć, że celem wszystkich skomplikowanych wyborów technologii w TON jest dążenie do wysokiej współbieżności i wysokiej skalowalności. Oczywiście nie jest nam trudno to zrozumieć od momentu jego narodzin. TON, czyli The Open Network, to zdecentralizowana sieć komputerowa zawierająca łańcuch bloków L1 i wiele komponentów. TON został pierwotnie opracowany przez założyciela Telegramu Nikołaja Durowa i jego zespół, a obecnie jest wspierany i utrzymywany przez globalną społeczność niezależnych współpracowników. Jej narodziny datuje się na rok 2017, kiedy zespół Telegramu zaczął samodzielnie poszukiwać rozwiązań blockchain. Ponieważ żaden istniejący wówczas łańcuch bloków L1 nie był w stanie obsłużyć dziewięciocyfrowej bazy użytkowników Telegramu, postanowiono zaprojektować własny łańcuch bloków, nazwany wówczas Telegram Open Network. Nadszedł rok 2018. Aby pozyskać środki potrzebne do wdrożenia TON, Telegram w pierwszym kwartale 2018 roku uruchomił sprzedaż tokenów Gram (później przemianowanych na Toncoin). W 2020 roku zespół Telegramu wycofał się z projektu TON ze względu na kwestie regulacyjne. Następnie niewielka grupa programistów open source i zwycięzców konkursów Telegramu przejęła bazę kodową TON, zmieniła nazwę projektu na The Open Network i do dziś aktywnie rozwija blockchain, kierując się zasadami przedstawionymi w oryginalnej białej księdze TON.

Ponieważ więc został zaprojektowany jako zdecentralizowane środowisko wykonawcze Telegramu, musi naturalnie stawić czoła dwóm problemom: dużej liczbie jednoczesnych żądań i ogromnej ilości danych. Wiemy, że wraz z obecnym rozwojem technologii Solana, znana jako najwyższy TPS, ma najwyższy zmierzony TPS wynoszący zaledwie 65 000, co oczywiście nie wystarczy do obsługi ekosystemu Telegramu, który wymaga milionów TPS. Jednocześnie przy zastosowaniu na dużą skalę Telegramu ilość generowanych przez niego danych przekroczyła już niebo. Jako niezwykle redundantny system rozproszony, blockchain wymaga, aby każdy węzeł w sieci zapisywał pełną kopię danych również nierealne.

Dlatego, aby rozwiązać powyższe dwa problemy, TON dokonał dwóch optymalizacji głównych protokołów blockchain:

• Stosując „paradygmat nieskończonego fragmentowania” przy projektowaniu systemu, rozwiązujemy problem redundancji danych, aby mógł on przenosić duże zbiory danych i łagodzić problem wąskiego gardła wydajności;

• Dzięki wprowadzeniu w pełni równoległego środowiska wykonawczego opartego na modelu Actor, sieciowy TPS ulega znacznej poprawie;

Utwórz łańcuch blockchain — dzięki nieograniczonym możliwościom fragmentowania każde konto ma ekskluzywny łańcuch kont

Wiemy teraz, że sharding stał się głównym rozwiązaniem dla większości protokołów blockchain w celu poprawy wydajności i zmniejszenia kosztów, a TON doprowadziło to do skrajności i zaproponowało paradygmat nieskończonego shardingu, tak zwany paradygmat nieskończonego shardingu dynamicznie zwiększaj lub zmniejszaj liczbę fragmentów w oparciu o obciążenie sieci. Ten paradygmat umożliwia TON obsługę transakcji na dużą skalę i operacji inteligentnych kontraktów przy zachowaniu wysokiej wydajności. Teoretycznie TON może ustanowić wyłączny łańcuch kont dla każdego rachunku i zapewnić interoperacyjność między tymi łańcuchami poprzez pewne zasady.

Aby zrozumieć to abstrakcyjnie, w TON istnieją cztery poziomy struktury łańcucha:

• Łańcuch kont: Ten łańcuch warstw reprezentuje łańcuch składający się z serii transakcji powiązanych z kontem. Powodem, dla którego transakcje mogą tworzyć strukturę łańcuchową, jest to, że w przypadku automatu stanowego, o ile reguły wykonywania są spójne, automat stanowy będzie: wyniki uzyskane po otrzymaniu instrukcji w tej samej kolejności są spójne, dlatego we wszystkich rozproszonych systemach typu blockchain wymagane jest łańcuchowe uporządkowanie transakcji i TON nie jest tu wyjątkiem. Łańcuch kont jest najbardziej podstawową jednostką składową sieci TON. Zwykle łańcuch kont jest koncepcją wirtualną i jest mało prawdopodobne, aby w rzeczywistości istniał niezależny łańcuch kont.

• Łańcuch odłamków: W większości kontekstów łańcuch odłamków jest rzeczywistą jednostką składową TON. Tak zwany łańcuch odłamków to zbiór łańcuchów kont.

• WorkChain: Można go również nazwać zestawem łańcuchów fragmentowania z niestandardowymi regułami, takimi jak tworzenie łańcucha pracy opartego na EVM i uruchamianie na nim inteligentnych kontraktów Solidity. Teoretycznie każdy członek społeczności może stworzyć własny łańcuch pracy. W rzeczywistości zbudowanie go jest dość złożonym zadaniem, poprzedzonym uiszczeniem (kosztownej) opłaty za jego utworzenie i uzyskaniem 2/3 głosów walidatorów do zatwierdzenia utworzenia Twojego łańcucha roboczego.

• Łańcuch główny (MasterChain): Wreszcie w TON istnieje specjalny łańcuch zwany łańcuchem głównym, który jest odpowiedzialny za doprowadzenie do finalności wszystkich łańcuchów odłamków. Kiedy hash bloku łańcucha fragmentu zostanie scalony z blokiem łańcucha głównego, ten blok łańcucha fragmentu i wszystkie jego bloki nadrzędne zostaną uznane za ostateczne, co oznacza, że ​​można je uznać za stałe i niezniszczalne. Do zmienionej zawartości odwołują się kolejne bloki wszystkich fragmentów więzy.

Przyjmując taki paradygmat, sieć TON ma następujące trzy cechy:

• Dynamiczne sharding: TON może automatycznie dzielić i łączyć łańcuchy fragmentów, aby dostosować się do zmian obciążenia. Oznacza to, że nowe bloki są zawsze generowane szybko, a transakcje nie wymagają długiego czasu oczekiwania.

• Wysoka skalowalność: dzięki paradygmatowi nieskończonego fragmentowania TON może obsługiwać niemal nieograniczoną liczbę fragmentów i teoretycznie może osiągnąć łańcuchy robocze od 2 do 60 potęgi.

• Możliwość adaptacji: gdy obciążenie części sieci wzrasta, tę część można podzielić na więcej fragmentów, aby obsłużyć zwiększony wolumen transakcji. I odwrotnie, gdy obciążenie spada, fragmenty można łączyć w celu zwiększenia wydajności.

Wtedy pierwszą rzeczą, z którą musi się zmierzyć taki wielołańcuchowy system, jest problem komunikacji międzyłańcuchowej, szczególnie ze względu na możliwość nieograniczonego shardingu, gdy liczba shardów w sieci osiągnie określony poziom, następuje routing informacji pomiędzy łańcuchami stanie się rzeczą trudną do zrobienia. Wyobraź sobie, że w sieci znajdują się 4 węzły. Każdy węzeł jest odpowiedzialny za utrzymanie niezależnego łańcucha pracy. Relacja łącza wskazuje, że oprócz tego, że jest odpowiedzialny za sortowanie transakcji w swoim własnym łańcuchu pracy, węzeł musi także monitorować i przetwarzać stan. zmiany w łańcuchu docelowym, realizowane w TON specjalnie poprzez monitorowanie komunikatów w kolejce wyjściowej,

Załóżmy, że konto A w łańcuchu pracy 1 chce wysłać wiadomość do konta C w łańcuchu pracy 3. Musisz zaprojektować problem routingu wiadomości. W tym przykładzie istnieją dwie ścieżki routingu, łańcuch roboczy 1 -> łańcuch roboczy 2 -> łańcuch roboczy 3 i łańcuch roboczy 1 -> łańcuch roboczy 4 -> łańcuch roboczy 3.

W przypadku bardziej złożonych sytuacji potrzebny jest wydajny i niedrogi algorytm routingu, aby szybko zakończyć komunikację wiadomości. Tak zwana struktura hipersześcianu odnosi się do specjalnej topologii sieci. N-wymiarowy hipersześcian składa się z 2^n wierzchołków, a każdy wierzchołek można jednoznacznie zidentyfikować za pomocą n-bitowej liczby binarnej. W tej strukturze dowolne dwa wierzchołki sąsiadują ze sobą, jeśli różnią się tylko jednym bitem w reprezentacji binarnej. Na przykład w hipersześcianie 3D wierzchołek 000 i wierzchołek 001 sąsiadują ze sobą, ponieważ różnią się tylko ostatnim bitem. Powyższy przykład to dwuwymiarowy hipersześcian.

W protokole routingu Hypercube proces routingu komunikatu ze źródłowego łańcucha roboczego do docelowego łańcucha roboczego jest wykonywany poprzez porównanie binarnych reprezentacji adresów źródłowego i docelowego łańcucha roboczego. Algorytm routingu znajduje minimalną odległość (tj. liczbę różnych bitów w reprezentacji binarnej) pomiędzy tymi dwoma adresami i stopniowo przekazuje informację przez sąsiednie łańcuchy robocze, aż do osiągnięcia docelowego łańcucha roboczego. Metoda ta gwarantuje, że pakiety danych przesyłane są najkrótszą drogą, co poprawia efektywność komunikacji w sieci.

Oczywiście, aby uprościć ten proces, TON zaproponował również optymistyczne rozwiązanie techniczne, gdy użytkownik może przedstawić ważny dowód określonej ścieżki routingu, którym jest zwykle korzeń Merkle Trie, węzeł może bezpośrednio rozpoznać wiarygodność wiadomości. przesłane przez użytkownika, jest to również nazywane natychmiastowym routingiem hipersześcianu.

Dlatego widzimy, że istnieją oczywiste różnice między adresami w TON i innych protokołach blockchain. Większość innych głównych protokołów blockchain używa jako adresu skrótu odpowiadającego kluczowi publicznemu w kluczach publicznych i prywatnych wygenerowanych przez algorytm szyfrowania eliptycznego, ponieważ. adres jest używany tylko jako unikalny adres. Nie musi zawierać funkcji adresowania routingu, a adres w TON składa się z dwóch części (workchain_id, account_id), gdzie workchain_id jest kodowany zgodnie z adresem algorytmu routingu hipersześcianu, który nie będą tu szczegółowo omawiane.

Jest jeszcze jeden punkt, który łatwo wzbudzić wątpliwości. Być może zauważyłeś, że łańcuch główny ma powiązania z każdym działającym łańcuchem, więc czy nie wystarczyłoby, gdyby wszystkie informacje między łańcuchami były po prostu przekazywane przez ten łańcuch. jak Kosmos. W koncepcji projektowej TON główny łańcuch jest używany tylko do obsługi najbardziej krytycznych zadań, to znaczy utrzymania finalności wielu łańcuchów roboczych. Nie jest niemożliwe kierowanie komunikatów przez główny łańcuch, ale wynikające z tego opłaty manipulacyjne będą bardzo wysokie .

Na koniec wspomnijmy krótko o algorytmie konsensusu TON przyjmuje metodę BFT+PoS, co oznacza, że ​​każdy zainteresowany ma możliwość uczestniczenia w pakowaniu blokowym. Umowa dotycząca zarządzania wyborami TON będzie losowo wybierać weryfikatora opakowań spośród wszystkich Stakerów w regularnych odstępach czasu klastrze, węzły wybrane jako walidatory zostaną spakowane i wyprodukowane za pomocą algorytmu BFT. Jeśli spakują nieprawidłowe informacje lub zrobią coś złego, ich postawione tokeny zostaną utracone i w przeciwnym razie otrzymają nagrody blokowe. Jest to w zasadzie powszechny wybór, więc nie będę go tutaj przedstawiać.

Inteligentne kontrakty i w pełni równoległe środowisko wykonawcze oparte na modelu Actor

Kolejnym punktem TON, który różni się od głównych protokołów blockchain, jest inteligentne środowisko realizacji kontraktów. Aby przełamać ograniczenia głównego nurtu protokołu blockchain TPS, TON przyjęła koncepcję projektowania oddolnego i wykorzystała model Actor do zrekonstruowania inteligentnych kontraktów i metod ich realizacji, dając im możliwość pełnej równoległości.

Wiemy, że większość głównych protokołów blockchain wykorzystuje jednowątkowe środowisko wykonywania szeregowego. Biorąc za przykład Ethereum, jego środowisko wykonawcze EVM jest maszyną stanu z transakcjami jako danymi wejściowymi, gdy węzeł wytwarzający blok kończy transakcję poprzez pakowanie bloku po sortowaniu , transakcje będą realizowane przez EVM w tej kolejności. Cały proces jest w pełni szeregowy i jednowątkowy, co oznacza, że ​​w określonym czasie może być wykonana tylko jedna transakcja. Zaletą tego jest to, że jest taka długa sekwencja transakcji potwierdzony, wynikiem wykonania będzie: Istnieje spójność w szerokim zakresie rozproszonych klastrów. Jednocześnie, ponieważ tylko jedna transakcja jest wykonywana szeregowo w tym samym czasie, oznacza to, że podczas procesu realizacji nie jest możliwe wykonanie innych transakcji. modyfikować określone dane stanu, do których ma być dostępny dostęp, tak aby osiągnięta została interoperacyjność pomiędzy inteligentnymi kontraktami. Na przykład używamy USDT do zakupu ETH za pośrednictwem Uniswap. Kiedy transakcja jest realizowana, rozkład LP w parze handlowej ma określoną wartość. W ten sposób odpowiedni wynik można uzyskać za pomocą pewnych modeli matematycznych, ale zakładając, że tak jest nie ma to miejsca, jeżeli przy obliczaniu określonej krzywej obligacji inne LP dodadzą nową płynność, wynik obliczeń będzie wynikiem nieaktualnym, co jest oczywiście niedopuszczalne.

Ale ta architektura ma również oczywiste ograniczenia, które stanowią wąskie gardło TPS, a to wąskie gardło wydaje się bardzo stare w przypadku obecnych procesorów wielordzeniowych. Podobnie jest w przypadku korzystania z najnowszego komputera PC do grania w niektóre stare gry komputerowe, takie jak Red Alert, Kiedy liczba jednostek bojowych osiągnie pewien poziom, nadal będzie można stwierdzić, że jest ona zablokowana. Jest to problem związany z architekturą oprogramowania.

Można usłyszeć, że niektóre protokoły już zwróciły uwagę na ten problem i zaproponowały własne rozwiązania równoległe Biorąc za przykład Solanę, która obecnie twierdzi, że ma najwyższy TPS, ma również możliwość wykonywania równoległego. Jednak jego pomysł na projekt różni się od TON w Solanie, jego podstawową ideą jest podzielenie wszystkich transakcji na kilka grup zgodnie z zależnościami wykonania, a żadne dane o stanie nie są współdzielone pomiędzy różnymi grupami. Oznacza to, że nie ma identycznych zależności, więc transakcje w różnych grupach można realizować równolegle bez obawy o konflikty, natomiast transakcje w ramach tej samej grupy są nadal realizowane w tradycyjny sposób szeregowy.

W TON całkowicie porzucono architekturę wykonania szeregowego i zamiast tego przyjęto paradygmat programistyczny specjalnie zaprojektowany pod kątem równoległości, model aktora, w celu zrekonstruowania środowiska wykonawczego. Tak zwany model aktora został po raz pierwszy zaproponowany przez Carla Hewitta w 1973 roku w celu rozwiązania złożoności stanu współdzielonego w tradycyjnych programach współbieżnych poprzez przekazywanie komunikatów. Każdy aktor ma swój własny prywatny stan i zachowanie i nie udostępnia żadnych informacji o stanie innym aktorom. Model aktora to model obliczeń współbieżnych, który implementuje obliczenia równoległe poprzez przekazywanie komunikatów. W tym modelu „Aktor” jest podstawową jednostką pracy zdolną do przetwarzania otrzymanych wiadomości, tworzenia nowych Aktorów, wysyłania większej liczby wiadomości i decydowania o tym, jak odpowiedzieć na kolejne wiadomości. Model aktora musi mieć następujące cechy:

• Hermetyzacja i niezależność: Każdy aktor jest całkowicie niezależny podczas przetwarzania komunikatów i może przetwarzać komunikaty równolegle, nie zakłócając się nawzajem.

• Przekazywanie wiadomości: aktorzy wchodzą ze sobą w interakcję jedynie poprzez wysyłanie i odbieranie wiadomości, a przekazywanie wiadomości jest asynchroniczne.

• Struktura dynamiczna: aktorzy mogą tworzyć więcej aktorów w czasie wykonywania. Ta dynamiczna natura pozwala modelowi aktora na rozbudowę systemu w miarę potrzeb.

TON przyjmuje tę architekturę do projektowania modeli inteligentnych kontraktów, co oznacza, że ​​w TON każdy inteligentny kontrakt jest modelem aktora z całkowicie niezależną przestrzenią dyskową. Ponieważ nie opiera się na żadnych danych zewnętrznych. Dodatkowo wywołania tego samego smart kontraktu w dalszym ciągu realizowane są według kolejności komunikatów w kolejce odbiorczej, dzięki czemu transakcje w TON mogą być sprawnie realizowane równolegle, bez obawy o konflikty.

Jednak taki schemat projektowania niesie ze sobą także pewne nowe skutki. Dla programistów DApp ich przyzwyczajony paradygmat programowania zostanie złamany w następujący sposób:

1. Asynchroniczne wywołania pomiędzy inteligentnymi kontraktami: Nie jest możliwe atomowe wywoływanie kontraktów zewnętrznych ani uzyskiwanie dostępu do zewnętrznych danych kontraktów w ramach inteligentnych kontraktów TON. Wiemy, że w Solidity funkcja 1 kontraktu A wywołuje funkcję 2 kontraktu B lub poprzez funkcję tylko do odczytu 3 kontraktu C uzyskuje dostęp do określonych danych stanu. Cały proces jest atomowy i realizowany w ramach transakcji. Jest to jednak bardzo prosta rzecz, jednak w TON nie będzie to możliwe i wszelka interakcja z zewnętrzną inteligencją. Interakcje z kontraktem będą realizowane asynchronicznie poprzez pakowanie nowych transakcji. Takie transakcje inicjowane przez inteligentne kontrakty nazywane są także komunikatami wewnętrznymi. Nie można go również zablokować podczas wykonywania, aby uzyskać wyniki wykonania.

Na przykład, jeśli opracujemy DEX i przyjmiemy wspólny paradygmat w EVM, zazwyczaj będzie istniała ujednolicona umowa routera używana do zarządzania routingiem transakcji, a każda Pula niezależnie zarządza danymi LP związanymi z określoną parą handlową. Zakładając to obecnie istnieją dwie pule: USDT-DAI i DAI-ETH. Gdy użytkownik chce kupić ETH bezpośrednio przez USDT, może sekwencyjnie zażądać tych dwóch pul w jednej transakcji za pośrednictwem umowy routera, aby zakończyć transakcję niepodzielną. Jednakże nie jest to takie proste do wdrożenia w TON. Należy pomyśleć o nowym paradygmacie rozwoju. Jeśli ten paradygmat będzie nadal stosowany, przepływ informacji może wyglądać następująco. Żądaniu temu będzie towarzyszył komunikat zewnętrzny inicjowany przez użytkownika i trzy komunikaty wewnętrzne są gotowe (należy pamiętać, że służy to do zilustrowania różnicy. W prawdziwym rozwoju nawet paradygmat ERC20 musi zostać przeprojektowany).

2. Należy dokładnie rozważyć proces przetwarzania błędów wykonania przy wywołaniach międzykontraktowych i zaprojektować odpowiednie funkcje zwrotne dla każdego wywołania międzykontraktowego. Wiemy, że w głównym nurcie EVM, gdy podczas realizacji transakcji pojawi się problem, cała transakcja zostanie wycofana, czyli zresetowana do początkowego stanu wykonania. Łatwo to zrozumieć w szeregowym modelu jednowątkowym. Jednak w TON, ponieważ wywołania pomiędzy kontraktami realizowane są asynchronicznie, nawet jeśli w kolejnym łączu wystąpi błąd, gdyż poprzednio pomyślnie wykonana transakcja została już wykonana i potwierdzona, może to powodować problemy. Dlatego w TON ustawiany jest specjalny typ komunikatu, zwany komunikatem zwrotnym. Oznacza to, że gdy w kolejnym procesie wykonania wystąpi błąd wywołany komunikatem wewnętrznym, wywołany kontrakt może wywołać określony komunikat w kontrakcie poprzez funkcję zwrotną. zarezerwowane przez umowę wyzwalającą. Niektóre statusy są resetowane.

3. W niektórych skomplikowanych sytuacjach transakcja otrzymana jako pierwsza może nie zostać wykonana jako pierwsza, dlatego nie można z góry ustalić tej zależności czasowej. W takim systemie asynchronicznych i równoległych wywołań inteligentnych kontraktów określenie kolejności przetwarzania operacji może być trudne. Dlatego też każdy komunikat w TON ma swój czas logiczny, czas Lamporta (zwany dalej lt). Służy do zrozumienia, które zdarzenie wywołało kolejne i z czym walidator musi się uporać w pierwszej kolejności. W przypadku prostego modelu transakcja otrzymana jako pierwsza musi zostać wykonana jako pierwsza.

W tym modelu A i B reprezentują odpowiednio dwa inteligentne kontrakty i istnieje zależność czasowa taka, że ​​jeśli msg1_lt < msg2_lt, to tx1_lt < tx2_lt.

Jednak w bardziej skomplikowanych sytuacjach zasada ta zostaje złamana. Przykład tego znajduje się w oficjalnej dokumentacji. Załóżmy, że mamy trzy umowy A, B i C. Podczas transakcji A wysyła dwie wewnętrzne wiadomości msg1 i msg2: jedną do B, a drugą do C. Chociaż są one tworzone w dokładnej kolejności (najpierw msg1, potem msg2), nie możemy być pewni, że msg1 zostanie przetworzone przed msg2. Dzieje się tak dlatego, że trasy z A do B i z A do C mogą różnić się długością i zestawem walidatorów. Jeśli te kontrakty znajdują się w różnych łańcuchach fragmentów, dotarcie jednego z komunikatów do kontraktu docelowego może zająć kilka bloków. Oznacza to, że mamy dwie możliwe ścieżki handlu, jak pokazano na rysunku.

4. W TON trwałe przechowywanie inteligentnych kontraktów wykorzystuje ukierunkowany graf acykliczny z komórką jako jednostką jako strukturą danych. Dane zostaną kompaktowo skompresowane do komórki zgodnie z zasadami kodowania i jednocześnie zgodnie z skierowany wykres acykliczny Droga biegnie w dół, co różni się od strukturalnej organizacji danych stanu opartej na hashmapie w EVM. Ze względu na różne algorytmy żądania danych, TON ustala różne ceny gazu dla różnych głębokości przetwarzania danych , tym więcej gazu potrzeba, tym więcej, więc w TON istnieje paradygmat ataku DOS, to znaczy, że niektórzy szkodliwi użytkownicy zajmują wszystkie płytkie komórki w określonym inteligentnym kontrakcie, wysyłając dużą liczbę wiadomości spamowych, co oznacza, że koszty przechowywania uczciwych użytkowników będą coraz wyższe. W EVM, ponieważ złożoność zapytań w hashmapie wynosi o(1), ma ona ten sam gaz i nie będzie podobnych problemów. Dlatego programiści TON Dapp powinni starać się unikać nieograniczonych typów danych w inteligentnych kontraktach. Gdy pojawią się nieograniczone typy danych, należy je podzielić poprzez fragmentowanie.

5. Istnieją również pewne funkcje, które są mniej specjalne, takie jak inteligentne kontrakty, które muszą płacić czynsz za przechowywanie, inteligentne kontrakty w TON można w naturalny sposób aktualizować oraz natywne abstrakcyjne funkcje kont, czyli wszystkie adresy portfeli w TON są inteligentnymi kontraktami, po prostu nie został zainicjowany itp. Wymaga to od programistów zwrócenia szczególnej uwagi.

Powyższe to niektóre z moich doświadczeń w nauce technologii związanych z TON w tym okresie. Chciałbym się nimi z wami podzielić. Mam nadzieję, że poprawicie mnie, jeśli popełnię jakieś błędy. Jednocześnie myślę, że przy ogromnym ruchu na Telegramie zasobów, ekosystem TON z pewnością zapewni platformę dla Web3. Wprowadzając kilka zupełnie nowych aplikacji, przyjaciele zainteresowani rozwojem TON DApp mogą również skontaktować się ze mną i porozmawiać z nami.

Linki X: https://x.com/web3_mario