Mengapa Prop AMM penuh di Solana, tetapi masih kosong di EVM?

Judul Asli: dApps yang Harus Ditonton Setelah Peluncuran Monad Mainnet

Penulis asli: Optimus

Sumber asli:

Repost: Mars Finance

Prop AMM telah dengan cepat menguasai 40% dari total volume perdagangan Solana. Mengapa mereka belum muncul di EVM?

Automated Market Makers (Proprietary AMMs, disingkat Prop AMMs) sedang dengan cepat menjadi kekuatan dominan dalam ekosistem DeFi Solana, saat ini mereka telah menyumbang lebih dari 40% volume perdagangan di pasangan perdagangan utama. Tempat likuiditas khusus yang dioperasikan oleh pembuat pasar profesional ini dapat menyediakan likuiditas yang dalam dan harga yang lebih kompetitif, alasan utamanya adalah karena mereka secara signifikan mengurangi risiko pembuat pasar dieksploitasi oleh “kutipan kedaluwarsa” (stale quotes) untuk arbitrase front-running.

Namun, keberhasilan mereka hampir sepenuhnya terbatas pada Solana. Bahkan di jaringan Layer 2 yang cepat dan rendah biaya seperti Base atau Optimism, kehadiran Prop AMM di ekosistem EVM masih jarang terlihat. Mengapa mereka tidak berakar di EVM?

Artikel ini terutama membahas tiga pertanyaan: Apa itu Prop AMM, tantangan teknis dan ekonomi apa yang mereka hadapi di rantai EVM, dan arsitektur baru yang menjanjikan yang dapat membawa mereka ke garis depan DeFi EVM.

Apa itu Prop AMM?

Prop AMM adalah jenis pembuat pasar otomatis yang dikelola secara aktif oleh satu pembuat pasar profesional untuk mengelola likuiditas dan penetapan harga, bukan seperti AMM tradisional yang didanai secara pasif oleh masyarakat.

AMM tradisional (seperti Uniswap v2) biasanya menggunakan rumus x * y = k untuk menentukan harga, di mana x dan y masing-masing mewakili jumlah dua aset dalam kolam, dan k adalah nilai tetap. Namun, dalam Prop AMM, rumus penetapan harga tidak tetap, tetapi diperbarui secara frekuensi tinggi (biasanya diperbarui beberapa kali per detik). Karena sebagian besar mekanisme internal Prop AMM bersifat “kotak hitam”, pihak luar tidak mengetahui algoritma tepat yang mereka gunakan. Namun, kode kontrak pintar Prop AMM Obric di rantai Sui adalah publik (terima kasih kepada penemuan @markoggwp), dan invarian k bergantung pada variabel internal mult_x, mult_y, dan konsentrasi. Gambar di bawah ini menunjukkan bagaimana pembuat pasar terus memperbarui variabel-variabel ini.

Satu hal yang perlu dijelaskan adalah: rumus di sisi kiri kurva harga Obric lebih kompleks daripada sekadar x*y, tetapi kunci untuk memahami Prop AMM adalah—itu selalu sama dengan invariant k yang dapat bervariasi, dan pembuat pasar akan terus memperbarui k ini untuk menyesuaikan kurva harga.

Ulangi: Bagaimana AMM menentukan harga?

Dalam artikel ini, kita akan sering menyebut konsep “kurva harga”. Kurva harga menentukan harga yang perlu dibayar pengguna saat melakukan perdagangan AMM, dan juga merupakan bagian yang terus diperbarui oleh pembuat pasar dalam Prop AMM. Untuk memahami ini dengan lebih baik, kita dapat terlebih dahulu meninjau cara penetapan harga dalam AMM tradisional.

Sebagai contoh kolam WETH-USDC di Uniswap v2 (asumsi tanpa biaya). Harga ditentukan secara pasif oleh rumus x * y = k. Misalkan ada 100 WETH dan 400.000 USDC di kolam, maka titik kurva saat ini adalah x = 100, y = 400.000, yang sesuai dengan harga awal 400.000 / 100 = 4.000 USDC/WETH. Dari sini kita dapatkan konstanta k = 100 * 400.000 = 40.000.000.

