Admin
Администратор
И хотя никаких публичных заявлений Дуров не делал, работа над проектом идет вовсю. Документация и код TON доступны всем желающим по адресу test.ton.org, а на GitHub появилась организация ton-blockchain, которая опубликовала исходный код TON Blockchain Software.
Что такое 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) для входящих и исходящих сообщений определенного аккаунта.
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 в этой статье.
Смарт-контракты в TON используются повсеместно: в TON Storage, TON DNS и других сервисах. Для валидации блоков и консенсуса тоже используются смарт-контракты. Как ты уже понял, TON — платформа очень самодостаточная и совершенно не зависит от внешних факторов. Стоит еще упомянуть, что каждый аккаунт формально может являться смарт-контрактом.
Замечу на полях, что компания TON Labs готовит компиляторы для других языков программирования, чтобы писать смарт-контракты можно было не только на Fift. Компиляторы для C и Solidity уже можно посмотреть на ton.dev.
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 или даже собрать клиент и ноду.
Источник - https://xakep.ru/2019/09/10/ton/
