Analisis Teknis: Lapisan Akses Web Terbuka yang dibangun oleh Jaringan Partikel

Pendahuluan: Meskipun dompet AA telah secara signifikan menurunkan hambatan masuk pengguna dan mencapai pembayaran gas dan login akun web2, aspek-aspek yang terkait dengan adopsi massal, seperti login rahasia, transaksi rahasia, omnichain AA, dan protokol fusi niat, masih memerlukan pengembangan lebih lanjut pada dasar AA.

Meskipun kami melihat berbagai solusi pengoptimalan UX seperti dompet MPC ZenGo atau dompet kontrak pintar seperti Argent secara efektif mengurangi hambatan pengguna, solusi tersebut hanya menangani sebagian dari masalah yang disebutkan di atas, tanpa sepenuhnya mencakup masalah kegunaan produk secara keseluruhan.

Jelas, sebagian besar dompet AA atau produk serupa belum dapat mendukung adopsi Web3 secara luas. Di sisi lain, dari perspektif ekosistem, sisi pengembang adalah aspek yang sangat penting. Daya tarik bagi pengguna biasa saja, tanpa dampak yang cukup pada sisi pengembang, tidak mungkin mencapai skalabilitas. Munculnya lebih banyak solusi pengoptimalan pengalaman pengembang menunjukkan semakin pentingnya sisi pengembang dalam ekosistem produk.

Mengambil Particle Network sebagai contoh, kami akan menguraikan tantangan UX saat ini yang dihadapi oleh produk Web3 dan mendiskusikan cara merancang solusi teknis yang ditargetkan dan komprehensif. Solusi terintegrasi semacam ini mungkin merupakan syarat yang diperlukan untuk adopsi massal. Selain itu, strategi bisnis BtoBtoC Particle berfungsi sebagai pendekatan penting yang mungkin bermanfaat bagi banyak tim proyek.

Perincian Struktur Produk Partikel

Particle Network, dengan fokus utamanya pada penurunan hambatan penggunaan, mengadopsi konstruksi produk B2B2C dan pendekatan pengembangan ekologi, memberikan solusi komprehensif untuk adopsi Web3 secara luas. Modul intinya terdiri dari tiga komponen utama:

zkWaaS mengacu pada dompet tanpa pengetahuan sebagai layanan. Pengembang dapat dengan cepat mengintegrasikan modul dompet pintar ke dalam dApps mereka menggunakan SDK Particle. Dompet ini adalah dompet kontrak pintar tanpa kunci yang didasarkan pada abstraksi akun, memungkinkan pembayaran gas dan menawarkan login rahasia OAuth gaya Web2 dan transaksi rahasia.

Particle Chain - Skema Abstraksi Akun Omnichain khusus yang dirancang untuk Particle bertujuan untuk mengatasi tantangan penyebaran, pemeliharaan, dan pemanggilan lintas rantai untuk dompet kontrak pintar. Ini juga mencakup Token Gas Terpadu, menyederhanakan penggunaan token gas yang berbeda dalam transaksi multi-rantai.

Protokol Fusi Intent - Termasuk Domain-Specific Language (DSL) yang ringkas, kerangka kerja Intent, Intent Solver Network, dll., untuk membangun kerangka kerja interaksi Web3 berdasarkan maksud. Pengguna menyatakan maksud transaksi mereka secara langsung daripada mengeksekusi setiap operasi tertentu, membebaskan mereka dari pertimbangan jalur yang rumit dan mengurangi kebutuhan untuk memahami infrastruktur dasar yang kompleks.

zkWaaS - Dompet Nol-Pengetahuan sebagai Layanan

Di sisi dompet, Particle terutama menyediakan SDK untuk pengembang dApp dalam bentuk Wallet-as-a-Service (WaaS). Tujuannya adalah untuk memungkinkan para pengembang berintegrasi ke dalam kerangka kerja adopsi massal Web3 yang komprehensif. Pendekatan BtoBtoC ini memiliki beberapa keuntungan baik dari segi bisnis maupun ekosistem:

