TON: Telegram Open Network. Časť 2: Blockchainy, sharding

Tento text je pokračovaním série článkov, v ktorých skúmam štruktúru (pravdepodobne) distribuovanej siete Telegram Open Network (TON), ktorá sa pripravuje na vydanie v tomto roku. IN predchádzajúca časť Popísal som jeho najzákladnejšiu úroveň – spôsob, akým medzi sebou uzly interagujú.

Pre každý prípad mi dovoľte pripomenúť, že s vývojom tejto siete nemám nič spoločné a všetok materiál bol zozbieraný z otvoreného (aj keď neovereného) zdroja - dokument (existuje aj sprievodný brožúry, ktorý stručne načrtáva hlavné body), ktorý sa objavil koncom minulého roka. Množstvo informácií v tomto dokumente podľa môjho názoru svedčí o jeho pravosti, hoci o tom neexistuje žiadne oficiálne potvrdenie.

Dnes sa pozrieme na hlavnú zložku TON – blockchain.

Základné pojmy

Účet (účet). Súbor údajov identifikovaných 256-bitovým číslom Číslo účtu (najčastejšie ide o verejný kľúč vlastníka účtu). V základnom prípade (pozri nižšie nulový pracovný reťazec), tieto údaje sa týkajú zostatku používateľa. "Occupy" špecifické Číslo účtu môže každý, ale jeho hodnotu možno meniť len podľa určitých pravidiel.

Inteligentná zmluva (smart-zmluva). V podstate ide o špeciálny prípad účtu, doplnený o smart kontraktový kód a uloženie jeho premenných. Ak v prípade „peňaženky“ môžete vkladať a vyberať z nej peniaze podľa relatívne jednoduchých a vopred stanovených pravidiel, tak v prípade smart kontraktu sú tieto pravidlá napísané vo forme jej kódu (v určitom Turingovom komplete programovací jazyk).

Stav blockchainu (stav blockchainu). Množina stavov všetkých účtov/inteligentných zmlúv (v abstraktnom zmysle hašovacia tabuľka, kde kľúče sú identifikátory účtov a hodnoty sú údaje uložené v účtoch).