Jika ada trader yang ingin membeli 1 WETH, dia perlu menambahkan USDC ke dalam pool, sehingga WETH dalam pool berkurang menjadi 99. Untuk menjaga produk tetap konstan k, titik baru (x, y) harus tetap berada di atas kurva, sehingga y harus berubah menjadi 40.000.000 / 99 ≈ 404.040,40. Dengan kata lain, trader tersebut membayar sekitar 4.040,40 USDC untuk 1 WETH, sedikit lebih tinggi dari harga awal. Fenomena ini disebut “slippage”. Inilah alasan mengapa x*y=k disebut sebagai “kurva harga”: harga yang dapat diperdagangkan harus berada di atas kurva ini.

Mengapa pembuat pasar memilih desain AMM daripada buku pesanan terpusat (CLOB)?

Mari kita jelaskan mengapa pembuat pasar ingin menggunakan desain AMM untuk melakukan pasar. Bayangkan Anda adalah pembuat pasar yang memberikan penawaran di buku pesanan terpusat (CLOB) di blockchain. Jika Anda ingin memperbarui penawaran Anda, Anda perlu membatalkan dan mengganti ribuan pesanan batas. Jika Anda memiliki N pesanan, maka biaya pembaruan adalah operasi tingkat O(N), yang lambat dan mahal di blockchain.

Dan jika Anda dapat mewakili semua penawaran dengan satu kurva matematika? Anda hanya perlu memperbarui beberapa parameter yang mendefinisikan kurva ini, sehingga mengubah operasi O(N) menjadi kompleksitas konstan O(1).

Untuk secara intuitif menunjukkan bagaimana “kurva harga” berhubungan dengan berbagai rentang harga yang valid, kita dapat merujuk pada SolFi yang dibuat oleh Ellipsis Labs—sebuah Prop AMM berbasis Solana. Meskipun kurva harga spesifiknya tidak diketahui dan disembunyikan, Ghostlabs telah menggambar sebuah grafik yang menunjukkan harga efektif saat menukar jumlah SOL yang berbeda dengan USDC dalam suatu slot Solana (periode waktu blok) tertentu. Setiap garis mewakili kolam WSOL/USDC yang berbeda, menunjukkan bahwa beberapa tingkat harga dapat ada secara bersamaan. Seiring dengan pembaruan kurva harga oleh pembuat pasar, grafik harga efektif ini juga akan berubah antara slot yang berbeda.

Poin kunci di sini adalah, dengan hanya memperbarui sejumlah kecil parameter kurva harga, pembuat pasar dapat mengubah distribusi harga yang efektif kapan saja, tanpa perlu mengubah satu per satu N pesanan. Inilah nilai proposisi inti dari Prop AMM—ini memungkinkan pembuat pasar untuk menyediakan likuiditas yang dinamis dan dalam dengan efisiensi modal dan komputasi yang lebih tinggi.

Mengapa arsitektur Solana sangat cocok untuk Prop AMM?

Prop AMM adalah sistem “manajemen aktif”, yang berarti ia membutuhkan dua syarat kunci:

1. Biaya pembaruan rendah (cheap updates)

2. Hak eksekusi prioritas (priority execution)

Di Solana, keduanya saling melengkapi: pembaruan dengan biaya rendah sering kali berarti pembaruan tersebut mendapatkan prioritas eksekusi.

Mengapa pembuat pasar memerlukan dua hal ini? Pertama, mereka akan terus memperbarui kurva harga berdasarkan perubahan persediaan atau fluktuasi harga indeks aset (seperti harga di bursa terpusat) dengan kecepatan operasi blockchain. Di jaringan berfrekuensi tinggi seperti Solana, jika biaya pembaruan terlalu tinggi, akan sulit untuk melakukan penyesuaian frekuensi tinggi.

Kedua, jika pembuat pasar tidak dapat memastikan pembaruan berada di bagian atas blok, penawaran lama mereka akan “diambil” oleh para arbitrase, menyebabkan kerugian yang pasti. Jika dua karakteristik ini hilang, pembuat pasar tidak akan dapat beroperasi secara efisien, dan pengguna juga akan mendapatkan harga perdagangan yang lebih buruk.

Sebagai contoh Prop AMM HumidiFi di Solana, menurut data @SliceAnalytics, pembuat pasar ini memperbarui harga hingga 74 kali per detik.

Pemain dari EVM mungkin akan bertanya: “Slot Solana sekitar 400ms, bagaimana Prop AMM dapat memperbarui harga beberapa kali dalam satu slot?”

Jawabannya terletak pada arsitektur kontinu Solana, yang pada dasarnya berbeda dari model blok diskrit EVM.

