See tekst on jätk artiklite seeriale, milles uurin (arvatavasti) hajutatud võrgu Telegram Open Network (TON) struktuuri, mida valmistatakse sel aastal avaldamiseks ette. IN Kirjeldasin selle kõige elementaarsemat taset – viisi, kuidas sõlmed üksteisega suhtlevad.
Igaks juhuks tuletan meelde, et mul pole selle võrgu arendamisega mingit pistmist ja kogu materjal on ammutatud avatud (kuigi kontrollimata) allikast - (kaasas on ka , tuues lühidalt välja põhipunktid), mis ilmus eelmise aasta lõpus. Selles dokumendis sisalduv teabe hulk näitab minu arvates selle autentsust, kuigi ametlikku kinnitust sellele pole.
Täna vaatleme TONi põhikomponenti - plokiahelat.
Põhimõisted
Konto (konto). 256-bitise numbriga identifitseeritud andmekogum Konto ID (enamasti on see konto omaniku avalik võti). Põhijuhul (vt allpool null tööahel), viitavad need andmed kasutaja saldole. "Occupy" spetsiifiline Konto ID igaüks võib, kuid selle väärtust saab muuta ainult teatud reeglite järgi.
Nutikas leping (nutikas leping). Sisuliselt on tegemist konto erijuhtumiga, mida on täiendatud nutika lepingu koodi ja selle muutujate salvestusega. Kui “rahakoti” puhul saab sinna raha sisse panna ja välja võtta suhteliselt lihtsate ja etteantud reeglite järgi, siis nutika lepingu puhul on need reeglid kirjas selle koodi kujul (teatud Turing-complete programmeerimiskeel).
Blockchaini osariik (plokiahela olek). Kõigi kontode/nutikate lepingute olekute kogum (abstraktses mõttes räsitabel, kus võtmeteks on konto identifikaatorid ja väärtusteks kontodele salvestatud andmed).
Sõnum (sõnum). Eespool kasutasin väljendit “krediidi- ja deebetraha” – see on konkreetne näide sõnumist (“ülekanne N grammi kontolt konto_1 kontole konto_2"). Ilmselgelt saab sellist sõnumit saata ainult sõlm, mis omab konto privaatvõtit konto_1 - ja suudab seda allkirjaga kinnitada. Selliste sõnumite tavakontole edastamise tulemuseks on selle saldo suurenemine ja nutika lepingu tulemuseks on selle koodi (mis töötleb sõnumi vastuvõtmist) täitmine. Muidugi on võimalikud ka muud sõnumid (mitte rahasummade, vaid suvaliste andmete ülekandmine nutikate lepingute vahel).
Tehing (tehing). Sõnumi edastamist nimetatakse tehinguks. Tehingud muudavad plokiahela olekut. Plokiahelas moodustavad plokid tehingud (sõnumiedastuskirjed). Sellega seoses võite mõelda plokiahela olekule kui inkrementaalsele andmebaasile - kõik plokid on "diffid", mida tuleb andmebaasi praeguse oleku saamiseks järjestikku rakendada. Nende "diffide" pakendamise (ja nendest täieliku oleku taastamise) spetsiifikat käsitletakse järgmises artiklis.
Blockchain TONis: mis see on ja miks?
Nagu eelmises artiklis mainitud, plokiahel on andmestruktuur, mille elemendid (plokid) on järjestatud "ahelasse" ja iga järgmine ahela plokk sisaldab eelmise räsi. Kommentaarides esitati küsimus: milleks meil sellist andmestruktuuri üldse vaja on, kui meil on juba DHT – hajutatud räsitabel? Ilmselgelt saab mõningaid andmeid DHT-s salvestada, kuid see sobib ainult mitte liiga "tundliku" teabe jaoks. Krüptovaluuta saldosid ei saa DHT-s salvestada – seda eelkõige kontrollide puudumise tõttu terviklikkus. Tegelikult kasvab plokiahela struktuuri kogu keerukus, et vältida häireid selles salvestatud andmetega.
TONi plokiahel näeb aga veelgi keerulisem kui enamikus teistes hajutatud süsteemides – ja seda kahel põhjusel. Esimene on soov minimeerida vajadust kahvlid. Traditsiooniliste krüptovaluutade puhul seatakse kõik parameetrid paika algstaadiumis ja iga katse neid muuta viib tegelikult „alternatiivse krüptoraha universumi“ tekkeni. Teine põhjus on purustamise toetamine (killustamine, killustamine) plokiahel. Blockchain on struktuur, mis ei saa aja jooksul väiksemaks muutuda; ja tavaliselt on iga võrgu toimimise eest vastutav sõlm sunnitud selle täielikult salvestama. Traditsioonilistes (tsentraliseeritud) süsteemides kasutatakse selliste probleemide lahendamiseks shardingut: osa andmebaasi kirjeid asuvad ühes serveris, osa teises jne. Krüptovaluutade puhul on selline funktsionaalsus veel üsna haruldane – eeskätt selle tõttu, et sharding’i on keeruline lisada süsteemi, kus see algselt plaanis polnud.
Kuidas kavatseb TON mõlemat ülaltoodud probleemi lahendada?
Plokiahela sisu. Tööahelad.
Kõigepealt räägime sellest, mida plaanitakse plokiahelasse salvestada. Sinna salvestatakse kontode olekud (põhijuhul “rahakotid”) ja nutikad lepingud (lihtsuse huvides eeldame, et see on sama, mis kontod). Sisuliselt on see tavaline räsitabel – selles olevad võtmed on identifikaatorid Konto ID, ja väärtused on andmestruktuurid, mis sisaldavad selliseid asju nagu:
- tasakaal;
- nutika lepingu kood (ainult nutikate lepingute puhul);
- nutika lepingu andmete salvestamine (ainult arukate lepingute jaoks);
- statistika;
- (vabatahtlik) kontolt ülekannete avalik võti, vaikimisi konto_id;
- väljaminevate sõnumite järjekord (siia sisestatakse need adressaadile edastamiseks);
- sellele kontole saadetud viimaste sõnumite loend.
Nagu eelpool mainitud, koosnevad plokid ise tehingutest – erinevatele account_id kontodele toimetatud sõnumitest. Kuid peale konto_id sisaldavad sõnumid ka 32-bitist välja tööahela_id — nn identifikaator tööahel (tööahel, töötav plokiahel). See võimaldab teil omada mitut üksteisest sõltumatut erineva konfiguratsiooniga plokiahelat. Sel juhul peetakse tööahela_id = 0 erijuhtumiks, null tööahel — selles olevad saldod vastavad krüptovaluutale TON (grammid). Tõenäoliselt pole esialgu muid tööahelaid üldse olemas.
Killuketid. Lõpmatu jagamise paradigma.
Kuid plokiahelate arvu kasv ei lõpe sellega. Tegeleme killustamisega. Kujutagem ette, et igale kontole (account_id) on eraldatud oma plokiahel - see sisaldab kõiki sellele saabuvaid sõnumeid - ja kõigi selliste plokiahelate olekud salvestatakse eraldi sõlmedesse.
Muidugi on see väga raiskav: tõenäoliselt kõigis neist shardchainid (shardchain, shard blockchain) tehinguid saabuvad väga harva ja vaja on palju võimsaid sõlme (tulevikku vaadates märgin, et me ei räägi ainult mobiiltelefonide klientidest - vaid tõsistest serveritest).
Seetõttu ühendavad shardchainid kontod nende identifikaatorite binaarsete eesliidete järgi: kui shardchainil on eesliide 0110, hõlmab see kõigi nende numbritega algavate konto_id-de tehinguid. See killu_prefiks pikkus võib olla 0 kuni 60 bitti - ja peamine on see, et see võib dünaamiliselt muutuda.
Niipea kui üks shardchainidest hakkab vastu võtma liiga palju tehinguid, jagavad sellega töötavad sõlmed vastavalt etteantud reeglitele selle kaheks lapseks - nende eesliited on natuke pikemad (ja ühe jaoks on see bitt võrdne 0-ga ja teise jaoks - 1). Näiteks, killu_prefiks = 0110b jaguneb 01100b ja 01101b. Omakorda, kui kaks "naaber" shardchaini hakkavad end (mõnda aega) piisavalt vabalt tundma, ühinevad nad uuesti.
Seega toimub killustamine "alt üles" - eeldame, et igal kontol on oma kild, kuid esialgu on need eesliidetega "kokku liimitud". Seda see tähendab Lõpmatu jagamise paradigma (lõpmatu killustamise paradigma).
Eraldi tahaksin rõhutada, et tööahelad eksisteerivad ainult virtuaalselt – tegelikult tööahela_id see on osa konkreetse shardchaini identifikaatorist. Formaalses mõttes on iga shardchain määratletud numbripaariga (tööahela_id, killu_prefiks).
Veaparandus. Vertikaalsed plokiahelad.
Traditsiooniliselt peetakse iga plokiahela tehingut "kivisse raiutuks". TONi puhul on aga võimalik “ajalugu ümber kirjutada” – juhuks, kui keegi (nn. kalamehe sõlm) tõestab, et üks plokkidest on valesti allkirjastatud. Sel juhul lisatakse vastavale shardchainile spetsiaalne parandusplokk, mis sisaldab parandatava ploki enda räsi (ja mitte shardchaini viimast plokki). Mõeldes shardchainile kui horisontaalselt paigutatud plokkide ahelale, võime öelda, et parandusplokk kinnitatakse vigase ploki külge mitte paremalt, vaid ülalt - seega arvatakse, et see muutub väikese "vertikaalse plokiahela" osaks. . Seega võime öelda, et shardchainid on kahemõõtmelised plokiahelad.
Kui pärast vigast plokki viitasid selle tehtud muudatustele järgmised plokid (st tehti uusi tehinguid kehtetute põhjal), lisatakse nendele plokkidele "peale" ka parandavad. Kui plokid ei mõjutanud "mõjutatud" teavet, ei kehti need "paranduslained" nende kohta. Näiteks ülaltoodud illustratsioonil tunnistati esimese ploki tehing, mis suurendas konto C jääki, ebaõigeks - seetõttu tuleks tühistada ka selle konto saldot vähendav tehing kolmandas plokis ja korrigeeriv blokk. tuleks toime panna ploki enda peale.
Tuleb märkida, et kuigi korrigeerivad plokid on kujutatud algsetest "ülevalpool", lisatakse need tegelikult vastava plokiahela lõppu (kus need peaksid olema kronoloogiliselt). Kahemõõtmeline asukoht näitab ainult seda, millisesse punkti plokiahelas nad "lingitakse" (nendes asuva algse ploki räsi kaudu).
Eraldi saate filosofeerida selle üle, kui hea on otsus "minevikku muuta". Näib, et kui tunnistame võimalust, et shardchainis ilmub vale plokk, siis ei saa me vältida vigase parandusploki ilmumise võimalust. Siin, niipalju kui ma aru saan, on erinevus nende sõlmede arvus, mis peavad jõudma konsensusele uute plokkide osas - iga shardchainiga töötab suhteliselt väike arv inimesi.töögrupp» sõlmed (mis muudab oma koostist üsna sageli) ja parandusplokkide kasutuselevõtt nõuab kõigi nõusolekut validaatori sõlmed. Validaatoritest, töörühmadest ja muudest sõlmerollidest räägin täpsemalt järgmises artiklis.
Üks plokiahel nende kõigi valitsemiseks
Eespool on loetletud palju teavet erinevate plokiahelate tüüpide kohta, mida tuleks samuti kuskil hoida. Eelkõige räägime järgmisest teabest:
- tööahelate arvu ja konfiguratsioonide kohta;
- shardchainide arvu ja nende eesliidete kohta;
- selle kohta, millised sõlmed vastutavad praegu milliste shardchainide eest;
- kõikidele shardchainidele lisatud viimaste plokkide räsid.
Nagu võis arvata, on kõik need asjad salvestatud teise plokiahela salvestusruumi - meistrikett (meisterikett, plokiahela juht). Kuna selle plokkides on kõikide shardchainide plokkidest pärit räsi, muudab see süsteemi tugevalt ühendatud. See tähendab muuhulgas, et uue ploki genereerimine põhiahelas toimub kohe pärast plokkide genereerimist shardchainides – eeldatakse, et shardchainides olevad plokid ilmuvad peaaegu üheaegselt ligikaudu iga 5 sekundi järel ja järgmine plokk masterchain - sekund pärast seda.
Kuid kes vastutab kogu selle titaanliku töö elluviimise eest - sõnumite saatmise, nutikate lepingute täitmise, shardchainides ja põhiahelas plokkide moodustamise ning isegi plokkide vigade kontrollimise eest? Kas seda kõike teevad salaja miljonite kasutajate telefonid, millele on installitud Telegrami klient? Või äkki loobub Durovi meeskond detsentraliseerimise ideedest ja nende serverid teevad seda vanamoodsalt?
Tegelikult pole ei üks ega teine vastus õige. Kuid selle artikli veerised saavad kiiresti otsa, nii et järgmises osas räägime sõlmede erinevatest rollidest (võib-olla olete juba märganud mõnda neist mainimist) ja nende töö mehaanikast.
Allikas: www.habr.com