Технический анализ: Уровень доступа в Open Web, созданный Particle Network

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

Хотя мы видим, что различные решения по оптимизации UX, такие как MPC-кошелек ZenGo или кошельки для смарт-контрактов, такие как Argent, эффективно снижают барьеры для пользователей, они решают лишь часть вышеупомянутых проблем, не полностью покрывая общую проблему удобства использования продукта.

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

На примере Particle Network мы подробно расскажем о текущих проблемах UX, с которыми сталкиваются продукты Web3, и обсудим, как разработать целенаправленное комплексное техническое решение. Такое интегрированное решение может стать необходимым условием для массового внедрения. Кроме того, бизнес-стратегия BtoBtoC компании Particle представляет собой достойный внимания подход, который может оказаться полезным для многих проектных команд.

Структурная разбивка продуктов на частицы

Компания Particle Network, ориентированная на снижение барьеров использования, применяет подход к созданию продуктов B2B2C и экологическому развитию, предлагая комплексное решение для широкого внедрения Web3. Его основные модули состоят из трех ключевых компонентов:

zkWaaS означает zero-knowledge wallet-as-a-service. Разработчики могут быстро интегрировать модули смарт-кошельков в свои dApp, используя SDK Particle. Кошелек представляет собой бесключевой смарт-контрактный кошелек, основанный на абстракции счета, позволяющий осуществлять платежи за газ и предлагающий конфиденциальный вход в систему и конфиденциальные транзакции в стиле Web2 OAuth.

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

Intent Fusion Protocol - Включает в себя краткий Domain-Specific Language (DSL), фреймворк Intent, сеть Intent Solver Network и т.д. для построения фреймворка взаимодействия Web3 на основе намерений. Пользователи напрямую объявляют о своих намерениях, а не выполняют каждую конкретную операцию, что освобождает их от сложных размышлений о путях и уменьшает необходимость в понимании сложной базовой инфраструктуры.

zkWaaS - Zero-Knowledge Wallet-as-a-Service

Что касается кошелька, Particle в первую очередь предоставляет SDK для разработчиков dApp в виде Wallet-as-a-Service (WaaS). Цель - дать разработчикам возможность интегрироваться в комплексную систему массового внедрения Web3. Такой подход BtoBtoC имеет ряд преимуществ как с точки зрения бизнеса, так и с точки зрения экосистемы:

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

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

Нынешние потребительские кошельки в основном ориентированы на финансы и активы, что может не соответствовать основным сценариям будущего Web3. Чтобы добиться широкого распространения Web3, такие основополагающие функции, как идентификация пользователя (учетные записи) и пользовательские операции (инициирование транзакций), должны быть абстрагированы как фундаментальный сервис, оставляя более богатые сценарии на усмотрение dApps.

Исторически сложилось так, что точки входа для dApps демонстрируют тесную взаимосвязь между кошельками и dApps. Увеличение доли рынка кошелька на стороне dApp имеет решающее значение. Это особенно выгодно для модели B2B2C.

Чтобы создать решение, отвечающее потребностям пользователей, снижающее входные барьеры и облегчающее интеграцию разработчиков, zkWaaS от Particle выступает в качестве ключевого компонента с тремя основными характеристиками:

1. Конфиденциальный вход: Использование традиционных методов входа в систему Web2, таких как верификация OAuth от таких платформ, как Twitter, Google, WeChat и т.д., на кошельке смарт-контракта. Это позволяет пользователям полностью освободиться от ограничений, связанных с управлением закрытыми ключами, и войти в Web3 наиболее привычным и простым способом. Одновременно личность пользователя скрывается с помощью доказательств с нулевым знанием.

2. Конфиденциальные транзакции: Реализация передачи конфиденциальности "точка-точка" с помощью механизма Smart Stealth Address, обеспечивающего всеобщую конфиденциальность транзакций. Кроме того, использование функции Paymaster в ERC-4337 позволяет использовать активы без газа для Smart Stealth Addresses (спонсорство газа).

3. Всеобъемлющая функциональность кошелька AA: Модуль кошелька Particle полностью соответствует фундаментальным требованиям ERC-4337. Он включает в себя такие важные компоненты, как Bundler, EntryPoint, Paymaster, Smart Wallet Account и другие, охватывая все критические аспекты рабочего процесса ERC-4337. Это универсальное решение эффективно удовлетворяет функциональные требования DApps или пользователей к смарт-кошелькам.

Конфиденциальный вход для цепочечных кошельков на основе Web2-аккаунтов

Решение Particle для конфиденциального входа в систему использует JSON Web Tokens (JWT), обеспечивая аутентификацию личности Web2 и операции с кошельком в рамках смарт-контракта.

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

(Источник: FlutterFlow Docs)

В JWT есть несколько ключевых полей, которые служат основой для проверки личности по договору:

