Углубленное обсуждение модульной конструкции учетной записи смарт-контракта: решение технических проблем при реализации

Автор: Руи С., SevenX Ventures; Составитель: Deep Wave TechFlow.

представлять

Переход от внешних учетных записей (EOA) к учетным записям смарт-контрактов (SCA) находится на подъеме и поддерживается многими энтузиастами, включая самого Виталика. Несмотря на ажиотаж, внедрение SCA не получило такого широкого распространения, как EOA. Ключевые проблемы включают проблемы медвежьего рынка, проблемы миграции, проблемы сигнатур, накладные расходы на газ и, что наиболее важно, инженерные проблемы.

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

Модульная абстракция учетных записей возникла как часть более широкого движения АА — инновационного подхода к отделению смарт-аккаунтов от их пользовательских функций. Цель — создать модульную структуру для разработки безопасных, легко интегрированных кошельков с разнообразными функциями. В будущем он может реализовать бесплатную учетную запись смарт-контракта «магазин приложений», чтобы кошельки и dApps больше не сосредотачивались на создании функций, а фокусировались на пользовательском опыте.

АА Краткое описание

Традиционный EOA создает множество проблем, таких как начальные фразы, газ, кроссчейн и множественные транзакции. Мы никогда не собирались привносить сложность, но реальность такова, что блокчейн — непростая игра для масс.

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

• Уровень протокола: некоторые протоколы сами по себе обеспечивают поддержку абстракции локальных учетных записей.Транзакции ZKsync, будь то из EOA или SCA, следуют одному и тому же процессу, используя один пул памяти и процесс транзакций для поддержки AA, в то время как Starknet удалил EOA и все учетные записи. Оба являются SCA. , и у них есть собственные кошельки для смарт-контрактов, такие как Argent.
• Уровень контракта: для Ethereum и его эквивалента L2 стандарт ERC 4337 вводит отдельную запись транзакции для поддержки AA без изменения уровня консенсуса. Такие проекты, как Stackup, Alchemy, Etherspot, Biconomy, Candide и Plimico, создают инфраструктуру сборщиков, а такие проекты, как Safe, Zerodev, Etherspot и Biconomy, создают стеки и SDK.

Дилеммы внедрения SCA

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

Давайте углубимся в эту дилемму:

• Влияние медвежьего рынка:

Хотя AA представил такие преимущества, как беспрепятственный вход в систему и абстракция Gas, люди, которые в настоящее время испытывают медвежий рынок, в основном состоят из образованных пользователей EOA, а не из новых пользователей, поэтому нет стимула для dApps и кошельков. Несмотря на это, некоторые ведущие приложения постепенно внедряют AA, например, Cyberconnect, которая выполнила около 360 000 UserOps (транзакций AA) всего за один месяц, представив свою систему AA и решение без газа.

• Барьеры для миграции:

Для кошельков и приложений, накопивших пользователей и активы, безопасная и удобная миграция активов остается проблемой. Однако такие инициативы, как EIP-7377, позволяют EOA инициировать одноразовые транзакции миграции.

*Проблема с подписью:

Сам смарт-контракт естественным образом не может подписывать сообщения, поскольку у него нет закрытого ключа, такого как EOA. Такие усилия, как ERC 1271, делают такую подпись возможной, но подпись сообщения не работает до первой транзакции, что создает проблему для кошельков, использующих контрфактические развертывания. ERC-6492, предложенный Ambire, является обратно совместимым преемником ERC-1271 и может решить предыдущие проблемы.

*Накладные расходы на газ:

Развертывание, моделирование и выполнение SCA требует более высоких затрат, чем стандартное EOA. Это становится препятствием для усыновления. Однако были проведены некоторые тесты, такие как отделение создания учетной записи от действий пользователя и рассмотрение возможности устранения солей учетных записей и проверок существования, чтобы снизить эти затраты.

• Инженерные проблемы:

Команда ERC-4337 создала репозиторий eth-infinitiism, чтобы предоставить разработчикам базовые реализации. Однако по мере того, как мы переходим к более детальным или конкретным функциональным возможностям в различных случаях использования, интеграция и декодирование становятся сложными.

В этой статье мы углубимся в пятый вопрос: инженерные проблемы.

Модульные смарт-контракты для решения инженерных задач

Дальнейшее объяснение инженерных проблем заключается в следующем:

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

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

Эти термины сходятся в общей концепции: построение модульной архитектуры абстракции учетных записей (Modular AA).

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

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

Модульная структура: основной аккаунт и модули

Делегирование вызова и прокси-контракт

Внешние вызовы и вызовы делегатов:

Хотя вызов делегата аналогичен вызову, вместо выполнения целевого контракта в его собственном контексте он выполняет целевой контракт в текущем состоянии вызывающего контракта. Это означает, что любые изменения состояния, внесенные целевым контрактом, будут применены к хранилищу вызывающего контракта.

Для реализации составных и обновляемых структур необходимы базовые знания, называемые «агентскими контрактами».

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

Архитектура безопасности

Safe — это ведущая модульная инфраструктура смарт-аккаунтов, предназначенная для обеспечения проверенной в боях безопасности и гибкости, позволяющая разработчикам создавать разнообразные приложения и кошельки. Стоит отметить, что многие команды используют Safe или вдохновляются им. Biconomy запускает свою учетную запись, расширяя встроенную мультиподпись 4337 и 1/1 в Safe. С более чем 164 000 развернутых контрактов и фиксированной стоимостью более 30,7 миллиардов долларов Safe, несомненно, является лучшим выбором в этой области.

Безопасная структура

• Контракт безопасного аккаунта: контракт основного агента (с сохранением состояния)

Учетная запись Safe является прокси-контрактом, поскольку она делегирует вызов одноэлементного контракта. Учетная запись Safe содержит владельца, пороговое значение и адрес реализации, которые устанавливаются как переменные для агента, тем самым определяя его состояние.

• Синглтон-контракт: интеграционный центр (без гражданства)

Синглтон обслуживает учетную запись Safe, интегрирует и определяет различные интеграции, включая плагины, перехватчики, обработчики функций и средства проверки подписи.

• Контракт модуля: пользовательская логика и функции.

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

Что произойдет, когда мы перейдём на Safe

• Обновляемые контракты:

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

• Сборные и многоразовые модули:

Модульная природа плагинов позволяет разработчикам самостоятельно создавать функциональность. Затем они могут свободно выбирать и комбинировать эти плагины в соответствии со своими сценариями использования, что обеспечивает широкие возможности настройки.

ERC-2535 Алмазный агент

О ERC 2535 и Diamond Agent

ERC 2535 стандартизирует Diamond Agent, модульную систему смарт-контрактов, которую можно обновлять/расширять после развертывания и которая практически не имеет ограничений по размеру. До сих пор многие команды были вдохновлены этим, например, эксперименты Zerodev Kernel и Soul Wallet.

Какова структура алмаза?

• Diamond Contract: Контракт главного агента (с состоянием). Diamond — это прокси-контракт, который вызывает функции из своей реализации посредством вызовов делегатов.
• Модули/плагины/фасетные контракты: пользовательская логика и функциональность (без сохранения состояния). Модуль или так называемый фасет — это контракт без сохранения состояния, который может развертывать свои функциональные возможности в одном или нескольких Diamonds. Это независимые контракты, которые могут совместно использовать внутренние функции, библиотеки и переменные состояния.

Что происходит, когда мы используем Diamond

• Обновляемые контракты: Diamond предоставляет систематический способ изолировать различные плагины и соединять их вместе, а также добавлять/заменять/удалять любые плагины непосредственно с помощью функции DiamondCut. Нет ограничений на количество плагинов, которые могут быть добавлены в Diamond с течением времени.
• Модульные и многоразовые плагины: развернутый плагин может использоваться любым количеством Diamonds, что значительно снижает затраты на развертывание.

Разница между безопасным смарт-аккаунтом и методом Diamond

Между архитектурами Safe и Diamond существует много общего: обе архитектуры опираются на прокси-контракты в качестве ядра и ссылаются на логические контракты для обеспечения возможности обновления и модульности.

Однако основное отличие заключается в обработке логических контрактов. Вот более подробная инструкция:

• Гибкость: при включении новых плагинов Safe необходимо повторно развернуть свой одноэлементный контракт, чтобы внести изменения в свой агент. Напротив, Diamond делает это напрямую через функцию DiamondCut в своем делегате. Эта разница в подходе означает, что Safe сохраняет более высокую степень контроля, а Diamond обеспечивает большую гибкость и модульность.
• Безопасность: в настоящее время в обеих структурах используется вызов делегата, который позволяет внешнему коду манипулировать хранилищем основного контракта. В безопасной архитектуре вызов делегата указывает на один логический контракт, тогда как Diamond использует вызов делегата между несколькими контрактами модулей (подключаемых модулей). Таким образом, вредоносный плагин может перезаписать другой плагин, тем самым создавая риск конфликтов хранилища, которые могут поставить под угрозу целостность агента.
• Стоимость. Гибкость, присущая ромбовидному подходу, сопряжена с повышенными проблемами безопасности. Это добавляет фактор затрат и требует полного аудита каждый раз при добавлении нового плагина. Ключевым моментом является обеспечение того, чтобы эти плагины не мешали работе друг друга, что может стать проблемой для малого и среднего бизнеса, пытающегося поддерживать строгие стандарты безопасности.

