Ĉi tiu teksto estas daŭrigo de serio de artikoloj, en kiuj mi ekzamenas la strukturon de la (supozeble) distribuita reto Telegram Open Network (TON), kiu estas preta por eldono ĉi-jare. EN Mi priskribis ĝian plej bazan nivelon - la manieron kiel nodoj interagas inter si.
Por la okazo, mi memorigu vin, ke mi havas nenion komunan kun la evoluo de ĉi tiu reto kaj la tuta materialo estis kolektita el malfermita (kvankam nekontrolita) fonto - (estas ankaŭ akompano , mallonge skizante la ĉefajn punktojn), kiuj aperis fine de la pasinta jaro. La kvanto de informoj en ĉi tiu dokumento, laŭ mi, indikas ĝian aŭtentikecon, kvankam ne ekzistas oficiala konfirmo pri tio.
Hodiaŭ ni rigardos la ĉefan komponanton de TON - la blokĉeno.
Bazaj konceptoj
konto (konto). Aro de datumoj identigitaj per 256-bita nombro konto_id (plej ofte ĉi tio estas la publika ŝlosilo de la posedanto de la konto). En la baza kazo (vidu malsupre nula laborĉeno), ĉi tiuj datumoj rilatas al la bilanco de la uzanto. "Okupi" specifa konto_id ĉiu povas, sed ĝia valoro povas esti ŝanĝita nur laŭ certaj reguloj.
Inteligenta kontrakto (inteligenta kontrakto). Esence, ĝi estas speciala kazo de konto, kompletigita per inteligenta kontraktokodo kaj stokado de ĝiaj variabloj. Se en la kazo de "monujo" vi povas deponi kaj eltiri monon el ĝi laŭ relative simplaj kaj antaŭdestinitaj reguloj, tiam en la kazo de inteligenta kontrakto ĉi tiuj reguloj estas skribitaj en la formo de ĝia kodo (en certa Turing-kompleta). programlingvo).
Blockchain Ŝtato (stato de blokĉeno). La aro de statoj de ĉiuj kontoj/inteligentaj kontraktoj (en abstrakta signifo, hashtabelo, kie la ŝlosiloj estas kontaj identigiloj kaj la valoroj estas la datumoj stokitaj en la kontoj).
mesaĝo (mesaĝo). Supre mi uzis la esprimon "kredito kaj debetmono" - ĉi tio estas aparta ekzemplo de mesaĝo ("transdono N gramoj de konto konto_1 al konto konto_2"). Evidente, nur la nodo, kiu posedas la privatan ŝlosilon de la konto, povas sendi tian mesaĝon konto_1 - kaj kapabla konfirmi tion per subskribo. La rezulto de liverado de tiaj mesaĝoj al regula konto estas pliigo de ĝia ekvilibro, kaj la rezulto de la inteligenta kontrakto estas la plenumo de ĝia kodo (kiu prilaboros la ricevon de la mesaĝo). Kompreneble, ankaŭ aliaj mesaĝoj eblas (transdoni ne monajn sumojn, sed arbitrajn datumojn inter inteligentaj kontraktoj).
Transakcio (transakcio). La fakto, ke mesaĝo estas transdonita, nomiĝas transakcio. Transakcioj ŝanĝas la staton de la blokĉeno. Estas transakcioj (mesaĝaj liveraj registroj) kiuj konsistigas la blokojn en la blokĉeno. Ĉi-rilate, vi povas pensi pri la stato de la blokĉeno kiel pliiga datumbazo - ĉiuj blokoj estas "malsamoj", kiuj devas esti aplikataj sinsekve por akiri la aktualan staton de la datumbazo. La specifaĵoj pri pakado de ĉi tiuj "malsamoj" (kaj restarigo de la plena stato de ili) estos diskutitaj en la sekva artikolo.
Blokoĉeno en TON: kio ĝi estas kaj kial?
Kiel menciite en la antaŭa artikolo, blokoĉeno estas datumstrukturo, kies elementoj (blokoj) estas ordigitaj en "ĉeno", kaj ĉiu posta bloko de la ĉeno enhavas haŝon de la antaŭa.. La komentoj faris la demandon: kial ni entute bezonas tian datumstrukturon kiam ni jam havas DHT - distribuitan hashtabelon? Evidente, iuj datumoj povas esti konservitaj en DHT, sed ĉi tio taŭgas nur por ne tro "sentemaj" informoj. Kriptaj moneroj ne povas esti stokitaj en DHT - ĉefe pro la manko de ĉekoj integreco. Fakte, la tuta komplekseco de la blokĉena strukturo kreskas por malhelpi interferon kun la datumoj stokitaj en ĝi.
Tamen, la blokĉeno en TON aspektas eĉ pli kompleksa ol en la plej multaj aliaj distribuitaj sistemoj - kaj pro du kialoj. La unua estas la deziro minimumigi la bezonon de forkoj. En tradiciaj kriptaj moneroj, ĉiuj parametroj estas fiksitaj en la komenca etapo kaj ĉiu provo ŝanĝi ilin efektive kondukas al la apero de "alternativa kripta monero universo". La dua kialo estas subteno por disbatado (sharding, sharding) blokĉeno. Blockchain estas strukturo, kiu ne povas fariĝi pli malgranda kun la tempo; kaj kutime ĉiu nodo respondeca por la funkciado de la reto estas devigita konservi ĝin tute. En tradiciaj (centralizitaj) sistemoj, sharding estas uzata por solvi tiajn problemojn: kelkaj el la rekordoj en la datumbazo situas sur unu servilo, kelkaj sur alia, ktp. En la kazo de kriptaj moneroj, tia funkcieco ankoraŭ estas sufiĉe malofta - precipe pro la fakto, ke estas malfacile aldoni sharding al sistemo, kie ĝi ne estis origine planita.
Kiel TON planas solvi ambaŭ ĉi-suprajn problemojn?
Enhavo de blokĉeno. Laborĉenoj.
Antaŭ ĉio, ni parolu pri tio, kio estas planita stoki en la blokĉeno. La statoj de kontoj ("monujoj" en la baza kazo) kaj inteligentaj kontraktoj estos konservitaj tie (por simpleco, ni supozos, ke tio estas la sama kiel kontoj). Esence, ĉi tio estos regula hashtabelo - la ŝlosiloj en ĝi estos identigiloj konto_id, kaj valoroj estas datumstrukturoj enhavantaj tiajn aferojn kiel:
- ekvilibro;
- inteligenta kontraktokodo (nur por inteligentaj kontraktoj);
- stokado de datumoj de inteligentaj kontraktoj (nur por inteligentaj kontraktoj);
- statistiko;
- (nedeviga) publika ŝlosilo por translokigoj de la konto, defaŭlte account_id;
- vosto de elirantaj mesaĝoj (ĉi tie ili estas enmetitaj por plusendo al la ricevanto);
- listo de la plej novaj mesaĝoj transdonitaj al ĉi tiu konto.
Kiel menciite supre, la blokoj mem konsistas el transakcioj - mesaĝoj transdonitaj al diversaj account_id-kontoj. Tamen, krom account_id, mesaĝoj ankaŭ enhavas 32-bitan kampon workchain_id — tiel nomata identigilo laborĉeno (laborĉeno, funkcianta blokĉeno). Ĉi tio ebligas al vi havi plurajn blokĉenojn sendependajn unu de la alia kun malsamaj agordoj. En ĉi tiu kazo, workchain_id = 0 estas konsiderata speciala kazo, nula laborĉeno — estas la ekvilibroj en ĝi, kiuj respondas al la TON (Gramoj) kripta monero. Plej verŝajne, komence, aliaj laborĉenoj tute ne ekzistos.
Fragĉenoj. Senfina Sharding Paradigmo.
Sed la kresko de la nombro da blokĉenoj ne ĉesas tie. Ni traktu sharding. Ni imagu, ke al ĉiu konto (account_id) estas asignita sia propra blokĉeno - ĝi enhavas ĉiujn mesaĝojn kiuj venas al ĝi - kaj la statoj de ĉiuj tiaj blokĉenoj estas stokitaj sur apartaj nodoj.
Kompreneble, ĉi tio estas tre malŝparema: plej verŝajne, en ĉiu el ĉi tiuj shardĉenoj (shardĉeno, shard blokĉeno) transakcioj alvenos tre malofte, kaj necesos multaj potencaj nodoj (rigardante antaŭen, mi rimarkas, ke ni parolas ne nur pri klientoj en poŝtelefonoj - sed pri seriozaj serviloj).
Tial, shardchain kombinas kontojn per la binaraj prefiksoj de siaj identigiloj: se shardchain havas prefikson de 0110, tiam ĝi inkluzivos transakciojn de ĉiuj account_ids kiuj komenciĝas per ĉi tiuj nombroj. Ĉi tio fragmento_prefikso povas havi longon de 0 ĝis 60 bitoj - kaj la ĉefa afero estas, ke ĝi povas ŝanĝiĝi dinamike.
Tuj kiam unu el la shardĉenoj komencas ricevi tro da transakcioj, la nodoj laborantaj sur ĝi, laŭ antaŭdestinitaj reguloj, "dividas" ĝin en du infanojn - iliaj prefiksoj estos unu iom pli longaj (kaj por unu el ili ĉi tiu bito estos egala al 0, kaj por la alia - 1). Ekzemple, fragmento_prefikso = 0110b dividiĝos en 01100b kaj 01101b. Siavice, se du "najbaraj" ŝardĉenoj komenciĝos sufiĉe trankvilaj (dum iom da tempo), ili denove kunfandiĝos.
Tiel, sharding estas farita "de malsupre supren" - ni supozas, ke ĉiu konto havas sian propran peceton, sed provizore ili estas "kungluitaj" per prefiksoj. Jen kion ĝi signifas Senfina Sharding Paradigmo (infinita sharding paradigmo).
Aparte, mi ŝatus emfazi, ke laborĉenoj ekzistas nur virtuale - fakte, workchain_id ĝi estas parto de la identigilo de specifa breĉeno. En formalaj esprimoj, ĉiu breĉeto estas difinita per paro de nombroj (workchain_id, fragmento_prefikso).
Korekto de eraro. Vertikalaj blokĉenoj.
Tradicie, ajna transakcio sur blokĉeno estas konsiderata kiel "ŝtonigita". Tamen, en la kazo de TON, eblas "skribi historion" - se iu (la t.n. fiŝkaptista nodo) pruvos, ke unu el la blokoj estis neĝuste subskribita. En ĉi tiu kazo, speciala korekta bloko estas aldonita al la responda shardĉeno, enhavanta la haŝon de la bloko mem korektita (kaj ne la lasta bloko en la shardĉeno). Pensante pri la shardĉeno kiel ĉeno de blokoj aranĝitaj horizontale, ni povas diri, ke la korekta bloko estas alfiksita al la erara bloko ne dekstre, sed de supre - do oni konsideras, ke ĝi fariĝas parto de malgranda "vertikala blokoĉeno" . Tiel, ni povas diri ke shardchains estas dudimensiaj blokĉenoj.
Se, post erara bloko, la ŝanĝoj faritaj de ĝi estis referencitaj de postaj blokoj (t.e., novaj transakcioj estis faritaj surbaze de nevalidaj), korektaj estas ankaŭ aldonitaj al ĉi tiuj blokoj "supre". Se la blokoj ne influis la "tuŝitajn" informojn, ĉi tiuj "korektaj ondoj" ne validas por ili. Ekzemple, en la supra ilustraĵo, la transakcio de la unua bloko, pliigante la bilancon de konto C, estis rekonita kiel malĝusta - tial la transakcio malpliiganta la saldon de ĉi tiu konto en la tria bloko ankaŭ devus esti nuligita, kaj korekta bloko. devus esti farita sur la supro de la bloko mem.
Oni devas rimarki, ke kvankam la korektaj blokoj estas prezentitaj kiel lokitaj "super" la originalaj, fakte ili estos aldonitaj al la fino de la responda blokĉeno (kie ili devus esti kronologie). La dudimensia loko nur montras al kiu punkto en la blokĉeno ili estos "ligitaj" (per la hash de la originala bloko situanta en ili).
Vi povas aparte filozofii pri kiom bona estas la decido "ŝanĝi la pasintecon". Ŝajnus, ke se ni akceptas la eblecon de malĝusta bloko aperanta en la shardĉeno, tiam ni ne povas eviti la eblecon de erara korekta bloko aperanta. Ĉi tie, kiom mi povas diri, la diferenco estas en la nombro da nodoj, kiuj devas atingi konsenton pri novaj blokoj - estos relative malgranda nombro da homoj laborantaj sur ĉiu shardĉeno."laborgrupo» nodoj (kiu sufiĉe ofte ŝanĝas sian komponadon), kaj la enkonduko de korektaj blokoj postulos la konsenton de ĉiuj; validigiloj nodoj. Mi parolos pli pri validigiloj, laborgrupoj kaj aliaj nodaj roloj en la sekva artikolo.
Unu blokĉeno por regi ilin ĉiujn
Estas multaj informoj listigitaj supre pri la malsamaj specoj de blokĉenoj, kiuj mem ankaŭ devus esti stokitaj ie. Precipe, ni parolas pri la sekvaj informoj:
- pri la nombro kaj agordoj de laborĉenoj;
- pri la nombro da shardĉenoj kaj iliaj prefiksoj;
- pri kiuj nodoj aktuale respondecas pri kiuj shardĉenoj;
- haŝiŝoj de la lastaj blokoj aldonitaj al ĉiuj shardĉenoj.
Kiel vi eble divenis, ĉiuj ĉi aferoj estas registritaj en alia blokĉena stokado - majstra ĉeno (majstra ĉeno, majstra blokĉeno). Pro la ĉeesto de hashoj de la blokoj de ĉiuj shardĉenoj en ĝiaj blokoj, ĝi faras la sistemon tre konektita. Ĉi tio signifas, interalie, ke la generacio de nova bloko en la majstra ĉeno okazos tuj post la generacio de blokoj en breĉenoj - estas atendite, ke blokoj en breĉenoj aperos preskaŭ samtempe proksimume ĉiujn 5 sekundojn, kaj la sekva bloko en la. masterchain - sekundo post tio.
Sed kiu respondecos pri la efektivigo de ĉi tiu tuta titana laboro - por sendi mesaĝojn, plenumi inteligentajn kontraktojn, formi blokojn en shardchains kaj la majstra ĉeno, kaj eĉ kontroli blokojn por eraroj? Ĉu ĉio ĉi estos sekrete farita de la telefonoj de milionoj da uzantoj kun la Telegram-kliento instalita sur ili? Aŭ, eble, la teamo de Durov forlasos la ideojn de malcentralizo kaj iliaj serviloj faros ĝin malmoderna?
Fakte, nek unu nek la alia respondo estas ĝusta. Sed la randoj de ĉi tiu artikolo rapide elĉerpiĝas, do ni parolos pri la diversaj roloj de nodoj (vi eble jam rimarkis menciojn pri iuj el ili), kaj ankaŭ pri la mekaniko de ilia laboro, en la sekva parto.
fonto: www.habr.com