Tekst ten jest kontynuacją serii artykułów, w których badam strukturę (prawdopodobnie) rozproszonej sieci Telegram Open Network (TON), która jest przygotowywana do premiery w tym roku. W Opisałem jego najbardziej podstawowy poziom - sposób, w jaki węzły oddziałują na siebie.
Na wszelki wypadek przypomnę, że nie mam nic wspólnego z rozwojem tej sieci, a cały materiał został zaczerpnięty z otwartego (aczkolwiek niezweryfikowanego) źródła - (jest też dodatek , krótko opisując główne punkty), który ukazał się pod koniec ubiegłego roku. Ilość informacji zawartych w tym dokumencie moim zdaniem wskazuje na jego autentyczność, choć nie ma na to oficjalnego potwierdzenia.
Dzisiaj przyjrzymy się głównemu komponentowi TON – blockchainowi.
Podstawowe pojęcia
Konto (konto). Zbiór danych identyfikowany liczbą 256-bitową ID konta (najczęściej jest to klucz publiczny właściciela konta). W przypadku podstawowym (patrz poniżej zerowy łańcuch roboczy), dane te dotyczą salda użytkownika. Specyficzne „zajmowanie”. ID konta każdy może, ale jego wartość można zmienić tylko zgodnie z pewnymi zasadami.
Inteligentna umowa (inteligentny kontrakt). W istocie jest to szczególny przypadek konta, uzupełnionego o inteligentny kod kontraktu i przechowywanie jego zmiennych. Jeśli w przypadku „portfela” można wpłacać i wypłacać z niego pieniądze według stosunkowo prostych i z góry ustalonych zasad, to w przypadku inteligentnego kontraktu zasady te są zapisane w postaci jego kodu (w pewnym zupełnym Turingu język programowania).
Stan Blockchain (stan blockchaina). Zbiór stanów wszystkich kont/smart kontraktów (w sensie abstrakcyjnym tablica mieszająca, gdzie klucze stanowią identyfikatory kont, a wartościami są dane przechowywane na rachunkach).
wiadomość (wiadomość). Powyżej użyłem wyrażenia „pieniądze kredytowe i debetowe” – jest to konkretny przykład komunikatu („przelew N gramów z konta konto_1 na konto konto_2„). Oczywiście tylko węzeł posiadający klucz prywatny konta może wysłać taką wiadomość konto_1 - i jest w stanie potwierdzić to podpisem. Efektem dostarczenia takich wiadomości na zwykłe konto jest zwiększenie jego salda, a efektem inteligentnego kontraktu jest wykonanie jego kodu (który będzie przetwarzał otrzymanie wiadomości). Oczywiście możliwe są także inne komunikaty (przesyłanie nie kwot pieniężnych, ale dowolnych danych pomiędzy inteligentnymi kontraktami).
transakcja (transakcja). Fakt dostarczenia wiadomości nazywany jest transakcją. Transakcje zmieniają stan blockchainu. To transakcje (rejestry dostarczenia wiadomości) tworzą bloki w łańcuchu bloków. W związku z tym można myśleć o stanie łańcucha bloków jak o przyrostowej bazie danych - wszystkie bloki to „różnice”, które należy zastosować sekwencyjnie, aby uzyskać bieżący stan bazy danych. Specyfika pakowania tych „różnic” (i przywracania z nich pełnego stanu) zostanie omówiona w następnym artykule.
Blockchain w TON: co to jest i dlaczego?
Jak wspomniano w poprzednim artykule, blockchain to struktura danych, której elementy (bloki) są ułożone w „łańcuch”, a każdy kolejny blok łańcucha zawiera skrót poprzedniego. W komentarzach pojawiało się pytanie: po co nam w ogóle taka struktura danych, skoro mamy już DHT – rozproszoną tablicę skrótów? Oczywiście niektóre dane można przechowywać w DHT, ale jest to odpowiednie tylko w przypadku niezbyt „wrażliwych” informacji. Salda kryptowalut nie mogą być przechowywane w DHT – przede wszystkim ze względu na brak kontroli integralność. Właściwie cała złożoność struktury blockchain rośnie, aby zapobiec ingerencji w przechowywane w nim dane.
Jednakże blockchain w TON wygląda na jeszcze bardziej złożony niż w większości innych systemów rozproszonych – i to z dwóch powodów. Pierwszą z nich jest chęć zminimalizowania potrzeby widelce. W tradycyjnych kryptowalutach wszystkie parametry ustalane są na początkowym etapie i każda próba ich zmiany tak naprawdę prowadzi do powstania „alternatywnego wszechświata kryptowalut”. Drugim powodem jest wsparcie dla kruszenia (fragmentowanie, fragmentowanie) Blockchain. Blockchain to struktura, która z biegiem czasu nie może się zmniejszać; i zwykle każdy węzeł odpowiedzialny za działanie sieci zmuszony jest do jego całkowitego przechowywania. W tradycyjnych (scentralizowanych) systemach do rozwiązywania takich problemów wykorzystuje się sharding: część rekordów w bazie danych znajduje się na jednym serwerze, część na innym itd. W przypadku kryptowalut taka funkcjonalność jest nadal dość rzadka – w szczególności ze względu na fakt, że trudno dodać sharding do systemu, w którym pierwotnie nie był on planowany.
Jak TON planuje rozwiązać oba powyższe problemy?
Treść blockchaina. Łańcuchy robocze.
Przede wszystkim porozmawiajmy o tym, co planuje się przechowywać w blockchainie. Będą tam przechowywane stany rachunków („portfeli” w przypadku bazowym) i smart kontrakty (dla uproszczenia przyjmiemy, że to to samo, co konta). W istocie będzie to zwykła tabela skrótów - klucze w niej będą identyfikatorami ID konta, a wartości to struktury danych zawierające takie rzeczy jak:
- saldo;
- inteligentny kod kontraktu (tylko dla inteligentnych kontraktów);
- przechowywanie danych inteligentnych kontraktów (tylko w przypadku inteligentnych kontraktów);
- Statystyka;
- (opcjonalne) klucz publiczny dla przelewów z rachunku, domyślnie account_id;
- kolejka wiadomości wychodzących (tutaj są one wprowadzane do przekazania odbiorcy);
- lista najnowszych wiadomości dostarczonych na to konto.
Jak wspomniano powyżej, same bloki składają się z transakcji - wiadomości dostarczanych na różne konta account_id. Jednak oprócz account_id wiadomości zawierają również pole 32-bitowe workchain_id — tzw. identyfikator łańcuch roboczy (łańcuch roboczy, działający blockchain). Pozwala to na posiadanie kilku niezależnych od siebie łańcuchów bloków o różnych konfiguracjach. W tym przypadku workchain_id = 0 jest uważany za przypadek specjalny, zerowy łańcuch roboczy — to salda w nim będą odpowiadać kryptowalutie TON (gramy). Najprawdopodobniej na początku inne łańcuchy robocze w ogóle nie będą istnieć.
Shardchains. Paradygmat nieskończonego fragmentowania.
Na tym jednak wzrost liczby blockchainów się nie kończy. Zajmijmy się shardingiem. Wyobraźmy sobie, że każdemu kontu (account_id) przydzielony jest własny blockchain – zawiera on wszystkie wiadomości, które do niego przychodzą – a stany wszystkich takich blockchainów przechowywane są w oddzielnych węzłach.
Oczywiście jest to bardzo marnotrawstwo: najprawdopodobniej w każdym z nich łańcuchy fragmentów (fragment łańcucha, fragment łańcucha bloków) transakcje będą pojawiać się bardzo rzadko i potrzebnych będzie wiele potężnych węzłów (patrząc w przyszłość, zauważam, że nie mówimy tylko o klientach na telefonach komórkowych - ale o poważnych serwerach).
Dlatego shardchainy łączą konta według binarnych przedrostków ich identyfikatorów: jeśli shardchain ma przedrostek 0110, wówczas będzie obejmował transakcje wszystkich identyfikatorów kont rozpoczynających się od tych liczb. Ten przedrostek_odłamka może mieć długość od 0 do 60 bitów - a najważniejsze, że może się zmieniać dynamicznie.
Gdy tylko jeden z shardchainów zacznie otrzymywać zbyt wiele transakcji, pracujące nad nim węzły, zgodnie z ustalonymi regułami, „dzielą” go na dwójkę dzieci – ich prefiksy będą o nieco dłuższe (a dla jednego z nich bit ten będzie równy 0, a dla drugiego - 1). Na przykład, przedrostek_odłamka = 0110b podzieli się na 01100b i 01101b. Z kolei, jeśli dwa „sąsiadujące” shardchains zaczną czuć się wystarczająco swobodnie (przez jakiś czas), ponownie się połączą.
Zatem sharding odbywa się „od dołu do góry” - zakładamy, że każde konto ma swój własny shard, ale na razie są one „sklejane” prefiksami. To właśnie oznacza Paradygmat nieskończonego fragmentowania (paradygmat nieskończonego fragmentowania).
Osobno chciałbym podkreślić, że workchains istnieją tylko wirtualnie – w rzeczywistości workchain_id jest częścią identyfikatora konkretnego shardchaina. Formalnie każdy shardchain jest zdefiniowany przez parę liczb (workchain_id, przedrostek_odłamka).
Korekcja błędów. Pionowe łańcuchy bloków.
Tradycyjnie każdą transakcję na blockchainie uważa się za „wyrytą w kamieniu”. Jednak w przypadku TON możliwe jest „napisanie historii na nowo” – w przypadku gdyby ktoś (tzw. węzeł rybacki) wykaże, że jeden z bloków został podpisany błędnie. W takim przypadku do odpowiedniego shardchaina dodawany jest specjalny blok korekcyjny, zawierający hash samego korygowanego bloku (a nie ostatniego bloku w shardchainie). Myśląc o shardchainie jako o łańcuchu bloków ułożonych poziomo, możemy powiedzieć, że blok korekcyjny jest dołączony do błędnego bloku nie z prawej strony, ale od góry - uważa się więc, że staje się on częścią małego „pionowego blockchainu” . Można zatem powiedzieć, że shardchains są dwuwymiarowe łańcuchy bloków.
Jeżeli po błędnym bloku wprowadzone przez niego zmiany zostały odniesione przez kolejne bloki (czyli na podstawie nieprawidłowych dokonano nowych transakcji), do tych bloków „na wierzch” dodawane są także transakcje korygujące. Jeżeli blokady nie wpłynęły na „dotknięte” informacje, te „fale naprawcze” ich nie dotyczą. Przykładowo na powyższym rysunku transakcja pierwszego bloku, zwiększająca saldo rachunku C, została uznana za nieprawidłową – w związku z tym należy anulować także transakcję zmniejszającą saldo tego rachunku w trzecim bloku, a blok korygujący powinien zostać popełniony na samym bloku.
Należy zauważyć, że chociaż bloki korekcyjne są przedstawiane jako umieszczone „nad” oryginalnymi, w rzeczywistości zostaną dodane na końcu odpowiedniego blockchainu (gdzie powinny być chronologicznie). Dwuwymiarowa lokalizacja pokazuje jedynie, do jakiego punktu w łańcuchu bloków zostaną one „połączone” (poprzez hash oryginalnego bloku znajdującego się w nich).
Możesz osobno filozofować na temat tego, jak dobra jest decyzja o „zmianie przeszłości”. Wydawać by się mogło, że jeśli dopuścimy możliwość pojawienia się nieprawidłowego bloku w shardchainie, to nie unikniemy możliwości pojawienia się błędnego bloku korygującego. Tutaj, o ile wiem, różnica polega na liczbie węzłów, które muszą osiągnąć konsensus w sprawie nowych bloków – nad każdym shardchainem będzie pracowała stosunkowo niewielka liczba osób.Grupa robocza» węzły (które dość często zmieniają swój skład), a wprowadzenie blokad korekcyjnych będzie wymagało zgody wszystkich węzły walidatora. Opowiem więcej o walidatorach, grupach roboczych i innych rolach węzłów w następnym artykule.
Jeden łańcuch bloków, aby wszystkimi rządzić
Powyżej wymieniono wiele informacji na temat różnych typów łańcuchów bloków, które same w sobie również powinny być gdzieś przechowywane. W szczególności mówimy o następujących informacjach:
- o liczbie i konfiguracjach workchainów;
- o liczbie shardchainów i ich przedrostków;
- o tym, które węzły są obecnie odpowiedzialne za które łańcuchy fragmentów;
- skróty ostatnich bloków dodanych do wszystkich shardchainów.
Jak można się domyślić, wszystkie te rzeczy są zapisywane w innym magazynie blockchain - łańcuch główny (łańcuch główny, główny łańcuch bloków). Ze względu na obecność skrótów z bloków wszystkich shardchainów w swoich blokach, sprawia to, że system jest wysoce połączony. Oznacza to między innymi, że wygenerowanie nowego bloku w masterchain nastąpi natychmiast po wygenerowaniu bloków w shardchains – oczekuje się, że bloki w shardchains będą pojawiać się niemal jednocześnie co około 5 sekund, a kolejny blok w łańcuchu masterchain - sekundę później.
Ale kto będzie odpowiedzialny za realizację całej tej gigantycznej pracy - za wysyłanie wiadomości, wykonywanie inteligentnych kontraktów, tworzenie bloków w shardchainach i masterchainie, a nawet sprawdzanie bloków pod kątem błędów? Czy to wszystko będzie potajemnie robione przez telefony milionów użytkowników z zainstalowanym na nich klientem Telegramu? A może zespół Durov porzuci idee decentralizacji, a ich serwery zrobią to w staromodny sposób?
Tak naprawdę ani jedna, ani druga odpowiedź nie jest prawidłowa. Jednak marginesy tego artykułu szybko się kończą, dlatego o różnych rolach węzłów (być może zauważyłeś już wzmianki o niektórych z nich), a także mechanice ich pracy, porozmawiamy w następnej części.
Źródło: www.habr.com