книги хакеры / журнал хакер / 246_Optimized

КАК РАБОТАЕТ TON И ПОЧЕМУ ЭТО НЕ ПРОСТО БЛОКЧЕЙН

Очень долго в разговорах не было конкретики: Дуров ничего не объявлял официально, а разные источники расходились во мнениях о том, что же такое TON. Первые достоверные новости появились в феврале 2018 года, когда Павел Дуров зарегистрировал компании TON Issuer и Telegram Group в Комиссии по ценным бумагам и биржам США (SEC). За два раунда зак рытого ICO команде удалось привлечь инвестиции в размере 1,7 миллиарда долларов.

И хотя никаких публичных заявлений Дуров не делал, работа над проектом идет вовсю. Документация и код TON доступны всем желающим по адресу test.ton.org, а на GitHub появилась организация ton blockchain, которая опуб ликовала исходный код TON Blockchain Software.

Эта статья основана на текущей версии white pa per (PDF) и доступном коде по состоянию на момент подготовки (см. дату публикации). TON — проект, который находится в активной раз работке; прямо сейчас запущена только тестовая сеть. У меня нет информации о том, какие изме нения будут внесены в этот проект.

ЧТО ТАКОЕ TON?

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

•TON Blockchain — ключевой компонент TON, о котором мы поговорим ниже.

•TON Network — сетевой уровень, который используется для коммуника ции. Все остальные компоненты системы так или иначе используют TON Network для общения.

•TON DHT — распределенная хеш таблица, похожая на Kademlia. Очень важный компонент платформы: используется в TON Storage (для поиска нод, которые имеют тот или иной файл), TON Proxy и других сервисах.

•TON Storage — децентрализованное хранение файлов, независимое от блокчейна. TON Blockchain вместе с TON DHT предоставляют «доступ» к файлам, в то время как сами файлы могут находиться где угодно. Похоже на то, как сейчас работают торренты.

•TON Proxy — прокси. Да, это просто возможность общаться не нап рямую, а через посредников, которые готовы предоставить свои узлы для этих целей. Похоже на то, как сейчас работает I2P.

•TON Services — платформа для сервисов. В качестве примера я расска жу о создании «сайта в TON».

•TON DNS — о нем мы тоже поговорим чуть позже.

•TON Payments — платформа для (микро)платежей.

TON BLOCKCHAIN

Это ключевой компонент TON. Он представляет собой не просто блокчейн,

аколлекцию разных блокчейнов.

•Masterchain — самый главный блокчейн, классическая цепочка блоков, содержит параметры системы, состояние воркчейнов и их шардов (про них ниже), хеши всех последних блоков, количество выпущенных Gram и прочую важную информацию. В общем, все самое необходимое для функционирования системы.

•Workchain — объединяет шарды. Всего может быть 232 таких воркчей нов, каждый из которых имеет уникальный идентификатор и свою логику. Каждый воркчейн, например, может иметь свою виртуальную машину, свои форматы адресов. То есть теоретически можно создать воркчейн для процессинга смарт контрактов из Ethereum. Первый воркчейн будет иметь префикс 0 — он зарезервирован для основного воркчейна TON.

•Shardchain (далее — шард) — главная часть масштабирования. В рамках

одного воркчейна может быть 260 шардов. Шарды могут «общаться» друг с другом, каждый шард отвечает за определенные аккаунты и подчиняется всем правилам своего воркчейна.

•Accountchain — можно сказать, что это учетная книга (ledger) для вхо дящих и исходящих сообщений определенного аккаунта.

Все это было придумано для решения двух острых проблем. Первая проб лема — размер блокчейна, который непрерывно растет и в случае с Bitcoin в 2019 году перевалил за 200 Гбайт. Большинство криптовалют требуют хра нить и синхронизировать весь блокчейн, и это становится все более накладно с ростом сети. Вторая проблема заключается в том, что для внесения серь езных инфраструктурных изменений часто требуется «пересоздать» блок чейн, то есть сделать форк.

TON решает первую проблему с помощью Infinite Sharding Program, как она называется в документе. Чтобы объяснить, как это работает, лучше зайти издалека. Начнем с того, что workchain — это на самом деле виртуальный блокчейн, объединяющий несколько шардов. Идентификатор воркчейна является частью идентификатора конкретного шарда, благодаря которому можно понять, к какому воркчейну относится тот или иной шард.

Создать воркчейн может каждый, кто готов оплатить высокую стоимость транзакции в мастерчейне и опубликовать спецификацию и «правила» нового воркчейна. Тем не менее требуется консенсус двух третей текущих валида торов, так как им придется обновить ПО для работы с блоками нового вор кчейна.

