لماذا تنتشر Prop AMM على Solana بينما لا تزال غائبة على EVM؟

العنوان الأصلي: Must-Watch dApps After Monad Mainnet Launch

الكاتب الأصلي: Optimus، مؤسس Waterloo Blockchain

الترجمة الأصلية: Dingdang، Odaily

Prop AMMs استحوذت بسرعة على 40% من إجمالي حجم التداول على Solana. لماذا لم تظهر بعد على EVM؟

صناع السوق الآليون المحترفون (Proprietary AMMs، اختصارًا Prop AMMs) أصبحوا بسرعة القوة المهيمنة في نظام Solana DeFi، حيث يساهمون الآن بأكثر من 40% من حجم التداول في أزواج التداول الرئيسية. هذه الأماكن الخاصة بالسيولة التي يديرها صناع سوق محترفون توفر سيولة عميقة وتسعيرًا أكثر تنافسية، والسبب الأساسي هو أنها تقلل بشكل كبير من خطر استغلال صناع السوق من خلال "عروض الأسعار المنتهية الصلاحية" (stale quotes) في عمليات المراجحة (front-running).

مصدر الصورة: dune.com

ومع ذلك، فإن نجاحها يكاد يكون محصورًا بالكامل في Solana. حتى على شبكات Layer 2 السريعة ومنخفضة التكلفة مثل Base أو Optimism، لا تزال Prop AMM نادرة في نظام EVM. لماذا لم تتجذر على EVM؟

تستكشف هذه المقالة ثلاثة أسئلة رئيسية: ما هي Prop AMM، ما هي العقبات التقنية والاقتصادية التي تواجهها على سلاسل EVM، وما هي البنى الجديدة الواعدة التي قد تجلبها في النهاية إلى طليعة EVM DeFi.

ما هي Prop AMM؟

Prop 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، ويقوم صانع السوق بتحديث هذا الثابت باستمرار لضبط منحنى الأسعار.

مراجعة: كيف تحدد 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 ثابتًا، يجب أن تصبح y = 40,000,000 / 99 ≈ 404,040.40. أي أن المتداول دفع حوالي 4,040.40 USDC مقابل 1 WETH، وهو أعلى قليلاً من السعر الأولي. هذه الظاهرة تسمى "الانزلاق السعري" (slippage). ولهذا السبب يسمى x*y=k "منحنى الأسعار": يجب أن يقع أي سعر تداول على هذا المنحنى.

لماذا يفضل صناع السوق تصميم AMM على دفتر أوامر مركزي (CLOB)؟

دعونا نشرح لماذا يرغب صانعو السوق في استخدام تصميم AMM. تخيل أنك صانع سوق تضع عروض أسعار على دفتر أوامر محدد الأسعار على السلسلة (CLOB). إذا أردت تحديث عروضك، عليك إلغاء واستبدال آلاف الطلبات المحددة. إذا كان لديك N طلبًا، فإن تكلفة التحديث هي من رتبة O(N)، وهو أمر بطيء ومكلف على السلسلة.

لكن ماذا لو تمكنت من تمثيل جميع عروضك بمنحنى رياضي واحد؟ حينها تحتاج فقط إلى تحديث عدد قليل من المعلمات التي تحدد هذا المنحنى، مما يحول العملية من O(N) إلى O(1) من حيث التعقيد.

لإظهار كيف يتوافق "منحنى الأسعار" مع نطاقات أسعار فعالة مختلفة، يمكننا الرجوع إلى SolFi الذي أنشأته Ellipsis Labs—وهو Prop AMM مبني على Solana. رغم أن منحنى الأسعار الدقيق غير معروف ومخفي، إلا أن Ghostlabs رسمت مخططًا يوضح الأسعار الفعالة عند مبادلة كميات مختلفة من SOL مقابل USDC خلال فترة slot واحدة على Solana. كل خط يمثل مجمع WSOL/USDC مختلف، ما يوضح إمكانية وجود مستويات أسعار متعددة في آن واحد. ومع تحديث صانع السوق لمنحنى الأسعار، يتغير هذا المخطط بين الفترات الزمنية المختلفة.

