مقدمة

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

ومع ذلك، فإن هذا التقدم يطرح تحديات جديدة. تقوم فرق متعددة بتطوير سلاسل كتل مستقلة فوق Ethereum ، مع إمكانية تشغيل بيني محدودة بينها. ينبع هذا القيد في المقام الأول من الانتهاء غير المتكرر من عمليات التجميع ، مما يعيق التواصل الهادف عبر السلسلة. علاوة على ذلك ، تواجه عمليات التجميع المتفائلة ، التي تستضيف حاليا غالبية نشاط النظام البيئي والقيمة الإجمالية المقفلة (TVL) ، قيودا تقنية متأصلة تمنع الاتصال المباشر خارج الجسور المشتركة ، مما يخلق حاجزا كبيرا أمام قابلية التشغيل البيني بين الشبكات الرئيسية مثل Arbitrum و Base. اقترح المجتمع حلولا مختلفة ، تتراوح من الجسور القائمة على المقاصد والمقايضات الذرية إلى تجريد السلسلة الشامل. على الرغم من اختلافاتها ، تشترك هذه الحلول في مطلب أساسي: مصدر موثوق للحقيقة - بروتوكول يتيح التحقق الآمن من الحالة بين عمليات التجميع السريعة والفعالة من حيث التكلفة.

من بين الحلول البارزة ، التي تعتمد عادة على البوابات المتفائلة أواكروس ، أو موافقة مشغل متخصص (Stargate عبر LayerZero) ، أو الثقة بالمتسلسل المركزي (Polymer Hub) ، تقدم Fast Finality Layer (NFFL) من Nuffle Labs توازنًا مقنعًا بين الكفاءة والأمان والمساواة في إثيريوم. يستكشف هذا الورقة البحثية النهج الابتكاري لـ NFFL في تمكين التحقق من الحالة عبر cross-rollup من خلال آلية إعادة الاستثمار لـ EigenLayer و NEAR DA ، ويستكشف تصميمه المعماري وخريطة تطويره ، ويحلل التطبيقات المحتملة وآثارها على النظام البيئي.

حافة إثيريومك

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

عنوان بريدك الإلكتروني

الخلفية

لفهم التحديات التي يتناولها NFFL، دعنا نفحص الهندسة المعمارية الأساسية للروبات، أهدافها، والقيود الجوهرية عليها.

الملخصات 101

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

مثال على هذا التمييز - جميع الرولابس هي L2s ، ولكن ليس كل L2s بالضرورة رولابس. المصدر: مدونة.ثردويب.كوم

بالطبع، في حالتنا، يعتبر سلسلة Ethereum الأب L1. فهي مسؤولة عن مشاركة اتفاقها مع اللفات (سنوضح هذا لاحقًا). دعونا نحلل كيف تستغل اللفات Ethereum لوظائفها الأساسية: ترتيب المعاملات وتوافر البيانات والاتفاق.

ترتيب المعاملات

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

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

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

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

مبدأ تشغيل المحرك. على الرغم من أنه لا يشغل المحرك، إلا أنه بدونه لن يعمل المحرك أيضًا. فكر في الـ rollup كمحرك وفي الـ sequencer كمبدأ تشغيل.

توفر البيانات

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

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

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

جسر موضوع (توافق)

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

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

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

Blobs

وقد أدخلت ترقية Dencun من Ethereum في مارس الماضي “النقط” - خلايا مؤقتة من البيانات التي يتم تخزينها خارج blockchain وتقليمها (حذفها من قبل مدققي الشبكة) بعد ~ 18 يوما. نظرا لأن جسور التجميع تجعل من الممكن إعادة بناء الحالة دون إعادة تنفيذ المعاملات ، أصبحت هذه الخاصية مفيدة جدا لعمليات التجميع ، والتي تم ترحيلها من calldata إلى blobs بعد فترة وجيزة من الترقية. الأرقام الناطقة ، قبل Dencun ، كان إجمالي TPS للتراكمات حوالي 50. اليوم ، أكثر من 200 ، مع حدود نظرية في 400-800 TPS اعتمادًا على الرول آب.

المصدر: L2BEAT

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

المصدر: growthepie.xyz

تسوية رولاب

