Mengapa Prop AMM banyak terdapat di Solana, tetapi masih kosong di EVM?

Judul Asli: Must-Watch dApps After Monad Mainnet Launch

Penulis Asli: Optimus, Pendiri Waterloo Blockchain

Penerjemah: Dingdang, Odaily

Prop AMM dengan cepat telah mengambil alih 40% volume perdagangan di Solana. Mengapa mereka belum muncul di EVM?

Proprietary AMM (Prop AMM) secara cepat menjadi kekuatan dominan dalam ekosistem DeFi Solana, saat ini telah menyumbang lebih dari 40% volume perdagangan pada pasangan utama. Tempat likuiditas khusus yang dioperasikan oleh market maker profesional ini mampu menyediakan likuiditas yang dalam dan penetapan harga yang lebih kompetitif, inti utamanya adalah mereka secara signifikan mengurangi risiko market maker terkena front-running arbitrase dengan memanfaatkan "stale quotes".

Sumber gambar: dune.com

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

Artikel ini terutama membahas tiga pertanyaan: apa itu Prop AMM, hambatan teknis dan ekonomi apa yang mereka hadapi di chain EVM, serta arsitektur baru yang menjanjikan yang pada akhirnya dapat membawa mereka ke garis depan DeFi EVM.

Apa itu Prop AMM?

Prop AMM adalah jenis automated market maker yang dikelola secara aktif oleh satu market maker profesional dalam hal likuiditas dan penetapan harga, bukan seperti AMM tradisional yang dana disediakan secara pasif oleh publik.

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 pool, dan k adalah nilai konstan. Namun dalam Prop AMM, rumus penetapan harga tidak tetap, melainkan diperbarui secara frekuentif (biasanya beberapa kali per detik). Karena sebagian besar mekanisme internal Prop AMM bersifat "kotak hitam", pihak luar tidak mengetahui algoritma pasti yang digunakan. Namun, kode smart contract Prop AMM Obric di chain Sui bersifat publik (berkat penemuan @markoggwp), di mana invarian k bergantung pada variabel internal mult_x, mult_y, dan concentration. Gambar di bawah menunjukkan bagaimana market maker terus memperbarui variabel ini.

Perlu diluruskan: rumus di sisi kiri kurva penetapan harga Obric lebih kompleks daripada sekadar x*y, namun kunci memahami Prop AMM adalah—nilainya selalu sama dengan invarian k yang dapat berubah, dan market maker terus memperbarui k ini untuk menyesuaikan kurva harga.

Ulasan: Bagaimana AMM Menentukan Harga?

Dalam artikel ini, kita akan sering menyebut konsep "kurva harga". Kurva harga menentukan harga yang harus dibayar pengguna saat berdagang di AMM, dan juga bagian yang terus diperbarui oleh market maker di Prop AMM. Untuk memahaminya dengan lebih baik, mari kita tinjau cara penetapan harga AMM tradisional.

Ambil contoh pool WETH-USDC di Uniswap v2 (dengan asumsi tanpa biaya). Harga ditentukan secara pasif oleh rumus x * y = k. Misalkan pool memiliki 100 WETH dan 400.000 USDC, maka titik kurva saat ini adalah x = 100, y = 400.000, harga awalnya adalah 400.000 / 100 = 4.000 USDC/WETH. Maka k = 100 * 400.000 = 40.000.000.

Jika seorang trader ingin membeli 1 WETH, dia harus menambahkan USDC ke pool sehingga WETH di pool berkurang menjadi 99. Untuk menjaga k tetap konstan, titik baru (x, y) harus tetap berada di kurva, sehingga y harus menjadi 40.000.000 / 99 ≈ 404.040,40. Artinya, 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 "kurva harga": setiap harga yang dapat diperdagangkan harus berada di kurva ini.

Mengapa Market Maker Memilih Desain AMM daripada Centralized Order Book (CLOB)?

Mari kita jelaskan mengapa market maker ingin menggunakan desain AMM untuk market making. Bayangkan Anda adalah market maker yang mengajukan harga di centralized limit order book (CLOB) on-chain. Jika ingin memperbarui harga, Anda harus membatalkan dan mengganti ribuan order limit. Jika Anda memiliki N order, maka biaya pembaruan adalah operasi O(N), yang lambat dan mahal di on-chain.

Tapi bagaimana jika Anda dapat mewakili semua harga dengan satu kurva matematika? Anda hanya perlu memperbarui beberapa parameter yang mendefinisikan kurva tersebut, sehingga operasi O(N) menjadi O(1) dengan kompleksitas konstan.

