Вече две седмици Рунет говори за Telegram и ситуацията с безсмисленото и безмилостно блокиране от Роскомнадзор. Рикошетът засегна много хора, но всичко това са теми за постове в Geektimes. Мен обаче ме изненада нещо друго - все още не съм виждал на Хабра нито един анализ на планираната за пускане мрежа TON - Telegram Open Network. Исках да попълня този недостиг, тъй като има какво да се изучава там, дори и при отсъствието на официални изявления за него.
Напомням - разпространяват се слухове, че Telegram е стартирал много мащабно закрито ICO, вече събрало невероятни суми. Предполага се, че вече тази година ще бъде пусната собствена криптовалута Gram - и на всеки потребител на Телеграм автоматично ще бъде даден портфейл, което само по себе си създава значително предимство пред останалите криптовалути.
За съжаление, тъй като официалните изявления са липсващи, по-далеч мога да се основавам само на , за което ви предупреждавам веднага. Разбира се, той може да се окаже много умела фалшификация, но не е изключено и да е истинският whitepaper на бъдещата система, написан от Николай Дуров (и вероятно изтекъл от някой инвеститор). Но дори и да е фейк, никой не може да ни забрани да го проучим и обсъдим, нали?
Какво се казва в този документ? Ще опитам да преразкажа с мои думи, близо до текста, но на български и малко по-човешки (дано Николай ми прости за склонността си към формалната математика). Имайте предвид, че дори в случай на неговата автентичност, това е черново описание на системата и е много вероятно да се промени до момента на публичния старт.
Разбираме, че освен криптовалутата, се предполага да има още много и интересни неща. Нека да разгледаме по-подробно.
- TON Blockchain. Това е основата на цялата система. Ако изобщо не знаете какво е — препоръчвам да се запознаете, тъй като тук ще има много блокчейни. Вложени един в друг, виртуално разпънати и дори "вертикални" блокчейни в блокове на други блокчейни. Освен това тук ще има няколко готини термина, като Instant Hypercube Routing и Infinite Sharding Paradigm, но за това по-късно. И, разбира се, proof-of-stake и смарт-контракти.
- TON P2P Network. Пиринговата мрежа, на основата на която ще бъде построена работата на системата. За нея ще се говори най-напред в тази част на повествованието.
- TON Хранилище. Файлово хранилище, което независимо от блокчейна ще бъде построено на горепосочената пирингова мрежа. Може да се сравни с торенти.
- TON Прокси. Това е услуга, чиято цел е да увеличи анонимността на участниците в мрежата. Всеки пакет може да бъде изпратен не директно, а през посреднически тунели с допълнително криптиране — подобно на I2P или TOR.
- TON DHT. Разпределена хеш-таблица за съхраняване на произволни стойности. Тя също е изградена върху TON Мрежа (но същевременно използва самата тя) и помага TON Хранилище да се намерят «раздаващи» възли, а TON Прокси — междинни релейни възли. Но е важно да се отбележи, че, за разлика от блокчейна, тази хеш-таблица не е защитено хранилище — не трябва да се съхранява важна информация в нея.
- TON Услуги. Платформа за произволни услуги. По същество — това е нов интернет върху всичко описано по-горе. Обменът на данни — чрез TON Мрежа/TON Прокси, а логиката — в смарт договорите на самия TON Blockchain. И интерфейс с доста познати URL адреси.
- TON DNS. След като става дума за познатите URL адреси, необходим е и преобразувател от тях в 256-битови адреси — на сметки, договори, услуги и възли.
- TON Плащания. И тук е моментът, в който се засяга паричният въпрос. И това няма да бъде само gram — както с ефира, ще бъдат възможни всякакви «токени»; грамовете тук ще бъдат просто валута «по подразбиране».
Това е първата част, описваща «приземения» слой на TON — неговата мрежова част, изградена върху традиционни протоколи. В следващата част ще стане дума за «сърцевината» — блокчейн, който ще бъде поддържан от описаната по-долу система. По този начин, моят ред на предаване е малко по-различен от използвания в гореспоменатия документ (който започва направо с абстрактното ниво).
Основни понятия
TL (Тип Язик). Това е абстрактен бинарен формат за произволни структури от данни. Той се използва в протокола на Телеграм и ще бъде активно използван в TON. Ако искате да се запознаете подробно с него — .
Хеш (hash). Функция, която извършва необратима трансформация на произволна структура от данни в единно число с фиксирана дължина. В рамките на документацията се говори за функцията .
Възел на мрежата (node). Възелът е софтуер, който осигурява функционирането на системата. По-специално, предполага се, че всяко клиентско приложение на Telegram ще включва възел на TON. На ниско ниво възлите имат IPv4/IPv6 адреси и комуникират по протокол UDP, а на по-високото ниво разполагат с абстрактни адреси и реализират протокол ADNL (за абстрактните адреси и ADNL — вижте по-долу). Когато се говори за това, че части от системата извършват действия или съхраняват данни — се подразбира, че това се извършва от мрежовите възли.
Абстрактният адрес (или просто адрес, address). Адресът на възела се определя от неговия публичен ключ. По-точно — това е 256-битов хеш (SHA256) от структурата на данни, съдържаща публичния ключ (конкретният криптографски алгоритъм не се уточнява — за пример се посочват елиптични криви и RSA-2048). За да може един възел да взаимодейства с друг, той трябва да знае не само адреса на другия, но и тази структура на данни. Теоретично един физически възел може да създаде произволен брой адреси (съответстващи на различни ключове).
По-нататък често се използва именно такава връзка: „прототип“ под формата на TL-структура (съдържаща практически всякакви данни) и 256-битов хеш от нея, използван за адресиране.
Блокчейн (blockchain). Блокчейнът е структура на данни, чиито елементи (блокове) са подредени в „верига“, и всеки следващ блок в веригата съдържа хеш на предишния. По този начин се постига цялостност — промените могат да се правят само чрез добавяне на нови блокове.
Сервиз (service). Сервисите в рамките на TON могат да бъдат от различни типове — в зависимост от това дали използват блокчейн или не. Например, един (или множество) от възлите в мрежата може да обработва определени RPC заявки по описания по-долу протокол ADNL, без да създава никакви записи в блокчейна — подобно на традиционните уеб сървъри. Включително се разглежда възможността за реализиране на HTTP върху ADNL, както и преминаването на самия мессенджър на този протокол. По аналогия с TOR или I2P, това ще го направи по-устойчив на различни блокировки.
В същото време редица услуги предвиждат взаимодействие както с блокчейна, така и с обработка на заявки извън него. Например, за TON Storage — файловото хранилище — не е особено разумно да се съхраняват самите файлове в блокчейна. В него ще бъдат записани само хешовете на файловете (заедно с някаква метаинформация за тях), а специализираните възли в мрежата, готови да ги предоставят на другите възли по ADNL, ще действат като "файлови сървъри".
Мъглив сервиз (fog service). Става въпрос за някои услуги, които предвиждат децентрализация и открито участие в тях. Например, TON Proxy е услуга, която може да поддържа всеки участник, желаещ да предостави своя възел като посредник (прокси), предаващ пакети между други възли. При желание той може да събира такса за това — използвайки системата TON Payments за микроплатежи (която, от своя страна, също е мъглив сервиз).
ADNL: Abstract Datagram Network Layer
На най-ниското ниво взаимодействието между възлите ще се осъществява по протокола UDP (въпреки че са допустими и други варианти).
Както беше споменато по-горе, за да може един възел да изпрати пакет на друг, той трябва да знае един от публичните му ключове (а следователно и адреса, който той определя). Той криптира пакета с този ключ и добавя в началото на пакета 256-битовия адрес на получателя — тъй като един възел може да притежава няколко такива адреса, това ще му позволи да определи кой ключ да използва за декриптиране.
Освен това, вместо адреса на получателя в началото на пакета от данни може да съществува т.н. идентификатор канал. В такъв случай обработката на пакета вече зависи от конкретните споразумения между възлите — например, данните, изпратени в определен канал, могат да бъдат предназначени за друг възел и трябва да бъдат пренасочени към него (това е услугата TON Прокси). Друг специфичен случай може да бъде взаимодействие директно между възлите, но със шифроване по индивидуална двойка ключове за този канал (предварително образувани по протокола Диффи-Хеллмана).
Накрая, специален случай е „нулевият“ канал – ако възелът все още не знае публичните ключове на своите „съседи“, той може да им изпраща пакети без никакво криптиране. Това е предназначено само за инициализация – веднага след като възлите изпратят информация за своите ключове, те трябва да бъдат използвани за по-нататъшно взаимодействие.
По-гореописаният протокол (256 бита идентификатор на канала + съдържание на пакета) се нарича ADNL. Документацията споменава възможността за реализиране на аналог на TCP върху него или собствени надстройки – RLDP (Reliable Large Datagram Protocol), но не навлиза в подробности относно тяхната реализация.
TON DHT: Разпределена хеш-таблица
Както и в случай на други разпределени системи, TON предвижда реализиране на DHT – . По-конкретно – таблицата е . Ако не сте запознати с такъв вид хеш-таблици – не се притеснявайте, по-долу ще опиша накратко как са организирани.
В абстрактен смисъл, DHT съответства на 256-битови ключове с произволни бинарни стойности от произволна дължина. При това ключовете в таблицата са хешове от определена TL-структура (самите структури също се съхраняват заедно с DHT). Това много прилича на формирането на адреси на възли – и те наистина могат да присъстват в DHT (например, по такъв ключ може да се намери IP адрес на възел, който съответства на зададения абстрактен адрес, ако той не го скрива). Но в общия случай, „прообразите на ключовете“ (техните описания, key descriptions) са метаданни, които указват на „собственика“ на записа в хеш-таблицата (т.е. публичен ключ на някой възел), тип на съхраняваната стойност и правила, по които този запис впоследствие може да се променя. Например, правилото може да разрешава промяна на стойността само от собственика – или да забрани намаляването на стойността (за да се защити от атаки с повторение).
Освен 256-битовите ключове, се въвежда понятието DHT-адреси. Разликата с обикновените адреси на възли е, че DHT-адресът задължително е свързан с IP адрес. Ако възелът не крие своя IP, той може да използва обикновен адрес за DHT. Но по-често за нуждите на DHT ще се създава отделен, „полу-постоянен“ адрес.
Над ключовете и DHT-адресите се въвежда понятието разстояние – в това всичко съвпада с таблиците — разстоянието между ключовете е равно на XOR (побитово изключително ИЛИ) от тях. Както в таблиците Kademlia, стойността, съответстваща на определен ключ, трябва да се съхранява на s възлите, които имат най-малко разстояние до този ключ (s тук — относително малко число).
За да може възел DHT да взаимодейства с други подобни възли, той запазва в паметта си таблица за маршрутизиране DHT — DHT- и IP-адреси на възли, с които е взаимодействал до този момент, групирани по разстояние до тях. Такива групи са 256 (те съответстват на най-стария зададяс бит в стойността на разстоянието — тоест възлите на разстояние от 0 до 255 попадат в една група, от 256 до 65535 — в следващата и т.н.). Вътре в всяка група се съхранява ограничен брой „най-добри“ възли (по отношение на латентността до тях).
Всеки възел трябва да поддържа няколко операции: съхраняване на стойност за ключ, търсене на възли и търсене на стойности. Търсенето на възли предполага предоставяне на най-близките до зададения ключ възли от таблицата за маршрутизиране; търсенето на стойности — същото, с изключение на ситуациите, когато на възела е известна стойността за ключа (в този случай просто я връща). Съответно, ако възел иска да намери стойност в DHT по ключ, той изпраща запитвания до малък брой най-близки до този ключ възли от своята таблица за маршрутизиране. Ако сред техните отговори няма исканата стойност, но има адреси на други възли, запитването се повтаря към тях.
TON DHT може да се използва за различни цели, например — за реализиране на файлово хранилище, подобно на торент (вж. TON Хранилище); за определяне на адресите на възлите, реализиращи определени услуги; за съхранение на информация за собствениците на сметки в блокчейн. Но най-важното приложение е откритие на възли по техните абстрактни адреси. За това адресът се използва като ключ, стойността на който трябва да се намери. В резултат на запитването може да бъде намерен самият възел (ако исканият адрес е неговият полу-постоянен DHT-адрес), или стойността ще бъде IP-адрес и порт за свързване — или друг адрес, който да се използва като тунел-посредник.
Надстройките в TON
Описаният по-горе протокол ADNL позволява на всяка точка да обменя информация помежду си — но това не е задължително да става по оптимални пътища. Може да се каже, че благодарение на ADNL всички узли оформят глобален граф TON (в идеалния случай — свързан). Но е предвидена и възможност за създаване на оверлейни мрежи — подграфи в рамките на този граф.
В такава мрежа взаимодействието се осъществява само директно — по предварително установени връзки между узлите-участници в мрежата (по каналите ADNL, описани по-горе). Създаването на такива връзки между съседите и търсенето на самите съседи е автоматичен процес, който се стреми да запази свързаността на оверлейната мрежа и да минимизира забавянията при обмен на данни в нея.
Освен това е предвиден начин бързо да се разпространяват големи широковещателни актуализации в мрежата — те се разделят на части, допълват се с код за корекция на грешки и всички тези парчета се предават от един участник на друг. Така на участника не е необходимо да получи напълно всички части, преди да ги предаде по-нататък в мрежата.
Оверлейните мрежи могат да бъдат публични и частни. Да станеш участник в публична мрежа не е трудно — нужно е да намериш TL-структурата, която я описва (тя може да бъде публична — или достъпна с определен ключ в DHT). В случай на частна мрежа, тази структура трябва да е известна на узла предварително.
Продължава
Реших да разделя прегледа на TON на няколко статии. С това тази част завършва, а преминавам към разглеждане на структурата на блокчейна (по-точно, блокчейните), от които ще се състои TON.
Източник: habr.com