بينما يدير المتسلسلون ترتيب المعاملات ونشرها، إلا أنهم يمثلون مكونًا واحدًا فقط من هندسة اللفات. تضم اللفات أيضًا كيانات تُسمى “المقترحون” المسؤولة عن إقناع جسر L1 بالنواتج الحالية المحددة ناتجة عن دفعات المتسلسلة الجديدة. في جوهره، بينما يُنشئ المتسلسلون حدوث وترتيب المعاملات، يظهر المقترحون نتائج هذه المعاملات وفقًا لمنطق معالجة اللفة، مثل آلته الظاهرية.

دور المقترح يختلف بشكل كبير بناءً على نهج التحقق من حالة الروولاب. يوجد اثنان منهجيات مختلفة بشكل جوهري، تحدد اثنتان من فئات الروولاب: التفاؤلية والمعرفة الصفرية (ZK).

تكديس التحسن

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

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

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

تجميعات الأدلة الصفرية

في اللفات ZK، يولد المقترحون دلائل رياضية (تسمى “validity proofs” أو “ZK proofs” بشكل أكثر دقة تقنية) تثبت صحة كل عملية انتقال حالة. توضح هذه الدلائل الرياضية أن جميع المعاملات في الدفعة تم تنفيذها وفقًا لقواعد اللفة دون الكشف عن التفاصيل الخاصة بتنفيذها.

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

التسوية والنهائية والتوافق

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

تفكر في كيف يؤثر هذا على استخدام العالم الحقيقي: المستخدم الذي يرغب في استخدام ضمانه القائم على Arbitrum للحصول على قرض على منصة Base يجب أن يقوم أولاً بتوجيه أصوله والانتظار لمدة تصل إلى 7 أيام قبل أن يتمكن من استخدامها. المتداول الذي يرصد فرصة الارتباط بين حمامات Uniswap على rollups مختلفة سيرى الفرصة تختفي قبل فترة طويلة قبل أن يتمكن من تنفيذها. تطبيق الألعاب الذي يرغب في السماح للاعبين بتداول العناصر عبر نشرات rollup مختلفة سيواجه تجربة مستخدم غير مقبولة مع تلك التأخيرات الطويلة.

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

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

الحلول الحالية

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

• الأمان - مدى قوة الضمانات بأن التحقق من الحالة صحيح
• السرعة - مدى سرعة التحقق من الحالة عبر الشبكات
• التكلفة - مدى ارتفاع تكلفة الحفاظ على الحل واستخدامه

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

التحدي الأساسي هو إنشاء “مصدر موثوق” آمن حول حالات الرولاب التي يمكن أن تكون:

• التحقق من تغييرات الحالة في غضون ثوانٍ أو دقائق بدلاً من ساعات أو أيام
• توفير ضمانات أمان cryptoeconomic قوية
• تشغيل بتكلفة فعالة لمقدمي البنية التحتية والمستخدمين
• الاندماج بسلاسة مع البنى التحتية للرول اب الموجودة

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

في الأقسام التالية، سنستكشف كيف يتعامل NFFL مع هذا التحدي من خلال تراكب EigenLayer الجديد و NEAR DA، مما يخلق طبقة نهائية سريعة تضرب توازنًا حذرًا بين الأمان والسرعة والكفاءة التكلفة.

NFFL تفحص عمقاً

الأطروحة الأساسية

تمثل Nuffle Fast Finality Layer (NFFL) نهجًا جديدًا لتمكين التفاعلات الآمنة عبر السلاسل الفرعية من خلال توفير التحقق السريع من الحالة بين rollups. بدلاً من إجبار المطورين على اختيار بين الأمان والسرعة، يستفيد NFFL من إعادة تثبيت ETH الخاص بـ EigenLayer لإنشاء طبقة نهائية سريعة مؤمنة من الناحية الكريبتواقتصادية يمكنها الشهادة على حالات rollup في غضون ثوانٍ.

في جوهرها، يعمل NFFL كخدمة معتمدة بنشاط (AVS) تعمل على EigenLayer. شبكة لامركزية من المشغلين، يقوم كل منهم بتشغيل العقد الكاملة للمشاركة في الروابط، يتحقق ويشهد على تحديثات الحالة. تدعم هذه الشهادات بـ ETH المعادة المراهنة من قبل المشغلين، مما يخلق حوافز اقتصادية قوية للسلوك الصادق. من خلال الجمع بين ذلك مع طبقة توفر البيانات في NEAR لتخزين البيانات الكتلية بكفاءة، يمكن لـ NFFL تمكين التطبيقات من التحقق الآمن لحالة السلسلة المتقاطعة في 2-3 ثوانٍ - أسرع بأمر من التسوية الجسرية الكنسية.

