Già da due settimane, il Runet discute di Telegram e della situazione con il suo blocco insensato e spietato da parte del Roskomnadzor. Questo ha colpito molte persone, ma sono tutti temi per i post su Geektimes. Quello che mi ha sorpreso, tuttavia, è che finora non ho visto su Habr alcuna analisi della rete TON — Telegram Open Network, che dovrebbe essere rilasciata basata su Telegram. Ho voluto colmare questa lacuna, perché c'è molto da esplorare — anche nonostante l'assenza di dichiarazioni ufficiali al riguardo.
Ricordo che ci sono voci secondo cui Telegram ha lanciato un ICO chiuso su larga scala, raccogliendo già somme incredibili. Si prevede che già quest'anno verrà lanciata la propria criptovaluta Gram — e ogni utente di Telegram avrà automaticamente un portafoglio, il che di per sé crea un notevole vantaggio rispetto alle altre criptovalute.
Sfortunatamente, poiché non ci sono dichiarazioni ufficiali, posso basarmi solo su , di cui vi avverto subito. Certamente, potrebbe rivelarsi un falso molto ben fatto, ma non è escluso che sia un vero whitepaper del futuro sistema, scritto da Nikolai Durov (e probabilmente trapelato da qualcuno tra gli investitori). Ma anche se si trattasse di un fake, nessuno ci impedirà di esplorarlo e discuterne, giusto?
Cosa dice quindi questo documento? Cercherò di riassumerlo con parole mie, vicino al testo, ma in italiano e con un tono un po' più umano (che Nikolai mi perdoni per la sua inclinazione ad addentrarsi nella matematica formale). Tenete presente che, anche nel caso fosse autentico, si tratta di una descrizione preliminare del sistema e, molto probabilmente, cambierà al momento del lancio pubblico.
Scopriamo che oltre alla criptovaluta ci sono molte e molte altre cose previste. Analizziamo tutto per ordine.
- TON Blockchain. È la base di tutto il sistema. Se non sapete affatto cosa sia , vi consiglio di informavi, perché qui ci saranno molte blockchain. Annidate l'una nell'altra, virtualmente frantumate e persino "verticali" blockchain all'interno di blocchi di altre blockchain. E ci saranno anche diversi termini che suonano bene come Instant Hypercube Routing e Infinite Sharding Paradigm, ma ne parleremo più avanti. E, naturalmente, proof-of-stake e smart contract.
- TON P2P Network. Rete peer-to-peer, su cui si baserà il funzionamento del sistema. Di essa si parlerà principalmente in questa parte della narrazione.
- TON Storage. Uno storage di file che, indipendentemente dalla blockchain, sarà costruito sulla rete peer-to-peer sopra menzionata. Può essere paragonato ai torrent.
- TON Proxy. Questo è un servizio il cui obiettivo è aumentare l'anonimato dei partecipanti alla rete. Qualsiasi pacchetto può essere inviato non direttamente, ma attraverso tunnel intermedi con crittografia aggiuntiva, simile a I2P o TOR.
- TON DHT. Una tabella hash distribuita per la memorizzazione di valori arbitrari. Anch'essa è costruita sopra TON Network (ma viene utilizzata dalla stessa rete) e aiuta TON Storage a trovare nodi "sharing", e TON Proxy — relay intermedi. Ma va notato che, a differenza della blockchain, questa tabella hash non è uno storage sicuro: non si possono memorizzare informazioni importanti al suo interno.
- TON Services. Una piattaforma per servizi arbitrari. In sostanza, questo è un nuovo internet sopra tutto quanto descritto. Lo scambio di dati avviene tramite TON Network/TON Proxy, mentre la logica è nei smart contract della stessa TON Blockchain. E l'interfaccia presenta URL piuttosto familiari.
- TON DNS. Dato che si è parlato di URL familiari, è necessario anche un convertitore da questi a indirizzi a 256 bit: account, contratti, servizi e nodi.
- TON Payments. E solo qui si tocca il tema monetario. E questo non sarà solo gram — come con l'ether, potranno essere disponibili qualsiasi "token"; i grammi saranno qui solo la valuta "predefinita".
Questa è la prima parte che descrive il livello "terreno" di TON — la sua parte di rete che si costruisce sopra protocolli tradizionali. Nella prossima parte si parlerà del "nucleo" — la blockchain che sarà supportata dal sistema descritto in seguito. Pertanto, il mio ordine di esposizione differisce leggermente da quello utilizzato nel documento sopra menzionato (che inizia subito con il livello astratto).
Concetti di base
TL (Type Language). È un formato binario astratto per strutture dati arbitrarie. Viene utilizzato nel protocollo di Telegram e sarà attivamente utilizzato in TON. Se vuoi approfondire, .
Hash (hash). Una funzione che esegue una trasformazione irreversibile di qualsiasi struttura dati in un singolo numero di lunghezza fissa. Nella documentazione, si parla ovunque di questa funzione. .
Nodo di rete (node). Un nodo è un software che garantirà il funzionamento del sistema. In particolare, si prevede che ogni applicazione client di Telegram includa un nodo del TON. A basso livello, i nodi hanno indirizzi IPv4/IPv6 e comunicano tramite protocollo UDP, a un livello superiore possiedono indirizzi astratti e realizzano il protocollo ADNL (sugli indirizzi astratti e ADNL — vedi sotto). Quando si parla di alcune parti del sistema che effettuano determinate operazioni o memorizzano dei dati, si intende che ciò viene svolto dai nodi della rete.
Indirizzo astratto (o semplicemente indirizzo, address). L'indirizzo di un nodo è definito dalla sua chiave pubblica. Più precisamente, si tratta di un hash a 256 bit (SHA256) della struttura dei dati contenente la chiave pubblica (il specifico algoritmo crittografico non viene specificato — come esempio si citano le curve ellittiche e RSA-2048). Affinché un nodo possa interagire con un altro, deve conoscere non solo l'indirizzo di quest'ultimo, ma anche questa struttura di dati. Teoricamente, un unico nodo fisico può creare un numero qualsiasi di indirizzi (corrispondenti a chiavi diverse).
Solitamente si utilizza proprio questa combinazione: il «modello» sotto forma di struttura TL (che contiene praticamente qualsiasi dato) e l'hash a 256 bit di essa, utilizzato per l'indirizzamento.
Blockchain (blockchain). La blockchain è una struttura dati i cui elementi (blocchi) sono ordinati in una «catena» e ogni blocco successivo della catena contiene l'hash del precedente. In questo modo si raggiunge l'integrità: le modifiche possono essere apportate solo aggiungendo nuovi blocchi.
Servizio (service). I servizi all'interno del TON possono essere di diversi tipi, a seconda che utilizzino o meno la blockchain. Ad esempio, uno (o più) nodi della rete può elaborare alcune richieste RPC attraverso il protocollo ADNL descritto di seguito, senza creare alcuna registrazione nella blockchain, simile ai tradizionali server web. Si sta anche considerando la possibilità di implementare HTTP sopra ADNL, così come il passaggio dello stesso messenger a questo protocollo. Analogamente a TOR o I2P, questo lo renderà più resistente a varie forme di blocco.
Allo stesso tempo, una serie di servizi implica sia l'interazione con la blockchain che l'elaborazione delle richieste esternamente. Ad esempio, per TON Storage — un'archiviazione di file — non è molto sensato memorizzare i file stessi nella blockchain. Essa conterrà solo gli hash dei file (insieme a qualche meta-informazione su di essi), mentre nodi specializzati della rete fungeranno da «server di file», pronti a fornirli ad altri nodi tramite ADNL.
Servizio nuvoloso (fog service). Si tratta di alcuni servizi che comportano decentralizzazione e partecipazione aperta. Ad esempio, TON Proxy è un servizio che può essere supportato da qualsiasi partecipante desideri fornire il proprio nodo come intermediario (proxy), che inoltra pacchetti tra altri nodi. Se lo desidera, può addebitare una commissione fissata da lui stesso — utilizzando il sistema TON Payments per micro-pagamenti (che, a sua volta, è anch'esso un servizio nuvoloso).
ADNL: Abstract Datagram Network Layer
A livello più basso, l'interazione tra i nodi avverrà tramite il protocollo UDP (anche se sono ammissibili altre varianti).
Come accennato in precedenza, affinché un nodo possa inviare un pacchetto a un altro, deve conoscere una delle sue chiavi pubbliche (e, di conseguenza, l'indirizzo ad essa definito). Cifra il pacchetto con questa chiave e aggiunge all'inizio del pacchetto un indirizzo del destinatario di 256 bit — poiché un nodo può avere più di questi indirizzi, questo gli consentirà di determinare quale chiave utilizzare per decrittare.
Inoltre, al posto dell'indirizzo del destinatario all'inizio del pacchetto dati può trovarsi il cosiddetto identificatore canale. In tal caso, l'elaborazione del pacchetto dipende già da specifici accordi tra i nodi — ad esempio, i dati inviati in un certo canale possono essere destinati a un altro nodo e devono essere indirizzati a lui (questo è il servizio TON Proxy). Un'altra situazione particolare può essere l'interazione diretta tra nodi, ma con crittografia basata su una coppia di chiavi individuali per quel canale (pre-formate secondo il protocollo di Diffie-Hellman).
Infine, un caso speciale è il canale "zero": se il nodo non conosce ancora le chiavi pubbliche dei suoi "vicini", può inviare loro pacchetti senza alcuna crittografia. Questo è destinato solo all'inizializzazione: non appena i nodi inviano informazioni sulle proprie chiavi, queste devono essere utilizzate per ulteriori interazioni.
Il protocollo sopra descritto (256 bit dell'identificatore di canale + contenuto del pacchetto) è chiamato ADNL. La documentazione menziona la possibilità di implementare un analogo di TCP sopra di esso o un proprio strato superiore: RLDP (Reliable Large Datagram Protocol), ma non entra nei dettagli su come vengono implementati.
TON DHT: Tabella hash distribuita
Come nel caso di altri sistemi distribuiti, TON prevede l'implementazione di una DHT — . Più specificamente, la tabella è . Se non sei familiare con questo tipo di tabelle hash, non preoccuparti, di seguito descriverò a grandi linee come sono strutturate.
In un senso astratto, la DHT associa chiavi a 256 bit a valori binari di lunghezza arbitraria. In questo caso, le chiavi nella tabella sono hash di una certa struttura TL (anche le strutture vengono memorizzate insieme alla DHT). Questo è molto simile alla formazione degli indirizzi dei nodi — e possono davvero essere presenti nella DHT (ad esempio, un indirizzo IP di un nodo corrispondente a un dato indirizzo astratto, se non lo nasconde). Ma in generale, i "prototipi delle chiavi" (le loro descrizioni, key descriptions) sono metadati che indicano il "proprietario" della voce nella tabella hash (cioè la chiave pubblica di un certo nodo), il tipo di valore memorizzato e le regole secondo cui questa voce può successivamente essere modificata. Ad esempio, una regola può consentire di modificare il valore solo al proprietario — o vietare la modifica del valore verso il basso (per proteggersi da attacchi di replay).
Oltre alle chiavi a 256 bit, viene introdotto il concetto di indirizzi DHT. La differenza con gli indirizzi normali dei nodi è che l'indirizzo DHT è necessariamente associato a un indirizzo IP. Se un nodo non nasconde il proprio IP, può utilizzare un indirizzo normale per la DHT. Ma più spesso, per le esigenze della DHT, verrà creato un indirizzo separato, "semi-permanente".
Sui valori delle chiavi e sugli indirizzi DHT viene introdotto il concetto di distanza — in questo tutto coincide con le tabelle. La distanza tra le chiavi è pari all'XOR (operazione esclusiva tra bit) tra di esse. Come nelle tabelle di Kademlia, il valore corrispondente a una certa chiave deve essere memorizzato su s nodi che hanno la distanza minore da questa chiave (s qui — un numero relativamente piccolo).
Per consentire a un nodo DHT di interagire con altri nodi simili, mantiene in memoria una tabella di instradamento DHT — indirizzi DHT e IP dei nodi con cui ha interagito in precedenza, raggruppati in base alla distanza da essi. Ci sono 256 di questi gruppi (corrispondono al bit più significativo impostato nel valore della distanza — cioè i nodi a distanza da 0 a 255 entreranno in un gruppo, da 256 a 65535 in un altro, e così via). All'interno di ciascun gruppo è memorizzato un numero limitato di "migliori" nodi (in termini di ping verso di essi).
Ogni nodo deve supportare diverse operazioni: memorizzazione di un valore per una chiave, ricerca di nodi e ricerca di valori. La ricerca di nodi implica il ritorno dei nodi più vicini ad essi dalla tabella di instradamento per la chiave data; la ricerca di valori è la stessa cosa, tranne nei casi in cui il nodo conosce già il valore per la chiave (in tal caso, restituisce semplicemente quel valore). Pertanto, se un nodo desidera trovare un valore DHT per una chiave, invia richieste a un numero ristretto di nodi più vicini a quella chiave dalla sua tabella di instradamento. Se nessuno dei loro risposte contiene il valore ricercato, ma ci sono altri indirizzi nodi, allora la richiesta viene ripetuta a questi.
TON DHT può essere utilizzato per vari scopi, ad esempio — per implementare uno storage di file simile a un torrent (vedi TON Storage); per identificare gli indirizzi dei nodi che implementano determinati servizi; per memorizzare informazioni sui proprietari di account nella blockchain. Ma l'applicazione più importante è la scoperta di nodi tramite i loro indirizzi astratti. A tal fine, l'indirizzo è utilizzato come chiave, il cui valore deve essere trovato. A seguito della richiesta, o si troverà il nodo stesso (se l'indirizzo ricercato era il suo indirizzo DHT semi-permanente), oppure il valore sarà un indirizzo IP e una porta per la connessione — oppure un altro indirizzo che dovrebbe essere utilizzato come tunnel intermediario.
Reti overlay in TON
Il protocollo ADNL descritto sopra implica che ogni nodo possa scambiarsi informazioni tra loro, anche se non necessariamente attraverso modalità ottimali. Si potrebbe dire che grazie all'ADNL tutti i nodi formano un grafo globale TON (idealmente – connesso). Tuttavia, è prevista anche la possibilità di creare reti sovrapposte – sottografi all'interno di questo grafo.
All'interno di tale rete, l'interazione avviene solo direttamente, tramite connessioni preformate tra i nodi partecipanti alla rete (tramite i canali ADNL, descritti sopra). La formazione di tali collegamenti tra i vicini e la ricerca degli stessi vicini è un processo automatico, mirato a mantenere la connettività della rete sovrapposta e a minimizzare i ritardi nello scambio di dati al suo interno.
Inoltre, è previsto un modo per diffondere rapidamente grandi aggiornamenti broadcast all'interno della rete: essi vengono suddivisi in parti, integrati con codici di correzione degli errori, e tutti questi pezzi vengono inviati da un partecipante all'altro. In questo modo, un partecipante non deve necessariamente ricevere completamente tutte le parti prima di inviarle ulteriormente nella rete.
Le reti sovrapposte possono essere pubbliche e private. Diventare partecipante di una rete pubblica non è difficile: è necessario trovare una struttura TL che la descriva (può essere pubblica o accessibile tramite un certo codice in DHT). Nel caso di una rete privata, questa struttura deve essere nota al nodo in anticipo.
Continua
Ho deciso di suddividere la panoramica di TON in più articoli. Qui termina questa parte, e passerò a discutere la struttura della blockchain (per essere precisi, delle blockchain) da cui sarà composto TON.
Fonte: habr.com
