ชื่อเรื่องต้นฉบับ: dApps ที่น่าจับตามองหลังการเปิดตัว Monad Mainnet

ผู้เขียนต้นฉบับ: Optimus ผู้ก่อตั้ง Waterloo Blockchain

ผู้แปลต้นฉบับ: Dingdang, Odaily Planet Daily

Proprietary AMMs (Prop AMMs) ได้ครองส่วนแบ่ง 40% ของปริมาณการซื้อขายทั้งหมดของ Solana อย่างรวดเร็ว ทำไมพวกเขาถึงยังไม่อยู่บน EVM ล่ะ?

Proprietary Automated Market Makers (Prop AMMs) กำลังกลายเป็นกำลังสำคัญในระบบนิเวศ Solana DeFi อย่างรวดเร็ว โดยปัจจุบันมีส่วนสนับสนุนปริมาณการซื้อขายมากกว่า 40% ในคู่สกุลเงินหลัก ผู้ให้บริการสภาพคล่องเฉพาะทางเหล่านี้ซึ่งดำเนินการโดย Market Makers มืออาชีพ มอบสภาพคล่องที่เข้มข้นและราคาที่แข่งขันได้มากขึ้น เนื่องจากช่วยลดความเสี่ยงจากการเก็งกำไรแบบ Front-running โดยใช้ราคาที่ค้างอยู่ได้อย่างมาก

ที่มาของรูปภาพ: dune.com

อย่างไรก็ตาม ความสำเร็จของพวกเขานั้นแทบจะจำกัดอยู่แค่ Solana เท่านั้น แม้แต่บนเครือข่าย Layer 2 ที่รวดเร็วและต้นทุนต่ำอย่าง Base หรือ Optimism Prop AMM ก็ยังคงหาได้ยากในระบบนิเวศ EVM เหตุใดจึงยังไม่หยั่งรากลงใน EVM

บทความนี้มุ่งเน้นไปที่คำถามสามข้อ ได้แก่ Prop AMM คืออะไร อุปสรรคทางเทคนิคและเศรษฐกิจใดบ้างที่พวกมันเผชิญในเครือข่าย EVM และสถาปัตยกรรมใหม่ๆ ที่น่าจับตามองซึ่งอาจนำพวกมันมาสู่แถวหน้าของ EVM DeFi ในท้ายที่สุด

Prop AMM คืออะไร Prop AMM คือผู้สร้างตลาดอัตโนมัติ (AMM) ซึ่งผู้สร้างตลาดมืออาชีพเพียงคนเดียวจะบริหารจัดการสภาพคล่องและการกำหนดราคาอย่างแข็งขัน แทนที่จะพึ่งพาเงินทุนแบบพาสซีฟจากสาธารณะเหมือนใน AMM แบบดั้งเดิม AMM แบบดั้งเดิม (เช่น Uniswap v2) มักใช้สูตร x * y = k ในการกำหนดราคา โดยที่ x และ y แทนปริมาณของสินทรัพย์สองรายการในพูลตามลำดับ และ k คือค่าคงที่ อย่างไรก็ตาม ใน Prop AMM สูตรการกำหนดราคาจะไม่คงที่ แต่จะมีการอัปเดตบ่อยครั้ง (โดยทั่วไปหลายครั้งต่อวินาที) เนื่องจากกลไกภายในของ Prop AMM ส่วนใหญ่คือ "กล่องดำ" อัลกอริทึมที่แน่ชัดที่ใช้จึงไม่เป็นที่ทราบแน่ชัด อย่างไรก็ตาม โค้ดสำหรับสัญญาอัจฉริยะ Prop AMM ของ Obric บนเครือข่าย Sui นั้นเปิดเผยต่อสาธารณะ (ขอขอบคุณ @markoggwp สำหรับการค้นพบของเขา) และค่าคงที่ k จะขึ้นอยู่กับตัวแปรภายใน mult_x, mult_y และ concentration แผนภาพด้านล่างแสดงให้เห็นว่าผู้ดูแลสภาพคล่องอัปเดตตัวแปรเหล่านี้อย่างต่อเนื่องอย่างไร

