من Solana إلى EVM: مسار جديد لـ AMMs المملوكة

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

أصبحت Proprietary AMMs (Prop AMMs) قوة رئيسية في نظام DeFi الخاص بـ Solana، إذ تستحوذ على أكثر من 40% من حجم التداول على الأزواج الرئيسية. تدير هذه المنصات المتخصصة، التي يشرف عليها صانعو السوق المحترفون، سيولة عميقة وتسعيرًا تنافسيًا عبر تقليل تعرضهم للاستغلال من قبل المراجحين الذين يستفيدون من الأسعار القديمة.

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

ومع ذلك، بقي نجاح Prop AMMs محصورًا تقريبًا في Solana. لماذا لم تنتقل هذه التقنية إلى منظومة EVM، حتى على الطبقات الثانية السريعة والمنخفضة التكلفة مثل Base أو Optimism؟

تستعرض هذه المقالة ماهية Prop AMMs، والعقبات التقنية والاقتصادية أمام انتشارها في سلاسل EVM، وتناقش بنية جديدة واعدة قد تضعها في صدارة DeFi على EVM.

ما هي Prop AMMs؟

Prop AMM هو Automated Market Maker تُدار فيه السيولة والتسعير بشكل نشط من قبل صانع سوق محترف واحد، على عكس AMMs التقليدية التي تعتمد على السيولة المقدمة بشكل سلبي من الجمهور.

على خلاف AMMs التقليدية التي تعتمد على معادلة x * y = k لتحديد الأسعار، حيث x و y كميتا الأصلين في الحوض و k ثابت، تستخدم Prop AMMs معادلات أخرى تُحدث عادة عدة مرات في الثانية. وبما أن Prop AMMs غالبًا ما تكون صندوقًا أسود، تبقى صيغتها مجهولة. إلا أن كود العقد الذكي لـ Obric’s Prop AMM على Sui متاح للعامة (شكرًا لـ @ markoggwp على اكتشاف ذلك!)، حيث يعتمد الثابت k على متغيرات داخلية مثل mult_x و mult_y و concentration. توضح الصورة أدناه كيف يقوم صانع السوق بتحديث هذه المتغيرات باستمرار.

توضيح مهم: الجانب الأيسر من معادلة منحنى السعر لـ Obric أكثر تعقيدًا من x * y، لكن الأساس لفهم Prop AMMs هو أنه يساوي ثابتًا k، والذي يقوم صانع السوق بتحديثه لضبط منحنى السعر.

مراجعة: كيف يتم تحديد الأسعار في AMM؟

مصطلح "منحنى السعر" سيظهر كثيرًا هنا، لأنه يحدد السعر الذي يدفعه المستخدم عند التداول عبر AMM، وهو ما يقوم صانع السوق بتحديثه في Prop AMM لضبط الأسعار. قبل التعمق في Prop AMMs، من المفيد أولًا فهم آلية تحديد الأسعار في AMM. لنأخذ مثالًا على حوض Uniswap v2 لـ WETH-USDC بدون رسوم. يتم تحديد السعر تلقائيًا عبر معادلة x * y = k، حيث x و y كميتا الأصلين في الحوض و k ثابت. فقط النقاط على المنحنى هي أسعار ممكنة يمكن للمستخدم دفعها.

مثال: إذا كان الحوض يحتوي على 100 WETH و 400,000 USDC، فإن النقطة الحالية هي x = 100 WETH، y = 400,000 USDC، أي أن السعر الأولي هو 400,000 USDC / 100 WETH = 4,000 USDC لكل WETH. باحتساب حاصل الضرب الثابت k، نحصل على xy = k = 40,000,000. إذا أراد متداول شراء 1 WETH، يضيف USDC إلى الحوض، وينخفض رصيد WETH إلى 99. للحفاظ على الثابت k، يجب أن تكون النقاط الجديدة x و y على المنحنى، لذا يرتفع رصيد USDC إلى 40,000,000 / 99 ≈ 404,040.40 USDC. بذلك دفع المتداول 4,040.40 USDC مقابل 1 WETH، وهو سعر أعلى من السعر الأولي بسبب تأثير السعر (الانزلاق). لهذا السبب تُعرف معادلة x y = k بمنحنى السعر، لأن كل سعر محتمل يجب أن يكون نقطة على المنحنى.

لماذا قد يفضل صانع السوق تصميم AMM على CLOB؟

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

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

لرؤية كيف يمكن لمنحنى السعر (مثل x*y = k) أن ينتج أسعار فعالة متنوعة، دعونا ننظر إلى SolFi، وهو Prop AMM من Ellipsis Labs. رغم أن منحنى السعر غير معروف، أنتجت Ghostlabs مخططًا يوضح السعر الفعلي لـ SOL مقابل USDC لكميات مختلفة من SOL في فتحة معينة على Solana. (بالنسبة لقراء EVM، رقم الفتحة يعادل رقم البلوك). كل خط يمثل حوض WSOL/USDC مختلف، ما يوضح كيف يمكنهم تقديم مستويات تسعير مختلفة في آن واحد. مع تحديث صانع السوق لمنحنى السعر، يتغير مخطط الأسعار الفعالة بين الفتحات.

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

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

