Второй день конференции разработчиков Эфириума DevCon-3 был отведен разработчикам, обсуждавшим технические вопросы построения Виртуальной Машины Эфириума (EVM) и ключевые проблемы написания и верификации смарт-контрактов. О первом дне конференции читайте здесь.
Как заметил сотрудник Фонда Эфириума Петер Жиляги (Peter Szilagyi): «Нынешний Эфириум представляет собой инструмент, написанный разработчиками для других разработчиков. Его программную среду трудно назвать дружественной».
Будущая EVM Эфириума
Ветеран Фонда Эфириума, доктор Грег Колвин (Greg Colvin), за характерную внешность прозванный Гэндальфом, рассказал о работе над возможными преемниками EVM, которые должны увеличить ее производительность.
Перспективная EVM должна стать компактнее и мощнее. Отвечая на вопрос: «Почему производительность EVM существенно ниже нативной скорости кода C++?», он назвал такие причины, как неоптимизированный интерпретатор, 256-битные регистры и порядок выполнения инструкций процессором. Будущая EVM 2.0 содержит опкоды для структурированного порядка выполнения. Он подчеркнул, что EVM 1.5 и 2.0 должны быть совместимы.
Безопасность Эфириума
Презентация Мартина Свенде (Martin Swende) из Фонда Эфириума называлась «Безопасность Эфириума в прошедшем году»: он напомнил, что начало предыдущей конференции DevCon-2 более года назад совпало с началом мощной DoS атаки на блокчейн Эфириума. Таких атак за истекший год было несколько, кроме того, атакам подвергалась тестовая сеть Ropsten. Анализ этих атак многому научил разработчиков: в сеть были добавлены узлы мониторинга с графическим отображением статистики. Работа этих узлов помогла оптимизировать транзакции, в результате чего скорость прохождения некоторых операций увеличилась в 20 – 30 раз.
В EVM добавлены функции дебаггера, позволяющие контролировать выполнение опкодов и подтверждать их одинаковое исполнение в разных клиентах, чтобы избежать проблем с консенсусом. Именно разночтения в клиентах стали причиной непреднамеренного форка между Geth и Parity осенью прошлого года.
Реализован инспектор транзакций, позволяющий видеть содержание памяти EVM по мере выполнения операций: он помогает воспроизвести и проанализировать способы возможных атак и быстро ликвидировать их последствия.
При тестировании новых версий клиентов перед запуском релиза Byzantium впервые применялся фаззинг (fuzzing), при помощи которого были выявлены несколько ошибок – если бы они не были найдены, запуск Byzantium мог привести к нарушению консенсуса между Geth и Parity. Фаззинг-инструмент позволяет в тысячи раз увеличить количество тестов основных клиентов.
Отчеты по децентрализованной файловой системе Swarm
Два проекта Эфириума – протокол распределенного хранения файлов Swarm и обмен мгновенными сообщениями с помощью узлов Эфириума Whisper, долгое время расматривались как неотъемлемые части будущего «Мирового компьютера» на блокчейне. Однако, их разработка сильно задержалась, и в результате, большинство разработчиков Dapps отдали предпочтение независимым проектам: распределенной файловой системе IPFS и протоколу обмена сообщениями PSS.
Тем не менее, Swarm продолжает развиваться – новости представил основатель проекта Виктор Трон (Victor Tron). По его словам, новый протокол синхронизации уже готов для работы в тестовой сети. Сетевой протокол также будет полностью переписан. Готовится к тестированию легкий клиент Swarm.
Люди используют централизованный Github. Мы разрабатываем плагин для Swarm, с помощью которого на нем сможет расположиться децентрализованный git.
Дэниел Неги (Daniel Nagy) из Swarm рассказал о масштабируемых Dapps с интегрированным Swarm и ENS. Варианты применения: мобильные приложения, IoT, фронтэнд. Крупные разделы бизнес-логики Dapps находятся на стороне клиента. Бэкэндом служит узел Эфириума, для хранения файлов используется swarm, а для коммуникаций между узлами Whisper/PSS.
Пользователи расходуют ETH или токены и характеризуются высокой скоростью оттока (churn) и ограниченными ресурсами. Поставщики услуг зарабатывают токены, характеризуются низкой скоростью оттока и высокой доступностью (по теореме CAP) и высоким уровнем ресурсов. Производительность приложений ограничивается скоростью блокчейна. Кроме того, приложения платят газ за трансляцию изменений состояния. Еще одно ограничение: максимальное количество вычислений, которое индивидуальный узел может провести от имени Dapp. Разработчики предлагают хранить данные на Swarm, и записывать корневой хеш в ENS.
Ограничение на скорость транзакций может быть решено с помощью быстрых апдейтов хеша через сайдчейн Raiden. Комбинация этих технологий существенно увеличивает пропускную способность Dapp. К примеру, если участники находятся в чатруме, то трансляция сообщений обеспечивает доступность (CAP), в то время как блокчейн отвечает за согласованность с теми, кто загрузит страницу позднее.
Будущее токенов и их контрактов: MiniMe, стандарт ERC223
Джорди Бейлина (Jordi Baylina) из проекта Giveth предложил контракт MiniMe, название которого заимствовано из фильма «Остин Пауэрс». Он представляет собой токен ERC20, отслеживающий всю историю распределения токена на блокчейне. Это значит, что можно создать «клон» токена, полностью повторяющий историю исходного токена, а вернее, его форк, после которого оба токена становятся независимыми.
Варианты применения такого контракта:
-
Клон можно использовать в качестве голосующего бюллетеня. После голосования он сжигается.
-
Апгрейд токена: после клонирования обновляется кодовая база нового токена, а старый контракт дезактивируется.
Недостатки токенов ERC20 привели к предложению нового стандарта ERC223, однако, его внедрению мешает обратная несовместимость. Проблему предлагается решить с помощью предложения EIP672: оно гласит, что в случае, если токен стандарта ERC223 не поддерживает какие-то функции ERC20, то можно воспользоваться отдельным контрактом, добавляющим такую функциональность.
