Вече две седмици Рунет говори за Telegram и ситуацията с безсмисленото и безпощадно блокиране от Роскомнадзор. Рикошетът засегна много, но всичко това е тема за публикации в Geektimes. Мен ме изненада друго — все още не съм виждал на Хабр нито един анализ на планираната за пускане мрежа на базата на Telegram — Telegram Open Network. Искаше ми се да запълня този недостиг, защото там има какво да се изследва — дори и да няма официални изявления по него.
Да напомня — говорят слухове, че Telegram е стартирал много мащабно затворено ICO, вече събрал невероятни суми. Предполага се, че още тази година ще бъде пусната собствена криптовалута Gram — и на всеки потребител на Телеграма автоматично ще се появи портфейл, което само по себе си създава значително предимство пред другите криптовалути.
За съжаление, тъй като няма официални изявления, нататък мога да се основавам само на , за което веднага ви предупреждавам. Разбира се, той може да се окаже много умела фалшификация, но не е изключено и това да е реалният whitepaper на бъдещата система, написан от Николай Дуров (и вероятно изтекъл от някой от инвеститорите). Но дори и да е фейк, никой не може да ни забрани да го изследваме и обсъждаме, нали?
Какво се казва в този документ? Ще се опитам да го преразкажа с моите думи, близко до текста, но на български и малко по-човечно (да ми прости Николай за склонността си да се впуска в формална математика). Имайте предвид, че дори в случай на автентичност, това е чернова на описанието на системата и вероятно ще се промени до момента на публичния старт.
Научаваме, че освен криптовалутата, се предвижда още много и много неща. Нека разгледаме всичко по ред.
- TON Blockchain. Това е основата на цялата система. Ако изобщо не знаете какво е — препоръчвам да се запознаете, защото тук ще има много блокчейни. Вложени един в друг, виртуално раздробени и дори "вертикални" блокчейни вътре в блокове на други блокчейни. А също така ще има и няколко звучни термина като Instant Hypercube Routing и Infinite Sharding Paradigm, но за това по-късно. И, разбира се, proof-of-stake и смарт-контракти.
- TON P2P Network. Pиринговата мрежа, на основата на която ще бъде изградена работата на системата. За нея ще се говори преди всичко в тази част на разказа.
- TON Storage. Файлово хранилище, което независимо от блокчейна ще бъде изградена на споменатата по-горе пирингова мрежа. Може да се сравни с торенти.
- TON Proxy. Това е услуга, чиято цел е да увеличи анонимността на участниците в мрежата. Всеки пакет може да бъде изпратен не директно, а чрез посреднически тунели с допълнително криптиране — подобно на I2P или TOR.
- TON DHT. Разпределена хеш-таблица за съхранение на произволни стойности. Тя е изградена върху TON Network (но при това използва самия него) и помага TON Storage да се намират „разпределящите“ възли, а TON Proxy — междинни реле. Но трябва да се отбележи, че за разлика от блокчейна, тази хеш-таблица не е защитено хранилище — не може да се съхранява важна информация в нея.
- TON Services. Платформа за произволни услуги. По същество — това е нов интернет върху всичко по-горе описано. Обмен на данни — чрез TON Network/TON Proxy, а логиката — в смарт-контрактите на самия TON Blockchain. И интерфейс с доста познати URL адреси.
- TON DNS. Раз щом стана дума за известните URL адреси, необходим е и преобразувател от тях в 256-битови адреси — на акаунти, договори, услуги и възли.
- TON Payments. И ето тук вече се засяга паричният въпрос. И това няма да бъде само gram — както с етер, ще са възможни всякакви „токени“; грамовете тук ще бъдат просто валута „по подразбиране“.
Това е първата част, описваща „приземеното“ ниво на TON — неговата мрежова част, изградена върху традиционни протоколи. В следващата част ще става въпрос за „мякотката“ — блокчейн, който ще бъде поддържан от описаната по-долу система. Така че, моят ред на разказа леко се различава от използваното в споменатия по-горе документ (който започва веднага с абстрактното ниво).
Основни понятия
TL (Type Language). Това е абстрактен бинарен формат за произволни структури от данни. Използва се в протокола на Телеграма и ще бъде активно използван в TON. Ако искате да се запознаете подробно с него — .
Хеш (hash). Функция, произвеждаща необратимо преобразуване на произволна структура от данни в единствено число с фиксирана дължина. В документацията постоянно се говори за функцията .
Възел на мрежата (node). Възелът е софтуер, който осигурява функционирането на системата. В частност, предвижда се всяко клиентско приложение на Телеграм да включва възел на 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 Proxy). Друг частен случай може да бъде взаимодействие на директно между възлите, но с криптиране по индивидуална двойка ключове за този канал (предварително формирани по протокола на Диффи-Хелмана).
Накрая, специален случай е «нулевият» канал — ако възелът все още не знае публичните ключове на «съседите» си, може да им изпраща пакети без никакво криптиране. Това е предназначено само за инициализация — щом възлите изпратят информация за своите ключове, те трябва да се използват за по-нататъшна комуникация.
По-гореописаният протокол (256 битов идентификатор на канала + съдържание на пакета) се нарича ADNL. Документацията споменава възможността за внедряване на аналог на TCP върху него или собствено разширение — RLDP (Reliable Large Datagram Protocol), но не влага подробности за тяхната реализация.
TON DHT: Разпределена хеш-таблица
Както и при другите разпределени системи, TON предвижда реализиране на DHT — . По-точно — таблицата е . Ако не сте запознати с този тип хеш-таблици — не се притеснявайте, по-долу ще опиша накратко как са устроени.
В абстрактен смисъл, DHT съпоставя 256-битови ключове на произволни бинарни стойности с произволна дължина. Ключовете в таблицата — това са хешове от определена TL-структура (самите структури също се съхраняват заедно с DHT). Това много прилича на образуването на адреси на възли — и те наистина могат да присъстват в DHT (например, по такъв ключ може да се намира IP-адреса на възел, съответстващ на зададения абстрактен адрес, ако той не го скрива). Но в общия случай, «образите на ключовете» (техните описания, key descriptions) — това са метаданни, които сочат към «посредника» на записа в хеш-таблицата (тоест публичния ключ на определен възел), тип на съхраняваната стойност и правилата, по които този запис може след това да бъде променян. Например, правилото може да позволява промяна на стойността само на притежателя — или да забранява промяна на стойността в по-малка посока (за да се защити от replay-атаки).
Освен 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 Storage); за определяне на адресите на възли, реализиращи определени услуги; за съхранение на информация за собствениците на акаунти в блокчейна. Но най-важното приложение е откритие на възли по техните абстрактни адреси. За това адресът се използва като ключ, стойността на който трябва да бъде намерена. В резултат на заявката ще бъде намерен или самият възел (ако търсеният адрес е бил неговият полу-постоянен DHT адрес), или стойността ще бъде IP адресът и портът за свързване — или друг адрес, който трябва да се използва като тунел-посредник.
Оверлейните мрежи в TON
По-горе описаният протокол ADNL предвижда възможността всички възли да обменят информация помежду си — разбира се, не непременно по оптимални пътища. Можем да кажем, че благодарение на ADNL всички възли образуват глобален граф TON (в идеалния случай — свързан). Но допълнително е предвидена възможността за създаване на оверлейни мрежи — подграфи в рамките на този граф.
В такава мрежа взаимодействието се осъществява само директно — по предварително определени връзки между участниците в мрежата (по каналите ADNL, описани по-горе). Създаването на такива връзки между съседите, откритията на самите съседи — е автоматичен процес, стремящ се да поддържа свързаността на оверлейната мрежа и да минимизира закъсненията при обмена на данни в нея.
Освен това е предвиден начин за бързо разпространение на големи широковещателни актуализации в мрежата — те се разделят на части, допълват се с код за корекция на грешки и всички тези парчета се изпращат от един участник на друг. По този начин участникът не е задължен да получи всички части изцяло, преди да ги прехвърли по мрежата.
Оверлейните мрежи могат да бъдат публични или частни. Становището на публична мрежа не е сложно — трябва да намерите TL-структура, описваща я (тя може да бъде публична — или достъпна по определен ключ в DHT). В случая на частната мрежа, тази структура трябва да е известна на възела предварително.
Продължение следва
Реших да разделя прегледа на TON на няколко статии. С тази част приключваме, а преминавам към разглеждане на структурата на блокчейна (по-точно, блокчейните), от които ще се състои TON.
Източник: habr.com
