Questo testo è il proseguimento di una serie di articoli in cui analizzo la struttura (presumibilmente) della rete decentralizzata Telegram Open Network (TON) che dovrebbe essere rilasciata quest'anno. 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 è stato tratto da una fonte aperta (anche se non verificata) — (c'è anche un , che espone brevemente i punti principali), pubblicato alla fine dello scorso anno. Il volume di informazioni in questo documento, a mio avviso, testimonia la sua autenticità, sebbene non ci siano conferme ufficiali.
Oggi daremo un'occhiata al componente principale di TON — blockchain.
Concetti di base
Account (account). Un insieme di dati, identificato da un numero a 256 bit account_id (di solito si tratta della chiave pubblica del proprietario dell'account). Nel caso di base (vedi sotto blockchain nullo), questi dati rappresentano il saldo dell'utente. Chiunque può "prendere in prestito" un determinato account_id ma il suo valore può essere modificato solo secondo determinate regole.
Smart contract (smart-contract). In effetti, è un caso particolare di account, arricchito da codice di smart contract e da una repository delle sue variabili. Nel caso del "wallet" si possono accreditare e addebitare soldi da esso secondo regole relativamente semplici e prestabilite, mentre nel caso dello smart contract queste regole sono scritte sotto forma del suo codice (in un linguaggio di programmazione Turing completo).
Stato della blockchain (state of blockchain). Insieme degli stati di tutti gli account/smart contracts (in senso astratto — 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 soldi" — questo è un esempio particolare di messaggio ("trasferire N grammi da account account_1 a account account_2"). È evidente che solo un nodo in possesso della chiave privata dell'account può inviare un tale messaggio. account_1 — e in grado di confermarlo con la propria firma. Il risultato della consegna di tali messaggi a un account normale è l'aumento del suo saldo, mentre per il contratto intelligente è l'esecuzione del suo codice (che gestirà la ricezione del messaggio). Ovviamente, possono esistere anche altri messaggi (che trasferiscono dati arbitrari tra contratti intelligenti, non somme di denaro).
La transazione (transazione). Il fatto che un messaggio venga consegnato è chiamato transazione. Le transazioni modificano lo stato della blockchain. È proprio dalle transazioni (registrazioni di consegna dei messaggi) che sono costituiti i blocchi nella blockchain. In questo senso, si può considerare lo stato della blockchain come un database incrementale: tutti i blocchi sono "diff" che devono essere applicati in sequenza per ottenere lo stato attuale del DB. Si parlerà della specificità dell'imballaggio di questi "diff" (e del ripristino dello stato completo da essi) nel prossimo articolo.
Blockchain in TON: che cos'è e a cosa serve?
Come accennato nell'articolo precedente, la blockchain è una struttura dati i cui elementi (blocchi) sono disposti in una "catena", e ogni blocco successivo della catena contiene l'hash di quello precedente. Nei commenti è stata posta la domanda: a cosa serve questa struttura dati, quando abbiamo già una DHT — una tabella hash distribuita? È chiaro che alcuni dati possono essere memorizzati anche nella DHT, ma questo è adatto solo per informazioni non troppo "sensibili". Non si possono memorizzare i saldi delle criptovalute nella DHT, prima di tutto a causa dell'assenza di controlli su integrità. In effetti, tutta la complessità della struttura della blockchain si sviluppa per prevenire interferenze nei dati memorizzati al suo interno.
Tuttavia, la blockchain in TON appare ancora più complessa rispetto alla maggior parte degli altri sistemi distribuiti — e ci sono due motivi per questo. Il primo è la volontà di ridurre al minimo la necessità di fork. Nelle criptovalute tradizionali, tutti i parametri sono definiti all'inizio e qualsiasi tentativo di cambiarli porta di fatto alla creazione di un "universo alternativo della criptovaluta". Il secondo motivo è il supporto del partizionamento (sharding, )) blockchain. Il blockchain è una struttura che non può ridursi nel tempo; e di solito ogni nodo responsabile del funzionamento della rete è costretto a conservarlo completamente. Nelle tradizionali (centralizzate) sistemi, per affrontare simili problemi si utilizza lo sharding: parte dei record nel database risiede su un server, parte su un altro, e così via. Nel caso delle criptovalute, questa funzionalità è ancora piuttosto rara, soprattutto perché è difficile implementare lo sharding in un sistema dove non era stato pianificato fin dall'inizio.
In che modo TON intende affrontare entrambe le problematiche descritte sopra?
Contenuto del blockchain. Workchains.
Per cominciare, parliamo di cosa si prevede si conservi nel blockchain. Qui saranno memorizzati gli stati degli account (i 'portafogli' nel caso base) e dei contratti intelligenti (per semplicità consideriamo che siano la stessa cosa degli account). In sostanza, sarà una normale tabella hash — le chiavi saranno gli identificatori account_id, e i valori saranno strutture dati contenenti cose come:
- saldo;
- codice del contratto intelligente (solo per i contratti intelligenti);
- memoria dei dati del contratto intelligente (solo per i contratti intelligenti);
- statistiche;
- (opzionalmente) chiave pubblica per trasferimenti dall'account, per impostazione predefinita account_id;
- coda dei messaggi in uscita (qui vengono messi per essere inviati ai destinatari);
- lista degli ultimi messaggi recapitati a questo account.
Come detto sopra, i blocchi consistono essenzialmente in transazioni — messaggi inviati a diversi account account_id. Tuttavia, oltre a account_id, i messaggi contengono anche un campo a 32 bit workchain_id — identificatore del cosiddetto workchain (workchain, working blockchain). Questo consente di avere diversi blockchain indipendenti l'uno dall'altro con configurazioni diverse. In questo contesto, workchain_id = 0 è considerato un caso speciale, workchain nullo — infatti i saldi in esso corrisponderanno alla criptovaluta TON (Grams). È probabile che inizialmente non esisteranno altri workchains.
Shardchains. Infinite Sharding Paradigm.
Ma la crescita del numero di blockchain non si ferma qui. Approfondiamo il concetto di sharding. Immaginiamo che a ciascun account (account_id) sia assegnata la propria blockchain — in essa si trovano tutti i messaggi in arrivo — e lo stato di tutte queste blockchain è conservato su nodi separati.
Certo, questo è piuttosto dispendioso: è probabile che in ciascuna di queste shardchain (shardchain, blockchain shard) le transazioni arriveranno molto raramente, e ci saranno bisogno di molti nodi potenti (anticipando, segnalo che non si parla semplicemente di client su telefoni cellulari, ma di server seri).
Pertanto, le shardchain raggruppano gli account in base ai prefissi binari dei loro identificatori: se una shardchain ha un prefisso 0110, allora riceverà le transazioni di tutti gli account che iniziano con queste cifre. Questo shard_prefix può avere una lunghezza da 0 a 60 bit — e la cosa principale è che può cambiare dinamicamente.
Non appena una delle shardchain inizia a ricevere un numero eccessivo di transazioni, i nodi che operano su di essa "dividono" la shardchain in due figlie secondo regole predefinite — i loro prefissi saranno più lunghi di un bit (e per uno di essi questo bit sarà 0, mentre per l'altro sarà 1). Ad esempio, shard_prefix = 0110b si dividerà in 01100b e 01101b. A sua volta, se due shardchain "vicine" iniziano a sentirsi abbastanza a loro agio (per un certo periodo di tempo), si fonderanno di nuovo.
In questo modo, lo sharding viene fatto "dal basso verso l'alto" — presumiamo che ciascun account possieda il proprio shard, ma essi sono - fino a un certo punto - "incollati" dai prefissi. Questo implica Infinite Sharding Paradigm (paradigma di sharding infinito).
Voglio sottolineare che le workchain esistono solo virtualmente — in realtà, workchain_id è parte dell’identificatore di una specifica shardchain. Parlando in termini formali, ogni shardchain è definita da una coppia di numeri (workchain_id, shard_prefix).
Correzione degli errori. Blockchain verticali.
Tradizionalmente si considera che ogni transazione in una 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") dimostrerà che uno dei blocchi è stato firmato in modo errato. In questo caso, un blocco correttivo speciale viene aggiunto al corrispondente sharding chain, contenente l'hash del blocco stesso da correggere (e non dell'ultimo blocco nello sharding chain). Rappresentando lo sharding chain come una catena di blocchi disposta orizzontalmente, si può dire che il blocco correttivo si attacca al blocco errato non a destra, ma sopra — pertanto si considera che diventi parte di un piccolo 'blockchain verticale'. Così, si può dire che gli sharding chain sono blockchain bidimensionali.
Nel caso in cui dopo un blocco errato le modifiche apportate da esso siano state richiamate da blocchi successivi (cioè, siano state effettuate nuove transazioni basate su dati non validi), a questi blocchi vengono anche aggiunti correttivi 'dall'alto'. Se i blocchi non hanno toccato le informazioni 'colpite', le 'onde correttive' non si diffondono su di essi. Ad esempio, nell'illustrazione sopra, la transazione del primo blocco, che aumenta il saldo dell'account C, è stata riconosciuta come errata — quindi la transazione che diminuisce il saldo di questo account nel terzo blocco deve anch'essa 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à saranno aggiunti alla fine del corrispondente blockchain (lì dove dovrebbero trovarsi cronologicamente). La disposizione bidimensionale mostra solo a quale punto nella blockchain saranno 'agganciati' (tramite l'hash del blocco originale contenuto in essi).
Si può filosofeggiare separatamente su quanto sia buona la decisione di 'cambiare il passato'. Sembrerebbe che, se tolleriamo la possibilità che si verifichi un blocco errato nello sharding chain, non si possa escludere nemmeno la possibilità di un blocco correttivo errato. Qui, per quanto posso giudicare, la differenza sta nel numero di nodi che devono raggiungere il consenso riguardo ai nuovi blocchi — su ogni sharding chain lavorerà un relativamente piccolo 'gruppo di lavoro' di nodi (che cambia abbastanza frequentemente), mentre l'inserimento di blocchi correttivi richiederà il consenso di tutti i nodi validatori. Parlerò di più sui validatori, gruppi di lavoro e altri ruoli dei nodi nel prossimo articolo.
Un blockchain per governarli tutti
Le informazioni varie sui diversi tipi di blockchain sopra citate devono essere anch'esse archiviate da qualche parte. In particolare, si tratta delle seguenti informazioni:
- sul numero e le configurazioni dei workchains;
- s sul numero di shardchains e i loro prefissi;
- sui nodi attualmente responsabili di quali shardchains;
- hash degli ultimi blocchi aggiunti a tutti gli shardchains.
Come potreste aver intuito, tutte queste informazioni vengono registrate in un altro blockchain di archiviazione— masterchain (masterchain, master blockchain). Grazie alla presenza negli suoi blocchi degli hash di tutti i blocchi degli shardchains, rende il sistema fortemente interconnesso. Ciò significa anche che la generazione di un nuovo blocco nel masterchain avverrà immediatamente dopo la generazione dei blocchi negli shardchains, con l'aspettativa che i blocchi negli shardchains compaiano quasi simultaneamente circa ogni 5 secondi, e il successivo blocco nel masterchain un secondo dopo.
Ma chi sarà responsabile per l'implementazione di tutto questo lavoro titanico - per l'invio di messaggi, l'esecuzione di contratti smart, la formazione di blocchi negli shardchains e nel masterchain, e persino il controllo dei blocchi per errori? Saranno davvero i telefoni di milioni di utenti con il client di Telegram installato a farlo in silenzio? O forse il team di Durov rinuncerà alle idee di decentralizzazione e lo faranno i loro server in modo tradizionale?
In realtà, nessuna delle due risposte è corretta. Ma gli spazi di questo articolo stanno rapidamente esaurendosi, quindi la discussione sui vari ruoli dei nodi (avrete già notato alcuni riferimenti a loro) e sulle meccaniche del loro funzionamento proseguirà nella prossima parte.
Fonte: habr.com