สิ่งหนึ่งที่ต้องชี้แจงให้ชัดเจนคือ สูตรทางด้านซ้ายของเส้นราคา Obric นั้นซับซ้อนกว่า x*y ธรรมดา แต่กุญแจสำคัญในการทำความเข้าใจ Prop AMM คือ สูตรนี้จะมีค่าเท่ากับ k คงที่แบบเปลี่ยนแปลงได้เสมอ และผู้ดูแลสภาพคล่องจะอัปเดต k นี้อย่างต่อเนื่องเพื่อปรับเส้นราคา

บทวิจารณ์: AMM กำหนดราคาอย่างไร

ในบทความนี้ เราจะกล่าวถึงแนวคิดของ "เส้นราคา" หลายครั้ง เส้นราคาเป็นตัวกำหนดราคาที่ผู้ใช้ต้องจ่ายเมื่อใช้ธุรกรรม AMM และเป็นส่วนที่ผู้ดูแลสภาพคล่องอัปเดตอย่างต่อเนื่องใน Prop AMM เพื่อให้เข้าใจเรื่องนี้ได้ดียิ่งขึ้น เรามาทบทวนวิธีการกำหนดราคาของ AMM แบบดั้งเดิมกันก่อน ยกตัวอย่างพูล WETH-USDC บน Uniswap v2 (สมมติว่าไม่มีค่าธรรมเนียม) ราคาจะถูกกำหนดโดยสูตร x * y = k สมมติว่ามี 100 WETH และ 400,000 USDC อยู่ในพูล จุดโค้งคือ x = 100 และ y = 400,000 ซึ่งสอดคล้องกับราคาเริ่มต้นที่ 400,000 / 100 = 4,000 USDC/WETH จากนี้ ค่าคงที่ k = 100 * 400,000 = 40,000,000 หากเทรดเดอร์ต้องการซื้อ 1 WETH พวกเขาจำเป็นต้องเพิ่ม USDC เข้าไปในพูล โดยลด WETH ในพูลให้เหลือ 99 เพื่อรักษาค่าผลิตภัณฑ์ k ให้คงที่ จุดใหม่ (x, y) จะต้องยังคงอยู่บนเส้นโค้ง ดังนั้น y จึงต้องกลายเป็น 40,000,000 / 99 ≈ 404,040.40 ซึ่งหมายความว่าเทรดเดอร์จ่ายเงินประมาณ 4,040.40 USDC สำหรับ 1 WETH ซึ่งสูงกว่าราคาเริ่มต้นเล็กน้อย ปรากฏการณ์นี้เรียกว่า "slippage" นี่คือเหตุผลที่ x*y=k ถูกเรียกว่า "เส้นราคา": ราคาที่ซื้อขายได้ใดๆ จะต้องอยู่บนเส้นโค้งนี้

ทำไมผู้ดูแลสภาพคล่องจึงเลือกการออกแบบ AMM แทนสมุดคำสั่งซื้อขายแบบรวมศูนย์ (CLOB)

มาอธิบายกันว่าทำไมผู้ดูแลสภาพคล่องจึงต้องการใช้การออกแบบ AMM ในการสร้างสภาพคล่อง ลองนึกภาพว่าคุณเป็นผู้ดูแลสภาพคล่อง (market maker) ที่เสนอราคาในสมุดคำสั่งซื้อขายแบบจำกัด (clob order) บนเครือข่าย (on-chain) การจะอัปเดตราคาของคุณ คุณต้องยกเลิกและแทนที่คำสั่งซื้อขายแบบจำกัดจำนวนหลายพันรายการ หากคุณมีคำสั่งซื้อขาย N รายการ การอัปเดตจะเป็นการดำเนินการแบบ O(N) ซึ่งใช้เวลานานและมีค่าใช้จ่ายสูงบนเครือข่ายจะเป็นอย่างไรหากคุณสามารถแสดงราคาเสนอทั้งหมดด้วยเส้นโค้งทางคณิตศาสตร์เส้นเดียว คุณเพียงแค่ต้องอัปเดตพารามิเตอร์บางตัวที่กำหนดเส้นโค้งนี้ โดยแปลงการดำเนินการ O(N) ให้มีความซับซ้อนคงที่ O(1) เพื่อให้เห็นภาพว่า "เส้นราคา" สอดคล้องกับช่วงราคาที่มีผลแตกต่างกันอย่างไร เราสามารถอ้างอิง SolFi ซึ่งเป็น Prop AMM ที่พัฒนาโดย Ellipsis Labs ถึงแม้ว่าเส้นราคาเฉพาะของมันจะยังไม่เป็นที่รู้จักและถูกซ่อนไว้ แต่ Ghostlabs ได้วาดกราฟแสดงราคาที่มีผลเมื่อแลกเปลี่ยน SOL จำนวนต่างๆ เป็น USDC ภายในช่อง Solana (ช่วงเวลาบล็อก) แต่ละเส้นแสดงกลุ่ม WSOL/USDC ที่แตกต่างกัน ซึ่งบ่งชี้ว่าสามารถมีระดับราคาได้หลายระดับพร้อมกัน เมื่อผู้ดูแลสภาพคล่องอัปเดตเส้นราคา กราฟราคาที่มีผลนี้จะเปลี่ยนแปลงไปตามช่องต่างๆ ด้วย

