Mengambil Particle Network sebagai contoh, teknologi menginterpretasikan masalah pengalaman produk Web3 saat ini

Penulis: Wuyue, Geek Web3

Pendahuluan: Meskipun dompet AA telah menurunkan ambang batas bagi pengguna untuk sebagian besar dan pada awalnya menyadari pembayaran gas dan login akun web2, desain yang terkait dengan adopsi massal, seperti login privasi - transaksi pribadi, akun AA terpadu rantai penuh, dan arsitektur khusus niat, masih perlu ditambahkan berdasarkan AA.

Meskipun kita dapat melihat banyak solusi pengoptimalan UX, seperti dompet MPC seperti ZenGo atau dompet kontrak pintar seperti Argent, yang secara efektif menurunkan ambang batas bagi pengguna, mereka hanya menyelesaikan beberapa masalah di atas, dan tidak sepenuhnya menutupi kemudahan penggunaan produk.

Jelas, sebagian besar dompet AA atau produk serupa belum dapat mendukung adopsi massal Web3. Di sisi lain, dari sudut pandang ekologi, sisi pengembang adalah level yang sangat penting, yang hanya menarik bagi pengguna biasa dalam hal produk, tetapi sulit untuk membentuk skala karena pengaruhnya yang tidak memadai di sisi pengembang. ** Munculnya semakin banyak solusi pengoptimalan pengalaman pengembangan telah menunjukkan pentingnya sisi pengembang terhadap ekosistem produk.

Kami akan mengambil Particle Network sebagai contoh untuk menjelaskan secara rinci masalah pengalaman produk Web3 saat ini, dan bagaimana merancang solusi teknis yang komprehensif, yang mungkin merupakan kondisi yang diperlukan untuk adopsi massal. Pada saat yang sama, strategi bisnis BtoBtoC Particle kebetulan merupakan ide yang perlu dipelajari oleh banyak pihak proyek. **

** Solusi lengkap struktur produk partikel **

Dengan inti memecahkan ambang penggunaan, Particle Network mengusulkan serangkaian solusi lengkap untuk adopsi Web3 skala besar dengan gagasan konstruksi produk B2B2C dan pengembangan ekologis. Modul intinya adalah tiga:

**zkWaaS, layanan Wallet-as-a-service (WaaS) berdasarkan bukti tanpa pengetahuan. **Pengembang dapat dengan cepat mengintegrasikan modul dompet pintar ke dApp mereka sendiri berdasarkan SDK yang disediakan oleh Particle. Dompet adalah dompet kontrak pintar tanpa kunci berdasarkan abstraksi akun, yang tidak hanya dapat mewujudkan skenario dasar AA seperti pembayaran gas, tetapi juga menyediakan metode login privasi OAuth gaya Web2 dan transaksi pribadi dan fungsi lainnya.

Particle Chain - Solusi Abstraksi Akun Omnichain yang didedikasikan untuk Particle, didedikasikan untuk menyelesaikan penyebaran, pemeliharaan, dan pemanggilan dompet kontrak pintar lintas rantai. Ada juga Token Gas Terpadu (Unified Gas Token) untuk mengatasi masalah penggunaan koin gas yang berbeda untuk transaksi multi-rantai.

**Intent Fusion Protocol, yang mencakup bahasa DSL (Domain Specific Language) ringkas, Intent Framework, Intent Solver Network, dll., digunakan untuk membangun satu set kerangka kerja interaksi Web3 berbasis Intent. Pengguna secara langsung menyatakan niat transaksi mereka alih-alih melakukan setiap tindakan tertentu, membebaskan pengguna dari pemikiran jalur yang rumit dan mengurangi pemahaman mereka tentang infrastruktur dasar yang kompleks.

zkWaaS - Smart Wallet-as-a-Service dikombinasikan dengan ZK

Di sisi dompet, Particle terutama menyediakan SDK untuk pengembang dApp dalam bentuk WaaS (Smart Contract Wallet-as-a-Service), untuk memungkinkan pengembang mengakses kerangka opsi massal Web3 lengkapnya. Solusi BtoBtoC ini memiliki beberapa keunggulan dari sudut pandang bisnis dan ekologi:

** Persaingan dompet C-end murni telah menjadi sangat panas, dan fungsinya relatif sama, dan dompet C-end tidak lagi menjadi titik masuk yang baik. Di sisi lain, pengembang dApp semakin cenderung membangun dompet ke dalam dApps untuk menghindari hilangnya pengalaman ketika pengguna perlu beralih dompet saat menghubungkan dompet dan transaksi, dan menyediakan fitur yang lebih dapat disesuaikan.

