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

Наша классификация подходов к абстрагированию счета следующая:

1. Усовершенствование/программируемость EOA: Это включает изменения на уровне протокола, которые позволяют EOA (Аккаунтам, принадлежащим внешним субъектам) переопределять часть логики выполнения своих правил валидности. Как хорошо известно в разработческом сообществе, EOA обычно связаны с конечными пользователями. Поэтому решения, входящие в этот подход, позволят конечным пользователям иметь больший контроль над тем, какие действия они могут авторизовать, в сравнении с тем, как это управляется сегодня.
2. Преобразование/миграция EOA: Этот подход включает предложения, которые стремятся к полному преобразованию EOA в CA (счета контрактов). Идея этого подхода заключается в том, что счета контрактов уже предлагают большую часть преимуществ, предлагаемых смарт-счетами, поэтому больше нет необходимости усложнять вещи; каждый просто должен использовать счет контракта как свой основной счет (через кошельки смарт-контрактов).

Этот подход включает механизмы, которые позволяют EOA переходить к CA, не перемещая свои активы, такие как EIP 7377иEIP 5003 (если рассматривать вместе с EIP 3074).

1. Smart Accounts: Эта группа предложений включает в себя дизайны, которые позволяют как EOA, так и CA действовать как «умные счета», позволяя им полностью переопределить свои правила действительности.

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

После возрождения этой темы Виталиком после слития, ЭРК-4337была предложена в качестве версии с возможностью выбора стандарта умного счета, аналогичного инфраструктуре PBS (разделение предложителя-строителя) для MEV (максимально извлекаемой стоимости). Таким образом, пользователи, которые стремятся получить преимущества умных счетов, могут просто использовать конвейер ERC-4337 для переопределения логики своего счета и правил проверки допустимости транзакций в структурах, называемых UserOperation (или UserOps в кратком виде).

ERC 4337 принесет преимущества умных счетов в настоящее время Ethereum, не утверждая при этом какой-либо сложности, функционируя как внепротокольная альтернатива утвержденным умным счетам. Однако это не означает, что инфраструктура оптимальна в своем текущем состоянии, поскольку ее собственная сложность все еще является значительной точкой отказа.

Для решения этой сложности,RIP 7560был разработан как увековеченная версия инфраструктуры ERC 4337 на Ethereum и его L2s, чтобы он наследовал схемы сопротивления сибил-атакам сети, а не создавал новый набор правил (как это делает ERC 4337 с ERC 7562).

В этом отчете мы сосредоточимся на изучении программирования EOA, оценим различные EIP, описывающие решения по этой линии, и обсудим их достоинства и недостатки. В части 2 и 3 этой серии мы рассмотрим оставшиеся два класса подходов к абстрагированию счета, исследуемых в рамках Ethereum.

Основы Ethereum счетов и транзакций

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

Счета Ethereum - это сущности с балансом эфира (ETH) и возможностью отправлять транзакции в блокчейне Ethereum. Они представлены в виде 42-значного шестнадцатеричного «адреса», который служит уникальным указателем на средства и транзакции счета.

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

1. nonce: Линейный счетчик, используемый для указания количества инициированных исходящих транзакций счета. Он также крайне важен для предотвращения атак повтора.
2. баланс: количество эфира (ETH), принадлежащее учетной записи, выраженное в вей.
3. codeHash: Хэш EVM-исполняемого кода, содержащегося в счете. EVM (Ethereum Virtual Machine) - это индивидуальная среда выполнения Ethereum, отвечающая за обработку сложных переходов состояния, выходящих за пределы простых транзакций «отправки». Кодовое содержимое счета неизменно спрограммировано для выполнения определенных форм перехода состояния на блокчейне Ethereum через EVM.
4. Хранилище хешей: хеш-значение корневого элемента хранилища счета, используемое для представления содержимого хранилища счета как 256-битного хеш-значения корневого узла дерева Меркла-Патриции. Проще говоря, это хеш-значение данных переменной состояния, связанных с контентом кода счета.

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

1. Внешне-управляемые учетные записи (EOA) - которые инициализируются как криптографическая пара ключей:

• Частный ключ, который является зашифрованным и доказуемо случайным 64-значным символом в шестнадцатеричной системе счисления, и его дополняющий контрпарт;
• Открытый ключ, который получают из закрытого ключа с помощью алгоритма цифровой подписи на эллиптических кривых (ECDSA).