Pasar dompet konsumen sangat kompetitif, dan fungsinya menjadi semakin mirip. Dompet konsumen tidak lagi menjadi titik masuk yang optimal. Di sisi lain, pengembang dApp lebih suka mengintegrasikan dompet dalam aplikasi mereka untuk meningkatkan pengalaman pengguna dan menyediakan lebih banyak fitur yang dapat disesuaikan.

Mendapatkan pengguna di sisi konsumen memang mahal, tetapi dari sisi bisnis berbeda. Pertumbuhan pengguna WaaS terutama berasal dari dApps yang terintegrasi dengan SDK. Dengan pengembangan bisnis dan hubungan pengembang yang efektif, ekosistem dapat berkembang secara organik.

Dompet konsumen saat ini terutama berfokus pada keuangan dan aset, yang mungkin tidak mewakili skenario utama untuk masa depan Web3. Untuk mencapai adopsi Web3 secara luas, fitur-fitur dasar seperti identitas pengguna (akun) dan operasi pengguna (inisiasi transaksi) harus diabstraksikan sebagai layanan dasar, sehingga skenario yang lebih kaya dapat ditangani oleh dApps.

Secara historis, titik masuk untuk dApps telah menunjukkan hubungan yang erat antara dompet dan dApps. Meningkatkan pangsa pasar dompet di sisi dApp sangat penting. Hal ini sangat menguntungkan untuk model B2B2C.

Untuk membangun solusi yang memenuhi kebutuhan pengguna, menurunkan hambatan masuk, dan memfasilitasi integrasi pengembang, zkWaaS dari Particle berfungsi sebagai komponen penting dengan tiga fitur inti:

1. Login Rahasia: Memanfaatkan metode login Web2 tradisional seperti verifikasi OAuth dari platform seperti Twitter, Google, WeChat, dll., pada dompet kontrak pintar. Hal ini memungkinkan pengguna untuk sepenuhnya membebaskan diri mereka dari batasan manajemen kunci privat, memasuki Web3 dengan cara yang paling akrab dan mudah. Secara bersamaan, identitas pengguna disembunyikan dengan menggunakan bukti tanpa pengetahuan.

2. Transaksi Rahasia: Menerapkan transfer privasi point-to-point melalui mekanisme Smart Stealth Address, memastikan privasi universal dalam transaksi. Selain itu, dengan menggunakan Paymaster ERC-4337, memungkinkan penggunaan aset tanpa gas untuk Smart Stealth Addresses (sponsor gas).

3. Fungsionalitas Dompet AA yang Komprehensif: Modul dompet Particle sepenuhnya sesuai dengan persyaratan dasar ERC-4337. Ini mencakup komponen penting seperti Bundler, EntryPoint, Paymaster, Akun Dompet Cerdas, dan banyak lagi, yang mencakup semua aspek penting dari alur kerja ERC-4337. Solusi satu atap ini secara efektif memenuhi tuntutan fungsional DApps atau pengguna untuk dompet pintar.

Login Rahasia untuk Dompet On-Chain Berdasarkan Akun Web2

Solusi login rahasia Particle menggunakan JSON Web Tokens (JWT), yang memungkinkan otentikasi identitas Web2 dan operasi dompet dalam kontrak pintar.

JWT adalah bentuk bukti identitas yang banyak digunakan dalam aplikasi internet tradisional, yang dikeluarkan oleh server ke klien. Klien menggunakan bukti ini untuk otentikasi identitas dalam setiap interaksi dengan server.

(Sumber: Dokumen FlutterFlow)

Ada beberapa bidang utama dalam JWT yang menjadi dasar verifikasi identitas menurut kontrak:

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

- "aud" (Penonton): Menentukan layanan atau aplikasi yang menjadi tujuan JWT. Misalnya, saat masuk ke Medium menggunakan Twitter, JWT yang dikeluarkan oleh Twitter akan menyertakan bidang ini yang menunjukkan penerapannya di Medium.

