De două săptămâni, Rusețul discută despre Telegram și situația blocării sale fără sens și necruțătoare de către Roskomnadzor. Mulți au fost afectați, dar toate acestea sunt subiecte pentru postări pe Geektimes. Pe mine m-a surprins altceva - până acum nu am văzut pe Habr nicio analiză a rețelei TON - Telegram Open Network, care urmează să fie lansată pe baza Telegramului. Mi-am dorit să completez această lipsă, deoarece este mult de studiat acolo - chiar și în absența declarațiilor oficiale despre aceasta.
Îmi amintesc - se zvonește că Telegram a lansat un ICO masiv și închis, deja strângând sume incredibile. Se presupune că în acest an va fi lansată propria criptomonedă Gram - și fiecare utilizator al Telegramului va avea automat un portofel, ceea ce în sine creează un avantaj considerabil față de alte criptomonede.
Din păcate, având în vedere că nu există declarații oficiale, mai departe mă pot baza doar pe , despre care vă avertizez imediat. Desigur, poate fi o falsificare foarte bine executată, dar nu este exclus să fie un whitepaper real al viitoarei sisteme, scris de Nikolai Durov (și scurs, probabil, de cineva dintre investitori). Dar chiar dacă este un fals, nimeni nu ne va interzice să-l studiem și să discutăm despre el, nu-i așa?
Ce spune acest document? Voi încerca să îl parafrazez în cuvintele mele, aproape conform textului, dar în română și puțin mai uman (să mă ierte Nikolai pentru tendința sa de a se lansa în matematică formală). Tineți cont că, chiar și în cazul autenticității sale, acesta este o descriere preliminară a sistemului și este foarte probabil să se schimbe până la lansarea publică.
Aflăm că, pe lângă criptomonedă, se preconizează și foarte multe altele. Să le discutăm pe rând.
- TON Blockchain. Aceasta este baza întregului sistem. Dacă nu știți deloc ce este - vă recomand să vă informați, deoarece aici vor fi multe blockchain-uri. Întrepătrunse, virtual descompuse și chiar "verticale" blockchain-uri în interiorul altor blockchain-uri. Și aici vor fi câteva termeni interesanți precum Instant Hypercube Routing și Infinite Sharding Paradigm, dar despre asta mai târziu. Și, desigur, proof-of-stake și smart contracts.
- TON P2P Network. O rețea peer-to-peer pe baza căreia va fi construită funcționarea sistemului. Despre aceasta se va discuta, în primul rând, în această parte a narațiunii.
- TON Storage. Stocare de fișiere, care va fi construită pe rețeaua peer-to-peer menționată anterior, independent de blockchain. Poate fi comparat cu torrentele.
- TON Proxy. Acesta este un serviciu destinat să crească anonimatul participanților la rețea. Orice pachet poate fi trimis nu direct, ci prin tuneluri intermediare cu criptare suplimentară — similar cu I2P sau TOR.
- TON DHT. O tabelă de hash distribuită pentru stocarea valorilor arbitrare. De asemenea, este construită pe TON Network (dar utilizează sistemul său) și ajută TON Storage să găsească nodurile „distribuitoare”, iar TON Proxy — retransmițătoarele intermediare. Dar trebuie menționat că, spre deosebire de blockchain, această tabelă de hash nu este un depozit sigur — nu este recomandat să stocați informații importante în ea.
- TON Services. O platformă pentru servicii arbitrare. Practic — este un nou internet deasupra tuturor celor menționate anterior. Schimbul de date se face prin TON Network/TON Proxy, iar logica se află în smart contractele în sine TON Blockchain. Și interfața are URL-uri destul de obișnuite.
- TON DNS. Daca tot am vorbit despre URL-uri obișnuite, avem nevoie și de un convertor din acestea în adrese de 256 de biți — pentru conturi, contracte, servicii și noduri.
- TON Payments. Și doar aici se discută despre aspectul financiar. Și nu va fi doar gram — la fel ca în cazul eterului, vor fi posibile orice „token-uri”; gramii vor fi doar valuta „implicită”.
Aceasta este prima parte care descrie nivelul „pășit” TON — partea sa de rețea construită deasupra protocoalelor tradiționale. În partea următoare se va vorbi despre „miez” — blockchain-ul, care va fi susținut de sistemul descris mai jos. Astfel, ordinea mea de relatare diferă puțin de cea utilizată în documentul menționat anterior (care începe direct cu nivelul abstract).
Noțiuni de bază
TL (Type Language). Acesta este un format binar abstract pentru structuri de date arbitrare. Este folosit în protocolul Telegram și va fi utilizat activ în TON. Dacă doriți să vă familiarizați în detaliu cu acesta — .
Hash (hash). Funcția care produce o transformare ireversibilă a unei structuri de date arbitrare într-un singur număr de lungime fixă. În documentație se discută pe scară largă despre funcția .
Nodul rețelei (node). Nodul este un software care va asigura funcționarea sistemului. În special, se preconizează că fiecare aplicație client Telegram va include un nod TON. La un nivel de bază, nodurile au adrese IPv4/IPv6 și comunică prin protocolul UDP, iar la un nivel mai înalt, dispun de adrese abstracte și implementează protocolul ADNL (despre adresele abstracte și ADNL — vezi mai jos). Când se vorbește despre faptul că anumite părți ale sistemului fac ceva sau stochează anumite date — se subînțelege că aceste lucruri sunt făcute de nodurile rețelei.
Adresa abstractă sau simplu adresă, address). Adresa unui nod este definită de cheia sa publică. Mai strict, aceasta este un hash de 256 de biți (SHA256) al structurii de date care conține cheia publică (algoritmul criptografic specific nu este precizat — ca exemplu sunt menționate curbele eliptice și RSA-2048). Pentru ca un nod să interacționeze cu altul, trebuie să cunoască nu doar adresa respectivă, ci și această structură de date. Teoretic, un nod fizic poate crea un număr nelimitat de adrese (corespunzătoare diferitelor chei).
Pentru unele utilizări se folosește exact acest tip de legătură: «modelul» sub forma unei structuri TL (care conține practic orice date), și hash-ul de 256 de biți al acesteia, folosit pentru adresare.
Blockchain (blockchain). Blockchain-ul este o structură de date, elementele (blocuri) căreia sunt ordonate într-o «lanț», și fiecare bloc următor din lanț conține hash-ul celui anterior. Astfel se atinge integritatea — modificările se pot aduce doar prin adăugarea de blocuri noi.
Serviciu (service). Serviciile în cadrul TON pot fi de diferite tipuri — în funcție de faptul dacă utilizează blockchain sau nu. De exemplu, unul (sau mai multe) din nodurile rețelei poate procesa anumite cereri RPC prin protocolul ADNL descris mai jos, fără a crea nicio înregistrare în blockchain — asemănător serverelor web tradiționale. De asemenea, se analizează posibilitatea implementării HTTP deasupra ADNL, precum și trecerea messenger-ului însuși la acest protocol. Prin analogie cu TOR sau I2P, acest lucru îl va face mai rezistent la diverse blocaje.
În același timp, o serie de servicii implică atât interacțiunea cu blockchain-ul, cât și procesarea cererilor din afara acestuia. De exemplu, pentru TON Storage — un stocare de fișiere — nu este foarte rezonabil să stochezi fișierele în blockchain. Acesta va conține doar hash-uri ale fișierelor (împreună cu unele metainformații despre acestea), iar ca „servere de fișiere” vor acționa noduri specializate ale rețelei, pregătite să le ofere altor noduri prin ADNL.
Serviciul de tip fog (fog service). Vorbim despre unele servicii care implică descentralizarea și participarea deschisă în acestea. De exemplu, TON Proxy — este un serviciu care poate fi susținut de orice participant doritor să ofere nodul său ca intermediar (proxy), care redirecționează pachete între alte noduri. Dacă dorește, acesta poate percepe o taxă stabilită de el — folosind sistemul TON Payments pentru micropagamente (care, la rândul său, este tot un serviciu de tip fog).
ADNL: Abstract Datagram Network Layer
La cel mai de bază nivel, interacțiunea între noduri se va realiza prin protocolul UDP (deși sunt acceptabile și alte variante).
Așa cum s-a menționat mai sus, pentru ca un nod să trimită un pachet altui nod, acesta trebuie să cunoască unul dintre cheile sale publice (și, prin urmare, adresa definită de aceasta). El criptează pachetul cu această cheie și adaugă la începutul pachetului o adresă de 256 de biți a destinatarului — deoarece un nod poate avea mai multe astfel de adrese, acest lucru îi va permite să determine ce cheie să folosească pentru decriptare.
În plus, în loc de adresa destinatarului la începutul pachetului de date poate fi un așa-numit identificator al canalului. În acest caz, procesarea pachetului depinde deja de acordurile specifice între noduri — de exemplu, datele trimise într-un anumit canal pot fi destinate altui nod și trebuie să fie redirecționate către acesta (aceasta este un serviciu TON Proxy). Un alt caz specific poate fi interacțiunea directă între noduri, dar cu criptarea pe o pereche individuală de chei pentru acest canal (formate anterior prin protocolul Diffie-Hellman).
În cele din urmă, un caz special este canalul „zero” - dacă un nod nu cunoaște încă cheile publice ale „vecinilor” săi, acesta poate trimite pachete fără criptare deloc. Aceasta este destinat doar inițializării - imediat ce nodurile trimite informații despre cheile lor, acestea ar trebui utilizate pentru interacțiunea ulterioară.
Protocolul descris mai sus (256 de biți de identificare a canalului + conținutul pachetului) se numește ADNL. Documentația menționează posibilitatea de implementare a unui analog TCP pe lângă acesta sau a unui strat propriu - RLDP (Reliable Large Datagram Protocol), dar nu intră în detalii despre implementarea lor.
TON DHT: Tabel de dispersie distribuit
Ca în cazul altor sisteme distribuite, TON preconizează implementarea DHT - . Mai concret - tabelul este Dacă nu ești familiarizat cu acest tip de tabele de dispersie - nu-ți face griji, voi descrie în linii mari cum sunt structurate.
În sens abstract, DHT asociază chei de 256 biți cu anumite valori binare de lungime arbitrară. În acest caz, cheile din tabel sunt hash-uri ale unei structuri TL specifice (structurile în sine sunt de asemenea stocate împreună cu DHT). Acest lucru se aseamănă foarte mult cu formarea adreselor nodurilor - și acestea pot fi de fapt prezente în DHT (de exemplu, o adresă IP a nodului corespunzător adresării abstracte) dacă acesta nu o ascunde). Dar în general, „modelele cheilor” (descrierile lor, dacă nu ascund informațiile). descrieri ale cheilor, key descriptions) - sunt metadate care indică „proprietarul” înregistrării în tabelul de dispersie (adică cheia publică a unui nod), tipul valorii stocate și regulile conform cărora această înregistrare poate fi ulterior modificată. De exemplu, regula poate permite modificarea valorii doar proprietarului - sau poate interzice modificarea valorii spre mai puțin (pentru a se proteja de atacurile de tip replay).
Pe lângă cheile de 256 biți, se introduce conceptul de adrese DHT. Diferența față de adresele obișnuite ale nodurilor este că adresa DHT este strict legată de adresa IP. Dacă un nod nu își ascunde IP-ul, el poate utiliza adresa obișnuită pentru DHT. Dar de obicei, pentru nevoile DHT se va crea o adresă separată, „semi-permanentă”.
Pe cheile și adresele DHT se introduce conceptul de distanță - în acest sens totul coincide cu tabelele — distanța dintre chei este egală cu XOR (sau exclusiv bit pe bit) dintre ele. Ca și în tabelele Kademlia, valoarea corespunzătoare unei chei anume trebuie stocată pe s noduri care au cea mai mică distanță față de această cheie (s aici — un număr relativ mic).
Pentru ca un nod DHT să poată interacționa cu alte astfel de noduri, el păstrează în memorie o tabelă de rutare DHT — adresele DHT și IP ale nodurilor cu care a interacționat anterior, grupate în funcție de distanța față de ele. Există 256 de astfel de grupuri (correspondente cu bitul cel mai semnificativ în valoarea distanței — adică nodurile la o distanță de la 0 la 255 vor cădea într-un grup, de la 256 la 65535 — în următorul, și așa mai departe). În interiorul fiecărui grup se păstrează un număr limitat de „cele mai bune” noduri (în ceea ce privește ping-ul până la ele).
Fiecare nod trebuie să susțină mai multe operațiuni: stocarea valorii pentru o cheie, căutarea nodurilor și căutarea valorilor. Căutarea nodurilor implică returnarea celor mai apropiate noduri de la tabelul de rutare pentru o cheie dată; căutarea valorilor — același lucru, cu excepția cazului în care nodul cunoaște valoarea pentru cheie (atunci pur și simplu o returnează). Prin urmare, dacă un nod dorește să găsească în DHT o valoare pentru o cheie, el trimite cereri unui număr mic de noduri apropiate de această cheie din tabelul său de rutare. Dacă printre răspunsurile lor nu se află valoarea căutată, dar există alte adrese de noduri, cererea se repetă deja la acestea.
TON DHT poate fi utilizat pentru diverse scopuri, de exemplu — pentru implementarea unui depozit de fișiere similar torrentelor (vezi TON Storage); pentru determinarea adreselor nodurilor care implementează anumite servicii; pentru stocarea informațiilor despre proprietarii de conturi în blockchain. Dar cea mai importantă aplicație este descoperirea nodurilor prin adresele lor abstracte. Pentru aceasta, adresa este utilizată ca o cheie, iar valoarea acesteia trebuie găsită. Ca rezultat al cererii, se va găsi fie nodul însuși (dacă adresa căutată a fost adresa sa DHT semi-permanentă), fie valoarea va fi IP-ul și portul pentru conectare — sau o altă adresă care trebuie utilizată ca tunel-intermediar.
Rețelele de overlay în TON
Protocolul ADNL descris mai sus permite oricărui nod să schimbe informații între ele — deși nu neapărat pe căi optime. Se poate spune că datorită ADNL, toate nodurile formează un graf global TON (în ideal — conex). Totuși, este prevăzută și posibilitatea de a crea rețele overlay — subgrafuri în interiorul acestui graf.
În cadrul unei astfel de rețele, interacțiunea se face direct — prin legături preformate între nodurile participanților rețelei (prin canalele ADNL, descrise mai sus). Formarea acestor legături între vecini și căutarea propriilor vecini sunt procese automate, menite să păstreze conectivitatea rețelei overlay și să minimizeze întârzierile în schimbul de date.
În plus, este prevăzut un mod de a răspândi rapid actualizări masive în rețea — acestea sunt împărțite în părți, completate cu cod de corectare a erorilor, iar toate aceste fragmente sunt trimise de la un participant la altul. Astfel, participantul nu trebuie să primească toate părțile înainte de a le trimite mai departe în rețea.
Rețelele overlay pot fi publice și private. A deveni participant într-o rețea publică nu este greu — trebuie să găsești o structură TL care o descrie (aceasta poate fi publică — sau disponibilă printr-o cheie specifică în DHT). În cazul unei rețele private, această structură trebuie să fie cunoscută nodului dinainte.
Continuarea urmează
Am decis să împart recenzia TON în mai multe articole. Această parte se încheie aici, iar voi trece la analiza structurii blockchain-ului (mai exact, a blockchain-urilor) din care va consta TON.
Sursa: habr.com
