لماذا يمتلئ Solana بـ Prop AMMs بينما يظل EVM فارغًا؟

BlockbeatsBlockbeats

عنوان المقال الأصلي: تطبيقات لامركزية يجب متابعتها بعد إطلاق شبكة Monad الرئيسية

المؤلف الأصلي للمقال: @0xOptimus

ترجمة المقال الأصلي: دينغدانغ، صحيفة أوديلي بلانيت ديلي

استحوذت صناديق الاستثمار الآلية (AMMs) الخاصة بسرعة على 40% من إجمالي حجم تداول سولانا. لماذا لم تظهر على منصة التداول الإلكترونية (EVM) حتى الآن؟

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

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

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

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

ما هي Prop AMMs؟

تعتبر أدوات السوق الآلية الملكية نوعًا من صناع السوق الآليين حيث يقوم صانع سوق محترف واحد بإدارة السيولة والأسعار بشكل نشط، بدلاً من توفير الأموال بشكل سلبي من قبل الجمهور كما هو الحال في أدوات السوق الآلية التقليدية.

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

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

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

في هذه المقالة، سنتناول مفهوم "منحنى السعر" عدة مرات. يُحدد منحنى السعر السعر الذي يتعين على المستخدمين دفعه عند التداول باستخدام نموذج التداول الآلي (AMM)، وهو الجزء الذي يُحدّثه مُزوّدو السيولة باستمرار في نموذج التداول الآلي (Prop AMM). لفهم هذا بشكل أفضل، يُمكننا أولاً مراجعة آلية التسعير في نموذج التداول الآلي التقليدي (AMM).

لنأخذ مثالاً على تجمع WETH-USDC على منصة Uniswap الإصدار الثاني (بافتراض عدم وجود رسوم). يُحدد السعر تلقائيًا بالصيغة 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.

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

لماذا يختار مزودو السيولة تصميم AMM بدلاً من دفتر الطلبات المركزي (CLOB)؟

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

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

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

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

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

لماذا تعتبر هندسة Solana مثالية لـ Prop AMM؟

Prop AMM هو نظام "مُدار بشكل نشط"، مما يعني أنه يتطلب شرطين رئيسيين:

1. تكاليف التحديث المنخفضة

2. التنفيذ ذو الأولوية

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

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

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

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

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

تكمن الإجابة في بنية Solana المستمرة، والتي تختلف بشكل أساسي عن نموذج الكتلة المنفصلة الخاص بـ EVM.

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

سولانا: لا تنتظر عُقد التحقق الرئيسية اكتمال الكتلة؛ بل تُقسّم المعاملات إلى حزم بيانات صغيرة (تُسمى "شِرَدات") وتُبثّها باستمرار إلى الشبكة. قد توجد عدة بورصات داخل كل فتحة، لكن تحديث السعر في الشِرَد رقم 1 يؤثر على المبادلة رقم 1، وتحديث السعر في الشِرَد رقم 2 يؤثر على المبادلة رقم 2.

ملاحظة: كتل الفلاش تُشبه شرائح سولانا. ووفقًا لـ @Ashwinningg من مختبرات أنزا في مؤتمر CBER، فإن حد الفتحة البالغ 32,000 شريحة كل 400 مللي ثانية يُعادل 80 شريحة في كل ميلي ثانية. ويبقى السؤال مطروحًا حول ما إذا كانت كتل الفلاش التي تبلغ سرعتها 200 مللي ثانية كافية لتلبية متطلبات مزودي السيولة، مقارنةً ببنية سولانا المستمرة.

إذًا، لماذا تُعدّ تحديثات سولانا رخيصةً جدًا؟ وما الذي يُفضي إلى تنفيذها على الفور؟

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

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

لننتقل الآن إلى الجزء الثاني. على مستوى أعلى، تُعطي سولانا الأولوية للمعاملات باختيار المعاملات ذات أعلى نسبة رسوم/وحدات حسابية (وحدات الحسابية تُشبه غاز EVM)، كما هو الحال في EVM.

· على وجه التحديد، إذا كنت تستخدم Jito، فإن الصيغة هي Jito Tip / Compute Units

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

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

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

تبادل المشتري: يمكن أن يصل التبادل عبر مسار المشتري إلى حوالي 100000 وحدة نقدية أوروبية، بتكلفة إجمالية تبلغ 0.000005 SOL

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

لماذا لم يتم اعتماد Prop AMM حتى الآن على EVM؟

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

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

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

تذكر أنه في سلاسل الكتل OP-Stack Layer 2 (مثل Base وUnichain)، يتم تحديد أولوية المعاملات بناءً على الرسوم لكل غاز (على غرار فرز Fee/CU الخاص بـ Solana).

