Абстракция аккаунтов: прошлое, настоящее, будущее

Даже в разгар медвежьего рынка мало кто сомневается, что крипто пришло всерьёз и надолго — взять хотя бы кошельки вроде MetaMask, которыми уже пользуются миллионы людей. Тем не менее вопрос остаётся открытым: «Как привлечь следующий миллиард пользователей в web3?»

В зависимости от того, кого спросить, ответы будут разными. Но все сходятся в одном — необходимо улучшить опыт взаимодействия пользователей с блокчейн-приложениями. Без повышения удобства web3 у людей практически нет стимула отказываться от привычных web2-приложений.

«Account abstraction» — это предложение, направленное на улучшение взаимодействия пользователей с Ethereum, которое всё чаще становится темой обсуждений в криптосообществе. Возможно, вы задаётесь вопросом: «Что такое account abstraction и почему это важно для меня?»

Эта статья поможет вам разобраться в account abstraction, рассмотрев её прошлое, настоящее и будущее в контексте. Мы ответим на все возможные вопросы по этой теме — кто, что, почему, как и когда применительно к account abstraction.

Краткое резюме ключевых тезисов:

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

• Account abstraction вносит существенные изменения, открывающие путь к широкому распространению доверенных, устойчивых к цензуре смарт-аккаунтов. Рассматриваются различные подходы к реализации account abstraction — каждый со своими преимуществами и компромиссами.

• MetaMask поддерживает внедрение account abstraction через свою открытую платформу для инноваций: MetaMask Snaps. С помощью MetaMask Snaps разработчики могут расширять возможности MetaMask, принося преимущества account abstraction криптопользователям по всему миру.

Что такое account abstraction?

Как и любая другая новая концепция в web3, account abstraction непросто поддаётся определению. Тем не менее лучше понять её можно, сначала разобравшись в терминах, связанных с обсуждением account abstraction в Ethereum:

1. Абстракция (сущ.): (Довольно сложный) термин в информатике, который в общих чертах означает сокрытие информации о системе или приложении, чтобы ими можно было пользоваться, не зная деталей фоновых процессов. Также определяется как «процесс сокрытия сложности системы путём предоставления интерфейса, упрощающего работу с ней».

2. Аккаунт (сущ.): Представление пользователя в блокчейне, которое может отправлять и получать транзакции, а также взаимодействовать с другими on-chain аккаунтами. В Ethereum существует два типа аккаунтов: Externally Owned Accounts (EOA) и контрактные аккаунты (они же «смарт-контракты»).

2a. Externally Owned Accounts (EOA): Аккаунты Ethereum, созданные с помощью программного обеспечения кошелька (например, MetaMask) и управляемые криптографической парой публичного и приватного ключей. EOA является «активным» (он может инициировать транзакции и оплачивать газ за выполнение EVM). Однако он ограничен базовыми операциями — например, отправкой Ether или взаимодействием с контрактами.

2b. Контрактные аккаунты: Аккаунты Ethereum, развёрнутые в виде смарт-контракта и управляемые логикой, написанной в коде (а не приватным ключом). Контрактный аккаунт является «пассивным»: он может отправлять транзакции только в ответ на транзакцию от EOA и не может оплачивать газ. Однако он программируем и способен выполнять произвольную логику в зависимости от кода, хранящегося по адресу.

1. Кошелёк (сущ.): Интерфейс для управления средствами на вашем аккаунте Ethereum — принцип работы кошелька зависит от типа связанного с ним аккаунта. Кошелёк на основе EOA, такой как MetaMask, требует приватного ключа для авторизации транзакций. Кошелёк на основе смарт-контракта связан с контрактным аккаунтом и может использовать произвольную логику для авторизации транзакций (например, схему мультиподписи).

Разобравшись с определениями, мы можем перейти к понятию account abstraction.

Определение account abstraction

Account abstraction — это предложение по повышению гибкости в управлении и поведении аккаунтов Ethereum. Это достигается путём введения account contracts: смарт-контрактов специального назначения, которые определяют аккаунт пользователя в Ethereum и управляют им (теперь называемым смарт-аккаунтом).

С account abstraction вы получаете программируемый доступ к средствам через кошелёк на основе смарт-контракта, не полагаясь исключительно на приватные ключи для обеспечения безопасности. Это возможно, поскольку ваш смарт-аккаунт может иметь пользовательские правила для расходования монет и перевода активов.

Так как же «абстракция» вписывается во всё это?

С точки зрения сети, «account abstraction» означает, что детали типов аккаунтов невидимы для протокола Ethereum. Каждый аккаунт (включая самостоятельные) — это просто смарт-контракт, и пользователи вольны сами определять, как управляются и работают отдельные аккаунты.