-"sub" (Subjek): Mengacu pada identitas pengguna yang menerima JWT, biasanya diidentifikasi dengan UID.

Dalam praktiknya, "iss" dan "sub" umumnya tetap konstan untuk menghindari kebingungan substansial antara sistem internal dan referensi eksternal. Oleh karena itu, parameter ini dapat digunakan oleh kontrak untuk menentukan identitas pengguna, sehingga pengguna tidak perlu lagi membuat dan menjaga private key.

Sejalan dengan JWT adalah konsep JSON Web Key (JWK), satu set pasangan kunci pada server. Ketika mengeluarkan JWT, server menandatanganinya dengan kunci privat JWK, sementara kunci publik yang sesuai dibuat publik untuk layanan lain untuk memverifikasi tanda tangan.

Misalnya, ketika Medium menggunakan Twitter untuk login, Medium akan memvalidasi JWT menggunakan JWK publik Google untuk mengonfirmasi keasliannya - bahwa JWT tersebut memang dikeluarkan oleh Google. Verifikasi kontrak JWT juga akan melibatkan penggunaan JWK.

Proses solusi login rahasia Particle digambarkan dalam diagram di bawah ini:

Kami akan melewatkan sirkuit ZK yang spesifik di sini, hanya menyoroti beberapa poin penting dalam prosesnya:

Kontrak Verifikator yang memvalidasi informasi login hanya akan melihat ZK Proof yang terkait dengan identitas pengguna JWT dan eph_pk. Ia tidak dapat secara langsung mendapatkan kunci publik dompet yang sesuai atau informasi JWT, memastikan privasi pengguna, dan mencegah entitas eksternal untuk mengidentifikasi pengguna yang masuk dari data on-chain.

eph_pk (pasangan kunci sementara) adalah pasangan kunci yang digunakan dalam satu sesi dan bukan merupakan pasangan kunci publik-privat dompet. Pengguna tidak perlu mengkhawatirkan hal itu.

Sistem ini mendukung verifikasi off-chain dan dapat digunakan untuk dompet kontrak yang menggunakan logika seperti MPC (Multiparty Computation).

Karena ini adalah solusi verifikasi kontrak yang benar-benar didasarkan pada metode login tradisional, pengguna juga dapat menunjuk kontak sosial lain sebagai wali dalam kasus-kasus ekstrem, seperti akun Web2 yang dinonaktifkan.

Transaksi Rahasia Berdasarkan Pertukaran Kunci DH

Sebelum membahas transaksi rahasia Particle, mari kita lihat bagaimana cara mencapai transaksi rahasia untuk penerima dalam sistem EVM yang ada, khususnya menyembunyikan alamat penerima.

Dengan mengasumsikan Alice sebagai pengirim dan Bob sebagai penerima, kedua belah pihak memiliki pengetahuan yang sama:

1. Bob menghasilkan kunci pengeluaran root (m) dan sebuah meta-address siluman (M). M dapat dihasilkan oleh m, dan hubungan mereka diwakili oleh M = G * m, yang mengindikasikan sebuah hubungan matematis dalam operasi kriptografi.

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

3. Alice menghasilkan kunci pribadi sementara (r) dan menggunakan algoritma generate_address(r, M) untuk membuat alamat siluman (A). Alamat ini berfungsi sebagai alamat siluman khusus yang disiapkan untuk Bob, dengan Bob mendapatkan kendali setelah aset diterima.

4. Alice membuat sebuah ephemeral pubkey (R) berdasarkan pada kunci privat r yang bersifat sementara dan mengirimkannya ke kontrak perekaman ephemeral pubkey (atau lokasi yang telah disepakati bersama yang dapat diakses oleh Bob).

5. Bob secara berkala memindai kontrak rekaman pubkey fana, merekam setiap pubkey fana yang diperbarui. Karena kontrak pubkey sementara bersifat publik dan berisi kunci yang terkait dengan transaksi privasi yang dikirim oleh orang lain, Bob tidak tahu yang mana yang dikirim Alice untuk dilihatnya.