**Biaya akuisisi pelanggan tinggi di sisi-C, tetapi berbeda di sisi-B. **Pertumbuhan pengguna WaaS terutama didorong oleh dApps yang terintegrasi dengan SDK. Selama hubungan antara BD dan pengembang baik, seluruh ekosistem dapat diperluas dengan gaya “kota di sekitar pedesaan”.

**Saat ini, dompet C-end terutama berfokus pada keuangan dan aset, dan sulit bagi kami untuk mengatakan bahwa ini adalah skenario utama Web3 di masa depan. Untuk benar-benar mencapai adopsi massal Web3, harus ada proyek yang mengabstraksi fitur yang lebih mendasar - identitas pengguna (akun) dan operasi pengguna (mengirim transaksi / transaksi) sebagai layanan tingkat rendah, dan menyerahkan skenario yang lebih kaya dari lapisan atas ke dApp.

Dari pintu masuk koneksi dApp sebelumnya, Anda dapat mengamati hubungan pengikatan yang erat antara dompet dan dApp. ** Sangat penting untuk meningkatkan pangsa pasar dompet sebanyak mungkin di sisi dApp. Ini adalah prioritas pertama untuk model B2B2C. **

Membangun WaaS yang memenuhi kebutuhan pengguna, menurunkan hambatan masuk, dan mudah diakses oleh pengembang adalah pilar lain dari kesuksesan solusi. zkWaaS partikel memiliki tiga inti:

**1. Login Privasi. **Menggunakan metode login Web2 tradisional pada dompet kontrak, seperti Twitter, Google, login WeChat, dan metode verifikasi OAuth lainnya, pengguna dapat sepenuhnya menyingkirkan belenggu manajemen kunci pribadi dan memasuki Web3 dengan cara yang paling akrab dan sederhana. Pada saat yang sama, bukti tanpa pengetahuan digunakan untuk menyembunyikan identitas pengguna.

2. Transaksi Privasi. ** Menerapkan transfer pribadi universal peer-to-peer melalui mekanisme Smart Stealth Address, dan menggunakan ERC4337 Paymaster untuk memungkinkan Stealth Address menggunakan aset (sponsor gas) tanpa gas.

**3. Fungsi dompet AA lengkap. **Modul dompet partikel sepenuhnya mematuhi persyaratan dasar ERC-4337, termasuk Bundler, EntryPoint, Paymaster, Akun Dompet Cerdas, dan bagian penting lainnya dari alur kerja ERC-4337, satu atap untuk memenuhi persyaratan fungsional DAPP atau pengguna untuk dompet pintar.

Login privasi dompet on-chain berdasarkan akun web2

Solusi login pribadi partikel menggunakan JWT (Json Web Token), yang dapat digunakan untuk otentikasi identitas Web2 dan operasi dompet dalam kontrak.

JWT adalah sejenis sertifikat identitas yang dikeluarkan oleh server untuk klien yang banyak digunakan di Internet tradisional, dan klien bergantung pada bukti ini untuk mengotentikasi setiap kali berinteraksi dengan server.

Ada beberapa bidang utama dalam JWT yang menjadi dasar kontrak untuk memverifikasi identitas:

·" iss" (Penerbit) menunjukkan penerbit JWT, yaitu server, seperti Google, Twitter, dll.

·" aud" (Audiens) menunjukkan layanan atau aplikasi yang digunakan oleh JWT, jika Anda masuk ke Medium dengan Twitter, maka bidang ini akan menunjukkan bahwa JWT berlaku untuk Medium saat Twitter menerbitkan JWT.

·" sub" (Subjek) mengacu pada identitas pengguna yang menerima JWT, yang biasanya ditandai dengan UID.

Dalam praktiknya, ISS dan kapal selam tidak akan berubah dalam sebagian besar kasus, jika tidak maka akan membawa kekacauan besar sistem internal dan referensi eksternal. Oleh karena itu, parameter ini dapat digunakan oleh kontrak untuk menentukan identitas pengguna,** sehingga pengguna tidak perlu membuat dan menyimpan kunci pribadi sama sekali. **

Konsep yang sesuai dengan JWT adalah JWK (JSON Web Key), yang merupakan sekumpulan pasangan kunci di sisi server. Ketika server mengeluarkan JWT, server akan menandatangani dengan kunci pribadi JWK, dan kunci publik yang sesuai bersifat publik dan digunakan untuk memverifikasi tanda tangannya untuk layanan lain.

