Penelitian Masalah Pemisahan Likuiditas di Era Layer 2

Seiring dengan Ethereum beralih ke strategi ekspansi yang berfokus pada Layer 2, serta munculnya alat seperti RaaS, banyak blockchain publik berkembang pesat. Banyak entitas ingin membangun rantai mereka sendiri untuk mewakili berbagai kepentingan dan mencari penilaian yang lebih tinggi. Namun, munculnya banyak blockchain publik membuat perkembangan ekosistem sulit mengikuti langkah blockchain publik, menyebabkan banyak proyek gagal saat diluncurkan.

Dengan OP Stack, sebuah platform perdagangan meluncurkan Layer 2 miliknya; dengan teknologi ZK, platform perdagangan lainnya meluncurkan Layer miliknya; sebuah perusahaan merilis rantai miliknya, perusahaan perangkat lunak komunikasi meluncurkan rantai miliknya, dan sebagainya. Saat ini, biaya dan batasan teknis untuk membangun sebuah rantai telah sangat menurun, biaya untuk mengoperasikan sebuah rantai berdasarkan OP Stack adalah sekitar 10.000 dolar AS per bulan.

Masa depan pasti akan menjadi era multi-rantai yang saling berdampingan. Meskipun rantai Layer 2 ini mungkin memilih kompatibilitas EVM untuk mencapai interoperabilitas, tetapi karena entitas Web2 di baliknya memiliki banyak aplikasi hilir, mereka sulit untuk membangun aplikasi dan mencapai konsensus di satu rantai yang sama.

Ekosistem multirantai saat ini membawa tantangan baru: Likuiditas dan status yang terdistribusi. Karena keberadaan multirantai adalah suatu keharusan, interopabilitas menjadi bidang yang harus dijelajahi dan dipecahkan. Saat ini ada banyak solusi likuiditas, seperti abstraksi rantai, niat, Eksekusi Clearing, Native CrossChain, ZKSharding, tetapi esensi intinya sama.

Kami menggunakan arsitektur Cake yang diakui secara luas di industri untuk memperkenalkan komponen inti dari abstraksi lintas rantai dari atas ke bawah:

Lapisan Aplikasi(Application Layer)

Ini adalah lapisan interaksi langsung pengguna, juga merupakan lapisan paling abstrak dalam solusi likuiditas, karena sepenuhnya menyembunyikan detail konversi likuiditas. Di lapisan aplikasi, pengguna berinteraksi dengan antarmuka depan, mungkin tidak memahami mekanisme konversi likuiditas di lapisan bawah.

Lapisan Izin(Permission Layer)

Terletak di bawah lapisan aplikasi, pengguna memenuhi niat transaksi dengan menghubungkan dompet ke dApp dan meminta kutipan. Di sini, "niat" mengacu pada hasil transaksi akhir yang diharapkan pengguna ( yaitu output ), bukan jalur pelaksanaan transaksi yang spesifik.

Manajemen Akun dan Abstraksi Kunci ( Manajemen Akun dan Abstraksi )

Karena adanya lingkungan multi-chain, diperlukan sistem manajemen akun dan abstraksi yang dapat beradaptasi dengan berbagai chain untuk mempertahankan struktur akun unik masing-masing chain. Misalnya, sistem akun pusat objek SUI sangat berbeda dari EVM. Beberapa proyek membangun sistem akun yang dapat dipercaya, tanpa perlu membangun konsensus antar chain, hanya memerlukan komitmen terpercaya antara sistem akun yang ada. Selain itu, proyek lain mencapai manajemen abstraksi dengan menghasilkan dompet akun multi-chain untuk pengguna, yang sangat mengoptimalkan pengalaman pengguna dan mengurangi fragmentasi UX. Namun, dalam hal likuiditas, sebagian besar terintegrasi dengan blockchain publik yang ada.

Mencari solusi Layer (Solver Layer)

Lapisan ini bertanggung jawab untuk menerima dan mewujudkan niat transaksi pengguna, peran Solver bersaing di sini untuk memberikan pengalaman pengguna yang lebih baik, termasuk waktu transaksi yang lebih cepat dan kecepatan eksekusi. Berdasarkan hal ini, proyek berbasis niat telah membangun berbagai solusi yang didorong oleh niat. Turunan dari niat semacam itu, seperti komponen Predicate, dapat mewujudkan niat pengguna di bawah aturan tertentu.

Lapisan Penyelesaian (Settlement Layer )

Ini adalah lapisan perantara yang digunakan untuk mencapai niat pengguna. Komponen inti dari solusi likuiditas dan status terdistribusi termasuk:

• 预言机(Oracle): digunakan untuk mendapatkan informasi status di rantai lain.
• Jembatan Lintas Rantai ( Bridges ): Bertanggung jawab atas penyampaian informasi dan Likuiditas antar rantai.
• Konfirmasi awal (Pre-Confirmation): Memperpendek waktu konfirmasi lintas rantai.
• Ketersediaan data(DA): Menyediakan aksesibilitas data.

Selain itu, perlu mempertimbangkan likuiditas antar rantai, finalitas (Finality ), mekanisme pembuktian Layer 2 dan faktor lainnya, untuk memastikan operasi efisien dari seluruh sistem multi-rantai.

Saat ini, ada berbagai solusi di pasar untuk mengatasi pemisahan likuiditas. Setelah melihat banyak solusi, kami menemukan bahwa ada beberapa cara utama:

1. Berfokus pada RaaS: Solusi Rollup seperti OP Stack, dengan menambahkan sorter bersama dan jembatan lintas rantai tertentu untuk membantu berbagi likuiditas dan status dari Rollup yang dibangun di atas OP Stack. Ini diharapkan dapat menyelesaikan masalah likuiditas dan status yang terdistribusi dengan arah yang lebih tinggi. Di dalamnya terdapat desain sorter bersama yang lebih terperinci, solusi ini lebih ditujukan untuk Layer 2 dan tidak bersifat universal.

