В предыдущей статье мы описали ключевые особенности блокчейна Everscale. Сегодня мы предлагаем копнуть немного глубже и рассказать, благодаря чему достигается асинхронность в Everscale, являющаяся одним из ключевых элементов по достижению высокой масштабируемости, и о том, как с помощью асинхронности решаются проблемы современных блокчейнов на примере сравнений с синхронным блокчейном Ethereum, а также затронем особенности разработки в рамках экосистемы Everscale.

Асинхронность

Асинхронность в блокчейне Everscale складывается из двух составляющих:

1. Использование виртуальной машины TVM (Threaded Virtual Machine);

2. Применение модели акторов.

Модель акторов

Данная модель параллельных вычислений, описанная в 1973 году Карлом Хьюитом, нашла применение во многих параллельных системах. На ее разработку автора вдохновили такие языки программирования, как LISP и Simula. Далее, с оглядкой на данную модель вычислений были написаны такие языки программирования как Scala и Erlang.

Как в модели акторов, где актор — основная единица вычислений, способная принимать и отправлять сообщения, создавать других акторов и изменять свое состояние при получении сообщений от других акторов, так и в блокчейне Everscale основная единица — смарт‑контракт. Смарт‑контракты изменяют свое состояние при получении внешних (от приложений) или внутренних (от других смарт‑контрактов) сообщений, отправляют сообщения другим смарт‑контрактам, а также через отправку сообщений создают другие смарт‑контракты.

В анимации ниже демонстрируются некоторые сценарии взаимодействия между акторами в сети Everscale: смарт‑контракт отправляет исходящие сообщения для передачи токенов (сценарий 1), запроса исполнения логики другого смарт‑контракта (сценарий 2), создания новых смарт‑контрактов и записи новых данных в них (сценарий 3).

Threaded Virtual Machine

Ответственность за исполнение смарт‑контрактов в экосистеме Everscale лежит на TVM — Threaded Virtual Machine, в основу которой легла виртуальная машина от Николая Дурова — The Open Network Virtual Machine.

Анимация ниже демонстрирует работу виртуальной машины: после получения сообщения от смарт‑контракта, инициируется выполнение кода в TVM, результатом которого становится изменение состояния смарт‑контракта 2.

Использование виртуальной машины TVM позволило спроектировать блокчейн так, что обновление состояния блокчейна происходит в рамках асинхронной парадигмы. Для наглядности следует привести сравнение с обновлением состояния сети в EVM‑блокчейнах.

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

В TVM‑сетях обновление состояния сети основывается на обновлении состояния смарт‑контрактов, которые обмениваются сообщениями и обновляют свое состояние асинхронно. Любое действие пользователя раскладывается на взаимодействия между несколькими смарт‑контрактами. Исполнение смарт‑контракта генерирует транзакцию, которая должна быть завалидирована нодой.

Смарт‑контракты объединены в шард, за валидацию транзакций из которого ответственна одна группа нод‑валидаторов. При растущей нагрузке, шард (набор смарт‑контрактов) делится на несколько шардов, каждый из которых получает собственную группу валидаторов. При этом, смарт‑контракты из разных шардов все так же могут обмениваться сообщениями. Таким образом, одно действие пользователя может быть обработано в асинхронном режиме двумя или более нодами.

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

Блокчейны в блокчейне

Все описанное выше релевантно для работающего на данный момент воркчейна 0 и мастерчейна -1. Кратко, в воркчейне происходят взаимодействия между смарт‑контрактами, а мастерчейн несет служебную функцию и хранит данные о состоянии сети в целом.

Существует возможность развернуть до 232 воркчейнов, в каждом из которых валидация транзакций будет проходить асинхронно. Поскольку все 232 воркчейна объединены общим мастерчейном, смарт‑контракты из разных воркчейнов могут обмениваться сообщениями друг с другом. При этом, каждый воркчейн может быть гибко сконфигурирован под определенные нужды.

Стабильные комиссии

