جدول الأعمال

المشكلة

1. تحديد الحالة النهائية: ما الذي يجعل تطبيقات التشفير "قابلة للاستخدام"

2. لماذا يعد "تجريد السلسلة" حلا لمشكلة UX التي تنشأ من الطوبولوجيا الأساسية لسلاسل الكتل المعيارية

3. لماذا يجب بناء تطبيقات العملات المشفرة القابلة للاستخدام على أعلى من بنية تجريد السلسلة

المساحة الحلول

1. كيف سيؤدي الهندسة المعمارية القائمة على النية إلى ظهور تجريد السلسلة

2. فهم أن أسواق النوايا تعمل بشكل أفضل عندما تكون شبكة الحل كبيرة وتنافسية

3. تشغيل شبكة حل المقصد يتطلب إضافة المزيد من التطبيقات التي ستنتج النوايا

المقترح

1. لماذا نحتاج إلى معيار للنوايا عبر السلاسل الذي يعطي الأولوية لـ “تجربة مستخدم الحل” لتنمية سوق الحلول والنوايا بمقياس كافٍ لتحقيق تأثيرات الشبكة

يتعذر بناء تطبيقات العملات المشفرة القابلة للإستخدام بدون تجريد السلسلة

هل يقوم أفضلنا وألمعنا ببناء بنية تحتية متكررة؟

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

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

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

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

1. السرعة: يجب أن تبدو التطبيقات سريعة كتطبيقات الويب2.
2. Cost: بخلاف web2، يجب أن تتحمل جميع تفاعلات web3 بعض التكلفة، لكن 'تكلفة النقرة' يجب أن تكون مهملة.
3. مقاومة الرقابة ("عدم التصريح"): يجب أن يكون بإمكان أي شخص لديه محفظة التفاعل مع التطبيق إذا كان بإمكانه تحمل التكاليف.
4. الأمان: يجب أن تفعل النقرات ما يتوقعه المستخدمون ولا تعود - يجب أن تكون جميع تحديثات الويب3 دائمة.

هذه هي خصائص التطبيقات الاقتصادية الرقمية "القابلة للإستخدام".

لقد حاولنا بناء عملة مشفرة قابلة للاستخدام لفترة طويلة

تقدم حلول سلسلة الكتل النموذجية اليوم جميع هذه الخصائص للمستهلكين، لكنها غير متاحة جميعها في نفس المكان.

في عام 2020، كانت شبكات البلوكتشين تعمل بشكل موحد، تقدم إحدى الخصائص الثلاث للمستخدمين: السرعة، التكلفة، أو الأمان. ثم تصورنا مستقبل متمحور حول الرول أب أو موديولارالتي ستفتح كل الخصائص الثلاث معًا.

اليوم، لقد قمنا ببناء الأسس لهذه البنية التحتية المركزة على Rollup. تقدم الطبقة الثانية مساحة كتل رخيصة وسريعة، ومعظمها تقدم مساحة كتل بدون إذن. وعلى الجانب الآخر، تقدم الطبقة الأولى مساحة كتل آمنة مقاومة للحروب العالمية الثالثة. (يمكنك قراءة المزيد حول التناقض بين الأمان وتجربة المستخدم المقدمة من قبل الطبقة الأولى والطبقة الثانية فيمقالتي القصيرة للمسح). تتصل هذه الطبقات الفرعية بأمان بـ L1 عبر مسارات الرسائل الكنسية، وهي تضع الأسس لشبكة قابلة للتبادل ولكنها مرنة. خلال الأربع سنوات الماضية، بنينا الألياف البصرية بين سلاسل الكتل التي ستدعم في يوم من الأيام تطبيقات العملات الرقمية المفيدة. ولكن لماذا تكون سلاسل الكتل القابلة للتخصيص بهذه الصعوبة في الاستخدام؟

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

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

فيتاليك على أنواع مختلفة من L2s

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

لذلك،سلسلة التجريديعتمد بشكل حاسم على قدرة المستخدمين على تحويل القيمة عبر الشبكات بشكل آمن وبتكلفة منخفضة وبسرعة. التدفق الشائع للمستخدم اليوم هو أن يكون لديه ميزان USDC على سلسلة 'آمنة' مثل إيثريوم يرغب في إصدار NFT أو تبديل الرموز الجديدة على سلسلة أحدث مثل Blast أو Base. الطريقة للقيام بذلك في أقل عدد من الخطوات الممكنة هي تنفيذ سلسلة من المعاملات بتسلسل Bridge→Swap→Mint (أو Swap→Bridge→Mint).