ที่มาของรูปภาพ: github

ประเด็นสำคัญคือ การอัปเดตพารามิเตอร์ของเส้นราคาเพียงเล็กน้อย จะทำให้ผู้ดูแลสภาพคล่องสามารถเปลี่ยนแปลงการกระจายราคาที่มีผลได้ตลอดเวลาโดยไม่ต้องแก้ไขคำสั่ง N คำสั่งทีละคำสั่ง นี่คือคุณค่าหลักของ Prop AMM ที่ช่วยให้ผู้ดูแลสภาพคล่องสามารถมอบสภาพคล่องแบบไดนามิกและเชิงลึก พร้อมด้วยเงินทุนและประสิทธิภาพในการคำนวณที่สูงขึ้น

เหตุใดสถาปัตยกรรมของ Solana จึงเหมาะสมกับ Prop AMM?

Prop AMM เป็นระบบที่ "มีการจัดการเชิงรุก" ซึ่งหมายความว่าต้องมีเงื่อนไขสำคัญสองประการ:

1. การอัปเดตราคาประหยัด

2. การดำเนินการตามลำดับความสำคัญ

บน Solana ทั้งสองสิ่งนี้เสริมซึ่งกันและกัน: การอัปเดตราคาถูกมักหมายความว่าการอัปเดตสามารถดำเนินการตามลำดับความสำคัญได้

ทำไมผู้ดูแลตลาดจึงต้องการสองสิ่งนี้? ประการแรก พวกเขาจะอัปเดตเส้นโค้งราคาอย่างต่อเนื่องตามความเร็วของบล็อกเชนโดยอิงตามการเปลี่ยนแปลงของสินค้าคงคลังหรือความผันผวนของราคาดัชนีสินทรัพย์ (เช่น ราคาแลกเปลี่ยนรวมศูนย์) บนเครือข่ายความถี่สูงอย่าง Solana หากต้นทุนการอัปเดตสูงเกินไป การปรับความถี่สูงจะทำได้ยาก

ประการที่สอง หากผู้สร้างตลาดไม่สามารถจัดคิวการอัปเดตไว้ที่ด้านบนของบล็อก ราคาเสนอซื้อเดิมของพวกเขาจะถูก "คัดลอก" โดยผู้ทำการเก็งกำไร ส่งผลให้เกิดการขาดทุนที่หลีกเลี่ยงไม่ได้ หากไม่มีคุณสมบัติทั้งสองนี้ ผู้สร้างตลาดจะไม่สามารถดำเนินการอย่างมีประสิทธิภาพ และผู้ใช้จะได้รับราคาซื้อขายที่แย่ลง

ใช้ Solana Prop AMM HumidiFi เป็นตัวอย่าง จากข้อมูลของ @SliceAnalytics ผู้ดูแลตลาดรายนี้อัปเดตราคาเสนอซื้อสูงสุด 74 ครั้งต่อวินาที

จาก EVM ผู้เล่นอาจถามว่า "สล็อตของ Solana มีขนาดประมาณ 400 มิลลิวินาที Prop AMM จะอัปเดตราคาหลายครั้งภายในสล็อตเดียวได้อย่างไร"