التصميم المبسط المعماري لـ NFFL

ما يجعل NFFL مثيرًا للاهتمام بشكل خاص هو نهج تصميمه العملي. بدلاً من محاولة استبدال نموذج أمان Ethereum أو منافسته ، يوفر طبقة تكميلية محسّنة لحالات الاستخدام التي تتطلب سرعة النهاية. يمكن للتطبيقات اختيار الاعتماد على أمان NFFL الكريبتواقتصادي أو الانتظار لتسوية L1 الكاملة بناءً على احتياجاتها المحددة. يتيح هذا المرونة لـ NFFL تحسين تجربة المستخدم للعديد من التفاعلات العابرة للسلاسل في حين الحفاظ على ضمانات أمان قوية.

يقدم النظام ثلاثة ابتكارات رئيسية:

1. شبكة المشغل المتمركزة التي تحقق اتفاقًا حول حالات ال rollup من خلال مقارنة التحولات الحالية المنفذة محليًا مقابل بيانات الكتلة المنشورة إلى NEAR DA
2. نظام مهام يعتمد على نقاط التفتيش يتيح تجميع وتحقق فعال لشهادات المشغلين مع الحفاظ على المساءلة من خلال آليات التقطيع الخاصة بـ EigenLayer
3. آلية تخزين البيانات باستخدام NEAR DA التي تسمح بسهولة استرداد البيانات المدعومة عبر جميع الـ rollups

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

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

المكونات الأساسية

مجموعة المشغل

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

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

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

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

للنظام الأمن الاقتصادي خاصية مثيرة للاهتمام جدًا تنبع من ميكانيكيات الحذف التابعة لـ EigenLayer:

في EigenLayer ، يمكن للخدمات التي تم التحقق من صحتها بنشاط تنفيذ آلية تحقق قادرة على اكتشاف الشهادات غير الصالحة من المشغلين ، وخفض (تصفية) إيداعهم بعد ذلك. نظرا لأن NFFL “يستقر مبدئيا” إلى حد ما حالة التجميع خارج السلسلة قبل أن يستقر في الجسر ، فمن الممكن اكتشاف الاحتيال بشكل موضوعي من خلال انتظار تأخير التسوية وإخطار عقد AVS بعدم تناسق الإنتاج في الشهادة والجسر. هذا يثبط اقتصاديا الشهادات الاحتيالية ، حيث يمكن اكتشافها وخفضها من قبل أي كيان يراقب حالة L1 و NFFL ، حتى بدون تشغيل العقد التراكمية. بمعنى آخر ، NFFL “يؤمن” مطالبات الشبكة - يعرض المشغلون رأس مال كبير للخطر لدعم مطالباتهم حول حالات التراكم.

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

تدفق الرسائل

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

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

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

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

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

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

خدمة الوسيط

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

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

يعمل عملية تجميع التوقيع كما يلي:

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

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

تجميع التوقيع

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

المكاسب في الكفاءة هنا كبيرة. عندما يقوم مشغلو NFFL بتوقيع رسالة ، فإنهم يولدون توقيعات BLS القياسية باستخدام مفاتيحهم الخاصة. يمكن للمجمع الجمع بين هذه التوقيعات الفردية في توقيع واحد مدمج يثبت اتفاق الكوروم. يظل حجم وتكلفة التحقق من هذا التوقيع المجمع ثابتًا بغض النظر عن عدد المشغلين الذين شاركوا - وهو سمة تجعل النظام قابلًا للتوسع بشكل كبير.

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

المُجمع ونقاط الفحص

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

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

عقود السجل

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

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

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

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

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

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

تصنيف الأخطاء وتصميم الأمان

يتمحور نموذج الأمان في NFFL حول اكتشاف ومعاقبة نوعين رئيسيين من سلوك المشغل غير الصالح: أخطاء السلامة وأخطاء الحيوية.

عيوب السلامة هي الانتهاكات التي تؤثر على سلامة الشبكة من خلال إنتاج حالات غير صحيحة أو نتائج غير متسقة مع قواعد النظام. هناك نوعان رئيسيان من عيوب السلامة التي يمكن للمشغلين الارتكاب بها:

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

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

