Bakit puno ng Prop AMM sa Solana, ngunit bakante pa rin ito sa EVM?

Orihinal na Pamagat: Must-Watch dApps After Monad Mainnet Launch

Orihinal na May-akda: Optimus, Tagapagtatag ng Waterloo Blockchain

Orihinal na Pagsasalin: Dingdang, Odaily

Ang Prop AMMs ay mabilis na nakakuha ng 40% ng kabuuang volume ng kalakalan sa Solana. Bakit hindi pa sila lumalabas sa EVM?

Ang mga Propesyonal na Automated Market Makers (Proprietary AMMs, o Prop AMMs) ay mabilis na nagiging pangunahing puwersa sa Solana DeFi ecosystem, na kasalukuyang nagbibigay ng higit sa 40% ng volume ng kalakalan sa mga pangunahing trading pairs. Ang mga espesyal na liquidity venue na ito, na pinapatakbo ng mga propesyonal na market maker, ay nakakapagbigay ng malalim na liquidity at mas kompetitibong pagpepresyo, pangunahing dahil sa kanilang kakayahang makabuluhang bawasan ang panganib ng mga market maker na ma-front-run para sa arbitrage gamit ang "stale quotes".

Pinagmulan ng larawan: dune.com

Gayunpaman, ang kanilang tagumpay ay halos eksklusibo sa Solana. Kahit sa mga mabilis at mababang-gastos na Layer 2 network gaya ng Base o Optimism, bihira pa ring makita ang Prop AMM sa EVM ecosystem. Bakit hindi sila nag-ugat sa EVM?

Tinututukan ng artikulong ito ang tatlong pangunahing tanong: Ano ang Prop AMM, anong mga teknikal at ekonomikong hadlang ang kinakaharap nila sa EVM chains, at anong mga bagong promising architecture ang posibleng magdala sa kanila sa unahan ng EVM DeFi.

Ano ang Prop AMM?

Ang Prop AMM ay isang automated market maker na ang liquidity at pagpepresyo ay aktibong pinamamahalaan ng isang solong propesyonal na market maker, sa halip na pasibong pinopondohan ng masa gaya ng tradisyonal na AMM.

Ang tradisyonal na AMM (tulad ng Uniswap v2) ay karaniwang gumagamit ng formula na x * y = k upang tukuyin ang presyo, kung saan ang x at y ay kumakatawan sa dami ng dalawang asset sa pool, at ang k ay isang constant. Sa Prop AMM naman, ang pricing formula ay hindi nakapirmi, kundi madalas na ina-update nang mataas ang frequency (karaniwan ay maraming beses bawat segundo). Karamihan sa mga internal mechanism ng Prop AMM ay "black box", kaya hindi alam ng publiko ang eksaktong algorithm na ginagamit. Gayunpaman, ang Prop AMM smart contract code ng Obric sa Sui chain ay open-source (salamat kay @markoggwp), at ang invariant k nito ay nakadepende sa internal variables na mult_x, mult_y, at concentration. Ipinapakita ng larawan sa ibaba kung paano patuloy na ina-update ng market maker ang mga variable na ito.

Kailangang linawin: Ang formula sa kaliwang bahagi ng pricing curve ng Obric ay mas kumplikado kaysa sa simpleng x*y, ngunit ang mahalagang punto sa pag-unawa sa Prop AMM ay—ito ay laging katumbas ng isang variable na invariant k, at ang market maker ay patuloy na ina-update ang k na ito upang i-adjust ang price curve.

Balik-aral: Paano tinutukoy ng AMM ang presyo?

Sa artikulong ito, madalas nating babanggitin ang konsepto ng "price curve". Ang price curve ang nagtatakda ng presyo na kailangang bayaran ng user kapag nagte-trade sa AMM, at ito rin ang bahagi na patuloy na ina-update ng market maker sa Prop AMM. Para mas maunawaan ito, balikan natin ang pricing method ng tradisyonal na AMM.