لماذا بنية Solana مناسبة لـ Prop AMMs

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

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

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

بدون هاتين الخاصيتين، لن يستطيع صانعو السوق العمل بكفاءة، وسينعكس ذلك على المستخدم بأسعار تداول أسوأ.

على سبيل المثال، Prop AMMs مثل HumidiFi على Solana تحدث عروضها 74 مرة في الثانية (شكرًا لـ @ SliceAnalytics على البيانات)، كما يظهر في الصورة أدناه:

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

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

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

• EVM: تُنفذ المعاملات عادة بشكل متسلسل عندما يُقترح ويُؤكد بلوك كامل. هذا يعني أن التحديث المرسل في منتصف البلوك لن يظهر إلا عند بدء البلوك التالي.
• Solana: المدقق القائد لا ينتظر بناء بلوك كامل. بل يقسم المعاملات الواردة إلى حزم صغيرة تسمى "shreds" ويبثها لباقي الشبكة بشكل مستمر. قد تحدث عدة مبادلات في فتحة واحدة، لكن تحديث السعر في shred #1 يؤثر على سعر مبادلة #1، بينما تحديث السعر في shred #2 يؤثر على سعر مبادلة #2.

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

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

رغم أن تطبيق Prop AMMs على Solana هو صندوق أسود، توجد مكتبات مثل Pinocchio لإنشاء برامج Solana بطريقة محسنة لـ Compute Units. لدى Helius تدوينة حول هذه المكتبة (هنا)، حيث يمكن رؤية برامج Solana تنخفض من ~4000 CU إلى ~100 CU.

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

على مستوى عالٍ، تعطي Solana الأولوية للمعاملات عبر اختيار المعاملات ذات أعلى نسبة Fee / Computer Units (Compute Units تعادل Gas في EVM)، كما هو الحال في EVM.

