Runet už dva týždne robí hluk o Telegrame a situácii svojim nezmyselným a nemilosrdným blokovaním Roskomnadzorom. Ricochet urazil veľa ľudí, ale toto všetko sú témy pre príspevky na Geektimes. Prekvapilo ma niečo iné - ešte som nevidel jedinú analýzu siete TON siete TON, ktorá sa plánuje vydať na základe Telegramu - Telegram Open Network. Tento nedostatok som chcel vynahradiť, lebo je tam čo študovať – aj napriek tomu, že k tomu chýbajú oficiálne vyjadrenia.
Dovoľte mi pripomenúť, že sa hovorí, že Telegram spustil veľmi rozsiahle uzavreté ICO, pričom už vyzbieral neuveriteľné množstvo peňazí. Očakáva sa, že tento rok bude spustená vlastná kryptomena Gram – a každý používateľ Telegramu bude mať automaticky peňaženku, čo samo osebe vytvára významnú výhodu oproti iným kryptomenám.
Bohužiaľ, keďže neexistujú žiadne oficiálne vyjadrenia, môžem pokračovať ďalej , na čo vás hneď upozorňujem. Samozrejme, môže sa ukázať ako veľmi zručný falzifikát, ale je tiež možné, že ide o skutočný whitepaper budúceho systému, ktorý napísal Nikolaj Durov (a pravdepodobne unikol jedným z investorov). Ale aj keď je to falošné, nikto nám nezakáže študovať a diskutovať, však?
Čo hovorí tento dokument? Pokúsim sa to prerozprávať vlastnými slovami, blízkymi textu, ale v ruštine a trochu ľudskejšie (nech mi Nikolaj odpustí jeho tendenciu ísť do formálnej matematiky). Majte na pamäti, že aj keď je to pravé, ide o návrh popisu systému a veľmi pravdepodobne sa zmení v čase verejného spustenia.
Dozvedáme sa, že okrem kryptomeny sa očakáva ešte oveľa viac. Zoberme si to pekne po poriadku.
- TON Blockchain. Toto je základ celého systému. Ak neviete, čo to je — Odporúčam si to zistiť, pretože blockchainov tu bude veľa. Vnorené do seba, virtuálne fragmentované a dokonca „vertikálne“ blockchainy v rámci blokov iných blockchainov. Objavia sa aj chladne znejúce výrazy ako napr Okamžité smerovanie hyperkocky и Paradigma nekonečného štiepenia, ale o tom neskôr. A, samozrejme, proof-of-stake a smart kontrakty.
- TON P2P sieť. Peer-to-peer sieť, na základe ktorej bude systém vybudovaný. Najprv o nej bude reč v tejto časti príbehu.
- Úložný priestor TON. Súborové úložisko, ktoré bude bez ohľadu na blockchain postavené na vyššie spomínanej peer-to-peer sieti. Dá sa to prirovnať k torrentom.
- TON Proxy. Ide o službu, ktorej účelom je zvýšiť anonymitu účastníkov siete. Akýkoľvek paket môže byť odoslaný nie priamo, ale cez sprostredkujúce tunely s dodatočným šifrovaním - ako I2P alebo TOR.
- TON DHT. Distribuovaná hašovacia tabuľka na ukladanie ľubovoľných hodnôt. Je tiež postavená na vrchu Sieť TON (ale zároveň to používa aj on) a pomáha Úložný priestor TON nájsť „distribučné“ uzly a TON Proxy — medziľahlé zosilňovače. Treba si ale uvedomiť, že na rozdiel od blockchainu táto hašovacia tabuľka nie je bezpečným úložiskom – nemôžete do nej ukladať dôležité informácie.
- Služby TON. Platforma pre zákaznícke služby. V podstate ide o nový internet nad rámec všetkého opísaného vyššie. Výmena dát - cez Sieť TON/TON Proxya logika je v inteligentných zmluvách TON Blockchain. A rozhranie s pomerne známymi adresami URL.
- TON DNS. Keďže hovoríme o známych URL, potrebujeme z nich aj konvertor na 256-bitové adresy – účty, zmluvy, služby a uzly.
- Platby TON. A tu vstupuje do hry otázka peňazí. A nebude to len tak gram — rovnako ako v prípade éteru budú možné akékoľvek „žetóny“; Gramy tu budú len „predvolenou“ menou.
Toto je prvá časť, ktorá popisuje „uzemnenú“ vrstvu TON – jej sieťovú časť postavenú na tradičných protokoloch. V ďalšej časti si povieme niečo o „soft“ – blockchaine, ktorý bude podporovaný systémom popísaným nižšie. Preto sa moje poradie prerozprávania trochu líši od poradia použitého vo vyššie uvedenom dokumente (ktorý začína okamžite na abstraktnej úrovni).
Základné pojmy
TL (Zadajte jazyk). Je to abstraktný binárny formát pre ľubovoľné dátové štruktúry. Používa sa v protokole Telegram a bude sa aktívne používať v TON. Ak sa s tým chcete podrobne zoznámiť - .
Hash (hašiš). Funkcia, ktorá vykonáva nevratnú transformáciu ľubovoľnej dátovej štruktúry na jedno číslo pevnej dĺžky. V celej dokumentácii hovoríme o funkcii .
Sieťový uzol (uzol). Uzol je softvér, ktorý zabezpečí fungovanie systému. Predovšetkým sa predpokladá, že každá klientska aplikácia Telegram bude obsahovať uzol TON. Na nízkej úrovni majú uzly adresy IPv4/IPv6 a komunikujú pomocou protokolu UDP, na vyššej úrovni majú abstraktné adresy a implementovať protokol ADNL (o abstraktných adresách a ADNL - pozri nižšie). Pokiaľ ide o to, že niektoré časti systému niečo robia alebo ukladajú nejaké dáta, rozumie sa, že to robia sieťové uzly.
Abstraktná adresa (alebo jednoducho adresa, adresa). Adresa uzla je určená jeho verejným kľúčom. Presnejšie, ide o 256-bitový hash (SHA256) dátovej štruktúry obsahujúcej verejný kľúč (konkrétny kryptografický algoritmus nie je špecifikovaný - ako príklad sú uvedené eliptické krivky a RSA-2048). Aby mohol jeden uzol komunikovať s druhým, potrebuje poznať nielen adresu toho jedného, ale aj túto dátovú štruktúru. Teoreticky môže jeden fyzický uzol vytvoriť ľubovoľný počet adries (zodpovedajúcich rôznym kľúčom).
Ďalej sa často používa práve takýto odkaz: „prototyp“ vo forme štruktúry TL (obsahujúcej takmer akékoľvek údaje) a z nej 256-bitový hash, ktorý sa používa na adresovanie.
Blockchain (blockchain). Blockchain je dátová štruktúra, prvky (bloky), ktoré sú usporiadané do „reťazca“ a každý nasledujúci blok reťazca obsahuje hash predchádzajúceho. Týmto spôsobom sa dosiahne integrita - zmeny je možné vykonať iba pridaním nových blokov.
Služba (služba). Služby v rámci TON môžu byť rôznych typov v závislosti od toho, či využívajú blockchain alebo nie. Napríklad jeden (alebo viacero) sieťových uzlov môže spracovať určité požiadavky RPC pomocou protokolu ADNL opísaného nižšie bez vytvárania akýchkoľvek záznamov v blockchaine – ako tradičné webové servery. Vrátane možnosti implementácie HTTP cez ADNL, ako aj prechodu samotného messengeru na tento protokol. Analogicky s TOR alebo I2P bude odolnejší voči rôznym blokovaniam.
Množstvo služieb zároveň zahŕňa interakciu s blockchainom a spracovanie požiadaviek mimo neho. Napríklad pre TON Storage – ukladanie súborov – nie je veľmi rozumné ukladať samotné súbory na blockchain. Bude obsahovať iba hash súborov (spolu s niektorými metainformáciami o nich) a špecializované sieťové uzly budú fungovať ako „súborové servery“, pripravené ich posielať do iných uzlov cez ADNL.
Hmlová služba (hmlová služba). Hovoríme o niektorých službách, ktoré zahŕňajú decentralizáciu a otvorenú účasť na nich. Napríklad TON Proxy je služba, ktorú môže podporovať každý účastník, ktorý chce poskytnúť svoj uzol ako sprostredkovateľa (proxy) preposielajúceho pakety medzi inými uzlami. Na želanie si za to môže účtovať ním stanovený poplatok – pomocou systému TON Payments pre mikroplatby (čo je zase služba hmly).
ADNL: Sieťová vrstva abstraktného datagramu
Na najnižšej úrovni bude komunikácia medzi uzlami prebiehať pomocou protokolu UDP (aj keď sú prijateľné aj iné možnosti).
Ako už bolo spomenuté vyššie, aby mohol jeden uzol poslať paket druhému, musí poznať jeden z jeho verejných kľúčov (a teda adresu, ktorú definuje). Týmto kľúčom zašifruje paket a na začiatok paketu pridá 256-bitovú cieľovú adresu – keďže jeden uzol môže mať niekoľko týchto adries, umožní mu to určiť, ktorý kľúč použiť na dešifrovanie.
Navyše namiesto adresy príjemcu môže začiatok dátového paketu obsahovať tzv. identifikátor kanál. V tomto prípade spracovanie paketu už závisí od konkrétnych dohôd medzi uzlami - napríklad dáta odoslané na určitý kanál môžu byť určené pre iný uzol a musia sa mu preposlať (toto je služba TON Proxy). Ďalším špeciálnym prípadom môže byť interakcia priamo medzi uzlami, ale so šifrovaním pomocou individuálneho páru kľúčov pre tento kanál (vopred vygenerovaného pomocou protokolu Diffie-Hellman).
Nakoniec, špeciálnym prípadom je „nulový“ kanál – ak uzol ešte nepozná verejné kľúče svojich „susedov“, môže im posielať pakety bez šifrovania. Toto je určené len na inicializáciu – keď uzly pošlú informácie o svojich kľúčoch, mali by sa použiť na ďalšiu komunikáciu.
Vyššie opísaný protokol (256 bitov identifikátor kanála + obsah paketu) sa nazýva ADNL. Dokumentácia uvádza možnosť implementácie analógu TCP nad ním alebo jeho vlastného doplnku - RLDP (Reliable Large Datagram Protocol), ale nezachádza do podrobností o ich implementácii.
TON DHT: Distribuovaná tabuľka hash
Ako je to v prípade iných distribuovaných systémov, TON zahŕňa implementáciu DHT - . Presnejšie povedané, tabuľka je . Ak tento typ hašovacej tabuľky nepoznáte, nebojte sa, nižšie zhruba opíšem, ako fungujú.
V abstraktnom zmysle DHT mapuje 256-bitové kľúče na binárne hodnoty ľubovoľnej dĺžky. V tomto prípade sú kľúčmi v tabuľke hash z určitej štruktúry TL (samotné štruktúry sú tiež uložené spolu s DHT). Je to veľmi podobné vytváraniu adries uzlov – a skutočne môžu byť prítomné v DHT (napríklad pomocou takého kľúča IP adresa uzla zodpovedajúca danému abstraktná adresa, ak to neskrýva). Ale vo všeobecnom prípade „prototypy kľúčov“ (ich popisy, kľúčové popisy) sú metadáta, ktoré označujú „vlastníka“ položky v hašovacej tabuľke (t. j. verejný kľúč nejakého uzla), typ uloženej hodnoty a pravidlá, podľa ktorých je možné túto položku následne zmeniť. Pravidlo môže napríklad povoliť zmenu hodnoty iba vlastníkovi alebo zakázať zmenu hodnoty smerom nadol (na ochranu pred opakovanými útokmi).
Okrem 256-bitových kľúčov sa zavádza aj koncept DHT adries. Rozdiel oproti bežným hostiteľským adresám je v tom, že DHT adresa je nevyhnutne spojená s IP adresou. Ak uzol neskryje svoju IP, môže použiť bežnú adresu pre DHT. Častejšie sa však pre potreby DHT vytvorí samostatná „polostála“ adresa.
Pojem vzdialenosti je predstavený nad kľúčmi a adresami DHT - v tomto sa všetko zhoduje s tabuľkami — vzdialenosť medzi klávesmi sa rovná ich XOR (bitové exkluzívne OR). Rovnako ako v tabuľkách Kademlia musí byť uložená hodnota zodpovedajúca určitému kľúču s uzly, ktoré majú najkratšiu vzdialenosť k tomuto kľúču (s tu je relatívne malý počet).
Aby uzol DHT mohol komunikovať s inými takýmito uzlami, uchováva sa v pamäti Smerovacia tabuľka DHT — DHT a IP adresy uzlov, s ktorými predtým interagoval, zoskupené podľa vzdialenosti k nim. Existuje 256 takýchto skupín (zodpovedajú najvýznamnejšiemu bitu nastavenému v hodnote vzdialenosti - to znamená, že uzly vo vzdialenosti od 0 do 255 budú spadať do jednej skupiny, od 256 do 65535 - do ďalšej atď.). V rámci každej skupiny je uložený obmedzený počet „najlepších“ uzlov (pokiaľ ide o ping na ne).
Každý uzol musí podporovať niekoľko operácií: uloženie hodnoty pre kľúč, vyhľadávanie uzlov и hľadať hodnoty. Vyhľadávanie uzlov zahŕňa vydanie, na základe daného kľúča, uzlov, ktoré sú mu najbližšie zo smerovacej tabuľky; vyhľadávanie hodnôt je rovnaké, okrem prípadov, keď uzol pozná hodnotu kľúča (potom ju len vráti). Podobne, ak uzol chce nájsť hodnotu podľa kľúča v DHT, pošle požiadavky na malý počet uzlov, ktoré sú najbližšie k tomuto kľúču zo svojej smerovacej tabuľky. Ak sa požadovaná hodnota nenachádza medzi ich odpoveďami, ale sú tam iné adresy uzla, potom sa im požiadavka zopakuje.
TON DHT možno použiť na rôzne účely, napríklad na implementáciu úložiska súborov podobného torrentu (pozri. Úložný priestor TON); určiť adresy uzlov, ktoré implementujú určité služby; na ukladanie informácií o vlastníkoch účtov na blockchaine. Najdôležitejšou aplikáciou je však zisťovanie uzlov podľa ich abstraktných adries. Na tento účel sa adresa používa ako kľúč, ktorého hodnotu je potrebné nájsť. V dôsledku požiadavky sa buď nájde samotný uzol (ak bola hľadaná adresa jeho semipermanentná DHT adresa), alebo bude hodnotou IP adresa a port pre pripojenie - alebo iná adresa, ktorá by mala byť použitá ako sprostredkovateľský tunel.
Prekryvné siete v TON
Vyššie opísaný protokol ADNL predpokladá schopnosť akýchkoľvek uzlov vymieňať si medzi sebou informácie – aj keď nie nevyhnutne optimálnym spôsobom. Dá sa povedať, že vďaka ADNL tvoria všetky uzly globálny TON graf (ideálne prepojené). Okrem toho je však možné v tomto grafe vytvárať prekryvné siete - podgrafy.
V rámci takejto siete sa interakcia uskutočňuje iba priamo - prostredníctvom vopred vytvorených spojení medzi uzlami zapojenými do siete (cez ADNL kanály opísané vyššie). Vytváranie takýchto spojení medzi susedmi, vyhľadávanie samotných susedov, je automatický proces, ktorý sa snaží zachovať konektivitu prekryvnej siete a minimalizovať oneskorenia pri výmene dát v nej.
Okrem toho existuje spôsob rýchlej distribúcie veľkých aktualizácií vysielania v rámci siete – sú rozdelené na časti, doplnené o kód na opravu chýb a všetky tieto časti sa posielajú od jedného účastníka k druhému. Účastník teda nemusí úplne získať všetky diely pred ich odoslaním ďalej po sieti.
Prekryvné siete môžu byť verejné alebo súkromné. Stať sa členom verejnej siete nie je ťažké - musíte nájsť štruktúru TL, ktorá ju popisuje (môže byť verejná alebo prístupná určitým kľúčom v DHT). V prípade súkromnej siete musí byť táto štruktúra uzlu známa vopred.
Ak sa chcete pokračovať
Rozhodol som sa rozdeliť recenziu TON do niekoľkých článkov. Tu táto časť končí a Prejdem k úvahe o štruktúre blockchainu (presnejšie blockchainov), z ktorých bude TON pozostávať.
Zdroj: hab.com