- "iss" (Issuer) указывает на эмитента JWT, то есть сервер, например, Google, Twitter и т.д.

- "aud" (Audience): Указывает сервис или приложение, для которого предназначен JWT. Например, при входе на Medium с помощью Twitter, JWT, выданный Twitter, будет содержать это поле, указывающее на его применимость к Medium.

- "sub" (субъект): Относится к личности пользователя, получившего JWT, обычно идентифицируется по UID.

На практике "iss" и "sub" обычно остаются неизменными, чтобы избежать существенной путаницы между внутренними системами и внешними ссылками. Таким образом, эти параметры могут использоваться контрактом для определения личности пользователя, что избавляет пользователей от необходимости генерировать и хранить закрытые ключи.

С JWT корреспондирует концепция JSON Web Key (JWK), представляющая собой набор пар ключей на сервере. При выдаче JWT сервер подписывает его закрытым ключом JWK, а соответствующий открытый ключ выкладывается в открытый доступ, чтобы другие сервисы могли проверить подпись.

Например, когда Medium использует Twitter для входа в систему, Medium проверит JWT с помощью публичного JWK Google, чтобы подтвердить его подлинность - что он действительно был выдан Google. Проверка JWT по контракту также будет включать использование JWK.

Процесс работы решения Particle для конфиденциального входа в систему показан на схеме ниже:

Здесь мы не будем рассматривать конкретную схему ZK, а просто выделим некоторые ключевые моменты процесса:

Контракт Verifier, проверяющий информацию для входа в систему, будет воспринимать только ZK Proof, связанный с идентификационным JWT пользователя, и eph_pk. Он не может напрямую получить соответствующий открытый ключ кошелька или информацию JWT, обеспечивая конфиденциальность пользователя и не позволяя внешним субъектам идентифицировать пользователя по данным в сети.

eph_pk (ephemeral key pair) - это пара ключей, используемая в течение одной сессии и не являющаяся парой открытый-частный ключ кошелька. Пользователям не нужно беспокоиться об этом.

Эта система поддерживает внецепочечную верификацию и может использоваться для контрактных кошельков, использующих такую логику, как MPC (многосторонние вычисления).

Поскольку это решение для проверки контракта, не основанное на традиционных методах входа в систему, пользователи также могут назначить других социальных контактов в качестве опекунов в экстремальных случаях, например, когда учетная запись Web2 деактивирована.

Конфиденциальные операции на основе обмена ключами DH

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

Если предположить, что Алиса - отправитель, а Боб - получатель, то обе стороны обладают некоторыми общими знаниями:

1. Боб генерирует корневой расходный ключ (m) и скрытый мета-адрес (M). M может быть сгенерирован m, и их связь представлена M = G * m, что указывает на математическую связь в криптографических операциях.

2. Алиса получает скрытый мета-адрес Боба M любым способом.

3. Алиса генерирует эфемерный закрытый ключ (r) и использует алгоритм generate_address(r, M) для создания скрытого адреса (A). Этот адрес служит в качестве выделенного скрытого адреса, подготовленного для Боба, и Боб получает контроль над ним после получения активов.

4. Алиса генерирует эфемерный публичный ключ (R) на основе эфемерного закрытого ключа r и отправляет его в контракт на запись эфемерного публичного ключа (или в любое другое взаимно согласованное место, к которому Боб может получить доступ).

5. Боб периодически сканирует контракт на запись эфемерных pubkey, записывая каждый обновленный эфемерный pubkey. Поскольку эфемерный контракт pubkey является публичным и содержит ключи, связанные с транзакциями конфиденциальности, отправленными другими людьми, Боб не знает, какой из них Алиса отправила ему для просмотра.

6. Боб сканирует каждую обновленную запись, выполняя generate_address(R, m) для вычисления скрытого адреса. Если в этом адресе есть активы, значит, Алиса сгенерировала и авторизировала его для контроля Боба; в противном случае он не имеет отношения к Бобу.

7. Боб выполняет команду generate_spending_key(R, m), чтобы сгенерировать ключ траты для этого скрытого адреса, т.е. p = m + hash(A). Затем Боб может контролировать адрес A, сгенерированный Алисой.

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

Этот процесс обмена в некоторой степени аналогичен известному методу обмена ключами Диффи-Хеллмана. Не раскрывая своих секретов (корневого ключа Боба (m) и эфемерного закрытого ключа Алисы (r)), обе стороны могут вычислить общий секрет - скрытый адрес (A), упомянутый ранее. Если Вы не знакомы с обменом ЦТ, метафорическое понимание может быть облегчено с помощью приведенной ниже схемы.

