Ethereum имеет два типа счетов: Внешняя учетная запись (EOA) и Контрактная учетная запись (CA). EOA управляются закрытым ключом, в то время как центры сертификации управляются содержащимся в них кодом смарт-контракта. EOA всегда были более привилегированными, чем ЦС, потому что только EOA могут начать выполнение транзакций, заплатив газ. Абстракция счета (AA) — это предложение, которое позволяет контракту быть счетом «верхнего уровня», таким как EOA, который может оплачивать комиссию и начинать выполнение транзакций.

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

Приложение Status Messenger объединяет мессенджер, ориентированный на конфиденциальность, вместе с кошельком Ethereum и браузером Web3 ÐApp. Кошелек Status в настоящее время является кошельком EOA, который ограничивает нас в предложении богатого пользовательского интерфейса, который может предложить только кошелек смарт-контрактов, такой как безопасность мультиподписи, социальное восстановление, ограничение скорости, список разрешений/запретов адресов и мета-транзакции без комиссий. Однако пользовательский интерфейс смарт-контрактов сегодня серьезно затруднен колебаниями цен на газ, что неэффективно решается сторонними ретрансляторами. AA имеет целью решить эту проблему.

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

История и мотивация

Абстрагирование учетной записи было изначально предложено как EIP-86в 2017 году для реализации «Абстракции источника транзакции и подписи», но истоки мотивирующей идеи уходят еще дальше в прошлое доначало 2016 года, где было предложено следующее: «Вместо наличия механизма в протоколе, где ECDSA и схема значения по умолчанию установлены как единственный «стандартный» способ обеспечения безопасности учетной записи, мы предпринимаем первые шаги к модели, в рамках которой в долгосрочной перспективе все учетные записи являются контрактами, контракты могут оплачивать газ, и пользователи вольны определять свою собственную модель безопасности».

Первоначальные предложения считались сложными для реализации из-за необходимости множества требуемых изменений протокола и обеспечения требуемых гарантий безопасности. Более недавно Виталик и др. предложили проект для EIP-2938который описывает гораздо более простую реализацию путем минимизации изменений протокола/консенсуса и обеспечения необходимых гарантий безопасности с помощью правил памяти узла. Виталик'sПрезентация группы инженеров Ethereum на встречеиПрезентация ETHOnline(вместе с сопроводительными статьями @SamWilsn/ryhxoGp4D">1 & @SamWilsn/S1UQDOzBv">2) Сэм Уилсон и Ансгар Дитрихс (два из других авторов EIP) предлагают отличные введения в тему. В этой статье подчеркиваются ключевые аспекты из всех этих источников.

Мотивация: Мотивирующее обоснование AA очень простое, но фундаментальное: сегодня у транзакций Ethereum есть программируемые эффекты (достигаемые через вызовы смарт-контрактов), но у них фиксированная валидность в том смысле, что транзакции действительны только в случае наличия действительной подписи ECDSA с действительным nonce и достаточным балансом счета. AA обновляет транзакции с фиксированной валидностью до программной валидности, вводя новый тип транзакции AA, который всегда исходит из специального адреса, для которого протокол не требует подписи, проверки nonce или проверки баланса. Валидность таких транзакций AA определяется целевым смарт-контрактом, который может навязать свои собственные правила валидности, после чего он может решить оплатить такие транзакции.

Итак, зачем это полезно? Давайте рассмотрим пример кошельков Ethereum, чтобы продемонстрировать пользу AA.

Кошельки смарт-контрактов: Большинство кошельков Ethereum сегодня являются кошельками EOA, которые защищены частным ключом, сгенерированным из фразы-семени. (A BIP-39Семантическая фраза или мнемоническая фраза - это упорядоченный список из 12-24 слов, которые случайным образом выбираются из списка из 2048 слов. Это обеспечивает необходимую энтропию для получения двоичного семени, которое генерируется с использованием функции PBKDF2. Двоичное семя затем используется для генерации асимметричных ключевых пар для BIP-32Кошелек.) Ожидается, что пользователь запишет фразу восстановления где-то в безопасном месте, потому что впоследствии ее можно потребовать для восстановления ключей в другом кошельке. Такие кошельки, однако, уязвимы для кражи закрытого ключа или потери фразы восстановления, что приводит к потере средств пользователя.

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

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

Примеры умных контрактных кошельков - Аржент, Authereum, Dapper, Дхарма, Gnosis Safe, МонолитиMYKEY. Принятие таких кошельков, по всей видимости, увеличивается, как это указано ниже граф.

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