· EVM: Transaksi biasanya dieksekusi secara berurutan setelah blok penuh diusulkan dan dikonfirmasi. Ini berarti pembaruan yang dikirim di tengah jalan hanya akan berlaku di blok berikutnya.

· Solana: Node pemverifikasi Leader tidak akan menunggu blok lengkap, tetapi akan memecah transaksi menjadi paket data kecil (disebut “shred”) dan terus-menerus siarkan ke jaringan. Dalam satu slot mungkin ada beberapa pertukaran, tetapi shred #1 的价格更新影响 swap #1, shred #2 的价格更新影响 swap #2.

Catatan: Flashblocks mirip dengan shred Solana. Menurut @Ashwinningg dari Anza Labs dalam presentasinya di konferensi CBER, setiap slot 400ms memiliki batas maksimum 32.000 shred, yang setara dengan 80 shred per milidetik. Apakah Flashblocks 200ms cukup cepat untuk memenuhi kebutuhan pembuat pasar, dibandingkan dengan arsitektur berkelanjutan Solana, masih merupakan pertanyaan terbuka.

Jadi, mengapa pembaruan di Solana begitu murah? Dan bagaimana hal itu menyebabkan eksekusi prioritas?

Pertama, meskipun implementasi Prop AMM di Solana adalah kotak hitam, ada pustaka seperti Pinocchio yang dapat mengoptimalkan cara penulisan program Solana dengan CU. Blog Helius memberikan pengenalan yang luar biasa tentang hal ini, melalui pustaka ini, konsumsi CU program Solana dapat turun dari sekitar 4000 CU menjadi sekitar 100 CU.

Sekarang kita lihat bagian kedua. Di tingkat yang lebih tinggi, Solana memprioritaskan transaksi dengan rasio Fee / Compute Units tertinggi (Compute Units mirip dengan Gas di EVM), mirip dengan EVM.

· Secara khusus, jika menggunakan Jito, rumusnya adalah Jito Tip / Compute Units

· Tidak digunakan: Prioritas = ( biaya prioritas + biaya dasar ) / (1 + batas CU + tanda tangan CU + kunci tulis CU )

Dibandingkan dengan Compute Units dari Prop AMM yang diperbarui dan Jupiter Swap, terlihat bahwa pembaruan tersebut sangat murah, dengan rasio mencapai 1:1000.

Pembaruan Prop AMM: pembaruan kurva sederhana sangat murah. Pembaruan Wintermute serendah 109 CU, total biaya hanya 0.000007506 SOL

Jupiter Swap: Swap melalui rute Jupiter dapat mencapai ~100.000 CU, total biaya 0.000005 SOL

Karena perbedaan yang besar ini, pembuat pasar hanya perlu membayar biaya yang sangat kecil untuk memperbarui transaksi, sehingga mereka dapat mencapai rasio Fee/CU yang jauh lebih tinggi daripada pertukaran, memastikan bahwa pembaruan dieksekusi di bagian atas blok dan melindungi diri mereka dari serangan arbitrase.

Mengapa Prop AMM belum diluncurkan di EVM?

Misalkan pembaruan Prop AMM melibatkan penulisan variabel yang menentukan kurva harga pasangan perdagangan. Meskipun kode Prop AMM di Solana adalah “kotak hitam”, para pembuat pasar ingin menjaga kerahasiaan strategi mereka, tetapi kita dapat menggunakan asumsi ini untuk memahami cara Obric mengimplementasikan Prop AMM di Sui: variabel keputusan untuk penawaran pasangan perdagangan ditulis ke kontrak pintar melalui fungsi update.

Terima kasih @markoggwp atas penemuan ini!

Dengan menggunakan asumsi ini, kami menemukan bahwa arsitektur EVM memiliki hambatan signifikan yang membuat model Prop AMM Solana tidak dapat dilaksanakan di EVM.

Melihat kembali, pada blockchain OP-Stack Layer 2 (seperti Base dan Unichain), transaksi diurutkan berdasarkan biaya prioritas per Gas (mirip dengan Solana yang mengurutkan berdasarkan Fee / CU).

Di EVM, konsumsi Gas untuk operasi penulisan sangat tinggi. Dibandingkan dengan pembaruan Solana, biaya untuk menulis sebuah nilai di EVM melalui opcode SSTORE sangat mengejutkan:

· SSTORE（0 → non 0）：~22,100 gas

· SSTORE (non 0 → non 0): ~5.000 gas

