TON: Telegram Open Network. Osa 2: Blockchain'id, shardimine

See tekst on järje jätk, kus ma käsitlen struktuuri (pretensiooniliselt) käesoleval aastal käivituma valmistuvat jaotatud võrku Telegram Open Network (TON). eelmisel osal Siin kirjeldan ma selle kõige põhitaset - ühendustevaheline suhtlemine sõlmede vahel.

Igaks juhuks tuletan meelde, et mul ei ole selle võrgu arendamisega mingit seost ja kogu materjal on saadud avatud (kuigi kontrollimata) allikast - dokument (sealsetele on lisatud brošüür, mis lühidalt tutvustab peamisi punkte), mis ilmus eelmise aasta lõpus. Minu arvates viitab selle dokumendi info maht selle ehtsusele, kuigi ametlikke kinnitusi selle kohta ei ole.

Täna vaatame TONi peamist komponenti - plokiahelat.

Põhiteadmised

konto) (account). Teatud andmekogum, mida tuvastatakse 256-bitise numbriga account_id (enamasti on see konto omaniku avalik võti). Põhilisel juhul (vt allpool nullinõi), mõistetakse nende andmete all kasutaja bilanssi. Konkreetselt "laenata" võib igaüks, kuid selle väärtuse muutmine on lubatud ainult teatud reeglite alusel. account_id igaüks, kuid selle väärtust saab muuta ainult teatud reeglite alusel.

Nutileping (smart-contract). Põhimõtteliselt on see konto erijuhtum, millele on lisatud nutilepingu kood ja selle muutujaid sisaldav salvestus. Kui „rahakoti“ puhul saab raha kanda ja välja võtta suhteliselt lihtsate ja ette määratud reeglite alusel, siis nutilepingu puhul on need reeglid kirja pandud selle koodina (mõnes Turingi täielikus programmeerimiskeeles).

Plokiahela olek (plokiahela olek). Kõikide kontode/nutilepingute olekute kogum (abstraktse tähenduses — hash-tabel, kus võtmed on kontode identifikaatorid ja väärtused on kontodes salvestatud andmed).

Teade (message). Eelnevalt kasutasin väljendit „kaardil ja välja võtma raha“ — see on konkreetne näide sõnumist ("kanda N grammi kontolt account_1 konto peale account_2"). On ilmne, et sellist sõnumit saab saata ainult sõlm, kellel on konto privaatvõti. account_1 — ja suudab seda allkirjaga kinnitada. Selliste teadete tavalisse kontole saatmise tulemuseks on selle saldo suurenemine ning nutilepingule – selle koodi täitmine (mis käsitleb sõnumi vastuvõttu). Loomulikult on võimalikud ka teised teated (mis ei edasta raha summasid, vaid erinevaid andmeid nutilepingute vahel).

Tehing (tehing). Sõnumi kohaletoimetamise fakti nimetatakse tehinguks. Tehingud muudavad plokiahela seisundit. Just tehingutest (sõnumite kohaletoimetamise kirjed) koosnevad plokiahela plokid. Sellega seoses võib plokiahela seisundit ette kujutada nagu inkremenalset andmebaasi – kõik plokid on „diffid”, mida tuleb järjestikku rakendada, et saada praegune andmebaasi seisund. Nende „diffide” pakkimise konkreetsusest (ja täieliku seisundi rekonstruktsiooni osas) räägime järgmises artiklis.

Plokiahel TON-is: mis see on ja milleks on vajalik?

Nagu mainitud eelnevas artiklis, plokiahel on andmestruktuur, mille elemendid (plokid) on järjestatud „ahelaks”, ja iga järgmine ahela plokk sisaldab eelmise hashi.. Kommentaarides esitati küsimus: miks on selline andmestruktuur üldse vajalik, kui meil juba on DHT — jaotatud räsitabel? Selgelt on mõned andmed võimalik salvestada ka DHT-s, kuid see sobib vaid mitte liiga "tundlike" infosüsteemide jaoks. Krüptoraha saldosid ei saa DHT-s hoida — peamiselt kontrollimise puudumise tõttu puutumatuse. Tegelikult, kogu plokiahela struktuuri keerukus kasvab, et takistada sekkumist talle salvestatud andmetesse.