EOAs имеют пустые поля codeHash и storageHash и могут быть контролируемыми только теми, кто обладает приватными ключами. Их адреса можно получить из соответствующего публичного ключа, добавив префикс «0x» к последним двадцати символам хэша keccak-256 публичного ключа аккаунта.

1. Счета контрактов (CAs), которые могут быть созданы только существующим EOA. Они инициализируются благодаря развертыванию EOA исполняемого кода на EVM. Этот код (хранящийся как codeHash) закреплен в EVM и отвечает за управление счетом, определяя его логику и взаимодействия.

Их транзакции полностью основаны на извлечении и зависят от логики их развернутого кода.

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

Адрес CA происходит от адреса его создателя и его числа до момента развертывания контракта.

Транзакции

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

Итак, что такое эти «транзакции»?

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

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

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

Счета и правильность транзакций

На Ethereum, EOA оптимизированы для удобства использования, поскольку они обращены к конечному пользователю. У них есть способность отправлять транзакции определенным образом и идеально работать автономно. Их также можно создавать локально, более распространенным методом является использование провайдеров кошельков, таких как MetaMask, Rainbow, Rabby и т. д.

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

Более высокоуровневое описание будет таким: владельцы EOA могут только иметь баланс, в то время как владельцы CA могут иметь как баланс, так и логику, которая определяет, как этот баланс может быть потрачен.

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

1. Логика аутентификации - используется для определения того, как счет подтверждает свою личность перед сетью при изменении своего баланса и/или логики.
2. Логика авторизации - используется для определения политики доступа к счету, т.е. кто может получить доступ и вносить изменения в баланс и/или логику счета.
3. Логика nonce - определяющая порядок выполнения транзакций с аккаунта.
4. Логика оплаты газа - Используется для определения стороны, ответственной за оплату комиссии за газ в транзакции.
5. Логика выполнения - используется для определения, какие формы транзакций может отправлять учетная запись или как выполняется транзакция.

Эти параметры разработаны для жесткой настройки для EOAs таким образом:

• Аутентификация и авторизация осуществляется с помощью закрытого ключа на основе ECDSA, то есть пользователь, желающий отправить транзакцию со своего EOA, должен использовать свой закрытый ключ для доступа к счету и тем самым доказать, что у него есть право вносить изменения в его баланс.
• Логика nonce реализует последовательную схему счетчика, которая позволяет выполнить только одну транзакцию с уникальным nonce последовательно для каждого счета.
• Логика оплаты газа определяет, что комиссия за газ для транзакций должна быть оплачена отправителем/исходным счетом.
• Логика исполнения указывает, что внешние управляемые счета (EOA) могут отправлять только следующие формы транзакций:

1. Регулярные переводы между двумя EOA.
2. Развертывание контракта.
3. вызовы контракта, которые нацелены на логику развернутого счета контракта.

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

С другой стороны, у сертификационных центров больше гибкости в отношении этих параметров:

• Аутентификация не требуется, так как их транзакции являются консеквентными/основанными на выводе.
• Авторизация для СА может иметь две формы:

1. Способность «вызывать» содержимое кода CAs (или выполнять его смарт-контракт), что зависит от логики смарт-контракта учетной записи и ее инвариантов.
2. Возможность внесения изменений в код содержимого CA, который в основном зависит от того, является ли код содержимого обновляемым или нет.

В большинстве практических случаев логика, используемая в данном случае, является схемой мультиподписи, которая предусматривает, что для валидности изменения логики CA требуется M из N действительных подписей (где M < N) от конкретных счетов (обычно EOA).

• Их порядок транзакций основан на использовании нонсов. Сам CA способен отправлять множество транзакций различным вызывающим, однако каждый вызывающий ограничен своими собственными возможностями.
• Оплата газа обычно осуществляется вызывающей стороной логики СА.
• Логика выполнения СА более разнообразна для обеспечения улучшения UX, таких как многосоставные транзакции и атомарные транзакции.

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

EOA имеют полную автономию, но ограниченную программирование; они могут авторизовывать и отправлять транзакции в любое время, но эти транзакции должны следовать жесткому формату, чтобы быть признанными действительными. CA имеют полное программирование (ограниченное только дизайном EVM), но ограниченную автономию; их транзакции не обязаны следовать какому-либо жесткому формату, но могут быть отправлены только из-за того, что их логика вызывается первой.

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

