Questo testo è il seguito di una serie di articoli in cui esamino la struttura (presumibilmente) in fase di lancio quest'anno della rete distribuita Telegram Open Network (TON). In ho descritto il suo livello più basilare: il modo in cui i nodi interagiscono tra loro.
Per sicurezza, ricordo che non ho alcun legame con lo sviluppo di questa rete e tutto il materiale proviene da una fonte aperta (anche se non verificata) — (c'è anche una , che espone brevemente i punti principali), emersa alla fine dello scorso anno. A mio avviso, la quantità di informazioni in questo documento testimonia la sua autenticità, anche se non ci sono conferme ufficiali a riguardo.
Oggi daremo un'occhiata al componente principale di TON: la blockchain.
Concetti di base
Account (account). Un insieme di dati identificato da un numero a 256 bit account_id (nella maggior parte dei casi si tratta della chiave pubblica del proprietario dell'account). Nel caso base (vedi sotto workchain zero), questi dati si riferiscono al saldo dell'utente. Chiunque può "prendere in prestito" un certo account_id ma il suo valore può essere modificato solo secondo regole specifiche.
Smart contract (smart-contract). In sostanza, è un caso particolare di account, arricchito con codice di smart contract e memorizzazione delle sue variabili. Mentre nel caso di un «portafoglio» è possibile accreditare e addebitare denaro secondo regole relativamente semplici e predefinite, nel caso di uno smart contract queste regole sono registrate come codice (in un linguaggio di programmazione Turing-completo).
Stato della blockchain (state of blockchain). L'insieme degli stati di tutti gli account/smart contract (in una accezione astratta — una tabella hash, dove le chiavi sono gli identificatori degli account e i valori sono i dati memorizzati negli account).
Messaggio (message). Ho utilizzato sopra l'espressione «accreditare e addebitare denaro» — è un esempio specifico di messaggio («trasferire N grammi dall'account account_1 all'account account_2»). È ovvio che solo un nodo che possiede la chiave privata dell'account possa inviare un tale messaggio. account_1 — e può confermare ciò con la firma. La consegna di tali messaggi a un account normale porta ad un aumento del suo saldo, mentre al contratto intelligente ne comporta l'esecuzione del codice (che gestirà la ricezione del messaggio). Naturalmente, sono possibili anche altri messaggi (che trasferiscono non somme di denaro, ma dati arbitrari tra contratti intelligenti).
Transazione (transazione). Il fatto che un messaggio venga consegnato è chiamato transazione. Le transazioni modificano lo stato della blockchain. Sono proprio le transazioni (registrazioni di consegna dei messaggi) a costituire i blocchi nella blockchain. In questo senso, si può immaginare lo stato della blockchain come un database incrementale: tutti i blocchi sono «diff» che devono essere applicati sequenzialmente per ottenere l'attuale stato del DB. Di specificità del confezionamento di questi «diff» (e del ripristino dello stato completo tramite essi) si parlerà nel prossimo articolo.
Blockchain in TON: cos'è e a cosa serve?
Come accennato nell'articolo precedente, la blockchain è una struttura dati i cui elementi (blocchi) sono ordinati in una «catena», e ogni blocco successivo della catena contiene l'hash del blocco precedente.. Nei commenti è stata posta la domanda: a che serve una struttura dati del genere, quando abbiamo già il DHT — una tabella hash distribuita? È evidente che alcuni dati possono essere memorizzati anche nel DHT, ma questo è adatto solo per informazioni non troppo "sensibili". I saldi delle criptovalute non possono essere memorizzati nel DHT — soprattutto a causa dell'assenza di controlli sull' integrità. Infatti, tutta la complessità della struttura della blockchain cresce per prevenire le interferenze nei dati memorizzati in essa.
Tuttavia, la blockchain in TON sembra essere ancora più complessa rispetto alla maggior parte degli altri sistemi distribuiti — e ci sono due motivi per questo. Il primo è il tentativo di minimizzare la necessità di fork. Nelle criptovalute tradizionali, tutti i parametri sono definiti nella fase iniziale e ogni tentativo di modificarli porta praticamente alla nascita di un'"universo alternativo di criptovalute". Il secondo motivo è il supporto per la suddivisione (sharding, )) blockchain. Il blockchain è una struttura che non può ridursi nel tempo; e in genere ogni nodo responsabile del funzionamento della rete deve conservarne una copia completa. Nelle tradizionali (centralizzate) i sistemi, per risolvere problemi simili si usa lo sharding: parte dei dati nel database si trova su un server, parte su un altro, e così via. Nel caso delle criptovalute, questa funzionalità è ancora piuttosto rara — in particolare, perché è difficile aggiungere lo sharding in un sistema dove non era stato pianificato inizialmente.
Come intende il TON risolvere entrambi i problemi descritti sopra?
Contenuto del blockchain. I workchain.
Per prima cosa, parliamo di cosa si prevede di archiviare nel blockchain. Saranno conservati stati degli account (i "portafogli" nel caso di base) e dei contratti smart (per semplicità consideriamoli la stessa cosa degli account). In sostanza, sarà una normale tabella hash — gli identificatori saranno le chiavi account_id, e i valori saranno strutture dati che conterranno cose come:
- bilancio;
- codice del contratto smart (solo per i contratti smart);
- archiviazione dati del contratto intelligente (solo per contratti intelligenti);
- statistiche;
- (opzionale) chiave pubblica per trasferimenti dall'account, per impostazione predefinita account_id;
- coda dei messaggi in uscita (qui vengono registrati per l'invio al destinatario);
- elenco degli ultimi messaggi consegnati a questo account.
Come detto sopra, i blocchi consistono direttamente in transazioni — messaggi consegnati a diversi account account_id. Tuttavia, oltre a account_id, i messaggi contengono anche un campo di 32 bit workchain_id — identificatore del cosiddetto workchain (workchain, blockchain funzionante). Questo permette di avere più blockchain indipendenti l'una dall'altra con configurazioni diverse. In questo caso, workchain_id = 0 è considerato un caso speciale, workchain nullo — i saldi in esso corrisponderanno alla criptovaluta TON (Grams). È probabile che inizialmente non esistano altri workchain.
Sharding. Infinite Sharding Paradigm.
Ma la crescita del numero di blockchain non si ferma qui. Approfondiamo il concetto di sharding. Immaginiamo che a ogni account (account_id) venga assegnata una propria blockchain — in essa vengono registrati tutti i messaggi in arrivo — e gli stati di tutte queste blockchain sono memorizzati su nodi distinti.
Certo, è piuttosto dispendioso: probabilmente, in ciascuna di queste shardchain (shardchain, shard blockchain) le transazioni arriveranno molto raramente, e saranno necessari molti nodi potenti (anticipando, sottolineo che non si parla solo di client su telefoni cellulari — ma di server robusti).
Pertanto, gli shardchain raggruppano gli account in base ai prefissi binari dei loro identificatori: se uno shardchain ha un prefisso 0110, in esso confluiranno le transazioni di tutti gli account_id che iniziano con queste cifre. Questo shard_prefix può avere una lunghezza da 0 a 60 bit — e la cosa importante è che può cambiare dinamicamente.
Non appena uno dei shard chain inizia a ricevere un numero eccessivo di transazioni, i nodi che vi operano "splittano" il chain in due figli secondo regole prestabilite: i loro prefissi saranno più lunghi di un bit (e per uno di essi questo bit sarà 0, mentre per l'altro sarà 1). Per esempio, shard_prefix = 0110b si dividerà in 01100b e 01101b. A sua volta, se due shard chain "vicini" iniziano a sentirsi abbastanza a loro agio (per un certo periodo di tempo), essi si uniranno di nuovo in un unico chain.
Pertanto, lo sharding avviene "dal basso verso l'alto" — partiamo dal presupposto che ogni account abbia il proprio shard, ma fino a quel momento essi sono "uniti" per prefissi. Questo implica Paradigma di Sharding Infinito (il paradigma dello sharding infinito.).
Va sottolineato che i work chain esistono solo virtualmente — in realtà, workchain_id sono parte dell'identificatore di un particolare shard chain. In termini formali, ogni shard chain è definito da una coppia di numeri (workchain_id, shard_prefix).
Correzione degli errori. Blockchain verticali.
Tradizionalmente si considera che qualsiasi transazione sulla blockchain sia 'incisa nella pietra'. Tuttavia, nel caso di TON è prevista la possibilità di 'riscrivere la storia' — nel caso in cui qualcuno (il cosiddetto nodo 'pescatore') dimostri che uno dei blocchi è stato firmato in modo errato. In tal caso, viene aggiunto un blocco correttivo speciale al corrispondente shard chain, contenente l'hash del blocco da correggere (e non dell'ultimo blocco nella shard chain). Rappresentando lo shard chain come una catena di blocchi disposti orizzontalmente, si può dire che il blocco correttivo si attacca non a destra del blocco errato, ma sopra — per questo motivo si considera parte di un piccolo 'blockchain verticale'. Così si può dire che gli shard chain sono blockchain bidimensionali.
Nel caso in cui, dopo un blocco errato, successivi blocchi facessero riferimento alle modifiche apportate (cioè, fossero state effettuate nuove transazioni su basi non valide), anche a questi blocchi vengono aggiunti correttivi "dall'alto". Se i blocchi non hanno coinvolto le informazioni "colpite", queste "onde correttive" non si propagano su di essi. Ad esempio, nell'illustrazione sopra, la transazione del primo blocco, che incrementa il saldo dell'account C, è stata riconosciuta come non valida — pertanto la transazione che decrementa il saldo di questo account nel terzo blocco deve anche essere annullata, e un blocco correttivo deve essere registrato sopra il blocco stesso.
Va notato che, sebbene i blocchi correttivi siano rappresentati come posizionati "sopra" gli originali, in realtà verranno scritti alla fine del corrispondente blockchain (lì dove devono trovarsi cronologicamente). La disposizione bidimensionale mostra solo a quale punto della blockchain verranno "collegati" (tramite l'hash del blocco originale contenuto in essi).
Si può discutere separatamente su quanto sia efficace la soluzione di "cambiare il passato". Sembra che, se ammettiamo la possibilità di un blocco errato nella blockchain, non possiamo escludere neanche la possibilità di un blocco correttivo errato. Qui, per quanto posso giudicare, la differenza risiede nel numero di nodi che devono raggiungere un consenso sui nuovi blocchi: un numero relativamente ridotto di "gruppo di lavoro" nodi (che cambia abbastanza frequentemente), mentre l'aggiunta di blocchi correttivi richiederà il consenso di tutti i nodi-validatori. Maggiori dettagli sui validatori, sui gruppi di lavoro e sugli altri ruoli dei nodi saranno forniti nel prossimo articolo.
Una blockchain per governarle tutte
È stata fornita una grande quantità di informazioni sui vari tipi di blockchain, che di per sé deve anche essere archiviata da qualche parte. In particolare, si tratta delle seguenti informazioni:
- sul numero e le configurazioni dei workchain;
- sul numero di shardchain e i loro prefissi;
- su quali nodi sono attualmente responsabili di quali shardchain;
- gli hash degli ultimi blocchi aggiunti a tutte le shardchain.
Come avrete già capito, tutte queste cose vengono registrate in un ulteriore sistema di archiviazione: la blockchain — masterchain (masterchain, master blockchain). Grazie alla presenza degli hash dei blocchi di tutti gli sharding nei suoi blocchi, rende il sistema fortemente interconnesso. Ciò significa che la generazione di un nuovo blocco nel masterchain avverrà immediatamente dopo la generazione dei blocchi negli sharding — ci si aspetta che i blocchi negli sharding appaiano quasi simultaneamente ogni circa 5 secondi, e il successivo blocco nel masterchain — un secondo dopo di ciò.
Ma chi sarà responsabile per l'implementazione di tutto questo lavoro titanico — per l'invio dei messaggi, l'esecuzione dei contratti smart, la formazione dei blocchi negli sharding e nel masterchain, e anche per la verifica degli errori nei blocchi? Saranno davvero i telefoni di milioni di utenti con il client Telegram installato a fare tutto questo in silenzio? O forse il team di Durov rinuncerà alle idee di decentralizzazione e lo faranno i loro server in modo tradizionale?
In realtà, né l'uno né l'altro sono la risposta corretta. Ma gli spazi di quest'articolo si stanno rapidamente esaurendo, quindi parleremo delle diverse funzioni dei nodi (potresti aver già notato alcune menzioni di essi) e delle loro meccaniche nella prossima parte.
Fonte: habr.com