• إذا كنت تستخدم Jito، فإن المعادلة هي Jito Tip / Compute Units،
• وإذا لم تكن كذلك، فالأولوية = (رسوم الأولوية + الرسوم الأساسية) / (1 + حد CU + توقيع CUs + أقفال الكتابة CUs) (https://solana.com/docs/core/fees)

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

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

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

مبادلة Jupiter: يمكن أن تكلف المبادلة عبر Jupiter ما يصل إلى ~100,000 CU. إجمالي الرسوم لهذه المعاملة كان 0.000005 SOL.

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

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

لماذا لم تظهر Prop AMMs على EVM حتى الآن؟

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

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

شكرًا لـ @ markoggwp على اكتشاف ذلك!

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

تذكر أن المعاملات على سلاسل الطبقة الثانية مثل Base و Unichain تُرتب حسب Priority Fee لكل Gas (كما في Solana حسب Fee / CU).

على EVM، استخدام الغاز للكتابة مرتفع. كتابة قيمة واحدة عبر SSTORE مكلفة جدًا مقارنة بتحديث على Solana.

• SSTORE (من صفر إلى قيمة غير صفرية): ~22,100 غاز
• SSTORE (من غير صفر إلى غير صفر): ~5,000 غاز
• مبادلة على AMM نموذجي: ~200,000 - 300,000 غاز

لاحظ أن Gas في EVM يعادل Compute Units في Solana.

لاحظ أيضًا أن أرقام SSTORE أعلاه تفترض وجود كتابة واحدة فقط في المعاملة (كتابات باردة)، وهو منطقي لأنك لن ترسل أكثر من تحديث واحد في المعاملة.

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

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

1. نظرًا لأن استخدام الغاز مرتفع، فإن رسوم الأولوية الصغيرة لا تحقق نسبة Priority Fee / Gas عالية. هذا يعني أن ضمان عدم استباق التحديث وأن يكون في أعلى البلوك يتطلب رسوم أولوية أكبر، ما يجعله أكثر تكلفة.
2. نظرًا لأن نسبة استخدام الغاز بين التحديث والمبادلة على EVM هي فقط 1:10 مقارنة بـ 1:1000 على Solana، فهذا يعني أن المراجح على EVM يحتاج فقط لزيادة رسوم الأولوية بمقدار 10x عن معاملة التحديث ليتمكن من الاستباق، مقارنة بـ 1000x على Solana. في هذه البيئة ذات النسبة المنخفضة على EVM، من المرجح أن يستبق المراجح تحديث السعر ويستغل العروض القديمة لأنه ليس مكلفًا جدًا.

ابتكارات مثل EIP-1153 (TSTORE للتخزين المؤقت) توفر كتابات بـ 100 غاز، لكن هذا التخزين مؤقت ويستمر فقط خلال المعاملة الواحدة. لا يمكن استخدامه لتخزين تحديث السعر لمعاملة مبادلة لاحقة (مثلًا خلال مدة بلوك).

كيف يمكننا جلب Prop AMMs إلى EVM؟

قبل الإجابة على هذا السؤال، لنجب أولًا عن "لماذا". المستخدمون يريدون دائمًا عروض أسعار أفضل لصفقاتهم، لأن ذلك يمنحهم صفقة أفضل. Prop AMMs على Ethereum وسلاسل الطبقة الثانية ستوفر عروض أسعار أكثر تنافسية للمستخدمين على تلك السلاسل، وهي عروض كانت متاحة فقط على Solana والبورصات المركزية.

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

• تحديثات Prop AMM في أعلى البلوك على Solana تحمي صانع السوق من الاستباق. التحديثات في أعلى البلوك لأنها تستخدم وحدات حسابية قليلة جدًا، حيث تؤدي الرسوم المنخفضة إلى نسبة Fee / CUs عالية، خاصة مقارنة بالمبادلات.

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

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

نقترح حلاً عبر النهج الثاني، وهو إنشاء مسار أولوية لتحديثات Prop AMM.

نهج مبتكر، اقترحه @ MarkToda من فريق Uniswap، يقترح حلاً عبر عقد ذكي للتخزين العالمي (المستودع هنا) مع سياسة بناء مخصصة.

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

كيف يعمل ذلك:

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

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

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

• أدناه مثال على كيفية عمل خوارزمية بناء بلوك مخصصة باستخدام rblib.

• تكامل Prop AMM: يُصمم عقد Prop AMM الخاص بصانع السوق ليقرأ بيانات منحنى السعر من عقد التخزين العالمي عند تنفيذ المبادلة، لتحديد السعر المقدم للمستخدم.

تحل هذه البنية كلا المشكلتين بذكاء.

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

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

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

الخلاصة

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

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

أسئلة مفتوحة

• هل Prop AMMs العاملة على EVM بسرعات Flashblock 200 مللي ثانية سريعة بما يكفي للتنافس مع بنية Solana المستمرة؟
• على Solana، يأتي معظم تدفق الأوامر لـ AMMs من مجمع واحد، Jupiter، الذي يوفر SDK للربط مع المجمع. أما على سلاسل الطبقة الثانية لـ EVM، فهو موزع عبر عدة مجمعين لا يوفرون SDK عام. هل يشكل ذلك تحديًا لـ Prop AMMs على EVM؟
• كيف يتم تنفيذ Prop AMMs بحيث تستخدم تحديثاتها على Solana حوالي 100 CU فقط؟
• النموذج المقترح للمسار السريع يضع تحديثات Prop AMM فقط في أعلى البلوك. إذا كان Flashblock سريعًا حتى 200 مللي ثانية، قد توجد سيناريوهات بها عدة مبادلات في Flashblock ويرغب صانع السوق في تحديث السعر بين تلك الصفقات. كيف يمكن تنفيذ ذلك؟
• هل يمكن استخدام لغات مثل Yul أو Huff لكتابة برامج EVM محسنة، مثلما تُستخدم Pinocchio لكتابة برامج Solana محسنة؟
• كيف تقارن Prop AMMs مع RFQs؟
• كيف نمنع صانع السوق من إعطاء عرض ممتاز في البلوك N يُعرض للمستخدم ليحفزه على إرسال معاملة في البلوك N+1، حيث يحدث تحديث للعرض في البلوك N+1 بعرض سيئ؟ كيف يمنع Jupiter ذلك؟
• يقدم Jupiter’s Ultra V3 ميزة “Ultra Signaling” التي تتيح لـ Prop AMMs التمييز بين التدفق السام وغير السام، لتقديم عروض أكثر إحكامًا بـ 3 نقاط أساس. ما مدى أهمية ميزات المجمع مثل هذه لجلب Prop AMMs إلى EVM؟

ملاحظة: أبحث حاليًا عن فرص للتحدث في المؤتمرات حول هذا الموضوع. إذا كنت مرتبطًا بأي فعاليات خلال Devconnect، يسعدني التواصل معك حول فرص التحدث!

تنويه:

1. تم إعادة نشر هذه المقالة من [0xOptimus]. جميع الحقوق محفوظة للمؤلف الأصلي [0xOptimus]. إذا كان هناك اعتراض على إعادة النشر، يرجى التواصل مع فريق Gate Learn وسيتم التعامل مع الأمر بسرعة.
2. إخلاء مسؤولية: الآراء الواردة في هذه المقالة تعبر فقط عن رأي الكاتب ولا تشكل أي نصيحة استثمارية.
3. تمت ترجمة المقالة إلى لغات أخرى بواسطة فريق Gate Learn. ما لم يُذكر خلاف ذلك، يُمنع نسخ أو توزيع أو سرقة المقالات المترجمة.