Dari Solana ke EVM: Jalur Baru untuk Proprietary AMM

Prop AMMs telah dengan cepat menguasai 40% volume perdagangan di Solana. Mengapa mereka belum hadir di EVM?

Proprietary AMMs (Prop AMMs) kini menjadi kekuatan utama dalam ekosistem DeFi Solana, menyumbang lebih dari 40% volume perdagangan pada pasangan utama. Platform khusus ini, yang dioperasikan oleh market maker profesional, menawarkan likuiditas dalam dan harga kompetitif dengan meminimalkan risiko market maker terhadap front-running oleh arbitrageur yang memanfaatkan kuotasi usang.

https://dune.com/the_defi_report/prop-amms

Namun, keberhasilan Prop AMMs masih terbatas di Solana. Mengapa mereka belum berkembang di ekosistem EVM, bahkan di Layer 2 yang cepat dan murah seperti Base atau Optimism?

Artikel ini mengulas definisi Prop AMMs, tantangan teknis dan ekonomi yang mereka hadapi di chain EVM, serta arsitektur baru yang berpotensi membawa Prop AMMs ke panggung utama DeFi EVM.

Apa itu Prop AMMs?

Prop AMM merupakan automated market maker di mana likuiditas dan harga pool dikelola secara aktif oleh satu market maker profesional, berbeda dengan AMM tradisional yang likuiditasnya disediakan publik secara pasif.

Berbeda dengan AMM tradisional yang menentukan harga menggunakan persamaan x * y = k, di mana x dan y adalah jumlah dua aset dalam pool dan k adalah konstanta tetap, Prop AMMs menggunakan formula berbeda yang biasanya diperbarui beberapa kali per detik. Karena Prop AMMs umumnya bersifat black box, formula yang digunakan tidak diketahui publik. Namun, kode smart contract Prop AMM milik Obric di Sui tersedia secara publik (terima kasih kepada @ markoggwp atas temuannya!), di mana invariant k bergantung pada variabel internal mult_x, mult_y, dan concentration. Gambar berikut menunjukkan market maker yang terus memperbarui variabel-variabel tersebut.

Perlu diperjelas, sisi kiri formula kurva harga Obric lebih kompleks dari x * y, namun hal terpenting untuk memahami Prop AMMs adalah nilainya sama dengan invariant k, yang diperbarui market maker untuk menyesuaikan kurva harga.

Refresher: Bagaimana harga ditentukan pada AMM?

Istilah “kurva harga” akan sering muncul dalam artikel ini, karena kurva tersebut menentukan harga yang dibayar pengguna saat trading di AMM dan menjadi fokus pembaruan market maker pada Prop AMM. Sebelum membahas Prop AMMs lebih dalam, penting memahami cara penentuan harga pada AMM. Ambil contoh pool Uniswap v2 WETH-USDC tanpa fee. Harga ditentukan secara pasif melalui rumus x * y = k, di mana x dan y adalah jumlah dua aset dalam pool, dan k adalah konstanta. Hanya titik-titik pada kurva yang merupakan harga yang dapat dibayar pengguna untuk trading.

Misal, pool WETH-USDC berisi 100 WETH dan 400.000 USDC. Titik pada kurva adalah x = 100 WETH, y = 400.000 USDC, sehingga harga awalnya 400.000 USDC / 100 WETH = 4.000 USDC per WETH. Dengan menghitung konstanta produk k, didapat xy = k = 40.000.000. Jika trader membeli 1 WETH, mereka menambahkan USDC ke pool, sehingga saldo WETH turun menjadi 99. Untuk menjaga konstanta k, titik x dan y baru harus tetap di kurva, sehingga saldo USDC naik menjadi 40.000.000 / 99 ≈ 404.040,40 USDC. Trader membayar 4.040,40 USDC untuk 1 WETH, harga efektif yang lebih tinggi dari $4.000 awal akibat price impact (slippage). Inilah alasan rumus x y = k disebut kurva harga, karena setiap harga yang mungkin harus berupa titik pada kurva tersebut.

