TON: Telegram Open Network. Osa 2: Blokahelad, shardimine

See tekst on artikkel, kus ma käsitlen struktuuri (tõenäoliselt) sellel aastal välja tuleva jaotatud võrgustiku Telegram Open Network (TON). eelmises osas kirjeldasin selle kõige baastaset — sõlmede omavahelist suhtlemist.

Igaks juhuks meenutan, et ma ei ole seotud selle võrgu arendamisega ja kogu materjal on saadud avatud (kuigi kontrollimata) allikast — dokumentide (millega on kaasas brošüür, mis lühidalt kokku võtab põhiaspektid), mis ilmus eelmisel aastal. Materjali maht selles dokumendis, minu arvates, viitab selle ehtsusele, kuigi ametlikke kinnitusi ei ole.

Täna vaatame TON-i põhikomponenti — plokiahelat.

Põhidokumendid

Konto (account). Teatud andmekogum, mida identifitseerib 256-bitine number account_id (enamasti on see konto omaniku avalik võti). Baastasemel (vt allpool null plokiahel), nende andmete all mõistetakse kasutaja taset. "Laenata" saab igaüks, kuid selle väärtust saab muuta ainult kindlate reeglite järgi. account_id Nutikas leping

smart-contract (). Sisuliselt on see konto erijuhtum, millele on lisatud nutika lepingu kood ja selle muutujate hoidla. Kui "rahakoti" puhul saab raha kontole kanda ja sealt välja võtta suhteliselt lihtsate ja eelnevalt määratletud reeglite alusel, siis nutika lepingu puhul on need reeglid kirjas tema koodis (mõnes Turingu täisvõimes programmeerimiskeeles).Plokiahela olek