คำตอบอยู่ที่สถาปัตยกรรมแบบต่อเนื่องของ Solana ซึ่งแตกต่างโดยพื้นฐานจากโมเดลบล็อกแบบแยกส่วนของ EVM · EVM: โดยทั่วไปธุรกรรมจะดำเนินการตามลำดับหลังจากเสนอและเสร็จสิ้นบล็อกเต็ม ซึ่งหมายความว่าการอัปเดตที่ส่งระหว่างบล็อกจะไม่มีผลจนกว่าจะถึงบล็อกถัดไป · Solana: ผู้ตรวจสอบความถูกต้องของผู้นำจะไม่รอให้บล็อกเต็ม แต่จะแบ่งธุรกรรมออกเป็นแพ็กเก็ตขนาดเล็ก (เรียกว่า "shreds") และกระจายธุรกรรมไปยังเครือข่ายอย่างต่อเนื่อง การสลับสับเปลี่ยนหลายครั้งสามารถเกิดขึ้นได้ภายในสล็อตเดียว แต่การอัปเดตราคาของ shred #1 จะส่งผลต่อ swap #1 และการอัปเดตราคาของ shred #2 จะส่งผลต่อ swap #2 หมายเหตุ: Flashblocks มีลักษณะคล้ายกับ shred ของ Solana อ้างอิงจาก @Ashwinningg จาก Anza Labs ในงานประชุม CBER สล็อต 400 มิลลิวินาทีแต่ละสล็อตจะถูกจำกัดที่ 32,000 shreds ซึ่งเทียบเท่ากับ 80 shreds ต่อมิลลิวินาที คำถามที่ยังไม่ได้รับคำตอบคือ Flashblocks ความเร็ว 200 มิลลิวินาทีจะเร็วพอที่จะตอบสนองความต้องการของ Market Maker หรือไม่เมื่อเทียบกับสถาปัตยกรรมแบบต่อเนื่องของ Solana

แล้วทำไมการอัปเดตบน Solana ถึงราคาถูกจัง? และสิ่งนี้นำไปสู่การดำเนินการตามลำดับความสำคัญได้อย่างไร?

ประการแรก แม้ว่าการนำ Prop AMM ไปใช้บน Solana จะเป็นกล่องดำ แต่ก็มีไลบรารีอย่าง Pinocchio ที่สามารถเพิ่มประสิทธิภาพโปรแกรมของ Solana สำหรับ CU ได้ บล็อกของ Helius มีบทนำที่ยอดเยี่ยมเกี่ยวกับเรื่องนี้ โดยแสดงให้เห็นว่าการใช้ไลบรารีนี้ โปรแกรม Solana สามารถลดการใช้ CU จากประมาณ 4,000 CU เหลือประมาณ 100 CU ได้

ที่มาของรูปภาพ: github

มาดูส่วนที่สองกัน ในระดับสูง Solana ให้ความสำคัญกับธุรกรรมโดยเลือกธุรกรรมที่มีอัตราส่วน ค่าธรรมเนียม / หน่วยประมวลผล สูงที่สุด (หน่วยประมวลผลจะคล้ายกับ EVM gas) คล้ายกับ EVM

· โดยเฉพาะอย่างยิ่ง หากใช้ Jito สูตรคือ Jito Tip / หน่วยประมวลผล

· หากไม่มี Jito: ลำดับความสำคัญ = (ค่าธรรมเนียมลำดับความสำคัญ + ค่าธรรมเนียมพื้นฐาน) / (1 + CU Cap + Signature CU + Write Lock CU)

เมื่อเปรียบเทียบหน่วยประมวลผลของการอัปเดต Prop AMM และ Jupiter Swap เราจะเห็นว่าการอัปเดตมีราคาถูกมาก โดยมีอัตราส่วน 1:1000

การอัปเดต Prop AMM: การอัปเดตเส้นโค้งแบบง่ายมีราคาถูกมาก การอัปเดต Wintermute มีราคาต่ำถึง 109 CU และมีค่าธรรมเนียมรวมเพียง 0.000007506 SOL