Дилемма учетной записи Ethereum

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

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

Некоторые из забот, связанных с ними, это:

1. Уязвимость к квантовым атакам – Схема подписи ECDSA, используемая их ключевой парой, не устойчива к квантовым вычислениям, и с оптимистичным сроком в 5 до 10 лет для достижения промышленных квантовых систем, это представляет существенную угрозу для Ethereum и его приложений, которые тяжело полагаются на схему ECDSA для криптографических доказательств и безопасности.
2. Отсутствие выражения - жесткий формат правил действительности EOA устраняет возможность пользователя более кратко выражать свои транзакции с помощью функций, таких как атомарность и пакетирование транзакций, и делегирование транзакций.
3. Самодостаточность – У каждого были свои моменты «у меня закончился бензин» в середине сделки. Это связано с требованием, чтобы EOA сами рассчитывали газ за свои транзакции, что было бы не так уж и сложно, если бы эфир (ETH) не был единственной приемлемой газовой валютой. Несмотря на то, что это общая проблема с конечными автоматами, основанными на учетных записях (и даже на основе UTXO), Ethereum всегда задумывался иначе.

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

С другой стороны спектра счетов, CAs ориентированы на разработчиков и более техническую аудиторию пользователей. Они служат средством для смарт-контрактов (т.е. мы рассматриваем смарт-контракты как содержащуюся в них логику или код) и, таким образом, могут реализовывать новые форматы транзакций, доступные благодаря EVM.

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

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

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

Хронология абстракции счета

Концепция абстракции аккаунта (по крайней мере, через смарт-аккаунты) всегда была неотъемлемой частью дорожной карты Ethereum. Легенда заключается в том, что сложность, связанная с его реализацией, угрожала дальнейшей задержкой запуска Ethereum, и поэтому он был заменен на текущий дизайн с разными учетными записями, предлагающими разные функции. Он снова был отложен из-за того, что Ethereum сосредоточился на слиянии, и теперь всплывает на поверхность как основная часть следующего крупного обновления сети — Pectra. Тем не менее, его сложность по-прежнему считается существенным недостатком, препятствующим его закреплению, особенно с учетом того, что Ethereum перешел на дорожную карту, ориентированную на роллап.

Теперь требования двукратные:

1. Стандарты счета должны быть более выразительными, но без потери автономности. Новый стандарт, который устраняет различия между стандартами EOA и CA.
2. Новый стандарт должен преодолеть разрыв между EOA и CA, при этом оставаясь полностью совместимым с Ethereum и его экосистемой L2.

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

Абстракция учетной записи нацелена на объединение лучших характеристик EOAs и CAs в новый стандарт учетной записи - умные учетные записи, которые позволяют полностью или частично разделить правила действительности любой учетной записи на логику проверки и логику выполнения; таким образом, учетные записи могут определять свои собственные правила действительности - как разрешено EVM - так же, как учетные записи контрактов, оставаясь полностью автономными, как внешние учетные записи.

Часто возникает путаница в различиях между умными счетами и кошельками смарт-контрактов, поэтому давайте явно опишем, в чем эти различия, ниже:

• Умные счета - это счета Ethereum, которые концептуализированы для обеспечения равных частей программирования и автономности. Идея заключается в том, что как EOA, так и CA могут стать умными счетами, просто используя некий механизм (например, ERC 4337), который позволяет им заменить их сетевые правила действительности на индивидуальные правила действительности, по своему усмотрению.
• Смарт-контрактовые кошельки, с другой стороны, просто являются провайдерами кошельков, которые служат интерфейсами для контрактных счетов (да, кошелек не является счетом).

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

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

• Аутентификация
• Авторизация
• Логика Nonce
• Логика оплаты газа
• Логика выполнения

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

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

Во введении мы предоставили общий обзор текущего ландшафта AA в форме своего рода классификации различных предлагаемых конструкций. Теперь мы сосредоточимся на первом классе решений проблемы счетов Ethereum - программировании EOA.

Программируемые EOA

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

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

Ниже мы рассмотрим спецификации трех основных EIP, которые предоставляют действенные маршруты для программирования EOA, от менее известныхEIP 5806, до амбициозныхEIP 3074и наконец к победоносномуEIP 7702.

