Acest text reprezintă continuarea unei serii de articole în care analiza structura (presupus) a rețelei distribuite Telegram Open Network (TON) care ar urma să fie lansată în acest an. În am descris nivelul său de bază - modul în care nodurile interacționează între ele.
Îmi amintesc, pentru orice eventualitate, că nu am nicio legătură cu dezvoltarea acestei rețele, iar tot materialul este extras dintr-o sursă deschisă (deși neconfirmată) - (la care se atașează , care rezumă pe scurt punctele principale), apărută la sfârșitul anului trecut. Cantitatea de informații din acest document, în opinia mea, dovedește autenticitatea acestuia, deși nu există nicio confirmare oficială.
Astăzi ne vom uita la componenta principală a TON - blockchain-ul.
Noțiuni de bază
Cont (account). Un set de date identificat printr-un număr de 256 de biți account_id (cel mai frecvent, acesta este cheia publică a proprietarului contului). În cazul de bază (vezi mai jos blockchain zero), aceste date reprezintă soldul utilizatorului. Oricine poate „împrumuta” un anumit account_id dar modificarea valorii sale se poate face doar conform unor reguli specifice.
Contract inteligent (smart-contract). Practic, este un caz particular al unui cont, completat cu codul contractului inteligent și stocarea variabilelor sale. În cazul „portofelului” se pot adăuga și retrage bani din acesta conform unor reguli relativ simple și predefinite, iar în cazul contractului inteligent, aceste reguli sunt scrise sub formă de cod (într-un anumit limbaj de programare Turing-complet).
Starea blockchain-ului (state of blockchain). Totalitatea stărilor tuturor conturilor/contractelor inteligente (în sens abstract - o tabelă hash, unde cheile sunt identificatorii conturilor, iar valorile sunt datele stocate în conturi).
Mesaj (message). Mai sus am folosit expresia „a adăuga și a retrage bani” - acesta este un exemplu particular de mesaj („a transfera N grame de la contul account_1 la contul account_2”). Evident, un astfel de mesaj poate fi trimis doar de un nod care deține cheia privată a contului. account_1 — și capabil să confirme acest lucru printr-o semnătură. Rezultatul livrării unor astfel de mesaje către un cont obișnuit este creșterea soldului acestuia, iar contractul inteligent — executarea codului său (care va procesa primirea mesajului). Desigur, sunt posibile și alte mesaje (care nu transferă sume de bani, ci date arbitrare între contractele inteligente).
Transacție (transacție). Faptul livrării mesajului se numește transacție. Transacțiile schimbă starea blockchain-ului. Tocmai din transacții (înregistrări de livrare a mesajelor) sunt formate blocurile în blockchain. În acest sens, starea blockchain-ului poate fi văzută ca o bază de date incrementală — toate blocurile sunt „dife” care trebuie aplicate secvențial pentru a obține starea actuală a BDD. Despre specificul ambalării acestor „dife” (și restaurarea stării complete pe baza lor) va fi vorba în articolul următor.
Blockchain în TON: ce este și de ce este necesar?
Așa cum a fost menționat în articolul anterior, blockchain-ul este o structură de date, elementele (blocurile) căreia sunt ordonate într-un „lanț”, iar fiecare bloc următor al lanțului conține hash-ul precedentului. În comentarii s-a ridicat întrebarea: de ce este nevoie de o astfel de structură de date, când deja avem DHT — o tabelă hash distribuită? Este evident că anumite date pot fi stocate și în DHT, dar aceasta este potrivită doar pentru informații care nu sunt foarte „sensibile”. Soldurile criptomonedelor nu pot fi stocate în DHT — în primul rând din cauza lipsei verificărilor de integritate. De fapt, întreaga complexitate a structurii blockchain-ului crește pentru a preveni intervențiile în datele păstrate în el.
Cu toate acestea, blockchain-ul în TON arată chiar mai complex decât în majoritatea altor sisteme distribuite — și există două motive pentru aceasta. Primul — dorința de a minimiza nevoia de forkuri. În criptomonedele tradiționale, toate parametrii sunt definiți inițial și orice încercare de modificare a acestora duce în esență la apariția unei „univers alternativ” al criptomonedei. Al doilea motiv — suportul pentru fragmentare (sharding, shardare) blockchain-ului. Blockchain-ul este o structură care nu poate deveni mai mică odată cu trecerea timpului; în general, fiecare nod responsabil cu funcționarea rețelei este obligat să o stocheze în întregime. În sistemele tradiționale (centralizate), pentru a rezolva probleme asemănătoare, se aplică sharding-ul: o parte din înregistrările din baza de date se află pe un server, o parte pe altul, și așa mai departe. În cazul criptomonedelor, o astfel de funcționalitate este încă destul de rară — în special, din cauza dificultății de a adăuga sharding într-un sistem unde nu a fost planificat inițial.
Cum intenționează TON să rezolve ambele probleme descrise anterior?
Conținutul blockchain-ului. Workchains.
În primul rând, să discutăm despre ce se preconizează a fi stocat în blockchain. Vor fi stocate acolo stările conturilor („portofele” în cazul de bază) și ale contractelor inteligente (pentru simplificare, să presupunem că acestea sunt aceleași cu conturile). Practic, aceasta va fi o tabelă hash obișnuită — în care cheile vor fi identificatorii account_id, iar valorile vor fi structuri de date care conțin lucruri precum:
- saldo;
- codul contractului inteligent (doar pentru contractele inteligente);
- depozitul de date al contractului inteligent (doar pentru contractele inteligente);
- statistici;
- (opțional) cheia publică pentru transferuri din cont, default account_id;
- coada mesajelor ieșite (acestea sunt introduse aici pentru a fi trimise destinatarului);
- lista ultimelor mesaje livrate acestui cont.
După cum s-a menționat mai sus, blocurile constau în tranzacții — mesaje livrate diferitelor conturi account_id. Totuși, pe lângă account_id, mesajele conțin de asemenea un câmp de 32 de biți workchain_id — identificatorul așa-numitului workchain (workchain, blockchain-ul activ). Acest lucru permite existența mai multor blockchain-uri independente între ele cu configurații diferite. În acest context, workchain_id = 0 este considerat un caz special, workchain-ul zero — soldurile aflate în el vor corespunde criptomonedei TON (Grams). Cel mai probabil, în primele etape nu vor exista deloc alte workchains.
Sharding-urile. Infinite Sharding Paradigm.
Însă creșterea numărului de blockchain-uri nu se oprește aici. Să ne ocupăm de sharding. Să presupunem că fiecărui cont (account_id) i se alocă propriul blockchain — în el se află toate mesajele care îi sunt destinate — iar stările tuturor acestor blockchain-uri sunt stocate pe noduri separate.
Desigur, este destul de costisitor: cel mai probabil, în fiecare dintre aceste shardchain-uri (shardchain, shard blockchain) tranzacțiile vor veni foarte rar, iar noduri puternice vor fi necesare în număr mare (pentru a anticipa, menționez că nu este vorba doar despre clienți pe telefoane mobile — ci despre servere serioase).
De aceea, shardchain-urile combină conturile prin prefixele binare ale identificatorilor lor: dacă un shardchain are prefixul 0110, atunci tranzacțiile tuturor account_id-urilor care încep cu acești cifre vor fi incluse. Acest shard_prefix poate avea o lungime de la 0 la 60 de biți — iar cel mai important este că poate fi modificat dinamic.
Atunci când într-unul dintre shardchain-uri încep să vină excesiv de multe tranzacții, nodurile care lucrează la el „împart” conform unor reguli predefinite în două descendenți — prefixele lor vor fi cu un bit mai lung (și pentru unul dintre ei, acest bit va fi 0, iar pentru celălalt — 1). De exemplu, shard_prefix = 0110b se va împărți în 01100b și 01101b. La rândul său, dacă două shardchain-uri „vecine” încep să se simtă suficient de confortabil (pe o perioadă de timp), ele se vor fuziona din nou.
Astfel, sharding-ul se face „de jos în sus” — presupunem că fiecare cont are propriul său shard, dar acestea sunt, deocamdată, „lipite” împreună prin prefixe. Aceasta este ceea ce implică Infinite Sharding Paradigm (paradigma sharding-ului infinit).
Deosebit de important este că workchain-urile există doar virtual — de fapt, workchain_id aceasta este o parte a identificatorului unui anumit shardchain. Vorbind într-un limbaj formal, fiecare shardchain este definit printr-o pereche de numere (workchain_id, shard_prefix).
Corectarea erorilor. Blockchain-uri verticale.
Se consideră în mod tradițional că orice tranzacție în blockchain este „sculptată în piatră”. Cu toate acestea, în cazul TON este prevăzută posibilitatea de a „rescrie istoria” — în cazul în care cineva (așa-numitul nod-«pește») va dovedi că unul dintre blocuri a fost semnat incorect. În acest caz, un bloc corectiv special este adăugat la shardchain-ul corespunzător, conținând hash-ul blocului corectat (și nu al ultimului bloc din shardchain). Reprezentând shardchain-ul ca un lanț de blocuri așezate orizontal, se poate spune că blocul corectiv este atașat blocului eronat nu în dreapta, ci deasupra — prin urmare, se consideră că face parte dintr-un mic „lanț de blocuri vertical”. Astfel, se poate afirma că shardchain-urile sunt lanțuri de blocuri bidimensionale.
În cazul în care blocurile ulterioare au făcut referire la modificările introduse de blocul eronat (adică, au existat noi tranzacții pe baza unor blocuri invalide), blocurile respective primesc de asemenea corective adăugate „deasupra”. Dacă blocurile nu au afectat informațiile „păgubite”, aceste „valuri corective” nu se propagă la ele. De exemplu, în ilustrația de mai sus, tranzacția din primul bloc care crește soldul contului C a fost recunoscută ca fiind eronată — prin urmare, tranzacția care reduce soldul acestui cont în al treilea bloc trebuie să fie anulată, iar un bloc corectiv deasupra blocului în sine trebuie să fie angajat.
Trebuie remarcat — deși blocurile corective sunt ilustrate ca fiind „deasupra” celor originale, de fapt ele vor fi adăugate la sfârșitul lanțului de blocuri corespunzător (unde ar trebui să fie din punct de vedere cronologic). Dispunerea bidimensională arată doar la ce punct din lanțul de blocuri va fi „atașat” (prin intermediul hash-ului blocului original care se află în ele).
Se poate filozofa separat asupra cât de bună este decizia de a „schimba trecutul”. S-ar părea că, dacă admitem posibilitatea apariției unui bloc incorect în shardchain, nu putem exclude nici posibilitatea apariției unui bloc corectiv eronat. Aici, din câte îmi pot da seama, diferența constă în numărul de noduri care trebuie să ajungă la consens cu privire la noile blocuri — fiecare shardchain va avea o „echipă de lucru„ de noduri (destul de des își va schimba componența), iar introducerea blocurilor corective va necesita acordul tuturor nodurilor-validatoare. Mai multe detalii despre validatori, echipe de lucru și alte roluri ale nodurilor voi prezenta în următorul articol.
O singur blockchain pentru a le guverna pe toate
Informațiile enumerate mai sus despre diverse tipuri de blockchain-uri trebuie de asemenea stocate undeva. În special, ne referim la următoarele date:
- despre numărul și configurațiile workchain-urilor;
- despre numărul shardchain-urilor și prefixelor acestora;
- despre care noduri sunt în prezent responsabile pentru care shardchain-uri;
- hash-urile celor mai recent adăugate blocuri în toate shardchain-urile.
Așa cum ați putut ghici, toate aceste lucruri sunt înregistrate într-un alt depozit blockchain - masterchain (masterchain, master blockchain). Datorită prezenței hash-urilor blocurilor tuturor shardchain-urilor în blocurile sale, acesta face sistemul foarte interconectat. Aceasta înseamnă că generarea unui nou bloc în masterchain va avea loc imediat după generarea blocurilor în shardchain-uri - se așteaptă ca blocurile în shardchain-uri să apară aproape simultan la fiecare aproximativ 5 secunde, iar un nou bloc în masterchain să apară la o secundă după aceasta.
Dar cine va fi responsabil pentru implementarea întregii acestei lucrări titanice - pentru trimiterea mesajelor, executarea contractelor inteligente, formarea blocurilor în shardchain-uri și masterchain, și de asemenea verificarea blocurilor pentru erori? Oare toate acestea vor fi realizate în tăcere de telefoanele a milioane de utilizatori cu clientul Telegram instalat pe ele? Sau, poate, echipa lui Durov va renunța la ideea de descentralizare și va încerca să facă acest lucru pe serverele lor în stilul vechi?
De fapt, niciuna dintre aceste răspunsuri nu este corectă. Dar paginile acestui articol se termină rapid, așa că discutarea diferitelor roluri ale nodurilor (ați putut observa deja unele dintre ele) și mecanicile lor de funcționare va fi făcută în partea următoare.
Sursa: habr.com