«Метод безопасного смарт-аккаунта» и «Метод ромба» являются примерами различных структур, включающих агентов и модули. Как сбалансировать гибкость и безопасность имеет решающее значение, и эти два подхода, вероятно, будут дополнять друг друга в будущем.

Порядок модулей: валидатор, исполнитель и хук

Давайте расширим наше обсуждение, представив стандарт ERC 6900, предложенный командой Alchemy, который был вдохновлен Diamond и специально адаптирован для ERC-4337. Он решает проблему модульности смарт-аккаунтов, предоставляя общий интерфейс и координируя работу между разработчиками плагинов и кошельков.

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

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

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

Обнаружение и безопасность модулей

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

Безопасный{основной}протокол

Протокол Safe{Core} — это совместимый протокол учетных записей смарт-контрактов с открытым исходным кодом, предназначенный для повышения доступности для различных поставщиков и разработчиков посредством четко определенных стандартов и правил, сохраняя при этом высокий уровень безопасности.

• Учетная запись. В протоколе Safe{Core} концепция учетной записи является гибкой и не ограничена конкретной реализацией. Это позволяет участвовать различным поставщикам услуг по учетным записям.
• Менеджер: Менеджер действует как координатор между учетными записями, реестрами и модулями. Он также отвечает за безопасность, выступая в качестве уровня разрешений.
• Реестр: Реестр определяет атрибуты безопасности и обеспечивает соблюдение стандартов модулей, таких как ERC 6900, с целью создания открытой среды «магазина приложений» для обнаружения и безопасности.
• Модули: модули управляют функциональностью и предоставляются в различных начальных типах, включая плагины, хуки, средства проверки подписи и обработчики функций. Разработчики могут этому способствовать, если они соответствуют установленным стандартам.

Дизайн со стразами

Процесс разворачивается следующим образом:

• Создание определения схемы: схема служит предопределенной структурой данных для доказательства. Предприятия могут настраивать шаблон в соответствии со своими конкретными сценариями использования.
• Создайте модуль на основе шаблона: смарт-контракт регистрируется как модуль, получает байт-код и выбирает идентификатор шаблона. Эти данные затем сохраняются в реестре.
• Получите доказательства модулей: Сертификаторы/аудиторы могут предоставить доказательства модулей на основе схемы. Эти сертификаты могут включать уникальные идентификаторы (UID) и ссылки на другие сертификаты для связывания. Их можно распространять по цепочке и проверять соответствие определенным пороговым значениям в целевой цепочке.
• Используйте парсеры для реализации сложной логики: парсеры опционально устанавливаются в шаблоне. Их можно вызывать во время создания модуля, установления доказательства и демонтажа. Эти парсеры позволяют разработчикам включать сложную и разнообразную логику, сохраняя при этом структуру доказательства.
• Удобный доступ к запросам: Query предоставляет пользователям возможность доступа к информации о безопасности из внешнего интерфейса. ЭИП можно найти здесь.

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

• Сертификатор: доверенные организации, такие как Safe, могут сотрудничать с Rhinestone в качестве сертификаторов внутренних модулей. В то же время к участию могут присоединиться и независимые испытатели.
• Разработчики модулей: С формированием открытого рынка разработчики модулей смогут коммерциализировать свою работу через реестр.
• Пользователи: через удобные интерфейсы, такие как кошельки или децентрализованные приложения, пользователи могут просматривать информацию о модулях и делегировать доверие различным проверяющим.

Концепция «реестра модулей» предоставляет выгодные возможности разработчикам плагинов и модулей. Это также может проложить путь к «рынку модулей». Некоторые из этих аспектов могут контролироваться командой Safe, в то время как другие могут проявляться в виде децентрализованных торговых площадок, которые приглашают всех внести свой вклад и обеспечивают прозрачный контрольный журнал. Применяя такой подход, мы можем избежать привязки к поставщику и поддержать расширение EVM, обеспечив лучший пользовательский опыт, который понравится более широкой аудитории.

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

Подведем итог

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

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

Мы предвидим будущее с широким участием, что поднимает некоторые интересные вопросы: как только процесс заказа SCA станет достаточно прибыльным, как традиционные механизмы извлечения ценности майнерами (MEV) войдут в эту сферу, создадут сборщики пакетов и получат прибыль? Когда инфраструктура станет более зрелой, как абстракция учетной записи (AA) сможет стать базовым уровнем для транзакций, основанных на намерениях? Пожалуйста, следите за обновлениями, поскольку эта область постоянно развивается.