На прикладі Particle Network технологія інтерпретує проблеми досвіду поточних продуктів Web3

Автор: Вуюе, 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. Гаманець — це гаманець смарт-контрактів без ключа, заснований на абстракції облікового запису, який може не тільки реалізовувати базові сценарії АА, такі як оплата газу, але й надавати методи входу в конфіденційність OAuth у стилі Web2, приватні транзакції та інші функції.

Particle Chain - рішення Omnichain Account Abstraction, призначене для Particle, призначене для вирішення крос-чейн розгортання, обслуговування та виклику гаманців смарт-контрактів. Існує також Unified Gas Token (Unified Gas Token) для вирішення проблеми використання різних газових монет для багатоланцюгових транзакцій.

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

zkWaaS – Smart Wallet-as-a-Service у поєднанні з ZK

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

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

**Вартість залучення клієнта висока на стороні C, але вона відрізняється на стороні B. ** Зростання кількості користувачів WaaS в основному зумовлене dApps, інтегрованими з 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. Повна функція гаманця АА. **Модуль гаманця Particle повністю відповідає основним вимогам ERC-4337, включаючи Bundler, EntryPoint, Paymaster, обліковий запис Smart Wallet та інші важливі частини робочих процесів ERC-4337, єдине вікно для задоволення функціональних вимог DAPP або користувачів для розумних гаманців.

Вхід у конфіденційність ончейн-гаманця на основі облікових записів web2

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

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

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

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

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

·" sub" (Суб’єкт) відноситься до особистості користувача, який приймає JWT, який зазвичай позначається UID.

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

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

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

Потік приватного рішення для входу в систему Particle показаний на наступному малюнку:

Серед них ми пропустимо тут конкретну схему ЗК. Перерахуємо лише деякі ключові моменти процесу:

**Контракт Verifier, який перевіряє інформацію для входу, сприймає лише 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). **Якщо ви не знаєте про обмін ГД, ви можете скористатися наступною діаграмою фарбування, щоб зрозуміти це метафорично.

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

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

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

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

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

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

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

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

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

Підводячи підсумок, можна сказати, що Particle поєднує в собі АА і приховані адреси, а також спритно реалізує приватні перекази у вигляді розумних прихованих гаманців.

Абстракція ланцюга частинок і повного ланцюга

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

В даний час 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.

Стимулюючий рівень кожного ланцюга 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.

Я не знаю, який dApp тієї ж категорії вибрати, щоб краще завершити транзакцію або транзакцію.

· Тоді Approve має багато функцій для використання, а що таке approve?

Запилення гаманця, кілька дрібних токенів у певну валюту, процес громіздкий.

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

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

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

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

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

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

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

**4.Розв’язувач вказує конкретний контракт на виконання та передає намір реактору контракту-відповіді. **

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

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

Підсумки

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

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