Повышение эффективности исполнения смарт-контрактов

Thomas — Crypto Expert
7 min readOct 11, 2019

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

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

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

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

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

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

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

И выбор был: WASM

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

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

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

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

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

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

Мы хотели использовать двигатели WASM в лучшем виде, голые, как они есть, с минимальными накладными расходами, насколько это возможно, предпочтительно нет. Команда eWasm проделала большую работу по интеграции WABT, Bynarien и WAVM через heraVM в Ethereum, и код выглядел многообещающим. Двигатели WASM были оставлены такими же чистыми, как и они, добавив определение крючков blockchain как определенные функции при каждом запуске смарт-контракта. (Кстати, это место дальнейшего улучшения — сделайте эти вызовы частью базовой системы, сделайте это только один раз, а не при каждом запуске/развертывании).

Поэтому мы взяли код и начали создавать свой собственный адаптер к нему, который поддерживает интерфейс ELROND VM. Но при написании адаптера мы сделали несколько оптимизаций, чтобы смарт-контракты работали быстрее. Смарт-контракт может получить доступ к нескольким” системным “ функциям для чтения и записи в состояние блокчейна, для манипулирования балансом счетов. В нашей интеграции hera, мы приносим эти функции и данные как можно ближе к работающему движку — имея большую часть данных в адаптере напрямую.

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

Кроме того, в Elrond виртуальные машины получают доступ только для чтения к блокчейну, в то время как любая запись, которую они делают, производится в локальный кэш, который записывается в состояние только в конце обработки смарт-контракта. Запись в эти кэши происходит очень быстро, и в случае с hera это происходит непосредственно в адаптере. Окончательная запись в состояние blockchain выполняется только по протоколу, после базовой проверки-сохраняя систему в безопасности все время.

Поскольку hera реализовала интерфейс среды Ethereum, и мы создали над ним адаптер, это означает, что Elrond напрямую поддерживает EEI: смарт-контракты, написанные для Ethereum, могут быть развернуты и запущены в протоколе Elrond (с небольшой модификацией: изменение обработки адресов с 20 байт до 32 байт).

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

  • Фибоначчи 32 используется во многих открытых бенчмарках в пространстве, поэтому мы сделали то же самое. Мы написали простой контракт на C, скомпилировали его в WASM, развернули его в протоколе и вызвали его через транзакции. Результаты: среднее время обработки 16 мс
  • Процессор вычисления 8000 также был протестирован. Составлено так же, как Фибоначчи 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 (function) [0:4])
  • каждый аргумент перевести из шестнадцатеричного в 32 байта массив

Дальнейшие действия

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

Вывод

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

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

--

--