في EVM، تكلفة كتابة الغاز مرتفعة للغاية. مقارنةً بتحديثات Solana، فإن تكلفة كتابة قيمة في EVM عبر شفرة تشغيل SSTORE باهظة.

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

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

· مبادلة AMM النموذجية: ~200,000–300,000 غاز

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

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

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

١. ارتفاع تكاليف الغاز يُصعّب ضمان أولوية التحديثات: فانخفاض رسوم الغاز لا يضمن نسبة رسوم/غاز عالية. ولضمان عدم إجراء التحديثات بشكل مُسبق ووضعها في أعلى القائمة، يلزم رفع رسوم الغاز، مما يزيد التكاليف.

٢. ارتفاع مخاطر التحكيم في أداة القيمة السوقية الإلكترونية: تبلغ نسبة الغاز المُحدّث إلى الغاز المُقايض في أداة القيمة السوقية الإلكترونية ١:١٠ فقط، بينما تبلغ ١:١٠٠٠ في أداة سولانا. هذا يعني أن المُراجِعين بحاجة فقط إلى زيادة الرسوم بمقدار ١٠ أضعاف لتحديث مُزوّد السيولة، مُقارنةً بـ ١٠٠٠ ضعف في أداة سولانا. في ظل هذه النسبة المنخفضة، يميل المُراجِعون إلى تحديث الأسعار مُسبقًا للاستفادة من عروض الأسعار القديمة نظرًا لانخفاض تكلفتها.

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

كيفية تقديم Prop AMM إلى EVM؟

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

ولكي نجعل اقتراح AMM ممكناً على آلة التصويت الإلكترونية، دعونا نراجع أحد أسباب نجاحه على سولانا:

حماية تحديثات أعلى الكتلة: في منصة Solana، تُوضع تحديثات Prop AMM في أعلى الكتلة لحماية مزودي السيولة من التسرع. التحديثات الأعلى ممكنة لأن تكلفة الوحدة الحسابية ضئيلة، مما يسمح حتى للرسوم المنخفضة بتحقيق نسبة رسوم/وحدة عملة عالية، خاصةً بالمقارنة مع تداولات المشتقات.

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

بسبب مشكلة نمو حالة EVM، فإن تقليل نهج تكلفة الكتابة أقل جدوى، حيث أن SSTOREs الرخيصة من شأنها أن تؤدي إلى هجمات تضخم الحالة.

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

اقترح @MarkToda من Uniswap نهجًا جديدًا، مستفيدًا من استراتيجية العقد الذكي للتخزين العالمي + منشئ الكتل المخصص:

إليك كيفية عملها:

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

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

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

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

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

يعالج هذا التصميم المعماري قضيتين بمهارة:

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

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

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

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

خاتمة

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

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

الأسئلة المفتوحة


· هل سرعة Flashblock البالغة 200 مللي ثانية في Prop AMM على EVM كافية للتنافس مع بنية Solana المستمرة؟

في Solana، تأتي معظم حركة مرور AMM من مُجمِّع واحد يُسمى Jupiter، والذي يُوفِّر حزمة تطوير برمجيات (SDK) لتسهيل دمج AMM. مع ذلك، في EVM من الطبقة الثانية، تُوزَّع حركة المرور عبر مُجمِّعات متعددة بدون حزمة تطوير برمجيات عامة. هل يُشكِّل هذا تحديًا لـ Prop AMM؟

في Solana، تستهلك تحديثات Prop AMM حوالي 100 وحدة تحكم فقط. ما هي آلية التنفيذ وراء هذه الكفاءة؟

يضمن نموذج المسار السريع التحديثات في أعلى الكتلة فقط. إذا كانت هناك عدة بورصات داخل كتلة فلاش، فكيف يُحدِّث مُزوِّدو السيولة الأسعار بين هذه البورصات؟

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

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

كيف يُمكننا منع مُزوّدي السيولة من تقديم أسعار تنافسية في الكتلة N لجذب المستخدمين، ثم تحديثها إلى أسعار غير تنافسية في الكتلة N+1؟ كيف يُخفف جوبيتر من هذا الخطر؟

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

رابط التدوينة الأصلية

مرحبًا بكم في الانضمام إلى مجتمع BlockBeats الرسمي:

مجموعة اشتراكات التلجرام: https://t.me/theblockbeats

مجموعة نقاش تيليجرام: https://t.me/BlockBeats_App

الحساب الرسمي على تويتر: https://twitter.com/BlockBeatsAsia

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