Halimbawa, sa Uniswap v2 WETH-USDC pool (ipagpalagay na walang fee). Ang presyo ay pasibong tinutukoy ng formula na x * y = k. Kung mayroong 100 WETH at 400,000 USDC sa pool, ang point sa curve ay x = 100, y = 400,000, at ang initial price ay 400,000 / 100 = 4,000 USDC/WETH. Kaya, k = 100 * 400,000 = 40,000,000.

Kung may trader na gustong bumili ng 1 WETH, kailangan niyang magdagdag ng USDC sa pool, kaya bababa ang WETH sa 99. Para mapanatili ang constant product k, ang bagong point (x, y) ay dapat nasa curve pa rin, kaya y = 40,000,000 / 99 ≈ 404,040.40. Ibig sabihin, nagbayad ang trader ng humigit-kumulang 4,040.40 USDC para sa 1 WETH, na mas mataas nang kaunti sa initial price. Ito ang tinatawag na "slippage". Ito ang dahilan kung bakit tinatawag na "price curve" ang x*y=k: lahat ng posibleng presyo ay dapat nasa curve na ito.

Bakit pipiliin ng market maker ang AMM design sa halip na centralized order book (CLOB)?

Ipaliwanag natin kung bakit gustong gumamit ng AMM design ang market maker. Isipin mong isa kang market maker na naglalagay ng quotes sa on-chain centralized limit order book (CLOB). Kung gusto mong i-update ang iyong quotes, kailangan mong kanselahin at palitan ang libu-libong limit orders. Kung may N kang orders, ang update cost ay O(N), na mabagal at mahal on-chain.

Paano kung magagawa mong i-representa ang lahat ng quotes gamit ang isang mathematical curve? Kailangan mo lang i-update ang ilang parameters ng curve na ito, kaya ang O(N) na operasyon ay nagiging O(1) na constant complexity.

Para mas mailarawan kung paano tumutugma ang "price curve" sa iba't ibang effective price range, tingnan natin ang SolFi na ginawa ng Ellipsis Labs—isang Prop AMM sa Solana. Bagama't hindi alam ang eksaktong price curve nito, nag-drawing ang Ghostlabs ng graph na nagpapakita ng effective price kapag nagpapalit ng iba't ibang dami ng SOL sa USDC sa isang Solana slot. Bawat linya ay kumakatawan sa ibang WSOL/USDC pool, na nagpapakita na maaaring sabay-sabay na umiiral ang maraming price levels. Habang ina-update ng market maker ang price curve, nagbabago rin ang effective price graph sa bawat slot.

Pinagmulan ng larawan: github

Ang mahalagang punto dito ay, sa pamamagitan ng pag-update lamang ng ilang parameters ng price curve, maaaring baguhin ng market maker ang effective price distribution anumang oras, nang hindi kinakailangang i-update isa-isa ang N orders. Ito ang core value proposition ng Prop AMM—pinapayagan nito ang market maker na magbigay ng dynamic at malalim na liquidity nang mas mataas ang capital at computational efficiency.

Bakit napaka-angkop ng Solana architecture para sa Prop AMM?

Ang Prop AMM ay isang "actively managed" system, ibig sabihin kailangan nito ng dalawang mahalagang kondisyon:

1. Mababa ang update cost (cheap updates)

2. Priority execution

Sa Solana, magkaugnay ang dalawang ito: ang mababang update cost ay kadalasang nangangahulugang ang update ay nakakakuha ng execution priority.

Bakit kailangan ito ng market maker? Una, ina-update nila ang price curve nang mabilis batay sa pagbabago ng inventory o index price ng asset (hal. presyo sa centralized exchange), kasabay ng bilis ng blockchain. Sa high-frequency chain gaya ng Solana, kung mataas ang update cost, mahirap magpatupad ng high-frequency adjustment.

Pangalawa, kung hindi maipaprioritize ng market maker ang update sa itaas ng block, maaaring ma-front-run ng arbitrageurs ang kanilang lumang quote, na magdudulot ng tiyak na pagkalugi. Kung wala ang dalawang katangiang ito, hindi magiging efficient ang operasyon ng market maker, at mas malala ang presyo para sa mga user.