Каждый шард имеет следующий идентификатор в виде кортежа: workchain_id и префикс самого шарда. Префикс отвечает за те аккаунты (адреса), которые будут включены в шард. Например, если префикс 1337, то все адреса, которые начинаются с 1337, будут в этом шарде. Префикс может динамически меняться и иметь длину от 0 до 60 бит. Сделано это для того, чтобы склеивать шарды без нагрузки и разделять нагруженные шарды.

Accountchain — еще один виртуальный блокчейн, который имеет иден тификатор в виде кортежа: workchain_id и идентификатор самого аккаунта.

МАЙНИНГ

Вместо привычного перебора хешей на видеокартах в TON используется одна из вариаций PoS алгоритма, которая решает проблему византийских генералов (далее — BFT): в результате для консенсуса требуется две трети валидаторов.

Новые блоки создаются и проверяются валидаторами. Любой может стать валидатором, если он готов заложить много GRM в мастерчейн, подтвердив таким образом свои намерения. Такой «залог» замораживается минимум на месяц. На данный момент для того, чтобы стать валидатором в тестовой сети, нужно 100 000 GRM (тестовых, конечно же).

Валидаторы распределяются между всеми существующими шардами в случайном порядке. Примерно каждые 1024 блока валидаторы меняют шард, в котором они «работают». В рамках одного шарда валидаторы выбирают новый блок (благодаря BFT). Если консенсус был достигнут, то формируется новый блок, комиссии с транзакций и эмиссия в этом блоке распределяются между валидаторами. Один и тот же валидатор может валидировать несколько шардов — подразумевается, что он будет проделы вать эту работу параллельно.

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

ИСПРАВЛЕНИЕ ОШИБОК

Я посвящаю исправлению ошибок отдельный параграф, так как это очень интересный вопрос в мире блокчейна (вспомни историю The DAO и Ethereum Classic) и меня очень много о нем спрашивали на последнем выступлении про TON.

Конечно, ошибок быть не должно, так как для консенсуса требуется две трети валидаторов, но в системе заложено обнаружение и исправление «неп равильных» блоков. Предположим, что был обнаружен «неправильный» блок, и валидаторов, которые подписали этот блок, наказали. Но система все еще имеет неправильный блок — так что этих мер недостаточно.

В большинстве других систем для этого требуется форк с последнего «правильного» блока. Такой подход имеет множество недостатков: его слож но реализовать, нужно убедить всех участников перейти на новую сеть после форка; и не менее остро стоит вопрос о том, что делать с правильными тран закциями, которые были совершены уже после «неправильного» блока.

TON Blockchain решает эту проблему следующим образом. Каждый блок в шарде (и в мастерчейне тоже) является блокчейном, который по умолчанию состоит из одного блока. Если требуется исправить «неверный» блок, то этот маленький блокчейн вырастает еще на один блок, который и заменяет пре дыдущий. Этот блок также генерируется валидаторами, которые в данный момент работают в шарде.

При этом отдельно упоминается, что блоки в виртуальном accountchain не будут изменены, если они были правильными. Подразумевается, что в новом блоке будут исправлены только «неверные» транзакции, но это не затронет правильные.

CМАРТ-КОНТРАКТЫ

Смарт контракты в TON позволяют написать бизнес логику, которая будет выполняться децентрализованно. Контракты полноценные по Тьюрингу, и их предлагается писать на языке Fift. Fift — новый язык программирования, соз данный специально для TON; он имеет определенные сходства с Forth.

Для выполнения смарт контрактов была написана виртуальная машина — TON VM (Ton Virtual Machine). Но не стоит забывать, что воркчейн вместе с другими определяющими параметрами может иметь собственную вир туальную машину и собственный язык для смарт контрактов. Именно поэтому я не буду заострять внимание на Fift и TON VM в этой статье.

Подробности о Fift и TON VM можешь почерпнуть в документации проекта.

Ознакомиться с азами Forth или просто пос мотреть, как выглядит код на нем, тебе поможет статья «Загадочный Forth. Знакомимся с одним из важнейших языков программирования, о котором мало кто знает».

Смарт контракты в TON используются повсеместно: в TON Storage, TON DNS и других сервисах. Для валидации блоков и консенсуса тоже используются смарт контракты. Как ты уже понял, TON — платформа очень самодостаточ ная и совершенно не зависит от внешних факторов. Стоит еще упомянуть, что каждый аккаунт формально может являться смарт контрактом.

Замечу на полях, что компания TON Labs готовит компиляторы для других

TON DNS

TON DNS — один из сервисов TON. Используется для преобразования понят ных человеку идентификаторов (доменные имена, адреса) в адреса ADNL

и адреса TON Blockchain.

Использовать TON DNS можно, например, для передачи денег по иден тификатору вместо адреса кошелька. Это сильно упрощает дело, потому что теперь можно перевести сумму на понятный адрес или имя пользователя. Также идентификатор можно перенаправить на смарт контракт — например, выставляем счет на оплату в каком то магазине, а после перевода контракт обработает платеж.