Возможность программирования через EIP-5806

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

Прежде чем мы продолжим, давайте совершим поездку по памяти эволюции Ethereum до EIP-7.

EIP-7 предложил создание операции 0xf4/DELEgateCALL, которая используется для отправки вызовов сообщений в основной счет с логикой вторичного счета, при этом сохраняются значения полей [sender] и [value] основного счета.

Другими словами, основной счет "наследует" (или занимает, если вы предпочитаете) логику вторичного счета на определенный период, указанный в вызове сообщения, так что логика последнего выполняется в контексте первого.

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

EIP-5806 резюмирован

Итак, какие вызовы делегатов позволяют взаимозависимость CAs? Ну, EIP-5806 использует EIP-7 в качестве вдохновения, чтобы предложить расширение функциональности вызова делегата также для ЭОС; т.е. позволим ЭОС также взаимодействовать с CAs, ведь зачем нет.

Спецификации

EIP 5806 представляет новыйсовместимый с EIP-2718тип транзакции, который упаковывается следующим образом:

rlp([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list, signature_y_parity, signature_r, signature_s]).

Эти транзакции разработаны таким образом, что поле [to], которое представляет адрес получателя, может принимать только адреса в качестве 20-байтового ввода, отключая отправителя от использования операции CREATE.

Мотивация за каждым компонентом схемы RLP следующая:

• chainID: Идентификатор текущей цепи, совместимый с EIP-115, дополненный до 32 байт. Это значение обеспечивает защиту от повторных атак, чтобы транзакции на исходной цепи не могли быть легко воспроизведены на альтернативных цепях EVM с похожей историей и меньшей экономической безопасностью.
• nonce: Уникальный идентификатор для каждой транзакции, который также обеспечивает защиту от повторных атак.
• max_priority_fee_per_gas и max_fee_per_gas: Значения платы за газ, которую транзакция EIP-5806 должна оплатить за заказ и включение соответственно.
• gas_limit: Максимальное количество газа, которое может потребить одна транзакция типа 5806.
• назначение: Получатель транзакции
• данные: содержание исполняемого кода
• access_list: Агенты, которые условно авторизованы на выполнение транзакций EIP-5806.
• signature_y_parity, signature_r и signature_s: три значения, которые вместе представляют собой подпись secp256k1 на сообщении — keccak256 (TX_TYPE || rlp ([chainID, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, destination, data, access_list])).

Несмотря на то, что упаковка транзакций EIP-5806 в конверты EIP-2718 позволяет обеспечить их обратную совместимость, EOA не эквивалентны ЦС. Таким образом, определенные ограничения должны быть определены в том, как EOA использует вызовы делегатов для предотвращения неизменяемого разрыва.

Эти ограничения направлены на следующие операции:

• SSTORE/0x55: Этот опкод позволяет учетной записи сохранить значение в хранилище. Он ограничен в транзакциях EIP-5806, чтобы предотвратить установку/доступ к хранилищу с помощью делегированных вызовов у внешних учетных записей (EOA), тем самым предотвращая потенциальные проблемы, которые могут возникнуть в будущем из-за миграции учетной записи.
• CREATE/0xF0, CREATE2/0xF5 и SELFDESTRUCT/0xFF: Эти операции позволяют вызывающему создать новый счет. Доступ к ним ограничен, чтобы предотвратить изменение nonce EOA в другом исполнении (создание/уничтожение контракта в данном случае) во время выполнения транзакции EIP-5806, чтобы предотвратить аннулирование ожидания, что транзакции несут последовательные nonce.

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

Основное применение EIP 5806 - это абстракция выполнения для EOAs. Позволяет EOAs безопасно взаимодействовать со смарт-контрактами за пределами простых вызовов их логики, предоставляя им такие функции, как:

• Условное выполнение транзакций
• Групповая транзакция
• Транзакции с несколькими вызовами (например, одобрение и колл)

Критика

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

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

Вторая критика (которая является неким двухгранным мечом) - это простота EIP-5806; есть мнение, что вознаграждение за принятие EIP-5806 может не оправдывать затраты, поскольку он позволяет только осуществлять абстракцию выполнения и не более. В отличие от некоторых других EIP, которые мы обсудим в следующих подразделах, все остальные ограничения на подлинность остаются определенными сетью для ЭОА, которые выбирают EIP-5806.

