Вече две седмици Рунет вдига шум около Telegram и ситуацията с безсмисленото и безпощадно блокиране от Роскомнадзор. Рикошетът обиди мнозина, но всичко това са теми за публикации в Geektimes. Бях изненадан от нещо друго - все още не съм видял на Habré нито един анализ на мрежата TON, планиран да бъде пуснат на базата на Telegram - Telegram Open Network. Исках да компенсирам този недостатък, защото там има какво да се учи - въпреки липсата на официални изявления за това.
Нека ви напомня, че има слухове, че Telegram стартира много мащабно затворено ICO, като вече е събрало невероятни суми в него. Предполага се, че собствената криптовалута на Gram ще бъде пусната тази година и всеки потребител на Telegram автоматично ще има портфейл, което само по себе си създава значително предимство пред другите криптовалути.
За съжаление, тъй като няма официални изявления, мога само да изхождам от за което веднага ви предупреждавам. Разбира се, може да се окаже много умел фалшификат, но също така е възможно това да е истинската бяла книга на бъдещата система, написана от Николай Дуров (и вероятно изтекла от някой от инвеститорите). Но дори това да е фалшификат, никой няма да ни забрани да го изучаваме и обсъждаме, нали?
Какво казва този документ? Ще се опитам да го преразкажа със свои думи, близки до текста, но на руски и малко по-човешки (да ме прости Николай със склонността си да навлиза в формалната математика). Имайте предвид, че дори да е автентично, това е чернова на описание на системата и е много вероятно да се промени до момента на публичното пускане.
Научаваме, че в допълнение към криптовалутата се очаква да се случи много повече. Нека го вземем по ред.
- TON Блокхайн. Това е основата на цялата система. Ако наистина не знаете какво е - Препоръчвам да разберете, защото тук ще има много блокчейни. Вложени, виртуално фрагментирани и дори „вертикални“ блокчейни в блокове от други блокчейни. Ще има и някои готино звучащи термини като Незабавно маршрутизиране на Hypercube и Парадигма за безкрайно шардинг, но повече за това по-късно. И, разбира се, доказателство за участие и интелигентни договори.
- TON P2P мрежа. Peer-to-peer мрежа, на базата на която ще бъде изградена системата. За него ще стане дума преди всичко в тази част на историята.
- TON съхранение. Файлово хранилище, което ще бъде изградено върху гореспоменатата peer-to-peer мрежа, независимо от блокчейна. Може да се сравни с торенти.
- TON прокси. Това е услуга, чиято цел е да повиши анонимността на участниците в мрежата. Всеки пакет може да бъде изпратен не директно, а през междинни тунели с допълнително криптиране - като I2P или TOR.
- TON DHT. Разпределена хеш таблица за съхраняване на произволни стойности. Той също е изграден отгоре TON мрежа (но в същото време се използва от него) и помага TON съхранение намерете "разпределителни" възли и TON прокси - междинни релета. Но трябва да се отбележи, че за разлика от блокчейна, тази хеш таблица не е защитено хранилище - не можете да съхранявате важна информация в нея.
- TON услуги. Платформа за произволни услуги. Всъщност това е един нов интернет в допълнение към всичко описано по-горе. Обмен на данни - чрез TON мрежа/TON прокси, а логиката е в интелигентните договори на TON Блокхайн. И интерфейс с доста познати URL адреси.
- ТОН DNS. Тъй като говорим за обичайните URL адреси, имаме нужда и от конвертор от тях към 256-битови адреси - акаунти, договори, услуги и възли.
- TON плащания. И тук идва въпросът с парите. И не само ще гр - както при етера, всякакви "жетони" ще бъдат възможни; Грамовете ще бъдат само валутата „по подразбиране“ тук.
Това е първата част, която описва "наземното" ниво на TON - неговата мрежова част, изградена върху традиционните протоколи. В следващата част ще говорим за „целулозата“ – блокчейн, която ще се поддържа от описаната по-долу система. По този начин моят ред на преразказ е малко по-различен от този, използван в горния документ (който започва веднага на абстрактно ниво).
Основни понятия
TL (Напишете език). Това е абстрактен двоичен формат за произволни структури от данни. Използва се в протокола Telegram и ще се използва активно в TON. Ако искате да научите повече за това - .
Хеш (хашиш). Функция, която извършва необратима трансформация на произволна структура от данни в едно число с фиксирана дължина. В цялата документация се говори много за функцията .
Мрежов възел (възел). Възелът е софтуерът, който ще осигури работата на системата. По-специално се предполага, че всяко клиентско приложение на Telegram ще включва TON възел. На ниско ниво възлите имат IPv4/IPv6 адреси и комуникират с помощта на UDP протокола, на по-високо ниво имат абстрактни адреси и имплементирайте протокола ADNL (вижте по-долу за абстрактни адреси и ADNL). Когато става въпрос за факта, че някои части на системата правят нещо или съхраняват някакви данни, се разбира, че мрежовите възли го правят.
Абстрактен адрес (или просто адрес, адрес). Адресът на възел се определя от неговия публичен ключ. По-точно, това е 256-битов хеш (SHA256) от структура от данни, съдържаща публичен ключ (конкретният криптографски алгоритъм не е посочен в този случай - елиптични криви и RSA-2048 са дадени като пример). За да може един възел да комуникира с друг, той трябва да знае не само адреса на този, но и тази структура от данни. Теоретично един физически възел може да създаде произволен брой адреси (съответстващи на различни ключове).
Освен това често се използва точно такъв пакет: „предварителен образ“ под формата на TL структура (съдържаща почти всякакви данни) и 256-битов хеш от него, използван за адресиране.
Блокчейн (blockchain). Blockchain е структура от данни, елементи (блокове), които са подредени във "верига", като всеки следващ блок от веригата съдържа хеша на предишния. По този начин се постига цялост - промени могат да се правят само чрез добавяне на нови блокове.
Обслужване (обслужване). Услугите в рамките на TON могат да бъдат от различни видове, в зависимост от това дали използват блокчейн или не. Например, един (или много) от мрежовите възли може да обработва някои RPC заявки, използвайки ADNL протокола, описан по-долу, без да създава никакви записи в блокчейна - като традиционните уеб сървъри. По-специално се разглежда възможността за внедряване на HTTP през ADNL, както и прехода на самия месинджър към този протокол. По аналогия с TOR или I2P, това ще го направи по-устойчив на различни блокировки.
В същото време редица услуги предполагат както взаимодействие с блокчейна, така и обработка на заявки извън него. Например за TON Storage – съхранение на файлове – не е много разумно самите файлове да се съхраняват в блокчейна. Той ще съдържа само файлови хешове (заедно с известна мета-информация за тях), а специализираните мрежови възли ще действат като „файлови сървъри“, готови да ги предоставят на други възли чрез ADNL.
услуга за мъгла (услуга за мъгла). Говорим за някои услуги, които включват децентрализация и открито участие в тях. Например TON Proxy е услуга, която може да се поддържа от всеки участник, който иска да предостави своя възел като посредник (прокси), който препраща пакети между други възли. Ако желае, той може да начисли определена от него такса за това - използвайки системата TON Payments за микроплащания (която от своя страна също е мъглива услуга).
ADNL: Мрежов слой на абстрактна дейтаграма
На най-ниското ниво комуникацията между възлите ще бъде чрез UDP (въпреки че и други опции са приемливи).
Както бе споменато по-горе, за да може един възел да изпрати пакет на друг, той трябва да знае един от публичните си ключове (и следователно адреса, който определя). Той криптира пакета с този ключ и добавя 256-битов целеви адрес в началото на пакета - тъй като един възел може да има няколко такива адреса, това ще му позволи да определи кой ключ да използва за дешифриране.
Освен това вместо адреса на получателя в началото на пакета данни може да има т.нар. идентификатор канал. В този случай обработката на пакета вече зависи от конкретни споразумения между възлите - например данните, изпратени до определен канал, могат да бъдат предназначени за друг възел и трябва да бъдат пренасочени към него (това е услугата TON прокси). Друг специален случай може да бъде взаимодействието директно между възлите, но с криптиране с помощта на индивидуална двойка ключове за този канал (преди това формиран с помощта на протокола Diffie-Hellman).
И накрая, специален случай е "нулевият" канал - ако възелът все още не знае публичните ключове на своите "съседи", той може да им изпрати пакети без изобщо да криптира. Това е само за инициализация - веднага щом възлите изпратят информация за своите ключове, те трябва да се използват за по-нататъшно взаимодействие.
Протоколът, описан по-горе (256 бита идентификатор на канал + съдържание на пакет), се нарича ADNL. В документацията се споменава възможността за имплементиране на аналог на TCP върху него или негова собствена добавка - RLDP (Reliable Large Datagram Protocol), но не се навлиза в подробности за тяхното внедряване.
TON DHT: Разпределена хеш таблица
Както в случая с други разпределени системи, TON включва внедряването на DHT - . По-конкретно, таблицата е . Ако не сте запознати с този вид хеш таблици, не се притеснявайте, тогава ще опиша грубо как са подредени.
В абстрактен смисъл DHT преобразува 256-битови ключове в двоични стойности с произволна дължина. В същото време ключовете в таблицата са хешове от определена TL структура (самите структури също се съхраняват заедно с DHT). Това е много подобно на формирането на адреси на възли - и те наистина могат да присъстват в DHT (например такъв ключ може да съдържа IP адреса на възела, съответстващ на дадения абстрактен адресако не го скрива). Но в общия случай "предварителни образи на ключове" (техните описания, ключови описания) са метаданни, които указват „собственика“ на запис в хеш-таблицата (т.е. публичния ключ на някакъв възел), вида на съхранената стойност и правилата, по които този запис може впоследствие да бъде променен. Например, едно правило може да позволи само на собственика да промени стойността - или да забрани промяната на стойността надолу (за защита срещу атаки при повторно възпроизвеждане).
В допълнение към 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.
Източник: www.habr.com