Mengapa Market Maker memilih desain AMM daripada CLOB?

Mengapa market maker memilih AMM untuk market making? Bayangkan Anda adalah market maker di Central Limit Order Book (CLOB) onchain. Untuk memperbarui kuotasi, Anda harus membatalkan dan mengganti ribuan limit order. Jika ada N order, ini adalah operasi O(N) secara linier, sangat lambat dan mahal secara komputasi di onchain.

Bagaimana jika semua kuotasi dapat direpresentasikan sebagai satu kurva matematika? Alih-alih mengelola N order berbeda, Anda hanya perlu memperbarui beberapa parameter yang mendefinisikan seluruh kurva. Ini mengubah masalah O(N) menjadi O(1) yang konstan.

Untuk memvisualisasikan bagaimana kurva harga (misal x*y = k) menghasilkan berbagai harga efektif, mari lihat SolFi, Prop AMM besutan Ellipsis Labs. Walau kurva harga tidak diketahui publik, Ghostlabs membuat grafik berikut yang menunjukkan harga efektif SOL ke USDC untuk berbagai jumlah SOL yang ingin ditukar pada satu slot Solana (slot di Solana setara dengan block di EVM). Setiap garis mewakili pool WSOL/USDC berbeda, menunjukkan tier harga yang berbeda secara simultan. Saat market maker memperbarui kurva harga, grafik harga efektif akan berubah antar slot.

https://github.com/tryghostxyz/solfi-sim/blob/main/static/curves_333436948.png

Poin utama: dengan satu pembaruan pada beberapa nilai kurva harga, market maker dapat mengubah grafik harga efektif sesuai keinginan, tanpa harus memperbarui N order berbeda. Inilah nilai utama Prop AMM, memungkinkan market maker menyediakan likuiditas dinamis dan dalam dengan efisiensi modal dan komputasi tinggi.

Mengapa Arsitektur Solana sangat cocok untuk Prop AMMs

Prop AMMs dikelola aktif. Ini membutuhkan dua hal: pembaruan murah dan eksekusi prioritas. Di Solana, pembaruan murah menghasilkan eksekusi prioritas.

Mengapa market maker butuh dua hal ini? Pertama, market maker memperbarui kurva harga secepat chain berjalan, berdasarkan inventori dan perubahan harga indeks aset (misal dari centralized exchange). Di chain cepat seperti Solana, pembaruan akan mahal jika tidak murah.

Kedua, jika market maker tidak dapat menempatkan pembaruan di bagian atas blok, kuotasi usang akan diambil arbitrageur, menyebabkan kerugian pasti.

Tanpa kedua hal ini, market maker tidak bisa beroperasi efisien, dan harga trading pengguna jadi lebih buruk.

Contohnya, Prop AMM Solana seperti HumidiFi memperbarui kuotasi 74 kali per detik (data dari @ SliceAnalytics), seperti gambar berikut:

https://dune.com/queries/5980584/9644764

Dari sudut pandang EVM: “Jika slot Solana ~400ms, bagaimana Prop AMM bisa memperbarui harga beberapa kali dalam satu slot?”

Jawabannya ada pada arsitektur Solana yang bersifat kontinu, berbeda dari model blok diskret EVM.

• EVM: Transaksi dieksekusi berurutan saat blok lengkap diusulkan dan difinalisasi. Pembaruan di tengah blok baru tercermin di blok berikutnya.
• Solana: Validator leader tidak menunggu blok penuh. Ia memecah transaksi jadi “shreds” dan mengirimnya ke jaringan secara kontinu. Bisa ada beberapa swap dalam satu slot, namun pembaruan harga di shred #1 memengaruhi swap #1, pembaruan di shred #2 memengaruhi swap #2.

