Penelitian Masalah Pemisahan Likuiditas di Era Layer 2

Setelah Ethereum beralih ke solusi skala berbasis Layer 2, ditambah dengan munculnya alat-alat seperti RaaS, banyak blockchain publik berkembang dengan cepat. Banyak entitas ingin membangun rantai mereka sendiri untuk mewakili tuntutan kepentingan yang berbeda dan mencari valuasi yang lebih tinggi. Namun, munculnya banyak blockchain publik membuat pengembangan ekosistem sulit mengikuti laju blockchain publik, menyebabkan banyak proyek menghadapi kesulitan di awal.

Dengan OP Stack, sebuah platform perdagangan meluncurkan Layer 2 miliknya, dan platform perdagangan lainnya merilis proyek blockchain baru; dengan teknologi ZK, sebuah platform perdagangan meluncurkan lapisan baru. Beberapa perusahaan teknologi besar juga berturut-turut merilis proyek blockchain mereka sendiri. Saat ini, biaya dan ambang teknologi untuk membangun sebuah rantai telah sangat menurun, biaya untuk mengoperasikan sebuah rantai berbasis OP Stack adalah sekitar 10.000 dolar AS per bulan.

Masa depan pasti akan menjadi era keberadaan banyak rantai. Meskipun rantai Layer 2 ini mungkin akan memilih kompatibilitas EVM untuk mencapai interoperabilitas, tetapi karena perusahaan teknologi tradisional di baliknya memiliki banyak aplikasi hilir, mereka sulit untuk membangun aplikasi dan mencapai konsensus di satu rantai yang sama.

Ekosistem multirantai saat ini menghadirkan tantangan baru: Likuiditas dan status yang terdistribusi. Karena keberadaan multirantai adalah suatu keharusan, maka interoperabilitas adalah bidang yang harus dieksplorasi dan diselesaikan. Saat ini ada banyak solusi likuiditas, seperti abstraksi rantai, niat, Eksekusi Clearing, Native CrossChain, ZKSharding, dll., tetapi inti dari semuanya sama.

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

Lapisan aplikasi: Ini adalah lapisan di mana pengguna berinteraksi secara langsung, dan juga merupakan lapisan paling abstrak dalam solusi likuiditas, karena sepenuhnya menyembunyikan detail konversi likuiditas. Di lapisan aplikasi, pengguna berinteraksi dengan antarmuka depan, tanpa harus memahami mekanisme konversi likuiditas di lapisan bawah.

Lapisan izin: terletak di bawah lapisan aplikasi, pengguna menghubungkan dompet ke dApp dan meminta penawaran untuk memenuhi niat transaksi. Di sini, "niat" merujuk pada hasil transaksi akhir yang diharapkan pengguna, bukan jalur eksekusi transaksi yang spesifik.

Manajemen akun dan lapisan abstrak: Karena adanya lingkungan multi-rantai, diperlukan sistem manajemen akun dan abstraksi yang dapat beradaptasi dengan berbagai rantai untuk memelihara struktur akun unik dari masing-masing rantai. Beberapa proyek membangun sistem akun yang terpercaya, tanpa perlu membangun konsensus antar rantai, hanya memerlukan komitmen terpercaya antara sistem akun yang ada. Selain itu, proyek lain mewujudkan manajemen abstraksi dengan menghasilkan dompet akun multi-rantai untuk pengguna, yang sangat mengoptimalkan pengalaman pengguna dan mengurangi fragmentasi UX. Namun, dalam hal likuiditas, sebagian besar terintegrasi dengan rantai publik yang ada.

Layer 2: 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 membangun berbagai solusi yang digerakkan oleh niat. Derivatif dari niat tersebut seperti komponen Predicate, dapat mewujudkan niat pengguna di bawah aturan tertentu.

Settlement Layer: Ini adalah lapisan middleware yang digunakan oleh lapisan solusi untuk mewujudkan niat pengguna. Komponen inti dari solusi likuiditas dan status terdistribusi meliputi: oracle, jembatan antar rantai, skema konfirmasi awal, dan ketersediaan data. Selain itu, perlu mempertimbangkan likuiditas antar rantai, finalitas konfirmasi, mekanisme bukti Layer 2, dan faktor-faktor lain untuk memastikan operasi efisien dari seluruh sistem multi-rantai.

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