Jupiter Swaps: ค่าสวอปที่ส่งผ่าน Jupiter สามารถสูงถึง ~100,000 CU และมีค่าธรรมเนียมรวม 0.000005 SOL

เนื่องจากความแตกต่างที่มากนี้ ผู้สร้างตลาดจึงต้องจ่ายค่าธรรมเนียมเพียงเล็กน้อยสำหรับธุรกรรมการอัปเดต ซึ่งจะทำให้ได้อัตราส่วนค่าธรรมเนียม/CU ที่สูงกว่าสวอปมาก จึงมั่นใจได้ว่าการอัปเดตจะดำเนินการที่ด้านบนสุดของบล็อกและป้องกันตนเองจากการโจมตีแบบเก็งกำไร

เหตุใดจึงยังไม่มีการนำ Prop AMM มาใช้งานบน EVM

สมมติว่าการอัปเดต Prop AMM เกี่ยวข้องกับการเขียนตัวแปรที่กำหนดเส้นราคาของคู่ซื้อขาย แม้ว่าโค้ด Prop AMM บน Solana จะเป็น "กล่องดำ" และผู้ดูแลสภาพคล่องต้องการเก็บกลยุทธ์ของตนไว้เป็นความลับ แต่เราสามารถใช้สมมติฐานนี้เพื่อทำความเข้าใจว่า Obric นำ Prop AMM มาใช้งานบน Sui ได้อย่างไร โดยตัวแปรที่กำหนดราคาเสนอซื้อของคู่ซื้อขายจะถูกเขียนลงในสัญญาอัจฉริยะผ่านฟังก์ชันอัปเดต

ขอขอบคุณ @markoggwp สำหรับการค้นพบนี้!

ด้วยการใช้สมมติฐานนี้ เราได้ค้นพบว่าสถาปัตยกรรมของ EVM มีอุปสรรคสำคัญที่ทำให้โมเดล Prop AMM ของ Solana ไม่สามารถใช้งานได้บน EVM

โปรดจำไว้ว่าบนบล็อกเชนเลเยอร์ 2 ของ OP-Stack เช่น Base และ Unichain ธุรกรรมจะถูกเรียงลำดับตามลำดับความสำคัญของค่าธรรมเนียมต่อก๊าซ (คล้ายกับการเรียงลำดับค่าธรรมเนียม/CU ของ Solana)