Согласно EIP-1559, актуальному на момент написания статьи, комиссии в Эфириуме изменяются динамически в зависимости от суммы газа, включаемой в каждый последующий блок (размер блока). В случае если сумма газа отличается от целевой, базовая комиссия поднимается на 12.5%, и так до тех пор, пока размер блока не придет к целевым значениям. Именно из‑за этого механизма и из‑за конкуренции за место в очереди по включению пользовательских транзакций в блоки комиссии в EVM‑сетях растут при повышении нагрузки на сеть. Данный механизм не может быть изменен, поскольку нодам требуется время для валидации блока, увеличение размера которого может привести к ситуации, когда менее производительные ноды будут не успевать валидировать блоки за отведенные 12 секунд.

Поскольку в TVM‑сетях нагрузка делится между несколькими валидаторами, ситуация, когда увеличение количества транзакций начнет оказывать влияние на работоспособность сети крайне низка, следовательно, необходимость в регулировании спроса на услуги сети через повышение комиссий отсутствует.

Модульная система комиссий

Асинхронность вычислений и самостоятельность смарт‑контрактов позволили разработать систему комиссий, состоящую из нескольких видов комиссий:

• Forwarding fee — комиссия, которой облагаются сообщения любого типа — внешние и внутренние, входящие и исходящие. Рассчитывается из размера сообщения. В зависимости от типа сообщения данная комиссия может распадаться на составные части, которые уходят валидаторам в качестве вознаграждения за обработку сообщений и включаются в расчеты Total action fee;

• Storage fee — рассчитывается за каждую секунду хранения данных внутри смарт‑контракта;

• Compute fee — взимается, если производятся расчеты на виртуальной машине;

• Total action fee — общая комиссия, рассчитываемая из всех отправленных сообщений, не взимается, если в результате транзакции не было отправлено ни одного сообщения;

Комиссии рассчитываются исходя из физического размера данных. Ноды вознаграждаются в соответствии с объемом данных транзакций, которые были ими завалидированы. C пользователей, в свою очередь, взимается комиссия исходя из типа совершенного действия и объема данных. Кроме того, размер каждой из комиссий может настраиваться.

В анимации ниже демонстрируется, как нагрузка на сеть оказывает влияние на размер комиссий в блокчейнах на базе EVM и TVM:

Ограниченное время хранения данных

Виталик Бутерин в одной из статей указывал на проблему хранения полного состояния блокчейна (по сути, всех данных, ранее использовавшихся в сети). Благодаря внедрению отдельной комиссии за хранение данных в TVM‑сетях ненужные данные (хранящиеся в смарт‑контрактах, балансы которых не пополняются на протяжении продолжительного времени) будут автоматически удаляться. Таким образом, новым пользователям сети не придется оплачивать хранение старых неиспользуемых данных.

Нативные абстрактные аккаунты

Мы уже отмечали, что все акторы в Everscale — смарт‑контракты. Вследствие этого, в TVM‑сетях не существует как таковых аккаунтом под внешним управлением (Externally Owned Accounts — EOA). Вместо них в Everscale изначально реализованы абстрактные аккаунты — ценные активы хранятся в смарт‑контракте, а их отправка инициируется получением внешнего или внутреннего сообщения. Таким образом, даже кошелек в сети Everscale — смарт‑контракт, управляемый внешними сообщениями. В сети Ethereum абстрактные аккаунты также реализованы, однако они работают поверх протокола и их доработка еще активно ведется.

Механизм управления балансами абстрактного аккаунта позволяет реализовать дополнительный функционал:

• Возможность восстановления доступа к средствам:

• Возможность гибкой настройки лимитов на отправку средств:

• Возможность включения адресов в черный список:

• Возможность использования одного абстрактного аккаунта несколькими пользователями:

Оплата действий в блокчейне определенной стороной

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

Возможность локального чтения состояния сети

В TVM‑сетях реализована возможность скачивания текущего состояния сети и его локального чтения без отправки дополнительных сетевых запросов с помощью Evernode Simple Emulator. В EVM‑сетях чтение данных, получаемых от исполнения метода смарт‑контракта, требует отправки отдельного запроса на RPC URL эндпоинт.

Очевидный механизм обновления функционала

В EVM‑сетях для обновления функционала смарт‑контрактов необходимо использование прокси смарт‑контрактов и делегирующих вызовов (delegatecall). Существует несколько стандартов обновления логики смарт‑контрактов: Transparent Proxy, UUPS Proxy, Multi‑Facet Proxy (diamond) и фреймворк OpenZeppelin для безопасной разработки смарт‑контрактов.