Halimbawa, sa Prop AMM na HumidiFi sa Solana, ayon sa @SliceAnalytics, umaabot sa 74 beses kada segundo ang pag-update ng quote ng market maker na ito.

Maaaring magtanong ang mga galing sa EVM: "Ang slot ng Solana ay mga 400ms, paano nakakapag-update ng presyo nang maraming beses ang Prop AMM sa loob ng isang slot?"

Ang sagot ay nasa continuous architecture ng Solana, na ibang-iba sa discrete block model ng EVM.

· EVM: Karaniwan, ang mga transaksyon ay isinasagawa nang sunod-sunod pagkatapos ma-propose at ma-finalize ang isang buong block. Ibig sabihin, ang mga update na ipinadala sa gitna ay magiging epektibo lamang sa susunod na block.

· Solana: Ang leader validator node ay hindi naghihintay ng buong block, kundi hinahati ang mga transaksyon sa maliliit na data packet ("shred") at tuloy-tuloy na ibinobroadcast sa network. Sa isang slot, maaaring maraming swap, ngunit ang price update ng shred #1 ay para sa swap #1, at ang price update ng shred #2 ay para sa swap #2.

Tandaan: Ang Flashblocks ay katulad ng shred ng Solana. Ayon kay @Ashwinningg ng Anza Labs sa CBER conference, ang bawat 400ms slot ay may limit na 32,000 shred, katumbas ng 80 shred bawat millisecond. Kung sapat na ang 200ms Flashblocks para sa pangangailangan ng market maker kumpara sa continuous architecture ng Solana ay nananatiling bukas na tanong.

Bakit napakamura ng update sa Solana? At paano ito nagdudulot ng priority execution?

Una, bagama't black box ang implementation ng Prop AMM sa Solana, may mga library gaya ng Pinocchio na nagpapahintulot ng CU-optimized na pagsulat ng Solana programs. Ayon sa blog ng Helius, gamit ang library na ito, ang CU consumption ng Solana programs ay maaaring bumaba mula mga 4000 CU hanggang mga 100 CU.

Pinagmulan ng larawan: github

Pangalawa, sa mas mataas na antas, inuuna ng Solana ang mga transaksyon na may pinakamataas na Fee / Compute Units ratio (ang Compute Units ay katulad ng Gas sa EVM), katulad ng EVM.

· Kung gumagamit ng Jito, ang formula ay Jito Tip / Compute Units

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

Kung ikukumpara ang Compute Units ng Prop AMM update at Jupiter Swap, makikita na napakamura ng update, ratio ay 1:1000.

Prop AMM update: Ang simpleng curve update ay napakamura. Ang update ng Wintermute ay umaabot lang sa 109 CU, at ang kabuuang fee ay 0.000007506 SOL

Jupiter Swap: Ang swap sa pamamagitan ng Jupiter router ay umaabot sa ~100,000 CU, at ang kabuuang fee ay 0.000005 SOL

Dahil sa napakalaking pagkakaiba, kailangan lang magbayad ng market maker ng napakaliit na fee para sa update transaction upang makamit ang mas mataas na Fee/CU ratio kaysa sa swap, kaya't naisasagawa ang update sa itaas ng block at napoprotektahan ang sarili laban sa arbitrage attack.

Bakit hindi pa naisasakatuparan ang Prop AMM sa EVM?

Ipagpalagay na ang update ng Prop AMM ay nangangailangan ng pagsusulat ng variable na nagtatakda ng price curve ng trading pair. Bagama't black box ang Prop AMM code sa Solana, nais ng market maker na panatilihing lihim ang kanilang strategy, ngunit maaari nating gamitin ang assumption na ito upang maunawaan ang paraan ng Prop AMM implementation ng Obric sa Sui: ang variable na nagtatakda ng quote ng trading pair ay isinusulat sa smart contract sa pamamagitan ng update function.

Salamat kay @markoggwp sa pagkakatuklas!

Gamit ang assumption na ito, makikita natin na may malaking hadlang sa architecture ng EVM na nagpapahirap para sa Solana Prop AMM model na gumana sa EVM.