مصدر الصورة: github

النقطة الأساسية هنا هي أن صانع السوق يمكنه تغيير توزيع الأسعار الفعالة في أي وقت فقط من خلال تحديث عدد قليل من معلمات منحنى الأسعار، دون الحاجة لتعديل N طلبًا واحدًا تلو الآخر. هذه هي القيمة الجوهرية لـ Prop AMM—فهي تمكن صانع السوق من توفير سيولة ديناميكية وعميقة بكفاءة رأسمالية وحسابية أعلى.

لماذا بنية Solana مثالية لـ Prop AMM؟

Prop AMM هو نظام "مدار نشطًا"، ما يعني أنه يحتاج إلى شرطين أساسيين:

1. تكلفة تحديث منخفضة (cheap updates)

2. أولوية التنفيذ (priority execution)

على Solana، هذان الشرطان متكاملان: التحديث منخفض التكلفة غالبًا ما يعني أن التحديث يحصل على أولوية التنفيذ.

لماذا يحتاج صانعو السوق إلى هذين الشرطين؟ أولاً، يقومون بتحديث منحنى الأسعار باستمرار وفقًا لتغيرات المخزون أو تقلبات سعر المؤشر للأصل (مثل سعر البورصة المركزية)، بسرعة تشغيل البلوكشين. على سلاسل عالية التردد مثل Solana، إذا كانت تكلفة التحديث مرتفعة، سيكون من الصعب إجراء تعديلات متكررة.

ثانيًا، إذا لم يتمكن صانع السوق من وضع التحديث في أعلى الكتلة، سيتم استغلال عروضه القديمة من قبل المراجحين، مما يؤدي إلى خسائر حتمية. إذا غاب هذان الشرطان، لن يتمكن صانع السوق من العمل بكفاءة، وسيحصل المستخدمون على أسعار تداول أسوأ.

خذ على سبيل المثال Prop AMM HumidiFi على Solana، حيث وفقًا لبيانات @SliceAnalytics، يقوم صانع السوق بتحديث عروضه حتى 74 مرة في الثانية.

قد يتساءل القادمون من EVM: "مدة slot في Solana حوالي 400ms، كيف يمكن لـ Prop AMM تحديث الأسعار عدة مرات ضمن slot واحد؟"

الجواب يكمن في بنية Solana المتواصلة، والتي تختلف جوهريًا عن نموذج الكتل المنفصلة في EVM.

· EVM: عادةً ما يتم تنفيذ المعاملات بترتيبها بعد اقتراح وتأكيد الكتلة بالكامل. هذا يعني أن التحديثات المرسلة في منتصف الطريق لن تصبح سارية حتى الكتلة التالية.

· Solana: لا ينتظر عقدة Leader الكتلة الكاملة، بل يقسم المعاملات إلى حزم بيانات صغيرة (تسمى "shred") ويبثها باستمرار عبر الشبكة. قد يكون هناك عدة عمليات swap ضمن slot واحد، لكن تحديث السعر في shred #1 يؤثر على swap #1، وتحديث السعر في shred #2 يؤثر على swap #2.

ملاحظة: Flashblocks مشابهة لـ shred في Solana. وفقًا لعرض @Ashwinningg من Anza Labs في مؤتمر CBER، الحد الأعلى لكل slot مدته 400ms هو 32,000 shred، أي 80 shred لكل ميلي ثانية. أما إذا كانت Flashblocks بسرعة 200ms كافية لتلبية احتياجات صناع السوق مقارنة ببنية Solana المتواصلة، فلا يزال هذا سؤالًا مفتوحًا.

فلماذا تحديثات Solana رخيصة جدًا؟ وكيف تؤدي إلى أولوية التنفيذ؟