Správa (správa). Vyššie som použil výraz „kreditné a debetné peniaze“ - toto je konkrétny príklad správy („prevod N gramov z účtu účet_1 na účet účet_2"). Je zrejmé, že takúto správu môže odoslať iba uzol, ktorý vlastní súkromný kľúč účtu účet_1 - a môže to potvrdiť podpisom. Výsledkom doručovania takýchto správ na bežný účet je zvýšenie jeho zostatku a výsledkom smart kontraktu je spustenie jeho kódu (ktorý spracuje príjem správy). Samozrejme sú možné aj iné správy (prenos nie peňažných čiastok, ale ľubovoľných údajov medzi smart kontraktmi).

Transakcia (transakcie). Skutočnosť, že je správa doručená, sa nazýva transakcia. Transakcie menia stav blockchainu. Sú to transakcie (záznamy o doručení správ), ktoré tvoria bloky v blockchaine. V tomto ohľade si stav blockchainu môžete predstaviť ako prírastkovú databázu – všetky bloky sú „rozdiely“, ktoré je potrebné aplikovať postupne, aby ste získali aktuálny stav databázy. Špecifiká balenia týchto „rozdielov“ (a obnovenie plného stavu z nich) budú diskutované v nasledujúcom článku.

Blockchain v TON: čo to je a prečo?

Ako bolo uvedené v predchádzajúcom článku, blockchain je dátová štruktúra, ktorej prvky (bloky) sú usporiadané do „reťazca“ a každý nasledujúci blok reťazca obsahuje hash predchádzajúceho. V komentároch bola otázka: načo vôbec potrebujeme takúto dátovú štruktúru, keď už máme DHT – distribuovanú hašovaciu tabuľku? Je zrejmé, že niektoré údaje môžu byť uložené v DHT, ale to je vhodné len pre nie príliš „citlivé“ informácie. Zostatky v kryptomenách nie je možné uložiť v DHT – predovšetkým kvôli nedostatku kontrol bezúhonnosť. V skutočnosti celá zložitosť blockchainovej štruktúry rastie, aby sa zabránilo interferencii s údajmi v nej uloženými.

Blockchain v TON však vyzerá ešte zložitejšie ako vo väčšine iných distribuovaných systémov – a to z dvoch dôvodov. Prvým je túžba minimalizovať potrebu vidličky. V tradičných kryptomenách sú všetky parametre nastavené v počiatočnej fáze a akýkoľvek pokus o ich zmenu v skutočnosti vedie k vzniku „alternatívneho kryptomenového vesmíru“. Druhým dôvodom je podpora drvenia (úlomky, úlomky) blockchain. Blockchain je štruktúra, ktorá sa časom nemôže zmenšiť; a zvyčajne je každý uzol zodpovedný za prevádzku siete nútený ju úplne uložiť. V tradičných (centralizovaných) systémoch sa na riešenie takýchto problémov používa sharding: niektoré záznamy v databáze sú umiestnené na jednom serveri, niektoré na inom atď. V prípade kryptomien je takáto funkcionalita stále pomerne vzácna – najmä kvôli tomu, že je ťažké pridať sharding do systému, kde sa pôvodne neplánovalo.

Ako plánuje TON vyriešiť oba vyššie uvedené problémy?

Blockchainový obsah. Pracovné reťazce.

Najprv si povedzme o tom, čo sa plánuje uložiť v blockchaine. Budú tam uložené stavy účtov („peňaženky“ v základnom prípade) a smart kontrakty (pre jednoduchosť budeme predpokladať, že je to to isté ako účty). V podstate pôjde o bežnú hašovaciu tabuľku – kľúče v nej budú identifikátory Číslo účtua hodnoty sú dátové štruktúry obsahujúce také veci ako:

• rovnováha;
• kód inteligentnej zmluvy (len pre inteligentné zmluvy);
• ukladanie údajov inteligentných zmlúv (len pre inteligentné zmluvy);
• štatistiky;
• (voliteľný) verejný kľúč pre prevody z účtu, štandardne account_id;
• front odchádzajúcich správ (tu sa zadávajú na preposielanie príjemcovi);
• zoznam najnovších správ doručených na tento účet.

Ako už bolo spomenuté vyššie, samotné bloky pozostávajú z transakcií – správ doručených na rôzne účty account_id. Okrem account_id však správy obsahujú aj 32-bitové pole workchain_id — takzvaný identifikátor pracovný reťazec (pracovný reťazec, fungujúci blockchain). To vám umožňuje mať niekoľko nezávislých blockchainov s rôznymi konfiguráciami. V tomto prípade sa workchain_id = 0 považuje za špeciálny prípad, nulový pracovný reťazec — sú to zostatky v ňom, ktoré budú zodpovedať kryptomene TON (Grams). S najväčšou pravdepodobnosťou spočiatku iné pracovné reťazce vôbec nebudú existovať.

Shardchains. Paradigma nekonečného štiepenia.

Tým sa však rast počtu blockchainov nekončí. Poďme sa zaoberať štiepaním. Predstavme si, že každému účtu (account_id) je pridelený vlastný blockchain – obsahuje všetky správy, ktoré k nemu prichádzajú – a stavy všetkých takýchto blockchainov sú uložené na samostatných uzloch.

Samozrejme, je to veľmi zbytočné: s najväčšou pravdepodobnosťou v každom z nich shardchains (shardchain, črepový blockchain) transakcie prídu veľmi zriedkavo a bude potrebných veľa výkonných uzlov (pri pohľade do budúcnosti podotýkam, že nehovoríme len o klientoch na mobilných telefónoch – ale o serióznych serveroch).

Preto reťazce shardchain kombinujú účty podľa binárnych predpôn ich identifikátorov: ak reťazec shardchain má predponu 0110, bude zahŕňať transakcie všetkých ID účtu, ktoré začínajú týmito číslami. Toto predpona_úlomku môže mať dĺžku od 0 do 60 bitov – a hlavné je, že sa môže dynamicky meniť.

Akonáhle jeden zo shardchainov začne prijímať príliš veľa transakcií, uzly, ktoré na ňom pracujú, ho podľa vopred stanovených pravidiel „rozdelia“ na dve deti – ich predpony budú o jeden bit dlhšie (a pre jedného z nich bude tento bit rovná 0 a pre druhú - 1). Napríklad, predpona_úlomku = 0110b sa rozdelí na 01100b a 01101b. Na druhej strane, ak sa dva „susedné“ reťazce začnú cítiť dostatočne pohodlne (na nejaký čas), opäť sa spoja.

Sharding sa teda robí „zdola nahor“ – predpokladáme, že každý účet má svoj vlastný črep, no zatiaľ sú „zlepené“ predponami. To je to, čo to znamená Paradigma nekonečného štiepenia (paradigma nekonečného shardingu).

Samostatne by som rád zdôraznil, že pracovné reťazce existujú iba virtuálne – v skutočnosti workchain_id je súčasťou identifikátora konkrétneho shardchainu. Z formálneho hľadiska je každý shardchain definovaný dvojicou čísel (workchain_id, predpona_úlomku).

Oprava chyby. Vertikálne blockchainy.

Tradične sa každá transakcia na blockchaine považuje za „pevnú“. V prípade TON je však možné „prepísať históriu“ – v prípade, že niekto (tzv. rybársky uzol) preukáže, že jeden z blokov bol podpísaný nesprávne. V tomto prípade sa do zodpovedajúceho shardchainu pridá špeciálny opravný blok, ktorý obsahuje hash samotného opravovaného bloku (a nie posledného bloku v shardchaine). Keď uvažujeme o shardchaine ako o reťazi blokov usporiadaných horizontálne, môžeme povedať, že opravný blok je pripojený k chybnému bloku nie vpravo, ale zhora - takže sa predpokladá, že sa stáva súčasťou malého „vertikálneho blockchainu“ . Môžeme teda povedať, že shardchainy sú dvojrozmerné blockchainy.

Ak sa po chybnom bloku na ním vykonané zmeny odkazovali ďalšie bloky (t. j. nové transakcie boli vykonané na základe neplatných), opravné sa pridajú aj k týmto blokom „navrch“. Ak bloky neovplyvnili „ovplyvnené“ informácie, tieto „opravné vlny“ sa na ne nevzťahujú. Napríklad na obrázku vyššie bola transakcia prvého bloku zvyšujúca zostatok účtu C uznaná ako nesprávna - preto by sa mala zrušiť aj transakcia znižujúca zostatok tohto účtu v treťom bloku a opravný blok by mala byť vykonaná na vrchole samotného bloku.

Treba poznamenať, že hoci sú korekčné bloky zobrazené ako umiestnené „nad“ pôvodnými, v skutočnosti budú pridané na koniec zodpovedajúceho blockchainu (kde by mali byť chronologicky). Dvojrozmerné umiestnenie iba ukazuje, ku ktorému bodu v blockchaine budú „prepojené“ (cez hash pôvodného bloku, ktorý sa v nich nachádza).

Môžete samostatne filozofovať o tom, aké dobré je rozhodnutie „zmeniť minulosť“. Zdalo by sa, že ak pripustíme možnosť, že sa v shardchaine objaví nesprávny blok, potom sa nevyhneme možnosti, že sa objaví chybný opravný blok. Tu, pokiaľ viem, rozdiel je v počte uzlov, ktoré musia dosiahnuť konsenzus o nových blokoch – na každom shardchaine bude pracovať relatívne malý počet ľudí.“pracovná skupina» uzlov (ktoré pomerne často mení svoje zloženie) a na zavedenie opravných blokov bude potrebný súhlas všetkých uzly validátora. Viac o validátoroch, pracovných skupinách a iných rolách uzlov si poviem v ďalšom článku.

Jeden blockchain, ktorý bude vládnuť všetkým

Vyššie je uvedených veľa informácií o rôznych typoch blockchainov, ktoré by samotné mali byť niekde uložené. Hovoríme najmä o nasledujúcich informáciách:

• o počte a konfiguráciách pracovných reťazcov;
• o počte shardchainov a ich predponách;
• o tom, ktoré uzly sú momentálne zodpovedné za ktoré shardchainy;
• hash posledných blokov pridaných do všetkých shardchainov.

Ako ste možno uhádli, všetky tieto veci sú zaznamenané v inom blockchainovom úložisku – masterchain (masterchain, hlavný blockchain). Vďaka prítomnosti hashov z blokov všetkých shardchainov vo svojich blokoch je systém vysoko prepojený. To okrem iného znamená, že vygenerovanie nového bloku v masterchaine nastane ihneď po vygenerovaní blokov v shardchainoch – očakáva sa, že bloky v shardchainoch sa objavia takmer súčasne približne každých 5 sekúnd a ďalší blok v masterchain - sekundu po tom.

Kto však bude zodpovedný za realizáciu celej tejto titánskej práce – za odosielanie správ, vykonávanie inteligentných zmlúv, vytváranie blokov v shardchainoch a masterchaine a dokonca aj za kontrolu chýb v blokoch? Budú toto všetko tajne robiť telefóny miliónov používateľov s nainštalovaným klientom Telegram? Alebo možno tím Durov opustí myšlienky decentralizácie a ich servery to urobia staromódnym spôsobom?

V skutočnosti ani jedna, ani druhá odpoveď nie je správna. Okraje tohto článku sa ale rýchlo míňajú, a tak si o rôznych úlohách uzlov (možno ste si už všimli zmienky o niektorých z nich), ako aj o mechanike ich práce, povieme v ďalšej časti.

Zdroj: hab.com