state of blockchain (). Kõigi kontode/nutika lepingute olekute kogum (abstraktses mõttes — häshtabel, kus võtmed on konto identifikaatorid ja väärtused on kontodes hoitavad andmed).). Ülalpool kasutasin väljendit "kanda raha" — see on eriline näide sõnumist ("kanda

Teade (messageN grammi kontolt account_1 kontole account_2 "). Ilmselgelt saadab sellise sõnumi vaid sõlm, kellel on konto privaatvõti.»). Ilmselt võib sellise sõnumi saata ainult sõlm, millel on konto privaatvõti kontole — ja suudab seda kinnitada allkirjaga. Selliste sõnumite saatmise tulemuseks tavalisele kontole on selle tasakaalu suurenemine, samas kui nutilepingule toimub olemasoleva koodi täitmine (mis töötleb sõnumi vastuvõtmist). Loomulikult on võimalikud ka muud sõnumid (mida kantakse, edastades mitte rahasummasid, vaid suvalisi andmeid nutilepingute vahel).

Tehing (tehing). Sõnumi kohaletoimetamise fakti nimetatakse tehinguks. Tehingud muudavad plokiahela seisundit. Just tehingutest (sõnumite kohaletoimetamise registreerimise) koosnevad plokid plokiahelas. Sellest vaatepunktist võib plokiahela seisundit kujutada kui inkrmenteerivat andmebaasi — kõik plokid on „diffid”, mis tuleb järjestikulised rakendada, et saada praegune andmebaasi seisund. Täpsemalt nende „diffide” pakkimise kohta (ja täieliku seisundi taastamise kohta nende põhjal) räägime järgmises artiklis.

Plokiahel TONis: mis see on ja milleks seda vaja?

Nagu mainitud eelnevas artiklis, plokiahel on andmestruktuur, mille elemendid (plokid) on järjestatud „ahelasse” ja iga järgmine ahelaplokke sisaldab eelneva häsši. Kommentaarides esitati küsimus: miks on selline andmestruktuur üldse vajalik, kui meil on juba DHT — jaotatud häshtabel? On ilmne, et teatud andmeid saab salvestada ka DHT-s, kuid see sobib ainult mitte liiga „tundlikule” teabele. Krüptorahade saldod ei saa DHT-sse salvestada — eelkõige seetõttu, et seal puuduvad kontrollid puutumatuse. Tegelikult tuleneb plokiahela struktuuri kogu keerukus selleks, et vältida sekkumist selle salvestatud andmetesse.

Kuid plokiahel TONis näeb välja isegi keerukam kui enamik teisi jaotatud süsteeme — ja sellel on kaks põhjust. Esiteks — soov minimeerida vajadust haakimiste. Traditsioonilistes krüptovaluutades on kõik parameetrid määratud alguses ja iga nende muutmise katse viib tegelikult „alternatiivse krüptovaluuta universumi” loomiseni. Teine põhjus — toetada jaotamist (shardimist, jagamine) blokcheini. Blokcheyn on struktuur, mis ei suuda aja jooksul väheneda; ja tavaliselt peab iga sõlme, mis vastutab võrgu töökorras hoidmise eest, selle täiesti hoidma. Traditsioonilistes (tsentraliseeritud) süsteemides kasutatakse sarnaste probleemide lahendamiseks lõhestamist: osa andmetest andmebaasis on ühel serveril, teine osa teisel jne. Krüptoraha puhul on selline funktsionaalsus senini üsna haruldane — eelkõige seetõttu, et on keeruline lisada lõhestamist süsteemi, kus seda ei olnud algselt kavandatud.

Kuidas kavatseb TON lahendada mõlemad ülaltoodud probleemid?

Blokcheini sisu. Workchains.

Esiteks räägime sellest, mida on plaanis blokcheinis hoida. Seal hoitakse kontode (algses juhtumis „rahakotid“) ja nutilepingute olekuid (lihtsuse pärast arvame, et need on samad, mis kontod). Tegu on põhimõtteliselt tavalise hash-tabeliga — võtitena on seal identifikaatorid account_id, väärtustena aga andmestruktuurid, milles sisalduvad sellised asjad nagu:

• saldo;
• nutilepingu kood (ainult nutilepingute puhul);
• nutilepingu andmehoidla (ainult nutilepingute puhul);
• statistika;
• (valikuline) avalik võti kontolt ülekannete jaoks, vaikimisi account_id;
• väljuvate sõnumite järjekord (siia need kantakse saatmiseks adressaadile);
• viimasele sellele kontole edastatud sõnumite nimekiri.

Nagu varem öeldud, koosnevad plokid otseselt 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 — identifikaator nii-öelda. workchain (workchain, töötav blokchaing). See võimaldab omada mitmeid omavahel sõltumatuid blokchaine erinevate konfigureeringutega. Samal ajal on workchain_id = 0 erijuhtum, nullworkchain — just selle saldo vastab TON (Grams) krüptorahale. Tõenäoliselt ei eksisteeri algusaegadel teisi workchain'e üldse.

Shardchains. Lõpmatu lõhestamise paradigma.

Kuid blockchain'ide arvu kasv ei peatu siin. Vaatame shardimist. Kujutame ette, et igaühele (account_id) on eraldatud omaenda blockchain - seal on kõik tema saadetud sõnumid - ja kõikide selliste blockchain'ide olekud salvestatakse eraldi sõlmedes.

Muidugi on see üsna raiskav: tõenäoliselt saab igasse neist shardchain'idesse (shardchain, shard blockchain) tehingud saavad väga harva, ja palju jõulisi sõlmi on vaja (rääkinud ette, tuletan meelde, et jutt ei käi mitte lihtsalt mobiilsete klientide kohta - vaid tõsiste serverite kohta).

Seetõttu koondavad shardchain'id kontod oma identifikaatorite binaarsete prefikside järgi: kui shardchain'il on prefiks 0110, siis kuuluvad sinna kõik account_id, mis algavad nende numbritega. See shard_prefix võib olla pikkusega 0 kuni 60 bitti - ja mis peamine, see võib dünaamiliselt muutuda.

Niipea, kui ühte shardchain'i hakkab jõudma liiga palju tehinguid, siis selle kallal töötavad sõlmed vastavalt eelnevalt määratletud reeglitele "lahutavad" selle kaheks tütarüksuseks - nende prefiksid on ühe bitiga pikemad (ja ühele neist on see bit 0, teisele aga 1). Näiteks, shard_prefix = 0110b lahustub 01100b ja 01101b. Omakorda, kui kaks "naaberriiki" shardchain'i hakkavad end piisavalt mugavalt tundma (mingi perioodi jooksul), siis nad liituvad taas üksiksuse.

Nii tehakse shardimine "alt üles" - me eeldame, et igal kontol on oma shard, kuid need on - küll hetkel - "liimitud" prefikside järgi. See ongi see, mida tähendab Infinite Sharding Paradigm (lõputu shardimise paradigma).

Erakordselt tahaks rõhutada, et workchain'id eksisteerivad ainult virtuaalselt - tegelikult, workchain_id on see konkreetse shardchain'i identifikaatori osa. Formaalset keelt kasutades määratleb iga shardchain paar numbreid (workchain_id, shard_prefix).

Vigade parandamine. Vertikaalsed blockchain'id.

Traditsiooni kohaselt peetakse, et iga blockchain'is olev tehing on "kivisse raiutud". Siiski, TON'i korral on ette nähtud võimalus "ajalugu ümber kirjutada" - juhul, kui keegi (nn "kalamehe" sõlm) tõestab, et üks plokk on allkirjastatud valesti. Sellisel juhul lisatakse vastavasse shard-ahelasse spetsiaalne parandav plokk, mis sisaldab parandatava ploki (mitte shard-ahela viimase ploki) häshti. Kujutades shard-ahelat horisontaalse plokkide ahelana, võib öelda, et parandav plokk kinnitatakse vale ploki juurde mitte paremale, vaid ülevalt - seetõttu loetakse, et see muutub väikese 'vertikaalse plokiahela' osaks. Seega võib öelda, et shard-ahelad on kahemõõtmelised plokiahelad.

Juhul, kui vale ploki tehtud muudatustele viitasid sellele järgnenud plokid (st valeandmete põhjal tehti uusi tehinguid), lisatakse ka nendele plokkidele 'ülevalt' parandavad plokid. Kui plokid ei puudutanud 'mõjutatuid' andmeid, ei laiene need 'parandavad lained' neile. Näiteks, nagu ülaltoodud joonisel, tunnistati esimese ploki tehing vale, mis suurendas konto C saldo - seetõttu peab ka selle konto saldo vähendav tehing kolmandas plokis olema tühistatud ja parandav plokk peab olema kirjutatud otse selle ploki peale.

Tuleb märkida, et ehkki parandavad plokid kuvatakse 'originalide' kohal, kirjutatakse nad tegelikult vastava plokiahela lõppu (seal, kus nad kronoloogiliselt paiknema peavad). Kahemõõtmeline paigutus näitab vaid, millisele plokiahela punktile nad 'kinnitatakse' (kasutades nende algse ploki häshti).

Võib eraldi filosoofeerida selle üle, kui hea on otsus 'mineviku muutmine'. Tundub, et kui me lubame vale ploki tekkimist shard-ahelas, siis ei saa me välistada ka vale parandava ploki võimalust. Siin, kui ma õigesti aru sain, on erinevus sõlmede arvus, mis peavad uute plokkide üle konsensusele jõudma - iga shard-ahela kallal töötab suhteliselt väiketöörühmsõlmede (mis sageli muudavad oma koosseisu), samas kui parandavate plokkide lisamine nõuab kõigi kehtivate sõlmedekonsensust. Rohkem räägin kehtijatest, töörühmades ja muudest sõlmede rollidest järgmises artiklis.

Üks plokiahel, et kõike juhtida

Ülaltoodud on palju teavet erinevate plokiahelate tüüpide kohta, mida tuleb samuti kuskil salvestada. Eelkõige räägime järgmiste andmete kohta:

• töötajate arvu ja konfiguratsioonide kohta;
• šardhahelate arvu ja nende eesliidete kohta;
• millised sõlmed vastutavad praegu milliste šardhahelate eest;
• viimati lisatud plokkide hash'id kõikidesse šardhahelatesse.

Nagu te juba võisite arvata, salvestatakse kõik need asjad veel ühte plokiahelasse - meisterplokiahel (masterchain, master blockchain). Tänu sellele, et selle plokkides on hash'id kõigi šardhahelate plokkidest, muudab see süsteemi tugevalt ühendatuks. See tähendab ka, et uue ploki genereerimine meisterplokiahelas toimub otse pärast plokkide genereerimist šardhahelates - oodatakse, et plokid šardhahelates ilmuvad peaaegu samaaegselt iga viie sekundi tagant, ning järgmine plokk meisterplokiahelas ilmub sekund pärast seda.

Aga kes on vastutav kogu selle titaanliku töö teostamise eest - sõnumite edastamine, nutilepingute täitmine, plokkide genereerimine šardhahelates ja meisterplokiahelas, ning plokkide vigade kontrollimine? Kas kõik seda teevad vaikselt miljonite kasutajate telefonid, millel on installitud Telegrami klient? Või loobub Durovi meeskond detsentraliseerimise ideedest ja teeb seda nende serverid vanamoodsalt?

Tegelikult ei ole kumbki vastus õige. Kuid selle artikli lehed lõppevad kiiresti, seega on jutt erinevatest sõlmede rollidest (te olete ehk juba mõned neist mainimisi märganud) ning nende töömehhanismidest järgmises osas.

Allikas: habr.com