1. Berbasis RaaS: Mirip dengan beberapa solusi Rollup, dengan menambahkan penyortiran bersama tertentu dan jembatan lintas rantai untuk membantu membangun Rollup yang dibangun di atasnya berbagi likuiditas dan status. Ini diharapkan dapat menyelesaikan likuiditas dan status yang terdistribusi dengan arah yang lebih tinggi. Di sini ada yang lebih terperinci yaitu desain penyortiran bersama secara terpisah, solusi ini lebih ditujukan untuk Layer 2, tidak memiliki universalitas.

2. Berbasis Akun: Membangun dompet akun yang terintegrasi di seluruh rantai, yang mendukung penandatanganan dan pelaksanaan transaksi melalui teknologi yang disebut "tanda tangan rantai" di berbagai protokol blockchain. Komponen inti dari sistem ini adalah jaringan MPC, yang menggantikan pengguna untuk menandatangani transaksi multi-rantai. Meskipun solusi ini dapat sangat mengatasi masalah fragmentasi UX, bagi pengembang, ini melibatkan implementasi backend yang rumit dan pada dasarnya tidak menyelesaikan masalah likuiditas dan penyebaran status.

3. Berbasis pada jaringan niat off-chain: yaitu Solver Network dalam diagram arsitektur "pengantar" kami, inti dari ini adalah pengguna mengirimkan niat ke jaringan Solver, peran Solver ini bersaing untuk memberikan penawaran, memberikan waktu penyelesaian dan harga transaksi yang optimal, Solver ini bisa berupa AI Agent, bursa, pembuat pasar, bahkan protokol integrasi itu sendiri. Meskipun niat secara teoritis dapat mewujudkan operasi lintas rantai yang kompleks dengan tingkat kesulitan yang tidak terbatas, namun dalam implementasinya memang diperlukan Solver dengan likuiditas yang cukup untuk membantu, dan ketika menghadapi beberapa kebutuhan off-chain, ada kemungkinan penipuan yang terjadi pada Solver, jika metode seperti bukti penipuan diperkenalkan, maka tingkat 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 khusus untuk mengoptimalkan masalah likuiditas lintas rantai, tetapi tidak menyelesaikan masalah desentralisasi status on-chain lainnya. Intinya adalah membangun lapisan likuiditas, di mana aplikasi dibangun di atasnya, untuk berbagi likuiditas seluruh rantai.

5. Berfokus pada aplikasi on-chain: Aplikasi jenis ini membangun aplikasi dengan likuiditas tinggi melalui integrasi dengan pembuat pasar besar atau aplikasi pihak ketiga. Proyek-proyek ini perlu mengelola proses lintas rantai yang kompleks, yang menuntut pengembang dengan sangat tinggi, sehingga juga sangat rentan terhadap celah keamanan.

Mengatasi masalah likuiditas adalah sebuah proposisi yang sangat penting, di dunia keuangan likuiditas seringkali mewakili segalanya, jika kita dapat membangun sebuah platform integrasi likuiditas, terutama mengintegrasikan likuiditas seluruh rantai yang terpisah, itu akan memiliki potensi yang sangat besar, dan kami juga telah melihat banyak solusi yang berbeda.

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

Selanjutnya, kita akan membahas beberapa proyek konsep abstraksi rantai yang khas, untuk melihat bagaimana masing-masing menyelesaikan masalah pemisahan likuiditas dari sudut pandang mereka sendiri.

Sebuah proyek telah membangun layanan RaaS di dunia DeFi, yang dapat menyediakan komponen yang diperlukan untuk membangun protokol DeFi secara langsung, seperti Oracle, Pool Type, IRM, Asset, dan lain-lain, serta dapat menyediakan komponen seperti Leverage Trading dan Yield Strategy yang dapat segera digunakan. Ini setara dengan sisi pembangunan aplikasi lainnya, tetapi likuiditas akhirnya disimpan di lapisan likuiditas proyek tersebut. Namun, saat ini, mekanisme dasar masih belum diungkapkan.

Proyek lain telah membangun tiga komponen inti, yaitu lapisan kompatibilitas Intent, Validity, dan lapisan penyelesaian umum. Aplikasi eksternal atau lapisan niat dapat mengirimkan niat ke proyek ini, kemudian lapisan kompatibilitas Intent dapat mengubah niat eksternal menjadi format yang dapat dikenali oleh Solver protokol, dengan format yang distandarisasi yaitu bahasa Validity. Node proyek ini bertanggung jawab untuk mengirimkan hasil akhir ke lapisan penyelesaian umum melalui jembatan lintas rantai, teknologi penyelesaian cepat, dan lain-lain. Proyek ini masih dalam tahap pembangunan dan belum mengungkapkan lebih banyak detail kerja.

