To besedilo je nadaljevanje serije člankov, v katerih preučujem strukturo (predvidoma) porazdeljenega omrežja Telegram Open Network (TON), ki je v pripravi za izdajo letos. IN Opisal sem njegovo najosnovnejšo raven – način interakcije vozlišč med seboj.
Za vsak slučaj naj vas spomnim, da nimam nič z razvojem tega omrežja in da je bilo vse gradivo pobrano iz odprtega (čeprav nepreverjenega) vira - (obstaja tudi spremljava , ki na kratko opisuje glavne točke), ki se je pojavil konec lanskega leta. Količina informacij v tem dokumentu po mojem mnenju kaže na njegovo verodostojnost, čeprav uradne potrditve tega ni.
Danes si bomo ogledali glavno komponento TON - verigo blokov.
Osnovni pojmi
Račun (račun). Niz podatkov, označenih z 256-bitnim številom account_id (najpogosteje je to javni ključ lastnika računa). V osnovnem primeru (glejte spodaj ničelna delovna veriga), ti podatki se nanašajo na stanje uporabnika. Specifično za "Occupy". account_id lahko kdorkoli, vendar se njegova vrednost lahko spremeni le v skladu z določenimi pravili.
Pametna pogodba (pametna pogodba). V bistvu gre za poseben primer računa, ki je dopolnjen s kodo pametne pogodbe in shranjevanjem njenih spremenljivk. Če lahko v primeru »denarnice« položite in dvignete denar iz nje po razmeroma enostavnih in vnaprej določenih pravilih, potem so v primeru pametne pogodbe ta pravila zapisana v obliki njene kode (v določenem Turingovem kompletu). programski jezik).
Stanje verige blokov (stanje blockchaina). Nabor stanj vseh računov/pametnih pogodb (v abstraktnem smislu zgoščena tabela, kjer so ključi identifikatorji računa, vrednosti pa podatki, shranjeni v računih).
Sporočilo (Sporočilo). Zgoraj sem uporabil izraz "kreditni in debetni denar" - to je poseben primer sporočila ("prenos N gramov iz računa račun_1 na račun račun_2"). Očitno lahko takšno sporočilo pošlje le vozlišče, ki ima v lasti zasebni ključ računa račun_1 - in to lahko potrdi s podpisom. Rezultat dostave tovrstnih sporočil na navaden račun je povečanje njegovega stanja, rezultat pametne pogodbe pa je izvršitev njene kode (ki bo obdelala prejem sporočila). Možna so seveda tudi druga sporočila (prenos ne denarnih zneskov, ampak poljubnih podatkov med pametnimi pogodbami).
Transakcija (transakcija). Dejstvo, da je sporočilo dostavljeno, se imenuje transakcija. Transakcije spremenijo stanje verige blokov. Prav transakcije (zapisi o dostavi sporočil) sestavljajo bloke v verigi blokov. V zvezi s tem si lahko predstavljate stanje verige blokov kot inkrementalno bazo podatkov - vsi bloki so "razlike", ki jih je treba uporabiti zaporedno, da dobite trenutno stanje baze podatkov. O posebnostih pakiranja teh »razlik« (in obnavljanja celotnega stanja iz njih) bomo razpravljali v naslednjem članku.
Blockchain v TON: kaj je to in zakaj?
Kot je omenjeno v prejšnjem članku, blockchain je podatkovna struktura, katere elementi (bloki) so razvrščeni v "verigo", vsak naslednji blok verige pa vsebuje zgoščeno vrednost prejšnjega.. Komentarji so postavljali vprašanje: zakaj sploh potrebujemo takšno podatkovno strukturo, ko pa že imamo DHT – porazdeljeno zgoščeno tabelo? Očitno je mogoče nekatere podatke shraniti v DHT, vendar je to primerno le za ne preveč "občutljive" informacije. Stanja kriptovalut ni mogoče shraniti v DHT – predvsem zaradi pomanjkanja preverjanj celovitost. Pravzaprav celotna kompleksnost strukture blockchain raste, da bi preprečili motnje v podatkih, ki so v njej shranjeni.
Vendar je veriga blokov v TON videti še bolj zapletena kot v večini drugih porazdeljenih sistemov – in to iz dveh razlogov. Prva je želja po zmanjšanju potrebe po vilice. Pri tradicionalnih kriptovalutah so vsi parametri nastavljeni v začetni fazi in vsak poskus njihove spremembe dejansko vodi v nastanek »alternativnega vesolja kriptovalut«. Drugi razlog je podpora za drobljenje (drobljenje, drobljenje) veriga blokov. Blockchain je struktura, ki se sčasoma ne more zmanjšati; in običajno ga je vsako vozlišče, ki je odgovorno za delovanje omrežja, prisiljeno v celoti shraniti. V tradicionalnih (centraliziranih) sistemih se za reševanje takšnih težav uporablja sharding: nekateri zapisi v bazi podatkov se nahajajo na enem strežniku, nekateri na drugem itd. V primeru kriptovalut je takšna funkcionalnost še vedno precej redka – zlasti zaradi dejstva, da je težko dodati razdeljevanje v sistem, kjer prvotno ni bilo načrtovano.
Kako namerava TON rešiti oba zgoraj navedena problema?
Vsebina verige blokov. Delovne verige.
Najprej se pogovorimo o tem, kaj je načrtovano za shranjevanje v verigi blokov. Tam bodo shranjena stanja računov (»denarnice« v osnovnem primeru) in pametnih pogodb (zaradi poenostavitve bomo predpostavili, da je to isto kot računi). V bistvu bo to običajna zgoščena tabela - ključi v njej bodo identifikatorji account_id, vrednosti pa so podatkovne strukture, ki vsebujejo stvari, kot so:
- ravnovesje;
- koda pametne pogodbe (samo za pametne pogodbe);
- shranjevanje podatkov pametnih pogodb (samo za pametne pogodbe);
- statistika;
- (neobvezno) javni ključ za nakazila z računa, privzeto account_id;
- čakalna vrsta odhodnih sporočil (tu se vnesejo za posredovanje prejemniku);
- seznam zadnjih sporočil, dostavljenih na ta račun.
Kot je navedeno zgoraj, so bloki sami sestavljeni iz transakcij - sporočil, dostavljenih različnim računom account_id. Vendar sporočila poleg account_id vsebujejo tudi 32-bitno polje workchain_id — tako imenovani identifikator delovna veriga (delovna veriga, delujoča veriga blokov). To vam omogoča, da imate več verig blokov, neodvisnih druga od druge, z različnimi konfiguracijami. V tem primeru se workchain_id = 0 obravnava kot poseben primer, ničelna delovna veriga — ravno stanje v njem bo ustrezalo kriptovaluti TON (Grams). Najverjetneje sprva druge delovne verige sploh ne bodo obstajale.
Shardchains. Paradigma neskončnega drobljenja.
Toda rast števila blokovnih verig se tu ne ustavi. Ukvarjajmo se s šardingom. Predstavljajmo si, da je vsakemu računu (account_id) dodeljena lastna veriga blokov – vsebuje vsa sporočila, ki pridejo do njega – stanja vseh takih verig blokov pa so shranjena na ločenih vozliščih.
Seveda je to zelo potratno: najverjetneje v vsakem od teh verige drobcev (shardchain, shard blockchain) transakcije bodo prispele zelo redko in potrebnih bo veliko močnih vozlišč (če pogledam naprej, ugotavljam, da ne govorimo samo o odjemalcih na mobilnih telefonih - ampak o resnih strežnikih).
Zato verige drobcev združujejo račune glede na binarne predpone njihovih identifikatorjev: če ima veriga drobcev predpono 0110, bo vključevala transakcije vseh account_id-jev, ki se začnejo s temi številkami. to shard_prefix lahko ima dolžino od 0 do 60 bitov - in glavna stvar je, da se lahko dinamično spreminja.
Takoj, ko začne ena od verig shardchainov prejemati preveč transakcij, jo vozlišča, ki delajo na njej, po vnaprej določenih pravilih »razdelijo« na dva otroka - njune predpone bodo en bit daljše (in za enega od njih bo ta bit enako 0, za drugo pa 1). na primer shard_prefix = 0110b se bo razdelil na 01100b in 01101b. Če se dve »sosednji« verigi drobcev začneta počutiti dovolj sproščeno (za nekaj časa), se bosta znova združili.
Sharding torej poteka "od spodaj navzgor" - predvidevamo, da ima vsak račun svoj shard, vendar so zaenkrat "zlepljeni" s predponami. To pomeni Paradigma neskončnega drobljenja (paradigma neskončnega drobljenja).
Ločeno bi rad poudaril, da delovne verige obstajajo le virtualno - v resnici workchain_id je del identifikatorja določene verige drobcev. Formalno je vsaka veriga drobcev definirana s parom številk (workchain_id, shard_prefix).
Popravek napak. Navpične verige blokov.
Tradicionalno velja, da je vsaka transakcija v verigi blokov "vklenjena v kamen". Vendar pa je v primeru TON mogoče "prepisati zgodovino" - v primeru, da nekdo (ti. ribiški vozel) bo dokazal, da je bil eden od blokov nepravilno podpisan. V tem primeru se v ustrezno verigo segmentov doda poseben korekcijski blok, ki vsebuje zgoščeno vrednost samega bloka, ki se popravlja (in ne zadnjega bloka v verigi segmentov). Če razmišljamo o shardchainu kot o verigi blokov, postavljenih vodoravno, lahko rečemo, da je korektivni blok pritrjen na napačni blok ne na desni, ampak od zgoraj - zato se šteje, da postane del majhne "navpične verige blokov" . Tako lahko rečemo, da shardchains so dvodimenzionalne verige blokov.
Če so se po napačnem bloku spremembe, ki jih je naredil, sklicevale na naslednje bloke (tj. nove transakcije so bile opravljene na podlagi neveljavnih), se tem blokom "na vrhu" dodajo tudi popravne. Če bloki niso vplivali na "prizadete" informacije, ti "popravljalni valovi" zanje ne veljajo. Na primer, na zgornji sliki je bila transakcija prvega bloka, ki je povečala stanje na računu C, prepoznana kot nepravilna - zato je treba preklicati tudi transakcijo, ki je zmanjšala stanje tega računa v tretjem bloku, in izvesti korektivni blok. mora biti zavezan na vrhu samega bloka.
Upoštevati je treba, da čeprav so korektivni bloki upodobljeni, kot da se nahajajo "nad" prvotnimi, bodo v resnici dodani na konec ustrezne verige blokov (kjer bi morali biti kronološko). Dvodimenzionalna lokacija samo pokaže, na katero točko v verigi blokov bodo "povezani" (prek zgoščene vrednosti prvotnega bloka, ki se nahaja v njih).
Ločeno lahko filozofirate o tem, kako dobra je odločitev za "spreminjanje preteklosti". Zdi se, da se ne moremo izogniti možnosti pojava napačnega popravljalnega bloka, če priznamo možnost pojava napačnega bloka v shardchainu. Tukaj, kolikor lahko povem, je razlika v številu vozlišč, ki morajo doseči soglasje o novih blokih - na vsaki verigi shardchaina bo delalo relativno majhno število ljudi."delovna skupina» vozlišča (ki precej pogosto spreminjajo sestavo), za uvedbo korektivnih blokov pa bo potrebno soglasje vseh validatorska vozlišča. Več o validatorjih, delovnih skupinah in drugih vlogah vozlišč bom govoril v naslednjem članku.
Ena veriga blokov, ki bo vladala vsem
Zgoraj je naštetih veliko informacij o različnih vrstah verig blokov, ki jih je prav tako treba nekje shraniti. Zlasti govorimo o naslednjih informacijah:
- o številu in konfiguracijah delovnih verig;
- o številu shardchainov in njihovih predponah;
- o tem, katera vozlišča so trenutno odgovorna za katere verige drobcev;
- zgoščene vrednosti zadnjih blokov, dodanih vsem verigam drobcev.
Kot ste morda uganili, so vse te stvari zabeležene v drugi shrambi verige blokov - masterchain (masterchain, master blockchain). Zaradi prisotnosti zgoščenj iz blokov vseh verig shardchain v svojih blokih naredi sistem zelo povezan. To med drugim pomeni, da se bo generiranje novega bloka v masterchainu zgodilo takoj za generiranjem blokov v shardchain-ih – predvidoma se bodo bloki v shardchain-ih pojavili skoraj istočasno približno vsakih 5 sekund, naslednji blok v masterchain - sekundo za tem.
Toda kdo bo odgovoren za izvedbo vsega tega titanskega dela - za pošiljanje sporočil, izvajanje pametnih pogodb, oblikovanje blokov v verigah shardchain in masterchain ter celo preverjanje napak v blokih? Bodo vse to na skrivaj počeli telefoni milijonov uporabnikov z nameščenim odjemalcem Telegram? Ali pa bo ekipa Durov morda opustila ideje o decentralizaciji in bodo njihovi strežniki to storili na staromoden način?
Pravzaprav ne en ne drugi odgovor ni pravilen. Toda rob tega članka hitro zmanjka, zato bomo o različnih vlogah vozlišč (morda ste že opazili omembe nekaterih) in o mehaniki njihovega delovanja spregovorili v naslednjem delu.
Vir: www.habr.com