Возможность программирования через EIP-3074

EIP-3074 предлагает позволить внешним управляемым аккаунтам (EOA) делегировать большую часть своей логики проверки специализированным контрактным аккаунтам, называемым инвокерами, путем наложения логики авторизации последних на свою логику для определенных форм транзакций.

Он достигает этого, передавая свою политику доступа контракту-вызывателю, который затем становится ответственным за определение политики доступа EOA.

Этот EIP предлагает добавление двух новых опкодов в EVM:

• [AUTH], который устанавливает учетную запись контекстной переменной [authorized] действовать от имени второй учетной записи [authority] на основе подписи последней ECDSA.
• [AUTHCALL], который отправляет/выполняет вызовы от учетной записи [authority] от имени учетной записи [authorized].

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

спецификации

EIP-3074 позволяет транзакциям использовать формат подписи [MAGIC], чтобы избежать коллизий с другими форматами подписи транзакций. Аккаунт, к которому передаются инструкции [AUTHCALL], определяется как поле контекстной переменной с именем [authorized], которое сохраняется только на протяжении одной транзакции и должно быть переопределено для каждого нового [AUTHCALL].

Прежде чем перейти к рассмотрению сложностей каждого кода операции, перечислим следующие сущности, участвующие в транзакции EIP-3074:

• [авторитет]: Основной учетная запись для подписи (EOA), которая делегирует доступ/управление второй учетной записи, которая обычно является контрактной учетной записью.
• [authorized]: учетная запись, которой должны быть переданы инструкции [AUTHCALL] для выполнения. Другими словами, это учетная запись, в которой выполняется логика [AUTHCALL] от имени [центра] с использованием ограничений, определенных [вызывающим объектом].
• [invoker]: Подконтракт, предназначенный для управления взаимодействием между [authorized] счетом и логикой [AUTHCALL], особенно в случаях, когда основная логика кода контракта последнего является спонсорством газа.

Контракты Invoker получают сообщения [AUTH] с значением [COMMIT] от [authority]; это значение определяет ограничения, которые счет хочет наложить на выполнение [AUTHCALL] инструкций [authorized].

Таким образом, инициаторы отвечают за то, чтобы [contract_code], определенный в [авторизованной] учетной записи, не был вредоносным и мог удовлетворять инвариантам, помещенным основной учетной записью подписи в значении [COMMIT].

Код операции [AUTH] имеет три входных элемента стека; Или, проще говоря, он определяется тремя входами, которые вычисляют один выход. Вот эти входные данные:

1. авторитет: это адрес EOA, который генерирует подпись
2. смещение
3. длина

Последние два входных параметра используются для описания диапазона модифицируемой памяти от 0 до 97, где:

1. [память(смещение: смещение+1)] – [yParity]
2. [память(смещение+1: смещение+33] – [r]
3. [память(смещение+33 : смещение+65)] – [с]
4. [memory(offset+65 : offset+97)] - [COMMIT]

Переменные [yParity], [r] и [s] совместно интерпретируются как ECDSA-подпись [magic] на кривой secp256k1 над сообщением:

[keccak256 (MAGIC || chainID || nonce || адрес инициатора || КОММИТ)]

где:

• [MAGIC] - это подпись ECDSA, полученная в результате комбинации переменных:
  • [chainID], который является идентификатором, соответствующим EIP 115, используемым для обеспечения защиты от атаки повторения на альтернативных цепях EVM с аналогичной историей и меньшей экономической безопасностью.
  • [nonce], который является текущим nonce адреса подписчика транзакции, дополненный до 32 байтов.
  • [invokerAddress], который является адресом контракта, содержащего логику выполнения [AUTH].
• [COMMIT] - это 32-байтовое значение, используемое для указания дополнительных условий допустимости транзакции в логике предварительной обработки вызывающего.

Если вычисленная подпись действительна и адрес подписанта равен [authority], поле [authorized] обновляется до значения, предоставленного [authority]. Если какое-либо из этих требований не удовлетворено, поле [authorized] остается неизменным в своем предыдущем состоянии или как незаданное значение.

Стоимость газа для этой операции вычисляется как сумма:

1. Фиксированная плата за предварительную компиляцию [ecrecover] и дополнительная плата за хеширование keccak256 и некоторую дополнительную логику, стоимостью 3100 единиц
2. Плата за расширение памяти, которая рассчитывается аналогично коду операции [RETURN] и применяется, когда память расширяется за пределы указанного диапазона текущего выделения (97 единиц)
3. Фиксированная стоимость в размере 100 единиц для теплого [авторитета] и 2600 единиц для холодного для предотвращения атак из-за неправильной оценки кодов операций, обращающихся к состоянию.

[AUTH] реализован таким образом, чтобы не изменять память, и принимает значение [authority] в качестве аргумента, чтобы было легко проверить его значение из предоставленной подписи.

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

У него такая же логика, как у операции [CALL], т.е. он используется для отправки сообщений в счет и запуска определенной логики в его контрактах. Единственное отклонение в их логике заключается в том, что [AUTHCALL] предназначен для установки значения [CALLER] перед продолжением выполнения.

Таким образом, [AUTHCALL] используется [центром] для запуска контекстно-зависимого поведения в [authorized] с логическими проверками, происходящими следующим образом:

1. Проверьте значение [authorized]. Если не установлено, выполнение считается недействительным, и рамка немедленно завершается. Это помогает предотвратить несправедливые расходы из-за непредвиденных сбоев.
2. Проверяет стоимость газа для намеренного поведения [authorized].
3. Проверяет совместимое значение EIP-150 операнда [gas].
4. Проверяет наличие полной стоимости газа –[value]– на счету [authority].
5. Исполнение происходит после вычета [value] из баланса счета [authority]. Если [value] больше их баланса, исполнение недействительно.

Стоимость газа для [AUTHCALL] вычисляется как сумма:

• Фиксированная плата за звонок [warm_storage_read]
• Стоимость расширения памяти [memory_expansion_fee]; которая рассчитывается аналогично стоимости газа для опкода [CALL]
• Динамическая стоимость [dynamic_gas]
• Стоимость выполнения подвызова [subcall_gas]

Данные, полученные из [AUTHCALL], доступны через:

• [RETURNDATASIZE] - который помещает размер буфера возвращаемых данных в стек вывода
• [RETURNDATACOPY] - копирует данные из буфера возврата данных в память.

Для того чтобы все это объединить с гораздо меньшим количеством технической речи; транзакции Ethereum обычно указывают два значения:

1. tx.origin - предоставляет авторизацию для транзакции.
2. msg.sender - в котором фактически происходит транзакция.

В EOAs, как уже упоминалось, авторизация тесно связана с выполнением, т.е.; (tx.origin == msg.sender). Этот простой инвариант порождает большинство проблем, о которых мы объяснили в подразделе "Действительность счетов и транзакций" этого отчета.

[AUTH] сообщений от [authority] позволяет ему сместить функцию tx.origin на [authorized], оставаясь при этом msg.sender. Он также позволяет определять ограничения для этой привилегии с помощью значения [COMMIT].

[AUTHCALL], затем позволяет [авторизованному] получить доступ к логике контракта, используя [invoker] в качестве посредника, чтобы убедиться, что контракт, к которому он хочет получить доступ, безопасен. То есть, для каждого [AUTHCALL], [авторизованный] должен указать конкретного [invoker] для своего [COMMIT].

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

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

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

• Логика Nonce: EIP-3074 позволяет сохранить Nonce для EOAs неизменным после отправки сообщения [AUTH], тогда как для каждого [AUTHCALL] его Nonce зависит от того, с кем он взаимодействует. Таким образом, это обеспечивает параллелизм Nonce для EOAs, чтобы они могли отправлять несколько неперекрывающихся [AUTHCALL], как им угодно.
• Логика оплаты газа: Как указаноВ EIP вызыватели могут быть спроектированы для разрешения спонсирования газа. Таким образом, комиссия за газ для [COMMIT] пользователя может быть вычтена из источника транзакции или из любого поддерживающего счета, будь то личный или сервисный ретранслятор (услуги спонсирования газа).

Кроме того, логика выполнения интуитивно абстрагирована; в конце концов, вызывающая сторона (которая является CA) теперь отвечает за выполнение транзакционных запросов от имени EOA.

Критика

• Централизация Инвокера

Цитирование один из его авторов: «Я бы не ожидал, что кошельки будут раскрывать функциональность для подписи произвольных инициаторов...». Возможно, самая большая проблема, связанная с инициативой 3074, заключается в том, что инновации, лежащие на ее вершине, очень легко приведут к разрешенным и проприетарным потокам сделок; точно так же, как и текущие итерации рынков MEV и PBS Ethereum.

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

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

• Проблемы совместимости вперед

EIP-3074 закрепляет схему подписи ECDSA, поскольку она до сих пор считается более действительной, чем схема авторизации, введенная через вызывающий. Хотя есть аргументы в пользу того, что квантовая стойкость в настоящее время не является окончательной проблемой, и что в будущем с ECDSA может столкнуться с гораздо более серьезными проблемами; неявная цель Ethereum - всегда опережать такие проблемы. Потенциальная жертва квантовой и цензурной стойкости в обмен на маргинальные улучшения UX может быть не лучшим выбором в ближайшем будущем.

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

Даже с дорожной картой для нативного абстрагирования счета, операции [AUTH] и [AUTHCALL] в конечном итоге перестанут быть актуальными в EVM, внося значительную техническую задолженность в Ethereum, чтобы достичь незначительного улучшения UX.

• Невозможность отзыва схемы ECDSA

После отправки сообщения [AUTH] и делегирования управления от EOA ожидается, что он будет избегать обычной схемы авторизации с помощью закрытого ключа, поскольку отправка «обычной» транзакции вызывает отзыв авторизации, которую он делегировал каждому вызывающему.

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

Программирование через EIP-7702

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

Его подход заключается в добавлении нового типа транзакции, совместимого с EIP 2718, - [SET_CODE_TX_TYPE] -, который позволяет EOA вести себя как умный счет для указанных транзакций.

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

Характеристики

EIP-7702 позволяет EOA «импортировать» содержимое кода контракта через транзакцию, соответствующую [SET_CODE_TX_TYPE] 2718-комплиантному формату:

rlp([chain_id, nonce, max_priority_fee_per_gas, max_fee_per_gas, gas_limit, назначение, значение, данные, access_list, authorization_list, signature_y_parity, signature_r, signature_s])

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

[[chain_id, адрес, nonce, y_паритет, r, s], …]

где каждый кортеж определяет значение [адреса].

Перед продолжением стороны, участвующие в SET_CODE_TX_TYPE, являются:

• [authority]: который является EOA/основным учетным записью для подписи
• [адрес]: который является адресом учетной записи, содержащей делегируемый код.

Когда [полномочия] подписывает SET_CODE_TX_TYPE с указанием [адрес], создается обозначение делегирования. Это "программа-указатель", которая приводит к тому, что все запросы на извлечение кода, вызванные действиями [авторитета], в любой момент времени направляются в наблюдаемый код [адрес].

Для каждой кортеж [chain_id, address, nonce, y_parity, r, s], логический поток транзакции типа 7702 следующий:

1. Проверка подписи [authority] из предоставленного хэша с помощью: authority = ecrecover(keccak(MAGIC || rlp([chain_id, address, nonce])), y_parity, r, s]
2. Предотвращение атак воспроизведения межцепочечных операций и другие векторы атакипутем проверки идентификатора цепи.
3. Проверка наличия у [authority] кодового содержимого.
4. Проверка Nonce, чтобы гарантировать, что nonce [authority] равен nonce, включенному в кортеж.
5. Если транзакция является первой транзакцией SET_CODE_TX_TYPE [authority], ей будет начислена комиссия PER_EMPTY_ACCOUNT_COST. В случае, если баланс меньше этой комиссии, операция будет отменена.
6. Происходит назначение делегирования, при котором код [authority] устанавливается в указатель [address].
7. Nonce подписчика –[authority]– увеличивается на единицу.
8. [authority] добавляется в список доступных адресов, который (в упрощенной форме) представляет собой набор адресов, таких, что отмена области транзакции из них приводит к восстановлению их (адреса) в предыдущее состояние, прежде чем была введена отмененная область. Это определено в EIP-2929для включения кэширования повторно используемых значений и предотвращения ненужных расходов.

Фу! Чтобы завязать все обратно; Этот EIP позволяет EOA отправлять транзакции, которые устанавливают указатель на код контракта, что позволяет им реализовывать эту логику как свою собственную в последующих транзакциях. В этом смысле он строго сильнее, чем EIP 5806, потому что позволяет EOA иметь содержимое кода столько, сколько они хотят (в отличие от EIP 5806, который просто позволяет EOA отправлять вызовы делегатов).

Потенциальная применимость/Сферы применения

• Абстракция выполнения

Хотя можно утверждать, что это уже не абстракция, поскольку EOA активно принимает логику, которую хочет выполнить, она все еще не является «основным владельцем» этой логики. Кроме того, она не содержит логику напрямую, а просто указывает указатель на логику (для уменьшения вычислительной сложности). Поэтому мы идем по пути абстрагирования выполнения!

• Спонсорство газа

Хотя инвариант require(msg.sender == tx.origin) нарушается для возможности самостоятельного спонсирования, EIP все еще позволяет интеграцию ретрансляторов спонсируемых транзакций. Однако есть ограничение: такие ретрансляторы должны иметь систему, основанную на репутации или доле владения, чтобы предотвратить атаки гриферов.

• Политики условного доступа

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

Это также позволяет существование подключенных ключей, которые позволяют "деэскалацию привилегий", так что конкретные dAPPs имеют доступ только к балансу счета в определенных условиях. Например, можно представить разрешение на трату токенов ERC-20, но не ETH, или тратить до 1% от общего баланса в день, или взаимодействовать только с определенными приложениями.

• Развертывание умного контракта межцепочки

Из-за его нерестриктивной природы, транзакция EIP-7702 может позволить пользователю получить доступ к операции CREATE2 и использовать ее для развертывания байт-кода по адресу без каких-либо других ограничительных параметров, таких как логика рынка комиссий (например, EIP-1559 и EIP-4844). Это позволяет восстанавливать адрес и использовать его в нескольких состояниях, с тем же байт-кодом, где его учетная запись на каждой цепочке затем отвечает за определение других параметров контекста.

Критика

• Отсутствие обратной совместимости

Хотя EIP-7702 все еще очень недавний, уже было много прототипирования и тестирования его зависимостей и потенциальных недостатков, но его минималистичная модель гарантирует ему много гибкости и, следовательно, полезности в различных контекстах. Тем не менее, он нарушает слишком много инвариантов и не является немедленно обратно совместимым.

Некоторые из его логики включают:

1. Изменение счетчика EOA во время транзакции: EIP-7702 не ограничивает никакие операции в целях обеспечения согласованности. Это означает, что EOA может реализовывать операции, такие как CREATE, CREATE2 и SSTORE во время выполнения транзакции EIP-7702, что позволяет увеличить его счетчик в другом контексте.
2. Разрешение учетных записей с ненулевым значением codeHash быть инициаторами транзакций: EIP-3607 был реализован для уменьшения потенциальных последствий "столкновения адресов" между EOAs и CAs. Столкновение адресов происходит, когда 160-битное значение адреса EOA полностью эквивалентно адресу CA.

Большинство пользователей не знают о фактическом содержании счета (или даже разнице между счетом и адресом!), поэтому допуск адресных коллизий означает, что EOA может выдавать себя за CA и привлекать средства пользователей в долгом процессе, чтобы в конечном итоге украсть все. EIP-3607 решает эту проблему, определяя, что счета, содержащие код, не должны иметь возможность тратить свой баланс, используя свою собственную логику авторизации. Однако EIP 7702 нарушает это неизменное правило, чтобы позволить EOAs оставаться автономными даже после получения некоторой программной возможности.

• Похожесть на EIP-3074

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

Заключение

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

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

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

EIP-7702 в настоящее время является визитной карточкой механизмов, которые стремятся привнести программную возможность EVM в EOAs, поскольку он был отмечен как замена слота EIP 3074 в обновлении Pectra. Он наследует открытый дизайн механизма 3074, существенно снижая поверхность атаки / риски. Он также позволяет делать гораздо больше, избегая ограничений 3074 на определенные классы операционных кодов.

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

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

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

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

Отказ от ответственности：

1. Эта статья взята из [2077.xyz], Все авторские права принадлежат автору оригинала [zhev]. Если есть возражения по поводу этого перепечатывания, пожалуйста, свяжитесь с Gate Learnкоманда, и они незамедлительно справятся с этим.
2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, принадлежат исключительно автору и не являются какими-либо инвестиционными рекомендациями.
3. Переводы статьи на другие языки выполняются командой Gate Learn. Если не указано обратное, копирование, распространение или плагиат переведенных статей запрещены.