Gnosis Safe - это кошелек с мультиподписью, ориентированный на управление средствами команды, который требует минимального количества (m из n) участников команды для утверждения транзакции перед ее совершением. Он также позволяет безгазовые подписи через мета-транзакции.

Все эти продвинутые возможности кошелька требуют использования нетривиальных смарт-контрактов. Пользователи кошелька либо нуждаются в EOA с газом для взаимодействия с ними, либо зависят от поставщика кошелька для поддержки мета-транзакций через релеи поставщика или сторонние сети релееров, такие как Сеть заправок. В то время как первая полагается на ETH, обычно приобретаемый на централизованных биржах после KYC, вторая нацелена на уменьшение этого трения в UX при вводе, перекладывая бремя пользователя на релеи за счет, который компенсируется поставщиком кошелька on-/off-chain и/или пользователем off-chain.

Однако архитектура, основанная на ретрансляторах, имеет три основных недостатка: (1) их могут рассматривать как централизованных посредников с потенциалом для цензуры транзакций; (2) технически и экономически неэффективны из-за необходимости в дополнительной базовой газовой плате в размере 21000 для транзакции ретранслятора и их бизнес-необходимости получения прибыли поверх газовых сборов; (3) использование протоколов, специфичных для ретрансляторов, заставляет приложения полагаться на инфраструктуру Ethereum не базового уровня с меньшими пользовательскими базами и неопределенными гарантиями доступности.

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

Tornado Cash: Связанное мотивирующее приложение - это миксер, например, tornado.cash где @tornadoTornado улучшает конфиденциальность транзакций, разрывая он-чейн связь между адресами с помощью смарт-контракта, который принимает депозиты ETH, которые позже могут быть выведены другим адресом. Ожидается, что пользователь предоставит хэш секрета во время депозита, а затем предоставит zkSnark доказательство при выводе, чтобы показать знание секрета, не раскрывая сам секрет или ранее внесенный депозит. Это отделяет вывод от депозита.

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

Абстракция учетной записи решит эту проблему, позволяя контракту Tornado принимать транзакцию AA на вывод пользователя, проверять zkSnark, удерживать некоторые комиссии за газ (из предыдущей суммы депозита) и затем переводить оставшуюся сумму депозита на адрес вывода.

Абстракция учетной записи

Абстракция учетной записи, как предложено в EIP-2938, позволяет контракту быть учетной записью верхнего уровня, которая оплачивает сборы и запускает выполнение транзакции. Это достигается путем введения изменений протокола с новым типом транзакции AA, который требует две новые операции: NONCE и PAYGAS, изменения правил пула транзакций и расширения для поддержки расширенных использований. Типы учетных записей остаются двумя (EOA и контрактная учетная запись), и все предложенные изменения обратно совместимы с текущими транзакциями, умными контрактами и протоколом.

Применения AA рассматриваются в двух категориях: 1) Однозакранные приложения, такие как кошельки для смарт-контрактов, которые создают новый контракт для каждого пользователя 2) Многозакранные приложения, такие как tornado.cash или Uniswap, где несколько пользователей взаимодействуют с одним набором смарт-контрактов.

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

Изменения протокола

Вместе с двумя поддерживающими кодами операции NONCE и PAYGAS был введен новый тип транзакции. Это единственные изменения в протоколе.

Транзакция AA: Введен новый тип транзакции AA_TX_TYPE. Его полезная нагрузка интерпретируется как RLP([nonce, target, data]) вместо существующего типа транзакции, чья полезная нагрузка интерпретируется как RLP([nonce, gas_price, gas_limit, to, value, data, v, r, s]).

Пропущенные gas_price и gas_limit в AA-транзакции указываются целевым AA-контрактом во время выполнения. Пропущенная подпись ECDSA v, r, s в AA-транзакции заменяется проверками на специфическую контрактную проверку данных. Адрес to заменяется адресом целевого контракта. Значение опущено, потому что исходный адрес для всех AA-транзакций является специальным адресом ENTRY_POINT (0xFFFF…FFFF) и не является EOA, у которого есть связанное с ним значение.

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

Базовая стоимость газа транзакции AA предлагается установить на уровне 15000 вместо текущих 21000 (для отражения экономии затрат в связи с отсутствием внутренней подписи ECDSA). Кроме того, у транзакций AA нет встроенного предела газа. При начале выполнения предел газа просто устанавливается на оставшийся газ в блоке.

Операция NONCE: операция NONCE (0x48) помещает nonce вызываемого, т. е. целевого контракта AA, на стек EVM. Таким образом, Nonces подвергаются EVM, чтобы позволить проверку подписи выполняться над всеми полями транзакции (включая nonce) в рамках проверки в контракте AA.