Balikan natin, sa OP-Stack Layer 2 blockchains (tulad ng Base at Unichain), ang mga transaksyon ay inuuna batay sa priority fee per Gas (katulad ng Solana na Fee / CU).

Sa EVM, napakataas ng Gas consumption ng write operations. Kumpara sa update sa Solana, ang pagsusulat ng isang value gamit ang SSTORE opcode sa EVM ay napakamahal:

· SSTORE (0 → non-0): ~22,100 gas

· SSTORE (non-0 → non-0): ~5,000 gas

· Typical AMM swap: ~200,000–300,000 gas

Tandaan: Ang Gas sa EVM ay katulad ng Compute Units sa Solana. Ang SSTORE gas numbers sa itaas ay batay sa isang write per transaction (cold write), na makatwiran dahil karaniwan ay hindi nagpapadala ng maraming update sa isang transaction.

Bagama't mas mura pa rin ang update kaysa sa swap, ang gas usage ratio ay mga 10x lang (maaaring maraming SSTORE sa update), samantalang sa Solana ay mga 1000x.

Nagbubunga ito ng dalawang konklusyon na nagpapataas ng panganib ng Solana Prop AMM model sa EVM:

1. Mataas na Gas consumption kaya mahirap tiyakin ang update priority, hindi sapat ang mababang priority fee para makamit ang mataas na fee/Gas ratio. Para matiyak na hindi mauunahan ang update at mapunta ito sa itaas ng block, kailangan ng mas mataas na priority fee, na nagpapataas ng gastos.

2. Mas mataas ang arbitrage risk sa EVM, ang update Gas sa EVM ay 1:10 lang kumpara sa swap Gas, samantalang sa Solana ay 1:1000. Ibig sabihin, kailangan lang ng arbitrageur na itaas ang priority fee ng 10x para ma-front-run ang update ng market maker, samantalang sa Solana ay 1000x. Sa ganitong mas mababang ratio, mas malamang na ma-front-run ng arbitrageur ang price update para samantalahin ang stale quote dahil mura lang ang gastos.

May ilang innovation (tulad ng EIP-1153 na TSTORE para sa temporary storage) na nagbibigay ng ~100 gas na write, ngunit pansamantala lang ito at epektibo lang sa loob ng isang transaction, kaya hindi magagamit para i-persist ang price update para sa mga susunod na swap (hal. sa buong block).

Paano madadala ang Prop AMM sa EVM?

Bago sagutin, sagutin muna natin ang "bakit": Laging gusto ng user ng mas magandang quote, ibig sabihin mas kapaki-pakinabang na trade. Ang Prop AMM sa Ethereum at Layer 2 ay maaaring magbigay ng kompetitibong quote na dati ay makukuha lang sa Solana o centralized exchange.

Para maging feasible ang Prop AMM sa EVM, balikan natin ang isa sa mga dahilan ng tagumpay nito sa Solana:

· Block-top update protection: Sa Solana, ang Prop AMM update ay nasa itaas ng block, kaya napoprotektahan ang market maker laban sa front-running. Nasa itaas ang update dahil napakababa ng compute unit consumption, kaya kahit mababa ang fee, mataas pa rin ang fee/CU ratio, lalo na kumpara sa swap.

Paano madadala ang block-top Prop AMM update sa Layer 2 EVM blockchain? Dalawang paraan: babaan ang write cost, o gumawa ng priority channel para sa Prop AMM update.

Dahil sa problema ng state growth sa EVM, hindi praktikal ang pagbawas ng write cost, dahil magdudulot ito ng spam attack sa state.

Iminumungkahi naming gumawa ng priority channel para sa Prop AMM update. Ito ang feasible na solusyon at ang pokus ng artikulong ito.

Iminungkahi ni @MarkToda ng Uniswap team ang isang bagong paraan gamit ang global storage smart contract + espesyal na block builder strategy:

Ganito ang proseso:

· Global storage contract: Magdeploy ng simpleng smart contract bilang public key-value storage. Isusulat ng market maker ang price curve parameters dito (hal. set(ETH-USDC_CONCENTRATION, 4000)).