· Swap AMM yang khas: ~200.000–300.000 gas

Perhatian: Gas di EVM mirip dengan unit komputasi (CU) di Solana. Angka gas SSTORE di atas mengasumsikan bahwa setiap transaksi hanya memiliki satu penulisan (penulisan dingin), ini wajar karena biasanya tidak akan mengirimkan beberapa pembaruan dalam satu transaksi.

Meskipun pembaruan masih lebih murah dibandingkan dengan pertukaran, tingkat penggunaan gas hanya sekitar 10 kali lipat (pembaruan mungkin melibatkan beberapa SSTORE), sementara di Solana, rasio ini sekitar 1000 kali lipat.

Ini menghasilkan dua kesimpulan, yang membuat model Solana Prop AMM yang sama lebih berisiko di EVM:

1. Tingginya konsumsi Gas menyebabkan biaya prioritas sulit dijamin untuk pembaruan prioritas, biaya prioritas yang lebih rendah tidak dapat mencapai rasio tarif tinggi/Gas. Untuk memastikan pembaruan tidak dieksekusi lebih dulu dan berada di bagian atas blok, diperlukan biaya prioritas yang lebih tinggi, sehingga meningkatkan biaya.

2. Risiko arbitrase di EVM lebih tinggi, rasio pembaruan Gas dan pertukaran Gas di EVM hanya 1:10, sedangkan di Solana adalah 1:1000. Ini berarti bahwa para arbitrase hanya perlu meningkatkan biaya prioritas 10 kali lipat untuk mendahului pembaruan pembuat pasar, sedangkan di Solana harus meningkat 1000 kali lipat. Dengan rasio yang lebih rendah ini, para arbitrase lebih mungkin untuk melakukan transaksi sebelum pembaruan harga untuk mendapatkan penawaran yang terlambat, karena biayanya yang rendah.

Beberapa inovasi (seperti TSTORE dari EIP-1153, yang digunakan untuk penyimpanan sementara) menawarkan biaya penulisan sekitar 100 gas, tetapi penyimpanan ini bersifat sementara, hanya berlaku dalam satu transaksi, dan tidak dapat digunakan untuk mempersistenkan pembaruan harga untuk digunakan dalam transaksi swap berikutnya (misalnya selama periode blok).

Bagaimana cara memperkenalkan Prop AMM ke EVM?

Sebelum menjawab, pertama-tama jawab “mengapa melakukan ini”: pengguna selalu ingin mendapatkan penawaran perdagangan yang lebih baik, yang berarti perdagangan menjadi lebih menguntungkan. Ethereum dan Prop AMM Layer 2 dapat memberikan kepada pengguna penawaran kompetitif yang biasanya hanya bisa didapatkan di Solana atau bursa terpusat.

Untuk membuat Prop AMM dapat berjalan di EVM, kita meninjau salah satu alasan keberhasilannya di Solana:

· Perlindungan pembaruan di atas blok: Di Solana, pembaruan Prop AMM terletak di atas blok, yang dapat melindungi pembuat pasar dari perdagangan mendahului. Pembaruan berada di atas karena konsumsi unit perhitungan sangat sedikit, bahkan dengan biaya rendah, dapat mencapai rasio biaya/CU yang tinggi, terutama dibandingkan dengan perdagangan swap.

Jadi, bagaimana cara memperkenalkan pembaruan Prop AMM di atas blok ke dalam blockchain EVM Layer 2? Ada dua cara: baik menurunkan biaya penulisan, atau membuat saluran prioritas untuk pembaruan Prop AMM.

Karena masalah pertumbuhan status EVM, metode untuk mengurangi biaya penulisan ini kurang layak, karena SSTORE yang murah dapat menyebabkan serangan status sampah.

Kami mengusulkan untuk membuat saluran prioritas untuk pembaruan Prop AMM. Ini adalah solusi yang dapat dilakukan dan juga merupakan fokus dari artikel ini.

Tim Uniswap @MarkToda mengusulkan metode baru untuk mencapai: kontrak pintar penyimpanan global + strategi pembangun blok khusus.

Cara kerjanya adalah sebagai berikut:

· Kontrak penyimpanan global: Menyebarkan kontrak pintar sederhana sebagai penyimpanan nilai kunci publik. Pembuat pasar akan menulis parameter kurva harga ke kontrak tersebut (misalnya set(ETH-USDC_CONCENTRATION, 4000)).