Untuk menunjukkan secara visual bagaimana "kurva harga" sesuai dengan berbagai rentang harga efektif, kita dapat merujuk pada SolFi buatan Ellipsis Labs—sebuah Prop AMM berbasis Solana. Meskipun kurva harganya tidak diketahui dan disembunyikan, Ghostlabs membuat grafik yang menunjukkan harga efektif untuk menukar sejumlah SOL dengan USDC dalam satu slot Solana (periode blok). Setiap garis mewakili pool WSOL/USDC yang berbeda, menunjukkan bahwa beberapa level harga dapat ada secara bersamaan. Saat market maker memperbarui kurva harga, grafik harga efektif ini juga berubah antar slot.

Sumber gambar: github

Poin kuncinya di sini adalah, dengan hanya memperbarui sedikit parameter kurva harga, market maker dapat mengubah distribusi harga efektif kapan saja tanpa harus mengubah N order satu per satu. Inilah proposisi nilai inti Prop AMM—memungkinkan market maker menyediakan likuiditas 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 membutuhkan dua syarat utama:

1. Biaya pembaruan rendah (cheap updates)

2. Eksekusi prioritas (priority execution)

Di Solana, keduanya saling melengkapi: biaya pembaruan yang rendah biasanya berarti pembaruan dapat memperoleh eksekusi prioritas.

Mengapa market maker membutuhkan dua hal ini? Pertama, mereka akan terus memperbarui kurva harga sesuai perubahan inventaris atau fluktuasi harga indeks aset (misal harga di centralized exchange) secepat blockchain berjalan. Di chain dengan frekuensi tinggi seperti Solana, jika biaya pembaruan terlalu tinggi, penyesuaian frekuensi tinggi akan sulit dilakukan.

Kedua, jika market maker tidak dapat memastikan pembaruan berada di bagian atas blok, quote lama mereka akan diambil oleh arbitrase, menyebabkan kerugian yang pasti. Tanpa dua fitur ini, market maker tidak dapat beroperasi secara efisien, dan pengguna akan mendapatkan harga perdagangan yang lebih buruk.

Ambil contoh Prop AMM HumidiFi di Solana, menurut data @SliceAnalytics, market maker ini memperbarui quote hingga 74 kali per detik.

Pemain dari EVM mungkin bertanya: "Slot Solana sekitar 400ms, bagaimana Prop AMM bisa memperbarui harga beberapa kali dalam satu slot?"

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

· EVM: Transaksi biasanya dieksekusi secara berurutan setelah satu blok penuh diusulkan dan dikonfirmasi. Artinya, pembaruan yang dikirim di tengah jalan baru akan berlaku di blok berikutnya.

· Solana: Node validator Leader tidak menunggu blok penuh, melainkan membagi transaksi menjadi paket data kecil (disebut "shred") yang disiarkan terus-menerus ke jaringan. Dalam satu slot bisa ada beberapa swap, tetapi pembaruan harga shred #1 memengaruhi swap #1, pembaruan harga shred #2 memengaruhi swap #2.

Catatan: Flashblocks mirip dengan shred di Solana. Menurut presentasi @Ashwinningg dari Anza Labs di konferensi CBER, batas atas setiap slot 400ms adalah 32.000 shred, setara dengan 80 shred per milidetik. Apakah Flashblocks 200ms cukup cepat untuk memenuhi kebutuhan market maker dibandingkan arsitektur kontinu Solana masih menjadi pertanyaan terbuka.

Lalu, mengapa pembaruan di Solana sangat murah? Dan bagaimana hal itu menyebabkan eksekusi prioritas?

Pertama, meskipun implementasi Prop AMM di Solana adalah kotak hitam, ada library seperti Pinocchio yang dapat mengoptimalkan penulisan program Solana untuk mengurangi CU. Blog Helius membahas ini dengan baik, melalui library ini, konsumsi CU program Solana dapat turun dari sekitar 4000 CU menjadi sekitar 100 CU.

Sumber gambar: github

Kedua, pada tingkat yang lebih tinggi, Solana memilih transaksi dengan rasio Fee / Compute Units tertinggi untuk diprioritaskan (Compute Units mirip dengan Gas di EVM), mirip dengan EVM.

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

· Jika tidak: Priority = (priority fee + base fee) / (1 + CU limit + signature CU + write lock CU)

Bandingkan Compute Units pembaruan Prop AMM dengan Jupiter Swap, terlihat pembaruan sangat murah, dengan rasio 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 routing Jupiter bisa mencapai ~100.000 CU, total biaya 0,000005 SOL

