Già da due settimane, il Runet parla di Telegram e della situazione riguardante il suo blocco ingiustificato e spietato da parte di Roskomnadzor. Molti hanno subito un impatto, ma questi sono argomenti per post su Geektimes. Ciò che mi ha colpito è un'altra cosa: non ho ancora visto su Habr una sola analisi della rete TON — Telegram Open Network, che dovrebbe essere lanciata. Volevo colmare questa lacuna, perché c'è molto da scoprire, anche nonostante l'assenza di dichiarazioni ufficiali su di essa.
Ricordo che ci sono voci che Telegram abbia avviato un'imponente ICO riservata, 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é rappresenta un grande vantaggio rispetto ad altre criptovalute.
Purtroppo, poiché non ci sono dichiarazioni ufficiali, posso basarmi solo su , di cui vi avverto subito. Certo, potrebbe rivelarsi una contraffazione molto ben fatta, ma non è escluso che si tratti di un vero whitepaper del futuro sistema, scritto da Nikolai Durov (e probabilmente trapelato da qualche investitore). Ma anche se fosse un falso, nessuno può vietarci di studiarlo e discuterne, giusto?
Cosa viene detto in questo documento? Cercherò di riassumerlo con parole mie, rimanendo fedele al testo ma in modo più umano (mi perdoni Nikolai per la sua tendenza a scivolare nella matematica formale). Tenete presente che, anche nel caso sia autentico, si tratta di una descrizione preliminare del sistema e molto probabilmente subirà modifiche prima del lancio pubblico.
Scopriamo che oltre alla criptovaluta ci sono molte altre cose previste. Analizziamo tutto per ordine.
- TON Blockchain. Questa è la base dell'intero sistema. Se non sapete affatto che cos'è — vi consiglio di informavi, perché qui ci saranno molte blockchain. Incorporate l'una nell'altra, virtualmente frammentate e anche blockchain "verticali" all'interno di blocchi di altri blockchain. E ci saranno anche alcuni termini che suonano davvero cool come Instant Hypercube Routing e Paradigma di Sharding Infinito, ma ne parleremo più tardi. E, naturalmente, proof-of-stake e smart contract.
- Rete P2P TON. Una rete di peer-to-peer, su cui si baserà il funzionamento del sistema. Di essa si parlerà principalmente in questa parte della narrazione.
- TON Storage. Uno spazio di archiviazione di file, che sarà costruito sulla rete peer-to-peer sopra menzionata, indipendentemente dalla blockchain. Può essere paragonato ai torrent.
- TON Proxy. Questo servizio ha l'obiettivo di 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 di hash distribuita per memorizzare valori arbitrari. Anche questa è costruita sopra TON Network (ma ne utilizza lo stesso) e aiuta TON Storage a trovare nodi ‘seed’ e TON Proxy — relay intermedi. Va notato che, a differenza della blockchain, questa tabella di hash non è un archivio sicuro — non è possibile memorizzare informazioni importanti qui.
- TON Services. Una piattaforma per servizi vari. In sostanza, è un nuovo internet sopra tutto ciò che è stato descritto. TON Network/TON Proxy, mentre la logica è nei smart contract stessi. TON Blockchain. E l'interfaccia ha URL piuttosto familiari.
- TON DNS. A proposito di URL familiari, serve anche un convertitore in indirizzi a 256 bit — per account, contratti, servizi e nodi.
- TON Payments. E qui si tocca la questione monetaria. E non si tratterà solo di gram — come con l'Ethereum, saranno possibili qualsiasi tipo di «token»; i gram saranno semplicemente la valuta «predefinita».
Questa è la prima parte che descrive il livello «tangibile» di TON — la sua parte di rete, costruita sopra protocolli tradizionali. Nella prossima parte si parlerà del «nocciolo» — il blockchain che sarà supportato dal sistema descritto successivamente. In questo modo, il mio ordine di rielaborazione differisce un po' da quello utilizzato nel documento sopra citato (che inizia immediatamente con il livello astratto).
Concetti di base
TL (Type Language). Questo è un formato binario astratto per strutture di dati arbitrarie. Viene utilizzato nel protocollo di Telegram e sarà ampiamente utilizzato in TON. Se desideri conoscerlo nel dettaglio — .
Hash (hash). La funzione che produce una trasformazione irreversibile di una struttura dati arbitraria in un singolo numero di lunghezza fissa. Nella documentazione si parla ampiamente di questa funzione .
Nodo di rete (node). Un nodo è un software che garantisce il funzionamento del sistema. In particolare, si prevede che ogni applicazione client di Telegram includa un nodo di TON. A un livello basso, i nodi hanno indirizzi IPv4/IPv6 e comunicano tramite il protocollo UDP; a un livello più alto, possiedono indirizzi astratti e implementano il protocollo ADNL (sugli indirizzi astratti e ADNL — vedi sotto). Quando si parla di alcune parti del sistema che eseguono operazioni o memorizzano dati, si intende che ciò sia fatto dai nodi di rete.
Indirizzo astratto (o semplicemente indirizzo, address). L'indirizzo di un nodo è determinato dalla sua chiave pubblica. Più precisamente, è un hash a 256 bit (SHA256) della struttura dati che contiene la chiave pubblica (il particolare algoritmo crittografico non è specificato — come esempio vengono citate le curve ellittiche e RSA-2048). Per permettere a un nodo di interagire con un altro, è necessario che conosca non solo l'indirizzo dell'altro, ma anche questa struttura dati. Teoricamente, un singolo nodo fisico può creare un numero qualsiasi di indirizzi (corrispondenti a diverse chiavi).
Successivamente, spesso viene utilizzata proprio questa combinazione: un 'prototipo' sotto forma di struttura TL (che può contenere praticamente qualsiasi dato) e un hash a 256 bit di essa, usato per l'indirizzamento.
Blockchain (blockchain). La blockchain è una struttura dati i cui elementi (blocchi) sono ordinati in una 'catena', e ogni blocco successivo contiene l'hash del blocco precedente. In questo modo si garantisce l'integrità: le modifiche possono essere effettuate solo aggiungendo nuovi blocchi.
Servizio (service). I servizi nell'ambito di TON possono essere di diversi tipi, a seconda che utilizzino o meno la blockchain. Ad esempio, uno (o più) nodi della rete possono gestire alcune richieste RPC secondo il protocollo ADNL descritto di seguito, senza creare alcuna registrazione nella blockchain, simile ai tradizionali server web. Viene anche considerata la possibilità di implementare HTTP sopra ADNL, così come la migrazione del messenger stesso a questo protocollo. Analogamente a TOR o I2P, ciò lo renderà più resistente a varie forme di blocco.
Allo stesso tempo, diversi servizi implicano sia l'interazione con la blockchain sia l'elaborazione di richieste al di fuori di essa. Ad esempio, per TON Storage — un'archiviazione di file — non è molto sensato memorizzare i file stessi nella blockchain. In essa saranno contenuti solo gli hash dei file (insieme a qualche meta-informazione su di essi), mentre i nodi specializzati della rete funzioni come 'server di file', pronti a fornire tali file ad altri nodi tramite ADNL.
Servizio fog (fog service). Si parla di alcuni servizi che implicano la decentralizzazione e la partecipazione aperta. Ad esempio, TON Proxy è un servizio che qualsiasi partecipante può supportare offrendo il proprio nodo come intermediario (proxy) che inoltra pacchetti tra altri nodi. Se lo desidera, può addebitare una tariffa stabilita — utilizzando il sistema TON Payments per microtransazioni (che, a sua volta, è anch'esso un servizio nebuloso).
ADNL: Livello di Rete Datagramma Astratto
A livello più basso, l'interazione tra i nodi avverrà tramite protocollo UDP (sebbene siano ammessi anche altri metodi).
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 che essa determina). 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 tali indirizzi, ciò gli consentirà di determinare quale chiave utilizzare per la decifratura.
Inoltre, anziché l'indirizzo del destinatario all'inizio del pacchetto dati, potremmo trovare un cosiddetto identificatore canale. In questo caso, l'elaborazione del pacchetto dipende già dagli accordi specifici tra i nodi: ad esempio, i dati inviati a un certo canale possono essere destinati a un altro nodo e devono essere reindirizzati a esso (questo è il servizio TON Proxy). Un altro caso particolare può essere l'interazione diretta tra i nodi, ma con crittografia tramite una coppia di chiavi individuali per questo canale (preparatorie formate secondo il protocollo di Diffie-Hellman).
Infine, un caso speciale è il «canale zero»: se un nodo non conosce ancora le chiavi pubbliche dei suoi «vicini», può inviare loro pacchetti senza crittografia. Questo è destinato solo all'inizializzazione: non appena i nodi inviano informazioni sulle loro chiavi, dovrebbero essere utilizzate per ulteriori interazioni.
Il protocollo descritto sopra (256 bit di identificatore del canale + contenuto del pacchetto) si chiama ADNL. La documentazione menziona la possibilità di implementare un analogo di TCP sopra di esso o un proprio strato — RLDP (Reliable Large Datagram Protocol), ma non entra nei dettagli sulla loro implementazione.
TON DHT: Tabella hash distribuita
Come in altre sistemi distribuiti, TON prevede l'implementazione di una DHT — . Più specificamente, la tabella è una Se non sei familiare con questo tipo di tabelle hash, non preoccuparti, di seguito descriverò brevemente come funzionano.
In un senso astratto, la DHT associa a chiavi a 256 bit alcuni valori binari di lunghezza arbitraria. Le chiavi nella tabella sono hash di una determinata struttura TL (le strutture stesse sono memorizzate insieme alla DHT). Questo è molto simile alla generazione degli indirizzi dei nodi — e possono effettivamente essere presenti nella DHT (ad esempio, a tale chiave potrebbe corrispondere l'indirizzo IP di un nodo corrispondente all' indirizzo astratto, se non lo nasconde). Ma in generale, i "prototipi delle chiavi" (le loro descrizioni, key descriptions) — questi sono metadati che indicano il «proprietario» della registrazione nella tabella hash (cioè la chiave pubblica di un nodo), il tipo di valore memorizzato e le regole secondo cui questa registrazione può essere successivamente modificata. Ad esempio, una regola può consentire di modificare il valore solo al proprietario — o vietare di ridurre il valore (per proteggere da attacchi di replay).
Oltre alle chiavi a 256 bit, viene introdotto il concetto di indirizzi DHT. La differenza rispetto agli indirizzi normali dei nodi è che l'indirizzo DHT è necessariamente legato all'indirizzo IP. Se un nodo non nasconde il proprio IP, può utilizzare un indirizzo normale per il DHT. Ma più spesso, per le necessità del DHT, si creerà un indirizzo separato, «semi-permanente».
Sulle 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 di esclusivo o bit a bit) tra di esse. Come nelle tabelle Kademlia, il valore corrispondente a una certa chiave deve essere memorizzato sui s nodi che hanno la distanza più breve da questa chiave (s qui — un numero relativamente piccolo).
Affinché un nodo DHT possa interagire con altri nodi simili, mantiene in memoria tabella di routing DHT — Indirizzi DHT e IP dei nodi con cui ha interagito in precedenza, raggruppati per distanza. Ci sono 256 gruppi (corrispondenti al bit più significativo nel valore della distanza — cioè i nodi a una distanza da 0 a 255 andranno in un gruppo, quelli da 256 a 65535 nel successivo, e così via). All'interno di ciascun gruppo viene mantenuto un numero limitato di "migliori" nodi (in termini di ping).
Ogni nodo deve supportare diverse operazioni: salvataggio di un valore per una chiave, ricerca di nodi e ricerca di valori. La ricerca di nodi implica la restituzione dei nodi più vicini alla chiave specificata dalla tabella di routing; 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 in DHT un valore per una chiave, invia richieste a un numero ristretto di nodi vicini a quella chiave dalla sua tabella di routing. Se tra le loro risposte non c'è il valore ricercato, ma ci sono altri indirizzi di nodi, la richiesta viene ripetuta a questi ultimi.
TON DHT può essere utilizzato per vari scopi, ad esempio — per implementare uno storage di file simile a un torrent (vedi TON Storage); per determinare gli indirizzi dei nodi che forniscono servizi specifici; per memorizzare informazioni sui proprietari degli account nella blockchain. Ma l'applicazione più importante è la rilevazione dei nodi tramite i loro indirizzi astratti. A tal fine, l'indirizzo viene usato come chiave, il cui valore deve essere trovato. Di conseguenza, la richiesta può restituire il nodo stesso (se l'indirizzo cercato era il suo indirizzo DHT semipermanente), oppure il valore sarà l'indirizzo IP e la porta per la connessione — oppure un altro indirizzo da utilizzare come tunnel intermediario.
Reti overlay in TON
Il protocollo ADNL descritto sopra prevede che qualsiasi nodo possa scambiare informazioni tra loro — anche se non necessariamente attraverso i percorsi ottimali. Si può dire che, grazie a ADNL, tutti i nodi formano un grafo globale TON (idealmente — connesso). Tuttavia, è prevista anche la possibilità di creare reti overlay — sotto-grafi all'interno di questo grafo.
All'interno di una rete di questo tipo, l'interazione avviene solo direttamente, attraverso collegamenti predefiniti tra i nodi partecipanti alla rete (tramite canali ADNL, descritti sopra). La creazione di questi collegamenti tra vicini e la ricerca degli stessi vicini è un processo automatico, volto a mantenere la connettività della rete overlay 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, arricchiti con codice di correzione degli errori, e tutti questi pezzi vengono inviati da un partecipante all'altro. In questo modo, non è necessario che un partecipante riceva completamente tutte le parti prima di inoltrarle ulteriormente nella rete.
Le reti overlay possono essere pubbliche e private. Diventare un partecipante in una rete pubblica non è difficile: bisogna trovare una struttura TL che la descriva (può essere pubblica o accessibile tramite una certa chiave nel DHT). Nel caso di una rete privata, questa struttura deve essere nota al nodo in anticipo.
To be continued
Ho deciso di suddividere la panoramica di TON in più articoli. Qui termina questa parte, mentre Sto passando a esaminare la struttura della blockchain (o meglio, delle blockchain) di cui sarà composta TON.
Fonte: habr.com
