EIP-3074 в одночасье стал самой горячей темой, поскольку его разрешили включить в следующий хард-форк Ethereum (Pectra/Petra). Однако о чем идет речь и как это повлияет на Ethereum и экосистему EVM? В этой статье мы рассмотрим это предложение, ответим на часто задаваемые вопросы и развеем некоторые мифы и недоразумения. Давайте погрузимся, ладно?
Обзор абстракции учетной записи EIP/ERC
Чтобы лучше понять абстракцию учетной записи, вам необходимо знать, что в 99% случаев, когда кто-то говорит «абстракция учетной записи», он имеет в виду «умные (контрактные) учетные записи», то есть когда учетная запись основана на коде контракта, а не на коде контракта. один закрытый ключ. Он по-прежнему может быть аутентифицирован с помощью одного закрытого ключа, как это происходит в большинстве случаев (это важно позже), но это также может быть кошелек с мультиподписью, как в случае с Safe.
Первоначальное значение «абстракции учетной записи» заключалось в том, чтобы «позволить смарт-контрактам инициировать транзакции», но с тех пор оно изменилось на «все функции, которые поддерживают учетные записи смарт-контрактов».
Учетные записи смарт-контрактов включают эти и многие другие функции.
Абстракция газа: децентрализованные приложения спонсируют газ, пользователь платит газ в различных токенах ERC20 или даже предоплату за газ, что отлично подходит для межсетевого подключения.
Это отлично подходит для конфиденциальности и OpSec, поскольку исключает необходимость доксинга, когда вы просите друзей пополнить ваш счет с помощью ETH MATIC, независимо от национальной валюты цепочки/агрегата, или, что еще хуже, вывода средств с бирж.
Пакетная обработка транзакций: или объединение нескольких действий в одну транзакцию. Это великолепно как с точки зрения безопасности, так и с точки зрения эффективности использования газа.
Безопасность: решение вопросов одобрения ERC-20. В качестве побочного эффекта пакетной обработки мы можем утверждать точную сумму вместе с каждым действием, которое требует этого, тем самым устраняя проблему утверждения. Почему? Потому что нам не нужны бесконечные/остаточные утверждения, и нам не нужна вторая подпись для утверждения.
Пользовательская криптография: включение новых криптографических кривых, WebAuthn, безопасный анклав iOS, квантовая безопасность и многое другое.
Ротация ключей и восстановление учетной записи: изменение закрытых ключей существующей учетной записи или восстановление учетной записи с помощью таких схем, как социальное восстановление Арджента.
Заметили что-нибудь? Все это так или иначе помогает безопасности.
Вернемся к ERC.
Как правило, все ERC, связанные с абстракцией учетной записи, заявляют, что эти функции являются их мотивацией, но они не обязательно их предоставляют; они просто помогают проложить путь к распространению этих функций.
Давайте разберемся. Крупные ERC решают определенные проблемы:
Инициирование транзакции: способность контрактов инициировать транзакции.
Собственный: специальный тип транзакции внутри протокола, который может исходить из смарт-контракта. Включает ERC-2938, позже замененный на RIP-7560.
Эмулируемый: ERC-4337 «эмулируется» в том смысле, что транзакции фактически все еще инициируются EOA. Это не означает, что пользователь должен знать об этом EOA. Этот EOA контролируется и управляется сборщиком.
Преобразование существующих пользователей: здесь на помощь приходит EIP-3074 (и его меньший помощник ERC-5003).
EIP-3074 позволяет делегировать управление СУЩЕСТВУЮЩИМ EOA смарт-контракту. Смарт-контракт может управлять этим EOA и совершать вызовы с его адреса, но не может инициировать транзакции. Это важно, поскольку нам еще предстоит решить проблему инициации транзакции.
ERC-5003 позволяет «полностью» преобразовать EOA в учетную запись смарт-контракта благодаря отзыву исходного закрытого ключа, который действует как главный ключ для этого EOA.
Подписи: Контракты обычно не могут быть подписаны подписями. Но они вроде как могут... они могут определить логику, которая определяет, что является действительной подписью для этого контракта. Например, кошелек со смарт-контрактом, использующий мультиподпись между Бобом и Алисой, определит действительную подпись как isValidSignature = isValid(bobsSignature) AND isValid(alicesSignature). Это должно быть определено в коде контракта.
ERC-1271 определяет интерфейс, позволяющий это сделать.
ERC-6492 расширяет его для поддержки еще не развернутых учетных записей смарт-контрактов: это позволяет беспрепятственно использовать один и тот же адрес во всех цепочках, в то же время позволяя пользователю подписывать сообщения.
Для работы оба должны быть реализованы с помощью dApps.
Чтобы по-настоящему создать опыт АА, вы должны решить все вышеперечисленные задачи одновременно. Вот почему EIP-3074 не конкурирует с ERC-4337, RIP-7560 или любой другой абстракцией учетной записи ERC.
Если вы хотите увидеть все это визуально, мы предлагаем этот слайд из доклада о демистификации AA ERC.
Разрушение мифов об обычном EIP-3074 FUD
Начнем со слона в комнате. Было три части FUD, связанных с EIP-3074:
Позволяет вредоносным децентрализованным приложениям опустошать существующие кошельки за одну транзакцию: это правда, что такая подпись может быть создана, но у поставщика кошельков нет причин или вариантов использования, чтобы когда-либо разрешать децентрализованным приложениям заставлять вас подписывать такие запросы. Защитить это со стороны кошелька намного проще, чем защитить сам ваш закрытый ключ, и утечка закрытого ключа имеет тот же эффект.
Учетная запись сохраняет один главный ключ (исходный ключ EOA). Эту проблему решает дополнительный ERC, EIP-5003, также известный как AUTHUSURP, который позволяет отозвать исходный закрытый ключ.
EIP-3074 — это пластырь, который не дает преимуществ встроенного АА: EIP-3074 никогда не предназначался для конкуренции с реальными предложениями АА, такими как RIP-7560. Это не пластырь для АА; это путь миграции. Нам по-прежнему нужен собственный AA, потому что, как мы помним ранее, он не решает проблему инициации транзакций.
Плюсы и минусы ЭИП-3074
Плюсы: он создает очень простой путь миграции для существующих пользователей MetaMask, Trezor, Ledger и т. д., чтобы они могли испытать функции абстракции учетных записей в своих существующих учетных записях.
Минусы: это жертвует вращением клавиш. Хотя все упомянутые выше функции AA можно включить, ротация ключей становится немного неуловимой, поскольку исходный закрытый ключ сохраняет контроль над учетной записью во всех сетях, которые никогда не использовались, даже с EIP-5003.
Умственные упражнения
Вот умственное упражнение, которое поможет вам понять движущиеся части:
В основной сети Ethereum существует EOA, аlice.eth (0x696969..69). Этот EOA по определению является межсетевым, поэтому он также существует во всех объединениях и цепочках EVM.
Этот EOA контролируется исключительно закрытым ключом A, принадлежащим Алисе.
EIP-3074 запущен в эксплуатацию.
Вредоносное децентрализованное приложение пытается обмануть Алису и просит ее подписать подпись EIP-3074 AUTH, разрешающую вредоносный контракт. Кошелек игнорирует этот запрос и отключает dApp, потому что он хорошо реализован, и нет возможности когда-либо разрешить это из dApp.
Алиса нажимает кнопку «Включить абстракцию учетной записи» на своем провайдере кошелька (скажем, MetaMask, через Snap или Ambire, естественно). Кошелек подписывает подпись EIP-3074 AUTH, разрешающую контракт, созданный поставщиком кошелька, который помогает выполнять пакетную обработку, газовое спонсорство и т. д.
Этот контракт контролируется исключительно с помощью закрытого ключа А.
alice.eth теперь отдельно контролируется двумя объектами: закрытым ключом A (в режиме EOA) и новым контрактом, который сам по себе также контролируется исключительно закрытым ключом A.
Теперь Алиса может выполнять пакетную обработку, но для спонсорства газа провайдеру кошелька Алисы необходимо внедрить либо ERC-4337, либо RIP-7560 (если сеть его поддерживает), либо собственный ретранслятор, чтобы Алисе не приходилось использовать свой ETH ( что является жестким требованием сети, если вы хотите инициировать транзакцию).
Алиса решает преобразовать alice.eth в мультиподпись, и провайдер кошелька дает указание контракту отозвать закрытый ключ A и авторизовать 2/2 мультиподписи частных ключей BMobilePhone и BLaptop.
Однако это не работает, поскольку закрытый ключ A по-прежнему контролирует Alice.eth: согласно EIP-3074, исходный закрытый ключ сохраняет контроль, несмотря на то, что он делегирован контракту.
EIP-5003 запускается на Ethereum и позволяет alice.eth отправлять в сеть специальную инструкцию через своего провайдера кошелька, чтобы отменить контроль над закрытым ключом A.
alice.eth теперь успешно конвертирован в мультиподпись, но только на Ethereum. Закрытый ключ A (принадлежит Алисе) по-прежнему сохраняет контроль над alice.eth во всех других сетях.
В конечном итоге мы узнали несколько вещей:
Мы сделали нечто потрясающее, потому что без EIP-3074 Алиса, вероятно, никогда бы не приняла абстракцию учетной записи.
EIP-3074 не решает всего; нам по-прежнему нужны ERC-4337 и RIP-7560 столько же, сколько нам было нужно вчера.
EIP-3074 не очень хорошо справляется с вращением клавиш, даже если у нас есть EIP-5003. Вот почему нам по-прежнему нужны настоящие смарт-аккаунты для облегчения таких вариантов использования, как мультиподпись и ротация ключей.
В качестве примечания: мы считаем, что ротация ключей является слишком новой для большинства и немного запутанной в мире перекрестных цепочек, где у вас нет одинакового состояния между всеми объединениями и цепочками. Большинство пользователей, похоже, придерживаются парадигмы «один ключ = одна учетная запись», особенно с аппаратными кошельками, которые достаточно безопасны для большинства случаев использования.
Часто задаваемые вопросы
Остальная часть этой статьи будет в формате часто задаваемых вопросов, чтобы мы могли лучше ответить на некоторые из наиболее распространенных вопросов, которые возникают у людей.
Поможет ли это MetaMask продвинуться вперед?
Мы считаем, что компании, занимающиеся абстракцией учетных записей, получат гораздо большую выгоду от упрощения внедрения UX, чем традиционные игроки от возможности предлагать функции AA своей существующей аудитории.
Другими словами, он «высвобождает» власть кошельков АА над всем адресным рынком, а не только над первыми пользователями, желающими переместить свои средства на новый адрес.
Благодаря MetaMask Snaps многие компании AA перейдут к построению AA на MetaMask, который представляет собой позиционирование мозга галактики, появление которого никто, кроме самых проницательных наблюдателей, не предвидел.
Является ли пакетирование само по себе небезопасным?
Точно нет. Вы все равно видите, что подписываете. В сочетании с моделированием транзакций это означает, что подписание нескольких действий так же безопасно, а в большинстве практических случаев безопаснее, чем подписание одного действия.
Пакетная обработка транзакций — одна из самых популярных функций Account Abstraction.
Помогает ли это децентрализованным приложениям внедрить AA? Решает ли это проблемы совместимости?
dApps работают с любой формой абстракции учетной записи, за некоторыми исключениями:
Некоторые децентрализованные приложения дискриминируют смарт-аккаунты (контрактные)
Некоторые dApps не поддерживают ERC-1271.
EIP-3074 волшебным образом решает обе проблемы: учетные записи отображаются как EOA (у них нет кода), поэтому их невозможно дискриминировать. Что касается подписей, EOA с поддержкой AA (через 3074) по-прежнему будут подписываться как EOA, поэтому драмы нет. Он будет волшебным образом работать со всеми децентрализованными приложениями за счет потери ротации ключей.
Однако, если большинство людей выбирают EOA с поддержкой AA вместо чистых смарт-аккаунтов, это лишает децентрализованные приложения поддержки ERC-1271 и ERC-6492, но ERC-4337 уже помог повысить осведомленность о предложениях по подписям.
А как насчет отзыва исходного ключа?
Вы можете отозвать ключ через EIP-5003 (который пока не запланирован в хард-форке).
Один из нюансов заключается в том, что это не идеальное решение в мире кроссчейнов. EOA всегда будет начинаться как EOA в каждой новой цепочке, которую вы начинаете использовать, а это означает, что исходный ключ никогда не может быть по-настоящему отозван. Но это применимо к каждой форме AA, поскольку исходные разрешения/привилегии, с которыми вы создали учетную запись, всегда совпадают с тем, с чего учетная запись начинается в любой новой сети.
EIP-3074 лучше работает, обеспечивая все функции AA, за исключением ротации ключей, в существующих EOA. Другими словами, если вы решите включить AA для EOA, вы навсегда застрянете с исходным закрытым ключом, стоящим за этим EOA.
Убивает ли он родной АА (RIP-7560)?
Нет, потому что вам все равно нужно решение для инициации транзакции, по крайней мере, если вы хотите платить газ токеном, отличным от собственного (или вам нужно спонсорство газа).
ERC-4337 — одно из таких решений, которое не требует обновлений протокола (оно не является родным), но встроенное AA, закрепленное в протоколе, чрезвычайно ценно, поскольку оно устраняет накладные расходы на газ и сложность ERC-4337.
Но сэр, а как насчет EIP-7377?
EIP-7377 позволяет преобразовать EOA в смарт-аккаунт. Вместо того, чтобы позволить смарт-контракту контролировать EOA наряду с исходным PK, этот EIP позволяет контракту взять на себя управление EOA за одну транзакцию.
Его можно считать альтернативой EIP-3074 + EIP-5003, но он не набрал таких больших оборотов.
Заключительные мысли
EIP-3074 — это не пластырь. Это чрезвычайно оптимистично для будущего Ethereum и экосистемы EVM, поскольку предложение пользователям внезапно покинуть свои существующие учетные записи и перевести все свои средства, позиции по ставкам и т. д. на новую учетную запись (учетную запись смарт-контракта) значительно повышает барьер для входа.
EIP-3074 обеспечит новую золотую середину и постепенную адаптацию, а это именно то, что нам нужно для значительного улучшения UX.
Вас интересует Амбир? Подписывайтесь на нас:
Раздор | Х (Твиттер) | Реддит | Гитхаб | Телеграмма | Фейсбук