Misalnya, jika Anda masuk ke Twitter di Medium, Medium akan memverifikasi JWT dengan kunci publik JWK yang telah dipublikasikan Google untuk mengonfirmasi bahwa JWT tersebut asli — bahwa JWT memang dikeluarkan oleh Google. JWK juga digunakan untuk validasi kontrak JWT.

Alur solusi login pribadi partikel ditunjukkan pada gambar berikut:

Di antara mereka, kami akan melewati sirkuit ZK tertentu di sini. Buat daftar hanya beberapa poin penting dalam proses:

**Kontrak Verifier yang memverifikasi informasi login hanya akan melihat Bukti ZK yang terkait dengan identitas pengguna-JWT, serta eph_pk yang tidak berbahaya, dan tidak dapat secara langsung mendapatkan kunci publik dompet atau informasi JWT yang sesuai, untuk melindungi privasi pengguna, dan dunia luar tidak dapat mengetahui identitas orang yang login dari data on-chain. **

Eph_pk (pasangan kunci sementara) adalah pasangan kunci yang digunakan dalam satu sesi, bukan kunci publik atau pribadi dompet, dan pengguna tidak perlu peduli.

Sistem ini juga dapat digunakan untuk verifikasi off-chain, dan dapat digunakan untuk dompet kontrak yang menggunakan logika seperti MPC.

Karena ini adalah skema verifikasi kontrak sejati berdasarkan login tradisional, pengguna juga dapat menunjuk kontak sosial lain sebagai wali mereka jika terjadi situasi yang sangat ekstrem seperti pembatalan akun Web2.

Transaksi pribadi berdasarkan metode pertukaran kunci DH

Sebelum berbicara tentang solusi transaksi pribadi Particle, pertama-tama mari kita periksa bagaimana mencapai transaksi pribadi ke penerima dalam sistem EVM yang ada, yaitu, menyembunyikan alamat penerima.

Mari kita asumsikan bahwa Alice adalah pengirim dan Bob adalah penerima, dan kita memiliki beberapa pengetahuan umum:

1. Bob menghasilkan kunci pengeluaran root m dan meta-address stealth M. M dapat dihasilkan oleh m, dan hubungan antara keduanya adalah M = G * m, yang mewakili hubungan matematis dalam operasi kriptografi.

2. Alice mendapatkan alamat meta siluman Bob M dengan cara apa pun.

3. Alice menghasilkan kunci pribadi sementara r, dan menggunakan generate_address algoritmik (r,M) untuk menghasilkan alamat tersembunyi A. **Alamat ini adalah alamat siluman berdarah eksklusif Bob, dan Bob memiliki kendali atas alamat tersebut setelah menerima aset. **

4. Alice kemudian menghasilkan kunci publik sementara R berdasarkan kunci privat sementara r dan mengirimkannya ke kontrak catatan kunci publik sementara (atau lokasi yang disepakati bersama, apa pun salurannya selama Bob dapat memperolehnya).

5. Bob perlu memindai kontrak catatan kunci publik sementara secara berkala dan mencatat setiap kunci publik sementara yang diperbarui. Karena kontrak kunci publik sementara bersifat publik dan berisi kunci yang terkait dengan transaksi pribadi yang dikirim oleh orang lain, Bob tidak tahu yang mana yang dikirim Alice kepadanya.

6. Bob memindai setiap catatan yang diperbarui dan melakukan generate_address (R,m) untuk menghitung alamat yang disunting. Jika ada aset di alamat, itu dihasilkan oleh Alice dan diizinkan untuk dikendalikan oleh Bob, jika tidak, itu tidak ada hubungannya dengan Bob.

7. Bob mengeksekusi generate_spending_key (R, m) untuk menghasilkan kunci pribadi konsumen untuk alamat siluman, yaitu p = m + hash (A), dan kemudian dapat mengontrol alamat A yang dihasilkan oleh Alice.

Deskripsi proses di atas sebenarnya menyederhanakan banyak operasi matematika yang kompleks, ** Seluruh proses pertukaran intelijen seperti dua mata-mata yang menuliskan beberapa kata kode yang hanya dapat diuraikan satu sama lain di papan buletin publik, ** Meskipun metode pembuatan dan dekripsi kata-kata kode bersifat publik, hanya dua mata-mata yang mengetahui data penting yang diperlukan di tengah, jadi meskipun dunia luar mengetahui metode pembuatan dan dekripsi kata-kata kode, mereka masih tidak dapat didekripsi dengan lancar.

