Już od dwóch tygodni Runet huczy na temat Telegramu i sytuacji z jego bezsensowną i bezwzględną blokadą przez Roskomnadzor. Ricochetem odczuli to wielu, ale to wszystko — tematy na posty na Geektimes. Mnie jednak zaskoczyło coś innego — wciąż nie widziałem na Habrze żadnej analizy zaplanowanego wydania sieci TON — Telegram Open Network, opartej na Telegramie. Chciałem to uzupełnić, ponieważ jest to naprawdę warte zbadania — nawet pomimo braku oficjalnych oświadczeń na ten temat.
Przypominam — krążą plotki, że Telegram uruchomił bardzo dużą zamkniętą ICO, zbierając już niewiarygodne sumy. Zakłada się, że już w tym roku zostanie uruchomiona własna kryptowaluta Gram — a każdy użytkownik Telegramu automatycznie dostanie portfel, co samo w sobie stwarza dużą przewagę nad innymi kryptowalutami.
Niestety, ponieważ brak jest oficjalnych oświadczeń, mogę się teraz opierać tylko na , o czym od razu was uprzedzam. Oczywiście, może to być bardzo zmyślona podróbka, ale nie można wykluczyć, że to jest rzeczywisty whitepaper przyszłego systemu, napisany przez Nikolaja Durova (i prawdopodobnie wycieknięty przez kogoś z inwestorów). Ale nawet jeśli to fałszywka, nikt nie zabroni nam tego badać i dyskutować, prawda?
Co więc mówi ten dokument? Postaram się streścić go swoimi słowami, blisko tekstu, ale po polsku i nieco bardziej ludzkimi słowami (niech mi wybaczy Nikolaj za jego tendencję do formalnej matematyki). Miejcie na uwadze, że nawet w przypadku jego autentyczności, jest to szkicowy opis systemu i najprawdopodobniej zmieni się do momentu publicznego uruchomienia.
Dowiadujemy się, że oprócz kryptowaluty przewiduje się jeszcze bardzo, bardzo wiele innych rzeczy. Rozłóżmy to w kolejności.
- TON Blockchain. To podstawa całego systemu. Jeśli nie wiecie, co to jest — polecam się zapoznać, ponieważ będzie tutaj wiele blockhainów. Zagnieżdżone jeden w drugi, wirtualnie podzielone, a nawet „pionowe” blockhainy wewnątrz blockhainów innych blockhainów. A także będą pojawiać się kilka świetnie brzmiących terminów, takich jak Instant Hypercube Routing i Infinite Sharding Paradigm, ale o tym później. I oczywiście, proof-of-stake oraz inteligentne kontrakty.
- TON P2P Network. Sieć peer-to-peer, na której będzie oparta praca systemu. O tym będzie mowa w tej części narracji.
- TON Storage. System plików, które będzie zbudowane na wspomnianej wcześniej sieci peer-to-peer, niezależnie od blockchaina. Można to porównać do torrentów.
- TON Proxy. Jest to usługa, której celem jest zwiększenie anonimowości uczestników sieci. Każdy pakiet może być wysyłany nie bezpośrednio, lecz przez pośredniczące tunele z dodatkowym szyfrowaniem — podobnie jak w przypadku I2P lub TOR.
- TON DHT. Rozproszona tablica haszy do przechowywania dowolnych wartości. Jest ona również zbudowana na TON Network (ale używa tej samej technologii) i pomaga TON Storage znajdować „udostępniające” węzły, a TON Proxy — pośrednich retranslatorów. Warto jednak zaznaczyć, że w przeciwieństwie do blockchaina, ta tablica haszy nie jest bezpiecznym magazynem — nie należy przechowywać w niej ważnych informacji.
- TON Services. Platforma dla różnych usług. W zasadzie jest to nowy internet oparty na wszystkim powyższym. Wymiana danych odbywa się przez TON Network/TON Proxy, a logika opiera się na smart kontraktach tego TON Blockchain. I interfejs z dość znajomymi adresami URL.
- TON DNS. Skoro już mówimy o znajomych adresach URL, potrzebny jest także konwerter z nich na 256-bitowe adresy — konta, kontrakty, usługi i węzły.
- TON Payments. I tutaj zaczyna się kwestia finansowa. Będzie to nie tylko gram — jak w przypadku Etheru, będą możliwe wszelkie „tokeny”; gramy będą jedynie walutą „domyślną”.
To pierwsza część, opisująca „przyziemny” poziom TON — jego część sieciową, budującą się na tradycyjnych protokołach. W następnej części mowa będzie o „miękiszu” — blockchainie, który będzie wspierany przez opisaną poniżej system. W ten sposób moje podejście do narracji nieco różni się od tego użytego w wspomnianym dokumencie (który zaczyna się od razu od poziomu abstrakcyjnego).
Podstawowe pojęcia
TL (Type Language). To abstrakcyjny format binarny dla dowolnych struktur danych. Jest używany w protokole Telegramu i będzie aktywnie wykorzystywany w TON. Jeśli chcesz dokładnie się z nim zapoznać — .
Hash (hash). Funkcja, która dokonuje nieodwracalnej transformacji dowolnej struktury danych w pojedynczą liczbę o stałej długości. W dokumentacji odwołuje się do funkcji .
Węzeł sieci (node). Węzeł to oprogramowanie, które zapewnia działanie systemu. W szczególności zakłada się, że każda aplikacja kliencka Telegramu będzie zawierała węzeł TON’a. Na niskim poziomie węzły mają adresy IPv4/IPv6 i komunikują się za pomocą protokołu UDP, na wyższym poziomie mają adresy abstrakcyjne i realizują protokół ADNL (o adresach abstrakcyjnych i ADNL — zobacz poniżej). Kiedy mówimy, że niektóre części systemu coś robią lub przechowują dane — rozumiemy, że robią to węzły sieci.
Adres abstrakcyjny (lub po prostu adres, address). Adres węzła określa jego klucz publiczny. Ścisłej mówiąc — to 256-bitowy hash (SHA256) struktury danych zawierającej klucz publiczny (konkretny algorytm kryptograficzny nie jest określony — przykładami są krzywe eliptyczne i RSA-2048). Aby jeden węzeł mógł komunikować się z innym, musi znać nie tylko adres tego drugiego, ale także tę strukturę danych. Teoretycznie jeden fizyczny węzeł może stworzyć dowolną liczbę adresów (odpowiadających różnym kluczom).
Często używa się takiego połączenia: „prototyp” w postaci struktury TL (zawierającej praktycznie dowolne dane), i 256-bitowy hash z niej, używany do adresowania.
Blockchain (blockchain). Blockchain to struktura danych, której elementy (bloki) są uporządkowane w „łańcuch”, a każdy następny blok łańcucha zawiera hash poprzedniego. W ten sposób osiągana jest integralność — zmiany mogą być wprowadzane tylko przez dodanie nowych bloków.
Serwis (service). Usługi w ramach TON mogą mieć różne typy — w zależności od tego, czy używają blockchaina, czy nie. Na przykład jeden (lub wiele) węzłów sieci może obsługiwać pewne zapytania RPC zgodnie z opisanym poniżej protokołem ADNL, nie tworząc żadnych zapisów w blockchainie — podobnie jak tradycyjne serwery WWW. Rozważa się również możliwość wdrożenia HTTP nad ADNL, a także przejście samego komunikatora na ten protokół. Podobnie jak w przypadku TOR lub I2P, uczyni to go bardziej odpornym na różne blokady.
Jednocześnie niektóre usługi zakładają zarówno interakcję z blockchainem, jak i przetwarzanie zapytań poza nim. Na przykład w przypadku TON Storage — magazynu plików — przechowywanie samych plików w blockchainie nie ma sensu. Będą w nim jedynie zawarte hashe plików (razem z pewnymi informacjami meta na ich temat), a jako «serwery plikowe» będą występować wyspecjalizowane węzły sieci, gotowe do udostępniania ich innym węzłom przez ADNL.
Usługa mgły (fog service). Mowa o niektórych usługach, które zakładają decentralizację i otwarte uczestnictwo. Na przykład TON Proxy — to usługa, którą może wspierać każdy uczestnik, który chce udostępnić swój węzeł jako pośrednika (proxy), przesyłającego pakiety między innymi węzłami. W razie chęci może pobierać ustaloną przez siebie opłatę — korzystając z systemu TON Payments do mikropłatności (który z kolei również jest usługą mgły).
ADNL: Abstrakcyjna warstwa sieci datagramów
Na najniższym poziomie interakcja między węzłami będzie odbywać się za pomocą protokołu UDP (chociaż dopuszczalne są inne opcje).
Jak wspomniano wcześniej, aby jeden węzeł mógł wysłać pakiet do drugiego, musi znać jeden z jego kluczy publicznych (a tym samym adres przypisany do niego). Szyfruje pakiet tym kluczem i dodaje na początku pakietu 256-bitowy adres odbiorcy — ponieważ jeden węzeł może mieć kilka takich adresów, pozwoli to określić, który klucz użyć do odszyfrowania.
Ponadto, zamiast adresu odbiorcy, na początku pakietu danych może znajdować się tzw. identyfikator kanału. W takim przypadku przetwarzanie pakietu zależy od konkretnych ustaleń między węzłami — na przykład, dane wysłane do określonego kanału mogą być przeznaczone dla innego węzła i powinny być do niego przekazywane (to jest usługa TON Proxy). Inny szczególny przypadek może być bezpośrednia interakcja między węzłami, ale z szyfrowaniem za pomocą indywidualnej pary kluczy dla tego kanału (wcześniej utworzonej zgodnie z protokołem Diffiego-Hellmana).
W końcu szczególnym przypadkiem jest »zerowy« kanał – jeśli węzeł jeszcze nie zna publicznych kluczy swoich »sąsiadów«, może wysyłać im pakiety bez szyfrowania. To jest przeznaczone tylko do inicjalizacji – gdy węzły prześlą informacje o swoich kluczach, powinny być one użyte do dalszej interakcji.
Opisany powyżej protokół (256-bitowy identyfikator kanału + zawartość pakietu) nazywa się ADNL. Dokumentacja wspomina o możliwości realizacji analogowego TCP na jego bazie lub własnej nakładki – RLDP (Reliable Large Datagram Protocol), ale nie wchodzi w szczegóły dotyczące ich implementacji.
TON DHT: Rozproszona tabela haszująca
Jak w przypadku innych rozproszonych systemów, TON przewiduje implementację DHT – . Bardziej konkretnie – tabela jest . Jeśli nie znasz tego typu tabel haszujących – nie martw się, poniżej w skrócie opiszę, jak one działają.
W abstrakcyjnym sensie DHT przypisuje 256-bitowym kluczom pewne binarne wartości o dowolnej długości. Klucze w tabeli to hashe określonej struktury TL (same struktury również są przechowywane razem z DHT). To bardzo przypomina tworzenie adresów węzłów – i mogą one rzeczywiście znajdować się w DHT (na przykład pod takim kluczem może znajdować się adres IP węzła odpowiadającego zadanemu abstrakcyjnemu adresowi, jeśli nie ukrywa go). W ogólnym przypadku „wzory kluczy” (ich opisy, key descriptions) – to metadane, które wskazują na „właściciela” wpisu w tabeli haszującej (tj. publiczny klucz jakiegoś węzła), typ przechowywanej wartości oraz zasady, zgodnie z którymi ten wpis może później być zmieniany. Na przykład zasada może zezwalać na zmianę wartości tylko właścicielowi – lub zabraniać zmiany wartości w dół (aby chronić przed atakami powtarzającymi).
Oprócz 256-bitowych kluczy wprowadza się pojęcie adresów DHT. Różnica z zwykłymi adresami węzłów polega na tym, że adres DHT zawsze jest związany z adresem IP. Jeśli węzeł nie ukrywa swojego adresu IP, może używać zwykłego adresu dla DHT. Częściej jednak dla potrzeb DHT zakładany jest osobny, „pół-stały” adres.
Wprowadzane są pojęcia odległości między kluczami a adresami DHT – w tym wszystko pokrywa się z tabelami. — odległość między kluczami to XOR (bitowe wykluczające OR) tych kluczy. Podobnie jak w tabelach Kademlia, wartość odpowiadająca pewnemu kluczowi musi być przechowywana na s węzłach, które mają najmniejszą odległość do tego klucza (s tutaj — stosunkowo niewielka liczba).
Aby węzeł DHT mógł współpracować z innymi takimi węzłami, przechowuje w pamięci tabelę routingu DHT — adresy DHT i IP węzłów, z którymi wcześniej współpracował, pogrupowane według odległości do nich. Jest 256 takich grup (odpowiadają najstarszemu ustalonemu bitowi w wartościach odległości — to znaczy węzły w odległości od 0 do 255 znajdą się w jednej grupie, od 256 do 65535 — w następnej, itp.). W obrębie każdej grupy przechowywana jest ograniczona liczba "najlepszych" węzłów (w kontekście pinga do nich).
Każdy węzeł musi obsługiwać kilka operacji: zapisywanie wartości dla klucza, wyszukiwanie węzłów i wyszukiwanie wartości. Wyszukiwanie węzłów oznacza wydanie w obrębie określonego klucza najbliższych do niego węzłów z tabeli routingu; wyszukiwanie wartości — to samo, z wyjątkiem sytuacji, gdy węzeł zna wartość dla klucza (wtedy po prostu ją zwraca). Odpowiednio, jeśli węzeł chce znaleźć w DHT wartość dla klucza, wysyła zapytania do niewielkiej liczby najbliższych do tego klucza węzłów z tabeli routingu. Jeśli wśród ich odpowiedzi nie ma żądanej wartości, ale są inne adresy węzłów, zapytanie jest powtarzane już do nich.
TON DHT może być używane do różnych celów, na przykład — do realizacji przechowywania plików podobnego do torrenta (zob. TON Storage); do określania adresów węzłów realizujących określone usługi; do przechowywania informacji o właścicielach kont w blockchainie. Ale najważniejsze zastosowanie to odkrywanie węzłów według ich abstrakcyjnych adresów. W tym celu adres jest używany jako klucz, którego wartość należy znaleźć. W wyniku żądania albo znajdzie się sam węzeł (jeśli poszukiwany adres był jego półstałym adresem DHT), albo wartością okaże się adres IP i port do połączenia — lub inny adres, który należy wykorzystać jako tunel pośredniczący.
Sieci nakładkowe w TON
Opisany powyżej protokół ADNL umożliwia dowolnym węzłom wymianę informacji między sobą — wprawdzie nie zawsze optymalnymi ścieżkami. Można powiedzieć, że dzięki ADNL wszystkie węzły tworzą globalny graf TON (w idealnym przypadku — spójny). Dodatkowo przewidziano możliwość tworzenia sieci nakładkowych — podgrafów w obrębie tego grafu.
Wewnętrznie w takiej sieci interakcja odbywa się tylko bezpośrednio — przez uprzednio utworzone połączenia między węzłami uczestniczącymi w sieci (przez kanały ADNL, opisane powyżej). Tworzenie takich połączeń między sąsiadami, wyszukiwanie samych sąsiadów — to proces automatyczny, mający na celu zachowanie spójności sieci nakładkowej oraz minimalizację opóźnień przy wymianie danych w niej.
Ponadto przewidziano sposób szybkiego rozpowszechniania dużych aktualizacji rozgłoszeniowych w obrębie sieci — są one dzielone na części, uzupełniane kodem korekcyjnym błędów, a wszystkie te fragmenty są przesyłane od jednego uczestnika do drugiego. W ten sposób uczestnik nie musi otrzymać wszystkich części, zanim przekaże je dalej w sieci.
Sieci nakładkowe mogą być publiczne lub prywatne. Dołączenie do publicznej sieci nie jest trudne — wystarczy znaleźć strukturę TL, która ją opisuje (może być publiczna — lub dostępna za pomocą określonego klucza w DHT). W przypadku prywatnej sieci ta struktura musi być znana węzłowi z wyprzedzeniem.
Ciąg dalszy nastąpi
Postanowiłem podzielić przegląd TON na kilka artykułów. Ta część się kończy, a przechodzę do omówienia struktury blockchaina (a dokładniej — blockchainów), z których będzie się składał TON.
Źródło: habr.com
