НовостиКриптовалютыВиталик Бутерин предложил отделить валидацию транзакций от исполнения в Ethereum

Виталик Бутерин предложил отделить валидацию транзакций от исполнения в Ethereum

Автор: Hokanews·

Ключевые выводы

  • Предложение Бутерина разделяет зависимости транзакций (условия, необходимые до исполнения) и действия транзакций (изменения, производимые в Ethereum).
  • Зависимости, вычисляемые без доступа к состоянию сети, названные чистыми зависимостями, могут проверяться в мемпуле до включения в блок, что обеспечивает параллельные и одновременные проверки.
  • Технология рекурсивных STARK могла бы объединять несколько завершённых проверок в единое доказательство, сокращая повторяющиеся вычисления валидаторов.
  • Ключевые nonce позволили бы создавать отдельные последовательности транзакций внутри одного аккаунта, чтобы несвязанные операции не блокировались задержанной транзакцией.
  • Дизайн остаётся развивающейся исследовательской концепцией: до попадания в основную сеть потребуются доработка безопасности и прохождение публичного рассмотрения и стандартизации в Ethereum.
Виталик Бутерин предложил отделить валидацию транзакций от исполнения в Ethereum

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

Предложение опирается на несколько направлений исследований Ethereum, включая EIP-8141, ключевые nonce, альтернативные модели состояния и рекурсивные STARK-мемпулы. Исследование Бутерина различает действия транзакций, которые производят изменения в Ethereum, и зависимости, которые должны быть разрешены до безопасного исполнения этих действий.

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

Дизайн транзакций может обеспечить параллельную валидацию

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

Существующий поток транзакций Ethereum связывает эти требования валидации с исполнением: узлы получают транзакции, проверяют, удовлетворены ли их требования, а затем выполняют запрошенные операции.

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

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

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

Это разграничение может становиться всё более значимым по мере усложнения транзакций Ethereum и появления более сложной логики авторизации и исполнения. Параллельное исполнение и повышение пропускной способности валидации — повторяющиеся темы в дорожной карте масштабирования Ethereum, где упор делается на увеличение пропускной способности сети за счёт сочетания rollup'ов второго уровня и улучшений базового уровня.

Рекурсивные STARK и абстракция аккаунтов — часть предложения

Технология рекурсивных STARK — ещё один компонент концепции. Несколько завершённых проверок потенциально можно объединить в единое криптографическое доказательство, что позволит валидаторам проверять агрегированный результат вместо независимого повторения каждого базового вычисления. Системы доказательств на основе STARK уже применяются в экосистеме Ethereum, в том числе в zero-knowledge rollup'ах, где они сжимают вычисления в краткие доказательства.

Предлагаемая архитектура также связана с более широкими исследованиями абстракции аккаунтов в Ethereum. EIP-8141 изучает форматы транзакций, поддерживающие более гибкие механизмы авторизации и исполнения, а ключевые nonce могли бы дать большую гибкость в порядке транзакций отдельных аккаунтов. Абстракция аккаунтов продвигалась на Ethereum постепенно благодаря ранним усилиям, таким как ERC-4337, представивший альтернативный мемпул и аккаунты-смарт-контракты, и EIP-7702, позволяющий обычным (externally owned) аккаунтам временно получать функциональность смарт-контрактов.

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

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

Альтернативные модели состояния могли бы дополнительно изменить организацию информации о транзакциях в Ethereum и определение того, какие условия требуют проверки.

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

Предложение остаётся развивающейся исследовательской концепцией

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

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

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

Источник: Hokanews