Proses pertukaran ini hampir sama dengan metode pertukaran kunci Diffie-Hellman yang terkenal, di mana kedua belah pihak dapat menghitung rahasia bersama – Alamat Tersembunyi A di atas – tanpa mengungkapkan rahasia masing-masing (kunci pribadi konsumen root Bob m dan kunci pribadi sementara Alice r). **Jika Anda tidak tahu tentang pertukaran DH, Anda dapat menggunakan diagram pewarnaan berikut untuk memahaminya secara metaforis.

Langkah tambahan dibandingkan dengan DH adalah bahwa setelah masing-masing dari mereka mengetahui alamat A yang disunting rahasia bersama, mereka tidak dapat menggunakannya sebagai kunci pribadi, karena Alice juga mengenal A. Penting untuk membangun kunci pribadi konsumen p = m + hash (A), dan memperlakukan A sebagai kunci publik. Seperti disebutkan sebelumnya, kunci pribadi konsumen root m hanya diketahui oleh Bob, jadi Bob menjadi satu-satunya pengontrol alamat siluman. **

Jelas, dengan metode transfer pribadi ini, setiap kali penerima menerima transaksi baru, dana untuk transaksi itu akan mengalir ke alamat EOA baru. Penerima dapat menggunakan kunci privat konsumsi root untuk menghitung kunci privat konsumsi setiap alamat secara terpisah untuk melihat mana yang benar-benar terkait dengannya.

Tapi sekarang ada masalah lain, alamat siluman yang baru dibuat ini masih merupakan akun EOA di awal, mungkin tidak ada token gas seperti ETH di atasnya, Bob tidak memiliki cara untuk memulai transaksi secara langsung, ** perlu menggunakan fungsi Paymaster dari dompet kontrak pintar untuk pembayaran gas, untuk mencapai transaksi pribadi. **Oleh karena itu, perlu untuk membuat beberapa perubahan pada alamat penerima:

Hitung alamat kontrafaktual menggunakan metode perhitungan alamat dalam metode CREATE2 ketika kontrak digunakan, dengan parameter yang sesuai (mengatur alamat siluman A sebagai pemilik kontrak, dll.). Ini adalah alamat kontrak yang dihitung, tetapi kontrak belum digunakan, dan masih EOA untuk saat ini.

**Alice akan mentransfer uang langsung ke alamat Counterffact. **Ketika Bob ingin menggunakannya, dia dapat membuat dompet kontrak langsung di alamat ini, sehingga dia dapat menghubungi layanan pembayaran gas (langkah ini juga dapat dilakukan oleh jaringan Alice atau Particle atas namanya).

Kita dapat menyebut alamat Counterfactual di atas sebagai alamat siluman yang cerdas. Bob menggunakan proses berikut untuk menggunakan aset secara anonim di bawah alamat Smart Cloak:

Isi ulang Paymaster melalui salah satu alamat Anda sendiri, dan Paymaster akan mengembalikan bukti dana (ZK).

Dengan mekanisme AA, kirim UserOperation ke node Bundler dengan alamat lain (tidak dapat memiliki saldo) untuk memanggil aset di bawah alamat tersembunyi di atas. Bob hanya memberikan bukti dana kepada Paymaster dengan alamat baru, dan Paymaster membayar untuk transaksi pengemasan Bundler.

Ini sebenarnya mirip dengan cara kerja Tornado Cash, melalui proof-of-fund (ZK), yang dapat membuktikan bahwa ada top-up di set simpul daun di pohon Merkle, dan tidak ada yang tahu simpul daun mana yang dikonsumsi saat dihabiskan, sehingga dapat memutuskan hubungan antara konsumen dan deposan.

Singkatnya, Particle menggabungkan AA dan alamat tersembunyi, dan dengan cerdik mewujudkan transfer pribadi dalam bentuk dompet tersembunyi yang cerdas.

Abstraksi Akun Rantai Partikel & Rantai Penuh

Particle Chain adalah rantai POS yang dirancang untuk Omnichain Account Abstraction. Berfokus pada situasi saat ini dan masa depan, tidak mungkin menjadi dunia rantai tunggal, dan sangat penting untuk meningkatkan pengalaman pengguna dalam lingkungan kerja multi-rantai.

Saat ini sistem abstraksi akun ERC4337 akan memiliki masalah tertentu dalam kasus multi-chain:

