Runet už dva týdny dělá hluk o Telegramu a situaci s jeho nesmyslným a nemilosrdným blokováním Roskomnadzorem. Ricochet mnohé urazil, ale to vše jsou témata pro příspěvky na Geektimes. Překvapilo mě něco jiného - na Habrém jsem ještě neviděl jedinou analýzu sítě TON, která má být vydána na základě Telegramu - Telegram Open Network. Tento nedostatek jsem chtěl vynahradit, protože je tam co studovat – i přes absenci oficiálních vyjádření k tomu.
Dovolte mi, abych vám připomněl, že existují zvěsti, že Telegram spustil velmi rozsáhlé uzavřené ICO a již v něm shromáždil neuvěřitelné částky. Předpokládá se, že letos bude spuštěna vlastní kryptoměna Gram a každý uživatel Telegramu bude mít automaticky peněženku, což samo o sobě vytváří značnou výhodu oproti ostatním kryptoměnám.
Bohužel, protože neexistují žádná oficiální prohlášení, mohu vycházet pouze z na což vás hned varuji. Samozřejmě se může ukázat jako velmi zručný padělek, ale je také možné, že se jedná o skutečný whitepaper budoucího systému, který napsal Nikolaj Durov (a pravděpodobně unikl některým z investorů). Ale i když je to padělek, nikdo nám nezakáže to studovat a diskutovat, že?
Co tento dokument říká? Pokusím se to převyprávět vlastními slovy, blízkými textu, ale v ruštině a trochu lidštěji (ať mi Nikolaj odpustí jeho sklony k formální matematice). Mějte na paměti, že i když je autentický, jedná se o návrh popisu systému a je velmi pravděpodobné, že se do doby veřejného spuštění změní.
Dozvídáme se, že kromě kryptoměny se toho má stát mnohem víc. Vezměme to popořadě.
- TON Blockchain. To je základ celého systému. Pokud opravdu nevíte, co to je - Doporučuji si to zjistit, protože blockchainů zde bude hodně. Vnořené, virtuálně fragmentované a dokonce „vertikální“ blockchainy v blocích jiných blockchainů. Objeví se také některé cool znějící výrazy jako Okamžité směrování Hypercube и Paradigma nekonečného ostření, ale o tom později. A samozřejmě proof-of-stake a smart kontrakty.
- P2P síť TON. Síť peer-to-peer, na jejímž základě bude systém postaven. O tom bude řeč především v této části příběhu.
- Úložiště TON. Souborové úložiště, které bude postaveno na výše zmíněné peer-to-peer síti bez ohledu na blockchain. Dá se srovnat s torrenty.
- TON Proxy. Jedná se o službu, jejímž účelem je zvýšit anonymitu účastníků sítě. Jakýkoli paket lze odeslat ne přímo, ale prostřednictvím zprostředkujících tunelů s dodatečným šifrováním - jako I2P nebo TOR.
- TON DHT. Distribuovaná hashovací tabulka pro ukládání libovolných hodnot. Je také postavena na vrcholu Síť TON (ale zároveň to používá on) a pomáhá Úložiště TON najít "distribuční" uzly a TON Proxy - mezilehlá relé. Je ale třeba poznamenat, že na rozdíl od blockchainu není tato hashovací tabulka bezpečným úložištěm – nelze do ní ukládat důležité informace.
- Služby TON. Platforma pro libovolné služby. Ve skutečnosti se jedná o nový internet nad rámec všeho popsaného výše. Výměna dat - přes Síť TON/TON Proxya logika je v chytrých smlouvách TON Blockchain. A rozhraní s docela známými adresami URL.
- TON DNS. Jelikož se bavíme o obvyklých URL, potřebujeme z nich i převodník na 256bitové adresy – účty, smlouvy, služby a uzly.
- Platby TON. A zde přichází na řadu otázka peněz. A nejen to bude gram - stejně jako u etheru budou možné jakékoli "žetony"; Gramy zde budou pouze „výchozí“ měnou.
Toto je první část popisující "pozemní" úroveň TON - její síťové části postavené na tradičních protokolech. V příštím díle si povíme něco o „buniči“ – blockchainu, který bude podporován níže popsaným systémem. Moje pořadí převyprávění je tedy poněkud odlišné od pořadí použitého ve výše uvedeném dokumentu (který začíná okamžitě na abstraktní úrovni).
Základní pojmy
TL (Zadejte jazyk). Je to abstraktní binární formát pro libovolné datové struktury. Používá se v protokolu Telegram a bude aktivně používán v TON. Pokud se o tom chcete dozvědět více - .
hash (hašiš). Funkce, která provádí nevratnou transformaci libovolné datové struktury na jediné číslo pevné délky. V celé dokumentaci se hodně mluví o funkci .
Síťový uzel (uzel). Uzel je software, který zajistí chod systému. Zejména se předpokládá, že každá klientská aplikace Telegram bude obsahovat uzel TON. Na nízké úrovni mají uzly adresy IPv4/IPv6 a komunikují pomocí protokolu UDP, na vyšší úrovni mají abstraktní adresy a implementovat protokol ADNL (viz níže abstraktní adresy a ADNL). Pokud jde o to, že některé části systému něco dělají nebo ukládají nějaká data, rozumí se, že to dělají síťové uzly.
Abstraktní adresa (nebo jednoduše adresu, adresa). Adresa uzlu je určena jeho veřejným klíčem. Přesněji se jedná o 256bitový hash (SHA256) z datové struktury obsahující veřejný klíč (konkrétní kryptografický algoritmus v tomto případě není specifikován - jako příklad jsou uvedeny eliptické křivky a RSA-2048). Aby mohl jeden uzel komunikovat s druhým, potřebuje znát nejen adresu toho jednoho, ale i tuto datovou strukturu. 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ý balíček: „předobraz“ ve formě struktury TL (obsahující téměř jakákoli data) a 256bitový hash z ní používaný pro adresování.
Blockchain (blockchain). Blockchain je datová struktura, prvky (bloky), které jsou seřazeny do „řetězce“, a každý další blok řetězce obsahuje hash předchozího. Tímto způsobem je dosaženo integrity - změny lze provádět pouze přidáním nových bloků.
Služba (servis). Služby v rámci TON mohou být různého typu v závislosti na tom, zda využívají blockchain či nikoliv. Například jeden (nebo mnoho) síťových uzlů může zpracovat některé požadavky RPC pomocí protokolu ADNL popsaného níže, aniž by vytvářel jakékoli záznamy v blockchainu – jako tradiční webové servery. Zvažuje se zejména možnost implementace HTTP přes ADNL a také přechod samotného messengeru na tento protokol. Analogicky s TOR nebo I2P bude odolnější vůči různému blokování.
Řada služeb přitom zahrnuje jak interakci s blockchainem, tak zpracování požadavků mimo něj. Například pro TON Storage – ukládání souborů – není příliš rozumné ukládat samotné soubory na blockchain. Bude obsahovat pouze hashe souborů (spolu s některými metainformacemi o nich) a specializované síťové uzly budou fungovat jako „souborové servery“, připravené je předávat jiným uzlům prostřednictvím ADNL.
mlhová služba (mlhová služba). Hovoříme o některých službách, které zahrnují decentralizaci a otevřenou účast na nich. Například TON Proxy je služba, kterou může podporovat každý účastník, který chce poskytnout svůj uzel jako prostředníka (proxy), který přeposílá pakety mezi jinými uzly. Na přání si za to může účtovat jím stanovený poplatek – pomocí systému TON Payments pro mikroplatby (což je zase mlžná služba).
ADNL: Síťová vrstva abstraktního datagramu
Na nejnižší úrovni bude komunikace mezi uzly probíhat přes UDP (i když jsou přijatelné i jiné možnosti).
Jak bylo uvedeno výše, aby jeden uzel mohl poslat paket druhému, musí znát jeden ze svých veřejných klíčů (a tedy adresu, kterou určuje). Tímto klíčem paket zašifruje a na začátek paketu přidá 256bitovou cílovou adresu – protože jeden uzel může mít několik takových adres, umožní mu to určit, který klíč použít k dešifrování.
Navíc místo adresy příjemce na začátku datového paketu může být tzv. identifikátor kanál. V tomto případě již zpracování paketu závisí na konkrétních dohodách mezi uzly – např. data odeslaná na určitý kanál mohou směřovat do jiného uzlu a musí na něj být přesměrována (jedná se o službu TON Proxy). Dalším speciálním případem může být interakce přímo mezi uzly, ale se šifrováním pomocí individuálního páru klíčů pro tento kanál (dříve vytvořeného pomocí protokolu Diffie-Hellman).
Konečně speciálním případem je „nulový“ kanál – pokud uzel ještě nezná veřejné klíče svých „sousedů“, může jim posílat pakety zcela bez šifrování. Toto je pouze pro inicializaci – jakmile uzly pošlou informace o svých klíčích, měly by být použity pro další interakci.
Protokol popsaný výše (256 bitů ID kanálu + obsah paketu) se nazývá ADNL. Dokumentace zmiňuje možnost implementace analogu TCP nad něj nebo jeho vlastního doplňku - RLDP (Reliable Large Datagram Protocol), ale nezabývá se podrobnostmi o jejich implementaci.
TON DHT: Distribuovaná tabulka hash
Stejně jako v případě jiných distribuovaných systémů, TON zahrnuje implementaci DHT - . Přesněji řečeno, tabulka je . Pokud tento druh hashovacích tabulek neznáte, nebojte se, pak vám zhruba popíšu, jak jsou uspořádány.
V abstraktním smyslu DHT mapuje 256bitové klíče na binární hodnoty libovolné délky. Klíče v tabulce jsou zároveň hashe z určité struktury TL (samotné struktury jsou také uloženy společně s DHT). Je to velmi podobné vytváření adres uzlů - a skutečně mohou být přítomny v DHT (například takový klíč může obsahovat IP adresu uzlu odpovídající danému abstraktní adresapokud to neskryje). Ale v obecném případě "předobrazy klíčů" (jejich popisy, klíčové popisy) jsou metadata, která označují „vlastníka“ položky v hašovací tabulce (tj. veřejný klíč nějakého uzlu), typ uložené hodnoty a pravidla, podle kterých lze tuto položku následně změnit. Pravidlo může například povolit pouze vlastníkovi změnit hodnotu - nebo zakázat změnu hodnoty dolů (pro ochranu před útoky opakovaného přehrávání).
Kromě 256bitových klíčů je představen koncept DHT adres. Rozdíl oproti běžným hostitelským adresám je ten, že DHT adresa je vázána na IP adresu. Pokud uzel svou IP neskryje, může použít běžnou adresu pro DHT. Častěji však bude pro potřeby DHT vytvořena samostatná, „semi-permanentní“ adresa.
Nad klíči a adresami DHT je představen pojem vzdálenosti - v tomto se vše shoduje s tabulkami - vzdálenost mezi klávesami je rovna XOR (bitové exkluzivní OR) od nich. Stejně jako u tabulek Kademlia musí být uložena hodnota odpovídající nějakému klíči s uzly, které mají nejmenší vzdálenost k tomuto klíči (s zde je relativně malý počet).
Aby uzel DHT mohl komunikovat s jinými takovými uzly, uchovává se v paměti Směrovací tabulka DHT - DHT a IP adresy uzlů, se kterými předtím interagoval, seskupené podle vzdálenosti k nim. Takových skupin je 256 (odpovídají nejvýznamnějšímu bitu nastavenému v hodnotě vzdálenosti - to znamená, že uzly ve vzdálenosti od 0 do 255 budou spadat do jedné skupiny, od 256 do 65535 - do další atd.). V každé skupině je uložen omezený počet "nejlepších" uzlů (pokud jde o ping na ně).
Každý uzel musí podporovat několik operací: uložení hodnoty pro klíč, vyhledávání uzlů и hledat hodnoty. Hledání uzlů implikuje vydání daného klíče uzlů, které jsou mu nejblíže ze směrovací tabulky; vyhledávání hodnot je stejné, kromě případů, kdy uzel zná hodnotu klíče (v takovém případě ji jednoduše vrátí). Pokud tedy uzel chce najít hodnotu v DHT pomocí klíče, odešle požadavky na malý počet uzlů nejblíže tomuto klíči ze své směrovací tabulky. Pokud mezi jejich odpověďmi není požadovaná hodnota, ale jsou zde jiné adresy uzlů, pak se jim požadavek opakuje.
TON DHT lze použít k různým účelům, například k implementaci úložiště souborů podobného torrentu (viz. Úložiště TON); určit adresy uzlů, které implementují určité služby; k ukládání informací o majitelích účtů v blockchainu. Ale nejdůležitější aplikací je zjišťování uzlů podle jejich abstraktních adres. K tomu slouží adresa jako klíč, jehož hodnota se má zjistit. Dotaz buď najde samotného hostitele (pokud hledaná adresa byla jeho semipermanentní DHT adresa), nebo bude hodnotou IP adresa a port, ke kterému se má připojit, nebo jiná adresa, která se použije jako zprostředkující tunel.
Překryvné sítě v TON
Výše popsaný protokol ADNL předpokládá schopnost jakýchkoli uzlů vyměňovat si mezi sebou informace – i když ne nutně optimálními způsoby. Dá se říci, že díky ADNL tvoří všechny uzly globální TON graf (ideálně spojený). Ale navíc je možné v tomto grafu vytvořit překryvné sítě - podgrafy.
V rámci takové sítě je interakce prováděna pouze přímo - prostřednictvím předem vytvořených spojení mezi uzly členů sítě (přes kanály ADNL popsané výše). Vytváření takových spojení mezi sousedy, vyhledávání samotných sousedů je automatický proces, který se snaží zachovat konektivitu překryvné sítě a minimalizovat zpoždění při výměně dat v ní.
Kromě toho existuje způsob, jak rychle distribuovat velké aktualizace vysílání v rámci sítě – jsou rozděleny na části, doplněny o kód opravy chyb a všechny tyto části jsou odesílány od jednoho účastníka k druhému. Účastník tak nemusí obdržet všechny díly, než je přeposílá dále v síti.
Překryvné sítě mohou být veřejné nebo soukromé. Stát se členem veřejné sítě není nic složitého – je potřeba najít strukturu TL, která ji popisuje (může být veřejná – nebo přístupná určitým klíčem v DHT). V případě privátní sítě musí být tato struktura uzlu známa předem.
Chcete-li se pokračovat
Recenzi TON jsem se rozhodl rozdělit do více článků. Tady tato část končí, Přejdu k úvaze o struktuře blockchainu (přesněji blockchainů), ze kterého se bude TON skládat.
Zdroj: www.habr.com