Дополнительный шаг по сравнению с DH заключается в том, что после вычисления общего секрета - скрытого адреса (A), он не может быть использован в качестве закрытого ключа напрямую, поскольку Алиса также знает A. Необходимо построить ключ траты (p = m + hash(A)), используя A в качестве открытого ключа. Как упоминалось ранее, только Боб знает корневой ключ траты (m), что делает Боба единственным контролером этого скрытого адреса.

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

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

Используя метод расчета адреса из функции CREATE2 во время развертывания контракта, вместе с соответствующими параметрами (установка скрытого адреса A в качестве владельца контракта и т.д.), рассчитайте контрфактический адрес. Это вычисленный контрактный адрес, который еще не развернут, в настоящее время это EOA.

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

Мы можем называть вышеупомянутый контрфактический адрес "умным скрытым адресом". Боб анонимно использует активы под этим Smart Stealth Address посредством следующего процесса:

-Положите деньги в Paymaster с любого из его адресов, и Paymaster вернёт подтверждение наличия средств (на основе ZK).

-С помощью механизма AA используйте любой другой адрес, который может не иметь баланса, чтобы отправить UserOperation узлу Bundler, вызывая активы под упомянутым скрытым адресом. Бобу нужно только предоставить подтверждение о переводе средств в Paymaster, используя новый адрес, а Paymaster платит бандлеру за упаковку транзакции.

Этот процесс похож на то, как работает Tornado Cash. Доказательство фонда (на основе ZK) может доказать, что пополнение произошло в наборе листовых узлов дерева Меркла. Однако при расходовании средств никто не может определить, средства какого именно листового узла были израсходованы, тем самым разрывая связь между потребителем и подзарядным устройством.

В общем, Particle умело сочетает AA со стелс-адресами, обеспечивая конфиденциальные переводы через форму интеллектуальных стелс-кошельков.

Цепочка частиц & Абстракция счета Omnichain

Particle Chain - это POS-цепочка, разработанная для Omnichain Account Abstraction. Учитывая настоящее и будущее, доминирование одной сети маловероятно. Улучшение пользовательского опыта в многоцепочечном сценарии имеет решающее значение.

В настоящее время система абстракции счета ERC4337 может столкнуться с определенными проблемами в ситуации с несколькими цепочками:

• Адреса одного и того же пользователя в разных цепочках могут быть неодинаковыми, в зависимости от дизайна контракта.
• Управление кошельками контрактов различных цепочек требует ручных операций в нескольких цепочках, например, смены администраторов. В худших сценариях, если права администратора обновляются в одной цепочке, а затем отменяется старый метод проверки администратора, внести изменения в другие цепочки становится невозможно, что делает кошелек непригодным для использования.
• Использование разных цепочек требует наличия жетонов газа для каждой цепочки или предварительно накопленных средств в Paymaster каждой цепочки. Для разработчиков это может стать проблемой. Если они хотят, чтобы пользователи могли использовать определенные условия по нулевой цене или реализовывать другие функции, им нужно установить свои собственные Paymaster'ы на каждую цепочку и предварительно профинансировать их.

Абстракция Omnichain Account Abstraction от Particle Chain решает все вышеперечисленные проблемы:

• Создайте кошельки AA на Particle Chain.
• Используйте LayerZero и другие межцепочечные протоколы Arbitrary Message Bridge (AMB) для синхронизации различных операций, таких как создание, обновление и изменение разрешений, с другими цепочками. Это можно понимать так, что кошельки на других цепочках являются ссылками на кошелек на этой цепочке, а изменения в основной части синхронизируются со всеми кошельками.
• Обеспечьте единые адреса для кошельков на каждой цепочке с помощью согласованного параметра Deployer Contract.
• Кошельки на разных цепочках также могут звонить друг другу через AMB, не обязательно инициированные из Particle Chain.
• Выпустите Единый Газовый Жетон. Механизм Paymaster реализует ERC20 в качестве платы за газ. Даже если в цепочке нет газа или предварительно накопленных средств в Paymaster, межцепочечные транзакции с использованием унифицированных газовых токенов могут быть инициированы на совместимых цепочках.

Помимо вышеупомянутых вариантов использования, Particle Chain также может быть использована для:

• Децентрализованная сеть для доказательств zkWaaS и генерации соли.
• Стимулирующие уровни для бандлеров в разных цепочках, помогающие бандлерам достичь большей децентрализации.
• Служит в качестве сети решателей для протокола Intent Fusion Protocol.

В истории Particle Chain унифицированный газовый токен служит основным ценностным предложением для всей экосистемы:

• Функциональность оплаты газа - это неоднократно подтвержденный высокий спрос и логика захвата стоимости в криптовалютном пространстве.
• Unified Gas Token абстрагирует концепцию газовых слоев от существующих экосистем публичных цепочек. Эта абстракция не может быть достигнута без Particle Chain и кошельков. Таким образом, единый газовый токен представляет собой реализацию ценности для всей экосистемы Particle. С газовым слоем взаимодействие пользователей, рост и ценность собственных токенов в различных цепочках находятся во взаимовыгодной связи с единым газовым токеном.
• Унифицированный газ также является одним из движущих факторов для достижения Chainless. Для пользователей использование единой валюты значительно упрощает процесс использования и понимание затрат. В будущем, даже в многоцепочечном сценарии, пользователи могут не знать и не беспокоиться о работе базовой инфраструктуры. Подобно тому, как сейчас в Web2 мы взаимодействуем с серверами, не заботясь о расположении центров обработки данных, их конфигурациях, языках и базах данных, которые они используют.
• Пользователи, импортируемые dApps, напрямую расширяют возможности унифицированного газового токена, предлагая широкий спектр вариантов использования.

Протокол слияния намерений

Как правило, при использовании различных dApp пользователям постоянно приходится учитывать пути использования:

• Если на одном DEX нет ликвидности, необходимо проверить другой DEX.
• Выбор наиболее подходящего dApp в рамках одной категории для выполнения транзакции или задачи.
• Понимание концепции "Утвердить" необходимо для того, чтобы иметь возможность использовать многие функции.
• Вытирать пыль с кошельков, конвертировать множество мелких токенов в конкретный токен - утомительный процесс.
• Выполнение нескольких шагов в различных приложениях для достижения конечной цели. Например, при кредитовании с большим кредитным плечом: обмен, ставка, заем, получение жетонов, затем снова обмен, ставка и заем.

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

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

Аналогично, использование Intents требует поддержки со стороны ряда объектов. Давайте рассмотрим весь процесс:

1. Пользователи представляют свои намерения, описывая их каким-либо образом, например, на естественном языке, в виде RFS (Request For Solver), передаваемых в сеть Solver. Solver - это интерпретатор для намерений, а такие распространенные решатели, как 1inch, - агрегатор, ищущий оптимальный DEX для пользователей. Однако эти решатели, по сравнению с нашим видением, могут оказаться недостаточно универсальными и мощными.

2. Несколько решателей отвечают, соревнуясь друг с другом. Эти ответы написаны на языке Intent DSL, а затем разобраны клиентом в форме, удобной для понимания пользователями. Эти реакции включают ограничения на входе и ограничения на выходе, определяющие границы входов и выходов. Пользователи также могут сами указывать ограничения. Простой пример для понимания: при использовании Swap пользователю предлагается указать минимальную сумму, которую он может получить после обмена, что является формой ограничения. Пользователи выбирают из ответов, предоставленных несколькими решателями.

3. Подпишите намерение.

4. Решатель задает конкретный контракт на выполнение Исполнителю и передает намерение контракту на ответ Реактору.

5. Реактор собирает необходимые исходные данные (например, определенный актив) со счета пользователя, передает намерение Исполнителю, и после вызова соответствующего логического контракта возвращает результат транзакции Реактору. Реактор проверяет ограничения и, если они верны, возвращает результат пользователю.

Мы можем представить себе этот процесс так, как будто Вы объясняете ChatGPT свои требования. Независимо от того, насколько сложными являются требования, он сможет создать для Вас окончательный результат. Если Вы удовлетворены результатом, Вы можете использовать его напрямую, не обращая внимания на основной процесс.

Заключение

Компания Particle Network предложила комплексное решение: благодаря интегрированной форме zkWaaS, Particle Chain и Intent Fusion Protocol она обеспечивает конфиденциальный вход в систему Web2 OAuth, конфиденциальные транзакции, абстракцию учетной записи omnichain и парадигму транзакций на основе намерений. Каждая функция решает часть проблем, связанных с использованием Web3. Эти усовершенствования и оптимизации послужат основой для будущего повсеместного внедрения продуктов и технологий Web3. Что касается экосистемы и бизнес-моделей, то следует принять парадигму B2B2C, использовать WaaS в качестве точки входа, чтобы обеспечить масштабируемость и стандартизацию всей цепочки продуктов, совместно с разработчиками dApp создать экосистему и совместно создать для пользователей мир Web3 с низким порогом и высоким уровнем впечатлений.

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

Отказ от ответственности：

1. Эта статья перепечатана с сайта[极客 Web3], все авторские права принадлежат автору оригинала[雾月，极客Web3]. Если у Вас есть возражения против этой перепечатки, пожалуйста, свяжитесь с командой Gate Learn, и они незамедлительно рассмотрят их.
2. Отказ от ответственности: Мнения и взгляды, выраженные в этой статье, принадлежат исключительно автору и не являются инвестиционным советом.
3. Перевод статьи на другие языки осуществляется командой Gate Learn. Если не указано, копирование, распространение или плагиат переведенных статей запрещены.