Alamat pengguna yang sama dalam rantai yang berbeda mungkin tidak seragam, tergantung pada desain kontrak.

Pengguna perlu mengulangi operasi manajemen secara manual antara beberapa rantai untuk mengelola dompet kontrak pada rantai yang berbeda, seperti mengubah administrator. Lebih buruk lagi, jika hak administrator diperbarui pada satu rantai dan kemudian metode otentikasi admin lama dibuang, dompet tidak dapat diubah pada rantai lain.

Untuk menggunakan rantai yang berbeda, Anda harus memiliki koin gas di setiap rantai, atau memiliki dana yang disetorkan sebelumnya di Paymaster di setiap rantai. Ada juga sejumlah masalah bagi pengembang, jika mereka ingin pengguna menggunakan atau mengimplementasikan fungsi lain tanpa biaya dalam kondisi tertentu, mereka juga perlu menerapkan Paymaster kustom mereka sendiri di setiap rantai dan menyetor dana di dalamnya.

** Abstraksi akun rantai penuh Particle Chain membahas titik-titik nyeri di atas: **

Buat dompet AA di Particle Chain.

Melalui protokol lintas rantai AMB (Arbitrary Message Bridge) seperti LayerZero, berbagai operasi, seperti pembuatan baru, peningkatan, perubahan izin, dll., Disinkronkan ke rantai lain. ** Dapat dipahami bahwa dompet lain pada rantai adalah referensi ke dompet pada rantai, dan hanya badan utama yang perlu dimodifikasi untuk disinkronkan ke semua dompet.

**Kontrak Deployer dengan parameter yang konsisten untuk memastikan bahwa alamat dompet pada setiap chain sama. **

Dompet antar rantai juga dapat saling memanggil melalui AMB, tidak semuanya dimulai dari Particle Chain.

**Penerbitan Token Gas Terpadu, koin gas rantai penuh. **ERC20 diimplementasikan oleh mekanisme Paymaster sebagai biaya gas. Bahkan jika tidak ada gas atau dana pra-deposit Paymaster pada rantai tertentu, Anda dapat memulai transaksi lintas rantai pada rantai yang memenuhi syarat untuk menggunakan Token Gas Terpadu.

Selain penggunaan di atas, Rantai Partikel juga dapat digunakan di masa depan:

Jaringan terdesentralisasi yang dihasilkan oleh zkWaaS’s Proof and Salt.

Lapisan insentif dari setiap rantai Bundler membantu Bundler mencapai desentralisasi yang lebih baik.

Jaringan Solver sebagai Intent Fusion Protocol.

** Dalam narasi Particle Chain, Token Gas Terpadu adalah pegangan nilai inti dari seluruh ekosistem: **

Fungsi membayar biaya gas adalah permintaan yang kuat dan logika penangkapan nilai yang telah berulang kali diverifikasi dalam crypto.

Token Gas Terpadu mengabstraksi konsep lapisan gas dari ekologi rantai publik yang ada, dan abstraksi ini tidak dapat dicapai tanpa Rantai Partikel dan dompet, sehingga Token Gas Terpadu adalah penarikan nilai dari seluruh ekologi Partikel. Dengan lapisan gas, interaksi pengguna dan pertumbuhan setiap rantai dan nilai mata uang lokal saling menguntungkan dan bersimbiosis dengan Token Gas Terpadu.

Unified gas juga menjadi salah satu faktor pendorong terwujudnya Chainless. Bagi pengguna, membayar dalam mata uang tunggal sangat menyederhanakan proses dan memahami biaya. Di masa depan, bahkan dalam skenario multi-rantai, pengguna cenderung tidak peka, dan tidak perlu peduli dengan pengoperasian infrastruktur yang mendasarinya. Sama seperti saat ini di Web2, kami tidak peduli di wilayah mana ruang komputer berada, konfigurasi apa, bahasa apa yang digunakan, dan database apa yang berfungsi.

Pengguna yang diimpor oleh dApp secara langsung memberdayakan Token Gas Terpadu, dan skenario penggunaannya sangat kaya.

Protokol Fusi Maksud

** Biasanya, kita perlu terus-menerus memikirkan jalur penggunaan saat menggunakan berbagai dApps: **

Jika tidak ada likuiditas pada satu DEX, Anda perlu melihat DEX lain.

Saya tidak tahu dApp mana dari kategori yang sama yang harus dipilih untuk menyelesaikan transaksi atau transaksi dengan lebih baik.

