Улучшение производительности смарт контракта

https://docs.elrond.com

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

Одна такая ВМ должна удовлетворять интерфейсу и получать доступ только для чтения к данным, существующим в блокчейне, через набор хуков. Через этот интерфейс виртуальная машина получает доступ к криптографическим и хеш-функциям. Умный контракт может взаимодействовать с блокчейном через четко определенный API. Все выходные данные, генерируемые Смарт Контрактом(например, изменение баланса), сохраняются в так называемом VMOutput на уровне виртуальной машины. После полного выполнения смарт-контракта выходные данные виртуальной машины возвращаются в протокол. Затем протокол выполняет базовую проверку и обновляет состояние измененных учетных записей.

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

До сих пор в Elrond был развернут один компонент виртуальной машины с протоколом: формально проверенная виртуальная машина для языка IELE, сгенерированная K Framework с помощью нашего внутреннего интерфейса Go. Язык великолепен, так как он был создан для целей смарт контракта блокчейна, виртуальная машина формально проверена, что означает математически доказательство того, что все поведение является детерминированным.

Но IELE не является хорошо известным языком для умных контрактов, поэтому мы спросили себя, почему бы не поддерживать больше языков, больше виртуальных машин, каждый из которых оптимален для разных целей. А поскольку виртуальные машины в нашей архитектуре уже являются модульным компонентом, мы можем создавать больше таких компонентов, помещать их в контейнер и вызывать тот, который необходим для работы в любое конкретное время. Поэтому, имея это в виду, мы решили продолжить поиск следующей виртуальной машины, которая будет интегрирована в Elrond.

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

• Умный код контракта должен быть легким для чтения и простым в написании.
• Поймайте очевидные ошибки во время компиляции, и он должен иметь линтер для всего, что невозможно отловить во время компиляции.
• Скомпилируйте очень компактный байт-код, чтобы обеспечить дешевое развертывание интеллектуальных контрактов.
Должно быть легко узнать, как использовать API
• Он должен также максимально интегрироваться с остальной частью экосистемы, чтобы инструменты можно было повторно использовать и избежать повторной реализации кода.
• Поддержка инструментов и детерминизм для языков общего назначения

И выбор был: WASM

WebAssembly (часто сокращенно до Wasm) — это открытый стандарт, который определяет переносимый формат двоичного кода для исполняемых программ и соответствующий язык текстовой ассемблера, а также интерфейсы для облегчения взаимодействия между такими программами и их хост-средой. Основной целью WebAssembly является обеспечение высокопроизводительных приложений на веб-страницах, но формат предназначен для выполнения и интеграции в других средах.

WebAssembly является целью виртуальной машины, которая (в отличие от большинства виртуальных машин) обычно пытается соответствовать семантике архитектуры ЦП, такой как ARM или x86, вместо того, чтобы пытаться соответствовать семантике языка, который на нем работает. В результате многие языки могут скомпилировать его без изменений. Поскольку большинство языков программирования построены так, чтобы на определенном уровне раскрывать семантику ЦП, наличие виртуальной машины, эмулирующей ЦП, является хорошим наименьшим общим знаменателем. Это также позволяет нам использовать оптимизирующие компиляторы мирового класса, которые были созданы для ISA, таких как x86 и ARM, — это очень важно, когда вы платите по инструкции. У solc есть флаг — optimize, но, насколько я могу судить, все, что он делает, это удаляет неиспользуемые цели перехода из списка разрешенных целей в метаданных сборки, что является скорее функцией безопасности, чем оптимизацией.

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

Wasm расширяет семейство языков, доступных для разработчиков умных контрактов, и включает в себя Rust, C / C ++, C #, Typescript и многое другое. Это означает, что вы можете писать умные контракты на любом языке, с которым вы знакомы, компилировать его из WASM и даже легко отлаживать его WAT человек читаемый формат. Дополнительные преимущества для WebAssembly:

• Безопасный для памяти, песочница и независимый от платформы.
• Поддержка 64-битных и 32-битных целочисленных операций, которые отображаются один на один с инструкциями процессора.
• Легко становится детерминированным, удаляя операции с плавающей точкой
• Поддерживается проектом инфраструктуры компилятора LLVM, что означает, что Wasm извлекает выгоду из более чем десятилетней оптимизации компилятора LLVM.
• Постоянно разрабатывается крупными компаниями, такими как Google, Apple, Microsoft, Mozilla и Facebook.

Что касается части реализации, мы рассмотрели существующую интеграцию и обсудили, использовать ли интерпретаторы или компиляторы. Одной из причин выбора WASM была скорость: мы хотели иметь самую быструю виртуальную машину / двигатель. Эти движки в основном написаны на C ++, а наш протокол на GO, но с cgo эти два могут хорошо работать вместе.