عملية التحدي تختلف بناءً على نوع الخطأ والرسالة المتحدة:

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

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

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

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

أمثلة عملية في العالم الحقيقي

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

بروتوكول مرحبا

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

فكر في مستخدم يرغب في إرسال رسالة على الشبكة #1 التي سيتم قراءتها على الشبكة #2. يبدأ العملية عندما يقومون بإرسال عملية على الشبكة #1 تسجل رسالتهم “مرحبًا!” في حالة الشبكة. في هذه النقطة، توجد الرسالة فقط على الشبكة #1 وعادةً ما تتطلب الانتظار حتى يتم تسوية الجسر الكنسي (التي يمكن أن تستغرق ساعات أو أيام) قبل أن يتم التحقق منها من قبل لفات أخرى.

هنا يأتي دور NFFL. عند إنتاج الكتلة التي تحتوي على هذه الرسالة، يتم نشرها إلى NEAR DA عن طريق المعادل الشبكي. مشغلو NFFL، الذين يقومون بتشغيل العقد الكاملة لكلتا الشبكتين، يتحققون من أن بيانات هذه الكتلة تتطابق مع ما قام به عقد شبكتهم رقم 1 محليًا. بعد التحقق، يقومون بتوقيع الرسائل التي تشهد على جذر الحالة الجديد.

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

الآن يأتي الجزء المثير - استهلاك الرسالة على الشبكة #2. يمكن لعقد بروتوكول السلام على الشبكة #2 قبول عملية تحتوي على:

• البرهان التخزين يظهر أن الرسالة موجودة في حالة الشبكة #1
• تصديق NFFL يثبت صحة هذه الدولة
• إشارة إلى معاملة NEAR DA التي تحتوي على بيانات الكتلة

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

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

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

جسر الرموز سريع ورخيص

بناءً على هذه الأسس، دعونا نستكشف تطبيقًا أكثر عملية - جسر رمز يستفيد من NFFL للتحويلات السريعة بين الرولاب. يجبر المشهد الحالي للجسور على تسويات صعبة بين السرعة والتكلفة والأمان. لنتفحص كيف يمكن لـ NFFL أن تعدل هذه الديناميات.

توضح الجسور الرائدة اليوم هذه التنازلات بوضوح. يحقق ستارجيت، الذي يعتمد على لاير زيرو، تكاليف منخفضة نسبيًا ولكنه يستغرق 10-30 دقيقة لإتمام التحويلات بسبب حاجة شبكة المشغل إلى تحقيق ونقل التوافق عبر سلاسل متعددة. يوفر أكروس تحويلات سريعة تقريبًا ولكن بتكاليف أعلى بنسبة 10-100 مرة، بشكل رئيسي بسبب مخرجات أوراكل أوما المكلفة ودورات إعادة التوازن البطيئة (6 ساعات) التي تؤثر على كفاءة السيولة.

NFFL يقدم نموذجًا جديدًا هنا. من خلال استغلال إطار AVS لـ EigenLayer بدلاً من الاحتفاظ بشبكة مشغل منفصلة ، يمكن لـ NFFL تحقيق اتفاق حول حالات اللفة في غضون ثوانٍ. يمكن نقل هذا التوافق بكفاءة من خلال عقود السجل عبر جميع عمليات اللفات المشاركة ، مما يتيح تصميمات الجسر التي تجمع بين كفاءة تكلفة ستارغيت مع قابلية تأكيد أسرع من Across.

فكر في مستخدم يقوم بنقل ETH من Arbitrum إلى Base. عندما يتم قفل الرموز في عقد الجسر على Arbitrum ، يقوم مشغلو NFFL بالتحقق والتصديق على هذا التغيير في الحالة من خلال العُقد الكاملة لديهم. بمجرد جمع الوسّطاء للتحققات الكافية ، يمكن لعقد الجسر على Base التحقق من قفل الرمز عبر عقده السجل الخاص به وإطلاق الأموال للمستخدم على الفور.

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

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

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

بروتوكول الإقراض متعدد السلاسل