2. Berbasis akun: Membangun dompet akun seluruh rantai, yang mendukung penandatanganan dan pelaksanaan transaksi melalui berbagai protokol blockchain dengan teknologi yang disebut "tanda tangan rantai". Komponen inti adalah jaringan MPC, yang menggantikan pengguna dalam menandatangani transaksi multi-rantai. Meskipun solusi ini dapat sangat mengatasi masalah fragmentasi UX, tetapi bagi pengembang, ini melibatkan implementasi backend yang kompleks, dan tidak secara substansial menyelesaikan masalah likuiditas dan penyebaran status.

3. Berbasis pada jaringan niat off-chain: yaitu jaringan Solver dalam diagram arsitektur "pengantar" kami, inti dari ini adalah pengguna mengirimkan niat ke jaringan Solver, peran Solver ini bersaing dalam penawaran, memberikan waktu penyelesaian dan harga transaksi yang optimal, Solver ini bisa berupa AI Agent, CEX, Market Maker, atau bahkan protokol terintegrasi itu sendiri. Meskipun niat secara teori dapat mewujudkan operasi lintas rantai yang kompleks dengan kesulitan yang tidak terbatas, tetapi dalam pelaksanaannya, diperlukan Solver likuiditas yang cukup untuk membantu, dan ketika menghadapi beberapa kebutuhan off-chain, ada kemungkinan penipuan dari Solver, jika metode seperti bukti penipuan diterapkan, maka kesulitan dalam mewujudkan jaringan Solver akan semakin tinggi, dan ambang batas untuk menjalankan Solver juga akan semakin tinggi.

4. Berbasis pada jaringan likuiditas on-chain: Arah ini secara khusus mengoptimalkan masalah likuiditas lintas rantai, tetapi tidak menyelesaikan masalah status terdistribusi di rantai lain. Intinya adalah membangun suatu lapisan likuiditas, di mana aplikasi dibangun di atas lapisan tersebut, untuk berbagi likuiditas seluruh rantai.

5. Berbasis aplikasi on-chain: Aplikasi jenis ini membangun aplikasi dengan likuiditas tinggi melalui integrasi MM besar, atau aplikasi pihak ketiga. Proyek semacam ini perlu mengelola proses lintas rantai yang kompleks, sehingga memiliki tuntutan yang sangat tinggi terhadap pengembang, dan oleh karena itu juga sangat rentan terhadap serangan peretas.

Mengatasi masalah likuiditas adalah sebuah pernyataan yang sangat penting, di dunia keuangan likuiditas sering kali mewakili segalanya. Jika kita dapat membangun sebuah platform integrasi likuiditas, terutama dengan menggabungkan likuiditas rantai penuh yang terpisah, itu akan memiliki potensi yang sangat besar, dan kami juga telah melihat banyak solusi berbeda.

Dalam dua kategori di atas, kita dapat melihat bahwa berdasarkan struktur kue, Settlement Layer adalah solusi tingkat paling atom, di atas solusi atom seperti lintas rantai, oracle, dan Pre-Confirmation, dibangun satu lapisan yang lebih abstrak, yaitu Solver Layer, Permission Layer, dan Application Layer. Berbagai solusi abstrak atau likuiditas yang kami sebutkan di atas, yang dibangun ke arah yang berbeda, sesuai dengan berbagai tingkat dalam sistem ini, dapat dipahami sebagai hubungan hulu dan hilir. Namun, solusi ini tetap bukan solusi tingkat atom, masalah pemisahan likuiditas secara keseluruhan, menyebabkan munculnya banyak masalah turunan yang rumit, sehingga muncul berbagai solusi untuk interoperabilitas. Namun pada dasarnya tetap harus bergantung pada komponen-komponen ini.

Memecahkan masalah likuiditas lintas rantai adalah bidang yang sangat kompleks dan memiliki banyak solusi, seperti solusi Layer 2 yang dibagi menjadi penyelesaian melalui pesan lintas rantai yang terintegrasi, khususnya ERC-7683, serta OP Stack yang dibangun di Layer 2 untuk berbagi Sequencer. Di luar konteks Layer 2, semua Layer 1 juga menghadapi masalah pemisahan likuiditas, status, dan pengalaman pengguna. Ada solusi yang berfokus pada aplikasi khusus untuk likuiditas, serta solusi off-chain dari Solver Network, bahkan ada solusi yang berfokus pada akun, tetapi juga perlu didasarkan pada peran off-chain seperti Solver.

Kami cukup setuju bahwa pemisahan likuiditas lintas rantai, status, dan pengalaman pengguna adalah masalah di seluruh industri blockchain. Jika dilihat secara keseluruhan, perlu ada pendekatan yang lebih abstrak, mirip dengan abstraksi rantai, yang setara dengan pintu masuk Web3 yang sebenarnya, mengatasi pemisahan dalam pengalaman pengguna, sementara integrasi likuiditas dan status dilakukan di tempat yang tidak dapat dirasakan oleh pengguna. Bagaimana cara integrasi ini dilakukan, dibagi menjadi penggunaan jaringan Solver di luar rantai dan fasilitas jembatan lintas rantai yang bersifat atomik, semua ini layak untuk didiskusikan. Secara keseluruhan, masa depan pasti akan multi-rantai, dan mengatasi masalah dispersal likuiditas adalah tantangan yang harus dihadapi oleh industri, sementara integrasi likuiditas di seluruh rantai memiliki ruang pertumbuhan yang luas, berpotensi membangun pintu masuk internet baru di era Web3.