6. Bob memindai setiap record yang diperbarui, mengeksekusi generate_address(R, m) untuk menghitung alamat siluman. Jika ada aset di alamat tersebut, itu berarti Alice membuat dan mengesahkannya untuk kontrol Bob; jika tidak, itu tidak relevan bagi Bob.

7. Bob mengeksekusi generate_spending_key(R, m) untuk menghasilkan kunci pengeluaran untuk alamat siluman tersebut, yaitu, p = m + hash(A). Kemudian, Bob dapat mengontrol alamat A yang dihasilkan oleh Alice.

Proses yang dijelaskan menyederhanakan banyak operasi matematika yang rumit. Seluruh proses pertukaran informasi mirip dengan dua agen rahasia yang menulis pesan rahasia di papan buletin publik, pesan yang hanya dapat diuraikan oleh satu sama lain. Meskipun metode pembuatan dan dekripsi pesan-pesan ini bersifat publik, data penting yang diperlukan untuk kedua agen hanya diketahui oleh mereka. Akibatnya, bahkan jika orang luar memahami metodenya, dekripsi yang berhasil tetap sulit dipahami.

Proses pertukaran ini agak mirip dengan metode pertukaran kunci Diffie-Hellman yang terkenal. Tanpa mengungkapkan rahasia mereka (kunci pengeluaran akar Bob (m) dan kunci pribadi sementara Alice (r)), kedua belah pihak dapat menghitung rahasia bersama - alamat siluman (A) yang telah disebutkan sebelumnya. Jika tidak terbiasa dengan pertukaran DH, pemahaman metaforis dapat difasilitasi dengan menggunakan diagram di bawah ini.

Sebuah langkah tambahan dibandingkan dengan DH adalah, setelah menghitung rahasia bersama - alamat siluman (A), alamat tersebut tidak dapat digunakan sebagai kunci privat secara langsung karena Alice juga mengetahui A. Hal ini diperlukan untuk membuat kunci pengeluaran (p = m + hash (A)) yang memperlakukan A sebagai kunci publik. Seperti yang telah disebutkan sebelumnya, hanya Bob yang mengetahui kunci pengeluaran root (m), membuat Bob menjadi satu-satunya pengendali alamat siluman ini.

Jelas, dalam metode transfer privasi ini, untuk setiap transaksi baru yang diterima, dana akan mengalir ke alamat EOA yang baru. Penerima dapat menggunakan kunci pengeluaran root untuk menghitung kunci pengeluaran secara berulang-ulang untuk setiap alamat, bereksperimen untuk menemukan kunci pengeluaran yang benar-benar terkait dengan alamat tersebut.

Namun demikian, masih ada masalah. Pada awalnya, alamat siluman yang baru dibuat ini masih berupa akun EOA dan mungkin tidak memiliki ETH atau token gas lainnya. Bob tidak dapat memulai transaksi secara langsung dan perlu menggunakan Paymaster dari dompet kontrak pintar untuk pembayaran gas untuk mencapai transaksi rahasia. Oleh karena itu, diperlukan beberapa modifikasi untuk alamat penerima:

Dengan menggunakan metode penghitungan alamat dari fungsi CREATE2 selama penerapan kontrak, bersama dengan parameter yang sesuai (menetapkan alamat siluman A sebagai pemilik kontrak, dll.), Hitung alamat Kontrafaktual. Ini adalah alamat kontrak yang dihitung yang belum digunakan, saat ini merupakan EOA.

Alice secara langsung mentransfer dana ke alamat Konterfaktual ini. Ketika Bob ingin menggunakannya, dia langsung membuat dompet kontrak di alamat ini, memungkinkan pemanggilan layanan pembayaran gas (langkah ini juga dapat ditangani oleh Alice atau jaringan Partikel sebelumnya).