С точки зрения пользователя, «account abstraction» означает, что определённые технические детали взаимодействия с аккаунтами Ethereum скрыты за высокоуровневыми интерфейсами. Это улучшает дизайн кошельков и значительно снижает сложность использования web3-приложений.

Это уточнение необходимо, поскольку путаница вокруг account abstraction возникает из-за непонимания (a) что именно абстрагируется и (b) где происходит абстракция. Аккаунты не обязательно абстрагируются от пользователей (даже если они абстрагируются от протокола). У вас по-прежнему есть адрес кошелька для получения средств и ключ подписи, гарантирующий, что только вы можете тратить эти средства.

С вашей точки зрения, account abstraction — это скорее использование смарт-аккаунта, который абстрагирует некоторые детали взаимодействия с блокчейном. Для понимания контекста: вот как выглядит взаимодействие с dapp с точки зрения пользователя, впервые сталкивающегося с этим:

С account abstraction разработчики кошельков могут создавать системы, которые берут на себя эти процессы в фоновом режиме и упрощают работу с web3 (если коротко: кошельки становятся «невидимыми»). Среди сценариев использования (которые мы рассмотрим подробнее позже): устранение необходимости хранить seed-фразы/приватные ключи, оплачивать газ за транзакции или самостоятельно создавать on-chain аккаунт.

Преимущества account abstraction

Как уже упоминалось, account abstraction устраняет большинство барьеров, связанных с использованием web3-кошельков и взаимодействием с dapp. Это приближает web3 к идеалу web2, где все пользователи — как новички, так и опытные — могут пользоваться одинаковой степенью гибкости, безопасности и удобства.

В частности, account abstraction имеет огромное значение для будущего самостоятельного хранения активов. Благодаря функциям, предоставляемым account contracts, использование web3-кошелька будет ощущаться как использование банковского счёта или приложения — без необходимости доверять банку.

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

Абстракция подписи

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

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

2. Самостоятельное хранение активов может ощущаться как экстремальный спорт. В отличие от обычного банковского счёта, вы не можете «восстановить» EOA-кошелёк в случае утери seed-фразы/приватного ключа. Это создаёт серьёзную проблему для новых пользователей, которым приходится осознавать последствия полной и безвозвратной потери активов на аккаунтах Ethereum.

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

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

1. Лимиты транзакций: Кошелёк, связанный с вашим смарт-аккаунтом, может отклонить транзакцию (или запросить дополнительную авторизацию), если сумма превышает заранее установленный лимит. Звучит знакомо? Так и должно быть — банки уже делают это для защиты ваших счетов и кредитных карт от мошенничества, несанкционированного использования и других угроз безопасности.

2. Многостороннее подтверждение: Вы можете делегировать частичный контроль над своим аккаунтом доверенным лицам, так называемым «гардианам». Гардианами могут быть друзья, члены семьи, поставщики услуг или даже отдельное устройство, которым вы владеете (например, аппаратный кошелёк). Таким образом, вы можете включить многофакторную аутентификацию (MFA) в стиле web2 для своего кошелька, требуя одобрения гардиана для транзакций, выводящих средства с вашего смарт-аккаунта.

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

2. Доверенные сессии: Вам надоело подтверждать каждое действие при взаимодействии с dapp в браузере? Отлично! Вы можете создать специальные «сессионные ключи» в своём смарт-аккаунте, чтобы dapp автоматически подписывал транзакции в течение определённого периода. Это означает, что вы можете взаимодействовать с dapp — например, играть в блокчейн-игру — без надоедливых всплывающих окон кошелька.

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

1. Автоматические платежи: По аналогии с идеей сессионных ключей, вы можете разрешить поставщикам услуг «списывать» средства с вашего смарт-аккаунта (в соответствии с заранее определёнными правилами). Это делает возможным настройку регулярных платежей и подписок с помощью вашего web3-кошелька. Можете ли вы представить, что оплачиваете подписку на Netflix или коммунальные услуги через свой аккаунт Ethereum?

Абстракция комиссий

В настоящее время каждая транзакция Ethereum должна содержать «газовую комиссию», указывающую, сколько отправляющий EOA готов заплатить за выполнение. Газовые комиссии номинированы в Ether — нативном токене Ethereum. Это создаёт проблемы, особенно для новых пользователей, которым теперь нужно сначала раздобыть ETH, прежде чем отправить транзакцию.

Account abstraction не устраняет необходимость платить газовые комиссии, но абстрагирует детали того, как и когда пользователи выбирают способ оплаты газа (абстракция комиссий). Например, account abstraction позволяет реализовать «спонсируемые транзакции», при которых другой аккаунт покрывает стоимость газа за транзакцию пользователя. Некоторые преимущества спонсируемых транзакций:

1. Оплата газа не в ETH: Вы когда-нибудь хотели оплачивать комиссии за транзакции ERC-20 токенами из своего кошелька? Со спонсируемыми транзакциями вы можете воспользоваться услугами relayer с ETH, который авансирует стоимость ваших транзакций, а вы возмещаете ему расходы в другом токене, например DAI или USDC.

1. Транзакции без газа: Разработчики dapp могут спонсировать транзакции и минимизировать барьеры при онбординге новых пользователей Ethereum. По сути, вы можете пользоваться web3-приложениями, ничего не зная о «газе», и наслаждаться тем же опытом в один клик, который предоставляют web2-приложения.

1. Социальные логины: Dapp может развернуть контрактный кошелёк от вашего имени, решая проблему необходимости настройки кошелька перед отправкой on-chain транзакций. Самое приятное? Кошельки могут использовать инфраструктуру аутентификации (например, Web3Auth и WebAuthn), чтобы пользователи могли создавать web3-аккаунты с существующими учётными данными — например, адресом электронной почты или аккаунтом Facebook/Twitter.

Абстракция nonce

Смарт-аккаунты в Ethereum обладают ещё одной особенностью: пакетной обработкой транзакций. С помощью пакетных транзакций вы можете объединить несколько операций в одну on-chain транзакцию и снизить стоимость и сложность взаимодействия с dapp. Вот почему пакетная обработка транзакций важна:

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

Но есть одна загвоздка. Nonce вынуждает вас обрабатывать транзакции в порядке «первым пришёл — первым обслужен» (FIFO). Представьте, что у вас есть две транзакции (A и B) с nonce 0 и 1 соответственно. В этом случае вы отправляете транзакцию A и ждёте подтверждения (её выполнения) перед отправкой B.

Отправка B, пока A ещё ожидает обработки, просто приведёт к отклонению первой, поскольку nonce будет выше допустимого диапазона (текущий nonce EOA + 1). Фактически, именно по этой причине у вас возникают «зависшие транзакции» при использовании кошелька.

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

Тем не менее абстракция nonce сложна в реализации на практике и потенциально может нарушить определённые инварианты, критически важные для безопасности и UX (например, уникальность хэша транзакции). Именно здесь на сцену выходит пакетная обработка транзакций:

Поскольку смарт-аккаунты могут обрабатывать несколько транзакций одновременно, необходимость в сложных схемах абстракции nonce в значительной мере отпадает. Возвращаясь к предыдущему примеру, представим, что транзакции A и B — это лишь части одной гипотетической операции, например обмена активов на Uniswap:

• Транзакция A: Разрешить контракту Uniswap доступ к вашим токенам

• Транзакция B: Завершить обмен токенов

С пакетной обработкой транзакций вы можете объединить рабочий процесс «разрешить и обменять» в одну транзакцию. Результат: более низкие газовые комиссии и сокращение времени ожидания при использовании dapp. Неплохо, правда?

«Как» работает account abstraction

К этому моменту вы уже знаете, что account abstraction позволяет добавлять пользовательскую функциональность и политики авторизации к пользовательским аккаунтам. Но мы ещё не говорили о том, как именно это становится возможным. В этом разделе рассматриваются различные подходы к реализации абстракции в Ethereum (если это звучит не слишком увлекательно, смело переходите к следующему разделу).

Существует два общепринятых способа достижения account abstraction: (a) предоставление EOA возможности выполнять код EVM и (b) разрешение смарт-контрактам инициировать транзакции. Поэтому многие предложения по account abstraction либо хотят, чтобы EOA вели себя как смарт-контракты, либо чтобы контрактные аккаунты действовали как EOA.

Это естественно порождает ряд вопросов:

• «Чем именно эти подходы отличаются друг от друга?»

• «Почему важно, какой подход мы выберем?»

Account abstraction: Подход №1 (Обновление EOA для выполнения кода)

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

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

Ниже представлена инфографика с различными предложениями по account abstraction в лагере «сделать EOA программируемыми», включая их ключевые особенности и статус реализации:

Account abstraction: Подход №2 (Обновление смарт-контрактов)

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

Дело в том, что некоторые кошельки на основе смарт-контрактов уже существуют сегодня и предоставляют многие преимущества account abstraction. Но пользоваться этими кошельками крайне сложно, поскольку Ethereum относится к смарт-контрактам как к «гражданам второго сорта» и требует, чтобы все транзакции начинались с EOA.

Это ограничение также означает, что кошельки на основе смарт-контрактов лишены доверенности и самостоятельного хранения, присущих EOA-кошелькам вроде MetaMask. Для понимания контекста рассмотрим процесс создания и использования кошелька на основе смарт-контракта:

• Развернуть новый контрактный аккаунт

• Отправить транзакции для вызова функций вашего контракта кошелька

Проблема уже очевидна: теперь вам нужно управлять двумя кошельками. Почему? EOA (предварительно пополненный ETH) должен покрывать расходы на развёртывание кошелька и последующий вызов необходимых функций.

