Уже две недели Рунет шумит про 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). Функция, производящая необратимое преобразование произвольной структуры данных в единственное число фиксированной длины. В рамках документации повсеместно идёт речь о функции SHA-256.
Узел сети (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 — распределённой хэш-таблицы. Более конкретно — таблица является Kademlia-подобной. Если вы не знакомы с такой разновидностью хэш-таблиц — не беспокойтесь, далее я примерно опишу, как они устроены.
В абстрактном смысле, DHT ставит в соответствие 256-битным ключам некие бинарные значения произвольной длины. При этом ключи в таблице — это хэши от определённой TL-структуры (сами структуры тоже хранятся вместе с DHT). Это очень похоже на формирование адресов узлов — и они действительно могут присутствовать в DHT (например, по такому ключу может находиться IP-адрес узла соответствующего заданному абстрактному адресу, если он не скрывает его). Но в общем случае, «прообразы ключей» (их описания, key descriptions) — это метаданные, которые указывают на «владельца» записи в хэш-таблице (то есть публичный ключ какого-то узла), тип хранимого значения и правила, по которым эта запись может впоследствии изменяться. Например, правило может разрешать изменять значение только владельцу — или запрещать изменение значения в меньшую сторону (чтобы защититься от replay-атак).
Кроме 256-битных ключей вводится понятие DHT-адресов. Разница с обычными адресами узлов в том, что DHT-адрес обязательно привязан к IP-адресу. Если узел не скрывает своего IP, он может использовать обычный адрес для DHT. Но чаще для нужд DHT будет заводиться отдельный, «полу-постоянный» адрес.
Над ключами и DHT-адресами вводится понятие расстояния — в этом всё совпадает с таблицами Kademlia — расстояние между ключами равно 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.