Мы хотели использовать двигатели WASM в их лучшем виде, как бы они ни были, с минимальными накладными расходами, желательно без. Команда eWasm проделала большую работу по интеграции WABT, Bynarien и WAVM через heraVM в Ethereum, и код выглядел многообещающим. Движки WASM остались такими же чистыми, как и они, добавив определение хуков блокчейна в качестве определенных функций при каждом запуске смарт-контракта. (Кстати, это место дальнейшего улучшения — сделайте эти вызовы частью базовой системы, делайте это только один раз, а не при каждом запуске / развертывании).
Итак, мы взяли код и начали создавать собственный адаптер для него, который поддерживает интерфейс Elrond VM. Но при написании адаптера мы сделали несколько оптимизаций, чтобы умные контракты работали быстрее. Умный контракт может получить доступ к нескольким «системным» функциям для чтения и записи в состояние блокчейна, чтобы управлять балансом счетов. В нашей интеграции hera мы максимально приближаем эти функции и данные к работающему движку — имея большую часть данных непосредственно в адаптере.
Таким образом, в смарт-контрактах хуки цепочки блоков используются только тогда, когда у адаптера нет данных, запрашиваемых смарт-контрактом. Если учетная запись была затронута в ходе выполнения интеллектуального контракта, все ее данные передаются на адаптер. Следующие операции чтения из этих учетных записей будут решаться непосредственно на адаптере — больше не нужно тратить время на переход к блокчейну.
Кроме того, в Elrond виртуальные машины получают доступ только для чтения к блокчейну, в то время как любая записываемая ими запись выполняется в локальный кеш, который записывается в состояние только в конце обработки интеллектуального контракта. Запись в эти кэши выполняется очень быстро, и в случае с hera это происходит непосредственно в адаптере. Окончательная запись в состояние блокчейна выполняется только протоколом, после базовой проверки — постоянно поддерживая безопасность системы.
Поскольку hera внедрило интерфейс среды Ethereum и создал поверх него адаптер, это означает, что Elrond напрямую поддерживает EEI: интеллектуальные контракты, написанные для Ethereum, также могут быть развернуты и запущены в протоколе Elrond (с небольшой модификацией: изменение обработки адресов с 20 байт до 32 байт).

Наши критерии для умных контрактов, работающих по протоколу с использованием WASM:

Машина, используемая для этого теста — Asus ZenBook — 14-дюймовый ультрабук
  • Fibonacci 32 используется во многих открытых тестах в космосе, поэтому мы сделали то же самое. Мы написали простой контракт на C, скомпилировали его в WASM, развернули в протоколе и вызвали через транзакции. Результаты: среднее время обработки 16 мс
  • Процессор вычисления 8000 также был протестирован. Составлено так же, как Fibonacci 32. Итоговое среднее время обработки: 3,9 мс
  • Конкат строки 10000: конкатенация строки длиной 44 символа 10000 раз заняла в среднем 6,7 мс.
  • Еще один тест выполнял контракты ERC20. Наш тест содержал 100K транзакций передачи ERC20, которые запускались несколько раз. Среднее время обработки для перевода в контракте ERC20 составляет 0,29 мс. Это означает, что в одном блоке, где предел создания блока равен 1 секунде, протокол способен помещать ~ 3350 транзакций • ERC20 (включая проверку, обработку и принятие). В Elrond раунд длится 4 секунды, первая секунда отводится лидеру для создания блока, следующие 3 секунды — для распространения, проверки и подписания.

Как мы решаем, какая виртуальная машина нужна для смарт контракта?

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

  • первые 8 байтов равны нулю
  • следующие 2 байта определяют идентификатор виртуальной
  • машины, на котором будет выполняться интеллектуальный контракт
  • Байты 11–30 равны sha256 (smart_contract_owner_address + nonce) [11:30]
  • Последние 2 байта являются идентификатором осколка

Во время развертывания владелец смарт-контракта отправляет транзакцию на зарезервированный адрес 0x0000000000000000000000000000000. Протокол знает, что эта транзакция особого типа: развертывание смарт-контракта. В поле данных транзакции владелец отправляет байт-код смарт-контракта в шестнадцатеричном формате и идентификатор виртуальной машины (2 байта), разделенные символом «@». Во время развертывания вычисляется адрес смарт-контракта (sha256 (smart_contract_owner_address + nonce)), и код смарт-контракта сохраняется в состоянии этого адреса.

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

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

  • первые 4 байта являются селектором функций (sha256 (функция) [0: 4])
  • каждый аргумент переводится из шестнадцатеричного в массив длиной 32 байта

Следующие шаги

  • Дальнейшая оптимизация интегрированных движков и создание набора базовых библиотек с наиболее необходимыми функциями.
  • Ранние следующие шаги — создание простых скриптов, объяснение API для ранних разработчиков на нескольких языках — начиная с C / C ++, затем для JavaScript, TypeScript, Rust (могут последовать другие).
  • Но API и сценариев недостаточно, чтобы разработчик чувствовал себя хорошо при создании нового приложения, ему нужны инструменты. Elrond продвинет вперед и создаст / интегрирует несколько инструментов для разработчиков, чтобы упростить разработку новых и удивительных приложений dApp.

Вывод

Elrond построен с учетом безопасности и скорости. Мы продемонстрировали скорость обработки транзакций более 50 тыс. TPS на нашей архитектуре с разделением по частям, и зрелая, быстрая виртуальная машина обязательна, чтобы не отставать от нашего протокола. Интеграция WASM, ключевого компонента новой децентрализованной сети, является шагом вперед в достижении очень высокой пропускной способности даже для транзакций с умными контрактами. Преимущества WASM на этом не заканчиваются: поддержка нескольких языков, изолированная среда, разработанная и поддерживаемая крупными компаниями. Наш сверхбыстрый специализированный адаптер в сочетании с двигателями WASM с обнаженным костяшком достиг очень высоких скоростей обработки.

Для получения дополнительной информации, пожалуйста, посетите нас:

--

--

--

Love podcasts or audiobooks? Learn on the go with our new app.

Get the Medium app

A button that says 'Download on the App Store', and if clicked it will lead you to the iOS App store
A button that says 'Get it on, Google Play', and if clicked it will lead you to the Google Play store
Marsel Marsel

Marsel Marsel

More from Medium

Unit testing - Data Layer — Dacpac file

“I Am in Fact a Hobbit (in all but size)”

A Vicious, Voiceless Voice