Хабрахабр

TON: Telegram Open Network. Часть 1: Вступление, сетевой уровень, ADNL, DHT, оверлейные сети

TON: Telegram Open Network

Рикошетом задело многих, но всё это — темы для постов на Geektimes. Уже две недели Рунет шумит про Telegram и ситуацию с его бессмысленной и беспощадной блокировкой Роскомнадзором. Мне захотелось восполнить этот недостаток, ибо поизучать там есть что — даже несмотря на отсутствие официальных заявлений о нём. Меня же удивило другое — я до сих пор не видел на Хабре ни одного разбора запланированной к выходу на базе Telegram сети TON — Telegram Open Network.

Предполагается, что уже в этом году будет запущена собственная криптовалюта Gram — и у каждого пользователя Телеграма автоматически появится кошелёк, что само по себе создает немалое преимущество перед остальными криптовалютами. Напомню — ходят слухи о том, что Telegram запустил очень масштабное закрытое ICO, уже собрав в нём невероятные суммы.

Конечно, он может оказаться очень искусной подделкой, но не исключено и то, что это — реальный whitepaper будущей системы, написанный Николаем Дуровым (и слитый, вероятно, кем-то из инвесторов). К сожалению, так как официальных заявлений нет, дальше я могу отталкиваться только от документа неизвестного происхождения, о чём я сразу вас предупреждаю. Но даже если это фейк, никто нам не запретит его поизучать и обсудить, верно?

Я попробую пересказать его своими словами, близко к тексту, но по-русски и чуть более человечно (да простит меня Николай со своей склонностью уходить в формальную математику). Что же говорится в этом документе? Имейте в виду, что даже в случае его подлинности, это черновое описание системы и оно, весьма вероятно, изменится к моменту публичного запуска.

Давайте разберём по порядку. Мы узнаём, что кроме криптовалюты предполагается ещё очень и очень много всего.

  • TON Blockchain. Это основа всей системы. Если вы совсем не знаете, что такое блокчейн — рекомендую узнать, потому что тут блокчейнов будет много. Вложенные друг в друга, виртуально раздроблённые и даже «вертикальные» блокчейны внутри блоков других блокчейнов. А ещё тут будет несколько круто звучащих терминов типа Instant Hypercube Routing и Infinite Sharding Paradigm, но об этом позже. И, конечно, proof-of-stake и смарт-контракты.
  • TON P2P Network. Пиринговая сеть, на основе которой будет построена работа системы. О ней в первую очередь пойдёт речь в этой части повествования.
  • 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). В рамках документации повсеместно идёт речь о функции SHA-256.