· Approve kemudian memiliki banyak fitur untuk digunakan, dan apa yang disetujui?

Dompet debu, beberapa token kecil ke dalam mata uang tertentu, prosesnya rumit.

Untuk mencapai tujuan akhir, dibutuhkan beberapa aplikasi. Seperti pinjaman leverage tinggi: swap, pledge, borrow, get Token dan kemudian swap, pledge, borrow…

Hal di atas hanyalah puncak gunung es di dunia DeFi kita saat ini, dan di era adopsi massal Web3 di mana dApps menjadi lebih beragam, interaksi bisa jauh lebih kompleks daripada yang Anda pikirkan.

Oleh karena itu, mengganti langkah-langkah operasi tertentu dengan maksud maksud bisa sangat berbeda untuk pengalaman pengguna. Maksud lebih dari sekadar operasional, sama seperti pemrograman deklaratif adalah pemrograman fungsional. Pernyataan deklaratif cenderung terasa sederhana dan lugas, cukup nyatakan apa yang akan saya lakukan dan tidak peduli dengan detailnya, dan ini membutuhkan berbagai pernyataan pemrograman fungsional yang dikemas di bagian bawah.

Maka penggunaan Intents tidak terkecuali, dan itu juga perlu didukung oleh berbagai fasilitas. Mari kita lihat keseluruhan prosesnya:

**1. Pengguna mengirimkan ke jaringan Solver dalam bentuk RFS (Request For Solver), seperti bahasa alami. ** Solver adalah penerjemah niat, dan ada agregator seperti 1inch yang dapat menemukan dex terbaik untuk pengguna, tetapi mereka tidak generik dan cukup kuat dibandingkan dengan visi kami.

**2. Beberapa Solver saling merespons, dan mereka bersaing. Tanggapan ini ditulis dalam bahasa DSL Intent dan diuraikan oleh klien ke dalam bentuk yang mudah dipahami pengguna. Tanggapan ini terdiri dari Kendala Input dan Kendala Output, yang menentukan batas antara input dan output. Pengguna juga dapat menentukan batasan mereka sendiri. Contoh sederhana untuk dipahami: saat menggunakan Swap, pengguna akan diminta ke jumlah minimum yang dapat diperoleh setelah swapping, yang merupakan kendala. Pengguna memilih di antara respons beberapa Solver sendiri.

3. Tanda tangani niat.

**4.Solver menentukan utor kontrak eksekusi tertentu dan menyerahkan maksud ke Reaktor kontrak respons. **

5. Reaktor mengumpulkan input yang diperlukan (seperti aset) dari akun pengguna, mengajukan maksud ke utor, dan kemudian memanggil kontrak logis yang relevan untuk mengembalikan output transaksi ke Reaktor. Reaktor memeriksa kendala dan mengembalikan output ke pengguna jika sudah benar.

Kami dapat memikirkan proses ini saat Anda memberi tahu ChatGPT tentang persyaratannya, tidak peduli seberapa rumit persyaratannya, ia dapat memberikan hasil akhir untuk Anda, selama Anda puas dengan hasilnya, Anda dapat menggunakannya secara langsung, tanpa peduli dengan prosesnya.

Ringkasan

Particle Network mengusulkan solusi komprehensif: melalui trinitas zkWaaS, Particle Chain, dan Intent Fusion Protocol, login privasi Web2 OAuth, transaksi pribadi, abstraksi akun rantai penuh, dan paradigma transaksi niat direalisasikan. Setiap fitur akan mencakup beberapa poin rasa sakit dari penggunaan Web3, dan kemajuan serta pengoptimalan ini akan menjadi fondasi produk dan teknologi untuk adopsi massal Web3 di masa depan. Dalam hal ekologi dan model bisnis, paradigma B2B2C diadopsi, WaaS digunakan sebagai pintu masuk untuk mendorong standardisasi skala besar dari seluruh rantai produk, dan ekosistem dibangun dengan pengembang dApp untuk bersama-sama menciptakan dunia Web3 dengan ambang batas rendah dan pengalaman tinggi bagi pengguna.

Tentu saja, proyek yang berbeda memiliki pemahaman yang berbeda tentang jalur implementasi adopsi massal Web3. Selain meninjau proyek-proyek tertentu, kami berharap dapat mengarah pada pemahaman tentang gesekan onboard yang dihadapi Web3 saat ini, refleksi pada kebutuhan pengguna dan poin rasa sakit, dan pertimbangan untuk koneksi bersama dan pengembangan seluruh ekosistem.