Ужо два тыдні Рунэт шуміць пра Telegram і сітуацыю з яго бессэнсоўнай і бязлітаснай блакіроўкай Роскомнадзором. Рыкашэтам закранула многіх, але ўсё гэта – тэмы для пастоў на Geektimes. Мяне ж здзівіла іншае – я да гэтага часу не бачыў на Хабры ніводнага разбору запланаванай да выхаду на базе Telegram сеткі TON – Telegram Open Network. Мне захацелася папоўніць гэты недахоп, бо павывучаць там ёсць што - нават нягледзячы на адсутнасць афіцыйных заяў аб ім.
Нагадаю – ходзяць чуткі аб тым, што Telegram запусціў вельмі маштабнае закрытае ICO, ужо сабраўшы ў ім неверагодныя сумы. Мяркуецца, што ўжо ў гэтым годзе будзе запушчана ўласная криптовалюта Gram – і ў кожнага карыстальніка Тэлеграма аўтаматычна з'явіцца кашалёк, што само па сабе стварае немалую перавагу перад астатнімі криптовалютами.
Нажаль, бо афіцыйных заяў няма, далей я магу адштурхоўвацца толькі ад , пра што я адразу вас папярэджваю. Вядома, ён можа апынуцца вельмі майстэрскай падробкай, але не выключана і тое, што гэта - рэальны whitepaper будучай сістэмы, напісаны Мікалаем Дуровым (і зліты, верагодна, кімсьці з інвестараў). Але нават калі гэта фэйк, ніхто нам не забароніць яго павывучаць і абмеркаваць, праўда?
Што ж гаворыцца ў гэтым дакуменце? Я паспрабую пераказаць яго сваімі словамі, блізка да тэксту, але па-руску і крыху больш чалавечна (хай даруе мне Мікалай са сваёй схільнасцю сыходзіць у фармальную матэматыку). Майце на ўвазе, што нават у выпадку яго сапраўднасці, гэта чарнавое апісанне сістэмы і яно, вельмі верагодна, зменіцца да моманту публічнага запуску.
Мы даведваемся, што акрамя крыптавалюты мяркуецца яшчэ вельмі і вельмі шмат усяго. Давайце разбяром па парадку.
- Блокчейн TON. Гэта аснова ўсёй сістэмы. Калі вы зусім не ведаеце, што такое - Рэкамендую даведацца, таму што тут блокчейнов будзе шмат. Укладзеныя сябар у сябра, віртуальна раздробленыя і нават «вертыкальныя» блокчейны ўнутры блокаў іншых блокчейнов. А яшчэ тут будзе некалькі крута якія гучаць тэрмінаў тыпу Instant Hypercube Routing и Infinite Sharding Paradigm, Але пра гэта пазней. І, вядома, proof-of-stake і смарт-кантракты.
- TON P2P Network. Пірынгавая сетка, на аснове якой будзе пабудавана праца сістэмы. Пра яе ў першую чаргу пойдзе гаворка ў гэтай частцы апавядання.
- Захоўванне TON. Файлавае сховішча, якое незалежна ад блокчейна будзе пабудавана на вышэйзгаданай пірынгавай сетцы. Можна параўнаць з торэнтамі.
- TON проксі. Гэта сэрвіс, мэта якога - павысіць ананімнасць удзельнікаў сеткі. Любы пакет можна адправіць не напрамую, а праз тунэлі-пасрэднікі з дадатковым шыфраваннем - падобна I2P або TOR.
- TON DHT. Размеркаваная хэш-табліца для захоўвання адвольных значэнняў. Яна таксама пабудавана паверх TON Network (але пры гэтым выкарыстоўваецца ім жа) і дапамагае Захоўванне TON знаходзіць «раздаючыя» вузлы, а TON проксі - прамежкавыя рэтранслятары. Але трэба адзначыць, што, у адрозненне ад блокчейна, гэтая хэш-табліца не з'яўляецца абароненым сховішчам - захоўваць важную інфармацыю ў ёй нельга.
- Паслугі TON. Платформа для адвольных сэрвісаў. Па сутнасці — гэта новы інтэрнэт па-над усім вышэйапісаным. Абмен дадзенымі - праз TON Network/TON проксі, А логіка - у смарт-кантрактах самога Блокчейн TON. І інтэрфейс з даволі звыклымі URL.
- TON DNS. Раз ужо зайшла гаворка пра звыклыя URL, патрэбен і пераўтваральнік з іх у 256-бітныя адрасы - акаўнтаў, кантрактаў, сэрвісаў і вузлоў.
- Плацяжы TON. І вось толькі тут закранаецца грашовае пытанне. І гэта будзе не толькі грам - як з эфірам, будуць магчымыя любыя «токены»; грамы тут будуць усяго толькі валютай "па змаўчанні".
Гэта першая частка, якая апісвае «прызямлёны» узровень TON – яго сеткавую частку, якая будуецца па-над традыцыйнымі пратаколамі. У наступнай частцы прамова пайдзе пра "мякотку" - блокчейн, які будзе падтрымлівацца апісанай далей сістэмай. Такім чынам, мой парадак пераказу крыху адрозніваецца ад выкарыстанага ў вышэйзгаданым дакуменце (які пачынаецца адразу з абстрактнага ўзроўню).
базавыя паняцці
TL (Type Language). Гэта абстрактны бінарны фармат для адвольных структур даных. Ён выкарыстоўваецца ў пратаколе Тэлеграма і будзе актыўна выкарыстоўвацца ў TON. Калі хочаце падрабязна азнаёміцца з ім. .
Хэш (мешаніна). Функцыя, якая вырабляе незваротнае пераўтварэнне адвольнай структуры дадзеных у адзіны лік фіксаванай даўжыні. У рамках дакументацыі паўсюдна ідзе гаворка аб функцыі .
Вузел сеткі (вузел). Вузел - гэта ПЗ, якое будзе забяспечваць працу сістэмы. У прыватнасці, мяркуецца, што кожны кліенцкі дадатак Тэлеграма будзе ўключаць у сябе вузел TON'а. На нізкім узроўні вузлы маюць IPv4/IPv6-адрасы і маюць зносіны па пратаколе UDP, на больш высокім – валодаюць абстрактнымі адрасамі і рэалізуюць пратакол ADNL (аб абстрактных адрасах і ADNL - гл. ніжэй). Калі гаворка ідзе пра тое, што нейкія часткі сістэмы нешта робяць ці захоўваюць нейкія дадзеныя - маецца на ўвазе, што гэта робяць вузлы сеткі.
Абстрактны адрас (Ці проста адрас, адрас). Адрас вузла вызначаецца яго публічным ключом. Больш строга – гэта 256-бітны хэш (SHA256) ад структуры дадзеных, якая змяшчае публічны ключ (канкрэтны крыптаграфічны алгарытм пры гэтым не ўдакладняецца – у якасці прыкладу прыводзяцца эліптычныя крывыя і RSA-2048). Каб адзін вузел мог узаемадзейнічаць з іншым, яму трэба ведаць не толькі адрас таго, але і гэтую структуру даных. Тэарэтычна адзін фізічны вузел можа стварыць любую колькасць адрасоў (якія адпавядаюць розных ключам).
Далей часта выкарыстоўваецца менавіта такі звязак: "правобраз" у выглядзе TL-структуры (якая змяшчае практычна любыя дадзеныя), і 256-бітны хэш ад яе, які выкарыстоўваецца для адрасацыі.
Блокчэйн (blockchain). Блокчейн - гэта структура дадзеных, элементы (блокі) якой упарадкаваны ў «ланцуг», і кожны наступны блок ланцуга змяшчае ў сабе хэш папярэдняга. Такім чынам дасягаецца цэласнасць - змены могуць уносіцца толькі даданнем новых блокаў.
Сэрвіс (абслугоўванне). Сэрвісы ў рамках 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) - гэта метададзеныя, якія паказваюць на «ўладальніка» запісы ў хэш-табліцы (гэта значыць публічны ключ нейкага вузла), тып захоўваемага значэння і правілы, па якіх гэты запіс можа пасля змяняцца. Напрыклад, правіла можа дазваляць змяняць значэнне толькі ўладальніку - ці забараняць змяненне значэння ў меншы бок (каб абараніцца ад 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); для вызначэння адрасоў вузлоў, якія рэалізуюць пэўныя сервісы; для захоўвання інфармацыі аб уладальніках акаўнтаў у блокчейне. Але найважнейшае ўжыванне - выяўленне вузлоў па іх абстрактным адрасах. Для гэтага адрас выкарыстоўваецца ў якасці ключа, значэнне якога трэба знайсці. У выніку запыту альбо знойдзецца сам вузел (калі шуканы адрас быў яго паў-пастаянным DHT-адрасам), альбо значэннем апынецца IP-адрас і порт для падлучэння – ці ж іншы адрас, які варта выкарыстоўваць у якасці тунэлю-пасрэдніка.
Аверлейныя сеткі ў TON
Апісаны вышэй пратакол ADNL мае на ўвазе магчымасць любым вузлам абменьвацца інфармацыяй адзін з адным – праўда, не абавязкова аптымальнымі шляхамі. Можна сказаць, што дзякуючы ADNL усе вузлы ўтвараюць глабальны граф TON (у ідэале - сувязны). Але дадаткова прадугледжана магчымасць ствараць аверлейныя сеткі - падграфы ўнутры гэтага графа.
Унутры такой сеткі ўзаемадзеянне праводзіцца толькі напрамую – па папярэдне сфарміраваным сувязях паміж вузламі-ўдзельнікамі сеткі (па каналах ADNL, апісанымі вышэй). Фарміраванне такіх сувязяў паміж суседзямі, пошук саміх суседзяў - аўтаматычных працэс, які імкнецца захаваць складнасць оверлейной сеткі і мінімізаваць затрымкі пры абмене дадзенымі ў ёй.
Акрамя таго, прадугледжаны спосаб хутка распаўсюджваць буйныя шырокавяшчальныя абнаўленні ўнутры сеткі - яны разбіваюцца на часткі, дапаўняюцца кодам карэкцыі памылак, і ўсе гэтыя кавалкі перасылаюцца ад аднаго ўдзельніка іншаму. Такім чынам удзельніку не абавязкова поўнасцю атрымаць усе часткі, перш чым перасылаць іх далей па сетцы.
Аверлейныя сеткі могуць быць публічнымі і прыватнымі. Стаць удзельнікам публічнай сеткі нескладана – трэба знайсці TL-структуру, якая апісвае яе (яна можа быць публічнай – ці даступная па вызначаным ключы ў DHT). У выпадку з прыватнай сеткай гэтая структура павінна быць вядома вузлу загадзя.
Працяг варта
Я вырашыў падзяліць агляд TON на некалькі артыкулаў. На гэтым дадзеная частка заканчваецца, а я пераходжу да разгляду структуры блокчейна (дакладней, блокчейнов), з якіх будзе складацца TON.
Крыніца: habr.com