На примере Particle Network технология интерпретирует проблемы взаимодействия с текущими продуктами Web3

Автор: Wuyue, Geek Web3

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

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

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

Мы возьмем Particle Network в качестве примера, чтобы подробно объяснить текущие проблемы с опытом продуктов Web3 и то, как спроектировать комплексное техническое решение, которое может стать необходимым условием для массового внедрения. В то же время, бизнес-стратегия Particle BtoBtoC является идеей, на которой многим участникам проекта нужно поучиться. **

Полное решение по структуре частиц

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

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

Particle Chain — решение для абстракции омничейн-аккаунта, предназначенное для Particle, предназначенное для решения кроссчейн-развертывания, обслуживания и вызова кошельков смарт-контрактов. Существует также Unified Gas Token (Унифицированный газовый токен) для решения проблемы использования различных газовых монет для многоцепочечных транзакций.

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

zkWaaS – Умный кошелек как услуга в сочетании с ZK

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

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

** Стоимость привлечения клиента высока на стороне C, но отличается на стороне B. ** Рост пользователей WaaS в основном обусловлен децентрализованными приложениями, интегрированными с SDK. До тех пор, пока отношения между BD и разработчиками хорошие, вся экосистема может быть расширена в стиле «город, окружающий сельскую местность».

**В настоящее время кошельки C-end в основном ориентированы на финансы и активы, и нам сложно сказать, что это основной сценарий развития Web3 в будущем. Чтобы по-настоящему добиться массового внедрения Web3, должны быть проекты, которые абстрагируют более базовые функции - идентификацию пользователя (учетную запись) и управление пользователем (отправку транзакций/транзакций) как низкоуровневый сервис, и передают более богатые сценарии верхнего уровня dApp.

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

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

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

2. Конфиденциальность транзакций. ** Внедрить одноранговые универсальные частные переводы через механизм Smart Stealth Address и использовать ERC4337 Paymaster, чтобы позволить Stealth Address использовать активы (газовые спонсоры) без газа.

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

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

Решение для приватного входа в систему использует JWT (Json Web Token), который можно использовать для аутентификации личности Web2 и работы кошелька в рамках контракта.

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

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

·" iss" (Issuer) указывает на издателя JWT, то есть сервера, такого как Google, Twitter и т.д.

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

·" sub" (Subject) относится к идентификатору пользователя, принимающего JWT, который обычно помечен UID.

На практике МКС и ПЛ не изменятся в подавляющем большинстве случаев, иначе это принесет огромную кашу из внутренних систем и внешних референсов. Таким образом, эти параметры могут быть использованы контрактом для определения личности пользователя,** так что пользователю вообще не нужно генерировать и хранить закрытый ключ. **

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

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

Поток решения для частного входа в систему Particles показан на следующем рисунке:

Среди них мы пропустим здесь конкретную схему ZK. Перечислим лишь несколько ключевых моментов в этом процессе:

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

Eph_pk (эфемерная пара ключей) — это пара ключей, используемая в одной сессии, а не публичный или приватный ключ кошелька, и пользователю не нужно беспокоиться.

Эта система также может быть использована для проверки вне сети, а также может быть использована для контрактных кошельков, использующих логику, такую как 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. Бобу необходимо периодически сканировать контракт записи временного открытого ключа и записывать каждый обновленный временный открытый ключ. Поскольку временный контракт открытого ключа является открытым и содержит ключи, связанные с частными транзакциями, отправленными другими пользователями, Боб не знает, какой из них ему отправила Алиса.

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

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

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

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

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

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

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

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

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

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

Пополните счет Paymaster через любой из ваших собственных адресов, и Paymaster вернет подтверждение наличия средств (ZK).

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

На самом деле это похоже на то, как работает Tornado Cash, с помощью proof-of-funds (ZK), который может доказать, что в наборе листовых узлов на дереве Меркла было пополнение, и никто не может знать, какой листовой узел был израсходован, когда он был потрачен, чтобы прервать связь между потребителем и вкладчиком.

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

Абстракция цепочки частиц и полной цепочки

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

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

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

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

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

** Абстракция полного аккаунта Particle Chain решает вышеуказанные проблемы:**

Создайте кошелек AA на Particle Chain.

Через кроссчейн-протокол AMB (Arbitrary Message Bridge), такой как LayerZero, различные операции, такие как создание, обновление, изменение разрешений и т. д., синхронизируются с другими цепочками. **Можно понять, что другие кошельки в цепочке являются ссылками на кошельки в цепочке, и только основное тело должно быть изменено для синхронизации со всеми кошельками.

** Контракт деплотера с согласованными параметрами, гарантирующими, что адрес кошелька в каждой цепочке одинаков. **

Кошельки между цепочками также могут вызывать друг друга через AMB, не все из которых инициируются из Particle Chain.

**Выпуск Unified Gas Token, газовой монеты с полной цепочкой. **ERC20 реализован механизмом Paymaster в качестве платы за газ. Даже если в определенной цепочке нет газа или предварительно внесенных средств Paymaster, вы можете инициировать кроссчейн-транзакцию в соответствующей цепочке, чтобы использовать Unified Gas Token.

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

Децентрализованная сеть, созданная zkWaaS Proof and Salt.

Уровень поощрения каждой цепочки Bundler помогает Bundler достичь лучшей децентрализации.

Сеть Solver как протокол Intent Fusion.

В повествовании Particle Chain Unified Gas Token является основной ценностью всей экосистемы:

Функция оплаты платы за газ — это сильная логика спроса и захвата стоимости, которая была неоднократно проверена в крипте.

Unified Gas Token абстрагирует концепцию газового слоя от существующей публичной экологии цепочки, и эта абстракция не может быть достигнута без Particle Chain и кошелька, поэтому Unified Gas Token — это изъятие ценности всей экологии Particle. Благодаря газовому слою взаимодействие пользователей и рост каждой цепочки и стоимости местной валюты являются взаимовыгодными и симбиотическими с Unified Gas Token.

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

Пользователи, импортируемые dApp, напрямую расширяют возможности Unified Gas Token, а сценарии использования очень богаты.

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

Обычно нам нужно постоянно думать о пути использования при использовании различных dApps:

Если на одной DEX нет ликвидности, нужно присмотреться к другой DEX.

Я не знаю, какое децентрализованное приложение той же категории следует выбрать, чтобы лучше завершить транзакцию или транзакцию.

· Approve имеет множество функций для использования, а что такое approve?

Пыль в кошельке, несколько мелких токенов в определенной валюте, процесс громоздкий.

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

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

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

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

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

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

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

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

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

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

Резюме

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

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