· Builder strategy: Ito ang off-chain na mahalagang bahagi. Nakikilala ng block builder ang mga transaction na ipinapadala sa global storage contract, at inilalaan ang 5–10% ng block gas sa mga update transaction na ito, na inuuna batay sa fee para maiwasan ang spam.

Paalala: Kailangang direktang ipadala ang transaction sa global storage address, kung hindi ay hindi matitiyak ang block-top execution.

Para sa halimbawa ng custom block building algorithm, tingnan ang rblib.

Prop AMM integration: Babasahin ng Prop AMM contract ng market maker ang price curve data mula sa global storage contract kapag may swap, para magbigay ng quote.

Ang architecture na ito ay matalinong nilulutas ang dalawang problema:

1. Proteksyon: Gumagawa ang builder strategy ng "fast lane" na tinitiyak na lahat ng price update ay naisasagawa bago ang mga trade sa loob ng block, kaya tinatanggal ang panganib ng front-running.

2. Cost efficiency: Hindi na kailangang makipagkumpitensya ng market maker sa lahat ng DeFi user para sa mataas na Gas Price para makuha ang block-top transaction, kundi sa local fee market lang para sa reserved block-top update, kaya malaki ang tipid sa gastos.

Ang user trades ay isasagawa batay sa price curve na na-update ng market maker sa simula ng parehong block, kaya tinitiyak ang freshness at seguridad ng quote. Ang modelong ito ay muling nililikha ang low-cost, high-priority update environment ng Solana sa EVM, na nagbubukas ng daan para sa Prop AMM sa EVM.

Gayunpaman, may ilang kakulangan ang modelong ito, at iniiwan ko ang mga tanong na ito sa dulo ng artikulo para sa diskusyon.

Konklusyon

Ang feasibility ng Prop AMM ay nakasalalay sa paglutas ng core economic problem: mura at priority execution para maiwasan ang front-running.

Bagama't mataas ang cost at panganib ng ganitong operasyon sa standard EVM architecture, may mga bagong disenyo na nag-aalok ng iba't ibang solusyon. Sa pamamagitan ng pagsasama ng on-chain global storage smart contract at off-chain builder strategy, maaaring lumikha ng dedikadong "fast lane" na tinitiyak ang block-top update execution, habang nagtatatag ng local, controlled fee market. Hindi lang nito ginagawang feasible ang Prop AMM sa EVM, kundi maaari ring magdala ng pagbabago sa lahat ng EVM DeFi na umaasa sa block-top oracle update.

Mga Bukas na Tanong

· Sapat ba ang bilis ng Prop AMM sa EVM na may 200ms Flashblock para makipagkumpitensya sa continuous architecture ng Solana?

· Sa Solana, karamihan ng AMM traffic ay mula sa isang aggregator na Jupiter, na may SDK para madaling makakonekta ang AMM. Ngunit sa Layer 2 EVM, kalat ang traffic sa maraming aggregator at walang public SDK, magiging hamon ba ito para sa Prop AMM?

· Ang update ng Prop AMM sa Solana ay gumagamit lang ng mga 100 CU, paano ito naisasakatuparan?

· Ang fast lane model ay tinitiyak lang ang block-top update. Kung maraming swap sa isang Flashblock, paano mag-a-update ng presyo ang market maker sa pagitan ng mga swap?

· Maaari bang gumamit ng optimized EVM program na isinulat sa Yul o Huff, katulad ng Pinocchio optimization sa Solana?

· Paano ikukumpara ang Prop AMM sa RFQ?

· Paano maiiwasan na magbigay ang market maker ng magandang quote sa block N para akitin ang user, tapos mag-update ng masamang quote sa block N+1? Paano ito pinipigilan ng Jupiter?

· Pinapayagan ng Ultra Signaling feature ng Jupiter Ultra V3 ang Prop AMM na ihiwalay ang harmful at harmless traffic at magbigay ng mas mahigpit na quote. Gaano kahalaga ang ganitong aggregator feature para sa Prop AMM sa EVM?

Orihinal na Link