Už dvě týdny se Runeťané baví o Telegramu a situaci s jeho nesmyslnou a bezohlednou blokací ze strany Roskomnadzoru. Řada lidí byla tím zasažena, ale to všechno jsou témata na příspěvky na Geektimes. Mě ale překvapilo něco jiného – dosud jsem na Habru neviděl žádnou analýzu plánované sítě TON — Telegram Open Network, která má vyjít. Chtěl jsem tento nedostatek napravit, protože je tam co zkoumat – i přesto, že zatím nejsou žádná oficiální prohlášení.
Připomínám – kolují zvěsti, že Telegram spustil velmi rozsáhlé uzavřené ICO, ve kterém již získal neuvěřitelné částky. Předpokládá se, že ještě tento rok bude spuštěna vlastní kryptoměna Gram – a každý uživatel Telegramu automaticky dostane peněženku, což samo o sobě vytváří značnou výhodu oproti ostatním kryptoměnám.
Bohužel, protože nejsou žádná oficiální prohlášení, mohu se dále opírat pouze o , o čemž vás hned varuji. Samozřejmě, že to může být velmi umně vytvořená padělka, ale není vyloučeno, že je to – reálný whitepaper budoucího systému, napsaný Nikolajem Durovem (a pravděpodobně unikl někým z investorů). Ale i pokud je to podvrh, nikdo nám nebrání jej studovat a diskutovat o něm, že?
Co tedy tento dokument říká? Pokusím se jej převyprávět svými slovy, blízko textu, ale česky a trochu lidským způsobem (ať mi Nikolaj odpustí svou tendenci odcházet do formální matematiky). Mějte na paměti, že i v případě jeho pravosti, je to pracovní popis systému a je velmi pravděpodobné, že se změní do doby veřejného spuštění.
Zjistíme, že kromě kryptoměny se předpokládá ještě spousta dalších věcí. Pojďme na to podívat postupně.
- TON Blockchain. To je základ celého systému. Pokud vůbec nevíte, co je to — doporučuji se dozvědět, protože zde bude mnoho blockchainů. Vložené jeden do druhého, virtuálně rozdělené a dokonce „vertikální“ blockchainy uvnitř bloků dalších blockchainů. A také zde bude několik znějících termínů jako Instant Hypercube Routing a Infinite Sharding Paradigm, ale o tom později. A samozřejmě proof-of-stake a smart contracts.
- TON P2P Network. P2P síť, na jejímž základě bude systém fungovat. O té se bude hovořit především v této části vyprávění.
- TON Storage. Úložné zařízení, které bude nezávislé na blockchainu a bude postaveno na výše zmíněné P2P síti. Můžeme to přirovnat k torrentům.
- TON Proxy. To je služba, jejímž cílem je zvýšit anonymitu účastníků sítě. Jakýkoli paket lze odeslat nepřímo, ale prostřednictvím tunelů-zprostředkovatelů s dodatečným šifrováním — podobně jako I2P nebo TOR.
- TON DHT. Distribuovaná hash tabulka pro ukládání libovolných hodnot. Ta je také postavena na TON Network (ale používá jej) a pomáhá TON Storage nalezení „sdílejících“ uzlů, a TON Proxy — mezičlánkové retransmitery. Je však třeba poznamenat, že na rozdíl od blockchainu tato hash tabulka není zabezpečeným úložištěm — důležité informace v ní ukládat nelze.
- TON Services. Platforma pro různé služby. V podstatě jde o nový internet na základě všeho výše popsaného. Výměna dat — přes TON Network/TON Proxy, a logika — ve smart kontraktech samotného TON Blockchain. A rozhraní s poměrně běžnými URL.
- TON DNS. Když už byla řeč o běžných URL, potřebujeme také převodník z nich na 256-bitové adresy — účtů, kontraktů, služeb a uzlů.
- TON Payments. A zde se zas dotýkáme otázky peněz. A to nebude jen gram — stejně jako s ethereal, budou možné jakékoli „tokeny“; gramy zde budou pouze měnou „podle výchozího nastavení“.
To je první část, popisující „přístupnou“ úroveň TON — jeho síťovou část, budující se na tradičních protokolech. V další části se bude hovořit o „jádru“ — blockchainu, který bude podporován níže popsaným systémem. Tím pádem se můj způsob vyprávění trochu liší od použitého v výše zmíněném dokumentu (který začíná přímo od abstraktní úrovně).
Základní pojmy
TL (Type Language). To je abstraktní binární formát pro libovolné datové struktury. Používá se v protokolu Telegram a bude aktivně používán v TON. Pokud chcete se s ním podrobněji seznámit — .
Hash (hash). Funkce, která provádí nevratnou transformaci libovolné datové struktury na jediné číslo pevné délky. V rámci dokumentace se všude hovoří o funkci .
Uzly sítě (node). Uzl je software, který zajišťuje fungování systému. Předpokládá se, že každá klientská aplikace Telegramu bude obsahovat uzel TONu. Na nízké úrovni mají uzly IPv4/IPv6 adresy a komunikují pomocí protokolu UDP, na vyšší úrovni mají abstraktní adresy a implementují protokol ADNL (o abstraktních adresách a ADNL viz níže). Když se hovoří o tom, že některé části systému něco dělají nebo uchovávají nějaká data, znamená to, že to dělají uzly sítě.
Abstraktní adresa (nebo jednoduše adresa, address). Adresa uzlu je určena jeho veřejným klíčem. Přesněji řečeno, je to 256bitový hash (SHA256) struktury dat obsahující veřejný klíč (konkrétní kryptografický algoritmus není specifikován - jako příklad jsou uvedeny eliptické křivky a RSA-2048). Aby jeden uzel mohl interagovat s jiným, musí znát nejen adresu, ale také tuto strukturu dat. Teoreticky může jeden fyzický uzel vytvořit libovolný počet adres (odpovídajících různým klíčům).
Dále se často používá právě taková kombinace: „prototyp“ v podobě TL struktury (obsahující prakticky jakákoliv data) a 256bitový hash z ní, používaný pro adresaci.
Blockchain (blockchain). Blockchain je datová struktura, jejíž prvky (bloky) jsou uspořádány do „řetězu“ a každý následující blok řetězu obsahuje hash předchozího. Tímto způsobem se dosahuje integrity - změny mohou být prováděny pouze přidáním nových bloků.
SA-Frontend (service). Služby v rámci TON mohou být různých typů - v závislosti na tom, zda používají blockchain nebo ne. Například jeden (nebo více) uzlů sítě může zpracovávat určitá RPC požadavky podle níže popsaného protokolu ADNL, aniž by vytvářel jakékoli záznamy v blockchainu - podobně jako tradiční webové servery. Zvažuje se také možnost implementace HTTP nad ADNL a přechodu samotného messengeru na tento protokol. Podobně jako TOR nebo I2P to učiní systém odolnějším vůči různým blokacím.
Zároveň řada služeb zahrnuje interakci s blockchainem a zpracování požadavků mimo něj. Například pro TON Storage — cloudové úložiště — není příliš rozumné uchovávat samotné soubory na blockchainu. Ten bude obsahovat pouze hash souborů (spolu s nějakými metainformacemi o nich), a jako "soubory serveru" budou vystupovat specializované uzly sítě, připravené je poskytovat dalším uzlům prostřednictvím ADNL.
Mlha služba (fog service). Hovoříme o některých službách, které zahrnují decentralizaci a otevřenou účast. Například TON Proxy — to je služba, kterou může podporovat kterýkoli účastník, který chce poskytnout svůj uzel jako prostředník (proxy), přeposílající pakety mezi jinými uzly. Pokud chce, může za to účtovat stanovený poplatek — využívající systém TON Payments pro micropayments (který je také mlhavou službou).
ADNL: Abstract Datagram Network Layer
Na nejnižší úrovni bude interakce mezi uzly probíhat pomocí protokolu UDP (i když jsou povoleny i jiné varianty).
Jak bylo zmíněno výše, aby jeden uzel mohl poslat paket jinému, musí znát jeden z jeho veřejných klíčů (a tedy i adresu, kterou tento klíč určuje). Šifruje paket tímto klíčem a přidává na začátek paketu 256bitovou adresu příjemce — protože jeden uzel může mít několik takových adres, umožní mu to určit, který klíč použít pro dešifrování.
Kromě toho může místo adresy příjemce na začátku datového paketu být tzv. identifikátor kanálu. V takovém případě zpracování paketu již závisí na konkrétních dohodách mezi uzly — například data zaslaná do určitého kanálu mohou být určena jinému uzlu a měla by být jemu přesměrována (to je služba TON Proxy). Dalším zvláštním případem může být interakce přímo mezi uzly, ale se šifrováním pomocí jednotlivých párů klíčů pro tento kanál (předem vytvořenými podle protokolu Diffie-Hellman).
Nakonec existuje speciální případ „nulového“ kanálu — pokud uzel ještě nezná veřejné klíče svých „sousedů“, může jim posílat pakety úplně nešifrované. To je určeno pouze pro inicializaci — jakmile uzly pošlou informace o svých klíčích, měly by se použít pro další interakci.
Výše uvedený protokol (256bitový identifikátor kanálu + obsah paketu) se nazývá ADNL. Dokumentace zmiňuje možnost implementace analogie TCP nad ním nebo vlastní nadstavby — RLDP (Reliable Large Datagram Protocol), ale neprovidí žádné podrobnosti o jejich implementaci.
TON DHT: Distribuovaná hashovací tabulka
Jak je tomu i v případě jiných distribuovaných systémů, TON předpokládá implementaci DHT — . Konkrétně — tabulka je . Pokud nejste obeznámeni s tímto typem hashovacích tabulek — nebojte se, později přibližně popíšu, jak jsou uspořádány.
V abstraktním smyslu DHT přiřazuje k 256bitovým klíčům určité binární hodnoty libovolné délky. Klíče v tabulce jsou hashované od určité TL-struktury (samy struktury jsou také uloženy spolu s DHT). To velmi připomíná vytváření adres uzlů — a ty skutečně mohou být přítomny v DHT (například pod takovým klíčem může být umístěna IP adresa uzlu odpovídající dané abstraktní adrese, pokud ji neskrývá). Ale v obecném případě jsou „prototypy klíčů“ (jejich popisy, key descriptions) metadata, která označují „vlastníka“ záznamu v hashovací tabulce (to jest veřejný klíč nějakého uzlu), typ ukládané hodnoty a pravidla, podle kterých může být tento záznam později měněn. Například pravidlo může umožnit měnit hodnotu pouze vlastníkovi — nebo zakazovat změnu hodnoty směrem dolů (aby se chránil před replay útoky).
Kromě 256bitových klíčů se zavádí pojem DHT adres. Rozdíl oproti obvyklým adresám uzlů je v tom, že DHT adresa je nutně spojena s IP adresou. Pokud uzel neskrývá svou IP, může použít obvyklou adresu pro DHT. Častěji však pro potřeby DHT bude zavedena samostatná, „polopermanentní“ adresa.
Nad klíči a DHT adresami se zavádí pojem vzdálenosti — v tomto je vše shodné s tabulkami — vzdálenost mezi klíči je rovna XOR (bitovému exkluzivnímu NEBO) z nich. Stejně jako v tabulkách Kademlia musí být hodnota odpovídající určitému klíči uložena na s uzlech, které mají nejmenší vzdálenost k tomuto klíči (s toto je relativně malé číslo).
Aby uzel DHT mohl komunikovat s jinými takovými uzly, uchovává v paměti tabulku směrování DHT — DHT- a IP-adresy uzlů, se kterými komunikoval dříve, seskupené podle vzdálenosti k nim. Takových skupin je 256 (odpovídají nejvyššímu nastavenému bitu ve hodnotě vzdálenosti — to znamená, že uzly na vzdálenosti od 0 do 255 budou patřit do jedné skupiny, od 256 do 65535 do další atd.). V každé skupině je uchováváno omezené množství „nejlepších“ uzlů (z hlediska pingu k nim).
Každý uzel musí podporovat několik operací: ukládání hodnoty pro klíč, hledání uzlů a hledání hodnot. Hledání uzlů zahrnuje vracení nejbližších uzlů z tabulky směrování pro daný klíč; hledání hodnot je totéž, s tím rozdílem, že pokud má uzel hodnotu pro klíč (pak ji jednoduše vrátí). Pokud tedy uzel chce najít hodnotu v DHT podle klíče, posílá dotazy malému počtu nejbližších uzlů k tomuto klíči ze své tabulky směrování. Pokud v jejich odpovědích není požadovaná hodnota, ale jsou zde jiné adresy uzlů, dotaz se opakuje k nim.
TON DHT může být použito pro různé účely, například — pro realizaci souborového úložiště podobného torrentu (viz TON Storage); pro určení adres uzlů, které implementují určité služby; pro ukládání informací o vlastnících účtů v blockchainu. Ale nejdůležitější aplikace je detekce uzlů podle jejich abstraktních adres. K tomu je adresa používána jako klíč, jehož hodnotu je třeba najít. V důsledku dotazu buď najde ihned uzel (pokud byla hledaná adresa jeho polo-trvalým DHT-adresou), nebo hodnotou bude IP adresa a port pro připojení — nebo jiná adresa, kterou je třeba použít jako tunel-zprostředkovatele.
Overlayové sítě v TON
Popisovaný protokol ADNL umožňuje jakýmkoli uzlům vzájemně si vyměňovat informace — i když ne nutně optimálními cestami. Dá se říct, že díky ADNL všechny uzly tvoří globální graf TON (ideálně — souvislý). Dále je také předpokládána možnost vytvářet overlay sítě — podgrafy uvnitř tohoto grafu.
Uvnitř takové sítě probíhá interakce pouze přímo — podle předem vytvořených spojení mezi účastnickými uzly sítě (přes kanály ADNL, jak bylo uvedeno výše). Vytváření těchto spojení mezi sousedy, hledání samotných sousedů — je automatizovaný proces, který se snaží zachovat souvislost overlay sítě a minimalizovat zpoždění při výměně dat v ní.
Kromě toho je uveden způsob, jak rychle šířit velké broadcast aktualizace uvnitř sítě — ty se dělí na části, doplňují se kódem pro opravu chyb a všechny tyto kousky se přeposílají od jednoho účastníka k druhému. Takto účastník nemusí získat všechny části před tím, než je přepošle dále v síti.
Overlay sítě mohou být veřejné a soukromé. Stát se účastníkem veřejné sítě není obtížné — stačí najít TL strukturu, která ji popisuje (může být veřejná — nebo dostupná podle určitého klíče v DHT). V případě soukromé sítě by tato struktura měla být uzlu známá předem.
Pokračování příště
Rozhodl jsem se rozdělit přehled TON na několik článků. Tato část končí, a se zaměřím na strukturu blockchainu (přesněji, blockchainů), ze kterých bude TON složen.
Zdroj: habr.com