Опкод PAYGAS: Опкод PAYGAS (0x49) берет два аргумента со стека: (верхний) номер_версии, (второй сверху) начало_памяти. Номер_версии позволяет будущим реализациям изменять семантику опкода. В настоящее время опкод имеет следующую семантику:

1. Проверьте version_number == 0 (в противном случае сгенерируйте исключение)
2. Прочтите gas_price = bytes_to_int(vm.memory[memory_start: memory_start + 32])
3. Прочитайте gas_limit = bytes_to_int(vm.memory[memory_start + 32: memory_start + 64])
4. Проверьте contract.balance >= gas_price * gas_limit (иначе выбросьте исключение)
5. Проверьте globals.transaction_fee_paid == False (иначе вызовите исключение)
6. Проверьте рамку выполнения AA == верхний уровень рамки, т.е. если текущее выполнение EVM завершается или откатывается, выполнение EVM всей транзакции прекращается (иначе генерируется исключение)
7. Уменьшить contract.balance -= gas_price * gas_limit
8. Установить globals.transaction_fee_paid = True
9. Установите globals.gas_price = gas_price и globals.gas_limit = gas_limit
10. Установите оставшийся газ текущего контекста выполнения = лимит газа - уже потребленный газ

По окончании выполнения транзакции AA (globals.gas_limit - remaining_gas)globals.gas_price передается майнеру, а контракт AA возвращает оставшийся газglobals.gas_price.

PAYGAS действует как контрольная точка выполнения EVM. Любые откаты после этой точки будут откатываться только до этого момента, а затем контракт не получит возврата, и globals.gas_limit * globals.gas_price будет передан майнеру.

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

Правила Mempool

“The mempoolотносится к набору структур данных в памяти в узле Ethereum, который хранит кандидаты на транзакции до их добычи. Geth называет его «пулом транзакций»; Parity называет это «очередью транзакций». Независимо от названия, это пул транзакций, находящихся в памяти и ожидающих включения в блок. Представьте себе это как «зону ожидания» для транзакций, которые должны быть приняты в блок.

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

Транзакции AA вводят большую сложность с их программируемой действительностью. Транзакции AA не платят вперед газ и полагаются на свои целевые контракты AA, чтобы оплатить газ (через PAYGAS). Концептуально обработка транзакций AA разделена на две фазы: более короткая фаза верификации (до PAYGAS) и более длинная фаза выполнения (после PAYGAS). Если фаза верификации не проходит (или генерирует исключение), транзакция недействительна (как и не-AA транзакция с недействительной подписью сегодня), не включается в блок и майнер не получает комиссии.

Майнерам и узлам поэтому необходимо предсказуемый механизм, чтобы избежать зависимости действительности ожидающей транзакции AA от других ожидающих транзакций в пуле. В противном случае выполнение одной транзакции может аннулировать множество/все транзакции AA в пуле, что может привести к атакам типа DoS. Чтобы избежать этого сценария, существуют два предлагаемых правила, которые должны соблюдаться (майнерами и узлами, но не в самом протоколе) в отношении транзакций AA в пулах:

Ограничение операции

Для того чтобы предотвратить зависимость допустимости AA-транзакции от любого внешнего состояния, не относящегося к самому контракту AA, следующие операции считаются недопустимыми на этапе верификации (т. е. до PAYGAS): операции окружения (BLOCKHASH, COINBASE, TIMESTAMP, NUMBER, DIFFICULTY, GASLIMIT), BALANCE (любого счета, включая целевой счет), внешний вызов/создание чего-либо, кроме цели или предварительной компиляции (CALL, CALLCODE, STATICCALL, CREATE, CREATE2) и внешний доступ к состоянию, который считывает код (EXTCODESIZE, EXTCODEHASH, EXTCODECOPY, DELEGATECALL), если только адрес не является целью.

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

Ограничение префикса байткода

Если незащищенные транзакции могут влиять на состояние контрактов AA, то это повлияет на допустимость транзакций AA в памяти. Для предотвращения этого транзакции AA должны разрешаться только для контрактов, у которых в начале байт-кода есть AA_PREFIX, где AA_PREFIX выполняет проверку, что msg.sender является специальным адресом ENTRY_POINT для транзакций AA. Это эффективно предотвращает взаимодействие незащищенных транзакций с контрактами AA.

Узлы ожидают отбрасывания транзакций AA к контрактам AA, у которых нет этого AA_PREFIX в точках входа их байт-кода.