أولاً، رغم أن تنفيذ Prop AMM على Solana هو صندوق أسود، إلا أن هناك مكتبات مثل Pinocchio يمكنها تحسين استهلاك CU عند كتابة برامج Solana. مدونة Helius شرحت ذلك بشكل رائع، حيث يمكن أن ينخفض استهلاك CU لبرامج Solana من حوالي 4000 CU إلى حوالي 100 CU باستخدام هذه المكتبة.

مصدر الصورة: github

لننتقل إلى الجزء الثاني. على مستوى أعلى، تقوم Solana بترتيب المعاملات حسب نسبة الرسوم إلى وحدات الحوسبة (Fee / Compute Units)، وهي مشابهة لـ Gas في EVM.

· إذا كنت تستخدم Jito، الصيغة هي Jito Tip / Compute Units

· إذا لم تستخدم: Priority = (رسوم الأولوية + الرسوم الأساسية) / (1 + حد CU + توقيع CU + قفل الكتابة CU)

بمقارنة تحديثات Prop AMM مع وحدات الحوسبة لعمليات Swap في Jupiter، نجد أن التحديثات رخيصة للغاية، بنسبة تصل إلى 1:1000.

تحديثات Prop AMM: تحديث المنحنى البسيط رخيص جدًا. تحديثات Wintermute تصل إلى 109 CU فقط، بإجمالي تكلفة 0.000007506 SOL

Jupiter Swap: عمليات swap عبر Jupiter تصل إلى ~100,000 CU، بإجمالي تكلفة 0.000005 SOL

بسبب هذا الفارق الكبير، يحتاج صانع السوق فقط لدفع رسوم صغيرة جدًا لتحديث المعاملة، ليحقق نسبة Fee/CU أعلى بكثير من عمليات swap، ما يضمن تنفيذ التحديث في أعلى الكتلة ويحميه من هجمات المراجحة.

لماذا لم يتم تطبيق Prop AMM على EVM بعد؟

افترض أن تحديثات Prop AMM تتضمن كتابة متغيرات تحدد منحنى أسعار زوج التداول. رغم أن كود Prop AMM على Solana هو "صندوق أسود" ويحرص صانعو السوق على سرية استراتيجياتهم، يمكننا استخدام هذا الافتراض لفهم كيفية تنفيذ Prop AMM على Sui بواسطة Obric: حيث يتم كتابة متغيرات التسعير عبر دالة update في العقد الذكي.

شكرًا لاكتشاف @markoggwp!

باستخدام هذا الافتراض، نجد أن بنية EVM تفرض عقبات كبيرة تجعل نموذج Prop AMM الخاص بـ Solana غير قابل للتطبيق على EVM.

تذكير: على سلاسل OP-Stack Layer 2 (مثل Base وUnichain)، يتم ترتيب المعاملات حسب رسوم الأولوية لكل Gas (مشابه لترتيب Solana حسب Fee / CU).

على EVM، عمليات الكتابة تستهلك Gas عاليًا جدًا. مقارنة بتحديثات Solana، فإن كتابة قيمة واحدة عبر opcode SSTORE على EVM مكلف للغاية:

· SSTORE (0 → غير 0): ~22,100 gas

· SSTORE (غير 0 → غير 0): ~5,000 gas

· عملية swap نموذجية في AMM: ~200,000–300,000 gas

ملاحظة: Gas في EVM مشابه لوحدات الحوسبة (CU) في Solana. أرقام Gas لـ SSTORE تفترض عملية كتابة واحدة فقط (كتابة باردة)، وهو افتراض معقول لأن التحديثات المتعددة في معاملة واحدة غير شائعة.

رغم أن التحديث لا يزال أرخص من swap، إلا أن استخدام gas أقل بحوالي 10 مرات فقط (وقد يشمل التحديث عدة SSTORE)، بينما على Solana النسبة حوالي 1000 مرة.

هذا يؤدي إلى نتيجتين تجعل نموذج Prop AMM الخاص بـ Solana أكثر خطورة على EVM:

1. استهلاك Gas العالي يجعل من الصعب ضمان أولوية التحديث عبر رسوم الأولوية، حيث لا يمكن تحقيق نسبة رسوم عالية/Gas بسهولة. لضمان عدم تجاوز التحديثات من قبل الآخرين ووضعها في أعلى الكتلة، يجب دفع رسوم أولوية أعلى، مما يزيد التكلفة.

2. خطر المراجحة أعلى على EVM، حيث أن نسبة Gas بين التحديث وswap هي فقط 1:10، بينما على Solana هي 1:1000. هذا يعني أن المراجحين يحتاجون فقط لرفع رسوم الأولوية 10 مرات لتجاوز تحديثات صانع السوق، بينما على Solana يحتاجون لرفعها 1000 مرة. في هذه النسبة المنخفضة، من المرجح أن يقوم المراجحون بالتداول قبل تحديث السعر للاستفادة من عروض الأسعار القديمة، لأن التكلفة منخفضة.

بعض الابتكارات (مثل EIP-1153's TSTORE للتخزين المؤقت) توفر كتابة بحوالي 100 gas، لكن هذا التخزين مؤقت ويعمل فقط ضمن معاملة واحدة، ولا يمكن استخدامه لتخزين تحديثات الأسعار بشكل دائم لمعاملات swap لاحقة (مثل فترة الكتلة بالكامل).

كيف يمكن إدخال Prop AMM إلى EVM؟

قبل الإجابة، دعنا نجيب على "لماذا نفعل ذلك": المستخدمون يريدون دائمًا أسعار تداول أفضل، أي تداول أكثر كفاءة. Prop AMM على Ethereum وLayer 2 يمكن أن توفر للمستخدمين أسعارًا تنافسية لا تتوفر إلا على Solana أو البورصات المركزية.

لجعل Prop AMM قابلة للتطبيق على EVM، دعونا نراجع أحد أسباب نجاحها على Solana:

· حماية التحديثات في أعلى الكتلة: على Solana، يتم تنفيذ تحديثات Prop AMM في أعلى الكتلة، مما يحمي صانع السوق من المراجحة. التحديثات في الأعلى بسبب استهلاك وحدات الحوسبة المنخفض جدًا، حتى مع رسوم منخفضة، يمكن تحقيق نسبة رسوم/CU عالية، خاصة مقارنة بعمليات swap.

فكيف يمكن إدخال تحديثات Prop AMM في أعلى الكتلة إلى Layer 2 EVM؟ هناك طريقتان: إما تقليل تكلفة الكتابة، أو إنشاء قناة أولوية لتحديثات Prop AMM.

نظرًا لمشكلة نمو الحالة في EVM، فإن تقليل تكلفة الكتابة ليس عمليًا، لأن SSTORE الرخيص سيؤدي إلى هجمات حالة غير مرغوب فيها.

نقترح إنشاء قناة أولوية لتحديثات Prop AMM. هذا هو الحل العملي ومحور هذه المقالة.

اقترح فريق Uniswap بقيادة @MarkToda طريقة جديدة باستخدام عقد ذكي للتخزين العالمي + استراتيجية بناء كتل مخصصة:

كيف تعمل هذه الطريقة:

· عقد التخزين العالمي: يتم نشر عقد ذكي بسيط كمخزن مفاتيح عام. يكتب صانع السوق معلمات منحنى الأسعار في هذا العقد (مثلاً set(ETH-USDC_CONCENTRATION, 4000)).

· استراتيجية البناء: هذا هو المكون الأساسي خارج السلسلة. يتعرف منشئ الكتل على المعاملات المرسلة إلى عقد التخزين العالمي، ويخصص 5–10% من Gas في أعلى الكتلة لهذه التحديثات، ويرتبها حسب الرسوم لمنع المعاملات غير المرغوب فيها.

ملاحظة: يجب إرسال المعاملات مباشرة إلى عنوان التخزين العالمي، وإلا لا يمكن ضمان وضعها في أعلى الكتلة.

يمكن الرجوع إلى مثال خوارزمية بناء الكتل المخصصة في rblib.

تكامل Prop AMM: يقرأ عقد Prop AMM الخاص بصانع السوق بيانات منحنى الأسعار من عقد التخزين العالمي أثناء عمليات swap لتقديم الأسعار.

تعالج هذه البنية بذكاء مشكلتين:

1. الحماية: تخلق استراتيجية البناء "قناة سريعة"، تضمن تنفيذ جميع تحديثات الأسعار في الكتلة قبل المعاملات، مما يلغي خطر المراجحة.

2. الكفاءة من حيث التكلفة: لم يعد صانع السوق بحاجة للتنافس مع جميع مستخدمي DeFi على Gas Price مرتفع للوصول إلى أعلى الكتلة، بل ينافس فقط في سوق رسوم محلي مخصص للمعاملات المحجوزة في أعلى الكتلة، مما يقلل التكلفة بشكل كبير.

سيتم تنفيذ معاملات المستخدمين بناءً على منحنى الأسعار الذي حدده صانع السوق في بداية نفس الكتلة، مما يضمن حداثة وأمان الأسعار. يعيد هذا النموذج على EVM بيئة التحديثات منخفضة التكلفة وعالية الأولوية الموجودة على Solana، ويمهد الطريق لـ Prop AMM على EVM.

ومع ذلك، هناك بعض العيوب في هذا النموذج، وسأترك هذه القضايا للنقاش في نهاية المقال.

الخلاصة

تعتمد جدوى Prop AMM على حل المشكلة الاقتصادية الأساسية: تنفيذ رخيص وأولوية لمنع المراجحة.

رغم أن بنية EVM القياسية تجعل هذه العمليات مكلفة وعالية المخاطر، إلا أن التصميمات الجديدة تقدم طرقًا مختلفة لحل هذه المشكلة. من خلال الجمع بين عقد ذكي للتخزين العالمي واستراتيجية بناء كتل خارج السلسلة، يمكن إنشاء "قناة سريعة" مخصصة تضمن تنفيذ التحديثات في أعلى الكتلة، مع إنشاء سوق رسوم محلي وخاضع للرقابة. هذا لا يجعل Prop AMM قابلة للتطبيق على EVM فحسب، بل قد يحدث ثورة في جميع تطبيقات EVM DeFi التي تعتمد على تحديثات أوراكل في أعلى الكتلة.

أسئلة مفتوحة

· هل سرعة Flashblock 200ms على EVM كافية لمنافسة بنية Solana المتواصلة؟

· معظم حركة AMM على Solana تأتي من مجمع واحد هو Jupiter، الذي يوفر SDK يسهل تكامل AMM. لكن على Layer 2 EVM، الحركة موزعة بين عدة مجمعات ولا يوجد SDK عام، فهل يشكل هذا تحديًا لـ Prop AMM؟

· تحديثات Prop AMM على Solana تستهلك حوالي 100 CU فقط، كيف يتم تحقيق ذلك؟

· نموذج القناة السريعة يضمن فقط تحديثات في أعلى الكتلة. إذا كان هناك عدة عمليات swap ضمن Flashblock واحد، كيف يمكن لصانع السوق تحديث الأسعار بينها؟

· هل يمكن كتابة برامج EVM محسنة باستخدام لغات مثل Yul أو Huff، على غرار تحسينات Pinocchio على Solana؟

· كيف تقارن Prop AMM مع RFQ؟

· كيف يمكن منع صانع السوق من تقديم أسعار جيدة في الكتلة N لجذب المستخدمين، ثم تحديثها إلى أسعار سيئة في الكتلة N+1؟ كيف يتعامل Jupiter مع ذلك؟

· ميزة Ultra Signaling في Jupiter Ultra V3 تتيح لـ Prop AMM التمييز بين الحركة الضارة وغير الضارة وتقديم أسعار أكثر إحكامًا، فما أهمية هذه الميزة لمستقبل Prop AMM على EVM؟

رابط المقال الأصلي