Механизмы обновления логики в EVM‑сетях значительно отличается от той, к которой привыкло большинство разработчиков: обычно обновление ограничивается загрузкой новой версии кода на сервер и перезапуском приложения.

В TVM‑сетях реализован более привычный механизм обновления смарт‑контрактов: смарт‑контракт принимает новую версию кода из входящего сообщения и через опкод setcode применяет обновление логики.

Итого для обновления логики смарт‑контракта требуется написание нескольких строк кода:

// Если владелец знает, что в Рут контракте есть новая версия кода, 
  // он может запросить апгрейд для себя.
  function upgrade(address remainingGasTo) override external onlyOwner {
    ITokenRootUpgradeable(root_).requestUpgradeWallet{ value: 0, flag: TokenMsgFlag.REMAINING_GAS, bounce: false }(
      version_,
      owner_
    );
  }

  // В ответ он получает новую версию кода 
  function acceptUpgrade(TvmCell newCode, uint32 newVersion) override external onlyRoot {
    if (version_ != newVersion) {
      // Кодируем весь стейт контракта в TvmCell + новую версию
      TvmCell state = abi.encode(root_, owner_, balance_, version_, newVersion);
      // Устанавливаем контракту новый код начиная со следующей транзакции
      tvm.setcode(newCode);
      // Устанавливаем новый код прямо в текущей транзакции
      tvm.setCurrentCode(newCode);
      // Вызываем функцию onCodeUpgrade уже нового кода.
      onCodeUpgrade(state);
    }
  }
}

// Функция onCodeUpgrade в новой версии контракта, после setCurrentCode
// можно вызвать только ее.

function onCodeUpgrade(TvmCell data) private {
  // Сбрасываем сторадж контракта в 0, потому что если мы 
  // добавили какую-нибудь переменную, у нас бы изменилась
  // структура стораджа. Этот вызов не трогает служебные 
  // переменные _pubkey, _replayTs, _constructorFlag, 
  // остальные переменные во временном регистре c7 он инициализирует
  // нулями.
  tvm.resetStorage();
  
  // декодируем стейт 
  (address root, address owner, uint128 balance, uint32 fromVersion, uint32 newVersion) =
        abi.decode(data, (address, address, uint128, uint32, uint32));

  // инициализируем стейт
  root_ = root;
  owner_ = owner;
  balance_ = balance;
  version_ = newVersion;
}

Привычные инструменты разработки

Экосистема TVM‑сетей располагает инструментами, аналогичными тем, которые используются для разработки в EVM‑совместимых сетях:

• Locklift — аналог Hardhat:

  • Управление работой с разными сетями (main, test, local);

  • Автотесты смарт‑контрактов на Mocha;

  • Управление ключами;

  • Исполнение скриптов из предпочтительного окружения.

• Everscale Inpage Provider — аналогичен web3.js в EVM‑сетях:

  • Привычный для фронт‑энд EVM разработчика API;

  • Необходим для интеграции с браузерным расширением.

Нативная индексация блокчейна

В отличие от блокчейна Ethereum, для индексирования данных из которого требуется обращение к сторонним проектам: Infura и The Graph, Everscale предлагает собственные готовые решения для индексации.

Существует возможность установки сборки ноды с индексатором и GraphQL API с публичными эндпоинтами. Такое решение подойдет как начинающим, так и тем, для чьих проектов требуется углубленная аналитика данных из блокчейна. Благодаря открытому исходному коду индексацию можно адаптировать под конкретные нужды.

Кроме того, можно еще более гибко кастомизировать индексирование данных путем написания собственного индексатора, отправляющего данные в предпочтительную для разработчика базу. Такой подход реализуется с помощью легкой версии ноды Light Node и Kafka (ton‑kafka‑producer).

Экосистема TVM-сетей

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

• Octus Bridge — мост, позволяющий переносить активы из других сетей (git);

• Ever Name — система доменных имен на Everscale;

• FlatQube — децентрализованная биржа (git);

• Gravix — децентрализованная платформа для торговли деривативами (git);

• TokStock — NFT маркетплейс;

• Qamon — децентрализованная защищенная электронная почта.

Другие продукты экосистемы Everscale можно найти здесь.

Двери экосистемы открыты для всех желающих. Смотрите, изучайте, пробуйте, разрабатывайте и, конечно же, задавайте вопросы в комментариях.