Вступ: Хоча гаманці AA значно знизили бар'єри для входу користувачів і дозволили здійснювати платежі за газ і входити в облікові записи на web2, аспекти, пов'язані з масовим впровадженням, такі як конфіденційний вхід, конфіденційні транзакції, омнічайні AA і протокол злиття намірів, все ще потребують подальшого розвитку на основі AA.

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

Очевидно, що більшість гаманців АА або подібних продуктів ще не можуть підтримувати широке впровадження Web3. З іншого боку, з точки зору екосистеми, сторона розробника є вирішальним аспектом. Привабливість для звичайних користувачів сама по собі, без достатнього впливу на розробників, навряд чи дозволить досягти масштабованості. Поява більшої кількості рішень для оптимізації досвіду розробників свідчить про зростаючу важливість сторони розробника в екосистемі продукту.

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

Розподіл структури продукції за частинками

Particle Network, основним завданням якої є зниження бар'єрів у використанні, застосовує підхід до створення продуктів B2B2C та екологічної розробки, забезпечуючи комплексне рішення для широкого впровадження Web3. Її основні модулі складаються з трьох ключових компонентів:

zkWaaS - це гаманець як послуга з нульовим рівнем знань. Розробники можуть швидко інтегрувати модулі смарт-гаманців у свої додатки за допомогою SDK від Particle. Гаманець - це безключовий гаманець смарт-контрактів, заснований на абстракції рахунків, що дозволяє здійснювати платежі за газ і пропонує конфіденційний вхід в систему та конфіденційні транзакції в стилі Web2 за протоколом OAuth.

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

Протокол злиття намірів - включає в себе стислу доменну мову (DSL), фреймворк Intent, мережу Intent Solver Network і т.д. для побудови фреймворку взаємодії Web3 на основі намірів. Користувачі декларують свої наміри щодо транзакцій безпосередньо, а не виконують кожну конкретну операцію, що звільняє їх від складних міркувань щодо шляхів і зменшує потребу в розумінні складної базової інфраструктури.

zkWaaS - Гаманець як послуга з нульовим рівнем знань

Що стосується гаманців, Particle в першу чергу надає SDK для розробників dApp у формі Wallet-as-a-Service (WaaS). Мета полягає в тому, щоб дозволити розробникам інтегруватися у всеосяжну структуру масового впровадження Web3. Такий підхід BtoBtoC має низку переваг як з точки зору бізнесу, так і з точки зору екосистеми:

Ринок споживчих гаманців є висококонкурентним, а їхні функціональні можливості стають все більш схожими. Гаманці споживачів більше не є оптимальною точкою входу. З іншого боку, розробники dApp вважають за краще інтегрувати гаманці в свої додатки, щоб покращити користувацький досвід і надати більше можливостей для налаштування.

Залучення користувачів з боку споживача коштує дорого, але з боку бізнесу все інакше. Зростання користувачів WaaS в основному відбувається за рахунок додатків, інтегрованих з SDK. За умови ефективного розвитку бізнесу та відносин з девелоперами екосистема може органічно розширюватися.

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

Історично точка входу для dApps демонструє тісний взаємозв'язок між гаманцями та dApps. Збільшення частки ринку гаманця на стороні dApp має вирішальне значення. Це особливо вигідно для моделі B2B2C.

Для створення рішення, яке відповідає потребам користувачів, знижує бар'єри для входу та полегшує інтеграцію розробників, zkWaaS від Particle слугує ключовим компонентом з трьома основними функціями:

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

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

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

Конфіденційний логін для он-лайн гаманців на основі облікових записів Web2

Рішення для конфіденційного входу від Particle використовує веб-токени JSON (JWT), що дозволяє здійснювати аутентифікацію особи в Web2 та операції з гаманцями в рамках смарт-контракту.

JWT - це широко використовувана форма підтвердження особи в традиційних інтернет-додатках, що видається сервером клієнту. Клієнт використовує цей доказ для автентифікації особи при кожній взаємодії з сервером.

(Джерело: FlutterFlow Docs)

У JWT є кілька ключових полів, які є основою для перевірки особи за контрактом :

-"iss" (Емітент) вказує на емітента JWT, тобто сервер, наприклад, Google, Twitter тощо.

-"aud" (Аудиторія): Вказує послугу або програму, для якої призначена 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, лише виділимо деякі ключові моменти цього процесу:

Контракт Верифікатора, який перевіряє дані для входу, буде сприймати тільки ZK Proof, пов'язаний з ідентифікатором користувача 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, згенеровану Алісою.

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

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

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