Kita bisa menyebut alamat Konterfaktual yang disebutkan di atas sebagai Alamat Siluman Cerdas. Bob secara anonim menggunakan aset di bawah Alamat Siluman Cerdas ini melalui proses berikut:

-Menyetor Paymaster dari salah satu alamatnya, dan Paymaster akan mengembalikan bukti dana (berbasis ZK).

-Dengan mekanisme AA, gunakan alamat lain, yang mungkin tidak memiliki saldo, untuk mengirim UserOperation ke node Bundler, memanggil aset di bawah alamat siluman yang disebutkan. Bob hanya perlu memberikan bukti dana kepada Paymaster menggunakan alamat baru, dan Paymaster membayar Bundler untuk pengemasan transaksi.

Proses ini mirip dengan cara kerja Tornado Cash. Bukti dana (berbasis ZK) dapat membuktikan bahwa sebuah pengisian ulang terjadi pada himpunan simpul daun pada pohon Merkle. Namun, ketika menghabiskan dana, tidak ada yang dapat menentukan dana node daun tertentu yang dikonsumsi, sehingga memutuskan hubungan antara konsumen dan pengisi daya.

Singkatnya, Particle menggabungkan AA dengan alamat siluman dengan cerdik, mencapai transfer rahasia melalui bentuk dompet siluman yang cerdas.

Rantai Partikel & Abstraksi Akun Omnichain

Particle Chain adalah rantai POS yang dirancang untuk Abstraksi Akun Omnichain. Mempertimbangkan masa kini dan masa depan, dominasi rantai tunggal tidak mungkin terjadi. Meningkatkan pengalaman pengguna dalam skenario multi-rantai sangat penting.

Saat ini, sistem abstraksi akun ERC4337 mungkin mengalami masalah tertentu dalam situasi multi-rantai:

• Alamat pengguna yang sama pada rantai yang berbeda mungkin tidak seragam, tergantung pada desain kontrak.
• Mengelola dompet kontrak rantai yang berbeda membutuhkan operasi manual di beberapa rantai, seperti mengganti administrator. Dalam skenario yang lebih buruk, jika izin administrator diperbarui pada satu chain, diikuti dengan membuang metode validasi administrator yang lama, maka tidak mungkin untuk melakukan perubahan pada chain lainnya, sehingga wallet tidak dapat digunakan.
• Menggunakan rantai yang berbeda membutuhkan token gas untuk setiap rantai, atau dana yang telah disimpan sebelumnya di Paymaster setiap rantai. Bagi para pengembang, hal ini bisa merepotkan. Jika mereka ingin pengguna menggunakan kondisi tertentu dengan biaya nol atau menerapkan fungsi lain, mereka perlu menerapkan Paymaster khusus mereka pada setiap rantai dan mendanainya terlebih dahulu.

Abstraksi Akun Omnichain dari Particle Chain mengatasi masalah di atas:

• Buat dompet AA di Particle Chain.
• Gunakan LayerZero dan protokol lintas rantai Arbitrary Message Bridge (AMB) lainnya untuk menyinkronkan berbagai operasi, seperti membuat, meningkatkan, dan mengubah izin, ke rantai lain. Hal ini dapat dipahami sebagai dompet pada rantai lain yang menjadi referensi ke dompet pada rantai tersebut, dengan modifikasi pada badan utama yang disinkronkan ke semua dompet.
• Memastikan alamat yang seragam untuk dompet di setiap rantai melalui parameter yang konsisten pada Kontrak Penyedia Layanan.
• Dompet pada rantai yang berbeda juga dapat memanggil satu sama lain melalui AMB, tidak harus dimulai dari Particle Chain.
• Menerbitkan Token Gas Terpadu. Mekanisme Paymaster menerapkan ERC20 sebagai biaya gas. Bahkan pada chain tanpa gas atau dana yang sudah tersimpan sebelumnya di Paymaster, transaksi lintas chain yang menggunakan token gas terpadu dapat dimulai pada chain yang sesuai.

Selain kasus penggunaan yang disebutkan di atas, Particle Chain juga dapat digunakan untuk:

