Acest text este o continuare a unei serii de articole în care examinez structura rețelei (probabil) distribuite Telegram Open Network (TON), care este pregătită pentru lansare în acest an. ÎN Am descris nivelul său cel mai de bază - modul în care nodurile interacționează între ele.
Pentru orice eventualitate, permiteți-mi să vă reamintesc că nu am nimic de-a face cu dezvoltarea acestei rețele și că tot materialul a fost cules dintr-o sursă deschisă (deși neverificată) - (există și un însoțitor , subliniind pe scurt punctele principale), apărute la sfârșitul anului trecut. Cantitatea de informații din acest document, în opinia mea, indică autenticitatea acestuia, deși nu există o confirmare oficială în acest sens.
Astăzi ne vom uita la componenta principală a TON - blockchain-ul.
Noțiuni de bază
Cont (cont). Un set de date identificate printr-un număr de 256 de biți Cont ID (cel mai adesea aceasta este cheia publică a proprietarului contului). În cazul de bază (vezi mai jos lanț de lucru zero), aceste date se referă la soldul utilizatorului. Specific „Ocupa”. Cont ID oricine poate, dar valoarea sa poate fi schimbată doar după anumite reguli.
Contract inteligent (Contract inteligent). În esență, este un caz special al unui cont, completat cu cod de contract inteligent și stocarea variabilelor acestuia. Dacă în cazul unui „portofel” puteți depune și retrage bani din acesta conform unor reguli relativ simple și predeterminate, atunci în cazul unui contract inteligent aceste reguli sunt scrise sub forma codului său (într-un anumit Turing-complet limbaj de programare).
Stare Blockchain (starea blockchain-ului). Setul de stări ale tuturor conturilor/contractelor inteligente (în sens abstract, un tabel hash, unde cheile sunt identificatori de cont, iar valorile sunt datele stocate în conturi).
Mesaj (mesaj). Mai sus am folosit expresia „bani de credit și debit” - acesta este un exemplu particular de mesaj („transfer N grame din cont cont_1 a da socoteală cont_2"). Evident, doar nodul care deține cheia privată a contului poate trimite un astfel de mesaj cont_1 - și capabil să confirme acest lucru cu o semnătură. Rezultatul livrării unor astfel de mesaje într-un cont obișnuit este o creștere a soldului acestuia, iar rezultatul contractului inteligent este executarea codului acestuia (care va procesa primirea mesajului). Desigur, sunt posibile și alte mesaje (transferul nu de sume monetare, ci de date arbitrare între contractele inteligente).
Tranzacţie (tranzacție). Faptul că un mesaj este livrat se numește tranzacție. Tranzacțiile schimbă starea blockchain-ului. Sunt tranzacțiile (înregistrările de livrare a mesajelor) care alcătuiesc blocurile din blockchain. În acest sens, vă puteți gândi la starea blockchain-ului ca la o bază de date incrementală - toate blocurile sunt „diferențe” care trebuie aplicate secvenţial pentru a obține starea curentă a bazei de date. Specificul ambalării acestor „diferențe” (și restabilirea stării complete a acestora) va fi discutat în articolul următor.
Blockchain în TON: ce este și de ce?
După cum sa menționat în articolul anterior, blockchain este o structură de date, ale cărei elemente (blocuri) sunt ordonate într-un „lanț”, iar fiecare bloc ulterior al lanțului conține un hash al celui anterior. Comentariile au pus întrebarea: de ce avem nevoie de o astfel de structură de date când avem deja un DHT - un tabel hash distribuit? Evident, unele date pot fi stocate în DHT, dar acest lucru este potrivit doar pentru informații nu prea „sensibile”. Soldurile criptomonede nu pot fi stocate în DHT - în primul rând din cauza lipsei de verificări integritate. De fapt, întreaga complexitate a structurii blockchain crește pentru a preveni interferențele cu datele stocate în ea.
Cu toate acestea, blockchain-ul din TON pare chiar mai complex decât în majoritatea celorlalte sisteme distribuite - și din două motive. Prima este dorința de a minimiza nevoia de furci. În criptomonedele tradiționale, toți parametrii sunt stabiliți în stadiul inițial și orice încercare de a le schimba duce de fapt la apariția unui „univers alternativ al criptomonedei”. Al doilea motiv este suportul pentru zdrobire (fragmentare, fragmentare) blockchain. Blockchain este o structură care nu poate deveni mai mică în timp; și de obicei fiecare nod responsabil de funcționarea rețelei este forțat să o stocheze complet. În sistemele tradiționale (centralizate), sharding-ul este folosit pentru a rezolva astfel de probleme: unele dintre înregistrările din baza de date sunt situate pe un server, altele pe altul etc. În cazul criptomonedelor, o astfel de funcționalitate este încă destul de rară - în special, datorită faptului că este dificil să adăugați sharding la un sistem în care nu a fost planificat inițial.
Cum intenționează TON să rezolve ambele probleme de mai sus?
Conținut blockchain. Lanțuri de lucru.
În primul rând, să vorbim despre ceea ce este planificat să fie stocat în blockchain. Acolo vor fi stocate stările conturilor („portofele” în cazul de bază) și contractele inteligente (pentru simplitate, vom presupune că este același cu conturile). În esență, acesta va fi un tabel hash obișnuit - cheile din acesta vor fi identificatori Cont ID, iar valorile sunt structuri de date care conțin lucruri precum:
- echilibru;
- cod de contract inteligent (numai pentru contractele inteligente);
- stocarea datelor din contractele inteligente (numai pentru contractele inteligente);
- statistici;
- (facultativ) cheie publică pentru transferurile din cont, implicit account_id;
- coada de mesaje trimise (aici sunt introduse pentru redirecționare către destinatar);
- o listă cu cele mai recente mesaje livrate către acest cont.
După cum am menționat mai sus, blocurile în sine constau în tranzacții - mesaje livrate către diferite conturi account_id. Cu toate acestea, pe lângă account_id, mesajele conțin și un câmp pe 32 de biți workchain_id — așa-numitul identificator lanțul de lucru (lanțul de lucru, blockchain de lucru). Acest lucru vă permite să aveți mai multe blockchain-uri independente unul de celălalt, cu configurații diferite. În acest caz, workchain_id = 0 este considerat un caz special, lanț de lucru zero — soldurile din acesta sunt cele care vor corespunde criptomonedei TON (Grame). Cel mai probabil, la început, alte lanțuri de lucru nu vor exista deloc.
Lanțuri de cioburi. Paradigma de fragmentare infinită.
Dar creșterea numărului de blockchain nu se oprește aici. Să ne ocupăm de sharding. Să ne imaginăm că fiecărui cont (account_id) i se alocă propriul blockchain - conține toate mesajele care vin la el - și stările tuturor acestor blockchain-uri sunt stocate pe noduri separate.
Desigur, acest lucru este foarte risipitor: cel mai probabil, în fiecare dintre acestea lanţuri de cioburi (shardchain, shard blockchain) tranzacțiile vor ajunge foarte rar și va fi nevoie de o mulțime de noduri puternice (privind în viitor, observ că nu vorbim doar de clienți pe telefoane mobile - ci de servere serioase).
Prin urmare, shardchain-urile combină conturile după prefixele binare ale identificatorilor lor: dacă un shardchain are un prefix de 0110, atunci va include tranzacțiile tuturor account_id-urilor care încep cu aceste numere. Acest shard_prefix poate avea o lungime de la 0 la 60 de biți - iar principalul lucru este că se poate schimba dinamic.
De îndată ce unul dintre shardchain-uri începe să primească prea multe tranzacții, nodurile care lucrează la el, conform regulilor predeterminate, îl „împart” în doi copii - prefixele lor vor fi cu un pic mai lungi (și pentru unul dintre ei acest bit va fi egal cu 0, iar pentru celălalt - 1). De exemplu, shard_prefix = 0110b se va împărți în 01100b și 01101b. La rândul lor, dacă două lanțuri de cioburi „vecinate” încep să se simtă suficient de în largul lor (de ceva timp), se vor fuziona din nou.
Astfel, sharding-ul se face „de jos în sus” - presupunem că fiecare cont are propriul shard, dar deocamdată sunt „lipiți împreună” prin prefixe. Aceasta este ceea ce înseamnă Paradigma de fragmentare infinită (paradigma de fragmentare infinită).
Separat, aș dori să subliniez că lanțurile de lucru există doar virtual - de fapt, workchain_id face parte din identificatorul unui anumit shardchain. În termeni formali, fiecare shardchain este definit de o pereche de numere (workchain_id, shard_prefix).
Corectarea erorii. Blockchain-uri verticale.
În mod tradițional, orice tranzacție pe un blockchain este considerată a fi „pusă în piatră”. Cu toate acestea, în cazul lui TON, este posibil să „rescrieți istoria” - în cazul în care cineva (așa-numitul. nod de pescar) va dovedi că unul dintre blocuri a fost semnat incorect. În acest caz, se adaugă un bloc de corecție special la shardchain-ul corespunzător, care conține hash-ul blocului însuși care este corectat (și nu ultimul bloc din shardchain). Gândindu-ne la shardchain ca la un lanț de blocuri așezate orizontal, putem spune că blocul corector este atașat blocului eronat nu în dreapta, ci de sus - deci se consideră că devine parte dintr-un mic „blockchain vertical” . Astfel, putem spune că shardchains sunt blockchain-uri bidimensionale.
Dacă, după un bloc eronat, modificările făcute de acesta au fost referite prin blocuri ulterioare (adică s-au făcut tranzacții noi pe baza unora nevalide), la aceste blocuri se adaugă și cele corective „de sus”. Dacă blocurile nu au afectat informațiile „afectate”, aceste „unde corective” nu se aplică acestora. De exemplu, în ilustrația de mai sus, tranzacția din primul bloc, care crește soldul contului C, a fost recunoscută ca incorectă - prin urmare, tranzacția care reduce soldul acestui cont în al treilea bloc ar trebui, de asemenea, anulată și un bloc corectiv. ar trebui să fie comise deasupra blocului în sine.
Trebuie remarcat faptul că, deși blocurile corective sunt descrise ca fiind situate „deasupra” celor originale, de fapt ele vor fi adăugate la sfârșitul blockchain-ului corespunzător (unde ar trebui să fie cronologic). Locația bidimensională arată doar în ce punct din blockchain vor fi „legați” (prin hash-ul blocului original aflat în ele).
Puteți filosofa separat despre 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, atunci nu putem evita posibilitatea apariției unui bloc corectiv eronat. Aici, din câte îmi pot da seama, diferența este în numărul de noduri care trebuie să ajungă la un consens asupra noilor blocuri - va fi un număr relativ mic de oameni care lucrează la fiecare shardchain".grup de lucru» noduri (care își schimbă compoziția destul de des), iar introducerea de blocuri corective va necesita acordul tuturor noduri validatoare. Voi vorbi mai multe despre validatori, grupuri de lucru și alte roluri de noduri în articolul următor.
Un singur blockchain pentru a le guverna pe toate
Există o mulțime de informații enumerate mai sus despre diferitele tipuri de blockchain, care ar trebui, de asemenea, stocate undeva. În special, vorbim despre următoarele informații:
- despre numărul și configurațiile lanțurilor de lucru;
- despre numărul de shardchain și prefixele acestora;
- despre ce noduri sunt responsabile în prezent pentru ce shardchains;
- hash-uri ale ultimelor blocuri adăugate tuturor shardchain-urilor.
După cum probabil ați ghicit, toate aceste lucruri sunt înregistrate într-un alt depozit blockchain - masterchain (masterchain, master blockchain). Datorită prezenței hashurilor din blocurile tuturor shardchain-urilor din blocurile sale, face ca sistemul să fie foarte conectat. Aceasta înseamnă, printre altele, că generarea unui nou bloc în masterchain va avea loc imediat după generarea blocurilor în shardchains - este de așteptat ca blocurile în shardchain să apară aproape simultan aproximativ la fiecare 5 secunde, iar următorul bloc în masterchain - o secundă după aceea.
Dar cine va fi responsabil pentru implementarea acestei lucrări titanică - pentru trimiterea de mesaje, executarea contractelor inteligente, formarea blocurilor în shardchain și masterchain și chiar verificarea blocurilor pentru erori? Toate acestea vor fi făcute în secret de telefoanele a milioane de utilizatori cu clientul Telegram instalat pe ele? Sau, poate, echipa Durov va abandona ideile de descentralizare și serverele lor o vor face de modă veche?
De fapt, nici unul, nici celălalt răspuns nu este corect. Dar marginile acestui articol se epuizează rapid, așa că vom vorbi despre diferitele roluri ale nodurilor (s-ar putea să fi observat deja mențiuni despre unele dintre ele), precum și despre mecanica muncii lor, în partea următoare.
Sursa: www.habr.com