บน EVM การดำเนินการเขียนมีต้นทุนก๊าซที่สูงมาก เมื่อเทียบกับการอัปเดต Solana การเขียนค่าบน EVM ผ่าน opcode SSTORE นั้นมีราคาแพงอย่างน่าประหลาดใจ: · SSTORE (0 → not-0): ~22,100 gas · SSTORE (not-0 → not-0): ~5,000 gas · การสลับ AMM ทั่วไป: ~200,000–300,000 gas หมายเหตุ: Gas บน EVM นั้นคล้ายคลึงกับหน่วยประมวลผล (CU) บน Solana ตัวเลข SSTORE gas ด้านบนถือว่ามีการเขียนเพียงครั้งเดียวต่อธุรกรรม (การเขียนแบบเย็น) ซึ่งถือว่าสมเหตุสมผลเนื่องจากโดยทั่วไปคุณจะไม่ส่งการอัปเดตหลายครั้งในธุรกรรมเดียว แม้ว่าการอัปเดตจะยังคงถูกกว่าการสลับ แต่การใช้ gas จะสูงกว่าเพียงประมาณ 10 เท่าเท่านั้น (การอัปเดตอาจเกี่ยวข้องกับ SSTORE หลายรายการ) ในขณะที่บน Solana สูงกว่าประมาณ 1,000 เท่า สิ่งนี้นำไปสู่ผลที่ตามมาสองประการ ทำให้โมเดล Solana Prop AMM เดียวกันมีความเสี่ยงมากขึ้นบน EVM: 1. การใช้ gas สูงทำให้ยากต่อการจัดลำดับความสำคัญของการอัปเดตด้วยค่าธรรมเนียมตามลำดับความสำคัญ ค่าธรรมเนียมลำดับความสำคัญต่ำช่วยป้องกันอัตราส่วนค่าธรรมเนียมต่อค่าแก๊สที่สูง เพื่อให้แน่ใจว่าการอัปเดตไม่ใช่รายการนำหน้าและถูกวางไว้บนบล็อกสูงสุด จึงจำเป็นต้องเรียกเก็บค่าธรรมเนียมลำดับความสำคัญที่สูงขึ้น ซึ่งจะเพิ่มต้นทุน 2. ความเสี่ยงในการทำกำไรจากการซื้อขายแบบ Arbitrage สูงกว่าใน EVM อัตราส่วนของก๊าซอัปเดตต่อก๊าซแลกเปลี่ยนบน EVM อยู่ที่ 1:10 เท่านั้น ในขณะที่ Solana อยู่ที่ 1:1000 ซึ่งหมายความว่า Arbitrageurs จำเป็นต้องเพิ่มค่าธรรมเนียมลำดับความสำคัญเพียง 10 เท่าสำหรับการอัปเดตโดย Market Maker ที่เป็นผู้ดำเนินการล่วงหน้า ในขณะที่ Solana ต้องใช้ 1,000 เท่า ด้วยอัตราส่วนที่ต่ำกว่านี้ Arbitrageurs มีแนวโน้มที่จะทำการอัปเดตราคาล่วงหน้าเพื่อให้ได้ราคาที่ล้าสมัยเนื่องจากมีราคาถูกกว่านวัตกรรมบางอย่าง (เช่น TSTORE ของ EIP-1153 สำหรับพื้นที่จัดเก็บชั่วคราว) นำเสนอการเขียนข้อมูลด้วยแก๊สประมาณ 100 แต่พื้นที่จัดเก็บนี้มีอายุสั้นและใช้ได้เฉพาะภายในธุรกรรมเดียวเท่านั้น ทำให้ไม่เหมาะสำหรับการอัปเดตราคาอย่างต่อเนื่องสำหรับการแลกเปลี่ยนครั้งต่อไป (เช่น ข้ามบล็อก) เราจะนำ Prop AMM เข้ามาใน EVM ได้อย่างไร? ก่อนที่จะตอบคำถามนั้น เรามาตอบคำถาม "ทำไม" กันก่อน: ผู้ใช้มักต้องการราคาเสนอซื้อขายที่ดีกว่า ซึ่งหมายถึงธุรกรรมที่คุ้มค่ากว่า Prop AMM บน Ethereum และ Layer 2 สามารถให้ราคาเสนอซื้อขายที่แข่งขันได้กับผู้ใช้ ซึ่งก่อนหน้านี้มีเฉพาะบน Solana หรือตลาดแลกเปลี่ยนแบบรวมศูนย์เท่านั้น เพื่อให้ Prop AMM ใช้งานได้จริงบน EVM เรามาทบทวนเหตุผลหนึ่งที่ประสบความสำเร็จบน Solana: การป้องกันการอัปเดตจากระดับบนสุดของบล็อก: บน Solana การอัปเดต Prop AMM จะถูกวางไว้ที่ระดับบนสุดของบล็อก เพื่อปกป้องผู้สร้างตลาดจากการดำเนินการแบบฟรอนท์รันนิ่ง การจัดวางการอัปเดตนี้เป็นผลมาจากการใช้หน่วยประมวลผล (CU) น้อยที่สุด ทำให้มีอัตราส่วนค่าธรรมเนียมต่อ CU สูง แม้จะมีค่าธรรมเนียมต่ำ โดยเฉพาะอย่างยิ่งเมื่อเทียบกับการแลกเปลี่ยน แล้วจะนำการอัปเดต Prop AMM ที่ด้านบนสุดของบล็อกมาใช้กับบล็อกเชน EVM เลเยอร์ 2 ได้อย่างไร มีสองวิธี คือ ลดต้นทุนการเขียน หรือสร้างช่องทางลำดับความสำคัญสำหรับการอัปเดต Prop AMM การลดต้นทุนการเขียนไม่สามารถทำได้เนื่องจากปัญหาการเติบโตของสถานะของ EVM เนื่องจาก SSTORE ราคาถูกอาจนำไปสู่การโจมตีแบบขยะ เราเสนอให้สร้างช่องทางลำดับความสำคัญสำหรับการอัปเดต Prop AMM ซึ่งเป็นวิธีแก้ปัญหาที่ใช้งานได้จริง และเป็นประเด็นสำคัญของบทความนี้