· Strategi Pembuat: Ini adalah komponen kunci off-chain. Pembuat blok mengidentifikasi transaksi yang dikirim ke kontrak penyimpanan global, mendistribusikan 5-10% Gas blok untuk transaksi pembaruan ini, dan mengurutkannya berdasarkan biaya untuk mencegah transaksi sampah.

Harap diperhatikan: Transaksi harus langsung dikirim ke alamat penyimpanan global, jika tidak, tidak dapat dijamin berada di puncak blok.

Contoh algoritma pembangunan blok kustom dapat merujuk pada rblib.

Integrasi Prop AMM: Kontrak Prop AMM dari pembuat pasar membaca data kurva harga dari kontrak penyimpanan global saat pertukaran untuk memberikan kutipan.

Arsitektur ini dengan cerdik menyelesaikan dua masalah:

1. Perlindungan: Strategi pembangun menciptakan “jalur cepat”, memastikan semua pembaruan harga dalam blok dieksekusi sebelum transaksi, menghilangkan risiko perdagangan yang mendahului.

2. Manfaat biaya: Pembuat pasar tidak lagi bersaing dengan semua pengguna DeFi untuk transaksi di puncak blok dengan Gas Price yang tinggi, mereka hanya perlu bersaing di pasar biaya lokal untuk memperbarui reservasi transaksi di puncak blok, yang secara signifikan mengurangi biaya.

Transaksi pengguna akan dieksekusi berdasarkan kurva harga yang ditetapkan oleh pembuat pasar pada pembaruan awal blok yang sama, memastikan kesegaran dan keamanan penawaran. Model ini mereproduksi lingkungan pembaruan biaya rendah dan prioritas tinggi di Solana pada EVM, membuka jalan bagi Prop AMM di EVM.

Namun, model ini juga memiliki beberapa kekurangan, dan saya akan meninggalkan masalah ini di bagian bawah artikel ini untuk dibahas.

Kesimpulan

Kelayakan Prop AMM bergantung pada penyelesaian masalah ekonomi inti: murah dan prioritas eksekusi untuk mencegah perdagangan yang mendahului.

Meskipun arsitektur EVM standar membuat operasi semacam ini mahal dan berisiko tinggi, desain baru menawarkan pendekatan berbeda untuk mengatasi masalah ini. Dengan menggabungkan kontrak pintar penyimpanan global on-chain dan strategi pembangun off-chain, desain baru dapat menciptakan “saluran cepat” yang khusus, menjamin pelaksanaan pembaruan di atas blok, sekaligus membangun pasar biaya lokal yang terkontrol. Ini tidak hanya membuat Prop AMM layak di EVM, tetapi juga dapat membawa perubahan bagi semua EVM DeFi yang bergantung pada pembaruan oracle di atas blok.

Pertanyaan terbuka

· Apakah kecepatan 200ms Flashblock Prop AMM di EVM cukup untuk bersaing dengan arsitektur berkelanjutan Solana?

· Sebagian besar lalu lintas AMM di Solana berasal dari satu agregator Jupiter, yang menyediakan SDK untuk memudahkan AMM terhubung. Namun, di Layer 2 EVM, lalu lintas tersebar di beberapa agregator dan tidak ada SDK publik, apakah ini menjadi tantangan bagi Prop AMM?

· Prop AMM di Solana diperbarui hanya menghabiskan sekitar 100 CU, bagaimana mekanisme pelaksanaannya?

· Model jalur cepat hanya menjamin pembaruan di bagian atas blok. Jika ada beberapa pertukaran dalam satu Flashblock, bagaimana pembuat pasar dapat memperbarui harga di antara pertukaran tersebut?

· Apakah mungkin untuk menulis program EVM yang dioptimalkan menggunakan bahasa seperti Yul atau Huff, mirip dengan solusi optimasi Pinocchio di Solana?

· Bagaimana perbandingan Prop AMM dengan RFQ?

· Bagaimana cara mencegah market maker memberikan penawaran berkualitas tinggi di blok N untuk mengundang pengguna, kemudian memperbarui menjadi penawaran yang buruk di blok N+1? Bagaimana Jupiter mencegahnya?

· Fitur Ultra Signaling dari Jupiter Ultra V3 memungkinkan Prop AMM untuk membedakan antara lalu lintas yang berbahaya dan tidak berbahaya, serta memberikan penawaran yang lebih ketat. Seberapa penting karakteristik agregator ini bagi Prop AMM di EVM?