Сам TON DNS реализован в виде нескольких специальных смарт контрак тов. Эти смарт контракты представляют собой древовидную структуру. Каж дый из них отвечает за регистрацию поддоменов для определенной зоны или домена. Корневой контракт, который обслуживает домены первого уров ня сети TON, находится в мастерчейне.

Регистрация нового домена (идентификатора) реализуется через отправ ку сообщения в смарт контракт, который отвечает за желаемый поддомен. Это стоит определенной суммы (как и все передаваемые сообщения); ука зываются ключ, владелец, сроки регистрации. Идентификаторы регистри руются в порядке очереди — кто успел, того и тапки.

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

ADNL

ADNL — собственный протокол, основной для TON. Это протокол, который используется на самом низком уровне. Главное его преимущество — не нуж но беспокоиться об адресах IPv4/IPv6, портах и т.д.: они все скрыты абстрак тным сетевым уровнем. Для обмена данными используются 256 битные сетевые адреса (названные «абстрактными сетевыми адресами»). Если говорить простым языком, это аналог SSL по UDP. Чтобы принимать и рас шифровывать сообщения, предназначенные для определенного адреса, необходимо иметь его приватный ключ. Для того, чтобы отправить сооб щение, необходимо (помимо адреса) знать публичный ключ получателя.

Сточки зрения большинства компонентов TON, существует только ADNL,

спомощью которого можно отправлять сообщения с одного адреса на дру гой. В текущем white paper сказано, что ADNL будет реализован через UDP

сопциональным откатом до TCP, если UDP будет недоступен. Еще в докумен те упоминается RLDP (Reliable Large Datagram Protocol) как похожий на TCP

протокол более высокого уровня.

CАЙТ В СЕТИ TON

Теперь, когда мы знаем про ADNL и TON DNS, можно поговорить о том, как может выглядеть создание сайта в TON. Такой сайт будет децентрализо ванно хоститься в TON Network. Сервисы, которые полностью находятся

вTON Network, называются ton services.

Вкачестве примера white paper описывает создание сервиса, который принимает запросы HTTP через RLDP. Чтобы реализовать его, нужен обычный браузер и прокси сервер, который будет переводить запросы HTTP в TON Network. Общаясь по протоколу RLDP, сервис может отвечать на запросы, а прокси сервер будет возвращать их клиенту в привычном формате.

Стоит упомянуть, что на этом этапе можно использовать TON DNS для «коротких» адресов. Это позволяет воссоздать привычный порядок вещей. В будущем мы можем увидеть какой нибудь TON Browser, аналогич ный браузеру для сети Tor.

ЗАКЛЮЧЕНИЕ

Как видишь, описать TON в двух словах непросто. Это большая и сложная система, которая состоит из разных низкоуровневых компонентов, и блок чейн TON — только один из них. Но TON при этом — это не только блокчейн.

Уже в этом году мы, возможно, будем наблюдать запуск полноценной сети. Скорее всего, некоторые компоненты платформы из тех, что описаны в этой статье, будут доступны позже других.

Однако уже сейчас можно испытать клиент и сеть на тестовой ноде. Если тебе интересна эта тема и тянет на эксперименты, можешь заглянуть в blockchain explorer или даже собрать клиент и ноду.

№09 (246)

Евгения Шарипова

Литературный редактор

РЕДАКТОРЫ РУБРИК

MEGANEWS

Мария Нефёдова nefedova@glc.ru

АРТ

yambuto yambuto@gmail.com

РЕКЛАМА

Анна Яковлева

Директор по спецпроектам yakovleva.a@glc.ru

РАСПРОСТРАНЕНИЕ И ПОДПИСКА

Вопросы по подписке: lapina@glc.ru Вопросы по материалам: support@glc.ru

Адрес редакции: 125080, город Москва, Волоколамское шоссе, дом 1, строение 1, этаж 8, помещение IX, комната 54, офис 7. Издатель: ИП Югай Александр Олегович, 400046, Волгоградская область, г. Волгоград, ул. Дружбы народов, д. 54. Учредитель: ООО «Медиа Кар» 125080, город Москва, Волоколамское шоссе, дом 1, строение 1, этаж 8, помещение IX, комната 54, офис 7. Зарегистрировано в Федеральной службе по надзору в сфере связи, информационных технологий и массовых коммуникаций (Роскомнадзоре), свидетельство Эл № ФС77 67001 от 30. 08.2016 года. Мнение редакции не обязательно совпадает с мнением авторов. Все материалы в номере предоставляются как информация к размышлению. Лица, использующие данную информацию в противозаконных целях, могут быть привлечены к ответственности. Редакция не несет ответственности за содержание рекламных объявлений в номере. По вопросам лицензирования и получения прав на использование редакционных материалов журнала обращайтесь по адресу: xakep@glc.ru. © Журнал «Хакер», РФ, 2019