Siiski, plokiahel TON-is näeb välja veel keerulisem kui enamik teisi jaotatud süsteeme — ja sellel on kaks põhjust. Esimene — soov vähendada vajadust harude järele. Traditsioonilistes krüptovaluutades on kõik parameetrid määratud algfaasis ja any katsed neid muuta toovad sisuliselt kaasa "alternatiivse krüptovaluuta universumi". Teine põhjus — fragmentatsiooni toetamine (shardimise, fragmentatsiooni) plokia. Plokia on struktuur, mis ei saa aja jooksul väiksemaks muutuda; ja tavaliselt on iga sõlm, mis vastutab võrgu töökindluse eest, sunnitud seda täielikult säilitama. Traditsioonilistes (kesksetes) süsteemides rakendatakse selliste probleemide lahendamiseks sharding'ut: osa andmetest andmebaasis asub ühel serveril, osa - teisel jne. Krüptovaluutade puhul on selline funktsionaalsus seni üsna haruldane - eeskätt seetõttu, et on keeruline lisada sharding'ut süsteemi, kus seda ei ole algselt kavandatud.

Kuidas kavatseb TON lahendada mõlemad eespool kirjeldatud probleemid?

Plokia sisu. Võrguplokid.

Esiteks räägime sellest, mida kavatsetakse plokias hoiustada. Seal hoitakse kontode ('rahakottide' põhijuhtumina) ja nutilepingute olekuid (lihtsuse huvides oletame, et need on sama, mis kontod). Põhimõtteliselt on see tavaline räsitabel - võtmed selles on identifikaatorid account_id, ja väärtused - andmestruktuurid, mis sisaldavad selliseid asju nagu:

• saldo;
• nutilepingu kood (ainult nutilepingute jaoks);
• nutikate smart-lepingute andmed (ainult smart-lepingute jaoks);
• statistika;
• (valikuline) avalik võti konto ülekanneteks, vaikimisi account_id;
• väljuvate sõnumite järjekord (siia saadetakse, et edastada saajale);
• viimastele selle kontole edastatud sõnumite loend.

Nagu eelnevalt mainitud, koosnevad plokid otsekohe tehingutest — sõnumitest, mis on edastatud erinevatele kontodele account_id. Kuid lisaks account_id-le sisaldavad sõnumid ka 32-bitist välja workchain_id — nn identifikaator. workchain (töötav plokiahel, ). See võimaldab erinevate konfiguratsioonidega sõltumatute plokiahelate olemasolu. Samuti loetakse workchain_id = 0 erandjuhuks,nullworkchain — just selles olevaid saldosid vastavad krüptovaluutale TON (Gramad). Tuleb tõenäoliselt, et alguses ei eksisteeri teisi plokiahelate. Shard chain. Infinite Sharding Paradigm.

Shard-chains. Infinite Sharding Paradigm.

Kuid see ei tähenda, et plokiahelate arv ei jätku suureneda. Uurime sharding'ut. Kujutame ette, et igale kontole (account_id) on määratud oma plokiahel — kuhu salvestatakse kõik sellele saabuvaid sõnumeid — ja kõigi nende plokiahelate olekud hoitakse eraldi sõlmedes.

Loomulikult on see üsna raiskav: tõenäoliselt tuleb igasse neist shardchainidesse (shardchain, shard blockchain) tehingud tulevad väga harva, ja vajalik on palju võimsaid sõlmi (ütlen kohe, et jutt ei ole ainult mobiiltelefonide klientidest — vaid tõsistest serveritest).

Seetõttu ühendavad shardchainid kontod nende tuvastajate binaarsete prefiksidega: kui shardchainil on prefiks 0110, siis satuvad sellesse kõik account_id, mis algavad nende numbritega. See shard_prefix võib olla pikkus vahemikus 0 kuni 60 bitti — ja mis kõige tähtsam, see võib dünaamiliselt muutuda.

Kui ühe shardi lake hakkab laekuma liialt palju tehinguid, siis shardi kallal töötavad sõlmed jagavad selle etteantud reeglite kohaselt kaheks alam-shardiks, mille prefiksid on ühe bitiga pikemad (ja ühel neist on see bit 0, teisel aga 1). Näiteks, shard_prefix = 0110b jaguneb 01100b ja 01101b. Kui kaks 'naabruses' asuvat shardchaini tunnevad end piisavalt mugavalt (teatud aja jooksul), siis need taasühinevad.