На сцену выходят relayer: EOA, которые могут оплачивать транзакции вашего кошелька в обмен на комиссию. Провайдеры кошельков на основе смарт-контрактов нередко запускают relayer для субсидирования транзакций пользователей. То есть relayer платит ETH из своего кошелька для покрытия ваших комиссий за транзакции и возмещает расходы, взимая с вас плату другим способом — возможно, в фиате или каком-либо другом токене.

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

Но это крипто, и нам нравятся доверенные системы.

Позволив контрактным аккаунтам подтверждать транзакции и оплачивать газ, account abstraction делает процесс создания и использования кошелька на основе смарт-контракта более доверенным. Если быть точным, это позволяет любому, кто запускает relayer, выполнять транзакции от вашего имени. Вам нужно лишь подписать сообщение, разрешающее relayer списать средства с баланса вашего кошелька после выполнения транзакции:

Теперь процесс использования кошелька на основе смарт-контракта выглядит несколько иначе:

• Развёртывание контракта кошелька? Используя рабочие процессы контрфактического развёртывания, вы можете отправить средства на контрактный аккаунт до его развёртывания и оплатить расходы на развёртывание EOA relayer с баланса вашего кошелька.

• Взаимодействие с контрактом кошелька? Подпишите сообщение off-chain и поручите relayer сделать вызов к вашему account contract. Сообщение будет содержать инструкцию для account contract возместить relayer расходы на газ.

Эта идея создания доверенных и устойчивых к цензуре смарт-аккаунтов лежит в основе многих предложений по account abstraction в данной категории. Например, ERC-4337 — наиболее популярное на сегодняшний день предложение по account abstraction — децентрализует relayer, вводя альтернативный mempool, куда пользователи могут отправлять транзакции контрактных кошельков для обработки.

В этом случае relayer (называемые «bundler'ами») могут конкурировать за выполнение транзакций смарт-аккаунтов, снижая риск цензуры или чрезмерной зависимости от провайдеров кошельков. Ниже представлена инфографика с различными предложениями по account abstraction в лагере «наделить смарт-контракты функциями EOA», включая их ключевые особенности и статус реализации:

О будущем account abstraction

Спустя годы после того, как Виталик Бутерин впервые представил эту концепцию, по-прежнему нет единого мнения о наилучшем способе реализации account abstraction. Например, реализация EIP-3074 и EIP-5003 позволила бы существующим EOA (включая пользователей MetaMask) перейти на смарт-аккаунты. Но эти предложения требуют хардфорка, что, учитывая сосредоточенность сообщества на более насущных обновлениях, пока представляется нереалистичным.

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

В MetaMask мы убеждены, что account abstraction является ключом к обеспечению плавного онбординга новых пользователей web3. Мы также понимаем, что EOA не могут гарантировать массовое распространение крипто («Следующий миллиард пользователей не будет записывать 12 слов на бумаге», — образно выразился исследователь Ethereum Foundation Йоав Вайс).

Поэтому мы начали искать способы предоставить преимущества account abstraction, не жертвуя привычным и любимым пользователями кошельком MetaMask. Частью этих усилий является обращение к MetaMask Snaps — открытой платформе для инноваций, позволяющей разработчикам создавать пользовательские функции поверх существующей инфраструктуры MetaMask.

Используя Snaps, разработчики могут расширять функциональность вашего кошелька MetaMask для поддержки различных сценариев использования account abstraction. От сессионных ключей до полноценных интеграций смарт-аккаунтов, созданных с MetaMask — всё это реализовано с помощью Snaps — мы видим, как разработчики принимают вызов и используют MetaMask для демократизации доступа к account abstraction для пользователей.

«Не позволяйте совершенному быть врагом хорошего». — Вольтер

Нынешнее предложение по account abstraction — пусть и не идеальное — является гигантским шагом к достижению доверенных, устойчивых к цензуре смарт-аккаунтов в Ethereum и заслуживает всесторонней поддержки. Цитируя одного из наших коллег, Тейлор Монахан: «Реализованное наполовину решение всё равно лучше, чем нереализованное идеальное».

Именно поэтому наша следующая статья по теме account abstraction будет представлять собой глубокое погружение в детали ERC-4337. В частности, мы обсудим, как web3-разработчики могут начать строить будущее account abstraction и привлекать следующий миллиард пользователей — строчка за строчкой кода — с помощью MetaMask.

Следите за обновлениями!

Особая благодарность Патрику МакКорри, Саймону Брауну, Мирко Гарацо, Кристиану Монтойе, Оливеру Ренвику и Меган Диас за отзывы на ранние версии этой статьи. Отдельная признательность Клариссе Уотсон и Франческо Андреоли, оказавшим поддержку и руководство на начальных этапах проекта.