@MarkToda จากทีม Uniswap ได้เสนอแนวทางใหม่โดยใช้ สัญญาอัจฉริยะสำหรับการจัดเก็บข้อมูลทั่วโลก + กลยุทธ์การสร้างบล็อกแบบพิเศษ:

วิธีการทำงานมีดังนี้:

· สัญญาอัจฉริยะสำหรับการจัดเก็บข้อมูลทั่วโลก:ใช้งานสัญญาอัจฉริยะแบบง่ายเป็นที่เก็บคีย์-ค่าสาธารณะ ผู้สร้างตลาดจะเขียนพารามิเตอร์เส้นโค้งราคาลงในสัญญานี้ (เช่น set(ETH-USDC_CONCENTRATION, 4000))

กลยุทธ์ Builder: นี่คือองค์ประกอบสำคัญนอกเครือข่าย ผู้สร้างบล็อกจะระบุธุรกรรมที่ส่งไปยังสัญญาจัดเก็บข้อมูลทั่วโลก จัดสรรแก๊ส 5-10% แรกของบล็อกให้กับธุรกรรมอัปเดตเหล่านี้ และจัดลำดับความสำคัญตามค่าธรรมเนียมเพื่อป้องกันสแปม หมายเหตุ: ธุรกรรมต้องส่งไปยังที่อยู่จัดเก็บข้อมูลทั่วโลกโดยตรง มิฉะนั้นจะไม่รับประกันว่าจะอยู่ที่ด้านบนสุดของบล็อก สำหรับตัวอย่างอัลกอริทึมการสร้างบล็อกแบบกำหนดเอง โปรดดู rblib สัญญา Prop AMM สำหรับผู้ดูแลสภาพคล่องจะอ่านข้อมูลเส้นโค้งราคาจากสัญญาจัดเก็บข้อมูลทั่วโลกในระหว่างการแลกเปลี่ยนเพื่อเสนอราคา สถาปัตยกรรมนี้แก้ปัญหาสองประการได้อย่างชาญฉลาด: 1. การป้องกัน: กลยุทธ์ Builder สร้าง "ช่องทางด่วน" เพื่อให้แน่ใจว่าการอัปเดตราคาทั้งหมดภายในบล็อกจะดำเนินการก่อนธุรกรรม ซึ่งช่วยลดความเสี่ยงจากการถูกเรียกใช้งานล่วงหน้า 2. ประสิทธิภาพด้านต้นทุน: ผู้ดูแลสภาพคล่องไม่ต้องแข่งขันกับผู้ใช้ DeFi ทุกคนสำหรับราคาแก๊สที่สูงเพื่อซื้อขายที่ด้านบนสุดของบล็อกอีกต่อไป แต่กลับแข่งขันกันในตลาดค่าธรรมเนียมท้องถิ่นเพื่อบล็อกบนสุดที่สงวนไว้สำหรับธุรกรรมที่อัปเดต ซึ่งช่วยลดต้นทุนได้อย่างมาก ธุรกรรมของผู้ใช้จะดำเนินการตามเส้นโค้งราคาที่ผู้ดูแลสภาพคล่องกำหนดไว้ในการอัปเดตครั้งแรกของบล็อกเดียวกัน ทำให้มั่นใจได้ถึงความสดใหม่และความปลอดภัยของราคาเสนอซื้อ โมเดลนี้จำลองสภาพแวดล้อมการอัปเดตลำดับความสำคัญสูงที่มีต้นทุนต่ำของ Solana บน EVM ซึ่งปูทางไปสู่ Prop AMM บน EVM อย่างไรก็ตาม โมเดลนี้ยังมีข้อเสียอยู่บ้าง ซึ่งผมจะกล่าวถึงในตอนท้ายของบทความนี้

บทสรุป

