تحلل هذه الورقة التقنيات الرئيسية لأجهزة التسلسل المشتركة: مقاومة شديدة للرقابة ، وسهلة النشر ، وقابلة للتشغيل البيني ، وسريعة التحديد ، وفورية. توفر نظرية التجميع منظورًا جديدًا لها ، ويوجه التكامل الرأسي مزيدًا من التطوير.
** العنوان الأصلي: "**** The Shared Sequencer ****" **
** بقلم: MAVEN11 **
** التجميع: Kxp، BlockBeats **
تخيل ما سيكون عليه الحال إذا تمكنت Rollup "خارج الصندوق" من تحقيق درجة عالية من مقاومة الرقابة ، وسهولة النشر ، وإمكانية التشغيل البيني ، والنهاية السريعة ، والحيوية ، وإضفاء الطابع الديمقراطي على MEV. قد يبدو هذا كهدف كبير ، ولكن مع ظهور التسلسل المشترك ، قد يصبح حقيقة واقعة قريبًا. ومع ذلك ، ليست كل المجموعات هي نفسها ، لذلك يتعين علينا التفكير في كيفية توزيع المكافآت و MEV على شبكة جهاز التسلسل المشترك. في هذه الورقة ، نستكشف كيفية تنفيذ شبكات التصنيف المشتركة والخصائص التي يمكن تحقيقها.
تم تقديم شبكات التسلسل المشتركة بشكل أساسي بواسطة Alex Beckett ، وفي وقت لاحق بواسطة Evan Forbes (و Radius) من فريقي Celestia و Espresso ، ومقال جديد بقلم Jon Charbonneau يغطي الموضوع بمزيد من التعمق. جوش ، جوردان ، وفريقهم في Astria يبنون أول شبكة تسلسل مشترك جاهزة للإنتاج. شبكة الطلبات المشتركة في Astria عبارة عن blockchain معياري يقوم بتجميع معاملات Rollup وطلبها دون تنفيذها.
في إعداد Astria ، يرسل عامل الفرز الكتل المرتبة إلى طبقة DA وأيضًا إلى عقد الالتفاف. تحصل التراكميات على ضمانات نهائية ناعمة من صاحب الطلب وضمانات نهائية صارمة من طبقة DA (بعد إنهاء الكتل) ، وبعد ذلك سيتم تنفيذ المعاملات الصحيحة.
شبكة التسلسل المشترك هي في الأساس مجموعة من أجهزة التسلسل المتوافقة مع Rollup ، كما يوحي اسمها ، يمكنها تقديم خدمات لمجموعة مختلفة من Rollups. هذا له العديد من المفاضلات والخصائص ، والتي سنقوم بتفصيلها لاحقًا. أولاً ، يجب أن نصف أهم خصائص الفارز (أو مجموعة الفرز). في Rollup ، المطلب الرئيسي لمنظم التسلسل أو مجموعة من أجهزة التسلسل هو مقاومة الرقابة أو الحيوية (بعضها يأتي من الطبقة الأساسية ، بالإضافة إلى الأمان). هذا يعني أن المعاملة الصالحة التي يتم إرسالها إلى مقدم الطلب يجب أن يتم تضمينها في السلسلة في غضون فترة زمنية محدودة (معلمة المهلة). تحتاج مجموعة الطلبات المشتركة فقط إلى ضمان تضمين المعاملات في الكتل (أي قوائم crLists).
إن تلبية مقاومة الرقابة والفورية في نفس الوقت أمر صعب للغاية ، كما أوضحنا في Modular MEV Part II. في خوارزمية إجماع مثل Tendermint ، يمكنك ضمان التعافي بعد الهجوم. ومع ذلك ، في حالة وقوع هجوم ، تفقد السرعة. بشكل أساسي ، قد لا يكون طلب جميع أدوات التوليف الأخرى للتوقيع على كتلة ، بدلاً من اختيار رمز رئيسي مخصص ، هو الأمثل. في حين أن هذا يحسن مقاومة الرقابة ، فإنه يأتي على حساب "المركزية" واستخراج MEV إلى رمز رئيسي واحد. يمكن مقارنة آلية الفرز الأخرى المتاحة بـ Duality's Multiplicity ، وهي أداتهم الصغيرة لغير الرموز الرئيسية (أو الفرز) لتضمين المعاملات الأخرى في الكتل. بشكل عام ، يصعب تحقيق مقاومة الرقابة والفورية بعد الهجوم في معظم بروتوكولات الإجماع.
خوارزمية إجماع أخرى يمكن استخدامها هي HotStuff 2 ، والتي تضمن السرعة في حالة وقوع هجوم.
ما يسمح به هو تجنب انتظار الحد الأقصى لتأخير الشبكة (المهلة) في حالة الرقابة أو عدم التوقيع لانتخاب رمز رئيسي جديد. السبب في أنها قد تكون خوارزمية إجماع مثيرة للاهتمام لمجموعة لامركزية من الطلبات هو أنها تحل مشكلة فورية بالإجماع دون إضافة مرحلة إضافية. إذا كان ماسترنود يعرف أعلى قفل (أكبر عدد من المشاركين يتفقون على ناتج معين) ، ويمكنه إقناع الأطراف الصادقة ، يتم حل المشكلة. إذا لم يكن الأمر كذلك ، يمكن أن يتولى الرمز الرئيسي الصادق بعد نقطة معينة مسؤولية الدفع ، مما يساعد على الرمز الرئيسي التالي. على سبيل المثال ، لا تحتاج عقدة Hotstuff إلى استلام رسالة تبديل قبل إخطار رئيس جديد ، ولكن يمكنها التبديل مباشرةً إلى طريقة عرض جديدة وإخطار المدير الجديد.
الاختلاف مع Tendermint هو أنه على الرغم من أن كلاهما على مرحلتين (Hotstuff1 له ثلاثة ، Hotstuff2 له اثنان) ، فإن Tendermint لديه اتصال خطي ولكنه لا يستجيب ، بينما Hotstuff2 هو رد الفعل. إذا كانت هناك سلسلة من Masternodes صادقة ، فإن البروتوكول يستجيب بشكل إيجابي ، لأن جميع الخطوات باستثناء اقتراح Masternode الأول تعتمد على الحصول على كمية المعلومات من الخطوة السابقة. في إعداد الطلب المشترك ، يسمح هذا للبروتوكول بتحقيق فورية أفضل دون الرجوع إلى الطبقة السفلية ، مع عدم إلغاء هذا الاحتمال.
بناء مجموعات فارز مشتركة
يُسمح لمجموعة من أوامر الشراء بإرسال المعاملات إلى طبقة التسوية (الطبقة التي يوجد بها التجميع). يمكنك الانضمام إلى مجموعة التجميع هذه ، بشرط استيفاء متطلبات معينة وعدم الوصول إلى العدد المطلوب من منتجي الكتل. يعمل هذا على تحسين زمن الوصول والإنتاجية والمزيد. هذه المتطلبات مشابهة لتلك المطلوبة لتصبح مدققًا لـ blockchain. على سبيل المثال ، يجب أن تفي بمتطلبات معينة للأجهزة ، بالإضافة إلى إيداع أولي ، خاصة إذا كنت ترغب في التأكد من الظروف المالية.
تتكون مجموعة الطلبات المشتركة (أو أي مجموعة أوامر لامركزية) من عدة مكونات تعمل معًا لضمان المعالجة الصحيحة للمعاملات ، بما في ذلك:
قم بتوفير JSON-RPC لكل مجموعة تجميعية لتقديم المعاملة (لمشغلي العقدة غير الكاملة) إلى العقدة كمجمع ذاكرة ، ثم قم بالبناء والفرز. في mempool ، هناك حاجة إلى بعض الآليات لتحديد قائمة الانتظار ، وكذلك عملية اختيار المعاملة ، لضمان البناء الفعال للكتل.
خوارزمية بناء الكتلة / الدُفعات ، وهي مسؤولة عن معالجة المعاملات في قائمة الانتظار وتحويلها إلى كتل أو دفعات. قد تتضمن هذه الخطوة أيضًا ضغطًا لتقليل حجم الكتلة الناتج (يسمى ضغط البيانات). كما ذكرنا ، يجب أن يكون هذا منفصلاً عن مقدم العرض ، أي دعم السلوك الإيجابي بشكل أساسي. يمكن ضغط البيانات بعدة طرق ، على سبيل المثال:
لا يوجد تشفير RLP - ومع ذلك ، قد يتطلب ذلك مجموعة لامركزية من المجمعات للمساعدة في تطبيع نقل البيانات بين العقد ، وبالتالي توفير المساحة.
حذف nonce (رقم فريد للتحقق من صحة البيانات في كتلة معينة) - يمكن إعادة حسابها في وقت التنفيذ من خلال النظر في الحالة السابقة للسلسلة.
تبسيط سعر الغاز - حدد الغاز بناءً على نطاق سعري ثابت.
تبسيط الغاز - بالإضافة إلى سعر الغاز ، يوجد أيضًا نظام ترقيم للغاز.
استبدال العنوان بالفهرس - يمكن أن يخزن الملف التراكمي فهرسًا لعنوان معين بدلاً من تخزين العنوان الكامل.
القيم المعبر عنها في الترميز العلمي - حقول القيمة في معاملات Ethereum مقومة بـ wei ، وبالتالي فإن القيم كبيرة. لا يمكنك حذف الحقول الرقمية أو تقليلها إلى مجموعة ثابتة من القيم. ومع ذلك ، يمكنك كتابتها بترميز علمي لتحسين تخزين البيانات:
إغفال حقول البيانات: حقول البيانات ليست مطلوبة لعمليات النقل البسيطة ، ولكنها مطلوبة للمعاملات الأكثر تعقيدًا.
استبدل التوقيعات الفردية بالتوقيعات المجمعة من BLS: التوقيعات هي أكبر عنصر في معاملات Ethereum. بدلاً من تخزين كل توقيع ، يمكنك تخزين توقيعات BLS المجمعة لعدد معين من المعاملات. يمكنك أيضًا التحقق من التوقيع الكلي BLS مقابل مجموعة الرسائل وتعيين المرسل لضمان صلاحيتها.
استخدم الحقل من كفهرس: مثل الحقل "إلى" ، يمكنك استخدام الحقل "من" كفهرس للتعيين.
أحد المفاهيم المثيرة للاهتمام للتصميم "المعياري" هو أنه يمكنك إجراء تعديلات ومقايضات حسب الحاجة لجعلها تعمل مع مجموعة التحديثات الخاصة بك.
تسمح طبقة الند للند للمُطلبين بتلقي المعاملات من الطلبات الأخرى ونشر الكتل بعد الإنشاء. هذه الخطوة مهمة لضمان أن المُسلسِل المشترك يعمل بكفاءة عبر مجموعات متعددة.
خوارزمية دوران رئيسية لمجموعات أوامر الشراء المشتركة (لا يتطلب إجماعًا في حالة الاختيار الرئيسي الفردي). يمكنك اختيار تعيين خوارزمية دوران العقدة الرئيسية فقط ، أو اتخاذ مسار منتج الكتلة المتزامن المتعدد الذي اقترحته Duality.
يمكن أن تضمن خوارزميات الإجماع ، مثل Tendermint المذكورة أعلاه أو Hotstuff2 ، أن تتوافق عقد التجميع مع التسلسل الذي يقترحه دفتر الأستاذ.
عميل RPC لإرسال الكتل / الدُفعات إلى طبقة إجماع DA + الأساسية بحيث يمكن إضافة الكتل / الدفعات بأمان إلى طبقة DA ، مما يضمن النهاية "النهائية" وإتاحة جميع بيانات المعاملات على السلسلة.
فصل الأدوار بين البناة والمنتجين لضمان العدالة والاتساق ، وتجنب سرقة MEV. يزيل أيضًا الفرز الذي تم إجراؤه ، وهو أمر مهم لتحسين الكفاءة وتقليل PGA وزيادة CR.
تتلقى عُقد الالتفاف كتلًا مرتبة من أداة الفرز لتقديمها بشكل سلس ، وتتلقى كتل طبقة DA المطلوبة للتقديم الصعب. *
يتم نشر Calldata أولاً إلى الشبكة الأساسية ، حيث يتم تشغيل الإجماع لضمان معاملات المستخدم والتجميع. بعد ذلك ، تقوم عقدة التجميع بتنفيذ المعاملة وإرسال وظيفة انتقال الحالة إلى سلسلة Rollup الأساسية. توفر شبكة من أوامر الشراء المشتركة خاصية Rollup الفورية ومقاومة الرقابة. تحافظ المجموعات التراكمية على سيادتها لأن جميع بيانات المعاملات مخزنة في الطبقة الأساسية ، مما يسمح لها بالتشعب من الأمر المشترك في أي وقت. يتم حساب جذر الحالة الخاص بوظيفة انتقال حالة الالتفاف (STF) من جذور المعاملة (المدخلات) المرسلة من الأمر المشترك إلى طبقة DA. في Celestia ، يتم إنشاء جذور الحالة عند إضافة البيانات إلى السلسلة والتوصل إلى توافق في الآراء. نظرًا لأن لديك بالفعل جذر المعاملة (وجميع البيانات المتاحة) ، يمكن أن توفر Celestia للعملاء الخفيفين (عقد التجميع التي تعمل على Celestia) مع دليل صغير على التضمين.
من أجل توفير تجربة المستخدم التي يتوقعها المستخدمون ، تتلقى عقد الالتفاف كتلًا مرتبة (يتم إرسالها أيضًا إلى طبقة DA). يمكن أن يوفر هذا Rollup ضمانات حتمية ناعمة - ضمانات بأن الكتل سيتم ترتيبها في النهاية بالترتيب على طبقة DA ، وعند هذه النقطة تنفذ العقد التراكمية المعاملات وتوفر جذور حالة جديدة.
بلوك الإنشاء والفتحة
من أجل تحديد وقت إنشاء الكتلة ، يحتاج منظم التسلسل إلى ضبط الفتحة. يجب على جهاز التسلسل إرسال الدُفعات على فترات زمنية ثابتة (عادةً X ثانية) ، حيث يمثل X وقت الفتحة. يضمن هذا معالجة المعاملات بسرعة وكفاءة ، لأنه بخلاف ذلك ، سينتهي الرمز الرئيسي لفتحة معينة ويفقد مكافأة التوقيع (ومكافأة التنفيذ). على سبيل المثال ، يبلغ وقت حظر Celestia (وفقًا لمواصفات GitHub) حوالي 15 ثانية. نظرًا لأن هذا معروف ، يمكننا وضع بعض الافتراضات حول عدد "الفتحات / الكتل" التي قد تكون لدينا من مجموعة coorters المشتركة إلى طبقة DA ويتم تحميل عقد الالتفاف في الكتل النهائية. في هذا الصدد ، يمكننا الرجوع إلى Tendermint أو Hotstuff2 المحسن.
ضمن نفس الفتحة ، يمكننا إرسال دفعات متعددة من المعاملات ، بشرط أن يتضمن التصميم آليات للعقد التراكمية الكاملة لمعالجتها بكفاءة في كتلة واحدة (خلال تلك الفترة الزمنية ومعلمات المهلة). يساعد هذا في تحسين إنشاء الكتل بشكل أكبر ويضمن معالجة المعاملات بسرعة. بالإضافة إلى ذلك ، يمكن أيضًا استخدام الفتحات لتسهيل اختيار العقد الرئيسية للفرز. على سبيل المثال ، يمكنك تحديد عقدة رئيسية للفتحة بشكل عشوائي من مخزن التخزين على أساس وزن التخزين المؤقت. إن القيام بذلك بطريقة تحافظ على السرية ، وتوظف شيئًا مثل انتخاب القائد السري لتقليل الرقابة هو الخيار الأفضل ؛ أو حتى إعداد تكنولوجيا التحقق الموزعة مثل حلول مثل Obol / SSV. الكمون ووقت الفتحة لهما تأثير كبير على عمليات الإرسال المجمعة والبناء على البروتوكول. لذلك نحن بحاجة إلى النظر في كيفية تأثير ذلك على النظام. لدى Bloxroute بعض نقاط البحث والبيانات الرائعة حول Ethereum على وجه الخصوص. في MEV-Boost ، يطلب منتجو الكتل المشاركين (المدققون أو أجهزة التسلسل في حالة التراكمية) GetHeader من المرحل. يمنحهم هذا قيمة عرض سعر الكتلة ، وهي قيمة كتلة معينة. قد يكون هذا هو أعلى كتلة يتم تلقيها في كل مرة. لكل فتحة ، يطلب المدققون عادةً GetHeader حوالي 400 مللي ثانية بعد بدء الفتحة - نظرًا للعدد الكبير من أدوات التحقق ، غالبًا ما تحتاج المرحلات إلى إرسال طلبات عديدة. هذا أيضًا ما يمكن أن يحدث مع مجموعات الفرز المشتركة الكبيرة. هذا يعني أنك بحاجة إلى البنية التحتية الموجودة لتسهيل هذه العملية.
تساعد المرحلات أيضًا في تسهيل فصل البناة ومنتجي الكتل ، مع التحقق أيضًا من أن البناة قاموا ببناء الكتل الصحيحة. كما أنهم يتحققون من دفع الرسوم بشكل صحيح ويعملون كحماية DoS. أيضًا ، هم في الأساس أمناء على الكتل ويتعاملون مع تسجيل المدققين. هذا مهم بشكل خاص في بنية منظم التسلسل غير المحدود ، حيث تحتاج إلى تتبع من شارك ومن لم يشارك (على سبيل المثال ، طبقة المزامنة التي تمت مناقشتها سابقًا).
فيما يتعلق بأوقات الحظر (أي الكتل المقدمة من قبل المنشئين) ، فإنها تحدث عادةً حوالي 200 مللي ثانية. يبدأ تشغيلها في الغالب قبل / بعد حوالي 200 مللي ثانية ، على الرغم من وجود تباين كبير مثل GetHeader. إذا أرسل المنشئ الكتلة إلى مرحلات متعددة ، فسيؤدي ذلك إلى تأخير كبير. نظر Bloxroute أيضًا في ما يحدث عندما يتم إرسال الكتل إلى مرحلات متعددة. كما قد تتوقع ، فإن التأخير في انتشار الكتلة إلى المزيد من المرحلات سيكون أكبر. في المتوسط ، استغرق التتابع الثاني 99 مللي ثانية لإنفاق الكتلة ، والثالث 122 مللي ثانية ، والرابع 342 مللي ثانية.
ما تعلمناه على الأرجح خلال الأشهر القليلة الماضية هو أن RPC مهم جدًا لشبكات البلوكشين. إنه عبء كبير بدون البنية التحتية المناسبة ، كما أن وجود خيار RPC مناسب أمر بالغ الأهمية أيضًا. في هذه الحالة ، يعد RPC مهمًا لمستثمري التجزئة الذين يرسلون معاملاتهم إلى RPC (والمجمع المشترك العام). أجرت Bloxroute اختبارًا صغيرًا لـ 20 معاملة تم إرسالها إلى العديد من RPCs وقياس الوقت الذي تستغرقه كل معاملة ليتم تضمينها في كتلة.
المصدر: Bloxroute Labs *
ومن المثير للاهتمام ، أن بعض RPCs لا تتضمن المعاملات إلا بعد عدة كتل ، اعتمادًا على المنشئ الذي يفوز في الكتلة التالية. إذا أرسل RPC المعاملة إلى المزيد من المنشئين ، فإن احتمال التضمين السريع يكون أعلى. على الرغم من أنه من الممكن لمنشئي المعاملات الاستفادة من موقعهم الفريد من أجل التدفق لاستهداف بنائين محددين أو حتى بناء كتلهم الخاصة.
أداؤهم مثير للاهتمام أيضًا في إحصائيات أداء ترحيل Ethereum. يساعدنا هذا في اكتساب فهم أعمق لكيفية عمل PBS في عالم متعدد للتحقق / البناء / الترحيل ، وهو ما نأمل في تحقيقه من خلال ترقية Rollup. لدى Metrika بعض الإحصائيات الرائعة حول هذا الموضوع وجميع نقاط البيانات ترجع إليها.
من المهم ملاحظة أن العطاءات الفائتة تحدث عندما يُتوقع أن يقدم المُرحِّل المزايدة ، لكنه لا يقوم بالمزايدة. تأتي التوقعات المستهدفة من المدققين المسجلين في مرحل معين لأي فتحة معينة. هذا ليس خطأ ترحيل في حد ذاته ، ولا يتم التعامل معه بهذه الطريقة على مستوى البروتوكول.
المصدر: app.metrika.co *
إذا حدث خطأ (مثل مرحل يخدم كتلة غير صالحة) ، وكان مسؤولاً ، فسيتم اعتباره خطأ. عادة ما تكون هذه حالات نادرة وهي في الغالب حالات فشل تفضيل التسجيل (أي حدود الغاز أو الرسوم التي لا تتطابق مع التسجيلات الخاصة بمدقق معين). والأكثر ندرة هي حالات فشل طبقة الإجماع ، والتي لا تتوافق مع قواعد طبقة توافق Ethereum ، مثل الفتحات غير الصحيحة أو تجزئة الأصل غير المتوافقة مع الكتلة السابقة ، وما إلى ذلك.
فيما يتعلق بزمن الانتقال (مثل الوقت الذي يستغرقه المدقق لاستلام رأس كتلة تم إنشاؤه بواسطة منشئ) ، تكون البيانات متسقة للغاية. على الرغم من وجود بعض القيم المتطرفة ، مثل التتابع المطلوب في موقع جغرافي مختلف عن المدقق المختار.
المصدر: app.metrika.co *
فيما يتعلق بالبناة ، يبلغ إجمالي عدد البناة على MEV-boost حوالي 84 ، مع قيام الثلاثة الأوائل ببناء حوالي 65 ٪ من الكتل المبنية. على الرغم من أن هذا قد يكون مضللًا إلى حد ما لأن هؤلاء هم أيضًا البناة الأطول تشغيلًا. النتائج متشابهة إذا تم تقليل الإطار الزمني. عدد البناة النشطين الفعلي أقل بكثير ، 35 في الثلاثين يومًا الماضية و 24 في الأسبوع الماضي. المنافسة شرسة ، وعادة ما يفوز البناء الأقوى. قد يكون هناك بالفعل تدفق أوامر حصري ، والذي لن يؤدي إلا إلى تفاقم الوضع. نتوقع أن يظل توزيع المنشئين مركزيًا نسبيًا (نظرًا لأن هذا يعد سباقًا لتدفق النظام الأمثل وتحسين الأجهزة) ما لم نجري تغييرات كبيرة على الإعداد. على الرغم من أنها ليست مشكلة أساسية ، إلا أنها لا تزال قوة مركزية في المكدس ونود أن نسمع أفكارًا حول كيفية تحدي الوضع الراهن هنا. إذا كنت مهتمًا بالتعمق في هذه المشكلة (الخطيرة) ، فنحن نوصي بشدة بقراءة مقالات Quintus حول تدفق الطلبات والمزادات والمركزية.
بالنسبة لدور Builder في مكدس الوحدات النمطية في المستقبل ، نحن على يقين تام (على الأقل في إعداد Cosmos SDK) سنرى إعداد Skip / Mekatek-like Builder Modules. حل آخر هو إعداد نوع SUAVE ، مثل سلسلة بناء عالمية محددة تقدم خدمات بناء الكتل وتفضيل العطاءات لأي عدد من السلاسل لضمان دعم السلوك الإيجابي. سنستكشف هذا الحل بمزيد من التعمق لاحقًا ، ونقدم بعض الإجابات على الأسئلة التي لم يتم تناولها هنا.
فيما يتعلق بالمرحلات ، نوصي بشدة بقراءة مقال بقلم Ankit Chiplunkar من Frontier Research و Mike Neuder من مؤسسة Ethereum يسمى Optimistic Relays وأين يمكن العثور عليها. يوضح هذا المنشور بالتفصيل كيفية المرحلات في عمل MEV-boost ، والمفاضلات الحالية وتكاليف التشغيل ، وبعض التغييرات التي قد تزيد من الكفاءة. ومن المثير للاهتمام ، أن تشغيل مرحل في MEV-Boost يكلف حاليًا حوالي 100000 دولار سنويًا وفقًا لتقديرات Flashbot.
الحتمية
قبل أن نتحدث عن حتمية سلاسل الكتل المعيارية (كما تبدو حاليًا) ، دعنا نلقي نظرة على مقالتنا السابقة "معيارية MEV". لاحظ أن هذه ليست نظرة "رسمية" ولا شاملة للنهاية ، ولكننا نعتقد أنها تمثل بدقة أكبر الفروق الدقيقة في نهائية التراكمية لسهولة الفهم.
معلق \ _ تشغيل \ _L2: يمثل أمر التجميع التزامًا بسيطًا بأن معاملة المستخدم سيتم الالتزام بها وإنهائها في النهاية على الطبقة الأساسية لأمنها.
النهاية \ _On \ _L2: التزم منظم التسلسل بوظيفة انتقال الحالة في Rollup ، وتمت إضافة الكتلة إلى سلسلة Rollup الأساسية.
معلق \ _ تشغيل \ _L1: تم نشر وظيفة انتقال الإدخال أو الإخراج / الحالة للمعاملة إلى L1 ، ولكن لم يتم إصدار إثبات الصلاحية بعد ، أو لم تنته فترة التحكيم بعد - وهذا يتطلب Ethereum لعصرين متتاليين. هذه هي النقطة التي تقول عندها معظم التراكمية المتفائلة أنها وصلت إلى نهايتها ، ولكن لا تزال هناك فترة تحدي تعسفية مدتها 7 أيام في هذه المرحلة وفقًا لمواصفات جسر عبر السلسلة.
نهائية \ _ تشغيل \ _L1: بالنسبة إلى مجموعة التحديثات المتفائلة ، انتهت فترة التحكيم ، أو تم تأكيد إثبات صحة منشور ومحقق من قبل أغلبية ساحقة في فترتين متتاليتين.
الآن ، في تجميع الفرز المشترك السيادي ، يبدو هذا مختلفًا بعض الشيء ، دعنا نحاول شرحه برسم تخطيطي:
في هذه الحالة ، نظريًا يمكننا الحصول على الحتمية على L1 قبل L2 ، وما إلى ذلك؟ نعم ، في هذه الحالة ، تكون L2 ذات سيادة بعد كل شيء. هذا على افتراض عدم وجود أدلة على الاحتيال وفترات تحدي ، أو أنك تستخدم إثبات الصلاحية.
إذن كيف نحقق هذه المستويات من النهايات؟ يتم تحقيق نهائية الكتلة عند إضافة كتلة إلى السلسلة الأساسية ، والتي لا يمكن سحبها. ومع ذلك ، هناك بعض الفروق الدقيقة هنا ، اعتمادًا على العقد الكاملة أو الخفيفة. في حالة الكتلة المرتبة ، تكون حتمية بمجرد تضمينها في كتلة طبقة DA. يتم فرض الكتل (مع جذور الحالة) من خلال العقد / المدققات الكاملة Rollup ، والتي تمنحهم ضمان جذر حالة صالح مشتق من الكتل المرتبة للطبقة الأساسية. بالنسبة إلى الحتمية التي تتجاوز العقد الكاملة (مثل العملاء الخفيفين أو الجسور المتقاطعة) ، يجب أن تكون متأكدًا من صحة جذر هذه الحالة. هنا ، يمكنك استخدام إحدى الطرق الموضحة أدناه. أيضًا ، هناك طريقة أخرى تتمثل في جعل المدققين مسؤولين عن الإثبات الصحيح لجذر الدولة (الطريق المتفائل) ، من خلال سند وإثبات لاحق على الاحتيال. بالإضافة إلى ذلك ، يمكنك تقديم إثبات صحة (ZK).
طرق مختلفة لتحقيق الكتلة النهائية:
من خلال إثبات العمل (PoW) و LMD + Ghost و Goldfish و Ouroboros (PoS) وطرق احتمالية أخرى.
طريقة يمكن إثباتها عن طريق عدد كافٍ من أعضاء اللجنة للتوقيع. (مثل Tendermint 2/3 أو Hotshot2 أو أنواع PBFT الأخرى)
يعتمد على ترتيب المعاملات / الكتل على طبقة DA ، وقواعدها ، وهي قواعد اختيار السلسلة المتعارف عليها والشوكة.
يمكننا تحقيق أنواع مختلفة من النهايات من خلال آليات مختلفة.
أحد أنواع النهايات هو "النهاية الناعمة" (مثل المعلقة) ، والتي يمكن تحقيقها من خلال انتخاب زعيم واحد. في هذه الحالة ، سيكون لكل فتحة كتلة واحدة فقط أو كتلة صفرية (ملتزمة أم لا) ، ويمكن لطبقة التزامن أن تفترض بأمان تسلسل المعاملات في هذه الكتل.
نوع آخر من النهائية هو "نهائية يمكن إثباتها" ، والتي توفر ضمانات أقوى (نهائية بشكل أساسي) من النهاية الناعمة. لتحقيق نهائية يمكن إثباتها ، يجب على غالبية الأوامر التوقيع على الكتلة ، وبالتالي التعبير عن موافقتهم على أن الكتلة أساسية. في حين أن هذا النهج لطيف ، فقد لا يكون ضروريًا إذا تم تنفيذ انتخاب زعيم واحد ، لأنه يضمن بشكل أساسي أمر الكتلة. من الواضح أن هذا يعتمد على خوارزمية انتخاب الزعيم المعين التي يتم تنفيذها. على سبيل المثال ، هل هو تنفيذ بنسبة 51٪ ، أم تنفيذ بنسبة 66٪ ، أم قائد واحد (يفضل اختيار عشوائي (VRF) وسري). إذا كنت تريد معرفة المزيد عن الحتمية في Ethereum ، فاقرأ هذه المقالة التي نوصي بها بشدة ، والمقال الذي نوصي به لاحقًا لمجموعات الفرز غير المحدودة.
مرخصة أو شبه مرخصة أو غير مسموح بها
لمنع هجمات DoS المحتملة ، يجب وضع حواجز اقتصادية للانضمام إلى مجموعة الطلبات وإرسال المعاملات إلى طبقة الأمر. في المجموعات المحدودة (عدد محدود من أجهزة الفرز) وغير المحدودة (عدد غير محدود من أجهزة الفرز) ، يجب وضع حواجز اقتصادية لإرسال الدُفعات إلى طبقة DA لمنع طبقة المزامنة (نشر الكتل بين أجهزة الفرز) للحصول على بطء أو تحت هجوم DDoS . ومع ذلك ، توفر طبقة DA نفسها أيضًا بعض الحماية ، لأن إرسال البيانات إليها يتطلب تكلفة (da \ _fee). يجب أن يغطي مبلغ التأمين المطلوب للانضمام إلى المجموعة غير المحدودة أي تكاليف إضافية ضرورية لمنع طبقة المزامنة من البريد العشوائي. من ناحية أخرى ، سيعتمد الهامش المطلوب للانضمام إلى مجموعة محدودة على الطلب (متوازن من منظور التكلفة / الإيرادات).
بالنسبة لمجموعة غير محدودة من أدوات الفرز ، لا يمكننا تحقيق نهائية يمكن إثباتها في طبقة الفرز (نظرًا لأننا لا نعرف أبدًا عدد الناخبين / الموقعين النشطين). من ناحية أخرى ، في مجموعة محدودة من coorters ، يمكن تحقيق نهائية يمكن إثباتها من خلال غالبية كتل التوقيع coorters. يتطلب هذا أن تكون طبقة المزامنة على دراية بطبقة جهاز التسلسل وعدد أجهزة التسلسل النشطة في أي وقت معين ، وهو مقدار حمل إضافي. في مجموعة محدودة من الفرز (على سبيل المثال حتى 100) ، يمكنك أيضًا تحسين عدد الفرز لتحسين "الأداء" ، على الرغم من ذلك على حساب مقاومة اللامركزية والرقابة. إن أهمية المجموعات المحدودة والضمانات الاقتصادية لتوفير يقين "سريع" يمكن إثباته أمر حاسم أيضًا.
تنعكس أيضًا أنواع الفرز غير المحدود والفارز المحدود في سلاسل الكتل التقليدية. على سبيل المثال ، تعتمد PoS (Casper + LMD-GHOST) في Ethereum نوعًا غير محدود ، بينما تعتمد السلسلة المستندة إلى Cosmos SDK / Tendermint على النوع المقيد. هناك فكرة مثيرة للاهتمام وهي ، هل نتوقع رؤية اقتصاديات شبيهة بإثبات الحصة وخيارات من المجتمع حول أوامر الشراء المشتركة؟ في هذا الصدد ، رأينا تحركًا نحو مركزية بعض الكيانات (لذا لا يهم حقًا عدم التقييد إذا كان لديك بالفعل بعض موفري / مجموعات إثبات الحصة الكبيرة). على الرغم من أنهم "يخفون" المركزية ، إلا أنه لا يزال بإمكانك الألغام إذا أردت ذلك. من وجهة نظر أيديولوجية ، يجب أن تكون الخيارات دائمًا غير محدودة - لكن تذكر أن المبادئ الاقتصادية تجعلها متشابهة جدًا على أي حال. بغض النظر عمن هم المشاركون ، يجب أن تظل اقتصاديات ما تدفعه هي نفسها ، مثل تكلفة DA وتكلفة الأجهزة (على الرغم من أنه قد يتم تقليل ذلك من خلال عدد إثباتات الحصة التي تخصصها وتجربتها ، وتتسم بالكفاءة تشغيل البنية التحتية). حتى في عالم PoS المحدود ، رأينا مجموعة من مزودي البنية التحتية أصبحوا أكبر المدققين وأكثرهم شيوعًا في جميع السلاسل تقريبًا. في معظم سلاسل Cosmos ، تكون التبعيات بين المدققين كبيرة جدًا بالفعل ، وهذا بالتأكيد يشكل خطرًا على مقاومة اللامركزية والرقابة على السلاسل المذكورة. ومع ذلك ، هناك حقيقة مختلفة تمامًا وهي أن أي مستثمر تجزئة يمكنه المشاركة في أي مبلغ مع أي مدقق يختاره. لسوء الحظ ، يتم تعيين هذا عادةً في أعلى القائمة ، وتستمر الحياة. نسأل مرة أخرى: هل نتوقع نموذجًا اقتصاديًا مشابهًا في عالم معياري؟ يتمنى المرء أن لا يكون الأمر كذلك ، ولكن مع التخصص ، غالبًا ما تحتاج إلى أفضل ما يناسبك - وهم يميلون إلى أن يكونوا موفري إثبات حصص احترافي. سنقوم أيضًا بتغطية هذه القضايا الاقتصادية في فصل منفصل لاحقًا.
ومع ذلك ، فإن الشيء المهم الذي يجب تذكره في كل هذه الأمور هو أن أهم شيء هو مصادقة المستخدم النهائي ، وهو متاح لأي شخص ، بغض النظر عن مكان وجوده (حتى في الجيزة) من خلال العملاء الخفيفين وهرم DAS).
المصدر: @ JosephALChami *
فيما يلي المفاضلات والمزايا لأجهزة الفرز المحدودة وغير المحدودة:
مجموعة فارز غير محدودة:
يمكن لأي شخص لديه سندات / رهانات كافية أن يصبح فارزًا = درجة عالية من اللامركزية
ليس من الممكن أن يكون هناك رئيس انتخابي واحد ، لأن عامل الفرز هو في الأساس لانهائي.
يمكن انتخاب زعيم غير فردي عبر VRF ، ولكن من الصعب تحديد معلمات VRF لأنه من غير المعروف عدد الطلبات التي سيكون هناك. يجب أن تكون هذه أيضًا انتخابات زعيم سرية إذا أمكن لتجنب هجمات وزارة الخارجية.
لا يوجد انتخاب زعيم = مشكلة إهدار للموارد: بناء الكتلة هو في الأساس منافسة حرة ، كل من يقدم أول كتلة / دفعة صالحة يفوز ، ويخسر الجميع. · · لا يوجد يقين يمكن إثباته على مستوى الطلب ، فقط احتمالي: على سبيل المثال LMD Ghost + Casper
لا يتم تحقيق النهاية النهائية إلا بعد كتابة الدُفعات في طبقة DA (محدودة فقط بوقت الكتلة الأساسي ، 15 ثانية في حالة Celestia).
تعتبر المجموعات غير المحدودة مقاومة للرقابة "أفضل" من المجموعات المقيدة.
مجموعة محدودة من فارزات:
هذا هو أحد حلول Ethereum للحتمية ذات الفتحة الواحدة ، ولديك لجنة "أغلبية" عظمى.
هناك حد لعدد أجهزة التسلسل المسموح بها في أي وقت.
المجموعات المحدودة أكثر تعقيدًا من المجموعات غير المحدودة.
يمكن تنفيذ انتخاب قائد واحد ، مما يوفر ضمانًا حتميًا قويًا لطبقة الفرز.
تحتاج طبقة المزامنة إلى فهم مجموعة الطلبات لتحديد الكتل الصالحة.
كتابة مجموعات فارز (أو ضبط التغييرات) على كتل طبقة التسوية (مثل قواعد اختيار الشوكة) ، والتي تتم كتابتها في طبقة DA ، تسمح لطبقة المزامنة بتحديد مجموعة الفرز بشكل مستقل. على سبيل المثال ، هذا ما يفعله Sovereign Labs 'Rollup ، تتم كتابة تغييرات المجموعة في إثبات صحة منشور على طبقة DA.
قد لا تكون الضمانات النهائية القوية لطبقة الأمر ضرورية إذا كانت طبقة DA سريعة بدرجة كافية (ومع ذلك ، فإن معظم إعدادات طبقة التسوية الحالية غير المحسّنة لها ما لا يقل عن 10 ثوانٍ من أوقات الكتلة).
توجد غرفة تصميم كبيرة لكيفية مراقبة مجموعات الفرز هذه وإضافة أعضاء جدد أو إزالتهم. على سبيل المثال ، هل سيتم تحقيق ذلك من خلال Tokenholder Governance (ماذا عن العديد من الرموز والتجميعات المختلفة التي تستخدم المجموعات بعد ذلك؟). هذا يعني أن تغيير الإشارات خارج السلسلة قد يكون ممكنًا من خلال الإجماع الاجتماعي (على سبيل المثال ، خذ Ethereum كمثال). ومع ذلك ، تذكر أن الإجماع الفعلي على السلسلة محدد بوضوح ، والعقوبات على انتهاك قواعد الإجماع موجودة بالفعل.
الآلية الاقتصادية للفرز المشترك
تسمح اقتصاديات مشاركة شبكة من أجهزة التسلسل ببعض الخيارات المثيرة للاهتمام. كما ناقشنا سابقًا ، لا تختلف المدققات في شبكة أوامر مشتركة كثيرًا عن مدققي L1 النموذجيين. الشبكة التي تشارك فيها هي ببساطة أكثر تحسينًا لأداء مهمة واحدة ، وهي تلقي النوايا (المعروفة سابقًا باسم PBS) ، وبالتالي اقتراح المعاملات وطلبها. تمامًا مثل المدققين "العاديين" ، هناك مكونات للإيرادات والتكلفة. على جانبي المعادلة ، هناك قدر كبير من المرونة في الشبكات التي يشارك فيها المدققون ، على غرار L1 العادي.
تأتي الإيرادات من المستخدمين أو المجموعات التي يرغبون في النهاية في التفاعل مع دفع رسوم معينة لاستخدام جهاز التسلسل المشترك. يمكن أن تكون هذه الرسوم عبارة عن نسبة مئوية من MEV المسحوب (قد يكون إدخال الأرقام صعب التقريب) ، أو تحويلات القيمة عبر السلاسل ، أو الغاز ، أو رسم ثابت لكل تفاعل. قد يكون الحل الأنسب للإيرادات هو دفع قيمة أقل لأمر الشراء المشترك من القيمة الإضافية المكتسبة من خلال الأمر المشترك التراكمي ، إلى جانب مزايا الأمان والسيولة المشتركة. لكن الجانب السلبي لهذا هو أنه من الصعب تحديد فوائد اللامركزية لجزء آخر من المكدس. ومع ذلك ، مع نمو شبكة الطلبات المشتركة في نظامها الإيكولوجي الخاص ، قد تزداد قدرتها على استخراج الرسوم. ويرجع ذلك في جزء كبير منه إلى قدرتها المتأصلة على التجميع بسهولة ، مع وفورات حجم معينة. مع انضمام المزيد من المجموعات والتطبيقات إلى الشبكة ، سيتمكن المزيد والمزيد من MEVs عبر المجالات من استخراجها.
من حيث التكلفة ، تمتلك شبكات الطلب المشتركة أيضًا خيارات منافسة. يمكنهم بسهولة تمويل استخدام الشبكة الخاصة بهم عن طريق تمويل تكلفة النشر على طبقة DA ، أو حتى تكلفة التفاعل مع التطبيقات على Rollup. هذا مشابه للاستراتيجية التي تستخدمها شركات Web 2.0 ، حيث تتحمل الخسارة الأولية في اكتساب المستخدمين (أو التراكم) ، على أمل أن تفوق إيراداتهم طويلة الأجل الرسوم. هناك طريقة أخرى أكثر حداثة أو طريقة Crypto-original وهي السماح لـ Rollup بدفع رسوم DA باستخدام رمزها الأصلي. هنا ، تتحمل طبقة الفرز المشترك مخاطر التسعير بين الرمز المطلوب لنشر البيانات على طبقة DA والرمز الأصلي الأصلي لـ Rollup. في جوهرها ، لا تزال التكلفة الأولية للفرز المشترك ، ولكنها تخلق تناسقًا في النظام البيئي من خلال الحصول على رمز "المورد" (أي التجميع). هذا يشبه إلى حد ما بناء المستودع الذي شرحناه في ورقة AppChain ، ويمكن استخدام أشكال مختلفة من DA لتقليل التكاليف. ستقدم مستويات DA المختلفة أسعارًا مختلفة بسبب الاستخدام ، وقدرة المستخدمين على التحقق بسهولة من خلال عميل خفيف ، أو ببساطة اتخاذ خيارات مختلفة لحجم الكتلة. أخيرًا ، يمكن لأمر الطلب المشترك أيضًا دفعة المعاملات قبل النشر إلى طبقة DA. في حالة ZKR ، يمكن أن يؤدي ذلك إلى تقليل تكاليف المعاملات من خلال عدد معين من أرصدة المعاملات ، وفيما يتعلق بـ ORU ، يمكنك إجراء تحسينات مختلفة في معالجة الغاز على دفعات ، والتي يمكننا رؤيتها حاليًا في مختلف التراكميات. سيؤدي ذلك إلى تقليل كمية البيانات التي يجب نشرها على طبقة DA ، وبالتالي تقليل تكلفة شبكة جهاز التسلسل المشترك وزيادة ربحية الشبكة بأكملها. سيأتي هذا على حساب الحد من قابلية التشغيل البيني وتغيير أوقات نهائية الكتلة (الحتمية على L1 كما ذكرنا سابقًا).
بشكل عام ، تسمح اقتصاديات مشاركة شبكة من أجهزة التسلسل ببعض استراتيجيات التجريب والتمهيد المثيرة للاهتمام. نحن نقدر أن الاختلاف الرئيسي سيكون حجم النظام البيئي ، وبالتالي فإن عدد MEVs عبر المجالات أكبر من جانب التكلفة. نوصي بشدة أيضًا بمراجعة منشور مدونة فريق Espresso حول الطلبات المشتركة ، فهي تغطي أيضًا المقايضات الاقتصادية (والإيجابيات) لهذه الأنواع من الشبكات. لإظهار سبب تحفيز Rollup للاستفادة من أدوات الفرز المشتركة (إلى جانب الاقتصاد) ، يمكننا اعتبارها من منظور نظرية التجميع.
نظرية التجميع والفرز المشترك
هناك طريقة أخرى لوصف الخصائص التي أحدثتها أجهزة الفرز المشتركة وهي من خلال عدسة نظرية التجميع. تشير نظرية التجميع إلى مفهوم كيفية دمج النظام الأساسي أو المجمع بين الأنظمة الأساسية الأخرى ومستخدميها بطريقة منهجية لجذب انتباه المستخدم بشكل كبير. أنت تنقل اللعبة بشكل أساسي من تخصيص مورد نادر (على سبيل المثال ، مساحة الكتلة) إلى الحاجة إلى التحكم في مورد وفير (مرة أخرى ، مساحة الكتلة منطقية في هذا المثال). تقوم نظرية التجميع في الواقع بتجميع الموردين والمنتجات (مثل Rollup و Blockspace) في تجربة مستخدم فائقة لخدمة قاعدة المستخدمين المجمعة. مع نمو تأثير الشبكة لهذه المجمعات ، تصبح هذه العلاقة حصرية بشكل متزايد. عند حدوث ذلك ، تصبح تجربة المستخدم هي العامل الأساسي الذي يميز بين الإعدادات المتشابهة. إذا كانت هناك حوافز لجذب مستخدمين جدد (مثل تجربة مستخدم جيدة وإمكانية تشغيل تفاعلي أفضل) ، فمن غير المرجح أن ينتقل التراكمي إلى شبكته الخاصة أو إعداد مختلف - حيث تؤدي تأثيرات الشبكة إلى جذب موردين جدد وانضمام مستخدمين جدد. هذا يخلق تأثير دولاب الموازنة ، ليس فقط من منظور المزود والمستخدم ، ولكن أيضًا من منظور مجمع مقاوم للرقابة.
المصدر: Aggregation Theory 2015 ، Ben Thompson *
في عالم الفرز المشترك ، يمكن النظر إلى نظرية التجميع على أنها "مجموعات" واتحادات من مختلف Rollups ، وكلها تستخدم أعمدة متشابهة من المكدس - وتمكين أنفسهم والآخرين مع السماح للمستخدمين بالحصول على نفس التجربة.
الموفرون (مثل Rollups) ليسوا حصريين من الناحية النظرية لمجموعة coorter المشتركة ، ولكن من الناحية العملية ، مجموعة coorter المشتركة ، ومجموعاتها ، ويستفيد المستخدمون من سلسلة من حلقات تأثيرات الشبكة التي تؤدي إلى زيادة استخدام هذه المجموعات. تسهل هذه الفوائد على التراكميات والمستخدمين الاندماج في مكدس مشترك لأن لديهم الكثير ليخسروه إذا لم يشاركوا. في حين أنه من الصعب رؤية هذه الفوائد عندما يكون لديك فقط مجموعتان من Rollups تتشاركان في مجموعة مُسلسِل واحدة ، فإنها تصبح أكثر وضوحًا عندما تضيف المزيد والمزيد من Rollups والمستخدمين في المعادلة. مجموعات الفرز المشتركة لها علاقة مباشرة بالمستخدمين ، حيث يطلبون معاملاتهم ، حتى إذا كان المستخدمون أنفسهم لا يعرفون أنهم يتفاعلون معهم ، نظرًا لأنهم من وجهة نظرهم ، يستخدمون فقط المجموعات التي لديهم سبب للتفاعل معها ( هذا يعني أن الطلب / الفرز أصبح حصريًا). التكلفة الوحيدة لهذه الفرز هي تكلفة الأجهزة لتشغيلها ، طالما أن مساحة الكتلة والرموز المميزة التي تؤمنها ذات قيمة للمستخدم النهائي. يتم رقمنة رسوم المعاملات ، ويتم دفعها من محافظ المستخدمين ، وربما في المستقبل ، يمكن حتى استخلاصها من خلال التطورات مثل مضيفي الدفع في تجريد الحساب (ومع ذلك ، سيتعين على شخص ما تحمل تكلفة DA والطلب والتنفيذ).
يكون هذا أكثر منطقية عند التفكير في شركة Josh و Jordan السابقة في Astria - Google. منذ نشأتها ، كانت منتجات Google مستوحاة من فكرة AT ، لا سيما في بحث Google ، الذي تم إنشاؤه عن طريق تعديل الصفحات والمقالات الفردية ، مما يجعل الوصول إليها مباشرة من خلال نافذة البحث العالمية.
في حالة وجود مجموعة مشتركة من الفرز ، فإن المستخدمين الذين يستخدمون Rollups (أولئك الذين يشتركون في مجموعة من الفرز) لديهم تكاليف اكتساب أقل وأقل ، لأنه مع زيادة عدد الموردين (Rollup) ، فمن المحتمل أن ينجذبوا إلى المجموعة . هذا يعني أنه ، في معظم الحالات ، يكون للمُجمِّع (أو المُجمِّع المتعدد) تأثير مربح للجانبين ، حيث تزداد قيمة المُجمِّع مع زيادة عدد الموردين (طالما أن تجربة المستخدم جيدة بالطبع). في المقابل ، في شبكة تسلسلية واحدة ، يقتصر اكتساب العملاء على شبكة واحدة وتطبيقاتها. إذا أراد المستخدمون استخدام تطبيق Rollup على مجموعة بيانات مختلفة ، فسيتعين عليهم (ضمن القيود الحالية) تسجيل الخروج من الشبكة تمامًا. هذا يعني أن درجة لزوجة المستخدم وقيمته ليست عالية جدًا ، وهذا يعني أيضًا أنه في أي لحظة ، إذا كان هناك نظام بيئي آخر للعرض التراكمي ذو قيمة عالية (أو لديه المزيد من الحوافز) ، فقد يتم فقد رأس المال.
السمات وملخص المفاضلات
صفات
مجموعة الفرز المشتركة عبارة عن شبكة تراكمية تقوم بتجميع المعاملات وفرزها لمجموعات متعددة. هذه التراكمية تشترك في نفس فارز. يعني تجميع الموارد هذا أن التراكميات تكتسب أمانًا اقتصاديًا أقوى وقدرات مكافحة الرقابة ، والتي يمكن أن توفر ضمانات حتمية ناعمة سريعة ومعاملات عبر التراكمية المشروطة.
في الوقت الحالي ، هناك الكثير من الضوضاء حول الذرية بين Rollups التي تشترك في نفس مجموعة الفرز ، في الغالب حول ما إذا كانت ذرية بشكل افتراضي - وهي ليست كذلك. ومع ذلك ، إذا نفذت Rollups المعنية وظائف انتقال الحالة (STFs) لبعضها البعض باعتبارها تبعيات فيما بينها ، بما في ذلك المعاملات الشرطية ، فيمكنها بالفعل تحقيق الذرية بينهما - طالما كانت محاذاة الفتحة / blocktime (كما هو الحال مع مجموعات الفرز المشتركة). في هذه الحالة ، للحصول على إمكانية التشغيل البيني الذري ، ما عليك سوى تشغيل عميل خفيف من السلسلة B على السلسلة A والعكس صحيح (على غرار طريقة عمل IBC). لتعزيز قابلية التشغيل البيني للتدابير الأمنية (بخلاف الوثوق في عقدة كاملة واحدة كعقدة خفيفة) ، يمكنك تنفيذ ZKP (إثبات الحالة) لحل "مشكلة أوراكل" لضمان صحة الحالة. سيجعل هذا الأمر أكثر وضوحًا لمعرفة ما إذا كانت معاملة مشروطة أو شيء من هذا القبيل قد أصاب جسرًا متقاطعًا متقاطعًا بينهما. أدلة الاحتيال هي أيضًا احتمال ، ولكن من الواضح أنها ستترك فترة تحدي (مما يعني أن طرفًا ثالثًا سيأتي لتغطية تكلفة هذا الخطر). أيضًا ، في حالة العملاء الخفيفين (بدلاً من العقد الكاملة) ، سيكون هناك كتلة واحدة على الأقل متأخرة بسبب انتظار رأس التوقيع + نافذة إثبات الاحتيال (إن وجدت).
نعتقد أن مشكلة "الجسر عبر السلسلة" من المرجح أن يتم حلها مع عملاء خفيفي الوزن وبراهين صفرية المعرفة. التحدي في استخدام عميل خفيف الوزن (بدلاً من عقد ذكي) في هذه الحالة هو أن الهارد فورك (ترقيات ، وما إلى ذلك) على جانب عقدة التراكمية تحتاج إلى التنسيق مع بعضها البعض للحفاظ على عمل الجسر (تمامًا كما تحتاج IBC إلى التمكين وحدة الحالة نفسها). إذا كنت تريد الغوص بشكل أعمق في هذا الموضوع المحدد (وكيفية معالجته) ، فنحن نوصي بشدة بمراجعة هذا العرض التقديمي.
السبب في أن المقياس المشترك لمنظمي الطلبات جيدًا هو أنهم لا ينفذون ويخزنون أي حالة (كما يفعل النظام المركزي اليوم). الأمر نفسه ينطبق على عُقد التراكمية نفسها (ما لم تكن تريد الذرية فيما بينها - على سبيل المثال العميل الخفيف / إثبات الحالة). لا تنفذ هذه العقد سوى المعاملات الصالحة لمجموعتها ، وأي معاملات شرطية عبر المجال صالحة لها. إذا كان يتعين على عقدة Rollup تنفيذ وتخزين الحالة للعديد من Rollups ، فهذا يعيق قابلية التوسع ويقلل من اللامركزية (وبالتالي مقاومة الرقابة). ويعزز هذا أيضًا مفهوم فصل المنتج عن البناء (PBS). على الرغم من أننا ما زلنا بحاجة إلى فصل البناة والمنتجين تمامًا. في الإعداد الحالي ، يعتبر مقدمو الطلبات في الأساس منشئين ومنتجين للكتل (على الرغم من أنهم لا ينفذون المعاملات). قد يكون الإعداد المثالي هو المكان الذي يوجد فيه المسؤول فقط للتوقيع بشكل أعمى على الكتل من إعداد المنشئ المحسن للغاية والتأكد من تنفيذ الكتل بشكل صحيح (مع توفير درجة عالية من اليقين الاقتصادي ومقاومة الرقابة لتلك الشهادة). وبهذه الطريقة ، يمكنهم توفير درجة عالية من الأمان والالتزام بضمان نهائية ناعمة لعقد التراكمية.
بالنسبة للمعاملات الشرطية عبر التجميع ، فهي موجودة أيضًا للمساعدة في تمكين عقد التجميع (المنفذون) لتوفير جذور الحالة الوسيطة ، مما يتيح القدرة الذرية بين عمليات التجميع.
التنازل عن ميزة ممن أجل الحصول على أخرى
تحتوي معلمة المهلة المذكورة أعلاه على بعض التأثيرات المثيرة للاهتمام على MEV وإدراج المعاملات ، اعتمادًا على آلية Masternode / الإجماع لمجموعة الطلب. على سبيل المثال ، إذا تم وصف معلمة المهلة بأنها قصيرة نسبيًا في ورقة السلسلة الخاصة بالتطبيق ، فمن الأهمية بمكان أن يقوم منتجو الكتل لمجموعة لامركزية من الطلبات بنشر البيانات بأسرع ما يمكن. في مثل هذا العالم ، يمكنك أن ترى المنافسة بين "المدققين" الذين يتنافسون ليكونوا عُقدًا رئيسية ويقدمون عطاءات على طبقة DA لمساحة الكتلة حتى تصبح غير مربحة.
كما غطى إيفان في منشور الطلب الكسول الأصلي الخاص به على منتديات Celestia ، فإن انتظار نشر المعاملات إلى الطبقة الأساسية (Celestia في هذه الحالة) قبل تنفيذها أمر غير فعال للغاية. منذ الآن ، أصبحت مقيدًا بوقت حظر الطبقة الأساسية - وهو وقت طويل جدًا لانتظار تجربة المستخدم. للحصول على تجربة مستخدم أفضل ، يوفر مُنشئ الطلب المشترك Rollups التزامات حتمية ناعمة (كما هو موضح سابقًا) ، والتي توفر للمستخدمين تجربة المستخدم التي اعتادوا عليها في القوائم المركزية الحالية (مع الحفاظ على اللامركزية ومقاومة عالية للرقابة). الالتزامات الميسرة هي في الأساس مجرد التزامات بالترتيب النهائي للمعاملات ، ولكنها مدعومة بضمانات اقتصادية كبيرة وإنهاء سريع بمجرد إصدارها. يتم تغطية هذا أيضًا من خلال إثباتات الاحتيال (كما هو مذكور في المقدمة). يتم تحقيق النهاية الصعبة الفعلية بعد نشر جميع بيانات المعاملة إلى الطبقة الأساسية (مما يعني أن L1 تحقق بالفعل نهائية أسرع). يعتمد ذلك على ما إذا كان التراكمي يستخدم أدلة الاحتيال أو البراهين الصفرية للتحقق من إثبات السيادة - والذي يحدث في Rollup. سبب الرغبة في هذا الفصل هو إزالة عنق الزجاجة الضخم لتحولات الحالة من جهاز الفرز. بدلاً من ذلك ، تتعامل العقد التراكمية فقط مع العقد الصالحة لها (بمعنى أنه يتعين علينا إضافة معاملات شرطية أو إثبات الحالة أو التحقق من صحة العقدة الخفيفة من أجل التشغيل البيني المناسب). لا تزال الحتمية الصارمة تعتمد على الطبقة الأساسية (ولكن يمكن أن يصل هذا إلى 15 ثانية في Celestia ، وهو أيضًا حتمي في ظل Tendermint) ، مما يمنحنا ضمانات حتمية سريعة نسبيًا على Rollup.
استخدم براهين المعرفة الصفرية داخل الشبكة لتحسين التحقق من الصحة وحجم المعاملة (على سبيل المثال فقط نشر اختلافات الحالة - ولكن هذا يضيف مستوى أعلى من الثقة حتى يتم نشر ZKP). كما ذكرنا سابقًا ، يمكن استخدام إثباتات الحالة هذه للسماح للسلاسل / التجميعات المتصلة بالتشغيل البيني بشكل أسهل وأسرع (دون انتظار نوافذ التحدي).
يتمثل الجانب السلبي لهذه المعاملات الشرطية في أنها من المحتمل أن تكون أكثر تكلفة ، مما يتطلب تكاليف أعلى للتحقق والإصدار (مثل تكلفة التحقق من رأس كتلة Tendermint ، المدعوم في سلسلة Cosmos) ، وإضافة بعض زمن الانتقال إلى النظام ( ولكن لا يزال أسرع من التراكمية المعزولة أسرع بكثير). يمكن للذرية التي تم تحقيقها من خلال التكامل المشترك عموديًا أن تعوض هذه المشاكل.
أثناء مرحلة التمهيد لمجموعة التحديثات الجديدة ، يكون استخدام مجموعة مشتركة من أدوات التوليف منطقيًا إلى حد كبير ، ومن المحتمل أن تفوق المزايا التي تكتسبها كمزود بعض المقايضات التي قد تضطر إلى إجرائها على مستوى الخندق. ومع ذلك ، بالنسبة لمجموعة التحديثات الناضجة بالفعل ، حيث يوجد الكثير من المعاملات والنشاط الاقتصادي ، فربما لا يكون من المنطقي التخلي عن جزء من الخندق المائي.
هذا يطرح السؤال عما إذا كنا بحاجة إلى ترجيح اقتصادي / معاملات (لكل مجموعة) لإعادة توزيع MEV المستخرج للحث على التراكميات الناضجة بالفعل للانضمام إلى المجموعة المشتركة - أو حتى منع التراكميات الناضجة للغاية من إنشاء شبكة خاصة. كل هذا نظري إلى حد ما ، لكنه بلا شك عملية تفكير مثيرة للاهتمام فيما يتعلق بكيفية تقديم MEV في عالم رأسي مشترك بين العديد من Rollups بمستويات مختلفة من النشاط. على سبيل المثال ، إذا كان هناك تراكم فريد يدفع القيمة يشترك في بعض هذه الأرباح مع الآخرين (ربما لا يجلب الكثير من "القيمة") عبر مجموعة منظم التسلسل ، فيجب أن يكون هناك المزيد من الأسباب التي تجعلهم ينتقلون إلى نظامهم المنعزل. لدى Sreeram بواسطة EigenLayr بعض الأفكار حول هذا أيضًا ، والتي نوصي بقراءتها أيضًا.
يصبح هذا الأمر مهمًا بشكل متزايد عند التفكير في وجود تكلفة تقنية كبيرة للباحثين لتطوير سلاسل جديدة ، لذا قد يكون توحيد المعايير وتوفير بعض السيادة على MEVs "الخاصة بهم" مكانًا جيدًا للبدء. من الناحية العملية ، في MEV ، قد تفوز الواجهة (أو البرنامج) المهيمن ، ولكن في الواقع ، تحقيق الدخل من هذا البرنامج عن طريق تشغيل أجزاء مهمة من البنية التحتية أمر صعب للغاية (مما يؤدي إلى المركزية). على مستوى السوق ، ما يقدمه الطلب المشترك هو في الأساس مجموعة ذاكرة مشتركة للعديد من المزودين ، مع مزاد مركزي ، مما قد يؤدي إلى منافسة أكثر صحة.
يتمثل أحد الشواغل هنا في أنه إذا كان هناك اثنان من Rollups يعملان على فرز في المجموعة المشتركة ، فيمكن اختيار مجموعة تراكمية بقيمة "أقل اقتصادية" (A) لاقتراح مجموعة ذات مقدار كبير من MEV + رسوم من Rollup (B). . من وجهة نظر Rollup B ، فإنهم يفقدون بشكل أساسي بعض القيمة التي سيحتفظون بها لأنفسهم في النهج المعزول.
معالجة مقايضات التشغيل البيني
ملاحظة أخرى حول المقايضات التي تقدمها قابلية التشغيل البيني ، ويتبع طريقة أخرى لحل بعض المشاكل:
الغرض من شبكة الطلب المشتركة هو توفير ضمان أساسي لسلاسل متعددة ، والتي من الواضح أنها ميزة كبيرة في هذه الحالة. يمكن دمج هذا مع آلية لضمان انتقالات فعالة للحالة بين التراكميات. قد يكون هذا نهجًا قائمًا على اللجان (مثل PoS) ، أو أدلة مضمونة (النهج المتفائل) ، أو الأسلوب المفضل لدينا - ZKP مدعومًا بتوقيعات اللجنة. نظرًا لأن أدوات الفرز المشتركة "كسولة" ، فإنها تقوم فقط بإنشاء كتل فائقة لفرز معاملات مجموعات متعددة ، ويترك تنفيذ المعاملة المحددة لمجموعة محددة. تُعد إثباتات الحالة (مثل لاغرانج ، أو أكسيوم ، أو هيرودوت ، إلخ) حلولًا ممكنة للحصول على أدلة نهائية عبر التدفقات السيادية. يمكنك أيضًا إضافة أدلة على الجودة المضمونة اقتصاديًا من خلال أشياء مثل تجمعات Staking ، و EigenLayr ، وما إلى ذلك. الفكرة الأساسية هي أن فارز مشترك يوفر ضمانًا اقتصاديًا للطلب ، وإثباتات الصلاحية الناتجة عن هذا الفرز حتمية. الفكرة الأساسية هي أن Rollups يمكنها تنفيذ المعاملات بشكل متزامن مع بعضها البعض. على سبيل المثال ، يمكن لشبكة مكونة من عقدتين تراكميتين أن تعرف بشكل مشروط أن كلا من سجلات التجميع صالحة ، عبر ZKP والبيانات المتاحة (البيانات المنشورة على طبقة DA فعالة). من خلال نشر بادئة مجموعة تجميعية واحدة من كلتا الشبكتين A و B ، يمكن لعقدة Rollup تسوية مجموعتين من Rollup في وقت واحد. هناك شيء واحد يجب الإشارة إليه وهو أن المعاملات الشرطية عبر التجميع تستهلك موارد من نظامين منفصلين من خلال التنفيذ المشترك ، لذلك من المحتمل أن تكون المعاملات الشاملة (أو المتزامنة) أكثر تكلفة من المعاملات الداخلية الفردية.
كما غطت Succinct أيضًا المعاملات "الذرية" عبر السلسلة بين Rollups مع أوامر الشراء المشتركة (ومثبتات الاحتيال المشتركة) داخل نظام Optimism hyperchain ، والتي يمكن عرضها هنا. أيضًا ، كما يقول بو دو بوليمر: "المعاملات الذرية عبر السلسلة تشبه الحصول على أقفال بين أجزاء قاعدة البيانات عند الكتابة".
مستقبل التكامل الرأسي
لقد تم بالفعل استكشاف الأعمال الداخلية المحتملة لسلاسل SUAVE بعمق بواسطة Jon Charbonneau et al ، لذلك لن نخوض في الكثير من التفاصيل. إذا كنت تريد وصفًا أكثر تفصيلاً ، يمكنك التحقق من مقالته. ومع ذلك ، نعتقد أن التكامل الرأسي يستحق مقدمة منفصلة ، لإبراز كيف يمكن أن نكون نمطيًا (ولماذا) ولتقديم بعض المشكلات والمخاوف المرتبطة بالتكامل الرأسي.
في حين أن مخطط الطلب المشترك الحالي لـ Astria و Espresso و Radius معياري للغاية ، لا يزال القائمون على الطلبات يعملون كمنشئين ومنتجي كتلة (على الرغم من أنهم في حالة Astria ، لا ينفذون المعاملات). تعمل Astria أيضًا على بناء PBS بنشاط في هندستها المعمارية منذ البداية.
إذا لم يتم تضمين دعم السلوك الإيجابي في البروتوكول ، فهناك عدة طرق لتنفيذ دعم السلوك الإيجابي (وإن كان ذلك بدرجات متفاوتة من اللامركزية). منتجات مثل SUAVE ، استخدم نماذج غير متصلة بالإنترنت مثل MEV-Boost ، أو نفذ وحدات منشئ مثل وحدات Cosmos SDK التي صممها Mekatek و Skip.
من الجدير بالذكر أن أيا من هذه الأساليب لا يستبعد بعضها البعض. لديك المرونة في استخدام عدة طرق مختلفة والسماح لأي شخص بالتعبير عن تفضيلاته. بهذه الطريقة ، يمكن أن يكون لديك منفذون يتنافسون لملء تلك الوظائف الشاغرة. تعد إضافة المزيد من الخيارات دائمًا أمرًا جيدًا (ومتوافقًا مع إيماننا بالنمطية). ومع ذلك ، سيكون للتطبيقات المختلفة مقايضات مختلفة. على سبيل المثال ، في حالة مثل SUAVE ، يمكنك إضافة حماية الخصوصية من خلال تقنية SGX أو Crypto ، وإضافة أمان اقتصادي Crypto إلى الحقيقة ، بدلاً من الاعتماد على مُنشئ PBS مركزي موثوق به تمامًا. (شكرًا لجون شاربونو على ملاحظاته هنا).
يضمن التكامل الرأسي في سلسلة المنشئ الإنصاف دون اتخاذ اختصارات ، وإضافة زمن الوصول وتقليل الأداء. لذلك ، يجب تحسين سلسلة البناء بشكل كبير وقد تتطلب أجهزة باهظة الثمن وقوية (مما يؤدي إلى المركزية). هذا يعني أنه للحصول على التحقق من صحة المستخدم النهائي ، ربما نحتاج إلى نوع من العقد الخفيفة (على الرغم من أنه يتعين عليهم الوثوق بالعقد الكاملة) ، أو استخدام دليل على إعداد نوع الحالة لضمان حصول السلسلة والمستخدمين على دليل على تفضيلات عروض الأسعار مملوءة والكتل صحيحة البناء.
قد تكون سلسلة مثل هذه ثقيلة للغاية (نريد تجنب ذلك) ، على الرغم من أن هذه المعاملات الثقيلة للولاية ستعطى الأولوية عبر العقود الذكية. في حالة العطاء ذي الأولوية ، إما أن يتم ملؤه أو لا يتم ملؤه (لفترة قصيرة من الوقت) ، نظرًا لأن العطاءات عادة ما تكون صالحة فقط لفترة قصيرة من الوقت ، اعتمادًا على التفضيل. وهذا يعني أننا قد نكون قادرين على تنفيذ حالة فعالة للغاية (ومبكرة) لانتهاء صلاحية العطاءات - مما سيتيح لنا تقليم البيانات والحفاظ على السلسلة "نظيفة". يجب أن يكون تاريخ انتهاء الصلاحية طويلًا بما يكفي للسماح بملء العطاءات أولاً ، ولكن خفضه كثيرًا سيجعل من المستحيل تقريبًا تحقيق العقود الآجلة لـ blockspace. لا نحتاج إلى تحديث واسترداد عقود العطاءات منتهية الصلاحية حيث لا يلزم وجودها إلى الأبد (على عكس التطبيقات) - يمكن القيام بذلك إما عن طريق توفير أدلة الحالة / التخزين عند ملء العطاءات أو عن طريق حلول تخزين DAS (مثل المقترحة بواسطة حل Joachim Neu) لجعله أكثر "أمانًا" وجديرًا بالثقة.
كما ذكرنا سابقًا ، قد تقتصر الحاجة إلى التحقق من "أصالة" SUAVE على "jusha" (المستخدمين المتقدمين) للنظام الأساسي ، لأن معظم مستخدمي وعملاء SUAVE يمكنهم الحصول على فوائد اقتصادية عالية منه. قد يدفعنا هذا إلى السماح للأشخاص بتشغيل عقد كاملة فقط إذا كانوا يريدون التحقق من صحتها - على الرغم من أن هذا يستثني الغالبية العظمى من الأشخاص (يمكنك القول إنهم لا يحتاجون إلى التحقق من الصحة). هذا (في رأينا) عكس Crypto ، حيث نفضل تنفيذ تحقق SUAVE "غير موثوق به" من خلال إثباتات الحالة أو تطبيقات سهلة الاستخدام للعميل.
سبب الحاجة إلى ذلك هو أنك تريد التحقق من ملء أولوية عرض التسعير الخاص بك بشكل صحيح وأن الكتلة قد تم ملؤها بالمعلومات الصحيحة عند الدفع (لتجنب إعادة التجميع والأخطاء الأخرى). هذه مشكلة أوراكل أساسًا - في الواقع يمكن حلها بإثبات الحالة (كما هو الحال مع جميع المركبات SUAVEs). ومع ذلك ، فإن أدلة الحالة هذه تثير مشكلة أخرى عند عبور السلاسل ، كيف تنقل هذه المعلومات عبر السلاسل بطريقة لم يتم العبث بها أو إخفاؤها؟ قد يتطلب هذا المرور بنهاية اقتصادية قوية (مثل تلك التي اقترحها لاغرانج) ، وفي هذه الحالة يمكنك استخدام مدققي إعادة ضبط EigenLayr لإثبات نهائية وأصالة السلسلة ، ولديك قيود اقتصادية قوية للغاية. ثم يطرح هذا مشكلة أخرى (على سبيل المثال ، ينص عقد العطاء على أن "آلة أوراكل" - في هذه الحالة معيد التعهد - حددت الرمز المرهون وقدمت التزامًا اقتصاديًا - ولكن كيف يمكننا التوصل إلى إجماع بين القطع الخارجي لهذا الأمر؟ يمكنك كتابة معايير القطع ، وهذا ليس بالإجماع ، مما يعني أنه سيتم استغلال القطع الاجتماعي من خلال العقود الذكية (وهو أمر غير عادل أبدًا ويمكن أن يسبب مشاكل). هذا هو الحال حاليًا في EigenLayr أحد أكبر مشاكل التنازل .
إذا أين يتركنا هذا؟ من المحتمل ، إلى أن نحصل على خفض "غير موثوق به" على السلسلة بما يتجاوز الإجماع ، قد تحتاج سلاسل مثل SUAVE إلى خوارزميات إجماع خاصة بها وأمن Cryptoeconomic لإثبات تفضيلات عروض الأسعار وبناء يقين الكتلة - ومع ذلك ، هذا يعني إضافة المزيد من موجهات هجوم cryptoeconomic ، خاصة إذا كانت Rollup قيمة اللبنات الأساسية الخاصة به أعلى بكثير من أمان الاقتصاد المشفر الخاص به.
بالإضافة إلى ذلك ، لا يزال هناك الكثير من مساحة التصميم في سلاسل SUAVE من نوع SUAVE و MEVs عبر المجالات. فيما يلي بعض اتجاهات البحث الممكنة:
مطابقة النوايا والأنظمة القائمة على النية
التحسين المحدب في تداول الأصول المتعددة
DSL
إعادة تخصيص MEV
حرب مؤجلة
مشكلة التحجيم مع مجموعة واحدة من الجهات الفاعلة ولكن يجب بناؤها لأجهزة متعددة في حالة الالتفاف
تعبير التفضيل
فيما يتعلق بتعبير التفضيل ، للتفاعل مع عقد ذكي في EVM ، من الضروري إرسال مكالمة عقد (رسالة) إلى وظيفة محددة على عنوان الكود المنشور الذي يحتوي على تعليمات التنفيذ. بينما يقدم المستخدمون مدخلات ، قد لا يكون لديهم سيطرة على المخرجات بسبب الحالة المحتملة.
في المقابل ، تتطلب أنظمة تصميم تعبير التفضيل (مثل SUAVE و Anoma) فقط من المستخدمين توقيع التفضيلات بسند ، والذي يتم دفعه للبناة ومنتجي الكتل إذا تم استيفاء تفضيلات الباحث. بالنسبة للمنطق الاندماجي المعقد ، مثل تسلسل المعاملات لباحثي وبناة MEV ، قد يلزم تنفيذ لغات مختلفة وآلات افتراضية. هذه مساحة تصميم جديدة حظيت بالكثير من الاهتمام مؤخرًا ، خاصةً هندسة Anoma. أيضا ، نحن نوصي بشدة بهذه المقالة القصيرة.
شاهد النسخة الأصلية
المحتوى هو للمرجعية فقط، وليس دعوة أو عرضًا. لا يتم تقديم أي مشورة استثمارية أو ضريبية أو قانونية. للمزيد من الإفصاحات حول المخاطر، يُرجى الاطلاع على إخلاء المسؤولية.
فارز مشترك مفصل رباعي الأبعاد: مبدأ العمل ونظرية التجميع والتكامل الرأسي
** العنوان الأصلي: "**** The Shared Sequencer ****" **
** بقلم: MAVEN11 **
** التجميع: Kxp، BlockBeats **
تخيل ما سيكون عليه الحال إذا تمكنت Rollup "خارج الصندوق" من تحقيق درجة عالية من مقاومة الرقابة ، وسهولة النشر ، وإمكانية التشغيل البيني ، والنهاية السريعة ، والحيوية ، وإضفاء الطابع الديمقراطي على MEV. قد يبدو هذا كهدف كبير ، ولكن مع ظهور التسلسل المشترك ، قد يصبح حقيقة واقعة قريبًا. ومع ذلك ، ليست كل المجموعات هي نفسها ، لذلك يتعين علينا التفكير في كيفية توزيع المكافآت و MEV على شبكة جهاز التسلسل المشترك. في هذه الورقة ، نستكشف كيفية تنفيذ شبكات التصنيف المشتركة والخصائص التي يمكن تحقيقها.
تم تقديم شبكات التسلسل المشتركة بشكل أساسي بواسطة Alex Beckett ، وفي وقت لاحق بواسطة Evan Forbes (و Radius) من فريقي Celestia و Espresso ، ومقال جديد بقلم Jon Charbonneau يغطي الموضوع بمزيد من التعمق. جوش ، جوردان ، وفريقهم في Astria يبنون أول شبكة تسلسل مشترك جاهزة للإنتاج. شبكة الطلبات المشتركة في Astria عبارة عن blockchain معياري يقوم بتجميع معاملات Rollup وطلبها دون تنفيذها.
في إعداد Astria ، يرسل عامل الفرز الكتل المرتبة إلى طبقة DA وأيضًا إلى عقد الالتفاف. تحصل التراكميات على ضمانات نهائية ناعمة من صاحب الطلب وضمانات نهائية صارمة من طبقة DA (بعد إنهاء الكتل) ، وبعد ذلك سيتم تنفيذ المعاملات الصحيحة.
شبكة التسلسل المشترك هي في الأساس مجموعة من أجهزة التسلسل المتوافقة مع Rollup ، كما يوحي اسمها ، يمكنها تقديم خدمات لمجموعة مختلفة من Rollups. هذا له العديد من المفاضلات والخصائص ، والتي سنقوم بتفصيلها لاحقًا. أولاً ، يجب أن نصف أهم خصائص الفارز (أو مجموعة الفرز). في Rollup ، المطلب الرئيسي لمنظم التسلسل أو مجموعة من أجهزة التسلسل هو مقاومة الرقابة أو الحيوية (بعضها يأتي من الطبقة الأساسية ، بالإضافة إلى الأمان). هذا يعني أن المعاملة الصالحة التي يتم إرسالها إلى مقدم الطلب يجب أن يتم تضمينها في السلسلة في غضون فترة زمنية محدودة (معلمة المهلة). تحتاج مجموعة الطلبات المشتركة فقط إلى ضمان تضمين المعاملات في الكتل (أي قوائم crLists).
إن تلبية مقاومة الرقابة والفورية في نفس الوقت أمر صعب للغاية ، كما أوضحنا في Modular MEV Part II. في خوارزمية إجماع مثل Tendermint ، يمكنك ضمان التعافي بعد الهجوم. ومع ذلك ، في حالة وقوع هجوم ، تفقد السرعة. بشكل أساسي ، قد لا يكون طلب جميع أدوات التوليف الأخرى للتوقيع على كتلة ، بدلاً من اختيار رمز رئيسي مخصص ، هو الأمثل. في حين أن هذا يحسن مقاومة الرقابة ، فإنه يأتي على حساب "المركزية" واستخراج MEV إلى رمز رئيسي واحد. يمكن مقارنة آلية الفرز الأخرى المتاحة بـ Duality's Multiplicity ، وهي أداتهم الصغيرة لغير الرموز الرئيسية (أو الفرز) لتضمين المعاملات الأخرى في الكتل. بشكل عام ، يصعب تحقيق مقاومة الرقابة والفورية بعد الهجوم في معظم بروتوكولات الإجماع.
خوارزمية إجماع أخرى يمكن استخدامها هي HotStuff 2 ، والتي تضمن السرعة في حالة وقوع هجوم.
ما يسمح به هو تجنب انتظار الحد الأقصى لتأخير الشبكة (المهلة) في حالة الرقابة أو عدم التوقيع لانتخاب رمز رئيسي جديد. السبب في أنها قد تكون خوارزمية إجماع مثيرة للاهتمام لمجموعة لامركزية من الطلبات هو أنها تحل مشكلة فورية بالإجماع دون إضافة مرحلة إضافية. إذا كان ماسترنود يعرف أعلى قفل (أكبر عدد من المشاركين يتفقون على ناتج معين) ، ويمكنه إقناع الأطراف الصادقة ، يتم حل المشكلة. إذا لم يكن الأمر كذلك ، يمكن أن يتولى الرمز الرئيسي الصادق بعد نقطة معينة مسؤولية الدفع ، مما يساعد على الرمز الرئيسي التالي. على سبيل المثال ، لا تحتاج عقدة Hotstuff إلى استلام رسالة تبديل قبل إخطار رئيس جديد ، ولكن يمكنها التبديل مباشرةً إلى طريقة عرض جديدة وإخطار المدير الجديد.
الاختلاف مع Tendermint هو أنه على الرغم من أن كلاهما على مرحلتين (Hotstuff1 له ثلاثة ، Hotstuff2 له اثنان) ، فإن Tendermint لديه اتصال خطي ولكنه لا يستجيب ، بينما Hotstuff2 هو رد الفعل. إذا كانت هناك سلسلة من Masternodes صادقة ، فإن البروتوكول يستجيب بشكل إيجابي ، لأن جميع الخطوات باستثناء اقتراح Masternode الأول تعتمد على الحصول على كمية المعلومات من الخطوة السابقة. في إعداد الطلب المشترك ، يسمح هذا للبروتوكول بتحقيق فورية أفضل دون الرجوع إلى الطبقة السفلية ، مع عدم إلغاء هذا الاحتمال.
بناء مجموعات فارز مشتركة
يُسمح لمجموعة من أوامر الشراء بإرسال المعاملات إلى طبقة التسوية (الطبقة التي يوجد بها التجميع). يمكنك الانضمام إلى مجموعة التجميع هذه ، بشرط استيفاء متطلبات معينة وعدم الوصول إلى العدد المطلوب من منتجي الكتل. يعمل هذا على تحسين زمن الوصول والإنتاجية والمزيد. هذه المتطلبات مشابهة لتلك المطلوبة لتصبح مدققًا لـ blockchain. على سبيل المثال ، يجب أن تفي بمتطلبات معينة للأجهزة ، بالإضافة إلى إيداع أولي ، خاصة إذا كنت ترغب في التأكد من الظروف المالية.
تتكون مجموعة الطلبات المشتركة (أو أي مجموعة أوامر لامركزية) من عدة مكونات تعمل معًا لضمان المعالجة الصحيحة للمعاملات ، بما في ذلك:
قم بتوفير JSON-RPC لكل مجموعة تجميعية لتقديم المعاملة (لمشغلي العقدة غير الكاملة) إلى العقدة كمجمع ذاكرة ، ثم قم بالبناء والفرز. في mempool ، هناك حاجة إلى بعض الآليات لتحديد قائمة الانتظار ، وكذلك عملية اختيار المعاملة ، لضمان البناء الفعال للكتل.
خوارزمية بناء الكتلة / الدُفعات ، وهي مسؤولة عن معالجة المعاملات في قائمة الانتظار وتحويلها إلى كتل أو دفعات. قد تتضمن هذه الخطوة أيضًا ضغطًا لتقليل حجم الكتلة الناتج (يسمى ضغط البيانات). كما ذكرنا ، يجب أن يكون هذا منفصلاً عن مقدم العرض ، أي دعم السلوك الإيجابي بشكل أساسي. يمكن ضغط البيانات بعدة طرق ، على سبيل المثال:
إغفال حقول البيانات: حقول البيانات ليست مطلوبة لعمليات النقل البسيطة ، ولكنها مطلوبة للمعاملات الأكثر تعقيدًا.
استبدل التوقيعات الفردية بالتوقيعات المجمعة من BLS: التوقيعات هي أكبر عنصر في معاملات Ethereum. بدلاً من تخزين كل توقيع ، يمكنك تخزين توقيعات BLS المجمعة لعدد معين من المعاملات. يمكنك أيضًا التحقق من التوقيع الكلي BLS مقابل مجموعة الرسائل وتعيين المرسل لضمان صلاحيتها.
استخدم الحقل من كفهرس: مثل الحقل "إلى" ، يمكنك استخدام الحقل "من" كفهرس للتعيين.
أحد المفاهيم المثيرة للاهتمام للتصميم "المعياري" هو أنه يمكنك إجراء تعديلات ومقايضات حسب الحاجة لجعلها تعمل مع مجموعة التحديثات الخاصة بك.
خوارزمية دوران رئيسية لمجموعات أوامر الشراء المشتركة (لا يتطلب إجماعًا في حالة الاختيار الرئيسي الفردي). يمكنك اختيار تعيين خوارزمية دوران العقدة الرئيسية فقط ، أو اتخاذ مسار منتج الكتلة المتزامن المتعدد الذي اقترحته Duality.
يمكن أن تضمن خوارزميات الإجماع ، مثل Tendermint المذكورة أعلاه أو Hotstuff2 ، أن تتوافق عقد التجميع مع التسلسل الذي يقترحه دفتر الأستاذ.
عميل RPC لإرسال الكتل / الدُفعات إلى طبقة إجماع DA + الأساسية بحيث يمكن إضافة الكتل / الدفعات بأمان إلى طبقة DA ، مما يضمن النهاية "النهائية" وإتاحة جميع بيانات المعاملات على السلسلة.
فصل الأدوار بين البناة والمنتجين لضمان العدالة والاتساق ، وتجنب سرقة MEV. يزيل أيضًا الفرز الذي تم إجراؤه ، وهو أمر مهم لتحسين الكفاءة وتقليل PGA وزيادة CR.
يتم نشر Calldata أولاً إلى الشبكة الأساسية ، حيث يتم تشغيل الإجماع لضمان معاملات المستخدم والتجميع. بعد ذلك ، تقوم عقدة التجميع بتنفيذ المعاملة وإرسال وظيفة انتقال الحالة إلى سلسلة Rollup الأساسية. توفر شبكة من أوامر الشراء المشتركة خاصية Rollup الفورية ومقاومة الرقابة. تحافظ المجموعات التراكمية على سيادتها لأن جميع بيانات المعاملات مخزنة في الطبقة الأساسية ، مما يسمح لها بالتشعب من الأمر المشترك في أي وقت. يتم حساب جذر الحالة الخاص بوظيفة انتقال حالة الالتفاف (STF) من جذور المعاملة (المدخلات) المرسلة من الأمر المشترك إلى طبقة DA. في Celestia ، يتم إنشاء جذور الحالة عند إضافة البيانات إلى السلسلة والتوصل إلى توافق في الآراء. نظرًا لأن لديك بالفعل جذر المعاملة (وجميع البيانات المتاحة) ، يمكن أن توفر Celestia للعملاء الخفيفين (عقد التجميع التي تعمل على Celestia) مع دليل صغير على التضمين.
من أجل توفير تجربة المستخدم التي يتوقعها المستخدمون ، تتلقى عقد الالتفاف كتلًا مرتبة (يتم إرسالها أيضًا إلى طبقة DA). يمكن أن يوفر هذا Rollup ضمانات حتمية ناعمة - ضمانات بأن الكتل سيتم ترتيبها في النهاية بالترتيب على طبقة DA ، وعند هذه النقطة تنفذ العقد التراكمية المعاملات وتوفر جذور حالة جديدة.
بلوك الإنشاء والفتحة
من أجل تحديد وقت إنشاء الكتلة ، يحتاج منظم التسلسل إلى ضبط الفتحة. يجب على جهاز التسلسل إرسال الدُفعات على فترات زمنية ثابتة (عادةً X ثانية) ، حيث يمثل X وقت الفتحة. يضمن هذا معالجة المعاملات بسرعة وكفاءة ، لأنه بخلاف ذلك ، سينتهي الرمز الرئيسي لفتحة معينة ويفقد مكافأة التوقيع (ومكافأة التنفيذ). على سبيل المثال ، يبلغ وقت حظر Celestia (وفقًا لمواصفات GitHub) حوالي 15 ثانية. نظرًا لأن هذا معروف ، يمكننا وضع بعض الافتراضات حول عدد "الفتحات / الكتل" التي قد تكون لدينا من مجموعة coorters المشتركة إلى طبقة DA ويتم تحميل عقد الالتفاف في الكتل النهائية. في هذا الصدد ، يمكننا الرجوع إلى Tendermint أو Hotstuff2 المحسن.
ضمن نفس الفتحة ، يمكننا إرسال دفعات متعددة من المعاملات ، بشرط أن يتضمن التصميم آليات للعقد التراكمية الكاملة لمعالجتها بكفاءة في كتلة واحدة (خلال تلك الفترة الزمنية ومعلمات المهلة). يساعد هذا في تحسين إنشاء الكتل بشكل أكبر ويضمن معالجة المعاملات بسرعة. بالإضافة إلى ذلك ، يمكن أيضًا استخدام الفتحات لتسهيل اختيار العقد الرئيسية للفرز. على سبيل المثال ، يمكنك تحديد عقدة رئيسية للفتحة بشكل عشوائي من مخزن التخزين على أساس وزن التخزين المؤقت. إن القيام بذلك بطريقة تحافظ على السرية ، وتوظف شيئًا مثل انتخاب القائد السري لتقليل الرقابة هو الخيار الأفضل ؛ أو حتى إعداد تكنولوجيا التحقق الموزعة مثل حلول مثل Obol / SSV. الكمون ووقت الفتحة لهما تأثير كبير على عمليات الإرسال المجمعة والبناء على البروتوكول. لذلك نحن بحاجة إلى النظر في كيفية تأثير ذلك على النظام. لدى Bloxroute بعض نقاط البحث والبيانات الرائعة حول Ethereum على وجه الخصوص. في MEV-Boost ، يطلب منتجو الكتل المشاركين (المدققون أو أجهزة التسلسل في حالة التراكمية) GetHeader من المرحل. يمنحهم هذا قيمة عرض سعر الكتلة ، وهي قيمة كتلة معينة. قد يكون هذا هو أعلى كتلة يتم تلقيها في كل مرة. لكل فتحة ، يطلب المدققون عادةً GetHeader حوالي 400 مللي ثانية بعد بدء الفتحة - نظرًا للعدد الكبير من أدوات التحقق ، غالبًا ما تحتاج المرحلات إلى إرسال طلبات عديدة. هذا أيضًا ما يمكن أن يحدث مع مجموعات الفرز المشتركة الكبيرة. هذا يعني أنك بحاجة إلى البنية التحتية الموجودة لتسهيل هذه العملية.
تساعد المرحلات أيضًا في تسهيل فصل البناة ومنتجي الكتل ، مع التحقق أيضًا من أن البناة قاموا ببناء الكتل الصحيحة. كما أنهم يتحققون من دفع الرسوم بشكل صحيح ويعملون كحماية DoS. أيضًا ، هم في الأساس أمناء على الكتل ويتعاملون مع تسجيل المدققين. هذا مهم بشكل خاص في بنية منظم التسلسل غير المحدود ، حيث تحتاج إلى تتبع من شارك ومن لم يشارك (على سبيل المثال ، طبقة المزامنة التي تمت مناقشتها سابقًا).
فيما يتعلق بأوقات الحظر (أي الكتل المقدمة من قبل المنشئين) ، فإنها تحدث عادةً حوالي 200 مللي ثانية. يبدأ تشغيلها في الغالب قبل / بعد حوالي 200 مللي ثانية ، على الرغم من وجود تباين كبير مثل GetHeader. إذا أرسل المنشئ الكتلة إلى مرحلات متعددة ، فسيؤدي ذلك إلى تأخير كبير. نظر Bloxroute أيضًا في ما يحدث عندما يتم إرسال الكتل إلى مرحلات متعددة. كما قد تتوقع ، فإن التأخير في انتشار الكتلة إلى المزيد من المرحلات سيكون أكبر. في المتوسط ، استغرق التتابع الثاني 99 مللي ثانية لإنفاق الكتلة ، والثالث 122 مللي ثانية ، والرابع 342 مللي ثانية.
ما تعلمناه على الأرجح خلال الأشهر القليلة الماضية هو أن RPC مهم جدًا لشبكات البلوكشين. إنه عبء كبير بدون البنية التحتية المناسبة ، كما أن وجود خيار RPC مناسب أمر بالغ الأهمية أيضًا. في هذه الحالة ، يعد RPC مهمًا لمستثمري التجزئة الذين يرسلون معاملاتهم إلى RPC (والمجمع المشترك العام). أجرت Bloxroute اختبارًا صغيرًا لـ 20 معاملة تم إرسالها إلى العديد من RPCs وقياس الوقت الذي تستغرقه كل معاملة ليتم تضمينها في كتلة.
ومن المثير للاهتمام ، أن بعض RPCs لا تتضمن المعاملات إلا بعد عدة كتل ، اعتمادًا على المنشئ الذي يفوز في الكتلة التالية. إذا أرسل RPC المعاملة إلى المزيد من المنشئين ، فإن احتمال التضمين السريع يكون أعلى. على الرغم من أنه من الممكن لمنشئي المعاملات الاستفادة من موقعهم الفريد من أجل التدفق لاستهداف بنائين محددين أو حتى بناء كتلهم الخاصة.
أداؤهم مثير للاهتمام أيضًا في إحصائيات أداء ترحيل Ethereum. يساعدنا هذا في اكتساب فهم أعمق لكيفية عمل PBS في عالم متعدد للتحقق / البناء / الترحيل ، وهو ما نأمل في تحقيقه من خلال ترقية Rollup. لدى Metrika بعض الإحصائيات الرائعة حول هذا الموضوع وجميع نقاط البيانات ترجع إليها.
من المهم ملاحظة أن العطاءات الفائتة تحدث عندما يُتوقع أن يقدم المُرحِّل المزايدة ، لكنه لا يقوم بالمزايدة. تأتي التوقعات المستهدفة من المدققين المسجلين في مرحل معين لأي فتحة معينة. هذا ليس خطأ ترحيل في حد ذاته ، ولا يتم التعامل معه بهذه الطريقة على مستوى البروتوكول.
إذا حدث خطأ (مثل مرحل يخدم كتلة غير صالحة) ، وكان مسؤولاً ، فسيتم اعتباره خطأ. عادة ما تكون هذه حالات نادرة وهي في الغالب حالات فشل تفضيل التسجيل (أي حدود الغاز أو الرسوم التي لا تتطابق مع التسجيلات الخاصة بمدقق معين). والأكثر ندرة هي حالات فشل طبقة الإجماع ، والتي لا تتوافق مع قواعد طبقة توافق Ethereum ، مثل الفتحات غير الصحيحة أو تجزئة الأصل غير المتوافقة مع الكتلة السابقة ، وما إلى ذلك.
فيما يتعلق بزمن الانتقال (مثل الوقت الذي يستغرقه المدقق لاستلام رأس كتلة تم إنشاؤه بواسطة منشئ) ، تكون البيانات متسقة للغاية. على الرغم من وجود بعض القيم المتطرفة ، مثل التتابع المطلوب في موقع جغرافي مختلف عن المدقق المختار.
فيما يتعلق بالبناة ، يبلغ إجمالي عدد البناة على MEV-boost حوالي 84 ، مع قيام الثلاثة الأوائل ببناء حوالي 65 ٪ من الكتل المبنية. على الرغم من أن هذا قد يكون مضللًا إلى حد ما لأن هؤلاء هم أيضًا البناة الأطول تشغيلًا. النتائج متشابهة إذا تم تقليل الإطار الزمني. عدد البناة النشطين الفعلي أقل بكثير ، 35 في الثلاثين يومًا الماضية و 24 في الأسبوع الماضي. المنافسة شرسة ، وعادة ما يفوز البناء الأقوى. قد يكون هناك بالفعل تدفق أوامر حصري ، والذي لن يؤدي إلا إلى تفاقم الوضع. نتوقع أن يظل توزيع المنشئين مركزيًا نسبيًا (نظرًا لأن هذا يعد سباقًا لتدفق النظام الأمثل وتحسين الأجهزة) ما لم نجري تغييرات كبيرة على الإعداد. على الرغم من أنها ليست مشكلة أساسية ، إلا أنها لا تزال قوة مركزية في المكدس ونود أن نسمع أفكارًا حول كيفية تحدي الوضع الراهن هنا. إذا كنت مهتمًا بالتعمق في هذه المشكلة (الخطيرة) ، فنحن نوصي بشدة بقراءة مقالات Quintus حول تدفق الطلبات والمزادات والمركزية.
بالنسبة لدور Builder في مكدس الوحدات النمطية في المستقبل ، نحن على يقين تام (على الأقل في إعداد Cosmos SDK) سنرى إعداد Skip / Mekatek-like Builder Modules. حل آخر هو إعداد نوع SUAVE ، مثل سلسلة بناء عالمية محددة تقدم خدمات بناء الكتل وتفضيل العطاءات لأي عدد من السلاسل لضمان دعم السلوك الإيجابي. سنستكشف هذا الحل بمزيد من التعمق لاحقًا ، ونقدم بعض الإجابات على الأسئلة التي لم يتم تناولها هنا.
فيما يتعلق بالمرحلات ، نوصي بشدة بقراءة مقال بقلم Ankit Chiplunkar من Frontier Research و Mike Neuder من مؤسسة Ethereum يسمى Optimistic Relays وأين يمكن العثور عليها. يوضح هذا المنشور بالتفصيل كيفية المرحلات في عمل MEV-boost ، والمفاضلات الحالية وتكاليف التشغيل ، وبعض التغييرات التي قد تزيد من الكفاءة. ومن المثير للاهتمام ، أن تشغيل مرحل في MEV-Boost يكلف حاليًا حوالي 100000 دولار سنويًا وفقًا لتقديرات Flashbot.
الحتمية
قبل أن نتحدث عن حتمية سلاسل الكتل المعيارية (كما تبدو حاليًا) ، دعنا نلقي نظرة على مقالتنا السابقة "معيارية MEV". لاحظ أن هذه ليست نظرة "رسمية" ولا شاملة للنهاية ، ولكننا نعتقد أنها تمثل بدقة أكبر الفروق الدقيقة في نهائية التراكمية لسهولة الفهم.
معلق \ _ تشغيل \ _L2: يمثل أمر التجميع التزامًا بسيطًا بأن معاملة المستخدم سيتم الالتزام بها وإنهائها في النهاية على الطبقة الأساسية لأمنها.
النهاية \ _On \ _L2: التزم منظم التسلسل بوظيفة انتقال الحالة في Rollup ، وتمت إضافة الكتلة إلى سلسلة Rollup الأساسية.
معلق \ _ تشغيل \ _L1: تم نشر وظيفة انتقال الإدخال أو الإخراج / الحالة للمعاملة إلى L1 ، ولكن لم يتم إصدار إثبات الصلاحية بعد ، أو لم تنته فترة التحكيم بعد - وهذا يتطلب Ethereum لعصرين متتاليين. هذه هي النقطة التي تقول عندها معظم التراكمية المتفائلة أنها وصلت إلى نهايتها ، ولكن لا تزال هناك فترة تحدي تعسفية مدتها 7 أيام في هذه المرحلة وفقًا لمواصفات جسر عبر السلسلة.
نهائية \ _ تشغيل \ _L1: بالنسبة إلى مجموعة التحديثات المتفائلة ، انتهت فترة التحكيم ، أو تم تأكيد إثبات صحة منشور ومحقق من قبل أغلبية ساحقة في فترتين متتاليتين.
الآن ، في تجميع الفرز المشترك السيادي ، يبدو هذا مختلفًا بعض الشيء ، دعنا نحاول شرحه برسم تخطيطي:
في هذه الحالة ، نظريًا يمكننا الحصول على الحتمية على L1 قبل L2 ، وما إلى ذلك؟ نعم ، في هذه الحالة ، تكون L2 ذات سيادة بعد كل شيء. هذا على افتراض عدم وجود أدلة على الاحتيال وفترات تحدي ، أو أنك تستخدم إثبات الصلاحية.
إذن كيف نحقق هذه المستويات من النهايات؟ يتم تحقيق نهائية الكتلة عند إضافة كتلة إلى السلسلة الأساسية ، والتي لا يمكن سحبها. ومع ذلك ، هناك بعض الفروق الدقيقة هنا ، اعتمادًا على العقد الكاملة أو الخفيفة. في حالة الكتلة المرتبة ، تكون حتمية بمجرد تضمينها في كتلة طبقة DA. يتم فرض الكتل (مع جذور الحالة) من خلال العقد / المدققات الكاملة Rollup ، والتي تمنحهم ضمان جذر حالة صالح مشتق من الكتل المرتبة للطبقة الأساسية. بالنسبة إلى الحتمية التي تتجاوز العقد الكاملة (مثل العملاء الخفيفين أو الجسور المتقاطعة) ، يجب أن تكون متأكدًا من صحة جذر هذه الحالة. هنا ، يمكنك استخدام إحدى الطرق الموضحة أدناه. أيضًا ، هناك طريقة أخرى تتمثل في جعل المدققين مسؤولين عن الإثبات الصحيح لجذر الدولة (الطريق المتفائل) ، من خلال سند وإثبات لاحق على الاحتيال. بالإضافة إلى ذلك ، يمكنك تقديم إثبات صحة (ZK).
طرق مختلفة لتحقيق الكتلة النهائية:
من خلال إثبات العمل (PoW) و LMD + Ghost و Goldfish و Ouroboros (PoS) وطرق احتمالية أخرى.
طريقة يمكن إثباتها عن طريق عدد كافٍ من أعضاء اللجنة للتوقيع. (مثل Tendermint 2/3 أو Hotshot2 أو أنواع PBFT الأخرى)
يعتمد على ترتيب المعاملات / الكتل على طبقة DA ، وقواعدها ، وهي قواعد اختيار السلسلة المتعارف عليها والشوكة.
يمكننا تحقيق أنواع مختلفة من النهايات من خلال آليات مختلفة.
أحد أنواع النهايات هو "النهاية الناعمة" (مثل المعلقة) ، والتي يمكن تحقيقها من خلال انتخاب زعيم واحد. في هذه الحالة ، سيكون لكل فتحة كتلة واحدة فقط أو كتلة صفرية (ملتزمة أم لا) ، ويمكن لطبقة التزامن أن تفترض بأمان تسلسل المعاملات في هذه الكتل.
نوع آخر من النهائية هو "نهائية يمكن إثباتها" ، والتي توفر ضمانات أقوى (نهائية بشكل أساسي) من النهاية الناعمة. لتحقيق نهائية يمكن إثباتها ، يجب على غالبية الأوامر التوقيع على الكتلة ، وبالتالي التعبير عن موافقتهم على أن الكتلة أساسية. في حين أن هذا النهج لطيف ، فقد لا يكون ضروريًا إذا تم تنفيذ انتخاب زعيم واحد ، لأنه يضمن بشكل أساسي أمر الكتلة. من الواضح أن هذا يعتمد على خوارزمية انتخاب الزعيم المعين التي يتم تنفيذها. على سبيل المثال ، هل هو تنفيذ بنسبة 51٪ ، أم تنفيذ بنسبة 66٪ ، أم قائد واحد (يفضل اختيار عشوائي (VRF) وسري). إذا كنت تريد معرفة المزيد عن الحتمية في Ethereum ، فاقرأ هذه المقالة التي نوصي بها بشدة ، والمقال الذي نوصي به لاحقًا لمجموعات الفرز غير المحدودة.
مرخصة أو شبه مرخصة أو غير مسموح بها
لمنع هجمات DoS المحتملة ، يجب وضع حواجز اقتصادية للانضمام إلى مجموعة الطلبات وإرسال المعاملات إلى طبقة الأمر. في المجموعات المحدودة (عدد محدود من أجهزة الفرز) وغير المحدودة (عدد غير محدود من أجهزة الفرز) ، يجب وضع حواجز اقتصادية لإرسال الدُفعات إلى طبقة DA لمنع طبقة المزامنة (نشر الكتل بين أجهزة الفرز) للحصول على بطء أو تحت هجوم DDoS . ومع ذلك ، توفر طبقة DA نفسها أيضًا بعض الحماية ، لأن إرسال البيانات إليها يتطلب تكلفة (da \ _fee). يجب أن يغطي مبلغ التأمين المطلوب للانضمام إلى المجموعة غير المحدودة أي تكاليف إضافية ضرورية لمنع طبقة المزامنة من البريد العشوائي. من ناحية أخرى ، سيعتمد الهامش المطلوب للانضمام إلى مجموعة محدودة على الطلب (متوازن من منظور التكلفة / الإيرادات).
بالنسبة لمجموعة غير محدودة من أدوات الفرز ، لا يمكننا تحقيق نهائية يمكن إثباتها في طبقة الفرز (نظرًا لأننا لا نعرف أبدًا عدد الناخبين / الموقعين النشطين). من ناحية أخرى ، في مجموعة محدودة من coorters ، يمكن تحقيق نهائية يمكن إثباتها من خلال غالبية كتل التوقيع coorters. يتطلب هذا أن تكون طبقة المزامنة على دراية بطبقة جهاز التسلسل وعدد أجهزة التسلسل النشطة في أي وقت معين ، وهو مقدار حمل إضافي. في مجموعة محدودة من الفرز (على سبيل المثال حتى 100) ، يمكنك أيضًا تحسين عدد الفرز لتحسين "الأداء" ، على الرغم من ذلك على حساب مقاومة اللامركزية والرقابة. إن أهمية المجموعات المحدودة والضمانات الاقتصادية لتوفير يقين "سريع" يمكن إثباته أمر حاسم أيضًا.
تنعكس أيضًا أنواع الفرز غير المحدود والفارز المحدود في سلاسل الكتل التقليدية. على سبيل المثال ، تعتمد PoS (Casper + LMD-GHOST) في Ethereum نوعًا غير محدود ، بينما تعتمد السلسلة المستندة إلى Cosmos SDK / Tendermint على النوع المقيد. هناك فكرة مثيرة للاهتمام وهي ، هل نتوقع رؤية اقتصاديات شبيهة بإثبات الحصة وخيارات من المجتمع حول أوامر الشراء المشتركة؟ في هذا الصدد ، رأينا تحركًا نحو مركزية بعض الكيانات (لذا لا يهم حقًا عدم التقييد إذا كان لديك بالفعل بعض موفري / مجموعات إثبات الحصة الكبيرة). على الرغم من أنهم "يخفون" المركزية ، إلا أنه لا يزال بإمكانك الألغام إذا أردت ذلك. من وجهة نظر أيديولوجية ، يجب أن تكون الخيارات دائمًا غير محدودة - لكن تذكر أن المبادئ الاقتصادية تجعلها متشابهة جدًا على أي حال. بغض النظر عمن هم المشاركون ، يجب أن تظل اقتصاديات ما تدفعه هي نفسها ، مثل تكلفة DA وتكلفة الأجهزة (على الرغم من أنه قد يتم تقليل ذلك من خلال عدد إثباتات الحصة التي تخصصها وتجربتها ، وتتسم بالكفاءة تشغيل البنية التحتية). حتى في عالم PoS المحدود ، رأينا مجموعة من مزودي البنية التحتية أصبحوا أكبر المدققين وأكثرهم شيوعًا في جميع السلاسل تقريبًا. في معظم سلاسل Cosmos ، تكون التبعيات بين المدققين كبيرة جدًا بالفعل ، وهذا بالتأكيد يشكل خطرًا على مقاومة اللامركزية والرقابة على السلاسل المذكورة. ومع ذلك ، هناك حقيقة مختلفة تمامًا وهي أن أي مستثمر تجزئة يمكنه المشاركة في أي مبلغ مع أي مدقق يختاره. لسوء الحظ ، يتم تعيين هذا عادةً في أعلى القائمة ، وتستمر الحياة. نسأل مرة أخرى: هل نتوقع نموذجًا اقتصاديًا مشابهًا في عالم معياري؟ يتمنى المرء أن لا يكون الأمر كذلك ، ولكن مع التخصص ، غالبًا ما تحتاج إلى أفضل ما يناسبك - وهم يميلون إلى أن يكونوا موفري إثبات حصص احترافي. سنقوم أيضًا بتغطية هذه القضايا الاقتصادية في فصل منفصل لاحقًا.
ومع ذلك ، فإن الشيء المهم الذي يجب تذكره في كل هذه الأمور هو أن أهم شيء هو مصادقة المستخدم النهائي ، وهو متاح لأي شخص ، بغض النظر عن مكان وجوده (حتى في الجيزة) من خلال العملاء الخفيفين وهرم DAS).
فيما يلي المفاضلات والمزايا لأجهزة الفرز المحدودة وغير المحدودة:
مجموعة فارز غير محدودة:
مجموعة محدودة من فارزات:
هذا هو أحد حلول Ethereum للحتمية ذات الفتحة الواحدة ، ولديك لجنة "أغلبية" عظمى.
توجد غرفة تصميم كبيرة لكيفية مراقبة مجموعات الفرز هذه وإضافة أعضاء جدد أو إزالتهم. على سبيل المثال ، هل سيتم تحقيق ذلك من خلال Tokenholder Governance (ماذا عن العديد من الرموز والتجميعات المختلفة التي تستخدم المجموعات بعد ذلك؟). هذا يعني أن تغيير الإشارات خارج السلسلة قد يكون ممكنًا من خلال الإجماع الاجتماعي (على سبيل المثال ، خذ Ethereum كمثال). ومع ذلك ، تذكر أن الإجماع الفعلي على السلسلة محدد بوضوح ، والعقوبات على انتهاك قواعد الإجماع موجودة بالفعل.
الآلية الاقتصادية للفرز المشترك
تسمح اقتصاديات مشاركة شبكة من أجهزة التسلسل ببعض الخيارات المثيرة للاهتمام. كما ناقشنا سابقًا ، لا تختلف المدققات في شبكة أوامر مشتركة كثيرًا عن مدققي L1 النموذجيين. الشبكة التي تشارك فيها هي ببساطة أكثر تحسينًا لأداء مهمة واحدة ، وهي تلقي النوايا (المعروفة سابقًا باسم PBS) ، وبالتالي اقتراح المعاملات وطلبها. تمامًا مثل المدققين "العاديين" ، هناك مكونات للإيرادات والتكلفة. على جانبي المعادلة ، هناك قدر كبير من المرونة في الشبكات التي يشارك فيها المدققون ، على غرار L1 العادي.
تأتي الإيرادات من المستخدمين أو المجموعات التي يرغبون في النهاية في التفاعل مع دفع رسوم معينة لاستخدام جهاز التسلسل المشترك. يمكن أن تكون هذه الرسوم عبارة عن نسبة مئوية من MEV المسحوب (قد يكون إدخال الأرقام صعب التقريب) ، أو تحويلات القيمة عبر السلاسل ، أو الغاز ، أو رسم ثابت لكل تفاعل. قد يكون الحل الأنسب للإيرادات هو دفع قيمة أقل لأمر الشراء المشترك من القيمة الإضافية المكتسبة من خلال الأمر المشترك التراكمي ، إلى جانب مزايا الأمان والسيولة المشتركة. لكن الجانب السلبي لهذا هو أنه من الصعب تحديد فوائد اللامركزية لجزء آخر من المكدس. ومع ذلك ، مع نمو شبكة الطلبات المشتركة في نظامها الإيكولوجي الخاص ، قد تزداد قدرتها على استخراج الرسوم. ويرجع ذلك في جزء كبير منه إلى قدرتها المتأصلة على التجميع بسهولة ، مع وفورات حجم معينة. مع انضمام المزيد من المجموعات والتطبيقات إلى الشبكة ، سيتمكن المزيد والمزيد من MEVs عبر المجالات من استخراجها.
من حيث التكلفة ، تمتلك شبكات الطلب المشتركة أيضًا خيارات منافسة. يمكنهم بسهولة تمويل استخدام الشبكة الخاصة بهم عن طريق تمويل تكلفة النشر على طبقة DA ، أو حتى تكلفة التفاعل مع التطبيقات على Rollup. هذا مشابه للاستراتيجية التي تستخدمها شركات Web 2.0 ، حيث تتحمل الخسارة الأولية في اكتساب المستخدمين (أو التراكم) ، على أمل أن تفوق إيراداتهم طويلة الأجل الرسوم. هناك طريقة أخرى أكثر حداثة أو طريقة Crypto-original وهي السماح لـ Rollup بدفع رسوم DA باستخدام رمزها الأصلي. هنا ، تتحمل طبقة الفرز المشترك مخاطر التسعير بين الرمز المطلوب لنشر البيانات على طبقة DA والرمز الأصلي الأصلي لـ Rollup. في جوهرها ، لا تزال التكلفة الأولية للفرز المشترك ، ولكنها تخلق تناسقًا في النظام البيئي من خلال الحصول على رمز "المورد" (أي التجميع). هذا يشبه إلى حد ما بناء المستودع الذي شرحناه في ورقة AppChain ، ويمكن استخدام أشكال مختلفة من DA لتقليل التكاليف. ستقدم مستويات DA المختلفة أسعارًا مختلفة بسبب الاستخدام ، وقدرة المستخدمين على التحقق بسهولة من خلال عميل خفيف ، أو ببساطة اتخاذ خيارات مختلفة لحجم الكتلة. أخيرًا ، يمكن لأمر الطلب المشترك أيضًا دفعة المعاملات قبل النشر إلى طبقة DA. في حالة ZKR ، يمكن أن يؤدي ذلك إلى تقليل تكاليف المعاملات من خلال عدد معين من أرصدة المعاملات ، وفيما يتعلق بـ ORU ، يمكنك إجراء تحسينات مختلفة في معالجة الغاز على دفعات ، والتي يمكننا رؤيتها حاليًا في مختلف التراكميات. سيؤدي ذلك إلى تقليل كمية البيانات التي يجب نشرها على طبقة DA ، وبالتالي تقليل تكلفة شبكة جهاز التسلسل المشترك وزيادة ربحية الشبكة بأكملها. سيأتي هذا على حساب الحد من قابلية التشغيل البيني وتغيير أوقات نهائية الكتلة (الحتمية على L1 كما ذكرنا سابقًا).
بشكل عام ، تسمح اقتصاديات مشاركة شبكة من أجهزة التسلسل ببعض استراتيجيات التجريب والتمهيد المثيرة للاهتمام. نحن نقدر أن الاختلاف الرئيسي سيكون حجم النظام البيئي ، وبالتالي فإن عدد MEVs عبر المجالات أكبر من جانب التكلفة. نوصي بشدة أيضًا بمراجعة منشور مدونة فريق Espresso حول الطلبات المشتركة ، فهي تغطي أيضًا المقايضات الاقتصادية (والإيجابيات) لهذه الأنواع من الشبكات. لإظهار سبب تحفيز Rollup للاستفادة من أدوات الفرز المشتركة (إلى جانب الاقتصاد) ، يمكننا اعتبارها من منظور نظرية التجميع.
نظرية التجميع والفرز المشترك
هناك طريقة أخرى لوصف الخصائص التي أحدثتها أجهزة الفرز المشتركة وهي من خلال عدسة نظرية التجميع. تشير نظرية التجميع إلى مفهوم كيفية دمج النظام الأساسي أو المجمع بين الأنظمة الأساسية الأخرى ومستخدميها بطريقة منهجية لجذب انتباه المستخدم بشكل كبير. أنت تنقل اللعبة بشكل أساسي من تخصيص مورد نادر (على سبيل المثال ، مساحة الكتلة) إلى الحاجة إلى التحكم في مورد وفير (مرة أخرى ، مساحة الكتلة منطقية في هذا المثال). تقوم نظرية التجميع في الواقع بتجميع الموردين والمنتجات (مثل Rollup و Blockspace) في تجربة مستخدم فائقة لخدمة قاعدة المستخدمين المجمعة. مع نمو تأثير الشبكة لهذه المجمعات ، تصبح هذه العلاقة حصرية بشكل متزايد. عند حدوث ذلك ، تصبح تجربة المستخدم هي العامل الأساسي الذي يميز بين الإعدادات المتشابهة. إذا كانت هناك حوافز لجذب مستخدمين جدد (مثل تجربة مستخدم جيدة وإمكانية تشغيل تفاعلي أفضل) ، فمن غير المرجح أن ينتقل التراكمي إلى شبكته الخاصة أو إعداد مختلف - حيث تؤدي تأثيرات الشبكة إلى جذب موردين جدد وانضمام مستخدمين جدد. هذا يخلق تأثير دولاب الموازنة ، ليس فقط من منظور المزود والمستخدم ، ولكن أيضًا من منظور مجمع مقاوم للرقابة.
في عالم الفرز المشترك ، يمكن النظر إلى نظرية التجميع على أنها "مجموعات" واتحادات من مختلف Rollups ، وكلها تستخدم أعمدة متشابهة من المكدس - وتمكين أنفسهم والآخرين مع السماح للمستخدمين بالحصول على نفس التجربة.
الموفرون (مثل Rollups) ليسوا حصريين من الناحية النظرية لمجموعة coorter المشتركة ، ولكن من الناحية العملية ، مجموعة coorter المشتركة ، ومجموعاتها ، ويستفيد المستخدمون من سلسلة من حلقات تأثيرات الشبكة التي تؤدي إلى زيادة استخدام هذه المجموعات. تسهل هذه الفوائد على التراكميات والمستخدمين الاندماج في مكدس مشترك لأن لديهم الكثير ليخسروه إذا لم يشاركوا. في حين أنه من الصعب رؤية هذه الفوائد عندما يكون لديك فقط مجموعتان من Rollups تتشاركان في مجموعة مُسلسِل واحدة ، فإنها تصبح أكثر وضوحًا عندما تضيف المزيد والمزيد من Rollups والمستخدمين في المعادلة. مجموعات الفرز المشتركة لها علاقة مباشرة بالمستخدمين ، حيث يطلبون معاملاتهم ، حتى إذا كان المستخدمون أنفسهم لا يعرفون أنهم يتفاعلون معهم ، نظرًا لأنهم من وجهة نظرهم ، يستخدمون فقط المجموعات التي لديهم سبب للتفاعل معها ( هذا يعني أن الطلب / الفرز أصبح حصريًا). التكلفة الوحيدة لهذه الفرز هي تكلفة الأجهزة لتشغيلها ، طالما أن مساحة الكتلة والرموز المميزة التي تؤمنها ذات قيمة للمستخدم النهائي. يتم رقمنة رسوم المعاملات ، ويتم دفعها من محافظ المستخدمين ، وربما في المستقبل ، يمكن حتى استخلاصها من خلال التطورات مثل مضيفي الدفع في تجريد الحساب (ومع ذلك ، سيتعين على شخص ما تحمل تكلفة DA والطلب والتنفيذ).
يكون هذا أكثر منطقية عند التفكير في شركة Josh و Jordan السابقة في Astria - Google. منذ نشأتها ، كانت منتجات Google مستوحاة من فكرة AT ، لا سيما في بحث Google ، الذي تم إنشاؤه عن طريق تعديل الصفحات والمقالات الفردية ، مما يجعل الوصول إليها مباشرة من خلال نافذة البحث العالمية.
في حالة وجود مجموعة مشتركة من الفرز ، فإن المستخدمين الذين يستخدمون Rollups (أولئك الذين يشتركون في مجموعة من الفرز) لديهم تكاليف اكتساب أقل وأقل ، لأنه مع زيادة عدد الموردين (Rollup) ، فمن المحتمل أن ينجذبوا إلى المجموعة . هذا يعني أنه ، في معظم الحالات ، يكون للمُجمِّع (أو المُجمِّع المتعدد) تأثير مربح للجانبين ، حيث تزداد قيمة المُجمِّع مع زيادة عدد الموردين (طالما أن تجربة المستخدم جيدة بالطبع). في المقابل ، في شبكة تسلسلية واحدة ، يقتصر اكتساب العملاء على شبكة واحدة وتطبيقاتها. إذا أراد المستخدمون استخدام تطبيق Rollup على مجموعة بيانات مختلفة ، فسيتعين عليهم (ضمن القيود الحالية) تسجيل الخروج من الشبكة تمامًا. هذا يعني أن درجة لزوجة المستخدم وقيمته ليست عالية جدًا ، وهذا يعني أيضًا أنه في أي لحظة ، إذا كان هناك نظام بيئي آخر للعرض التراكمي ذو قيمة عالية (أو لديه المزيد من الحوافز) ، فقد يتم فقد رأس المال.
السمات وملخص المفاضلات
صفات
مجموعة الفرز المشتركة عبارة عن شبكة تراكمية تقوم بتجميع المعاملات وفرزها لمجموعات متعددة. هذه التراكمية تشترك في نفس فارز. يعني تجميع الموارد هذا أن التراكميات تكتسب أمانًا اقتصاديًا أقوى وقدرات مكافحة الرقابة ، والتي يمكن أن توفر ضمانات حتمية ناعمة سريعة ومعاملات عبر التراكمية المشروطة.
في الوقت الحالي ، هناك الكثير من الضوضاء حول الذرية بين Rollups التي تشترك في نفس مجموعة الفرز ، في الغالب حول ما إذا كانت ذرية بشكل افتراضي - وهي ليست كذلك. ومع ذلك ، إذا نفذت Rollups المعنية وظائف انتقال الحالة (STFs) لبعضها البعض باعتبارها تبعيات فيما بينها ، بما في ذلك المعاملات الشرطية ، فيمكنها بالفعل تحقيق الذرية بينهما - طالما كانت محاذاة الفتحة / blocktime (كما هو الحال مع مجموعات الفرز المشتركة). في هذه الحالة ، للحصول على إمكانية التشغيل البيني الذري ، ما عليك سوى تشغيل عميل خفيف من السلسلة B على السلسلة A والعكس صحيح (على غرار طريقة عمل IBC). لتعزيز قابلية التشغيل البيني للتدابير الأمنية (بخلاف الوثوق في عقدة كاملة واحدة كعقدة خفيفة) ، يمكنك تنفيذ ZKP (إثبات الحالة) لحل "مشكلة أوراكل" لضمان صحة الحالة. سيجعل هذا الأمر أكثر وضوحًا لمعرفة ما إذا كانت معاملة مشروطة أو شيء من هذا القبيل قد أصاب جسرًا متقاطعًا متقاطعًا بينهما. أدلة الاحتيال هي أيضًا احتمال ، ولكن من الواضح أنها ستترك فترة تحدي (مما يعني أن طرفًا ثالثًا سيأتي لتغطية تكلفة هذا الخطر). أيضًا ، في حالة العملاء الخفيفين (بدلاً من العقد الكاملة) ، سيكون هناك كتلة واحدة على الأقل متأخرة بسبب انتظار رأس التوقيع + نافذة إثبات الاحتيال (إن وجدت).
نعتقد أن مشكلة "الجسر عبر السلسلة" من المرجح أن يتم حلها مع عملاء خفيفي الوزن وبراهين صفرية المعرفة. التحدي في استخدام عميل خفيف الوزن (بدلاً من عقد ذكي) في هذه الحالة هو أن الهارد فورك (ترقيات ، وما إلى ذلك) على جانب عقدة التراكمية تحتاج إلى التنسيق مع بعضها البعض للحفاظ على عمل الجسر (تمامًا كما تحتاج IBC إلى التمكين وحدة الحالة نفسها). إذا كنت تريد الغوص بشكل أعمق في هذا الموضوع المحدد (وكيفية معالجته) ، فنحن نوصي بشدة بمراجعة هذا العرض التقديمي.
السبب في أن المقياس المشترك لمنظمي الطلبات جيدًا هو أنهم لا ينفذون ويخزنون أي حالة (كما يفعل النظام المركزي اليوم). الأمر نفسه ينطبق على عُقد التراكمية نفسها (ما لم تكن تريد الذرية فيما بينها - على سبيل المثال العميل الخفيف / إثبات الحالة). لا تنفذ هذه العقد سوى المعاملات الصالحة لمجموعتها ، وأي معاملات شرطية عبر المجال صالحة لها. إذا كان يتعين على عقدة Rollup تنفيذ وتخزين الحالة للعديد من Rollups ، فهذا يعيق قابلية التوسع ويقلل من اللامركزية (وبالتالي مقاومة الرقابة). ويعزز هذا أيضًا مفهوم فصل المنتج عن البناء (PBS). على الرغم من أننا ما زلنا بحاجة إلى فصل البناة والمنتجين تمامًا. في الإعداد الحالي ، يعتبر مقدمو الطلبات في الأساس منشئين ومنتجين للكتل (على الرغم من أنهم لا ينفذون المعاملات). قد يكون الإعداد المثالي هو المكان الذي يوجد فيه المسؤول فقط للتوقيع بشكل أعمى على الكتل من إعداد المنشئ المحسن للغاية والتأكد من تنفيذ الكتل بشكل صحيح (مع توفير درجة عالية من اليقين الاقتصادي ومقاومة الرقابة لتلك الشهادة). وبهذه الطريقة ، يمكنهم توفير درجة عالية من الأمان والالتزام بضمان نهائية ناعمة لعقد التراكمية.
بالنسبة للمعاملات الشرطية عبر التجميع ، فهي موجودة أيضًا للمساعدة في تمكين عقد التجميع (المنفذون) لتوفير جذور الحالة الوسيطة ، مما يتيح القدرة الذرية بين عمليات التجميع.
التنازل عن ميزة ممن أجل الحصول على أخرى
تحتوي معلمة المهلة المذكورة أعلاه على بعض التأثيرات المثيرة للاهتمام على MEV وإدراج المعاملات ، اعتمادًا على آلية Masternode / الإجماع لمجموعة الطلب. على سبيل المثال ، إذا تم وصف معلمة المهلة بأنها قصيرة نسبيًا في ورقة السلسلة الخاصة بالتطبيق ، فمن الأهمية بمكان أن يقوم منتجو الكتل لمجموعة لامركزية من الطلبات بنشر البيانات بأسرع ما يمكن. في مثل هذا العالم ، يمكنك أن ترى المنافسة بين "المدققين" الذين يتنافسون ليكونوا عُقدًا رئيسية ويقدمون عطاءات على طبقة DA لمساحة الكتلة حتى تصبح غير مربحة.
كما غطى إيفان في منشور الطلب الكسول الأصلي الخاص به على منتديات Celestia ، فإن انتظار نشر المعاملات إلى الطبقة الأساسية (Celestia في هذه الحالة) قبل تنفيذها أمر غير فعال للغاية. منذ الآن ، أصبحت مقيدًا بوقت حظر الطبقة الأساسية - وهو وقت طويل جدًا لانتظار تجربة المستخدم. للحصول على تجربة مستخدم أفضل ، يوفر مُنشئ الطلب المشترك Rollups التزامات حتمية ناعمة (كما هو موضح سابقًا) ، والتي توفر للمستخدمين تجربة المستخدم التي اعتادوا عليها في القوائم المركزية الحالية (مع الحفاظ على اللامركزية ومقاومة عالية للرقابة). الالتزامات الميسرة هي في الأساس مجرد التزامات بالترتيب النهائي للمعاملات ، ولكنها مدعومة بضمانات اقتصادية كبيرة وإنهاء سريع بمجرد إصدارها. يتم تغطية هذا أيضًا من خلال إثباتات الاحتيال (كما هو مذكور في المقدمة). يتم تحقيق النهاية الصعبة الفعلية بعد نشر جميع بيانات المعاملة إلى الطبقة الأساسية (مما يعني أن L1 تحقق بالفعل نهائية أسرع). يعتمد ذلك على ما إذا كان التراكمي يستخدم أدلة الاحتيال أو البراهين الصفرية للتحقق من إثبات السيادة - والذي يحدث في Rollup. سبب الرغبة في هذا الفصل هو إزالة عنق الزجاجة الضخم لتحولات الحالة من جهاز الفرز. بدلاً من ذلك ، تتعامل العقد التراكمية فقط مع العقد الصالحة لها (بمعنى أنه يتعين علينا إضافة معاملات شرطية أو إثبات الحالة أو التحقق من صحة العقدة الخفيفة من أجل التشغيل البيني المناسب). لا تزال الحتمية الصارمة تعتمد على الطبقة الأساسية (ولكن يمكن أن يصل هذا إلى 15 ثانية في Celestia ، وهو أيضًا حتمي في ظل Tendermint) ، مما يمنحنا ضمانات حتمية سريعة نسبيًا على Rollup.
استخدم براهين المعرفة الصفرية داخل الشبكة لتحسين التحقق من الصحة وحجم المعاملة (على سبيل المثال فقط نشر اختلافات الحالة - ولكن هذا يضيف مستوى أعلى من الثقة حتى يتم نشر ZKP). كما ذكرنا سابقًا ، يمكن استخدام إثباتات الحالة هذه للسماح للسلاسل / التجميعات المتصلة بالتشغيل البيني بشكل أسهل وأسرع (دون انتظار نوافذ التحدي).
يتمثل الجانب السلبي لهذه المعاملات الشرطية في أنها من المحتمل أن تكون أكثر تكلفة ، مما يتطلب تكاليف أعلى للتحقق والإصدار (مثل تكلفة التحقق من رأس كتلة Tendermint ، المدعوم في سلسلة Cosmos) ، وإضافة بعض زمن الانتقال إلى النظام ( ولكن لا يزال أسرع من التراكمية المعزولة أسرع بكثير). يمكن للذرية التي تم تحقيقها من خلال التكامل المشترك عموديًا أن تعوض هذه المشاكل.
أثناء مرحلة التمهيد لمجموعة التحديثات الجديدة ، يكون استخدام مجموعة مشتركة من أدوات التوليف منطقيًا إلى حد كبير ، ومن المحتمل أن تفوق المزايا التي تكتسبها كمزود بعض المقايضات التي قد تضطر إلى إجرائها على مستوى الخندق. ومع ذلك ، بالنسبة لمجموعة التحديثات الناضجة بالفعل ، حيث يوجد الكثير من المعاملات والنشاط الاقتصادي ، فربما لا يكون من المنطقي التخلي عن جزء من الخندق المائي.
هذا يطرح السؤال عما إذا كنا بحاجة إلى ترجيح اقتصادي / معاملات (لكل مجموعة) لإعادة توزيع MEV المستخرج للحث على التراكميات الناضجة بالفعل للانضمام إلى المجموعة المشتركة - أو حتى منع التراكميات الناضجة للغاية من إنشاء شبكة خاصة. كل هذا نظري إلى حد ما ، لكنه بلا شك عملية تفكير مثيرة للاهتمام فيما يتعلق بكيفية تقديم MEV في عالم رأسي مشترك بين العديد من Rollups بمستويات مختلفة من النشاط. على سبيل المثال ، إذا كان هناك تراكم فريد يدفع القيمة يشترك في بعض هذه الأرباح مع الآخرين (ربما لا يجلب الكثير من "القيمة") عبر مجموعة منظم التسلسل ، فيجب أن يكون هناك المزيد من الأسباب التي تجعلهم ينتقلون إلى نظامهم المنعزل. لدى Sreeram بواسطة EigenLayr بعض الأفكار حول هذا أيضًا ، والتي نوصي بقراءتها أيضًا.
يصبح هذا الأمر مهمًا بشكل متزايد عند التفكير في وجود تكلفة تقنية كبيرة للباحثين لتطوير سلاسل جديدة ، لذا قد يكون توحيد المعايير وتوفير بعض السيادة على MEVs "الخاصة بهم" مكانًا جيدًا للبدء. من الناحية العملية ، في MEV ، قد تفوز الواجهة (أو البرنامج) المهيمن ، ولكن في الواقع ، تحقيق الدخل من هذا البرنامج عن طريق تشغيل أجزاء مهمة من البنية التحتية أمر صعب للغاية (مما يؤدي إلى المركزية). على مستوى السوق ، ما يقدمه الطلب المشترك هو في الأساس مجموعة ذاكرة مشتركة للعديد من المزودين ، مع مزاد مركزي ، مما قد يؤدي إلى منافسة أكثر صحة.
يتمثل أحد الشواغل هنا في أنه إذا كان هناك اثنان من Rollups يعملان على فرز في المجموعة المشتركة ، فيمكن اختيار مجموعة تراكمية بقيمة "أقل اقتصادية" (A) لاقتراح مجموعة ذات مقدار كبير من MEV + رسوم من Rollup (B). . من وجهة نظر Rollup B ، فإنهم يفقدون بشكل أساسي بعض القيمة التي سيحتفظون بها لأنفسهم في النهج المعزول.
معالجة مقايضات التشغيل البيني
ملاحظة أخرى حول المقايضات التي تقدمها قابلية التشغيل البيني ، ويتبع طريقة أخرى لحل بعض المشاكل:
الغرض من شبكة الطلب المشتركة هو توفير ضمان أساسي لسلاسل متعددة ، والتي من الواضح أنها ميزة كبيرة في هذه الحالة. يمكن دمج هذا مع آلية لضمان انتقالات فعالة للحالة بين التراكميات. قد يكون هذا نهجًا قائمًا على اللجان (مثل PoS) ، أو أدلة مضمونة (النهج المتفائل) ، أو الأسلوب المفضل لدينا - ZKP مدعومًا بتوقيعات اللجنة. نظرًا لأن أدوات الفرز المشتركة "كسولة" ، فإنها تقوم فقط بإنشاء كتل فائقة لفرز معاملات مجموعات متعددة ، ويترك تنفيذ المعاملة المحددة لمجموعة محددة. تُعد إثباتات الحالة (مثل لاغرانج ، أو أكسيوم ، أو هيرودوت ، إلخ) حلولًا ممكنة للحصول على أدلة نهائية عبر التدفقات السيادية. يمكنك أيضًا إضافة أدلة على الجودة المضمونة اقتصاديًا من خلال أشياء مثل تجمعات Staking ، و EigenLayr ، وما إلى ذلك. الفكرة الأساسية هي أن فارز مشترك يوفر ضمانًا اقتصاديًا للطلب ، وإثباتات الصلاحية الناتجة عن هذا الفرز حتمية. الفكرة الأساسية هي أن Rollups يمكنها تنفيذ المعاملات بشكل متزامن مع بعضها البعض. على سبيل المثال ، يمكن لشبكة مكونة من عقدتين تراكميتين أن تعرف بشكل مشروط أن كلا من سجلات التجميع صالحة ، عبر ZKP والبيانات المتاحة (البيانات المنشورة على طبقة DA فعالة). من خلال نشر بادئة مجموعة تجميعية واحدة من كلتا الشبكتين A و B ، يمكن لعقدة Rollup تسوية مجموعتين من Rollup في وقت واحد. هناك شيء واحد يجب الإشارة إليه وهو أن المعاملات الشرطية عبر التجميع تستهلك موارد من نظامين منفصلين من خلال التنفيذ المشترك ، لذلك من المحتمل أن تكون المعاملات الشاملة (أو المتزامنة) أكثر تكلفة من المعاملات الداخلية الفردية.
كما غطت Succinct أيضًا المعاملات "الذرية" عبر السلسلة بين Rollups مع أوامر الشراء المشتركة (ومثبتات الاحتيال المشتركة) داخل نظام Optimism hyperchain ، والتي يمكن عرضها هنا. أيضًا ، كما يقول بو دو بوليمر: "المعاملات الذرية عبر السلسلة تشبه الحصول على أقفال بين أجزاء قاعدة البيانات عند الكتابة".
مستقبل التكامل الرأسي
لقد تم بالفعل استكشاف الأعمال الداخلية المحتملة لسلاسل SUAVE بعمق بواسطة Jon Charbonneau et al ، لذلك لن نخوض في الكثير من التفاصيل. إذا كنت تريد وصفًا أكثر تفصيلاً ، يمكنك التحقق من مقالته. ومع ذلك ، نعتقد أن التكامل الرأسي يستحق مقدمة منفصلة ، لإبراز كيف يمكن أن نكون نمطيًا (ولماذا) ولتقديم بعض المشكلات والمخاوف المرتبطة بالتكامل الرأسي.
في حين أن مخطط الطلب المشترك الحالي لـ Astria و Espresso و Radius معياري للغاية ، لا يزال القائمون على الطلبات يعملون كمنشئين ومنتجي كتلة (على الرغم من أنهم في حالة Astria ، لا ينفذون المعاملات). تعمل Astria أيضًا على بناء PBS بنشاط في هندستها المعمارية منذ البداية.
إذا لم يتم تضمين دعم السلوك الإيجابي في البروتوكول ، فهناك عدة طرق لتنفيذ دعم السلوك الإيجابي (وإن كان ذلك بدرجات متفاوتة من اللامركزية). منتجات مثل SUAVE ، استخدم نماذج غير متصلة بالإنترنت مثل MEV-Boost ، أو نفذ وحدات منشئ مثل وحدات Cosmos SDK التي صممها Mekatek و Skip.
من الجدير بالذكر أن أيا من هذه الأساليب لا يستبعد بعضها البعض. لديك المرونة في استخدام عدة طرق مختلفة والسماح لأي شخص بالتعبير عن تفضيلاته. بهذه الطريقة ، يمكن أن يكون لديك منفذون يتنافسون لملء تلك الوظائف الشاغرة. تعد إضافة المزيد من الخيارات دائمًا أمرًا جيدًا (ومتوافقًا مع إيماننا بالنمطية). ومع ذلك ، سيكون للتطبيقات المختلفة مقايضات مختلفة. على سبيل المثال ، في حالة مثل SUAVE ، يمكنك إضافة حماية الخصوصية من خلال تقنية SGX أو Crypto ، وإضافة أمان اقتصادي Crypto إلى الحقيقة ، بدلاً من الاعتماد على مُنشئ PBS مركزي موثوق به تمامًا. (شكرًا لجون شاربونو على ملاحظاته هنا).
يضمن التكامل الرأسي في سلسلة المنشئ الإنصاف دون اتخاذ اختصارات ، وإضافة زمن الوصول وتقليل الأداء. لذلك ، يجب تحسين سلسلة البناء بشكل كبير وقد تتطلب أجهزة باهظة الثمن وقوية (مما يؤدي إلى المركزية). هذا يعني أنه للحصول على التحقق من صحة المستخدم النهائي ، ربما نحتاج إلى نوع من العقد الخفيفة (على الرغم من أنه يتعين عليهم الوثوق بالعقد الكاملة) ، أو استخدام دليل على إعداد نوع الحالة لضمان حصول السلسلة والمستخدمين على دليل على تفضيلات عروض الأسعار مملوءة والكتل صحيحة البناء.
قد تكون سلسلة مثل هذه ثقيلة للغاية (نريد تجنب ذلك) ، على الرغم من أن هذه المعاملات الثقيلة للولاية ستعطى الأولوية عبر العقود الذكية. في حالة العطاء ذي الأولوية ، إما أن يتم ملؤه أو لا يتم ملؤه (لفترة قصيرة من الوقت) ، نظرًا لأن العطاءات عادة ما تكون صالحة فقط لفترة قصيرة من الوقت ، اعتمادًا على التفضيل. وهذا يعني أننا قد نكون قادرين على تنفيذ حالة فعالة للغاية (ومبكرة) لانتهاء صلاحية العطاءات - مما سيتيح لنا تقليم البيانات والحفاظ على السلسلة "نظيفة". يجب أن يكون تاريخ انتهاء الصلاحية طويلًا بما يكفي للسماح بملء العطاءات أولاً ، ولكن خفضه كثيرًا سيجعل من المستحيل تقريبًا تحقيق العقود الآجلة لـ blockspace. لا نحتاج إلى تحديث واسترداد عقود العطاءات منتهية الصلاحية حيث لا يلزم وجودها إلى الأبد (على عكس التطبيقات) - يمكن القيام بذلك إما عن طريق توفير أدلة الحالة / التخزين عند ملء العطاءات أو عن طريق حلول تخزين DAS (مثل المقترحة بواسطة حل Joachim Neu) لجعله أكثر "أمانًا" وجديرًا بالثقة.
كما ذكرنا سابقًا ، قد تقتصر الحاجة إلى التحقق من "أصالة" SUAVE على "jusha" (المستخدمين المتقدمين) للنظام الأساسي ، لأن معظم مستخدمي وعملاء SUAVE يمكنهم الحصول على فوائد اقتصادية عالية منه. قد يدفعنا هذا إلى السماح للأشخاص بتشغيل عقد كاملة فقط إذا كانوا يريدون التحقق من صحتها - على الرغم من أن هذا يستثني الغالبية العظمى من الأشخاص (يمكنك القول إنهم لا يحتاجون إلى التحقق من الصحة). هذا (في رأينا) عكس Crypto ، حيث نفضل تنفيذ تحقق SUAVE "غير موثوق به" من خلال إثباتات الحالة أو تطبيقات سهلة الاستخدام للعميل.
سبب الحاجة إلى ذلك هو أنك تريد التحقق من ملء أولوية عرض التسعير الخاص بك بشكل صحيح وأن الكتلة قد تم ملؤها بالمعلومات الصحيحة عند الدفع (لتجنب إعادة التجميع والأخطاء الأخرى). هذه مشكلة أوراكل أساسًا - في الواقع يمكن حلها بإثبات الحالة (كما هو الحال مع جميع المركبات SUAVEs). ومع ذلك ، فإن أدلة الحالة هذه تثير مشكلة أخرى عند عبور السلاسل ، كيف تنقل هذه المعلومات عبر السلاسل بطريقة لم يتم العبث بها أو إخفاؤها؟ قد يتطلب هذا المرور بنهاية اقتصادية قوية (مثل تلك التي اقترحها لاغرانج) ، وفي هذه الحالة يمكنك استخدام مدققي إعادة ضبط EigenLayr لإثبات نهائية وأصالة السلسلة ، ولديك قيود اقتصادية قوية للغاية. ثم يطرح هذا مشكلة أخرى (على سبيل المثال ، ينص عقد العطاء على أن "آلة أوراكل" - في هذه الحالة معيد التعهد - حددت الرمز المرهون وقدمت التزامًا اقتصاديًا - ولكن كيف يمكننا التوصل إلى إجماع بين القطع الخارجي لهذا الأمر؟ يمكنك كتابة معايير القطع ، وهذا ليس بالإجماع ، مما يعني أنه سيتم استغلال القطع الاجتماعي من خلال العقود الذكية (وهو أمر غير عادل أبدًا ويمكن أن يسبب مشاكل). هذا هو الحال حاليًا في EigenLayr أحد أكبر مشاكل التنازل .
إذا أين يتركنا هذا؟ من المحتمل ، إلى أن نحصل على خفض "غير موثوق به" على السلسلة بما يتجاوز الإجماع ، قد تحتاج سلاسل مثل SUAVE إلى خوارزميات إجماع خاصة بها وأمن Cryptoeconomic لإثبات تفضيلات عروض الأسعار وبناء يقين الكتلة - ومع ذلك ، هذا يعني إضافة المزيد من موجهات هجوم cryptoeconomic ، خاصة إذا كانت Rollup قيمة اللبنات الأساسية الخاصة به أعلى بكثير من أمان الاقتصاد المشفر الخاص به.
بالإضافة إلى ذلك ، لا يزال هناك الكثير من مساحة التصميم في سلاسل SUAVE من نوع SUAVE و MEVs عبر المجالات. فيما يلي بعض اتجاهات البحث الممكنة:
فيما يتعلق بتعبير التفضيل ، للتفاعل مع عقد ذكي في EVM ، من الضروري إرسال مكالمة عقد (رسالة) إلى وظيفة محددة على عنوان الكود المنشور الذي يحتوي على تعليمات التنفيذ. بينما يقدم المستخدمون مدخلات ، قد لا يكون لديهم سيطرة على المخرجات بسبب الحالة المحتملة.
في المقابل ، تتطلب أنظمة تصميم تعبير التفضيل (مثل SUAVE و Anoma) فقط من المستخدمين توقيع التفضيلات بسند ، والذي يتم دفعه للبناة ومنتجي الكتل إذا تم استيفاء تفضيلات الباحث. بالنسبة للمنطق الاندماجي المعقد ، مثل تسلسل المعاملات لباحثي وبناة MEV ، قد يلزم تنفيذ لغات مختلفة وآلات افتراضية. هذه مساحة تصميم جديدة حظيت بالكثير من الاهتمام مؤخرًا ، خاصةً هندسة Anoma. أيضا ، نحن نوصي بشدة بهذه المقالة القصيرة.