Aquest text és la continuació d'una sèrie d'articles en què examino l'estructura de la xarxa (presumiblement) distribuïda Telegram Open Network (TON), que s'està preparant per al seu llançament aquest any. EN Vaig descriure el seu nivell més bàsic: la manera com els nodes interactuen entre ells.
Per si de cas, us recordo que no tinc res a veure amb el desenvolupament d'aquesta xarxa i que tot el material s'ha recollit d'una font oberta (encara que no verificada). (també hi ha un acompanyament , exposant breument els punts principals), que van aparèixer a finals de l'any passat. La quantitat d'informació d'aquest document, al meu entendre, indica la seva autenticitat, encara que no hi ha cap confirmació oficial d'això.
Avui veurem el component principal de TON: la cadena de blocs.
Conceptes bàsics
Compte (Compte). Conjunt de dades identificades per un número de 256 bits account_id (la majoria de vegades aquesta és la clau pública del propietari del compte). En el cas base (vegeu a continuació cadena de treball zero), aquestes dades fan referència al saldo de l'usuari. "Ocupar" específic account_id qualsevol pot, però el seu valor només es pot canviar segons determinades regles.
Contracte intel·ligent (contracte intel·ligent). En essència, es tracta d'un cas especial d'un compte, complementat amb codi de contracte intel·ligent i emmagatzematge de les seves variables. Si en el cas d'una "cartera" podeu dipositar-ne i retirar diners d'acord amb regles relativament simples i predeterminades, aleshores en el cas d'un contracte intel·ligent aquestes regles s'escriuen en forma del seu codi (en un cert Turing-complet). llenguatge de programació).
Estat de la cadena de blocs (estat de la cadena de blocs). El conjunt d'estats de tots els comptes/contractes intel·ligents (en un sentit abstracte, una taula hash, on les claus són identificadors de comptes i els valors són les dades emmagatzemades als comptes).
Missatge (missatge). A dalt he utilitzat l'expressió "diners de crèdit i dèbit": aquest és un exemple particular de missatge ("transferència N grams des del compte compte_1 al compte compte_2"). Òbviament, només el node propietari de la clau privada del compte pot enviar aquest missatge compte_1 - i capaç de confirmar-ho amb una signatura. El resultat de lliurar aquests missatges a un compte normal és un augment del seu saldo, i el resultat del contracte intel·ligent és l'execució del seu codi (que processarà la recepció del missatge). Per descomptat, també són possibles altres missatges (transferint no quantitats monetàries, sinó dades arbitràries entre contractes intel·ligents).
Transacció (transacció). El fet que es lliura un missatge s'anomena transacció. Les transaccions canvien l'estat de la cadena de blocs. Són les transaccions (registres de lliurament de missatges) les que conformen els blocs de la cadena de blocs. En aquest sentit, podeu pensar en l'estat de la cadena de blocs com una base de dades incremental: tots els blocs són "diferències" que s'han d'aplicar seqüencialment per obtenir l'estat actual de la base de dades. Els detalls de l'embalatge d'aquestes "diferències" (i la restauració de l'estat complet d'ells) es parlaran al següent article.
Blockchain a TON: què és i per què?
Com s'ha esmentat a l'article anterior, blockchain és una estructura de dades, els elements (blocs) de les quals s'ordenen en una "cadena" i cada bloc posterior de la cadena conté un hash de l'anterior.. Els comentaris plantejaven la pregunta: per què necessitem aquesta estructura de dades quan ja tenim un DHT, una taula hash distribuïda? Òbviament, algunes dades es poden emmagatzemar a DHT, però això només és adequat per a informació no massa "sensible". Els saldos de criptomoneda no es poden emmagatzemar a DHT, principalment a causa de la manca de comprovacions integritat. De fet, tota la complexitat de l'estructura de la cadena de blocs creix per evitar interferències amb les dades emmagatzemades en ella.
Tanmateix, la cadena de blocs a TON sembla encara més complexa que a la majoria dels altres sistemes distribuïts, i per dues raons. El primer és el desig de minimitzar la necessitat de forquilles. A les criptomonedes tradicionals, tots els paràmetres s'estableixen en l'etapa inicial i qualsevol intent de canviar-los condueix realment a l'aparició d'un "univers alternatiu de criptomonedes". La segona raó és el suport per a la trituració (fragmentació, fragmentació) cadena de blocs. Blockchain és una estructura que no es pot reduir amb el temps; i normalment cada node responsable del funcionament de la xarxa es veu obligat a emmagatzemar-la completament. En els sistemes tradicionals (centralitzats), s'utilitza sharding per resoldre aquests problemes: alguns dels registres de la base de dades es troben en un servidor, alguns en un altre, etc. En el cas de les criptomonedes, aquesta funcionalitat encara és força rara, en particular, a causa del fet que és difícil afegir fragments a un sistema on no estava previst originalment.
Com pensa TON resoldre els dos problemes anteriors?
Contingut Blockchain. Cadenes de treball.
Primer de tot, parlem del que està previst emmagatzemar a la cadena de blocs. Allà s'emmagatzemaran els estats dels comptes ("carteres" en el cas base) i els contractes intel·ligents (per simplificar, assumirem que això és el mateix que els comptes). En essència, aquesta serà una taula hash normal: les claus seran identificadors account_id, i els valors són estructures de dades que contenen coses com ara:
- equilibri;
- codi de contracte intel·ligent (només per a contractes intel·ligents);
- Emmagatzematge de dades de contracte intel·ligent (només per a contractes intel·ligents);
- estadístiques;
- (opcional) clau pública per a transferències des del compte, per defecte account_id;
- cua de missatges sortints (aquí s'introdueixen per reenviar-los al destinatari);
- una llista dels darrers missatges enviats a aquest compte.
Com s'ha esmentat anteriorment, els blocs en si consisteixen en transaccions: missatges lliurats a diversos comptes account_id. Tanmateix, a més de account_id, els missatges també contenen un camp de 32 bits workchain_id - l'anomenat identificador cadena de treball (cadena de treball, blockchain en funcionament). Això us permet tenir diverses cadenes de blocs independents les unes de les altres amb diferents configuracions. En aquest cas, workchain_id = 0 es considera un cas especial, cadena de treball zero — són els saldos que hi ha que correspondran a la criptomoneda TON (Grams). Molt probablement, al principi, altres cadenes de treball no existiran en absolut.
Cadenas de fragments. Paradigma de fragmentació infinita.
Però el creixement del nombre de blockchains no s'atura aquí. Ocupem-nos de la fragmentació. Imaginem que a cada compte (account_id) se li assigna la seva pròpia cadena de blocs (conté tots els missatges que hi arriben) i els estats de totes aquestes cadenes de blocs s'emmagatzemen en nodes separats.
Per descomptat, això és molt malbaratador: molt probablement, en cadascun d'ells cadenes de fragments (cadena de fragments, shard blockchain) les transaccions arribaran molt poques vegades i es necessitaran molts nodes potents (de cara al futur, observo que no només parlem de clients en telèfons mòbils, sinó de servidors seriosos).
Per tant, les shardchain combinen els comptes mitjançant els prefixos binaris dels seus identificadors: si una shardchain té un prefix de 0110, inclourà les transaccions de tots els account_ids que comencen amb aquests números. Això shard_prefix pot tenir una longitud de 0 a 60 bits, i el més important és que pot canviar dinàmicament.
Tan bon punt una de les cadenes de fragments comença a rebre massa transaccions, els nodes que hi treballen, segons regles predeterminades, la "divideixen" en dos fills; els seus prefixos seran una mica més llargs (i per a un d'ells aquest bit serà igual a 0, i per a l'altre - 1). Per exemple, shard_prefix = 0110b es dividirà en 01100b i 01101b. Al seu torn, si dues cadenes de fragments "veïnes" comencen a sentir-se prou a gust (durant un temps), es tornaran a fusionar.
Així, el fragment es fa "des de baix cap amunt": suposem que cada compte té el seu propi fragment, però de moment estan "enganxats" per prefixos. Això és el que vol dir Paradigma de fragmentació infinita (paradigma de fragmentació infinita).
Per separat, m'agradaria subratllar que les cadenes de treball només existeixen virtualment; de fet, workchain_id forma part de l'identificador d'una cadena de fragments específica. En termes formals, cada shardchain es defineix per un parell de nombres (workchain_id, shard_prefix).
Correcció d'errors. Blockchains verticals.
Tradicionalment, qualsevol transacció en una cadena de blocs es considera que està "en pedra". Tanmateix, en el cas de TON, és possible "reescriure la història" - en cas que algú (l'anomenat. nus de pescador) demostrarà que un dels blocs estava signat incorrectament. En aquest cas, s'afegeix un bloc de correcció especial a la cadena de fragments corresponent, que conté el hash del bloc que es corregeix (i no l'últim bloc de la cadena de fragments). Pensant en la cadena de fragments com una cadena de blocs distribuïts horitzontalment, podem dir que el bloc correctiu està unit al bloc erroni no cap a la dreta, sinó des de dalt, per la qual cosa es considera que forma part d'una petita "cadena de blocs vertical". . Així, podem dir que les cadenes de fragments ho són cadenes de blocs bidimensionals.
Si, després d'un bloc erroni, els canvis fets per aquest van ser referenciats per blocs posteriors (és a dir, es van fer noves transaccions basades en transaccions no vàlides), també s'afegeixen a aquests blocs els correctius "a la part superior". Si els blocs no van afectar la informació "afectada", aquestes "ones correctores" no s'apliquen a ells. Per exemple, a la il·lustració anterior, la transacció del primer bloc, que augmenta el saldo del compte C, es va reconèixer com a incorrecta; per tant, la transacció que disminueix el saldo d'aquest compte al tercer bloc també s'hauria de cancel·lar i un bloc correctiu. s'hauria de comprometre a la part superior del bloc.
Cal tenir en compte que, tot i que els blocs correctius es representen com a situats "a sobre" dels originals, de fet s'afegiran al final de la cadena de blocs corresponent (on haurien d'estar cronològicament). La ubicació bidimensional només mostra fins a quin punt de la cadena de blocs estaran "enllaçats" (mitjançant el hash del bloc original situat en ells).
Podeu filosofar per separat sobre com de bona és la decisió de "canviar el passat". Sembla que si admetem la possibilitat que aparegui un bloc incorrecte a la cadena de fragments, no podem evitar la possibilitat que aparegui un bloc correctiu erroni. Aquí, pel que puc dir, la diferència està en el nombre de nodes que han d'arribar a consens sobre nous blocs: hi haurà un nombre relativament reduït de persones treballant en cada shardchain".grup de treball» nodes (que canvia la seva composició amb força freqüència), i la introducció de blocs correctius requerirà el consentiment de tothom nodes validadors. En el proper article parlaré més sobre validadors, grups de treball i altres rols de nodes.
Una cadena de blocs per governar-los a tots
Hi ha molta informació a la llista anterior sobre els diferents tipus de blockchains, que també s'han d'emmagatzemar en algun lloc. En concret, estem parlant de la informació següent:
- sobre el nombre i les configuracions de les cadenes de treball;
- sobre el nombre de shardchains i els seus prefixos;
- sobre quins nodes són els responsables actualment de quines cadenes de fragments;
- hashes dels últims blocs afegits a totes les cadenes de fragments.
Com haureu endevinat, totes aquestes coses es registren en un altre emmagatzematge blockchain: cadena mestra (cadena mestra, mestre blockchain). A causa de la presència de hashes dels blocs de totes les cadenes de fragments dels seus blocs, fa que el sistema estigui molt connectat. Això significa, entre altres coses, que la generació d'un nou bloc a la cadena mestra es produirà immediatament després de la generació de blocs a les cadenes de fragments; s'espera que els blocs a les cadenes de fragments apareguin gairebé simultàniament aproximadament cada 5 segons, i el bloc següent al Masterchain: un segon després.
Però, qui serà el responsable de la implementació de tot aquest treball titànic: per enviar missatges, executar contractes intel·ligents, formar blocs en shardchains i la masterchain i, fins i tot, comprovar si hi ha errors en els blocs? Tot això ho faran en secret els telèfons de milions d'usuaris amb el client de Telegram instal·lat? O, potser, l'equip de Durov abandonarà les idees de descentralització i els seus servidors ho faran a l'antiga?
De fet, ni una ni l'altra resposta són correctes. Però els marges d'aquest article s'esgoten ràpidament, així que parlarem dels diferents rols dels nodes (potser ja n'haureu notat mencions d'alguns d'ells), així com de la mecànica del seu treball, a la part següent.
Font: www.habr.com