Автор：Bing Ventures

Введение: Стандарт EIP-4337 стандартизировал кошельки смарт-контрактов и связанную с ними инфраструктуру, создав общий стандарт. В плане улучшения пользовательского опыта, кошельки с абстракцией аккаунтов предлагают более гибкие и программируемые функции, вводя высокоуровневые псевдопроцессы и пошаговую обработку. Это позволяет обновлять кошельки без изменения основного протокола Ethereum и предоставляет больше возможностей для настройки. В целом, решение по абстракции аккаунтов Ethereum имеет больший потенциал в плане пользовательского опыта и расширения функциональности, но в области безопасности все еще требует постоянного улучшения.

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

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

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

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

Логика безопасности кошельков с абстракцией аккаунтов

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

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

• Логика проверки: Кошельки с абстракцией аккаунтов обеспечивают законность и безопасность действий пользователей через логику проверки (например, алгоритмы сравнения подписей и nonces).
• Контроль точек входа: Для защиты кошельков от атак, кошельки с абстракцией аккаунтов помещают сложные приемы смарт-контрактов в контракты точек входа и ограничивают возможность инициировать операции и оплату сборов только доверенными точками входа.
• Независимый уровень проверки и выполнения: Проверка и выполнение в кошельках с абстракцией аккаунтов разделены на две функции, которые обрабатывают шаги проверки и выполнения действий пользователей, тем самым повышая безопасность и гибкость.
• Симуляция выполнения и проверки: Проверка действий пользователей может быть выполнена через симуляцию, чтобы проверить их законность, гарантируя, что они будут иметь тот же эффект при фактическом добавлении в блок, тем самым предотвращая потенциальные атаки DoS.

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

Безопасные риски абстрактных кошельков

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

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

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

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

Баланс между пользовательским опытом и безопасностью

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

1. Управление приватными ключами: Кошельки с абстракцией аккаунтов должны безопасно управлять приватными ключами пользователей, чтобы защитить активы пользователей от потенциальных атак. Это можно реализовать с помощью таких мер безопасности, как использование алгоритмов шифрования, аппаратных кошельков и многофакторной аутентификации. Однако слишком строгие меры безопасности могут привести к ухудшению пользовательского опыта, например, требуя частых шагов аутентификации. В этом отношении кошельки должны найти баланс, чтобы обеспечить безопасность приватных ключей, одновременно предоставляя удобные способы аутентификации, позволяя пользователям легко получать доступ к своим активам.
2. Подтверждение и скорость транзакций: Кошельки с абстракцией аккаунтов должны предоставлять своевременное подтверждение транзакций и быстрое их обработку, чтобы обеспечить хороший пользовательский опыт. Однако при обеспечении скорости транзакций необходимо также обращать внимание на предотвращение двойных расходов и других мошеннических действий. Кошельки могут использовать технические меры, такие как транзакции с нулевым подтверждением и автоматическую оценку рисков с помощью ИИ, чтобы сбалансировать безопасность и скорость транзакций, гарантируя безопасность активов пользователей и предоставляя быстрый опыт транзакций.
3. Поддержка нескольких цепочек: Текущая тенденция заключается в развитии мультицепочности. При рассмотрении возможности использования абстракции аккаунтов необходимо учитывать уровень принятия AA в различных экосистемах и возможные различия, которые могут создать неопределенность для реализации AA на различных цепочках и виртуальных машинах. Если вы являетесь разработчиком приложений и рассматриваете возможность использования AA, вам необходимо учитывать объем работы, необходимый для обеспечения взаимной совместимости между несколькими цепочками. В будущем кошельки с абстракцией аккаунтов должны поддерживать несколько блокчейнов, чтобы удовлетворить потребности пользователей на различных цепочках. Однако каждый блокчейн имеет свои уникальные характеристики безопасности и требования к пользовательскому опыту. При балансировке безопасности и пользовательского опыта кошельки должны обеспечить соответствие требованиям безопасности для каждой цепочки, одновременно предоставляя согласованный и интуитивно понятный пользовательский интерфейс, чтобы пользователи могли легко управлять и взаимодействовать с активами на различных цепочках.
4. Затраты: Затраты на транзакции в цепочке являются важным ограничивающим фактором для разработки приложений. Даже если предположить, что большинство транзакций будет происходить на втором уровне и сборы будут субсидироваться, масштабируемое развертывание и обновление могут все еще быть дорогими. В частности, обновление кошельков теперь требует обновления основных смарт-контрактов, что может привести к новым уязвимостям и высоким затратам.

Будущее схемы абстракции аккаунтов

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

В краткосрочной и среднесрочной перспективе кошельки с абстракцией аккаунтов, вводя общие конечные точки Bundler, Paymaster и Signature Aggregator без разрешений, создают открытый рынок, позволяя пользователям получать качественные услуги с минимальными затратами. Способность быстро и настраиваемо развертывать Bundler, Paymaster и Signature Aggregator станет испытанием для поставщиков инфраструктуры кошельков. Эти конкуренции будут способствовать инновациям, повышая безопасность и пользовательский опыт.

В то же время сторонние поставщики инфраструктуры (такие как Stackup) будут разрабатывать модульные Bundler и Paymaster, постепенно достигая безразрешительной модели. Кроме того, разработка инструментов для быстрого развертывания фронтенда становится актуальной, позволяя разработчикам сосредоточиться на разработке бизнес-логики, такой как создание стандартных библиотек разработки dApp, поддерживающих функции абстракции аккаунтов, упаковка таких функций, как создание кошельков с использованием аккаунтов социальных сетей Web2 и электронной почты, создание, подписание, отправка и прослушивание событий UserOperations, быстрое развертывание Paymaster и Signature Aggregator. Эти инструменты могут упростить процесс интеграции разработчиков с различными кошельками.

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