Виталик Бутерин представил редизайн транзакций Ethereum

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

Его предложение разделяет эффекты, производимые транзакциями, и условия, которые должны быть выполнены до того, как эти эффекты могут произойти.

Бутерин описал два компонента как «действия» и «зависимости» в подробном посте. Действия изменяют состояние Ethereum, например, перевод ETH или вызов контракта. Зависимости охватывают информацию, необходимую для установления того, что транзакция действительна.

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

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

Ethereum может обрабатывать зависимости транзакций параллельно

Транзакции Ethereum в настоящее время объединяют авторизацию, оплату комиссии и выполнение в общем процессе обработки. Узлы проверяют, правильно ли подписана транзакция, может ли отправитель оплатить ее и успешно ли выполняются ее инструкции.

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

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

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

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

Бутерин оценил, что более 90% активности Ethereum по объему не требует полного уровня динамической гибкости сети. Эта цифра является его оценкой, а не опубликованным измерением сети в посте. Более широкий аргумент заключается в том, что обычные переводы и рутинные взаимодействия с контрактами могли бы использовать более ограничительные форматы, не ограничивая специализированные приложения.

Предложенная модель сохранила бы гибкую систему счетов Ethereum для транзакций, которые в ней нуждаются. Более предсказуемая деятельность могла бы использовать статически анализируемые структуры, напоминающие части модели транзакций Bitcoin.

Биткоин использует модель непотраченных выходов транзакций, в которой транзакция определяет выходы, которые она намеревается потратить. Эфириум обычно использует счета с балансами, nonce и программируемым хранилищем контрактов. Бутерин не предлагает, чтобы Эфириум заменил свою модель счетов архитектурой Биткоина. Он описал спектр, сочетающий идеи обеих систем.

EIP-8141 предоставляет общую структуру транзакций

EIP-8141 — это черновик предложения по улучшению Эфириума для нового типа транзакций, известного как Frame Transaction. Он разделяет транзакцию на фреймы вызовов контрактов, которые могут проверять полномочия, одобрять оплату газа и выполнять пользовательские операции.

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

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

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

Эта структура соответствует разделению Бутерина на зависимости и действия. Фреймы проверки обрабатывают условия, которые должны быть выполнены. Фреймы отправителя обрабатывают операции, изменяющие состояние.

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

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

EIP-8141 остается классифицированным как черновое Core-предложение. Его текущая спецификация включает подробные правила для приема в мемпул, выполнения фреймов, квитанций, подписей, учета газа и распространения транзакций. Эти детали могут измениться в ходе рассмотрения.

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

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

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

Рекурсивные STARK могут устранить повторную проверку

Долгосрочная модель Бутерина выходит за рамки EIP-8141. Он предположил, что зависимости, не требующие доступа к состоянию, можно проверять один раз на уровне мемпула, а не повторять каждым валидатором.

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

STARK — это криптографическое доказательство, позволяющее одной стороне продемонстрировать, что вычисление было выполнено правильно. Рекурсивные доказательства могут проверять другие доказательства, что позволяет объединить множество проверок в меньшую задачу проверки.

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

Бутерин предположил, что этот подход также может уменьшить объем данных проверки, размещаемых в цепочке. Если рекурсивное доказательство устанавливает, что все зависимости были действительны, некоторые исходные данные потенциально можно было бы опустить.

Этот результат не является частью текущей спецификации EIP-8141. Он потребовал бы дополнительных исследований, охватывающих генерацию доказательств, координацию мемпула, доступность данных и защиту от недействительной агрегации.

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

EIP-8141 может позволить аккаунтам определять новые схемы авторизации, не дожидаясь, пока Ethereum заменит единый фиксированный стандарт подписи. Рекурсивная агрегация доказательств затем могла бы снизить стоимость проверки больших постквантовых подписей.

EIP-8141 может помочь аккаунтам Ethereum внедрить постквантовую авторизацию, если появятся практические системы подписей. Это остается долгосрочным путем обеспечения безопасности, а не немедленной реакцией на активную квантовую угрозу.

Ключевые nonce могут устранить узкие места транзакций

Аккаунты Ethereum используют последовательные nonce для предотвращения повторного воспроизведения транзакций. Если аккаунт отправляет транзакции с номерами 10, 11 и 12, сеть обычно обрабатывает их в этом порядке.

Последовательность может создавать узкое место. Если транзакция 10 застревает или становится недействительной, последующие транзакции с того же аккаунта также могут ждать, даже если их операции не связаны.

Ключевые nonce дадут аккаунту несколько независимых последовательностей nonce. Транзакции, назначенные разным ключам, могут выполняться, не дожидаясь продвижения другой последовательности.

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

Crypto.news ранее сообщал, что ключевые nonce могут предотвратить блокировку независимых приватных транзакций друг другом. Эта функция является частью более широких усилий по улучшению приватных транзакций, гибких аккаунтов и устойчивости к цензуре.

Бутерин также связал работу с транзакциями с альтернативными моделями состояния, включая нативные UTXO-дизайны и структуры состояния на основе доказательств. Эти проекты исследуют, могут ли некоторые активы или операции использовать предсказуемые правила состояния, в то время как сложные контракты сохраняют существующую гибкость Ethereum.

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

Такое дифференцированное ценообразование пыталось бы привести комиссии в соответствие с фактическими ограничениями масштабирования, создаваемыми каждой транзакцией. Это не гарантировало бы более низкие комиссии для каждого пользователя или приложения.

EIP-8141 все еще требует одобрения разработчиков и тестирования

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

Затем предложение потребует реализации клиентов, сетей разработки, тестирования совместимости, поддержки кошельков и проверки безопасности. Разработчикам также необходимо будет протестировать, как Frame Transactions взаимодействуют с построителями блоков, мемпулами, рынками комиссий и существующими смарт-контрактами.

Более ранние обсуждения разработчиков рассматривали EIP-8141 для будущего обновления Ethereum Hegotá. Однако crypto.news сообщил, что Frame Transactions оставались на рассмотрении, а не были официально запланированы.

FOCIL, отдельное предложение, направленное на улучшение устойчивости к цензуре с помощью списков включения транзакций, также обсуждалось вместе с EIP-8141. Эти два предложения решают разные проблемы. Frame Transactions касаются структуры авторизации и выполнения, в то время как FOCIL касается включения подходящих транзакций в блоки.

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

Таким образом, комментарии Бутерина от 6 сентября описывают возможное направление для дизайна транзакций Ethereum. Они не объявляют о завершенном обновлении, дате активации или подтвержденном изменении комиссий за газ в основной сети.

Следующими проверяемыми вехами были бы официальная поддержка разработчиков, включение в объем обновления и работающие реализации в сетях разработки. До тех пор EIP-8141 и рекурсивные STARK-мемпулы остаются активными исследовательскими и инженерными предложениями.

Часто задаваемые вопросы