ความสามารถในการอยู่รอดของ Prop AMM ขึ้นอยู่กับการแก้ปัญหาทางเศรษฐกิจหลัก นั่นคือ การดำเนินการที่มีต้นทุนต่ำและจัดลำดับความสำคัญเพื่อป้องกันการรันแบบฟรอนท์รัน

แม้ว่าสถาปัตยกรรม EVM มาตรฐานจะทำให้การดำเนินการดังกล่าวมีค่าใช้จ่ายสูงและมีความเสี่ยง แต่การออกแบบใหม่นี้นำเสนอแนวทางที่แตกต่างในการแก้ปัญหานี้ การออกแบบใหม่นี้ผสานรวมสัญญาอัจฉริยะด้านการจัดเก็บข้อมูลทั่วโลกแบบออนเชนเข้ากับกลยุทธ์การสร้างแบบออฟเชน ทำให้เกิด "ช่องทางด่วน" เฉพาะที่รับประกันการดำเนินการอัปเดตแบบ top-of-block ควบคู่ไปกับการสร้างตลาดค่าธรรมเนียมแบบท้องถิ่นที่ควบคุมได้ สิ่งนี้ไม่เพียงแต่ทำให้ Prop AMM ใช้งานได้จริงบน EVM เท่านั้น แต่ยังมีศักยภาพที่จะปฏิวัติ EVM DeFi ทั้งหมดที่ต้องอาศัยการอัปเดต Oracle แบบ top-of-block อีกด้วย

คำถามปลายเปิด

· ความเร็ว Flashblock 200ms ของ Prop AMM บน EVM เร็วพอที่จะแข่งขันกับสถาปัตยกรรมแบบต่อเนื่องของ Solana หรือไม่

· ปริมาณการรับส่งข้อมูล AMM ส่วนใหญ่บน Solana มาจากตัวรวบรวมเพียงตัวเดียวคือ Jupiter ซึ่งมี SDK สำหรับการรวม AMM เข้าด้วยกันอย่างง่ายดาย อย่างไรก็ตาม บน Layer 2 EVM ปริมาณการรับส่งข้อมูลจะกระจายไปยังตัวรวบรวมหลายตัวและไม่มี SDK สาธารณะ สิ่งนี้เป็นความท้าทายสำหรับ Prop AMM หรือไม่

· การอัปเดต Prop AMM บน Solana ใช้พื้นที่เพียง ~100 CU เท่านั้น การดำเนินการนี้เป็นอย่างไร

· โมเดลช่องทางที่รวดเร็วจะรับประกันการอัปเดตเฉพาะที่ด้านบนของบล็อกเท่านั้น หากมีสวอปหลายรายการภายในแฟลชบล็อก ผู้ดูแลตลาดจะอัปเดตราคาข้ามสวอปเหล่านี้อย่างไร

· โปรแกรม EVM ที่ปรับแต่งแล้วสามารถเขียนด้วยภาษาอย่าง Yul หรือ Huff คล้ายกับรูปแบบการปรับแต่ง Pinocchio บน Solana ได้หรือไม่

· Prop AMM เปรียบเทียบกับ RFQ ได้อย่างไร

· เราจะป้องกันไม่ให้ Market Maker เสนอราคาคุณภาพสูงในบล็อก N เพื่อจูงใจผู้ใช้ แล้วอัปเดตเป็นราคาที่แย่ในบล็อก N+1 ได้อย่างไร Jupiter ป้องกันปัญหานี้ได้อย่างไร

· ฟีเจอร์ Ultra Signaling ของ Jupiter Ultra V3 ช่วยให้ Prop AMM สามารถแยกแยะระหว่างทราฟฟิกที่เป็นอันตรายและไม่เป็นอันตราย และเสนอราคาที่แคบลงได้ ฟีเจอร์ตัวรวบรวมเหล่านี้มีความสำคัญต่อ Prop AMM บน EVM มากน้อยเพียงใด

ลิงก์ต้นฉบับ

ยินดีต้อนรับสู่ชุมชนทางการของ BlockBeats:

กลุ่ม Telegram สมัครสมาชิก: https://t.me/theblockbeats

กลุ่ม Telegram พูดคุย: https://t.me/BlockBeats_App

บัญชี Twitter ทางการ: https://twitter.com/BlockBeatsAsia