في هذا المثال، نوايا المستخدم هي استخدام USDC الخاص بهم على السلسلة الآمنة لإنتاج NFT على سلسلة أخرى. سيكون المستخدم راضيًا طالما تلقوا الـ NFT وتم خصم رصيدهم من USDC في أي مكان يختارون توديعها.

الهندسة المعمارية القائمة على النية هي الطريقة الوحيدة لبناء التجريد السلسلي

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

مخطط TCP/IP من ResearchGate

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

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

هناك عدة قضايا أساسية مع هذه الهندسة المعمارية:

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

جسور التمرير السريعة ستكون إما غير آمنة، بطيئة، أو مكلفة اعتمادًا على آلية التحقق. أسواق النوايا هي بنية بديلة للجسور السريعة تنبع من رؤية رئيسية:

القيمة قابلة للتبادل ولا ينبغي أن يهمّ للمتلقي كيف يتم تحويل القيمة طالما يتلقون الأموال

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

آليات النية تتيح للمستخدمين تحديد الشروط الدقيقة أو العهود التي يمكن في ظروفها تنفيذ عملية نقل قيمتهم.

نية قابلة للتطبيق هي أمر بدفع رمز X من السلسلة A لاستلام رمز Y على السلسلة B.

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

بروتوكولات تسوية النية

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

تقدم بروتوكولات تسوية النية نقل قيمة سريع ورخيص لأن الحلول الفردية يمكن أن تتحمل مخاطر النهائية وتحديد مسارات التنفيذ الأمثل

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

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

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

أكبر مصدر لتحسين السعر يأتي من الحدس بأن القيمة قابلة للتبادل، والعثور على أفضل مسار في الوقت المناسب عادة ما يفوق نقل القيمة. (ومع ذلك، ستكون بعض المسارات من المستحيل تحقيق الفوز على التكلفة في الوقت المناسب، مثل عند ربط USDC عبر CCTP.)

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

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

تقديم أمر عبر السلسلة كنية يسمح لحل الألغاز بتوظيف MEV المولد كتحسين للسعر.

الهندسة المعمارية القائمة على النية مصممة أساسًا لتكون آمنة

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

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

إذاً، كيف ينشأ تجريد السلسلة من الهندسة القائمة على النية؟

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

لا يحتاج نية المستخدم إلى أن تُقدم على السلسلة الكتلية من قبل المستخدم إذا تضمنت تصريح2أوEIP3074توقيع. هذا صحيح لكل من الجسور القائمة على تمرير الرسالة والتي تعتمد على النية. يمكن لكل من الهندسات العمارية الاستفادة من نمط Permit2 للسماح للمستخدم بتوقيع الكمية غير المتصلة التي يرغبون في دفعها من محفظة سلسلة المصدر الخاصة بهم.

تدعم أسواق النوايا تجريد السلسلة بشكل أفضل لأنها توفر نقلا رخيصا وسريعا للقيمة عبر السلسلة. تخيل عالما حيث يمكن للمستخدم أن يطلب من أحد المحللين منحه عرض أسعار للدخول في مركز WETH Staking على Arbitrum ، باستخدام USDC الخاص به على Optimism كدفعة. يمكن للمستخدم إرسال هذه النية إلى مزاد RFQ حيث يمكن للحلالين المزايدة عليها. يمكن للحل الفائز في المزاد بعد ذلك الحصول على نية المستخدم الموقعة ، والتي تحتوي على بدل لإنفاق USDC الخاص به على Optimism ، والمبلغ المطلوب من WETH لتلقيه على Arbitrum ، وبيانات الاتصال اللازمة لإيداع WETH هذا في مركز تخزين على Arbitrum. يمكن للمحلل لاحقا إرسال هذه المعاملة على Optimism (نيابة عن المستخدم) لبدء نية عبر السلسلة وسحب USDC من محفظة Optimism الخاصة بالمستخدم. أخيرا ، يمكن للمحلل ملء نية المستخدم في Arbitrum عن طريق إرسال WETH وإعادة توجيه بيانات المكالمة لإدخال المستخدم في موضع التخزين onchain.

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