يمثل الإقراض عبر السلاسل ربما التطبيق الفوري الأكثر إقناعًا لـ NFFL. تواجه بروتوكولات الإقراض الحالية قيودًا كبيرة بسبب تشظي السلاسل. خذ Aave - على الرغم من أنه يتم نشرها عبر عدة rollups، يعمل كل نشر بشكل منفصل. يجب على المستخدمين الراغبين في استخدام الضمانات عبر السلاسل تقديم الأصول والانتظار، مما يؤدي إلى تشظي السيولة وتقليل كفاءة رأس المال. علاوة على ذلك، بعض النشرات على rollups الأصغر حتى لا تحتوي على السيولة الكافية لأي إقراض ذي مغزى، مما يشكك في موقف Aave التسويقي للإقراض البسيط للجميع بأي حجم. “فقط استخدم Aave.” … لكن فقط على أكبر نشراتها.

تمكّن NFFL من نهج أساسي مختلف. فكر في برتوكول الإقراض الذي يحتفظ بحمامات عبر عدة rollups ولكن يستخدم NFFL لمشاركة حالة الضمانات بينهم. يمكن للمستخدم إيداع USDC كضمان على Base، ثم اقتراض USDT على Arbitrum على الفور ضد نفس الضمان حتى لو لم يتم نشر USDT على Base على الإطلاق. يتحقق عقد Arbitrum للبروتوكول ببساطة من الموقف الضماني على Base من خلال شهادات NFFL، دون الحاجة إلى جسر.

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

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

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

Cross-DEX: نشر مرة واحدة، استخدام في كل مكان

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

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

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

عند النظر في بورصة DEX جديدة تنتشر حصريًا على منصة Arbitrum، المختارة بسبب نظامها البيئي المستقر لـ DeFi وتكاليف الغاز المفضلة. بدلاً من إطلاق حالات منفصلة عبر الشبكات، يحافظ على مجموعات السيولة الموحدة على منصة Arbitrum مع تمكين الوصول إلى التداول من أي rollup. هكذا يمكن للمستخدم على منصة Base التفاعل معها:

1. يريد أليس تبادل 10،000 دولار أمريكي لـ ETH على Base
2. يستعلم واجهة الـ DEX القاعدية حالة حوض Arbitrum عبر شهادات NFFL
3. أليس ترى أنها يمكنها الحصول على تسعير أفضل من البرك المجزأة التي يقدمها بيس
4. توافق على التجارة في قاعدة
5. تنفذ العملية على أربيترام، مع النتيجة الموثقة إلى القاعدة

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

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

ولكن NFFL يتيح نمطًا أكثر قوة - لف أنظمة البروتوكولات DeFi الحالية للوصول العابر للسلاسل. بدلاً من بناء حوض سيولة منافسة، يمكن للمطورين إنشاء بروتوكولات “مساعدة” تجعل حمامات السيولة الضخمة لـ Arbitrum متاحة من أي تراكب.

نشرات Uniswap مع أكبر قيمة مقدارها TVL. تتصدر قاعدة وأربيتروم الرسم البياني، مع أن التفاؤل يمتلك TVL أصغر بمقدار 6 أضعاف من أي منهما، وتتراجع العناوين الفرعية الأخرى تحت “أخرى”. المصدر: DefiLlama

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

1. استعلم عن السيولة المتاحة عبر جميع حمامات أربيتروم يونيسواب عن طريق شهادات NFFL
2. العثور على سيولة عميقة للزوج المطلوب في بركة أربيتروم معتمدة
3. تنفيذ التجارة من القاعدة من خلال بروتوكول التغليف
4. استلم رموزه على Base بمجرد أن يشهد NFFL على اكتمال التبادل

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

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

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

• تكاليف الغاز لعملياتهم المحددة
• التراكم التكنولوجي - الجهاز الافتراضي، AA، نوع التسلسل، DA، الخ.
• الاعتبارات التنظيمية

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

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

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

خريطة الطريق وتطوير المستقبل

بينما يتيح NFFL بالفعل تطبيقات قوية جديدة للتبادل المشترك بين الشبكات ، فإن البروتوكول ما زال يتطور. يركز خارطة الطريق التنموية لـ NFFL على ثلاثة مجالات رئيسية:

أمان البروتوكول

• تنفيذ آليات تحدي شاملة وآليات تقليص من خلال طبقة Eigen
• تفعيل مشاركة المشغل غير المقيدة بإدارة قوية للرهان
• تعزيز التحقق من الحالة عبر السلسلة مع تحسين الأدوات المشفرة (BLS→ECDSA)

