*Примечание редактора: Счета смарт-контрактов (SCA) набирают обороты и поддерживаются многими основными предпринимателями, включая Виталика, но все еще существует много проблем для внедрения SCA. Преимущество абстракции учетной записи (AA) заключается в использовании настройки кода, но ее несовместимость приводит к проблемам интеграции и привязки к поставщику. Модульная абстракция учетной записи направлена на создание модульной структуры для разработки кошельков, которые являются универсальными, безопасными и легко интегрируемыми. *
Руи, инвестор SevenX Ventures >, определил пять основных проблем при внедрении SCA — влияние на медвежий рынок, трудности миграции, проблемы с подписью, высокие затраты на газ и инженерные проблемы — и обсудил их подробнее. Кроме того, анализ архитектуры модульных учетных записей смарт-контрактов указывает на то, что модульная SCA — это лишь малая часть проблем внедрения.
Для реализации всего потенциала SCA необходимы решения уровня 2, обеспечивающие дополнительную поддержку протокольного уровня, надежную инфраструктуру сборщиков и одноранговые пулы памяти, более экономичный и жизнеспособный механизм подписи SCA, межцепочечную синхронизацию и управление SCA, а также разработку удобных интерфейсов.
Что будет дальше в будущем, когда текущие проблемы будут решены и все больше людей будут внедрять SCA? Руй также задает несколько интересных вопросов. BlockBeats скомпилировал оригинальный текст следующим образом:
Переход от счетов, принадлежащих внешним владельцам (EOA), к счетам смарт-контрактов (SCA) набирает обороты и уже поддерживается многими основными предпринимателями, включая Виталика. Несмотря на это, принятие SCA не было столь широко распространено, как у EOA. Ключевые вопросы включают в себя влияние медвежьего рынка, трудности перехода с EOA на SCA, проблемы с подписью, высокие цены на газ и, что наиболее важно, проблемы с развитием.
Наиболее существенным преимуществом Account Abstraction (AA) является возможность настройки функциональности с помощью кода. Однако отсутствие функциональной совместимости функций AA представляет собой серьезную проблему, поскольку эта фрагментация препятствует интеграции AA и усиливает привязку к поставщику. Кроме того, важной задачей является обеспечение безопасности при одновременной модернизации и компонуемости.
Появление модульной абстракции учетных записей — это ниша в тренде AA, инновационный подход, который отделяет смарт-счета от их пользовательских функций. Цель состояла в том, чтобы создать модульную структуру для разработки кошельков с множеством функций, безопасностью и бесшовной интеграцией. В будущем модульная абстракция учетной записи позволит создать бесплатный «магазин приложений» для учетных записей смарт-контрактов, что позволит кошелькам и децентрализованным приложениям сосредоточиться на улучшении пользовательского опыта, а не тратить слишком много усилий на создание функций.
Краткая абстракция счета (AA)
! [Углубленный взгляд на модульную архитектуру учетной записи смарт-контракта и проблемы] (https://cdn-img.panewslab.com//panews/2022/11/19/images/cfeb01517174c8ebba563b682c0e14f3.)
Традиционное EOA создает множество проблем для людей с блокчейном, таких как seed-фразы, плата за газ, кросс-чейн-операции и множественные транзакции.
Абстракция учетной записи использует учетные записи смарт-контрактов для обеспечения программируемой проверки и настройки. Это означает, что пользователи смогут одобрять серию транзакций одновременно, вместо того, чтобы подписывать и транслировать каждую транзакцию. Абстракция учетной записи также может обеспечить дополнительные функции, такие как улучшенный пользовательский интерфейс (например, абстракция газа и ключи сеанса), снижение затрат (например, массовые транзакции) и повышенная безопасность (например, социальное восстановление, мультиподпись). В настоящее время существует два способа абстрагирования счетов:
· Протокольный уровень: Некоторые протоколы изначально обеспечивают встроенную поддержку абстракции учетных записей, транзакции ZKSync используют один мемпул и поток транзакций для поддержки AA, как из EOA, так и из SCA следуют одному и тому же процессу, в то время как Starknet удалил EOA, все учетные записи являются SCA, и у них есть собственные кошельки смарт-контрактов, такие как Argent.
· Контрактный уровень: Для Ethereum и аналогичных L2 ERC4337 ввели отдельный мемпул для поддержки AA без изменения уровня консенсуса. Такие сайты, как Stackup, Alchemy, Etherspot, Biconomy, Candide и Plimico создают инфраструктуру сборщиков, в то время как такие компании, как Safe, Zerodev, Etherspot и Biconomy, создают сборщики и SDK.
Дилемма принятия SCA
Тема абстракции счетов (AA) обсуждается с 2015 года и в этом году получила дальнейшее развитие в ERC 4337. Тем не менее, количество развернутых учетных записей смарт-контрактов все еще далеко не так низко, как EOA.
! [Углубленный взгляд на модульную архитектуру учетной записи смарт-контракта и проблемы] (https://cdn-img.panewslab.com//panews/2022/11/19/images/fff642cc328a24e3ae879c612eede147.)
Давайте разберемся в этой дилемме:
Влияние медвежьего рынка
Несмотря на преимущества AA, такие как бесшовный вход в систему и абстракция газа, на нынешнем медвежьем рынке, где все пользователи являются образованными пользователями EOA, а новых пользователей не так много, у децентрализованных приложений и кошельков нет стимула внедрять SCA. Тем не менее, некоторые из ведущих децентрализованных приложений постепенно внедряют AA, такие как Cyberconnect, который всего за один месяц провел около 360 000 транзакций UserOps (AA), представив свою систему AA и решение без газа.
Миграционные препятствия
Для кошельков и приложений, которые уже накопили пользователей и активы, по-прежнему сложно безопасно и удобно переносить активы. Однако такая схема, как EIP-7377, позволяет EOA инициировать одноразовую транзакцию миграции.
Проблемы с подписью
Сам смарт-контракт не может подписывать сообщения, потому что у него нет закрытого ключа, как у EOA. Такие попытки, как ERC1271, делают это возможным, но подписание сообщений не работает до первой транзакции, что, в свою очередь, создает проблему для кошельков, развернутых с контрфактами. ERC-6492, предложенный Ambire, является обратно совместимым преемником ERC-1271 и может решить предыдущую проблему.
Стоимость газа
Более высокая стоимость развертывания, моделирования и выполнения SCA по сравнению со стандартным EOA также является препятствием для внедрения. Тем не менее, были проведены некоторые тесты, такие как отделение создания учетной записи от действий пользователя, устранение «соли», связанной с учетной записью, и многое другое.
Инженерные проблемы
Команда ERC-4337 создала репозиторий eth-infinitism, который предоставляет базовую реализацию для разработчиков. Однако по мере того, как разработчики переходят на более детализированные и специфические функции для различных сценариев использования, интеграция и декодирование сталкиваются с большим количеством проблем. В этой статье мы углубимся в инженерные проблемы.
! [Углубленный взгляд на модульную архитектуру учетной записи смарт-контракта и проблемы] (https://cdn-img.panewslab.com//panews/2022/11/19/images/0fc706c8c21d06d7639926adfd563a6d.)
Решайте инженерные задачи с помощью модульных учетных записей смарт-контрактов
Инженерные задачи можно разделить на три аспекта: фрагментация, безопасность и возможность модернизации.
· Фрагментация: Функции теперь могут быть включены различными способами, будь то через определенную SCA или через автономную систему плагинов. Каждая платформа и поставщик услуг следуют своим собственным стандартам, что побуждает разработчиков решать, какие платформы и поставщиков услуг поддерживать. Это может привести к потенциальной привязке к платформе (поставщику) или избыточной работе.
· Безопасность: Несмотря на то, что разделение учетных записей и функций дает преимущество гибкости, оно также может сделать проблемы безопасности более серьезными. Поскольку все функции могут быть рассмотрены вместе, отсутствие независимой оценки может увеличить риск уязвимостей учетной записи.
· Возможность обновления: по мере роста учетной записи важно сохранять возможность добавлять, заменять или удалять функции, и каждое обновление, которое повторно развертывает существующие функции, создает сложности.
Чтобы решить эти проблемы, нам нужны обновляемые контракты для обеспечения безопасных и эффективных обновлений, повторно используемые ядра для повышения общей эффективности разработки и стандартизированные интерфейсы для обеспечения плавного перехода между различными интерфейсами.
Эти термины сходятся в общей концепции: построение модульной архитектуры абстракции учетной записи (Modular AA).
Модульная абстракция учетных записей является подразделом более широкой разработки AA, которая предусматривает модульность смарт-учетных записей для предоставления пользователям настраиваемых услуг и позволяет разработчикам беспрепятственно расширять функциональность с минимальными ограничениями.
Тем не менее, установление и продвижение новых стандартов в любой отрасли является огромной проблемой. До тех пор, пока все не примут один и тот же стандарт, на начальном этапе может появиться множество различных решений. Отрадно видеть, что те, кто работает над совершенствованием и продвижением абстракции учетных записей, будь то 4337 SDK, кошельки, команды инфраструктуры или разработчики протокольного уровня, работают вместе, чтобы ускорить этот процесс.
Модульная структура: мастер-счета и модули
Как учетная запись вызывает модуль для реализации функции
Делегирование вызова и прокси-контракта
Внешние и делегированные вызовы:
! [Углубленный взгляд на модульную архитектуру учетной записи смарт-контракта и проблемы] (https://cdn-img.panewslab.com//panews/2022/11/19/images/e159b7353f90ab70ee60852decc36c66.)
О вызовах делегирования
Несмотря на то, что «делегированный вызов» похож на «вызов», он выполняется не в контексте целевого контракта, а в контексте текущего состояния вызывающего контракта. Это означает, что любое изменение состояния, внесенное целевым контрактом, приведет к изменению хранилища вызывающего контракта.
! [Углубленный взгляд на модульную архитектуру учетной записи смарт-контракта и проблемы] (https://cdn-img.panewslab.com//panews/2022/11/19/images/42f728f5f9eae57483de2275c73ff732.)
Прокси-контракты и делегирующие вызовы
** Для достижения компонуемой и обновляемой структуры необходимо ввести базовую концепцию «агентского контракта». **
Прокси-контракт: обычный контракт хранит свою логику и состояние и не может быть обновлен после развертывания. Прокси-контракт развертывается в другом контракте с помощью вызова делегата. Реализуйте функцию по ссылке, чтобы выполнить ее в текущем состоянии прокси-контракта.
Сценарий использования: Пока прокси-контракт остается прежним, вы можете развернуть новую реализацию позади брокера. Прокси-контракты можно модернизировать, и они дешевле развертываются и поддерживаются в публичных блокчейнах.
Безопасная архитектура! [Углубленный взгляд на модульную архитектуру учетной записи смарт-контракта и проблемы] (https://cdn-img.panewslab.com//panews/2022/11/19/images/3177ae524aea7f850521a6340de396b3.)
Безопасная архитектура
Что такое безопасность: Safe — это ведущая модульная инфраструктура смарт-счетов, разработанная для обеспечения проверенной в боях безопасности и гибкости, и она позволяет разработчикам создавать различные приложения и кошельки. Многие команды создают приложения на основе Safe (или вдохновляются им). Например, Biconomy расширила Safe с помощью нативной 4337 и мультиподписи 1/1, когда запустила свою учетную запись смарт-контракта. Став свидетелем развертывания более 164 000 контрактов и зафиксировав стоимость более 30,7 миллиарда долларов, Safe, несомненно, является лидером в своей области.
Структура Safe включает в себя контракт безопасной учетной записи, одноэлементный контракт и модульный контракт.
Прокси-контракт: Stateful
Защищенная учетная запись является прокси-контрактом, так как делегированный вызов является одноэлементным контрактом. Учетная запись безопасности содержит переменные, в которых владелец, пороговое значение и адрес реализации задаются в качестве агентов, и их состояние определяется на их основе.
单例合约(singleton contract):Integration Hub(无状态)
Одноэлементный контракт обслуживает учетные записи Safe и определяет различные интеграции контрактов модулей, включая Plugin, Hook, Function Handler и Signature Validator.
Модули: Пользовательская логика и функциональность
Контракты модулей — это мощное средство. Плагины как модульные типы могут определять различные функции, такие как потоки платежей, механизмы восстановления и ключи сеанса, и могут выступать в качестве моста между Web2 и Web3, получая данные вне сети. Другие модули, такие как Hooks и Function Handlers в качестве охранников, могут реагировать на любую команду.
Изменения, которые произошли с момента внедрения Safe:
Обновляемые контракты: Всякий раз, когда вводится новый плагин, необходимо развернуть новый синглтон. Пользователь сохраняет автономию для обновления Safe до желаемой одноэлементной версии.
Компонуемые, многократно используемые модули: модульная природа плагинов позволяет разработчикам разрабатывать функции независимо друг от друга. Они могут свободно выбирать и комбинировать эти плагины в соответствии с их вариантом использования, что приводит к высоконастраиваемому подходу.
ERC-2535 Алмаз 代理
**! [Углубленный взгляд на модульную архитектуру учетной записи смарт-контракта и проблемы] (https://cdn-img.panewslab.com//panews/2022/11/19/images/c0483cb50c5a8f4f0b2b4c7c68ac1555.) **
О ERC2535, Diamond Agent:
ERC2535 стандартизированная модель Diamond, модульная система смарт-контрактов, которая может быть обновлена/масштабирована после развертывания практически без ограничений по размеру. В настоящее время многие команды, такие как Kernel от Zerodev и эксперименты Soul Wallet, были вдохновлены структурой Diamond.
Что такое ромбовидная структура:**
Контракт Diamond: Первичный прокси-контракт (с отслеживанием состояния) Diamond — это прокси-контракт, который использует делегированный метод вызова для вызова функции из своей реализации.
Контракт модуля/плагина/фасета: пользовательская логика и функциональность (без сохранения состояния) Модуль или так называемый фасет — это контракт без сохранения состояния, который может развернуть свою функциональность на одном или нескольких Алмазах. Это отдельные, независимые контракты, которые могут совместно использовать встроенные функции, библиотеки и переменные состояния.
Изменения с Diamond:
Обновляемые контракты: Diamond предоставляет систематический способ изолировать различные плагины и соединять их вместе, обмениваться данными между ними, а также добавлять/заменять/удалять любые плагины непосредственно с помощью функции diamondCut. Со временем количество плагинов, которые можно добавить в Diamond, не будет ограничено.
Модульные и многократно используемые плагины: развернутые плагины могут использоваться любым количеством Diamond, что значительно снижает затраты на развертывание.
Разница между Безопасным смарт-счетом и Бриллиантовым методом:
Существует много общего между архитектурами Safe и Diamond, обе из которых полагаются на свои основные прокси-контракты и ссылаются на логические контракты для возможности обновления и модульности.
Основное различие между ними заключается в работе с логическими контрактами. Конкретно:
· Гибкость: При включенном новом подключаемом модуле Safe необходимо повторно развернуть свой одноэлементный контракт для внесения изменений в свой прокси-сервер. В отличие от этого, Diamond достигает этого непосредственно с помощью функции diamondCut в своем прокси-контракте. Разница в подходе означает, что Safe сохраняет более высокую степень контроля, в то время как Diamond обеспечивает повышенную гибкость и модульность.
· Безопасность: В настоящее время используется в обеих структурах и позволяет внешнему коду манипулировать хранилищем основного контракта. В архитектуре Safe вызовы делегатов указывают на один логический контракт, в то время как Diamond использует вызовы делегатов для нескольких контрактов-плагинов модулей. В результате вредоносный плагин может перезаписать другой плагин, что приведет к возникновению конфликтов хранилища и нарушению целостности прокси-сервера.
· Стоимость: В подходе Diamond гибкость и безопасность сочетаются друг с другом. Это увеличивает стоимость, и каждый раз, когда добавляется новый плагин, его нужно полностью проверять. Ключ в том, чтобы гарантировать, что эти плагины не мешают функциональности друг друга, что является сложной задачей, особенно для малого и среднего бизнеса, пытающегося поддерживать высокие стандарты безопасности.
«Метод безопасного смарт-счета» и «Алмазный метод» являются примерами различных структур с участием агентов и модулей. Баланс между гибкостью и безопасностью имеет решающее значение, и эти два подхода будут продолжать развиваться и дополнять друг друга в будущем.
Порядок модулей: валидатор, исполнитель и хук
Давайте обсудим это подробнее, представив ERC6900, вдохновленный алмазами стандарт от команды Alchemy, который разработан специально для ERC-4337. Он решает проблемы модульности смарт-аккаунта, предоставляя общий интерфейс и координируя работу между разработчиками плагинов и кошельков.
Когда дело доходит до транзакционного процесса AA, существует три основных процесса: проверка, исполнение и привязка. Как мы обсуждали ранее, всеми этими шагами можно управлять с помощью модуля вызова прокси-аккаунта. Несмотря на то, что разные проекты могут использовать разные имена, важно понимать логику, лежащую в основе сходства.
! [Углубленный взгляд на модульную архитектуру учетной записи смарт-контракта и проблемы] (https://cdn-img.panewslab.com//panews/2022/11/19/images/ed0b816a1a752530a4aa2aa262621ff2.)
Название функции в разных дизайнах
Валидатор (Validator): Обеспечивает подлинность и разрешения вызывающего пользователя.
Выполнение (UTOR): выполнение любой пользовательской логики, разрешенной учетной записью.
Хук: Действует как модуль, который выполняется до или после другой функции. Он может изменить состояние или отменить весь вызов.
! [Углубленный взгляд на модульную архитектуру учетной записи смарт-контракта и проблемы] (https://cdn-img.panewslab.com//panews/2022/11/19/images/8cdb23a9a8107d700578098b858c7b14.)
Важно разделять модули по разной логике. Стандартизированный подход должен определять, как писать функции валидации, исполнения и привязки для учетных записей смарт-контрактов. Независимо от того, является ли это безопасным или ERC6900, стандартизация помогает снизить потребность в уникальных усилиях по разработке, специфичных для определенных реализаций или экосистем, и предотвращает привязку к поставщику.
Обнаружение и безопасность модулей
Как найти и проверить модули открытым способом: Одно из разрабатываемых решений включает в себя создание области, позволяющей пользователям обнаруживать проверяемые модули, которую можно назвать «реестром». Реестр функционирует как «магазин приложений» и направлен на создание упрощенного, но процветающего модульного рынка.
Safe{Core} 协议
! [Углубленный взгляд на модульную архитектуру учетной записи смарт-контракта и проблемы] (https://cdn-img.panewslab.com//panews/2022/11/19/images/2e9819139d78fbe550e17426902f4b17.)
Протокол Safe{Core} — это совместимый протокол с открытым исходным кодом для учетных записей смарт-контрактов, предназначенный для повышения доступности для широкого круга поставщиков и разработчиков, сохраняя при этом надежную безопасность с помощью четко определенных стандартов и правил.
· Учетные записи: В протоколе Safe{Core} концепция учетных записей является гибкой и не привязана к конкретной реализации. Это позволяет различным поставщикам услуг по работе с учетными записями принимать участие.
· Менеджер: Менеджер выступает в качестве координатора между учетными записями, реестрами и модулями. Он также заботится о безопасности в качестве уровня лицензирования.
· Реестр: реестр определяет атрибуты безопасности и применяет стандарты модулей, такие как ERC6900, для создания открытой среды «магазина приложений» для возможности обнаружения и безопасности.
· Модули: Модули обрабатывают функциональность и имеют различные начальные типы, включая плагины, хуки, валидаторы подписей и обработчики функций. Разработчики могут участвовать в проекте, если они соответствуют установленным критериям.
Горный хрусталь 设计
! [Углубленный взгляд на модульную архитектуру учетной записи смарт-контракта и проблемы] (https://cdn-img.panewslab.com//panews/2022/11/19/images/78f078ff37d8aa0c84a7f2d8508fbf8f.)
Процесс разворачивается следующим образом:
· Создание схемы: Схема предоставляет предопределенную структуру данных. Люди могут адаптировать его в соответствии со своим конкретным вариантом использования.
· Создание модулей на основе схемы: смарт-контракт, зарегистрированный как модуль, получает байт-код и выбирает идентификатор схемы, а данные сохраняются в реестре.
· Получить аттестацию модуля: Проверяющий/аудитор может предоставить доказательство модуля на основе архитектуры. Эти подтверждения могут включать уникальный идентификатор (UID) и ссылки на другие подтверждения, используемые для ссылки. Они могут распространяться по цепочкам и проверять, соответствует ли целевая цепочка определенным пороговым значениям.
· Реализуйте сложную логику с помощью сопоставителя: в игру вступает синтаксический анализатор (необязательно). Они могут быть вызваны во время создания модуля, установления аттестации и отзыва. Эти синтаксические анализаторы позволяют разработчикам интегрировать сложную и разнообразную логику, сохраняя при этом структуры доказательств.
Удобный доступ к запросам: Query предоставляет пользователям способ доступа к информации о безопасности из клиентской части.
Несмотря на то, что модель все еще находится на ранних стадиях, у нее есть потенциал для установления стандартов децентрализованным и совместным способом. Реестр позволяет разработчикам регистрировать свои модули, аудиторам — проверять их безопасность, кошельки — интегрировать, а пользователям — легко находить модули и проверять информацию об их аттестации. Возможны следующие варианты использования в будущем:
· Аттестатор: Доверенная организация, такая как Safe, может работать со Rhinestone в качестве проверки внутренних модулей. В то же время могут присоединиться и независимые сертифицирующие организации.
· Разработчик модулей: С формированием открытого маркетплейса у разработчиков модулей появилась возможность монетизировать свою работу через реестр.
· Пользователи: Участие через удобный интерфейс, такой как кошелек или dApp, позволяет пользователям проверять информацию о модуле и делегировать доверие различным проверщикам.
Концепция «реестра модулей» открывает разработчикам плагинов и модулей способы монетизации. Это может еще больше проложить путь к «рынку модулей». Некоторые аспекты могут контролироваться командой Safe, в то время как другие могут проявляться в виде децентрализованного рынка, который приглашает всех внести свой вклад и обеспечивает прозрачный аудиторский след. Это позволяет избежать привязки к поставщику и поддерживает расширение EVM за счет добавления улучшенного пользовательского интерфейса, привлекательного для более широкой аудитории.
В то время как эти методы гарантируют безопасность отдельных модулей, учетные записи смарт-контрактов не являются надежными, когда дело доходит до более широкой безопасности. Может быть непросто объединить с модулями соответствия и доказать, что у них нет конфликтов хранилища, что подчеркивает важность кошельков или инфраструктуры AA в решении таких проблем.
Резюме
Используя модульный стек учетных записей смарт-контрактов, поставщики кошельков и децентрализованные приложения могут быть освобождены от сложностей технического обслуживания. При этом внешние разработчики модулей имеют возможность предоставлять персонализированные профессиональные услуги. Тем не менее, проблемы, которые необходимо решить, включают в себя поиск баланса между гибкостью и безопасностью, продвижение модульных стандартов и внедрение стандартизированных интерфейсов, которые позволяют пользователям легко обновлять и изменять свои смарт-учетные записи.
Кроме того, модульные счета смарт-контрактов (SCA) — это лишь малая часть головоломки внедрения. Для реализации всего потенциала SCA необходимы решения уровня 2, обеспечивающие дополнительную поддержку протокольного уровня, такую как надежная инфраструктура сборщика и одноранговые пулы памяти, более экономичный и жизнеспособный механизм подписи SCA, механизмы межсетевой синхронизации и управления SCA, а также разработка удобных интерфейсов.
В будущем SCA будет более активно внедряться, но это также вызовет некоторые интересные вопросы: как традиционные механизмы извлекаемой ценности (MEV) майнеров войдут в пространство для создания бандлеров и получения ценности, когда поток заказов SCA станет достаточно прибыльным, и как абстракция счета (AA) будет служить базовым уровнем для транзакций на основе намерений, когда инфраструктура созреет?
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Углубленный взгляд на модульные архитектуры учетных записей смарт-контрактов и проблемы
作者:Руи, инвестор SevenX Ventures
编译:Luccy,Joyce,BlockBeats
Руи, инвестор SevenX Ventures >, определил пять основных проблем при внедрении SCA — влияние на медвежий рынок, трудности миграции, проблемы с подписью, высокие затраты на газ и инженерные проблемы — и обсудил их подробнее. Кроме того, анализ архитектуры модульных учетных записей смарт-контрактов указывает на то, что модульная SCA — это лишь малая часть проблем внедрения.
Переход от счетов, принадлежащих внешним владельцам (EOA), к счетам смарт-контрактов (SCA) набирает обороты и уже поддерживается многими основными предпринимателями, включая Виталика. Несмотря на это, принятие SCA не было столь широко распространено, как у EOA. Ключевые вопросы включают в себя влияние медвежьего рынка, трудности перехода с EOA на SCA, проблемы с подписью, высокие цены на газ и, что наиболее важно, проблемы с развитием.
Наиболее существенным преимуществом Account Abstraction (AA) является возможность настройки функциональности с помощью кода. Однако отсутствие функциональной совместимости функций AA представляет собой серьезную проблему, поскольку эта фрагментация препятствует интеграции AA и усиливает привязку к поставщику. Кроме того, важной задачей является обеспечение безопасности при одновременной модернизации и компонуемости.
Появление модульной абстракции учетных записей — это ниша в тренде AA, инновационный подход, который отделяет смарт-счета от их пользовательских функций. Цель состояла в том, чтобы создать модульную структуру для разработки кошельков с множеством функций, безопасностью и бесшовной интеграцией. В будущем модульная абстракция учетной записи позволит создать бесплатный «магазин приложений» для учетных записей смарт-контрактов, что позволит кошелькам и децентрализованным приложениям сосредоточиться на улучшении пользовательского опыта, а не тратить слишком много усилий на создание функций.
Краткая абстракция счета (AA)
! [Углубленный взгляд на модульную архитектуру учетной записи смарт-контракта и проблемы] (https://cdn-img.panewslab.com//panews/2022/11/19/images/cfeb01517174c8ebba563b682c0e14f3.)
Традиционное EOA создает множество проблем для людей с блокчейном, таких как seed-фразы, плата за газ, кросс-чейн-операции и множественные транзакции.
Абстракция учетной записи использует учетные записи смарт-контрактов для обеспечения программируемой проверки и настройки. Это означает, что пользователи смогут одобрять серию транзакций одновременно, вместо того, чтобы подписывать и транслировать каждую транзакцию. Абстракция учетной записи также может обеспечить дополнительные функции, такие как улучшенный пользовательский интерфейс (например, абстракция газа и ключи сеанса), снижение затрат (например, массовые транзакции) и повышенная безопасность (например, социальное восстановление, мультиподпись). В настоящее время существует два способа абстрагирования счетов:
· Протокольный уровень: Некоторые протоколы изначально обеспечивают встроенную поддержку абстракции учетных записей, транзакции ZKSync используют один мемпул и поток транзакций для поддержки AA, как из EOA, так и из SCA следуют одному и тому же процессу, в то время как Starknet удалил EOA, все учетные записи являются SCA, и у них есть собственные кошельки смарт-контрактов, такие как Argent.
· Контрактный уровень: Для Ethereum и аналогичных L2 ERC4337 ввели отдельный мемпул для поддержки AA без изменения уровня консенсуса. Такие сайты, как Stackup, Alchemy, Etherspot, Biconomy, Candide и Plimico создают инфраструктуру сборщиков, в то время как такие компании, как Safe, Zerodev, Etherspot и Biconomy, создают сборщики и SDK.
Дилемма принятия SCA
Тема абстракции счетов (AA) обсуждается с 2015 года и в этом году получила дальнейшее развитие в ERC 4337. Тем не менее, количество развернутых учетных записей смарт-контрактов все еще далеко не так низко, как EOA.
! [Углубленный взгляд на модульную архитектуру учетной записи смарт-контракта и проблемы] (https://cdn-img.panewslab.com//panews/2022/11/19/images/fff642cc328a24e3ae879c612eede147.)
Давайте разберемся в этой дилемме:
Несмотря на преимущества AA, такие как бесшовный вход в систему и абстракция газа, на нынешнем медвежьем рынке, где все пользователи являются образованными пользователями EOA, а новых пользователей не так много, у децентрализованных приложений и кошельков нет стимула внедрять SCA. Тем не менее, некоторые из ведущих децентрализованных приложений постепенно внедряют AA, такие как Cyberconnect, который всего за один месяц провел около 360 000 транзакций UserOps (AA), представив свою систему AA и решение без газа.
Для кошельков и приложений, которые уже накопили пользователей и активы, по-прежнему сложно безопасно и удобно переносить активы. Однако такая схема, как EIP-7377, позволяет EOA инициировать одноразовую транзакцию миграции.
Сам смарт-контракт не может подписывать сообщения, потому что у него нет закрытого ключа, как у EOA. Такие попытки, как ERC1271, делают это возможным, но подписание сообщений не работает до первой транзакции, что, в свою очередь, создает проблему для кошельков, развернутых с контрфактами. ERC-6492, предложенный Ambire, является обратно совместимым преемником ERC-1271 и может решить предыдущую проблему.
Более высокая стоимость развертывания, моделирования и выполнения SCA по сравнению со стандартным EOA также является препятствием для внедрения. Тем не менее, были проведены некоторые тесты, такие как отделение создания учетной записи от действий пользователя, устранение «соли», связанной с учетной записью, и многое другое.
Команда ERC-4337 создала репозиторий eth-infinitism, который предоставляет базовую реализацию для разработчиков. Однако по мере того, как разработчики переходят на более детализированные и специфические функции для различных сценариев использования, интеграция и декодирование сталкиваются с большим количеством проблем. В этой статье мы углубимся в инженерные проблемы.
! [Углубленный взгляд на модульную архитектуру учетной записи смарт-контракта и проблемы] (https://cdn-img.panewslab.com//panews/2022/11/19/images/0fc706c8c21d06d7639926adfd563a6d.)
Решайте инженерные задачи с помощью модульных учетных записей смарт-контрактов
Инженерные задачи можно разделить на три аспекта: фрагментация, безопасность и возможность модернизации.
· Фрагментация: Функции теперь могут быть включены различными способами, будь то через определенную SCA или через автономную систему плагинов. Каждая платформа и поставщик услуг следуют своим собственным стандартам, что побуждает разработчиков решать, какие платформы и поставщиков услуг поддерживать. Это может привести к потенциальной привязке к платформе (поставщику) или избыточной работе.
· Безопасность: Несмотря на то, что разделение учетных записей и функций дает преимущество гибкости, оно также может сделать проблемы безопасности более серьезными. Поскольку все функции могут быть рассмотрены вместе, отсутствие независимой оценки может увеличить риск уязвимостей учетной записи.
· Возможность обновления: по мере роста учетной записи важно сохранять возможность добавлять, заменять или удалять функции, и каждое обновление, которое повторно развертывает существующие функции, создает сложности.
Чтобы решить эти проблемы, нам нужны обновляемые контракты для обеспечения безопасных и эффективных обновлений, повторно используемые ядра для повышения общей эффективности разработки и стандартизированные интерфейсы для обеспечения плавного перехода между различными интерфейсами.
Эти термины сходятся в общей концепции: построение модульной архитектуры абстракции учетной записи (Modular AA).
Модульная абстракция учетных записей является подразделом более широкой разработки AA, которая предусматривает модульность смарт-учетных записей для предоставления пользователям настраиваемых услуг и позволяет разработчикам беспрепятственно расширять функциональность с минимальными ограничениями.
Тем не менее, установление и продвижение новых стандартов в любой отрасли является огромной проблемой. До тех пор, пока все не примут один и тот же стандарт, на начальном этапе может появиться множество различных решений. Отрадно видеть, что те, кто работает над совершенствованием и продвижением абстракции учетных записей, будь то 4337 SDK, кошельки, команды инфраструктуры или разработчики протокольного уровня, работают вместе, чтобы ускорить этот процесс.
Модульная структура: мастер-счета и модули
Как учетная запись вызывает модуль для реализации функции
Делегирование вызова и прокси-контракта
Внешние и делегированные вызовы:
! [Углубленный взгляд на модульную архитектуру учетной записи смарт-контракта и проблемы] (https://cdn-img.panewslab.com//panews/2022/11/19/images/e159b7353f90ab70ee60852decc36c66.)
О вызовах делегирования
Несмотря на то, что «делегированный вызов» похож на «вызов», он выполняется не в контексте целевого контракта, а в контексте текущего состояния вызывающего контракта. Это означает, что любое изменение состояния, внесенное целевым контрактом, приведет к изменению хранилища вызывающего контракта.
! [Углубленный взгляд на модульную архитектуру учетной записи смарт-контракта и проблемы] (https://cdn-img.panewslab.com//panews/2022/11/19/images/42f728f5f9eae57483de2275c73ff732.)
Прокси-контракты и делегирующие вызовы
** Для достижения компонуемой и обновляемой структуры необходимо ввести базовую концепцию «агентского контракта». **
Прокси-контракт: обычный контракт хранит свою логику и состояние и не может быть обновлен после развертывания. Прокси-контракт развертывается в другом контракте с помощью вызова делегата. Реализуйте функцию по ссылке, чтобы выполнить ее в текущем состоянии прокси-контракта.
Сценарий использования: Пока прокси-контракт остается прежним, вы можете развернуть новую реализацию позади брокера. Прокси-контракты можно модернизировать, и они дешевле развертываются и поддерживаются в публичных блокчейнах.
Безопасная архитектура! [Углубленный взгляд на модульную архитектуру учетной записи смарт-контракта и проблемы] (https://cdn-img.panewslab.com//panews/2022/11/19/images/3177ae524aea7f850521a6340de396b3.)
Безопасная архитектура
Что такое безопасность: Safe — это ведущая модульная инфраструктура смарт-счетов, разработанная для обеспечения проверенной в боях безопасности и гибкости, и она позволяет разработчикам создавать различные приложения и кошельки. Многие команды создают приложения на основе Safe (или вдохновляются им). Например, Biconomy расширила Safe с помощью нативной 4337 и мультиподписи 1/1, когда запустила свою учетную запись смарт-контракта. Став свидетелем развертывания более 164 000 контрактов и зафиксировав стоимость более 30,7 миллиарда долларов, Safe, несомненно, является лидером в своей области.
Структура Safe включает в себя контракт безопасной учетной записи, одноэлементный контракт и модульный контракт.
Прокси-контракт: Stateful
Защищенная учетная запись является прокси-контрактом, так как делегированный вызов является одноэлементным контрактом. Учетная запись безопасности содержит переменные, в которых владелец, пороговое значение и адрес реализации задаются в качестве агентов, и их состояние определяется на их основе.
单例合约(singleton contract):Integration Hub(无状态)
Одноэлементный контракт обслуживает учетные записи Safe и определяет различные интеграции контрактов модулей, включая Plugin, Hook, Function Handler и Signature Validator.
Модули: Пользовательская логика и функциональность
Контракты модулей — это мощное средство. Плагины как модульные типы могут определять различные функции, такие как потоки платежей, механизмы восстановления и ключи сеанса, и могут выступать в качестве моста между Web2 и Web3, получая данные вне сети. Другие модули, такие как Hooks и Function Handlers в качестве охранников, могут реагировать на любую команду.
Изменения, которые произошли с момента внедрения Safe:
Обновляемые контракты: Всякий раз, когда вводится новый плагин, необходимо развернуть новый синглтон. Пользователь сохраняет автономию для обновления Safe до желаемой одноэлементной версии.
Компонуемые, многократно используемые модули: модульная природа плагинов позволяет разработчикам разрабатывать функции независимо друг от друга. Они могут свободно выбирать и комбинировать эти плагины в соответствии с их вариантом использования, что приводит к высоконастраиваемому подходу.
ERC-2535 Алмаз 代理
**! [Углубленный взгляд на модульную архитектуру учетной записи смарт-контракта и проблемы] (https://cdn-img.panewslab.com//panews/2022/11/19/images/c0483cb50c5a8f4f0b2b4c7c68ac1555.) **
О ERC2535, Diamond Agent:
ERC2535 стандартизированная модель Diamond, модульная система смарт-контрактов, которая может быть обновлена/масштабирована после развертывания практически без ограничений по размеру. В настоящее время многие команды, такие как Kernel от Zerodev и эксперименты Soul Wallet, были вдохновлены структурой Diamond.
Что такое ромбовидная структура:**
Контракт Diamond: Первичный прокси-контракт (с отслеживанием состояния) Diamond — это прокси-контракт, который использует делегированный метод вызова для вызова функции из своей реализации.
Контракт модуля/плагина/фасета: пользовательская логика и функциональность (без сохранения состояния) Модуль или так называемый фасет — это контракт без сохранения состояния, который может развернуть свою функциональность на одном или нескольких Алмазах. Это отдельные, независимые контракты, которые могут совместно использовать встроенные функции, библиотеки и переменные состояния.
Изменения с Diamond:
Обновляемые контракты: Diamond предоставляет систематический способ изолировать различные плагины и соединять их вместе, обмениваться данными между ними, а также добавлять/заменять/удалять любые плагины непосредственно с помощью функции diamondCut. Со временем количество плагинов, которые можно добавить в Diamond, не будет ограничено.
Модульные и многократно используемые плагины: развернутые плагины могут использоваться любым количеством Diamond, что значительно снижает затраты на развертывание.
Разница между Безопасным смарт-счетом и Бриллиантовым методом:
Существует много общего между архитектурами Safe и Diamond, обе из которых полагаются на свои основные прокси-контракты и ссылаются на логические контракты для возможности обновления и модульности.
Основное различие между ними заключается в работе с логическими контрактами. Конкретно:
· Гибкость: При включенном новом подключаемом модуле Safe необходимо повторно развернуть свой одноэлементный контракт для внесения изменений в свой прокси-сервер. В отличие от этого, Diamond достигает этого непосредственно с помощью функции diamondCut в своем прокси-контракте. Разница в подходе означает, что Safe сохраняет более высокую степень контроля, в то время как Diamond обеспечивает повышенную гибкость и модульность.
· Безопасность: В настоящее время используется в обеих структурах и позволяет внешнему коду манипулировать хранилищем основного контракта. В архитектуре Safe вызовы делегатов указывают на один логический контракт, в то время как Diamond использует вызовы делегатов для нескольких контрактов-плагинов модулей. В результате вредоносный плагин может перезаписать другой плагин, что приведет к возникновению конфликтов хранилища и нарушению целостности прокси-сервера.
· Стоимость: В подходе Diamond гибкость и безопасность сочетаются друг с другом. Это увеличивает стоимость, и каждый раз, когда добавляется новый плагин, его нужно полностью проверять. Ключ в том, чтобы гарантировать, что эти плагины не мешают функциональности друг друга, что является сложной задачей, особенно для малого и среднего бизнеса, пытающегося поддерживать высокие стандарты безопасности.
«Метод безопасного смарт-счета» и «Алмазный метод» являются примерами различных структур с участием агентов и модулей. Баланс между гибкостью и безопасностью имеет решающее значение, и эти два подхода будут продолжать развиваться и дополнять друг друга в будущем.
Порядок модулей: валидатор, исполнитель и хук
Давайте обсудим это подробнее, представив ERC6900, вдохновленный алмазами стандарт от команды Alchemy, который разработан специально для ERC-4337. Он решает проблемы модульности смарт-аккаунта, предоставляя общий интерфейс и координируя работу между разработчиками плагинов и кошельков.
Когда дело доходит до транзакционного процесса AA, существует три основных процесса: проверка, исполнение и привязка. Как мы обсуждали ранее, всеми этими шагами можно управлять с помощью модуля вызова прокси-аккаунта. Несмотря на то, что разные проекты могут использовать разные имена, важно понимать логику, лежащую в основе сходства.
! [Углубленный взгляд на модульную архитектуру учетной записи смарт-контракта и проблемы] (https://cdn-img.panewslab.com//panews/2022/11/19/images/ed0b816a1a752530a4aa2aa262621ff2.)
Название функции в разных дизайнах
Валидатор (Validator): Обеспечивает подлинность и разрешения вызывающего пользователя.
Выполнение (UTOR): выполнение любой пользовательской логики, разрешенной учетной записью.
Хук: Действует как модуль, который выполняется до или после другой функции. Он может изменить состояние или отменить весь вызов.
! [Углубленный взгляд на модульную архитектуру учетной записи смарт-контракта и проблемы] (https://cdn-img.panewslab.com//panews/2022/11/19/images/8cdb23a9a8107d700578098b858c7b14.)
Важно разделять модули по разной логике. Стандартизированный подход должен определять, как писать функции валидации, исполнения и привязки для учетных записей смарт-контрактов. Независимо от того, является ли это безопасным или ERC6900, стандартизация помогает снизить потребность в уникальных усилиях по разработке, специфичных для определенных реализаций или экосистем, и предотвращает привязку к поставщику.
Обнаружение и безопасность модулей
Как найти и проверить модули открытым способом: Одно из разрабатываемых решений включает в себя создание области, позволяющей пользователям обнаруживать проверяемые модули, которую можно назвать «реестром». Реестр функционирует как «магазин приложений» и направлен на создание упрощенного, но процветающего модульного рынка.
Safe{Core} 协议
! [Углубленный взгляд на модульную архитектуру учетной записи смарт-контракта и проблемы] (https://cdn-img.panewslab.com//panews/2022/11/19/images/2e9819139d78fbe550e17426902f4b17.)
Протокол Safe{Core} — это совместимый протокол с открытым исходным кодом для учетных записей смарт-контрактов, предназначенный для повышения доступности для широкого круга поставщиков и разработчиков, сохраняя при этом надежную безопасность с помощью четко определенных стандартов и правил.
· Учетные записи: В протоколе Safe{Core} концепция учетных записей является гибкой и не привязана к конкретной реализации. Это позволяет различным поставщикам услуг по работе с учетными записями принимать участие.
· Менеджер: Менеджер выступает в качестве координатора между учетными записями, реестрами и модулями. Он также заботится о безопасности в качестве уровня лицензирования.
· Реестр: реестр определяет атрибуты безопасности и применяет стандарты модулей, такие как ERC6900, для создания открытой среды «магазина приложений» для возможности обнаружения и безопасности.
· Модули: Модули обрабатывают функциональность и имеют различные начальные типы, включая плагины, хуки, валидаторы подписей и обработчики функций. Разработчики могут участвовать в проекте, если они соответствуют установленным критериям.
Горный хрусталь 设计
! [Углубленный взгляд на модульную архитектуру учетной записи смарт-контракта и проблемы] (https://cdn-img.panewslab.com//panews/2022/11/19/images/78f078ff37d8aa0c84a7f2d8508fbf8f.)
Процесс разворачивается следующим образом:
· Создание схемы: Схема предоставляет предопределенную структуру данных. Люди могут адаптировать его в соответствии со своим конкретным вариантом использования.
· Создание модулей на основе схемы: смарт-контракт, зарегистрированный как модуль, получает байт-код и выбирает идентификатор схемы, а данные сохраняются в реестре.
· Получить аттестацию модуля: Проверяющий/аудитор может предоставить доказательство модуля на основе архитектуры. Эти подтверждения могут включать уникальный идентификатор (UID) и ссылки на другие подтверждения, используемые для ссылки. Они могут распространяться по цепочкам и проверять, соответствует ли целевая цепочка определенным пороговым значениям.
· Реализуйте сложную логику с помощью сопоставителя: в игру вступает синтаксический анализатор (необязательно). Они могут быть вызваны во время создания модуля, установления аттестации и отзыва. Эти синтаксические анализаторы позволяют разработчикам интегрировать сложную и разнообразную логику, сохраняя при этом структуры доказательств.
Удобный доступ к запросам: Query предоставляет пользователям способ доступа к информации о безопасности из клиентской части.
Несмотря на то, что модель все еще находится на ранних стадиях, у нее есть потенциал для установления стандартов децентрализованным и совместным способом. Реестр позволяет разработчикам регистрировать свои модули, аудиторам — проверять их безопасность, кошельки — интегрировать, а пользователям — легко находить модули и проверять информацию об их аттестации. Возможны следующие варианты использования в будущем:
· Аттестатор: Доверенная организация, такая как Safe, может работать со Rhinestone в качестве проверки внутренних модулей. В то же время могут присоединиться и независимые сертифицирующие организации.
· Разработчик модулей: С формированием открытого маркетплейса у разработчиков модулей появилась возможность монетизировать свою работу через реестр.
· Пользователи: Участие через удобный интерфейс, такой как кошелек или dApp, позволяет пользователям проверять информацию о модуле и делегировать доверие различным проверщикам.
Концепция «реестра модулей» открывает разработчикам плагинов и модулей способы монетизации. Это может еще больше проложить путь к «рынку модулей». Некоторые аспекты могут контролироваться командой Safe, в то время как другие могут проявляться в виде децентрализованного рынка, который приглашает всех внести свой вклад и обеспечивает прозрачный аудиторский след. Это позволяет избежать привязки к поставщику и поддерживает расширение EVM за счет добавления улучшенного пользовательского интерфейса, привлекательного для более широкой аудитории.
В то время как эти методы гарантируют безопасность отдельных модулей, учетные записи смарт-контрактов не являются надежными, когда дело доходит до более широкой безопасности. Может быть непросто объединить с модулями соответствия и доказать, что у них нет конфликтов хранилища, что подчеркивает важность кошельков или инфраструктуры AA в решении таких проблем.
Резюме
Используя модульный стек учетных записей смарт-контрактов, поставщики кошельков и децентрализованные приложения могут быть освобождены от сложностей технического обслуживания. При этом внешние разработчики модулей имеют возможность предоставлять персонализированные профессиональные услуги. Тем не менее, проблемы, которые необходимо решить, включают в себя поиск баланса между гибкостью и безопасностью, продвижение модульных стандартов и внедрение стандартизированных интерфейсов, которые позволяют пользователям легко обновлять и изменять свои смарт-учетные записи.
Кроме того, модульные счета смарт-контрактов (SCA) — это лишь малая часть головоломки внедрения. Для реализации всего потенциала SCA необходимы решения уровня 2, обеспечивающие дополнительную поддержку протокольного уровня, такую как надежная инфраструктура сборщика и одноранговые пулы памяти, более экономичный и жизнеспособный механизм подписи SCA, механизмы межсетевой синхронизации и управления SCA, а также разработка удобных интерфейсов.
В будущем SCA будет более активно внедряться, но это также вызовет некоторые интересные вопросы: как традиционные механизмы извлекаемой ценности (MEV) майнеров войдут в пространство для создания бандлеров и получения ценности, когда поток заказов SCA станет достаточно прибыльным, и как абстракция счета (AA) будет служить базовым уровнем для транзакций на основе намерений, когда инфраструктура созреет?