Seega toimub sharding 'alustades alt' — me eeldame, et igal kontol on oma shard, kuid need on — vaid seni — 'liidetud' prefikside kaudu. Just seda tähendab Piiramatu jaotamise paradigma (lõputu sharding'i paradigma.).

Eriliselt tahaks rõhutada, et workchainid eksisteerivad ainult virtuaalselt — tegelikult, workchain_id see on osa konkreetse shardchain'i identifikaatorist. Formaalselt öeldes, iga shardchain on määratletud paarina numbreid (workchain_id, shard_prefix).

Vigade parandamine. Vertikaalsed blokkheindid.

Traditsiooniliselt peetakse igat tehingut plokiahelas "kivisse raiutuks". Kuid TON-i puhul on ette nähtud võimalus "lugu ümber kirjutada" — juhul, kui keegi (nn püügipunkt) tõestab, et üks plokk on allkirjastatud vale moodi. Sellisel juhul lisatakse vastavasse shardchain'i spetsiaalne parandav plokk, mis sisaldab parandatava ploki hash'i (mitte viimase ploki hash'i shardchain'is). Kui vaadata shardchain'i kui horisontaalset plokkide ahelat, võib öelda, et parandav plokk kinnitatakse mitte vale ploki paremale, vaid ülemisele poole — seega peetakse seda väikese "vertikaalse plokiahela" osaks. Nii võib öelda, et shardchain'id on kahemõõtmelised plokiahelad.

Kui pärast valeploki peal muudetud muudatustele viidati järgmistes plokkides (st kehtetute alusel tehti uusi tehinguid), lisatakse ka nende plokkide peale korrigeerivad. Kui plokid ei puudutanud "tabatud" teavet, ei laiene need "korrektsioonilaine" neile. Näiteks ülaltoodud illustratsioonis tunnistati valeplokiks esimese ploki tehing, mis suurendas konto C bilanssi — seega peab ka selle konto bilanssi vähendav tehing kolmandas plokis olema tühistatud ja korrektuuri plokk peab olema koos plokiga commititud.

Olgu märgitud — kuigi korrigeerivad plokid kuvatakse paigutatuna "üle" originaalplokkide, kirjutatakse need tegelikult vastava ploki plokiahelas lõppu (seal, kus need chronoloogiliselt peaksid olema). Kaks mõõdet näitab lihtsalt, millele plokiahelas nad "kinnitatakse" (originaalploki hash, mis on neis).

Võime eraldi filosoofia mõttes arutada, kui hea on lahendus "mineviku muutmine". Tundub, et kui lubame moonutatud ploki ilmumist sharding'usse, ei saa me samas välistada ka vale parandava ploki tekkimist. Siin, kuivõrd mina suudan otsustada, on erinevus sõlmede arvus, mis peab jõudma uute plokkide konsensusele - iga sharding'u kallal töötab suhteliselt väike "töögrupp" sõlme (mis üsna tihti muudab oma koosseisu), ent parandavate plokkide lisamine nõuab kõigi sertifitseerimis-sõlmede. Täiendavalt räägin ma sertifitseerijatest, töögruppidest ja teistest sõlmede rollidest järgmises artiklis.

Üks plokiahel, et hallata kõike

Ülaltoodud on palju teavet erinevat tüüpi plokiahelate kohta, mida tuleks ka kuskil hoida. Eelkõige on juttu järgmistest andmetest:

• töötavate plokkide arvu ja konfigureerimise kohta;
• sharding'ute arvu ja nende eesliidete kohta;
• millised sõlmed on hetkel vastutavad milliste sharding'ute eest;
• viimati lisatud plokkide hash'id kõikidesse sharding'utesse.

Kuidas te juba võisite arvata, kõik need asjad salvestatakse veel ühte ladustamisse, plokiahelasse — meistriplokiahel (masterchain, meistriplokiahel). Aitäh sellele, et selle plokkides on shaardplokkide plokkide hashid, teeb see süsteemi tugevalt seotud. See tähendab ka, et uusi bloki genereerimine meistriplokiahelas toimub vahetult pärast shaardplokkide genereerimist — oodatakse, et bloki shaardides ilmuvad peaaegu samaaegselt ligikaudu iga 5 sekundi järel, ja järgmine blokk meistriplokiahelas — sekundi pärast seda.

Aga kes siis vastutab kogu selle titanilise töö teostamise eest — sõnumite edastamine, nutilepingute täitmine, plokkide loomine shaardplokkides ja meistriplokiahelas ning veel plokkide vigade kontrollimine? Kas tõesti teevad seda vaikides miljonite kasutajate mobiiltelefonid, kus on installitud Telegrami klient? Või võib-olla loobuvad Durovi tiimide ideedest detsentraliseerimise osas ja teevad seda nende serverid vanaviisi?

Tegelikult ei ole kumbki vastus õige. Kuid selle artikli väljaanded saavad kiiresti otsa, seetõttu räägime erinevate sõlmede rollidest (olete võib-olla mõnda neist juba maininud) ning nende töömehhanismidest järgmises osas.

Allikas: habr.com