Karena perbedaan besar ini, market maker hanya perlu membayar biaya yang sangat kecil untuk transaksi pembaruan, dapat mencapai rasio Fee/CU jauh lebih tinggi daripada swap, sehingga memastikan pembaruan dieksekusi di bagian atas blok, melindungi diri dari serangan arbitrase.

Mengapa Prop AMM Belum Terealisasi di EVM?

Misalkan pembaruan Prop AMM melibatkan penulisan variabel yang menentukan kurva harga pasangan trading. Meskipun kode Prop AMM di Solana adalah "kotak hitam", market maker ingin menjaga strategi mereka tetap rahasia, namun kita dapat menggunakan asumsi ini untuk memahami cara Obric mengimplementasikan Prop AMM di Sui: variabel penentu quote pasangan trading ditulis ke smart contract melalui fungsi update.

Terima kasih kepada @markoggwp atas penemuannya!

Menggunakan asumsi ini, kita menemukan arsitektur EVM memiliki hambatan besar yang membuat model Prop AMM Solana tidak dapat diterapkan di EVM.

Sekilas, di blockchain Layer 2 OP-Stack (seperti Base dan Unichain), transaksi diurutkan berdasarkan priority fee per Gas (mirip Solana yang mengurutkan berdasarkan Fee / CU).

Di EVM, operasi penulisan sangat mahal dalam hal Gas. Dibandingkan dengan pembaruan di Solana, biaya menulis satu nilai dengan opcode SSTORE di EVM sangat tinggi:

· SSTORE (0 → bukan 0): ~22.100 gas

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

· Swap AMM tipikal: ~200.000–300.000 gas

Catatan: Gas di EVM mirip dengan Compute Units (CU) di Solana. Angka gas SSTORE di atas diasumsikan hanya ada satu penulisan per transaksi (cold write), yang masuk akal karena biasanya tidak ada banyak pembaruan dalam satu transaksi.

Meski pembaruan tetap lebih murah daripada swap, penggunaan gas hanya sekitar 10 kali lipat (pembaruan mungkin melibatkan beberapa SSTORE), sedangkan di Solana, perbandingannya sekitar 1000 kali.

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

1. Konsumsi gas tinggi membuat priority fee sulit menjamin prioritas pembaruan, priority fee yang lebih rendah tidak dapat mencapai rasio fee/gas yang tinggi. Untuk memastikan pembaruan tidak didahului dan berada di bagian atas blok, diperlukan priority fee yang lebih tinggi, sehingga meningkatkan biaya.

2. Risiko arbitrase lebih tinggi di EVM, rasio gas pembaruan dan swap di EVM hanya 1:10, sedangkan di Solana 1:1000. Artinya, arbitrase hanya perlu menaikkan priority fee 10 kali untuk mendahului pembaruan market maker, sedangkan di Solana harus 1000 kali. Dengan rasio rendah ini, arbitrase lebih mungkin mendahului pembaruan harga untuk mendapatkan quote lama karena biayanya murah.

Beberapa inovasi (seperti EIP-1153 TSTORE, untuk penyimpanan sementara) menawarkan penulisan sekitar 100 gas, tetapi penyimpanan ini bersifat sementara, hanya berlaku dalam satu transaksi, tidak dapat digunakan untuk menyimpan pembaruan harga secara permanen untuk swap berikutnya (misal selama satu blok).

Bagaimana Membawa Prop AMM ke EVM?

Sebelum menjawab, mari jawab "mengapa harus dilakukan": pengguna selalu ingin mendapatkan quote perdagangan yang lebih baik, artinya perdagangan lebih menguntungkan. Prop AMM di Ethereum dan Layer 2 dapat memberikan quote kompetitif yang sebelumnya hanya tersedia di Solana atau centralized exchange.

Agar Prop AMM dapat diterapkan di EVM, mari kita tinjau salah satu alasan keberhasilannya di Solana:

· Perlindungan pembaruan di bagian atas blok: Di Solana, pembaruan Prop AMM berada di bagian atas blok, melindungi market maker dari front-running. Pembaruan berada di atas karena konsumsi compute unit sangat kecil, sehingga meski biayanya rendah, dapat mencapai rasio fee/CU tinggi, terutama dibandingkan swap.

Lalu, bagaimana membawa pembaruan Prop AMM di bagian atas blok ke blockchain Layer 2 EVM? Ada dua cara: menurunkan biaya penulisan, atau membuat jalur prioritas untuk pembaruan Prop AMM.

Karena masalah pertumbuhan status di EVM, menurunkan biaya penulisan tidak realistis, karena SSTORE murah akan menyebabkan serangan status sampah.