Ada sebuah proyek yang merupakan aplikasi terdesentralisasi, yang dapat mewujudkan penemuan harga berbasis lelang dan kolam likuiditas satu sisi. Misi utamanya adalah untuk menyediakan alat manajemen inventaris yang efisien bagi perusahaan perdagangan profesional, dan dengan mudah terhubung ke protokol DeFi inti saat menyelesaikan transaksi berdasarkan niat penggunaan. Sementara itu, proyek ini juga menciptakan pasar pinjam meminjam untuk melakukan transaksi pinjam meminjam. Aplikasi ini lebih fokus pada perdagangan itu sendiri.

Sebuah proyek berasal dari peningkatan merek lain, yang sebelumnya berfokus pada aplikasi konsumen, setelah itu tim menemukan adanya masalah fragmentasi yang besar dalam interaksi di blockchain, sehingga membangun proyek baru untuk memperbaiki masalah ini. Proyek ini didasarkan pada protokol konsensus Comet BFT. Komunikasi lintas rantai yang digunakannya didasarkan pada Cosmos IBC, sehingga lebih asli dan aman dibandingkan jembatan lintas rantai lainnya.

Sebuah yayasan adalah pengembang pasar komputasi ZK, prosesor ZK, dan Layer 2 untuk Ethereum, tim memiliki dasar teknis ZK yang mendalam. Mengusulkan solusi zkSharding, yang merupakan penggunaan teknologi ZK untuk memperluas jaringan utama Ethereum secara horizontal, mengeksekusi pemrosesan transaksi secara paralel melalui sharding dan menghasilkan ZKP, sementara sharding utama memverifikasi data, berkomunikasi dengan Ethereum, dan menyinkronkan status jaringan di antara semua validator. Sharding utama juga mengelola distribusi validator dan akun dalam sharding eksekusi. Protokol konsensus yang digunakan oleh komite verifikasi juga adalah Hotstuff, yang umum di proyek eksekusi paralel terbaru. Solusi ini sejak awal telah menyematkan komunikasi lintas sharding ke dalam protokol. Pesan lintas sharding diverifikasi oleh komite validator setiap sharding sebagai transaksi.

Inti dari gagasan ini adalah, melalui arsitektur Layer 2 yang terfragmentasi, untuk membangun arsitektur komunikasi lintas fragment yang terintegrasi seperti IBC, sehingga dapat menyelesaikan masalah likuiditas dan penyebaran status. Namun, gagasan intinya tidak rasional, karena masalah yang diselesaikan oleh penyebaran likuiditas adalah masalah multi-chain, sedangkan yang dibangun adalah Layer 2 tunggal, yang berarti untuk menyelesaikannya semua rantai harus menjadi salah satu fragment dari ZK-sharding, yang sulit untuk diwujudkan.

Ethereum juga sedang berupaya untuk menyelesaikan masalah likuiditas lintas rantai ini, saat ini ada beberapa proyek utama yang secara terbuka mendukung standar ERC tertentu, yang juga menggunakan metode lintas rantai berbasis Intent. Tujuan inti mereka adalah untuk membangun standar umum untuk operasi lintas L2 dan sidechain, menstandarisasi antarmuka pesanan dan penyelesaian, serta mewujudkan eksekusi lintas rantai yang mulus, inti utamanya adalah Filler yang juga bisa disebut sebagai peran Solver dalam abstraksi rantai untuk pembayaran pengganti. Proposal ini dibangun oleh dua proyek utama yang saat ini sedang ditinjau oleh kelompok kerja.

Beberapa tumpukan teknologi, standar ERC di atas, dan zkSharding sama-sama merupakan solusi untuk fragmentasi likuiditas antara Layer 2 di dalam Ethereum, diselesaikan di tingkat arsitektur, tingkat konsensus, dan tingkat aplikasi. Tumpukan teknologi ini merancang solusi multi Layer 2 yang lengkap untuk sekali jalan menyelesaikan masalah penyampaian informasi dan desentralisasi Sequencer. Ketika Anda menggunakan arsitektur tumpukan teknologi ini, kontrak lintas rantai akan secara otomatis dideploy, sementara akan ada Supervisor untuk menantang dan menghindari penyampaian informasi lintas rantai yang salah. Saat ini, ada beberapa proyek terkenal yang menggunakan arsitektur tumpukan teknologi ini.

Mengatasi 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 disematkan di Ethereum, khususnya standar ERC yang disebutkan di atas, serta shared Sequencer yang dibangun dengan tumpukan teknologi tertentu. Di luar konteks Layer 2, semua Layer 1 juga