Зрозуміло, що при такому методі передачі конфіденційності для кожної нової отриманої транзакції кошти будуть надходити на абсолютно нову адресу EOA. Одержувач може використовувати кореневий ключ витрат для ітеративного обчислення ключа витрат для кожної адреси, експериментуючи, щоб знайти той, який дійсно пов'язаний з ним.

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

Використовуючи метод обчислення адреси з функції CREATE2 під час розгортання контракту, разом з відповідними параметрами (встановлення стелс-адреси A як власника контракту тощо), обчисліть контрфактичну адресу. Це обчислювальна адреса контракту, яка ще не розгорнута, наразі це EOA.

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

Ми можемо назвати вищезгадану контрфактичну адресу "розумною стелс-адресою". Боб анонімно використовує активи за цією розумною стелс-адресою за допомогою наступного процесу:

-Поповніть Paymaster з будь-якої його адреси, і Paymaster поверне вам підтвердження коштів (на основі ZK).

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

Цей процес схожий на те, як працює Tornado Cash. Фондове доведення (на основі ZK) може довести, що у множині листкових вузлів на дереві Меркла відбулося перезаряджання. Однак при витрачанні коштів ніхто не може визначити, кошти якого саме вузла були витрачені, тим самим розриваючи зв'язок між споживачем і зарядним пристроєм.

Підсумовуючи, Particle розумно поєднує АА зі стелс-адресами, забезпечуючи конфіденційність переказів за допомогою інтелектуальних стелс-гаманців.

Ланцюжок частинок & Абстракція облікового запису Omnichain

Particle Chain - це POS-ланцюжок, розроблений для абстракції Omnichain Account Abstraction. З огляду на сьогодення і майбутнє, домінування одноланцюгових систем малоймовірне. Покращення користувацького досвіду в багатоланцюговому сценарії має вирішальне значення.

В даний час система абстрагування облікових записів ERC4337 може зіткнутися з певними проблемами в ситуації з декількома ланцюжками:

• Адреси одних і тих самих користувачів у різних ланцюжках можуть бути різними, залежно від структури контракту.
• Керування різними гаманцями ланцюгових контрактів вимагає ручних операцій у кількох ланцюгах, наприклад, зміни адміністраторів. У гірших сценаріях, якщо права адміністратора оновлюються на одному ланцюжку, а потім відкидається старий метод перевірки адміністратора, стає неможливим вносити зміни на інших ланцюжках, що робить гаманець непридатним для використання.
• Використання різних ланцюжків вимагає наявності газових токенів для кожного ланцюжка або попередньо збережених коштів у Paymaster кожного ланцюжка. Для розробників це може бути проблематично. Якщо вони хочуть, щоб користувачі могли користуватися певними умовами безкоштовно або реалізувати інші функції, їм потрібно розгорнути свої власні Paymasters у кожному ланцюжку і попередньо профінансувати їх.

Абстракція омніканального акаунта від Particle Chain вирішує вищезгадані больові точки:

• Створіть гаманці AA на Particle Chain.
• Використовуйте LayerZero та інші міжланцюгові протоколи Arbitrary Message Bridge (AMB) для синхронізації різних операцій, таких як створення, оновлення та зміна дозволів, з іншими ланцюгами. Це можна розуміти так, що гаманці в інших ланцюжках є посиланнями на гаманець в цьому ланцюжку, а зміни в основному тексті синхронізуються з усіма гаманцями.
• Забезпечити єдині адреси для гаманців у кожному ланцюжку за допомогою узгодженого параметра Deployer Contract.
• Гаманці в різних ланцюжках також можуть викликати один одного через AMB, не обов'язково ініційовані з ланцюжка Particle Chain.
• Випустити єдиний газовий токен. Механізм Paymaster впроваджує ERC20 як плату за газ. Навіть у ланцюжку без газу або попередньо збережених коштів у Paymaster можна ініціювати міжланцюгові транзакції з використанням уніфікованих газових токенів у ланцюжках, що відповідають вимогам.

На додаток до вищезгаданих випадків використання, Particle Chain також може бути використаний для інших цілей:

• Децентралізована мережа для zkWaaS-перевірок і генерації солі.
• Стимулюючі шари для учасників різних ланцюгів, які допомагають учасникам досягти більшої децентралізації.
• Слугує мережею розв'язувачів для протоколу Intent Fusion.

В оповіданні Particle Chain уніфікований газовий токен слугує основною ціннісною пропозицією для всієї екосистеми:

• Функціонал оплати за газ - це неодноразово підтверджена логіка високого попиту та захоплення цінності в криптопросторі.
• Уніфікований газовий токен абстрагує концепцію газових шарів від існуючих публічних ланцюгових екосистем. Такої абстракції без ланцюжка частинок і гаманців неможливо досягти. Таким чином, уніфікований газовий токен являє собою реалізацію цінності для всієї екосистеми Particle. Завдяки газовому шару взаємодія користувачів, зростання і вартість нативного токена в різних ланцюжках знаходяться у взаємовигідних відносинах з уніфікованим газовим токеном.
• Уніфікований газ також є одним з рушійних факторів для досягнення безланцюгового руху. Для користувачів використання єдиної валюти значно спрощує процес використання та розуміння витрат. У майбутньому, навіть у багатоланцюговому сценарії, користувачі можуть не знати і не турбуватися про роботу базової інфраструктури. Подібно до того, як зараз у Web2 ми взаємодіємо з серверами, не переймаючись розташуванням центрів обробки даних, їх конфігурацією або мовами і базами даних, які вони використовують.
• Користувачі, імпортовані через dApps, безпосередньо розширюють можливості єдиного газового токена, пропонуючи широкий спектр варіантів використання.

Протокол злиття намірів

Зазвичай, використовуючи різні dApps, користувачам постійно доводиться обмірковувати шляхи використання:

• Якщо немає ліквідності на одному DEX, необхідно перевірити інший DEX.
• Вибір найбільш підходящого dApp в межах однієї категорії для транзакції або завдання.
• Розуміння концепції "Затвердити" перед тим, як користуватися багатьма функціями.
• Струшувати пил з гаманців, конвертувати безліч дрібних сум в конкретний токен - виснажливий процес.
• Виконання декількох кроків у різних додатках для досягнення кінцевої мети. Наприклад, при кредитуванні з високим кредитним плечем: свопінг, стейкінг, запозичення, отримання токенів, потім знову свопінг, стейкінг і запозичення.

Вищеописаний контент являє собою лише погляд на сучасний ландшафт DeFi, і в міру того, як ми переходимо до епохи широкого впровадження різноманітних додатків у Web3, складність взаємодій може значно перевершити нашу уяву.

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

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

1. Користувачі подають свої Наміри, описуючи їх певним чином, наприклад, природною мовою, у вигляді RFS (Request For Solver), який надсилається до мережі Solver. Solver - це інтерпретатор намірів, а звичайні вирішувачі, такі як 1inch, агрегатор, шукають оптимальний DEX для користувачів. Однак, у порівнянні з нашим баченням, ці розв'язувачі можуть бути недостатньо універсальними та потужними.

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

3. Підпиши намір.

4. Розв'язувач вказує конкретного Виконавця контракту на виконання і подає наміри Реактору контракту на реагування.

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

Ми можемо уявити цей процес так, ніби ви пояснюєте свої вимоги ChatGPT. Незалежно від того, наскільки складними є вимоги, він може згенерувати для вас кінцевий результат. Якщо ви задоволені результатом, ви можете використовувати його безпосередньо, не переймаючись процесом, що лежить в його основі.

Висновок

Particle Network запропонувала комплексне рішення: завдяки інтегрованій формі zkWaaS, Particle Chain і протоколу злиття намірів, вона досягає приватного входу в Web2 OAuth, приватних транзакцій, абстракції омніканального облікового запису і парадигми транзакцій, заснованої на намірах. Кожна функція вирішує частину проблемних моментів у використанні Web3. Ці вдосконалення та оптимізації слугуватимуть основою для майбутнього широкого впровадження продуктів і технологій Web3. З точки зору екосистеми та бізнес-моделей, прийняття парадигми B2B2C, використання WaaS як відправної точки для масштабування та стандартизації всього продуктового ланцюжка, спільна розбудова екосистеми з розробниками dApp та спільне створення низькопорогового світу Web3 з високим рівнем досвіду для користувачів.

Звичайно, різні проекти по-різному інтерпретують шлях реалізації для масового впровадження Web3. Окрім детального розгляду конкретних проектів, ми сподіваємося використати різні рішення, щоб висвітлити розуміння труднощів, з якими наразі стикається Web3, роздуми про потреби та больові точки користувачів, а також міркування про колективний зв'язок та розвиток всієї екосистеми.

Відмова від відповідальності:.

1. Ця стаття передрукована з[极客 Web3], всі авторські права належать оригінальному автору[雾月，极客Web3]. Якщо у вас є заперечення щодо цього передруку, будь ласка, зв'яжіться з командою Gate Learn, і вони оперативно його опрацюють.
2. Відмова від відповідальності: Погляди та думки, висловлені в цій статті, належать виключно автору і не є інвестиційною порадою.
3. Переклади статті іншими мовами виконані командою Gate Learn. Якщо не зазначено інше, копіювання, розповсюдження або плагіат перекладених статей заборонені.