Kami mengusulkan untuk membuat jalur prioritas untuk pembaruan Prop AMM. Ini adalah solusi yang layak dan inti dari artikel ini.

Tim Uniswap @MarkToda mengusulkan metode baru, dengan smart contract penyimpanan global + strategi block builder khusus:

Cara kerjanya sebagai berikut:

· Smart contract penyimpanan global: Deploy smart contract sederhana sebagai penyimpanan key-value publik. Market maker menulis parameter kurva harga ke kontrak ini (misal set(ETH-USDC_CONCENTRATION, 4000)).

· Strategi builder: Ini adalah komponen off-chain kunci. Block builder mengenali transaksi yang dikirim ke smart contract penyimpanan global, mengalokasikan 5–10% Gas awal blok untuk transaksi pembaruan ini, dan mengurutkannya berdasarkan biaya untuk mencegah spam.

Catatan: Transaksi harus dikirim langsung ke alamat penyimpanan global, jika tidak tidak dapat dijamin berada di bagian atas blok.

Contoh algoritma block builder khusus dapat merujuk pada rblib.

Integrasi Prop AMM: Smart contract Prop AMM milik market maker akan membaca data kurva harga dari smart contract penyimpanan global saat swap, sehingga dapat memberikan quote.

Arsitektur ini dengan cerdas menyelesaikan dua masalah:

1. Perlindungan: Strategi builder menciptakan "jalur cepat", memastikan semua pembaruan harga di blok dieksekusi sebelum transaksi, menghilangkan risiko front-running.

2. Efisiensi biaya: Market maker tidak perlu bersaing dengan semua pengguna DeFi untuk mendapatkan transaksi di bagian atas blok dengan Gas Price tinggi, cukup bersaing di pasar biaya lokal untuk pembaruan yang dialokasikan di bagian atas blok, sehingga menurunkan biaya secara signifikan.

Transaksi pengguna akan dieksekusi berdasarkan kurva harga yang ditetapkan market maker pada pembaruan awal blok yang sama, memastikan quote tetap segar dan aman. Model ini mereplikasi lingkungan pembaruan murah dan prioritas tinggi di Solana ke EVM, membuka jalan bagi Prop AMM di EVM.

Namun, model ini juga memiliki beberapa kekurangan, yang akan saya bahas di akhir artikel ini untuk didiskusikan.

Kesimpulan

Kelangsungan Prop AMM bergantung pada penyelesaian masalah ekonomi inti: pembaruan murah dan eksekusi prioritas untuk mencegah front-running.

Meskipun arsitektur EVM standar membuat operasi semacam ini mahal dan berisiko, desain baru menawarkan pendekatan berbeda untuk mengatasi masalah ini. Dengan menggabungkan smart contract penyimpanan global on-chain dan strategi builder off-chain, dapat dibuat "jalur cepat" khusus yang menjamin pembaruan dieksekusi di bagian atas blok, sekaligus membangun pasar biaya lokal yang terkontrol. Ini tidak hanya membuat Prop AMM layak di EVM, tetapi juga dapat membawa perubahan bagi seluruh EVM DeFi yang bergantung pada pembaruan oracle di bagian atas blok.

Pertanyaan Terbuka

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

· Di Solana, sebagian besar volume AMM berasal dari satu agregator Jupiter, yang menyediakan SDK untuk memudahkan integrasi AMM. Namun di Layer 2 EVM, volume tersebar di banyak agregator dan tidak ada SDK publik, apakah ini menjadi tantangan bagi Prop AMM?

· Pembaruan Prop AMM di Solana hanya mengonsumsi sekitar 100 CU, bagaimana mekanisme implementasinya?

· Model jalur cepat hanya menjamin pembaruan di bagian atas blok. Jika ada beberapa swap dalam satu Flashblock, bagaimana market maker memperbarui harga di antara swap tersebut?

· Bisakah program EVM yang dioptimalkan ditulis dengan bahasa seperti Yul atau Huff, mirip dengan solusi optimasi Pinocchio di Solana?

· Bagaimana perbandingan Prop AMM dengan RFQ?

· Bagaimana mencegah market maker memberikan quote bagus di blok N untuk menarik pengguna, lalu memperbarui menjadi quote buruk di blok N+1? Bagaimana Jupiter mencegahnya?

· Fitur Ultra Signaling di Jupiter Ultra V3 memungkinkan Prop AMM membedakan traffic berbahaya dan tidak berbahaya, serta memberikan quote yang lebih ketat. Seberapa penting fitur agregator semacam ini bagi Prop AMM di EVM?

Tautan Asli