Catatan: Flashblocks mirip shred Solana. Menurut @ Ashwinningg dari Anza Labs, ada batas atas 32.000 shred per slot 400ms—80 shred per milidetik! Apakah Flashblocks 200ms cukup cepat bagi market maker dibanding arsitektur kontinu Solana masih jadi pertanyaan terbuka.

Lalu, mengapa pembaruan sangat murah di Solana, dan bagaimana ini menghasilkan eksekusi prioritas?

Meski implementasi Prop AMM Solana adalah black box, ada library seperti Pinocchio untuk membuat program Solana yang dioptimalkan Compute Units. Blog Helius membahas ini (di sini), yang dapat menurunkan program Solana dari ~4000 CU menjadi ~100 CU.

https://github.com/febo/p-token?tab=readme-ov-file#compute-units

Solana memprioritaskan transaksi dengan rasio Fee / Computer Units tertinggi (Compute Units analog Gas di EVM), mirip EVM.

• Jika menggunakan Jito, formulanya Jito Tip / Compute Units,
• jika tidak, Priority = (Prioritization fee + Base fee) / (1 + CU limit + Signature CUs + Write lock CUs) (https://solana.com/docs/core/fees)

Bandingkan Compute Units pembaruan Prop AMM dan Jupiter Swap: pembaruan Prop AMM sangat murah, rasio 1:1000.

Pembaruan Prop AMM: Pembaruan kurva sederhana sangat murah. Wintermute memperbarui hanya 109 CU, total biaya transaksi 0,000007506 SOL.

https://orb.helius.dev/tx/325EwPasEyXYuVqow9aGT44i17cZzd9G5GYPHxJr1JmLKwyWTS6rJgV6EP1svqExo9TnoqqmMF15si17x2s7wnSu?cluster=mainnet-beta&advanced=true&tab=summary

Jupiter Swap: Swap via Jupiter bisa memakan ~100.000 CU. Total biaya transaksi 0,000005 SOL.

https://orb.helius.dev/tx/4SbYyAEq6QBNv5YW517fLRatEPvBvh1kDit3C8NL84uBRXuE7FFEsVuX6BDG44reXtMt5WZCGxN7rS38jt4RSNY9?cluster=mainnet-beta&advanced=true&tab=summary)

Perbedaan besar ini memungkinkan market maker mendapat eksekusi prioritas dengan membayar fee kecil pada transaksi pembaruan dan memperoleh rasio Fee/CU jauh lebih tinggi daripada swapper. Ini menjamin pembaruan dieksekusi murah dan di bagian atas blok, melindungi dari arbitrage toxic flow.

Mengapa Prop AMMs belum hadir di EVM?

Asumsikan pembaruan Prop AMM melibatkan penulisan variabel penentu kurva harga pasangan trading. Kode Prop AMM Solana adalah black box, namun Prop AMM Obric di Sui menulis variabel penentu kuotasi ke smart contract melalui fungsi pembaruan.

https://suiscan.xyz/mainnet/object/0xb84e63d22ea4822a0a333c250e790f69bf5c2ef0c63f4e120e05a6415991368f/contracts

Terima kasih kepada @ markoggwp atas temuannya!

Dengan asumsi ini, arsitektur EVM menjadi hambatan besar bagi model Prop AMM Solana.

Di blockchain Layer 2 OP-Stack seperti Base dan Unichain, transaksi diurutkan berdasarkan Priority Fee per Gas (mirip Fee / CU di Solana).

Di EVM, penggunaan gas untuk penulisan sangat tinggi. Penulisan storage satu nilai via opcode SSTORE sangat mahal dibandingkan pembaruan di Solana.

• SSTORE (nol ke non-nol): ~22.100 gas
• SSTORE (non-nol ke non-nol): ~5.000 gas
• Swap AMM tipikal: ~200.000 - 300.000 gas

Gas di EVM setara dengan Compute Units di Solana.

Angka SSTORE di atas diasumsikan hanya ada 1 penulisan per transaksi (cold writes), masuk akal karena pembaruan biasanya satu transaksi.

Pembaruan memang lebih murah dari swap, namun rasio penggunaan gas hanya ~10x (pembaruan bisa melibatkan beberapa SSTORE), dibanding ~1000x di Solana.

Dua kesimpulan yang membuat model Prop AMM Solana lebih berisiko di EVM:

1. Karena penggunaan gas tinggi, fee prioritas kecil tidak menghasilkan Priority Fee / Gas tinggi. Agar pembaruan tidak di-front-run dan berada di Top of Block, dibutuhkan fee prioritas lebih besar, sehingga lebih mahal.
2. Rasio penggunaan gas pembaruan dan swap di EVM hanya 1:10, dibanding 1:1000 di Solana. Arbitrageur di EVM hanya perlu menaikkan Priority Fee 10x dari transaksi pembaruan untuk mengalahkan dan front-run pembaruan market maker, dibandingkan 1000x di Solana. Dalam rasio rendah di EVM, arbitrageur lebih mudah front-run pembaruan harga untuk mengambil kuotasi usang.

Inovasi seperti EIP-1153 (TSTORE untuk transient storage) menawarkan penulisan 100-gas, namun storage ini hanya bertahan selama satu transaksi dan tidak dapat digunakan untuk menyimpan pembaruan harga untuk swap berikutnya (misal selama satu blok).

Bagaimana Prop AMMs bisa hadir di EVM?

Sebelum menjawab, mari pahami “mengapa”. Pengguna selalu menginginkan kuotasi trading terbaik. Prop AMMs di Ethereum dan Layer 2 akan menghadirkan kuotasi kompetitif yang sebelumnya hanya tersedia di Solana dan centralized exchange.

Agar Prop AMMs layak di EVM, ingat alasan Prop AMMs sukses di Solana:

• Pembaruan Prop AMM di Top of Block di Solana melindungi market maker dari front-run. Pembaruan berada di ToB karena penggunaan Compute Units sangat rendah, sehingga fee kecil tetap menghasilkan Fee / CUs tinggi, terutama dibanding swap.

Bagaimana membawa pembaruan Prop AMM Top of Block ke Layer 2 EVM? Dua pendekatan: menurunkan biaya penulisan, atau membuat jalur prioritas untuk pembaruan Prop AMM.

Opsi menurunkan biaya penulisan kecil kemungkinan berhasil karena masalah pertumbuhan state di EVM—SSTORE murah bisa memicu spam state.

Kami mengusulkan solusi pendekatan kedua: membuat jalur prioritas untuk pembaruan Prop AMM.

Pendekatan inovatif dari @ MarkToda tim Uniswap, menawarkan solusi melalui smart contract Global Storage (repo di sini) dan kebijakan builder khusus.

https://github.com/flashbots/global-storage-smart-contract

Cara kerjanya:

• Global Storage Contract: Satu smart contract sederhana sebagai public key-value store. Market maker menulis parameter kurva harga ke contract ini (misal set(ETH-USDC_CONCENTRATION, 4000)).

Builder Policy: Komponen offchain penting. Block builder menerapkan kebijakan yang mengenali transaksi ke alamat Global Storage. Kebijakan ini mengalokasikan 5-10% gas blok khusus untuk transaksi pembaruan, diurutkan berdasarkan priority fee, untuk mencegah spam.

Penting: transaksi harus memiliki to ke alamat Global Storage, agar hanya transaksi pembaruan yang berada di Top of Block.

• Contoh algoritma custom block building menggunakan rblib di bawah ini.

• Integrasi Prop AMM: Smart contract Prop AMM membaca data kurva harga dari Global Storage saat swap, untuk menentukan kuotasi pengguna.

Arsitektur ini menyelesaikan dua masalah utama:

• Perlindungan: Kebijakan builder menciptakan “jalur cepat” yang menjamin semua pembaruan harga dieksekusi sebelum swap dalam satu blok, menghilangkan risiko front-running dalam blok yang sama.
• Efisiensi Biaya: Market maker hanya bersaing dengan transaksi pembaruan lain dalam fee market lokal untuk bagian ToB yang dipesan, bukan dengan seluruh pengguna DeFi. Ini sangat menurunkan biaya eksekusi prioritas.

Swap pengguna dieksekusi terhadap kurva harga yang diperbarui market maker di awal blok yang sama, memastikan kuotasi segar dan terlindungi. Model ini mereplikasi lingkungan pembaruan murah dan prioritas tinggi seperti di Solana, membuka era baru efisiensi pasar di EVM.

Namun, ada kekurangan model ini yang menjadi pertanyaan terbuka untuk diskusi di akhir artikel.

Kesimpulan

Keberhasilan Proprietary AMMs bergantung pada solusi masalah inti ekonomi: eksekusi prioritas murah untuk mencegah front-running.

Arsitektur EVM standar membuatnya mahal dan berisiko, namun desain baru menawarkan pendekatan berbeda. Dengan menggabungkan smart contract Global Storage onchain dan kebijakan builder offchain, kita dapat menciptakan “jalur cepat” khusus pembaruan harga. Model ini menjamin eksekusi Top of Block untuk pembaruan oracle dan membangun fee market lokal, mengatasi hambatan utama dan membuat Prop AMMs tidak hanya mungkin, tetapi berpotensi transformatif untuk seluruh DeFi berbasis EVM yang bergantung pada pembaruan oracle Top of Block.

Pertanyaan Terbuka

• Apakah Prop AMMs di EVM dengan kecepatan Flashblock 200ms cukup cepat untuk bersaing dengan arsitektur kontinu Solana?
• Di Solana, sebagian besar orderflow AMM berasal dari satu aggregator, Jupiter, yang menyediakan SDK untuk integrasi AMM. Di Layer 2 EVM, orderflow tersebar di banyak aggregator tanpa SDK publik. Apakah ini tantangan bagi Prop AMMs di EVM?
• Bagaimana Prop AMMs di Solana hanya menggunakan ~100 CU untuk pembaruannya?
• Model jalur cepat hanya menempatkan pembaruan Prop AMM di Top of Block. Dengan Flashblock hanya 200ms, bagaimana jika ada beberapa swap dalam satu Flashblock dan market maker ingin memperbarui harga di antara trade tersebut?
• Bisakah Yul atau Huff digunakan untuk menulis program EVM yang dioptimalkan, seperti Pinocchio untuk Solana?
• Bagaimana Prop AMMs dibandingkan RFQ?
• Bagaimana mencegah market maker memberi kuotasi bagus di blok N untuk memancing transaksi di blok N+1, lalu memperbarui kuotasi buruk di blok N+1? Bagaimana Jupiter mencegahnya?
• Jupiter Ultra V3 memperkenalkan “Ultra Signaling” yang memungkinkan Prop AMMs membedakan toxic flow dan non-toxic flow, sehingga kuotasi bisa 3 bps lebih ketat. Seberapa penting fitur aggregator seperti ini untuk Prop AMMs di EVM?

P.S: Saya sedang mencari slot pembicara konferensi untuk membahas topik ini. Jika Anda terhubung dengan event selama Devconnect, silakan hubungi saya untuk peluang berbicara!

Disclaimer:

1. Artikel ini diterbitkan ulang dari [0xOptimus]. Hak cipta sepenuhnya milik penulis asli [0xOptimus]. Jika ada keberatan atas penerbitan ulang ini, silakan hubungi tim Gate Learn untuk penanganan segera.
2. Disclaimer: Pandangan dan opini dalam artikel ini sepenuhnya milik penulis dan bukan merupakan saran investasi.
3. Terjemahan artikel ke bahasa lain dilakukan oleh tim Gate Learn. Kecuali disebutkan, dilarang menyalin, mendistribusikan, atau menjiplak artikel terjemahan.