Уже две недели Рунет шумит про Telegram и ситуацию с его бессмысленной и беспощадной блокировкой Роскомнадзором. Рикошетом задело многих, но всё это — темы для постов на Geektimes. Меня же удивило другое — я до сих пор не видел на Хабре ни одного разбора запланированной к выходу на базе Telegram сети TON — Telegram Open Network. Мне захотелось восполнить этот недостаток, ибо поизучать там есть что — даже несмотря на отсутствие официальных заявлений о нём.
Напомню — ходят слухи о том, что Telegram запустил очень масштабное закрытое ICO, уже собрав в нём невероятные суммы. Предполагается, что уже в этом году будет запущена собственная криптовалюта Gram — и у каждого пользователя Телеграма автоматически появится кошелёк, что само по себе создает немалое преимущество перед остальными криптовалютами.
К сожалению, так как официальных заявлений нет, дальше я могу отталкиваться только от , о чём я сразу вас предупреждаю. Конечно, он может оказаться очень искусной подделкой, но не исключено и то, что это — реальный 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). Функция, производящая необратимое преобразование произвольной структуры данных в единственное число фиксированной длины. В рамках документации повсеместно идёт речь о функции .
Узел сети (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