هندسة النية بواسطة أكروس

لتحقيق أفضل تجربة مستخدم يجب أن تنشأ شبكة تنافسية من حلول السولفرز بناءً على الغرض

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

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

كيف يمكننا تشغيل شبكة الحل؟

يجب أن نعطي أولوية لتجربة مستخدم حل الألغاز.

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

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

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

مقترح القيمة لشبكات تسوية النية هو توفير الأمان لحل الألغاز بالإضافة إلى ميزات أخرى قد تؤثر على قدرة الحل اللغز.

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

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

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

من الواضح أننا بحاجة إلى معيار لنوايا السلسلة المتقاطعة

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

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

هذا المعيار النية يجب أن يسمح للمشغل النية أو المحلل بتحديد الشبكة التسوية التي يرغبون في تسويتها على نيتهم.

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

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

بالتعاون مع Uniswap واستنادًا إلى التغذية المرتدة من مجموعة عمل CAKE، نقترح أنا و Across المعيار النموذجي للنية عبر السلسلة التالية مع التركيز على تجربة المستخدم للمحلل:

///@titleنوع الطلب عبر السلسلة الصلبة

/// @noticeهيكل الطلب القياسي الذي يجب توقيعه من قبل المتبادلين، ونشره للملئ، وتقديمه لعقود التسوية

هيكل CrossChainOrder {

/// @dev عنوان العقد الذي يجب تسويته من قبل الطلب./// يرسل الملئون هذا الطلب إلى عنوان العقد هذا على سلسلة المصدرaddress settlementContract;/// @dev عنوان المستخدم الذي يبدأ التبادل،/// الذي سيتم أخذ رموز الإدخال الخاصة به وتوديعهاaddress swapper;/// @dev عدم التكرار الذي يجب استخدامه كحماية ضد الإعادةuint256 nonce;/// @dev chainId لسلسلة المصدرuint32 originChainId;/// @dev الطابع الزمني الذي يجب أن يتم فيه بدء الطلبuint32 initiateDeadline;/// @dev الطابع الزمني الذي يجب أن يتم فيه ملء الطلب على سلسلة الوجهةuint32 fillDeadline;/// @dev بيانات تنفيذية محددة تخص التنفيذ/// يمكن استخدامها لتحديد الرموز، الكميات، سلاسل الوجهة، الرسوم، معلمات التسوية،/// أو أي معلومات خاصة بنوع الطلب أخرىbytes orderData;

}

تم تصميم هذا المعيار لتسهيل مهمة الحلال. أحد الخيارات التي يتخذها هو دعم Permit2 / EIP3074 أصلا مع nonce و initiateDeadline ويمنح الحشو بعض الضمانات ، مثل المبلغ الذي سيتم رده من شبكة التسوية وتنسيق نية المستخدم التي يمكنهم تتبعها. علاوة على ذلك ، يتم تعريف وظيفة البدء في المعيار الذي يسمح بشكل حاسم للحشو ، الشخص الذي سيجلب الطلب على السلسلة ، بتحديد سلسلة "fillerData" إضافية لم يكن المستخدم على علم بها في الوقت الذي وقع فيه على CrossChainOrder. يسمح ذلك للحشو بالتأكد من مكافأته بموجب عقد التسوية لتقديم المعاملة الوصفية للمستخدم وكذلك تعيين معلومات محددة للسداد مثل سلسلة السداد.

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

/// @titleنوع أمر تحويل معتمد

/// @noticeتمثيل عملي للنظام بشكل عام

///@devيحدد جميع المتطلبات لملء الطلب من خلال فك تجزئة بيانات الطلب الخاصة بالتنفيذ.

/// @devمن المقرر تحسين تعميم التكامل من خلال السماح للملء بحساب المعلومات الدقيقة للمدخلات والمخرجات بأي ترتيب