Узел — это ПО, которое будет обеспечивать работу системы. Узел сети (node). На низком уровне узлы имеют IPv4/IPv6-адреса и общаются по протоколу UDP, на более высоком — обладают абстрактными адресами и реализуют протокол ADNL (об абстрактных адресах и ADNL — см. В частности, предполагается, что каждое клиентское приложение Телеграма будет включать в себя узел TON'а. Когда речь идёт о том, что какие-то части системы что-то делают или хранят какие-то данные — подразумевается, что это делают узлы сети. ниже).

Адрес узла определяется его публичным ключом. Абстрактный адрес (или просто адрес, address). Чтобы один узел мог взаимодействовать с другим, ему нужно знать не только адрес того, но и эту структуру данных. Более строго — это 256-битный хэш (SHA256) от структуры данных, содержащей публичный ключ (конкретный криптографический алгоритм при этом не уточняется — в качестве примера приводятся эллиптические кривые и RSA-2048). Теоретически один физический узел может создать любое количество адресов (соответствующих разных ключам).

Далее часто используется именно такая связка: «прообраз» в виде TL-структуры (содержащей практически любые данные), и 256-битный хэш от неё, используемый для адресации.

Блокчейн — это структура данных, элементы (блоки) которой упорядочены в «цепь», и каждый следующий блок цепи содержит в себе хэш предыдущего. Блокчейн (blockchain). Таким образом достигается целостность — изменения могут вноситься только добавлением новых блоков.

Сервисы в рамках TON могут быть различных типов — в зависимости от того, используют они блокчейн или нет. Сервис (service). В том числе рассматривается возможность реализации HTTP поверх ADNL, а также переход самого мессенджера на этот протокол. Например, один (или множество) из узлов сети может обрабатывать некие RPC-запросы по описанному далее протоколу ADNL, не создавая никаких записей в блокчейне — наподобие традиционных веб-серверов. По аналогии с TOR или I2P, это сделает его более устойчивым к различным блокировкам.

Например, для TON Storage — файлового хранилища — не очень разумно хранить сами файлы в блокчейне. В то же время, ряд сервисов подразумевает и взаимодействие с блокчейном, и обработку запросов вне его. В нём будут содержаться только хэши файлов (вместе с какой-то метаинформацией о них), а в качестве «файловых серверов» будут выступать специализированные узлы сети, готовые отдавать их другим узлам по ADNL.

Речь идёт о некоторых из сервисов, которые подразумевают децентрализацию и открытое участие в них. Туманные сервисы (fog services). При желании он может взымать за эту установленную им плату — используя систему TON Payments для микроплатежей (которая, в свою очередь, тоже является туманным сервисом). Например, TON Proxy — это сервис, который может поддерживать любой участник, желающий предоставить свой узел в качестве посредника (прокси), пересылающего пакеты между другими узлами.

ADNL: Abstract Datagram Network Layer

На самом низком уровне взаимодействие между узлами будет производиться по протоколу UDP (хотя допустимы и другие варианты).

Он зашифровывает пакет этим ключом и добавляет в начало пакета 256-битный адрес получателя — поскольку один узел может иметь несколько таких адресов, это позволит ему определить, какой ключ использовать для расшифровки. Как упомянуто выше, чтобы один узел мог послать пакет другому, он должен знать один из его публичных ключей (и, следовательно, адрес, который им определяется).

ADNL

идентификатор канала. Кроме того, вместо адреса получателя в начале пакета данных может находиться т.н. Другим частным случаем может быть взаимодействие напрямую между узлами, но с шифрованием по индивидуальной паре ключей для этого канала (предварительно сформированных по протоколу Диффи-Хеллмана). В таком случае обработка пакета уже зависит от конкретных договорённостей между узлами — например, отправленные в некий канал данные могут предназначаться другому узлу и должны быть ему переадресованы (это и есть сервис TON Proxy).

Это предназначено только для инициализации — как только узлы пришлют информацию о своих ключах, их стоит использовать для дальнейшего взаимодействия. Наконец, специальным случаем является «нулевой» канал — если узел ещё не знает публичных ключей своих «соседей», он может посылать им пакеты без шифрования совсем.

Документация упоминает возможность реализации аналога TCP поверх него или собственной надстройки — RLDP (Reliable Large Datagram Protocol), но не вдается в подробности об их реализации. Вышеописанный протокол (256 бит идентификатора канала + содержимое пакета) называется ADNL.

TON DHT: Распределённая хэш-таблица

Более конкретно — таблица является Kademlia-подобной. Как в случае с другими распределёнными системами, TON предполагает реализацию DHT — распределённой хэш-таблицы. Если вы не знакомы с такой разновидностью хэш-таблиц — не беспокойтесь, далее я примерно опишу, как они устроены.

DHT

При этом ключи в таблице — это хэши от определённой TL-структуры (сами структуры тоже хранятся вместе с DHT). В абстрактном смысле, DHT ставит в соответствие 256-битным ключам некие бинарные значения произвольной длины. Но в общем случае, «прообразы ключей» (их описания, key descriptions) — это метаданные, которые указывают на «владельца» записи в хэш-таблице (то есть публичный ключ какого-то узла), тип хранимого значения и правила, по которым эта запись может впоследствии изменяться. Это очень похоже на формирование адресов узлов — и они действительно могут присутствовать в DHT (например, по такому ключу может находиться IP-адрес узла соответствующего заданному абстрактному адресу, если он не скрывает его). Например, правило может разрешать изменять значение только владельцу — или запрещать изменение значения в меньшую сторону (чтобы защититься от replay-атак).

Разница с обычными адресами узлов в том, что DHT-адрес обязательно привязан к IP-адресу. Кроме 256-битных ключей вводится понятие DHT-адресов. Но чаще для нужд DHT будет заводиться отдельный, «полу-постоянный» адрес.
image
Над ключами и DHT-адресами вводится понятие расстояния — в этом всё совпадает с таблицами Kademlia — расстояние между ключами равно XOR (побитовому исключающему ИЛИ) от них. Если узел не скрывает своего IP, он может использовать обычный адрес для DHT. Как и в таблицах Kademlia, значение, соответствующее некоему ключу, должно храниться на s узлах, имеющих наименьшее расстояние до этого ключа (s тут — относительно небольшое число).

Таких групп 256 (они соответствуют старшему выставленному биту в значении расстояния — то есть узлы на расстоянии от 0 до 255 попадут в одну группу, от 256 до 65535 — в следующую, и т.д.). Для того, чтобы узел DHT мог взаимодействовать с другими такими узлами, он держит в памяти таблицу маршрутизации DHT — DHT- и IP-адреса узлов, с которыми он взаимодействовал до этого, сгруппированные по расстоянию до них. Внутри каждой группы хранится ограниченное число «лучших» узлов (в плане пинга до них).

Структура TON DHT

Поиск узлов подразумевает выдачу по заданному ключу ближайших к нему узлов из таблицы маршрутизации; поиск значений — то же самое, за исключением ситуации, когда узел знает значения для ключа (тогда он просто возвращает его). Каждый узел должен поддерживать несколько операций: сохранение значения для ключа, поиск узлов и поиск значений. Если среди их ответов нет искомого значения, но есть другие адреса узлов, то запрос повторяется уже к ним. Соответственно, если узел хочет найти в DHT значение по ключу, он посылает запросы небольшому числу ближайших к нему узлов из своей таблицы маршрутизации.

TON Storage); для определения адресов узлов, реализующих определённые сервисы; для хранения информации о владельцах аккаунтов в блокчейне. TON DHT может использоваться для различных целей, например — для реализации торрент-подобного хранилища файлов (см. Для этого адрес используется в качестве ключа, значение которого нужно найти. Но самое важное применение — обнаружение узлов по их абстрактным адресам. В результате запроса либо найдётся сам узел (если искомый адрес был полу-постоянным DHT-адресом), либо значением окажется IP-адрес и порт для подключения — или же другой адрес, который следует использовать в качестве тоннеля-посредника.

Оверлейные сети в TON

Можно сказать, что благодаря ADNL все узлы образуют глобальный граф TON (в идеале — связный). Описанный выше протокол ADNL подразумевает возможность любым узлам обмениваться информацией друг с другом — правда, не обязательно оптимальными путями. Но дополнительно предусмотрена возможность создавать оверлейные сети — подграфы внутри этого графа.
Оверлейные сети

Формирование таких связей между соседями, поиск самих соседей — автоматических процесс, стремящийся сохранить связность оверлейной сети и минимизировать задержки при обмене данными в ней. Внутри такой сети взаимодействие производится только напрямую — по предварительно сформированным связям между узлами-участниками сети (по каналам ADNL, описанными выше).

Таким образом участнику не обязательно полностью получить все части, прежде чем пересылать их дальше по сети. Кроме того, предусмотрен способ быстро распространять крупные широковещательные обновления внутри сети — они разбиваются на части, дополняются кодом коррекции ошибок, и все эти куски пересылаются от одного участника другому.

Стать участником публичной сети несложно — нужно найти TL-структуру, описывающую её (она может быть публичной — или доступна по определённому ключу в DHT). Оверлейные сети могут быть публичными и приватными. В случае с приватной сетью эта структура должна быть известна узлу заранее.

Продолжение следует

На этом данная часть заканчивается, а в следующей я планирую перейти к рассмотрению структуры блокчейна (точнее, блокчейнов), из которых будет состоять TON. Я решил разделить обзор TON на несколько статей.

Теги
Показать больше

Похожие статьи

Добавить комментарий

Ваш e-mail не будет опубликован. Обязательные поля помечены *

Кнопка «Наверх»
Закрыть