قابلية التوسع الشبكية

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

تجربة المطور

• بناء SDK والأدوات لسهولة التكامل
• توسيع الدعم لأنواع مختلفة من ال Rollup والـ VMs
• إنشاء وثائق وأمثلة لحالات الاستخدام الشائعة

في الأقسام التالية، سنستكشف بعض التحسينات المخطط لها الأكثر أهمية بالتفصيل.

BLS إلى ECDSA

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

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

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

مجموعات المشغل الديناميكي

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

سيُسمح لنظام المشغل الديناميكي للمشغلين الجدد بالانضمام إلى الشبكة بدون إذن عن طريق الرهان من خلال EigenLayer. وهذا يُعرض العديد من التحديات التقنية التي يجب التعامل معها بعناية:

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

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

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

إيقاف عجلات التدريب

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

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

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

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

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

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

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

مستقبل الانتهاء السريع

على الرغم من أن NFFL يوفر حلاً فورياً للتحقق من حالة النقل المتقاطع ، إلا أنه يستحق النظر في كيف يندمج البروتوكول في خارطة طريق Ethereum للتوسع العامة. السؤال الرئيسي الذي يطرحه الكثيرون هو: “هل سيظل NFFL ذا صلة بينما تتقدم تكنولوجيا النقل المتداول؟”

يصبح الجواب واضحًا عندما نفحص قيود التسوية الأساسية في تصاميم Rollup المختلفة. على الرغم من شعبيتها ونضجها ، لا يمكن لـ Optimistic Rollups بشكل أساسي التسوية بشكل أسرع من نافذة إثبات الاحتيال الخاصة بها - وهي عادة ما تكون 7 أيام. بينما تمكن حلول مثل Superchain لـ Optimism و Arbitrum Orbit من تسهيل التواصل الأسرع بين Rollups التي تشترك في جسر واحد ، إلا أنها لا تساعد في التوافق خارج بيئاتها المحددة - على سبيل المثال ، بين هاتين الحلتين.

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

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

من المهم ألا يُنظر إلى NFFL على أنه يتنافس مع نموذج أمان Ethereum’s rollup أو يشكل تهديدًا له. بل يوفر أداة مكملة تمكن من إمكانيات جديدة داخل نظام البنية الأساسية Ethereum القابل للتعديل. يمكن لتطبيقات استخدام NFFL للتحقق السريع من الحالة مع الاعتماد على التسوية الكنسية من خلال L1 عند الحاجة. يُنشئ هذا مجموعة أدوات أكثر ثراءً للمطورين لبناء تطبيقات عبر السلاسل مع نماذج أمان مناسبة لاحتياجاتهم الخاصة.

استنتاج

تمثل NFFL نهجًا جديدًا لحل أحد التحديات الأكثر إلحاحًا في البيئة النظامية لإثيريوم - تمكين التحقق الآمن والفعال من الحالة عبر الإطار المتداخل للحسابات. من خلال استغلال تجميع ETH من EigenLayer للأمان الاقتصادي و NEAR DA لتخزين البيانات الفعال، يقوم NFFL بإنشاء طبقة للانتهاء السريع يمكن أن تتحقق من حالات الانتقال داخل ثوانٍ بدلاً من ساعات أو أيام.

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

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

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

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

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

1. تمت إعادة طبع هذه المقالة من[[](https://research.2077.xyz/nuffle-ethereums-finality-as-a-service-layer#introduction)[2077 بحث](https://research.2077.xyz/)\]. جميع حقوق الطبع والنشر تنتمي إلى الكاتب الأصلي [أليكس هوك]. إذا كان هناك اعتراضات على إعادة النشر هذه، يرجى التواصل مع بوابة التعلمالفريق، وسوف يتعاملون معه بسرعة.
2. تنويه المسؤولية: الآراء والآراء المعبر عنها في هذه المقالة هي فقط تلك التي تنتمي إلى المؤلف ولا تشكل أي نصيحة استثمارية.
3. يتم إجراء ترجمات المقال إلى لغات أخرى من قبل فريق تعلم gate. ما لم يرد ذكره، يُحظر نسخ أو توزيع أو نسخ المقالات المترجمة.