هيكل ResolvedCrossChainOrder {

/// @dev عنوان العقد الذي يفترض أن يتم تسويته عن طريق.address settlementContract;/// @dev عنوان المستخدم الذي يبدأ في عملية التبادلaddress swapper;/// @dev العدد التسلسلي الذي سيتم استخدامه كحماية ضد الإعادة للطلبuint256 nonce;/// @dev ChainId للسلسلة الأصليةuint32 originChainId;/// @dev الطابع الزمني الذي يجب أن يتم فيه بدء الطلبuint32 initiateDeadline;/// @dev الطابع الزمني الذي يجب أن يتم فيه تعبئة الطلب على سلاسل الوجهةuint32 fillDeadline;/// @dev المدخلات التي يجب أخذها من المبادل كجزء من بدء الطلبInput[] swapperInputs;/// @dev المخرجات التي يجب إعطاؤها للمبادل كجزء من تحقيق الطلبOutput[] swapperOutputs;/// @dev المخرجات التي يجب إعطاؤها للملء كجزء من تسوية الطلبOutput[] fillerOutputs;

}

///@noticeالرموز التي تم إرسالها بواسطة السوابر كمدخلات للطلب

struct Input {

/// @dev عنوان عملة ERC20 على سلسلة المنشأعنوان الرمز المميز للعملة؛/// @dev كمية الرمز المميز التي سيتم إرسالهاuint256 المبلغ؛

}

///@noticeالرموز التي يجب استلامها لأجل تنفيذ الطلب بشكل صحيح

تنسيق الإخراج {

/// @dev عنوان رمز ERC20 على السلسلة الوجهة/// @dev يتم استخدام العنوان (0) كعلامة للرمز الأصلي عنوان الرمز؛/// @dev كمية الرمز المراد إرسالهuint256 المبلغ؛/// @dev عنوان لاستلام الرموز الناتجةaddress المستلم؛/// @dev سلسلة الوجهة لهذا الإخراجuint32 chainId؛

}

يجب أن ينفذ تنفيذ عقد التسوية المتوافق واجهة ISettlementContract:

/// @titleعقد تسوية ISettlement

/// @noticeالواجهة القياسية لعقود التسوية

واجهة ISettlementContract {

/// @notice تبدأ تسوية أمر عبر السلسلة الجانبية/// @dev يجب أن يتم استدعاؤها بواسطة الحشو/// @param order The CrossChainOrder definition/// @param signature توقيع المبادل على الأمر/// @param fillerData أي بيانات محددة من قبل الحشو المطلوبة من قبل المستوطنةfunction initiate(CrossChainOrder order, bytes signature, bytes fillerData) external;/// @notice يحل أمر معين عبر السلسلة الجانبية إلى أمر معين محلول عام/// @dev يهدف إلى تحسين التكامل الموحد لأنواع الأوامر المختلفة وعقود التسوية/// @param order The CrossChainOrder definition/// @param fillerData أي بيانات محددة من قبل الحشو المطلوبة من قبل المستوطنة/// @returns ResolvedCrossChainOrder بيانات الأمر المغذية بما في ذلك مدخلات ومخرجات الأمرfunction resolve(CrossChainOrder order, bytes fillerData) external view returns (ResolvedCrossChainOrder);

}

كانت أهداف تصميم هذا المعيار تعزيز تجربة مُحلل الحلول، وتسهيل دعمهم لشبكات التسوية المتعددة، وحساب مكافآتهم بشكل قطعي. أعتقد أن هذا سيسمح لهم بتقديم اقتباسات أكثر دقة وأكثر تحكمًا للمستخدمين. يمكنك قراءة المزيد من التفاصيل حول هذا المعيار، المعروف بالرمز ERC7683، في هذا المنشور على X/Twitterوالنقاش المحيط بهعلى منتدى Ethereum Magicians.

أفكار الختام

"النوايا" مربكة لأنها غير معرفة، وهذا النقص في التعريف يخلق عيوب فعلية في تجربة المستخدم.

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

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

لبدء العمل، Across و Uniswap معًااقتراح معيارلجميع أطراف سلسلة التوريد استخدامه عند التعامل مع طلبات المستخدم لإرسال الرموز X من سلسلة A واستلام الرموز Y على سلسلة B. يمكن أن يدمج تدفق الطلبات الجاري من خلال UniswapX (الذي يتمتع بميزة تنافسية في تصميم المزاد والنوايا الأصلية) وAcross (الذي يتمتع بميزة تنافسية في تسوية تحقيق النوايا) ويشعل عملية تنشيط شبكة حلول أكبر وأكثر تنافسية.

إخلاء المسؤولية:

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