Эти два ограничения, применяемые к контрактам AA вместе, обеспечивают, что: (1) единственное состояние, к которому можно получить доступ через логику проверки правильности транзакции AA, является состоянием, внутренним для контракта AA, и (2) это состояние может быть изменено только другими транзакциями AA, нацеленными на этот конкретный контракт AA.

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

Расширения

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

1. Опкод SET_INDESTRUCTIBLE, который отключает SELFDESTRUCT и позволяет контрактам AA безопасно вызывать библиотеки с помощью DELEGATECALL на этапе верификации.
2. Опкод IS_STATIC, который возвращает true, если текущий контекст статический, и позволяет нестандартным вызывающим транзакциям переопределять предыдущее ограничение префикса байт-кода и безопасно считывать значения из контрактов AA.
3. Опкод RESERVE_GAS, который устанавливает нижнюю границу газа, потребляемого контрактом AA при вызове из транзакции, не являющейся AA, и стремящейся записать состояние контракта. Это служит для того, чтобы заставить злоумышленников тратить минимальное количество газа с целью отучить их от попыток аннулировать любые транзакции AA в пуле памяти.

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

Следующие шаги

Абстракция учетной записи EIP-2938 в настоящее время находится в черновом режиме и обсуждается на исследовательских форумах Ethereum. Следующим шагом для EIP является рассмотрение вопроса о включении в один из предстоящих хардфорков. Авторы EIP, по-видимому, нацелены на хардфорк после Берлина (Берлин предварительно запланирован на какое-то время в начало 2021 года) чей график в данный момент не очень ясен. Поэтому для EIP-2938 процесс все еще на ранней стадии.

Кроме того, также не ясно, будет ли необходимо включать EIP-2938 в Ethereum базовый уровень 1 (L1). Учитывая относительную гибкость решений уровня 2 (L2) (как описано в нашем ранеестатья) Реализация абстракции учетной записи может быть осуществлена на конкретных L2 без необходимости обновления всего L1. Однако есть преимущества в поддержке единой AA на L1, даже если некоторые L2 реализуют свои собственные версии AA. Поэтому пока неясно, где и как будет реализована AA.

«Абстракция учетной записи менее важна, потому что ее можно реализовать на L2 независимо от того, поддерживает ли L1 ее или нет.» — Виталик о вещах, которые будут продолжать иметь значение на базовом уровне (в егопостна центрической дорожной карте Ethereum).

Статус: В настоящее время кошелек Status является кошельком EOA, который отличается путем пакетирования приватного мессенджера и обеспечения интеграций, таких как платежи в чате или улучшенная безопасность сКарта доступаФункции кошелька смарт-контракта, такие как мультисиг и социальное восстановление, рассматриваются для которых поддержка AA EIP-2938 поможет, убрав зависимость от централизованных и неэффективных архитектур на основе релеев, как описано ранее.

Status также рассматривает решения L2 как для поддержки нескольких цепей в своем кошельке, так и для обеспечения необходимого масштабирования для различных использованных случаев, как описано в нашем ранее статья. Например, Keycard исследует сеть платежейчьи требования к дизайну масштабируемости на уровне кредитной карты и мгновенной окончательности не выполняются сегодня сетью Ethereum. Кроме того, существует множество других инициатив, таких какПрограмма рефералов, Реакции SNT, Tribute-to-TalkиИмена ENS, все из которых могли бы получить преимущества от масштабируемости L2 для реального развертывания и приемлемого пользовательского опыта. Если жизнеспособное решение L2 реализует AA, то проекты, разрабатывающиеся на этом L2, смогут использовать преимущества AA, не полагаясь на L1.

Сводка

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

AA имеет последствия для значительного улучшения пользовательского опыта в различных сценариях, таких как кошельки, миксеры, ÐApps и DeFi без использования централизованных и неэффективных архитектур на основе реле. Основные сценарии с одним арендатором, такие как кошельки смарт-контрактов, могут быть безопасно поддержаны AA с введением нового типа транзакции, двух новых опкодов и двух правил пула памяти. Расширенные многопользовательские приложения, такие как Tornado Cash, требуют расширения этих изменений протокола и правил узла.

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

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

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

1. Эта статья перепечатана из [ статус], Пересылать оригинальный заголовок‘Account Abstraction (EIP-2938): Why & What’, Все авторские права принадлежат оригинальному автору [ Раджив Гопалакришна]. Если есть возражения по поводу этого перепечатывания, пожалуйста, свяжитесь с Gate Learnкоманда, и они незамедлительно справятся с этим.

2. Отказ от ответственности: Взгляды и мнения, выраженные в этой статье, являются исключительно мнением автора и не являются инвестиционным советом.

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