نظام النية: الحلول المحتملة لمشكلة تعقيد التمويل اللامركزي

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

نقوم بتوزيع الأموال على جميع بروتوكولات التمويل اللامركزي المتاحة على معظم الشبكات. خلال جلسة مدتها من 2 إلى 4 ساعات، نقوم بإجراء عشرات من المعاملات مثل الموافقات، والتحويلات، والتبادلات، والإيداعات، والمطالبات، وسحب الأموال. يتم توزيع الأموال على أزواج تداول Uniswap LP المخصصة، وقفل تصويت Curve، وغيرها، لتحقيق أقصى قدر من الحوافز. استخدمنا تقريبًا جميع جسور نقل البيانات عبر السلاسل، وأشهر DEX، وتجميع العائدات لنقل مجموعة استقرار العملات الخاصة بنا. نحن نسعى للحصول على مجموعة متنوعة من العوائد في مجال العملات الرقمية.

يمكن القول أن هذه العملية جعلته يدخل فيها دون أي استعداد.

أكثر الأجزاء تحديًا في عملي هو محاولة شرح جميع خطوات العمليات اللازمة بالتفصيل. سأقوم بإعطاء التعليمات، وهو يقوم بالتنفيذ، وفي الوقت نفسه يجب عليه فهم واجهة المستخدم لهذه الأدوات المعقدة من التمويل اللامركزي. كانت اجتماعاتنا مليئة بتعليمات مثل "انقر هنا"، "اذهب إلى هناك"، "استبدل هذا". على سبيل المثال، لتحويل USDC إلى LP من FRAX/DAI على Polygon، تكون العملية كما يلي:

1. تحويل USDC إلى DAI على DEX معين ( صفقة، الموافقة + التحويل )
2. نقل USDC و DAI عبر السلسلة إلى Polygon(4 صفقة، الموافقة + عبر السلسلة )
3. دمج USDC و DAI( في صفقة واحدة على DEX معين على Polygon، الموافقة + الدمج )
4. قم بإيداع LP في الخزنة للحصول على المكافآت (2 موافقة على المعاملات + إيداع )

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

من منظور أعلى، جميع العمليات التي نقوم بها لها نتائج متوقعة واضحة. لدينا أصول ونود استخدامها لإكمال مهام X و Y و Z. كما في المثال أعلاه، "لدينا USDC( على الإيثيريوم )، نود توفير السيولة على شكل FRAX/DAI( على البوليغون )، ثم إيداعها في خزينة الرهن". هذه هي "المحتويات" لعملياتنا، والـ 12 معاملة التي يجب تنفيذها هي "طرق العمل" المحددة. من نقطة البداية إلى النهاية، تحتاج إلى مجموعة من الخطوات الواضحة والمنطقية، وكل هذه الخطوات قابلة للقياس.

الخوارزمية القوية التي تم بناؤها لمعالجة توجيه المعاملات ستجعل هذه العملية أكثر بساطة، وقد تتطلب فقط 1-2 خطوة. كل ما علينا هو مشاركة النتائج التي نريدها، وستقوم الخوارزمية بإرجاع أفضل مسار لنا، وقد تتولى حتى معالجة المعاملة مباشرة. تُعرف هذه الأنواع من هياكل رسم المسار بـ "النية"، وهي جزء من مستقبل البرمجيات الوسيطة التي تتطور بسرعة على إيثيريوم. على الرغم من عدم وجود تعريف موحد للنية حتى الآن، إلا أن هناك بعض الآراء العامة.

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

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

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

بجانب مجمعات التداول، توجد أنواع أخرى من "النوايا" على إيثريوم:

1. أوامر السعر المحدد: إذا تم استيفاء الشروط، يُسمح بسحب الأصول من الحساب.
2. تنفيذ الطلبات من طرف ثالث بناءً على السيولة غير اللامركزية.
3. رعاية الغاز: يسمح باستخدام بعض الرموز لتنفيذ معاملات الطرف الثالث، وينطبق ذلك على محافظ التجريد الحسابي.
4. التفويض: القائمة البيضاء تنتمي إلى هذا النوع، حيث يتم التحقق من قاعدة البيانات قبل تنفيذ الصفقة.
5. معالجة المعاملات: يسمح بتجميع نوايا كفاءة الغاز.
6. تبادل عبر السلاسل.

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

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

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

الخصائص الأساسية للنوايا هي كشف البيانات. من خلال توقيع رسالة النية، تشير إلى أنك على استعداد لاستخراج MEV على حساب الراحة. نظرًا لأن النوايا لا يمكن بثها مباشرة إلى تجمع الذاكرة في إيثريوم حيث يتم وضع ( في قائمة الانتظار قبل التنفيذ )، فإنها تُملأ في Interpool الخاصة غير العامة. يمكن أن تكون هذه Interpool مرخصة، غير مرخصة، أو مزيجًا من الاثنين.

تستخدم Interpool API لامركزية بدون ترخيص، مما يتيح للنقاط في النظام مشاركة النوايا بحرية ومنح المنفذين حق الوصول غير المحدود. لقد نضجت ذاكرة الوصول المفتوحة للهجمات DDOS، ولا يمكن ضمان منع انتشار النوايا السيئة.

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

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

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

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

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

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

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

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

![لماذا قد تكون النوايا (Intents) هي إجابة لمشكلة تعقيد التمويل اللامركزي؟])https://img-cdn.gateio.im/webp-social/moments-70514d53c1e83b0c3182c2cbc267ba05.webp(

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

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

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

![لماذا قد تكون النوايا (Intents) هي الإجابة على مشكلة تعقيد التمويل اللامركزي (DeFi)؟])https://img-cdn.gateio.im/webp-social/moments-3353241b9604eaf91cc264bdcaa43685.webp(