• Jaringan terdesentralisasi untuk pembuktian zkWaaS dan pembuatan garam.
• Lapisan insentif untuk Bundler di seluruh rantai yang berbeda, membantu Bundler dalam mencapai desentralisasi yang lebih besar.
• Berfungsi sebagai jaringan pemecah untuk Protokol Intent Fusion.

Dalam narasi Particle Chain, token gas terpadu berfungsi sebagai proposisi nilai inti untuk seluruh ekosistem:

• Fungsionalitas pembayaran biaya gas adalah permintaan yang kuat dan logika penangkapan nilai yang divalidasi berulang kali di ruang kripto.
• Token Gas Terpadu mengabstraksikan konsep lapisan gas dari ekosistem rantai publik yang ada. Abstraksi ini, tanpa Rantai Partikel dan dompet, tidak dapat dicapai. Oleh karena itu, token gas terpadu mewakili realisasi nilai untuk seluruh ekosistem Partikel. Dengan lapisan gas, interaksi pengguna, pertumbuhan, dan nilai token asli di berbagai rantai berada dalam hubungan yang saling menguntungkan dengan token gas terpadu.
• Gas terpadu juga merupakan salah satu faktor pendorong untuk mencapai Chainless. Bagi pengguna, penggunaan mata uang tunggal sangat menyederhanakan proses penggunaan dan pemahaman biaya. Di masa depan, bahkan dalam skenario multi-chain, pengguna mungkin tidak menyadari dan tidak perlu mengkhawatirkan pengoperasian infrastruktur yang mendasarinya. Mirip dengan bagaimana, saat ini di Web2, kita berinteraksi dengan server tanpa peduli dengan lokasi pusat data, konfigurasinya, atau bahasa dan basis data yang mereka gunakan.
• Pengguna yang diimpor oleh dApps secara langsung memberdayakan token gas terpadu, menawarkan berbagai kasus penggunaan.

Protokol Fusi Maksud

Biasanya, ketika menggunakan berbagai dApps, pengguna harus selalu mempertimbangkan jalur penggunaan:

• Jika tidak ada likuiditas di satu DEX, Anda perlu memeriksa DEX lain.
• Memilih dApp yang paling sesuai dalam kategori yang sama untuk suatu transaksi atau tugas.
• Memahami konsep "Setujui" sebelum dapat menggunakan banyak fitur.
• Membersihkan dompet, mengubah beberapa jumlah token kecil menjadi token tertentu - sebuah proses yang membosankan.
• Menyelesaikan beberapa langkah di berbagai aplikasi yang berbeda untuk mencapai tujuan akhir. Misalnya, dalam pinjaman dengan leverage tinggi: swapping, staking, meminjam, mendapatkan token, lalu swapping lagi, staking, dan meminjam.

Konten di atas hanya mewakili sekilas lanskap DeFi saat ini, dan saat kita memasuki era adopsi dApps yang beragam secara luas di Web3, kompleksitas interaksi mungkin jauh melebihi imajinasi kita.

Oleh karena itu, mengganti langkah operasional tertentu dengan maksud, akan memberikan pengalaman yang sangat berbeda bagi pengguna. Intent, dibandingkan dengan operasi, mirip dengan pemrograman deklaratif versus pemrograman fungsional. Pernyataan deklaratif sering kali memberikan kesan lugas, hanya membutuhkan pernyataan tentang apa yang perlu dilakukan tanpa perlu memikirkan detail selanjutnya. Hal ini memerlukan berbagai tingkat pernyataan pemrograman fungsional yang dienkapsulasi dalam lapisan yang mendasarinya.

Demikian pula, menggunakan Intents memerlukan dukungan dari serangkaian fasilitas. Mari kita cermati seluruh prosesnya:

1. Pengguna mengirimkan Intent mereka, mendeskripsikannya dengan cara tertentu, seperti bahasa alami, dalam bentuk RFS (Request For Solver), yang dikirimkan ke jaringan Solver. Solver adalah penerjemah untuk maksud, dan solver umum seperti 1inch, agregator, mencari DEX yang optimal untuk pengguna. Namun, Solver ini, dibandingkan dengan visi kami, mungkin tidak cukup serbaguna dan kuat.

2. Beberapa Solver merespons, bersaing satu sama lain. Tanggapan ini ditulis dalam bahasa Intent DSL, kemudian diuraikan oleh klien ke dalam bentuk yang mudah dimengerti oleh pengguna. Tanggapan ini mencakup Kendala Input dan Kendala Output, yang mendefinisikan batasan input dan output. Pengguna juga dapat menentukan batasannya sendiri. Contoh sederhana untuk memahami: ketika menggunakan Swap, pengguna diminta dengan jumlah minimum yang dapat mereka terima setelah melakukan swap, yang merupakan bentuk batasan. Pengguna memilih dari respons yang disediakan oleh beberapa Solver.

3. Tanda tangani surat perjanjian.

4. Solver menentukan Pelaksana kontrak eksekusi tertentu dan mengirimkan maksudnya ke Reaktor kontrak respons.

5. Reaktor mengumpulkan input yang diperlukan (seperti aset tertentu) dari akun pengguna, mengirimkan maksud kepada Pelaksana, dan setelah memanggil kontrak logika yang relevan, mengembalikan output transaksi ke Reaktor. Reaktor memeriksa batasan dan, jika benar, mengembalikan output kepada pengguna.

Kami dapat membayangkan proses ini seolah-olah Anda sedang menjelaskan kebutuhan Anda kepada ChatGPT. Terlepas dari seberapa rumit persyaratannya, ini dapat menghasilkan hasil akhir untuk Anda. Selama Anda puas dengan hasilnya, Anda bisa menggunakannya secara langsung tanpa perlu memikirkan proses yang mendasarinya.

Kesimpulan

Particle Network telah mengusulkan solusi yang komprehensif: melalui bentuk terintegrasi dari zkWaaS, Particle Chain, dan Intent Fusion Protocol, solusi ini mencapai login privasi Web2 OAuth, transaksi privasi, abstraksi akun omnichain, dan paradigma transaksi berbasis niat. Setiap fitur mengatasi sebagian dari masalah dalam penggunaan Web3. Kemajuan dan pengoptimalan ini akan menjadi fondasi bagi adopsi produk dan teknologi Web3 secara luas di masa depan. Dalam hal ekosistem dan model bisnis, mengadopsi paradigma B2B2C, menggunakan WaaS sebagai titik masuk untuk mendorong skalabilitas dan standarisasi seluruh rantai produk, membangun ekosistem bersama dengan pengembang dApp, dan bersama-sama menciptakan dunia Web3 dengan ambang batas yang rendah dan pengalaman yang tinggi bagi para pengguna.

Tentu saja, proyek yang berbeda memiliki interpretasi yang berbeda tentang jalur implementasi untuk adopsi massal Web3. Selain meneliti proyek-proyek tertentu, kami berharap dapat menggunakan solusi yang berbeda untuk menyoroti pemahaman tentang gesekan orientasi yang dihadapi oleh Web3 saat ini, perenungan tentang kebutuhan pengguna dan titik-titik masalah, dan pertimbangan untuk koneksi kolektif dan pengembangan seluruh ekosistem.

Penafian: Penafian

1. Artikel ini dicetak ulang dari[极客 Web3], Semua hak cipta adalah milik penulis asli[雾月，极客Web3]. Jika ada keberatan dengan pencetakan ulang ini, silakan hubungi tim Gate Learn, dan mereka akan segera menanganinya.
2. Penafian Tanggung Jawab: Pandangan dan pendapat yang diungkapkan dalam artikel ini semata-mata merupakan pandangan dan pendapat penulis dan bukan merupakan saran investasi.
3. Penerjemahan artikel ke dalam bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, menyalin, mendistribusikan, atau menjiplak artikel terjemahan dilarang.