Aurora выпускает версию движка 2.8.0

Внедрение усиленных мер реагирования в сфере безопасности, воспроизводимости и обновлений межсетевых вызовов контрактов

Blog post cover

Aurora выпускает версию движка 2.8.0

Внедрение усиленных мер реагирования в сфере безопасности, воспроизводимости и обновлений межсетевых вызовов контрактов

Aurora Labs рада объявить о выходе виртуальной машины Ethereum EVM версии 2.8.0, от команды движка. Она включает в себя усиленные меры безопасности, бинарную воспроизводимость, некоторые результаты фаззера и улучшения межсетевых вызовов контрактов.

Усиленные меры реагирования в сфере безопасности

Мы всегда ищем способы повысить скорость реагирования в EVM Aurora. В контракт EVM были добавлены две новые функции администратора, чтобы мы могли контролировать, какие части EVM нужно приостановить. Для этого мы добавили возможность приостанавливать прекомпиляции, специфичные для EVM Aurora, с помощью функций pause_precompiles и resume_precompiles.

Воспроизводимость

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

Постоянный аудит

В настоящее время у нас выполняется постоянный аудит силами компании Sigma Prime. Имеется не один, а два фаззера (объяснено в этой статье в разделе «Фаззинг-тесты») компаний Sigma Prime и BlockSec. Мы исправляем незначительные проблемы соответствия Go-Ethereum по мере их появления. Мы обнаружили досадную логическую регрессионную ошибку в прекомпиляциях BN256 и возведения в степень по модулю, которые с тех пор были исправлены.

Ситуация с межсетевыми вызовами контрактов

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

Расширенные примечания к патчу

Обратите внимание, что мы сделали больше, чем указано ниже, но мы делимся только основными моментами. Для получения более подробной информации читайте запрос на включение изменений последней версии здесь.

Добавлено

Приостановка/возобновление прекомпиляции

Требовался более детальный контроль над приостановкой определенных функций в EVM Aurora. В частности, нам нужна была возможность быстро приостанавливать функциональность, чтобы вывести токены ETH или ERC-20 из движка. Эта возможность была реализована путем введения в движок двух новых функций, pause_precompiles и resume_precompiles, которые позволяют владельцу контракта включать и отключать эту новую функциональность.

Воспроизводимые сборки

Хотя в настоящее время невозможно воспроизвести сборку без определенной контейнерной среды, можно использовать Docker и образ для получения воспроизводимой сборки. Воспроизводимая сборка теперь возможна, если запустить команду «cargo make --profile build-docker». Затем эту команду можно запустить, чтобы убедиться, что движок на детальном уровне воспроизводится вплоть до метаданных.

Исправления

Стек вызовов EVM слишком мал (#638, aurora-is-near/sputnikvm#16)

Для стека вызовов EVM глубина на Rust недостаточна, при необходимой 1028. К сожалению, мы заметили, что достигли предела.

Прекомпиляция BN256 имела регрессионную ошибку (#637)

Прекомпиляция BN256 имела регрессионную ошибку из предыдущей версии, когда точки (0; 0) приводили к возврату и не выполнялись успешно, поскольку они существуют на кривой.

Возведение в степень по модулю при оценочном газе (#636)

Прежде чем выполнение может произойти на прекомпиляции, мы должны оценить значение газа перед выполнением самого кода. К сожалению, для некоторых входных данных с показателями степени 0 оценка значения газа была сильно занижена до 200 gwei. Чтобы исправить это, мы обновили математическую часть:

До исправления:

gas = mul_complexity * iteration_count / 3

После исправления:

gas = mul_complexity * max(iteration_count, 1) / 3

После этого патча ввод 0x0000000000000900000000000000000, который ранее приводил к значению газа 200 gwei, теперь правильно оценивается в 18 446 744 073 709 551 615 gwei.

Этот патч устраняет проблему, из-за которой некоторые транзакции достигают максимального лимита газа на NEAR без каких-либо затрат для злоумышленника, стремящегося истощить балансы NEAR ретрансляторов. Этот патч не затронул RPC-ретранслятор Aurora, но мог повлиять на RPC-ретрансляторы других поставщиков.

Незначительные улучшения в межсетевых вызовах контрактов

Разрешить межсетевым вызовам контрактов выполнять любой возможный вызов NEAR (#610)

Мы определяем новую структуру данных под названием NearPromise, которая может моделировать все возможные действия с обещаниями на NEAR. Сюда входят все пакетные действия и все комбинаторы обещаний. Тип данных является рекурсивным, потому что в NEAR разрешены длинные цепочки обратных вызовов, а комбинатор «And» может объединять любые обещания.

Цель добавления этого определения — позволить пользователям функции межсетевого вызова контрактов совершать любые транзакции в NEAR, которые они могли бы совершить, если бы у них была учетная запись NEAR.

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

Обновляйте версию контракта маршрутизатора в хранилище только в случае успешного развертывания (#616)

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

Убедитесь, что маршрутизатор межсетевого вызова контракта присоединяет достаточно газа для выполнения (#622)

Работая над коннектором нативных токенов, мы стремились выполнять обещания с обратными вызовами, используя механизм межсетевого вызова контракта. Эта проблема возникла из-за того, что для предварительной компиляции межсетевого вызова контракта необходимо было присоединять больше газа NEAR к выполнению маршрутизатором функции, когда дело касалось обещаний. Количество необходимого газа линейно зависит от количества обратных вызовов. Мы исправили проблему, и предварительная компиляция межсетевого вызова контракта теперь учитывает линейно увеличивающееся количество газа, необходимого для обещаний с обратными вызовами.

Авторы

Большое спасибо нашим авторам этой версии:

This site uses cookies.
Read more