Ten tekst jest kontynuacją serii artykułów, w których omawiam strukturę (prawdopodobnie) planowanej na ten rok rozproszonej sieci Telegram Open Network (TON). W opisałem jej najprostszy poziom — sposób interakcji węzłów między sobą.
Dla przypomnienia, nie mam żadnego związku z rozwojem tej sieci, a wszystkie materiały pochodzą z otwartego (choć niezweryfikowanego) źródła — (do którego dołączona jest , w skrócie przedstawiająca główne kwestie), która pojawiła się pod koniec zeszłego roku. Według mnie objętość informacji w tym dokumencie świadczy o jego autentyczności, chociaż nie ma żadnych oficjalnych potwierdzeń.
Dziś przyjrzymy się głównemu komponentowi TON — blockchainowi.
Podstawowe pojęcia
Konto (account). Zbiór danych identyfikowany przez 256-bitową liczbę account_id (najczęściej jest to klucz publiczny właściciela konta). W podstawowym przypadku (patrz poniżej zerowy workchain), pod tymi danymi rozumie się saldo użytkownika. „Pożyczyć” konkretne account_id może ktokolwiek, ale zmieniać jego wartość można tylko według określonych zasad.
Smart kontrakt (smart-contract). W zasadzie jest to szczególny przypadek konta, wzbogacony kodem smart kontraktu i magazynem jego zmiennych. Jeśli w przypadku „portfela” można wprowadzać i wypłacać pieniądze na podstawie stosunkowo prostych i wcześniej określonych zasad, to w przypadku smart kontraktu te zasady są zapisane w formie jego kodu (w jakimś języku programowania Turing-complete).
Stan blockchaina (state of blockchain). Zbiór stanów wszystkich kont/smart kontraktów (w sensie abstrakcyjnym — tabela haszowa, gdzie kluczami są identyfikatory kont, a wartościami — dane przechowywane na kontach).
Komunikat (message). Wspomniałem wcześniej o wyrażeniu „wprowadzać i wypłacać pieniądze” — to szczególny przypadek wiadomości („przenieść N gramów z konta account_1 na konto account_2”). Oczywiście, taką wiadomość może wysłać tylko węzeł, który posiada prywatny klucz konta. account_1 — i potrafi to potwierdzić podpisem. Efektem dostarczenia takich wiadomości do zwykłego konta jest zwiększenie jego salda, a dla smart kontraktu — wykonanie jego kodu (który obsłuży przyjęcie wiadomości). Oczywiście możliwe są także inne wiadomości (przenoszące nie pieniężne kwoty, ale dowolne dane między smart kontraktami).
Transakcja (transakcja). Fakt dostarczenia wiadomości nazywa się transakcją. Transakcje zmieniają stan blockchaina. To właśnie z transakcji (rekordów o dostarczeniu wiadomości) składają się bloki w blockchainie. W tym kontekście stan blockchaina można wyobrazić sobie jako inkrementalną bazę danych — wszystkie bloki są „diffami”, które należy stosować sekwencyjnie, aby uzyskać aktualny stan bazy danych. O specyfice pakowania tych „diffów” (i przywracaniu pełnego stanu na ich podstawie) mowa będzie w następnym artykule.
Blockchain w TON: co to jest i po co?
Jak wspomniano w poprzednim artykule, blockchain to struktura danych, której elementy (bloki) są uporządkowane w „łańcuch”, a każdy kolejny blok łańcucha zawiera w sobie hash poprzedniego. W komentarzach zadano pytanie: po co w ogóle potrzebna jest taka struktura danych, skoro mamy już DHT — rozproszoną tabelę haszy? Oczywiście, że pewne dane można przechowywać i w DHT, ale to nadaje się tylko dla nieco „wrażliwych” informacji. Nie można przechowywać sald kryptowalut w DHT — przede wszystkim z powodu braku kontroli nad integralnością. Właściwie cała złożoność struktury blockchaina wynika z potrzeby zapobiegania ingerencjom w przechowywane w nim dane.
Jednak blockchain w TON wygląda jeszcze bardziej skomplikowanie niż w większości innych rozproszonych systemów — i są ku temu dwa powody. Pierwszy — chęć minimalizacji potrzeby forków. W tradycyjnych kryptowalutach wszystkie parametry są ustalone na początkowym etapie, a każda próba ich zmiany prowadzi w praktyce do powstania „alternatywnego wszechświata kryptowalut”. Drugi powód — wsparcie dla fragmentacji (shardingu, shardowanie) blockchain. Blockchain is a structure that cannot become smaller over time; and usually, each node responsible for the network's operation must store it completely. In traditional (centralized) systems, sharding is used to solve such problems: part of the database records is on one server, part is on another, and so on. In the case of cryptocurrencies, such functionality is still quite rare—mainly because it is difficult to add sharding to a system where it was not originally planned.
How does TON plan to address both of the aforementioned issues?
Content of the blockchain. Workchains.
First of all, let's talk about what will be stored in the blockchain. It will store the states of accounts (or 'wallets' in the basic case) and smart contracts (for simplicity, let's consider them the same as accounts). Essentially, this will be a regular hash table—its keys will be identifiers account_id, and the values will be data structures containing things like:
- balance;
- smart contract code (only for smart contracts);
- smart contract data storage (only for smart contracts);
- statistics;
- (optionally) a public key for outgoing transactions from the account, by default account_id;
- a queue of outgoing messages (they are entered here for forwarding to the recipient);
- a list of the last messages delivered to this account.
As mentioned above, blocks directly consist of transactions—messages delivered to various accounts account_id. However, in addition to account_id, messages also contain a 32-bit field workchain_id — the identifier of the so-called workchain (workchain, working blockchain). This allows for several independent blockchains with different configurations. In this case, workchain_id = 0 is considered a special case, the zero workchain — the balances contained in it will correspond to the TON cryptocurrency (Grams). Most likely, there will be no other workchains initially.
Shardchains. Infinite Sharding Paradigm.
Jednak wzrost liczby blockchainów na tym się nie zatrzymuje. Przyjrzyjmy się shardingu. Wyobraźmy sobie, że każdemu kontu (account_id) przydzielony jest własny blockchain — w nim znajdują się wszystkie nadchodzące wiadomości — a stany wszystkich takich blockchainów są przechowywane na oddzielnych węzłach.
Oczywiście to dość marnotrawne: najprawdopodobniej do każdego z tych shardchainów (shardchain, shard blockchain) transakcje będą wpływać bardzo rzadko, a potrzeba będzie wielu potężnych węzłów (w przeszłości zaznaczę, że mowa tutaj nie tylko o klientach na telefonach komórkowych — ale o poważnych serwerach).
Dlatego shardchainy łączą ze sobą konta na podstawie binarnych prefiksów ich identyfikatorów: jeśli shardchain ma prefiks 0110, to trafią do niego transakcje wszystkich account_id, które zaczynają się od tych cyfr. Ten shard_prefix może mieć długość od 0 do 60 bitów — a co najważniejsze, może się dynamicznie zmieniać.
Gdy tylko do jednego z shardchainów zaczyna napływać zbyt wiele transakcji, węzły pracujące nad nim według wcześniej określonych zasad „dzielą” go na dwa potomne — ich prefiksy będą o jeden bit dłuższe (i dla jednego z nich ten bit będzie równy 0, a dla drugiego — 1). Na przykład, shard_prefix = 0110b podzieli się na 01100b i 01101b. Z drugiej strony, jeśli dwa „sąsiednie” shardchainy zaczną czuć się wystarczająco swobodnie (przez pewien czas), ponownie się połączą.
W ten sposób sharding odbywa się „od dołu do góry” — zakładamy, że każde konto posiada swój shard, ale są one — przez jakiś czas — „połączone” w oparciu o prefiksy. To jest to, co oznacza Infinite Sharding Paradigm (paradigma nieskończonego shardingu).
Osobno pragnę podkreślić, że workchainy istnieją tylko wirtualnie — w rzeczywistości, workchain_id to część identyfikatora konkretnego shardchainu. Mówiąc formalnie, każdy shardchain jest definiowany przez parę liczb (workchain_id, shard_prefix).
Korygowanie błędów. W poziome blockchainy.
Tradycyjnie uważa się, że każda transakcja w blockchainie jest „wyryta w kamieniu”. Jednak w przypadku TON przewidziano możliwość „przepisywania historii” — w przypadku, gdy ktoś (tzw. węzeł-„rybak”) udowodni, że jeden z bloków został podpisany nieprawidłowo. W takim przypadku do odpowiedniego shardchain dodawany jest specjalny blok korekcyjny, zawierający hash samego korygowanego bloku (a nie ostatniego bloku w shardchain). Przedstawiając shardchain jako poziomą linię bloków, można stwierdzić, że blok korekcyjny jest podłączany do błędnego bloku nie z boku, a z góry — dlatego uważa się, że staje się częścią małego „pionowego blockchaina”. W ten sposób można stwierdzić, że shardchain są dwuwymiarowymi blockchainami.
W przypadku gdy po błędnym bloku następne bloki odnosiły się do jego zmian (tj. dokonano nowych transakcji na podstawie nieważnych), do tych bloków również „z góry” dodawane są bloki korekcyjne. Jeśli bloki nie dotykały „dotkniętych” informacji, te „fale korekcyjne” na nie nie mają wpływu. Na przykład w powyższej ilustracji transakcja pierwszego bloku, zwiększająca saldo konta C, została uznana za nieprawidłową — dlatego transakcja, która zmniejsza saldo tego konta w trzecim bloku, również musi być anulowana, a na samym bloku commitowany jest blok korekcyjny.
Należy zauważyć — chociaż bloki korekcyjne są przedstawiane jako umiejscowione „nad” oryginalnymi, faktycznie zostaną one zapisane na końcu odpowiedniego blockchaina (tam, gdzie powinny znajdować się chronologicznie). Dwuwymiarowe umiejscowienie jedynie pokazuje, do którego momentu w blockchainie będą „podłączone” (poprzez zawarty w nich hash oryginalnego bloku).
Można osobno rozważyć, jak dobre jest rozwiązanie „zmieniania przeszłości”. Wydaje się, że jeśli dopuszczamy możliwość pojawienia się nieprawidłowego bloku w shardchainie, to nie możemy nie dopuścić także do możliwości powstania błędnego bloku korekcyjnego. Tutaj, o ile mogę sądzić, różnica tkwi w liczbie węzłów, które muszą osiągnąć konsensus w sprawie nowych bloków — nad każdym shardchainem będzie pracować stosunkowo niewielka „grupa robocza” węzłów (dość często zmieniająca swój skład), a wprowadzenie bloków korekcyjnych będzie wymagało zgody właściwie wszystkich węzłów-walidatorów. Więcej o walidatorach, grupach roboczych i innych rolach węzłów opowiem w następnym artykule.
Jeden blockchain, aby rządzić wszystkimi
Powyżej wymieniono wiele informacji na temat różnych rodzajów blockchainów, które same w sobie również powinny być gdzieś przechowywane. W szczególności mowa o następujących informacjach:
- o liczbie i konfiguracjach workflowów;
- o liczbie shardchainów i ich prefiksach;
- o tym, które węzły obecnie odpowiadają za które shardchainy;
- hashe ostatnio dodanych bloków do wszystkich shardchainów.
Jak już mogłeś się domyślić, wszystkie te rzeczy są zapisywane w jeszcze jednym magazynie blockchain — masterchain (masterchain, master blockchain). Dzięki obecności w jego blokach hashy bloków wszystkich shardchainów, tworzy to silnie powiązaną system. Oznacza to, że generacja nowego bloku w masterchainie będzie miała miejsce bezpośrednio po generacji bloków w shardchainach — oczekuje się, że bloki w shardchainach będą pojawiać się niemal jednocześnie co około 5 sekund, a następny blok w masterchainie — sekundę później.
Ale kto będzie odpowiedzialny za realizację tej tytanicznej pracy — za przesyłanie wiadomości, wykonywanie smart kontraktów, formowanie bloków w shardchainach i masterchainie, a także za weryfikację bloków pod kątem błędów? Czyżby to miały być niepostrzeżenie telefonów milionów użytkowników z zainstalowanym klientem Telegramu? A może zespół Durovów zrezygnuje z idei decentralizacji i to będą robić ich serwery po staroświecku?
W rzeczywistości ani jedna, ani druga odpowiedź nie jest poprawna. Ale końca tego artykułu szybko się zbliża, więc rozmowa o różnych rolach węzłów (mogłeś już zauważyć wzmianki o niektórych z nich), a także o mechanizmach ich działania odbędzie się już w następnej części.
Źródło: habr.com
