Сергей Прилуцкий, известный блокчейн-эксперт, руководитель отдела исследований компании MixBytes и проекта SmartZ во время проведения Telegram Eventing поделился подробной информацией о проекте Павла Дурова TON. Данные были получены после изучения закрытой информации о текущем состоянии разработки TON и будут интересны не только узким специалистам, но и широкому кругу потенциальных инвесторов.
Общедоступная информация
Финансирование на разработку проекта TON было собрано в ходе проведения двух раундов закрытого ICO. Благодаря этому удалось собрать $1.7 млрд инвестиций, минимальный размер доли составил $20 млн, участие в ICO приняли около 100 инвесторов, среди которых был и Роман Абрамович.
Весь объём внутренней криптовалюты проекта будет выпущен сразу и составит 5 млрд коинов GRAM. После запуска проекта токены ICO у инвесторов будут обменяны на коинов в соотношении 1 к 1.
Технические особенности блокчейна TON
В сети TON консенсус обеспечивается специальными узлами-валидаторами, которые получают комиссию за свои услуги. Нечто подобное реализовано в протоколе Ripple. Достоверность транзакции подтверждается по BFT-алгоритму (задача византийских генералов).
Микроплатежи не отображаются сразу в блокчейне, виден только их хеш. Чтобы обеспечить валидность микротранзакций каждый валидатор должен иметь на счету некоторую залоговую сумму в коинах GRAM, которая предоставляется номинаторами. Валидатор не может провести больше транзакций, чем он способен обеспечить залоговыми монетами. В случае проведения ошибочного платежа валидатор и номинатор из этой суммы переводят коины на счета других валидаторов для покрытия их расходов на обеспечение проведения транзакции.
Каждый узел сети отвечает за свою часть блокчейна, которая делится на небольшие кусочки – шарды (shardes). При существенном увеличении нагрузки на сеть, часть шардов может быть передана соседним узлам сети. Эту идею разработчики TON назвали «Infinite Sharding». Подобное строение блокчейна позволяет не только легко разделять шарды, но и автоматически восстанавливать повреждённые участки.
Информация, полученная в ходе исследования экосистемы TON
Сергеем Прилуцким было проведено глубокое исследование проекта TON, во время которого всплыли интересные особенности нового проекта. Ниже мы предлагаем ознакомиться с детальной информацией о структуре и особенностях блокчейн-платформы Telegram Open Network (TON).
Идея Infinite Sharding
Главная концепция платформы TON – это сообщение. Пользователь может отправить его извне блокчейна на адрес любого аккаунта системы. Подобная процедура вызывает создание сообщение другим аккаунтам сети. Причём состояние отдельного аккаунта можно представить себе в виде собственного блокчейна (accountchain). Он по своей сути является хранилищем входящих и исходящих сообщений.
Множество аккаунтов-шардов (shardes) объединяются в Shardchain, блокчейн который обслуживается узлом-валидатором. Внутренний состав такого шардчейна может меняться динамически, в зависимости от нагрузки на конкретный узел сети.
Множество шардчейнов объединяются в воркчейн (Workchain), ещё одну блокчейн-структуру, за счёт одинакового префикса в своём адресе. В свою очередь все воркчейны образуют один мастерчейн (Masterchain), который и является общим блокчейном для сети TON. Остановимся поподробнее на этих структурах.
Masterchain
Мастерчейн представляет собой основную цепочку, которая устанавливает правила для всех цепочек блокчейнов более низкого уровня. Её роль – контроль глобального состояния всей Telegram Open Network и управление нею.
Особенность мастерчейна в том, что в ней нет разветвления и слияния отдельных частей, т.е. в этом она напоминает классический блокчейн. Каждый блок мастерчейна содержит хеши последних шард-блоков, организованных в бинарное дерево, и хранит состояние системных смарт-контрактов, а также их код. Контроль за PoS, данные о валидаторах, участниках сети – всё это хранится в мастерчейне. Однако точной информацию по этому поводу найти не удалось, а та, что есть – ненадёжная и не окончательная.
Управление мастерчейном основано на системных смарт-контрактах, которые содержат такие глобальные параметры:
- Общее количество и другие характеристики коина GRAM.
- Список узлов-валидаторов, параметры их доли, адрес контракта по которому происходит ежемесячный выбор новых валидаторов.
- Параметры TVM (TON Virtual Machine), его версия, минимальная и максимальная цена gas – по аналогии с Ethereum.
- Смарт-контракты дополнительных токенов и их состояние.
Важно, что все изменения глобальных параметров TON принимаются консенсусов более 2/3 всех валидаторов согласно BFT-алгоритму.
Workchain
Воркчейн – это условный блокчейн, объединяющий шардчейны одинакового типа. Его идентификатор является префиксом для id-номера шардов, он необходим для точной маршрутизации сообщений.
В TON предусмотрено достаточно места для множества воркчейнов (2^32 что соответствует приблизительно 4,3 млрд воркчейнов), причём в каждом из них можно организовать свою логику сообщений. Например, один воркчейн может обслуживать контракты Ethereum, а другой реализовывать анонимные UTXO (неизрасходованные монеты), как это сделано в ZCash.
Shardchain
Шардчейн является основной рабочей единицей в сети TON. Шардчейн – это отдельная цепочка блоков, которая отправляет и принимает сообщения от других шардов, т.е. это блокчейн, обслуживающий свой набор аккаунтов.
Каждый валидатор содержит у себя полный список своих шардов и только часть блоков от соседних. Валидатор производит новые блоки в своём шардчейне, отправляя и принимая сообщения от других шардов. На этом уровне уже возможно разделение и слияние цепочек блоков шардчейна. Схематически это выглядит как DAG (направленный ациклический граф), где каждый блок имеет нескольких родителей, которыми являются последние блоки объединившихся шардчейнов.
Shard-блоки
Каждый шард-блок должен содержать в себе некий обязательный набор данных, т.н. неделимую часть. Она включает в себя:
- Хеш предыдущего блока и, возможно, хеши родителей в случае слияния шардчейнов.
- Подписи валидаторов для уже акцептированных блоков.
- Номер последнего известного мастерчейн-блока.
- Хеши начального и конечного состояния шарда для этого блока.
- Очередь исходящих сообщений в виде списка сообщений, направленных в другие шарды.
Accountchain
Аккаунтчейн – это начальный уровень блокчейна TON. Каждый идентификатор аккаунта представляет собой 256-битный ключ + идентификатор воркчейна. Например, адрес смарт-контракта будет выглядеть так:
1:81525a3672b55678d4139b993b542c5c9735ac41b653d963a42855c9834b6921a4.
А адрес аккаунта пользователя так:
Ef+BVndfdQ45nUdlsfsmv68KBHGSgBJsfsv58dG2SE4oPMgs4.
Сам аккаунт получает и принимает сообщения (естественно это не сообщения из Telegram). Они могут содержать в себе токены GRAM, быть вызовами смарт-контрактов, представлять любые другие данные и т.д.
Все сообщения обрабатываются только тогда, когда они доставлены в нужный шард. При этом могут свободно перемещаться через промежуточные шарды. Также сообщения могут поступать извне блокчейна TON, т.е. быть «сообщениями из ниоткуда».
Account
Любой аккаунт представляет собой смарт-контракт, возможно даже с пустым кодом. Каждый аккаунт платит комиссию за хранение данных, т.е. его баланс со временем уменьшается. Аккаунт содержит в себе информацию о балансе токенов GRAM, код контракта или его хеш, время нахождения в сети, начиная с появления корневой ячейки, статистику использования хранилища данных (например, по времени последней оплаты хранения), формальное описание интерфейса.
Низкоуровневое хранение, ячейки
Хранение всех данных в блокчейне TON происходит в структурах, которые называются ячейки. Это основная единица для измерения размеров всех элементов сети: сообщений, кода контрактов, самых разнообразных данных.
Каждая ячейка содержит 1023 бита информации и до 4-х ссылок на соседние ячейки. Бывает 256 различных типов ячеек, которые отличаются способом реализации и количеством ссылок на другие ячейки. Все они объединены в дерево с количеством связей для каждого элемента от 0 до 4. Ячейки используются для унифицированного хранения и детерминированного оперирования в хранилище блокчейна.
Внутренние алгоритмы TON
Со структурой блокчейна TON и его основными элементами мы уже познакомились. Теперь очередь за принципами их работы и их основополагающими понятиями.
Логическое время
Как мы узнали ранее, структура данных в TON представляет собой DAG, как, в принципе, и у 90% других криптовалют, включая биткоин. Для фиксации факта доставки сообщения или события в блокчейне используется монотонный счётчик при операциях с ними, причём каждое такое сообщение содержит своё собственное время.
Из-за отсутствия центральных серверов синхронизации времени, использование абсолютного времени внутри сети может приводить к различным ошибкам. Именно поэтому в системах сообщений решили остановиться на логическом времени.
Сообщение
Что представляет собой сообщение? Это абсолютно любая операция между шардами. Любой шард-блок обязан иметь входящее сообщение из исходящего сообщения от другого существующего и валидного шард-блока. Для подтверждения истинности сообщения позволяется хранение только нескольких блоков из цепочки отправителя, обязательно хранение её неделимой части.
Также запрещено обрабатывать входящее сообщение, пока не получено доказательство доставки более ранних исходящих сообщений хотя бы от следующего шарда. Подобный подход заставляет валидаторов ставить в приоритет вначале отправку сообщений и лишь затем их приём.
Instant Hypercube Routing
Как теперь понятно, каждый шард, по сути, это очередь из входящих и исходящих сообщений. Для поиска нужного аккаунта и кратчайшего пути к нему используется ускоренный вариант алгоритма «гиперкуба». Это приводит к тому, что если в назначении указан свой шард, то транзакция передаётся нужному аккаунту, а порождённые ей новые сообщения размещаются в очереди исходящих сообщений. В том случае, когда адресатом служит чужой шард, то, по детерминистическим правилам маршрутизации, сообщение перекладывается во входящие сообщения следующего шарда.
Включение очереди сообщений в блоки – это новое решение в технологии блокчейн. Благодаря такому подходу, состояние сообщения можно сразу же отследить в блокчейне. Глобально же, весь массив отправляемых сообщений между шардами представляет собой сложный многомерный направленный ациклический граф (DAG). Однако, в настоящий момент окончательной ясности по поводу работы гарантий доставки сообщений адресату в таком DAG нет.
Смарт-контракты
В TON создание смарт-контракта или аккаунта представляет собой одно и то же. В случае отправки токенов GRAM на несуществующий адрес, он создаётся как пустой контракт с балансом, отличным от 0. Как говорилось ранее, любой аккаунт, что-то хранящий в блокчейне, платит комиссию за хранение. Поэтому при создании смарт-контракта надо обеспечить ему баланс в GRAM на оплату места в хранилище, или даже вначале обеспечить баланс, а затем уже размещать код смарт-контракта.
Есть также готовые библиотеки смарт-контрактов в мастерчейне. Каждый контракт обладает такими свойствами:
- Контракт может создавать новый контракт.
- Можно разместить хеш от кода смарт-контракта и только потом продемонстрировать его.
- Код смарт-контракта может быть изменён, но это должно быть предусмотрено в коде изначального смарт-контракта.
- Можно в блокчейне не хранить код смарт-контракта, но тогда аккаунту будут доступны только входящие сообщения. Код и данные будут храниться вне блокчейна.
- Код и состояние «умирающего» смарт-контракта (баланс которого близок к 0) заменяется на хеш его кода. С помощью хеша смарт-контракт ещё можно восстановить при условии пополнения баланса, в противном случае через несколько месяцев удалится и хеш.
В целом можно сделать вывод, что поведение и свойства аккаунтов в TON похожи одновременно на Bitcoin и Ethereum.
TVM (TON Virtual Machine)
Виртуальная машина TON представляет собой новую разработку в области работы смарт-контрактов. Она является детерминированной и стековой. Поэтому легко масштабируется и отлично справляется с упаковкой данных в ячейки. На TVM удобно вести подсчёт расходов GRAM за исполнение смарт-контрактов и очень просто восстанавливать смарт-контракты.
Модель ограничений в TVM построена на gas, а эллиптическая криптография реализована на защищённой кривой ed25519.
Язык смарт-контрактов
В TON используется низкоуровневый и крайне детерминистичный язык Fift, прототипом которому послужил язык FORTH (вероятно, поэтому и выбрали имя Fift). Он представляет собой конкатенативный, стековый язык для микроконтроллеров. К сожалению, для написания смарт-контрактов со свойствами детерминизма и максимальной экономичности придумали всего два варианта: EVM (Ethereum Virtual Machine) и WASM (WebAssembly).
Fift строго типизирован, в нём существует полтора десятка типов, в том числе и сложных (Tuple, List, Odject).
Вся идея этого языка построена вокруг «слов»-операторов: присутствует множество разных слов для манипуляции со стеком, функций, логических блоков, переменных – всё это подвержено центральной концепции «слова»-оператора.
К примеру, так выглядит код по выводу двух чисел Фибоначчи больших 1000:
{ 1 0 rot { -rot over + swap rot 2dup >= } until drop } : fib-gtr
1000 fib-gtr
Здесь:
- dop (xx x), создаёт дубликат значения вершины стека. Если стек пустой, то генерирует ошибку исключения.
- drop (x ),удаляет значение вершины стека.
- swap (xyyx), меняет местами два ближайших к вершине стека значения.
- rot (xyzyzx), проворачивает три значения, ближайших к вершине стека.
- -rot (xyzzxy), проворачивает три значения, ближайших к вершине стека, в обратном направлении. Эквивалент rot rot.
- over (xyxyx), создаёт копию второго значения в стеке и помещает в вершину стека.
- tuck (xyyxy), эквивалент swap over.
- nip (xyy), удаляет второе от вершины значение в стеке. Эквивалент swap drop.
- 2dup (xy-xyxy), эквивалент over over.
Следует заметить, что многие разработчики в шоке от такого синтаксиса и перед изучением документации по Fift, рекомендуется изучить таковую по FORTH.
По какой же причине разработчики выбрали в качестве языка для смарт-контрактов именно Fift? Возможно, потому что в таком виде он отлично подходит для формальной верификации и более устойчив к ошибкам, требуя от разработчиков приложений, полного понимания последовательности выполнения любых операций.
Общие впечатления от TON
В целом построение экосистемы TON вызывает приятное впечатление. Среди достоинств следует отметить:
- Новую, экономичную реализацию хранения данных. Это свидетельствует о серьёзном подходе к проблеме размера блокчейна.
- Примитивную систему сообщений, подобную используемой в GO.
- Обработка цепочки сообщений, пул памяти на блокчейне, почти вся информация о транзакции берётся из блокчейна, а не из внешних источников.
- Воркчейн для хардфорков или радикальных изменений в консенсусе, криптографии, виртуальной машине для смарт-контрактов. Это позволяет теоретически прикрутить к TON блокчейны биткоина, эфириума или ЭОС как новый воркчейн.
Управление TON с помощью смарт-контрактов – отлично зарекомендовавший себя метод. Например в Ethereum, EOS, Polkadot и др.
С точки зрения разработчика, нода TON – это несколько блокчейнов: мастерчейн, воркчейн, шардчейн.
Интерфейсы смарт-контрактов хранятся рядом со смарт-контрактами, что очень удобно для dApp, т.к. обеспечивает простейшее взаимодействие с ними.
Все ресурсы блокчейна честно оплачиваются, вплоть до аренды хранилища данных. Нет никаких скидок для крупных держателей GRAM или валидаторов.
Единственное, что хотелось бы изменить – это наличие более понятного механизма реализации формального доказательства доставки сообщений. Особенно учитывая многообразие вариантов топологии сети.
Заключение
WhitePaper проекта создаёт впечатление о том, что разработчики взяли лучшие рабочие паттерны из множества современных проектов, и по каждому из них сделали что-то своё. Здесь есть части, работающие как UTXO биткоина (сообщения, аккаунты), есть как EVM (смарт-контракты, управление), есть новые индивидуальные разработки (шарды, маршрутизация), а есть адаптация старых решений под свой проект (язык смарт-контрактов, ячейки хранилища).
В общем можно сказать, что TON вызывает закономерный интерес у огромного числа разработчиков и пользователей. К сожалению, пока кроме TVM примеров кода смарт-контрактов и тестовой ноды, которая с большой вероятностью хотя бы частично является эмуляцией, больше ничего нет. Полноценного запуска TON остаётся лишь с нетерпением ждать.