إلى الأمام العنوان الأصلي 'نحن جميعًا نبني نفس الشيء'

مقدمة

يحلل هذا المنشور ما يلي

• تنفيذ غير متزامن - لماذا تكون سلاسل الكتل المتكاملة عالية الأداء (على سبيل المثال، سولاناوموناد) سيفصل التنفيذ عن الاتفاق حول ترتيب (تتابع).
• التسلسل الكسول - كيف سيعكسون تصميم متسلسل كسول (على سبيل المثال، @astriaorg/hj6ccpp9t">astria).
• التأكيدات المسبقة - Preconfs على شبكة إيثيريوم L1 وشبكات Rollups المبنية على أساسها.
• مقارنة الأساسية مقابل غير الأساسية - مقارنة الجولات المستندة إلى الأساس + preconfs مقابل الجولات غير الأساسية + الاستناد إلى الطبقة الأساسية.
• التكامل المتزامن الشامل - عبر الإدراج الذري (من المتتاليات المشتركة) + الأمان التشفيري (على سبيل المثال، AggLayerو/أو إثبات في الوقت الحقيقي).
• التراص السريع القائم على التراص - يجب أن يكون للتراص القائم على التراص قاعدة سريعة فقط.
• ألعاب توقيت - الوقت هو المال، وكيف أن هذا يكمن وراء نهايات متباينة بين سولانا وإيثيريوم.
• اللامركزية لمقاومة الرقابة - كيففصل المصادق-المقترحعبرمزادات التنفيذقد يحتفظ بالمحققين اللامركزيين الذين يمكنهم فرض مقاومة الرقابة معقوائم الاستثناء.

أخيرًا والأهم ، سنرى لماذانحن جميعا نبني نفس اللعنة الشيءربما يجب علينا فقط...

تحسين تكرار آلية الحالة (SMR)

سنبني من الأساسيات لنرى أن نهاية أداء عالي للبلوكشينات (مثل سولانا،موناد, @patrickogradyإستراتيجية التخفيف تمكين البنائين من تحقيق أقصى ربح لتقليل العمليات التجارية غير الصحيحة">التقارب (hypersdk) يقترب منالمتسلسل الكسول (على سبيل المثال، @astriaorg/hj6ccpp9t">astria). سنعود لاحقا لمقارنتها مع اللفائف المستندة إلى إثيريوم + preconfs.

التسلسل مقابل التنفيذ

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

سنستخدم البنود التالية في هذا القسم:

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

دعونا نكبّر في تسلسل وتنفيذ، لأن هذه هي المهام الفرعية الأساسية المطلوبة لحساب حالة السلسلة:

بالإضافة إلى ذلك، تقوم العقد بالتحقق والتكرار للبيانات عبر الشبكة. يتوصل العقد إلى اتفاق للحفاظ على رؤية متسقة للسلسلة.

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

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

المفاعلات النووية الصغيرة التقليدية

يقوم الـ smr التقليدي (مثل إيثيريوم) بربط التسلسل والتنفيذ بشكلٍ وثيق. تقوم العُقد بتسلسل وتنفيذ جميع معاملات طبقة الأساس بشكلٍ مستمر - كلاهما شرطٌ مسبق للعُقد للوصول إلى الاتفاق. بالإضافة إلى التحقق من توافر جميع بيانات الكتلة (والتسلسل)، يجب أن يقوم العُقد أيضًا بتنفيذ الكتلة للتحقق من أن:

• جميع المعاملات صحيحة بصورة صرفية ودلالية
• تتطابق الحالة الجديدة المحسوبة مع تلك التي قدمها القائد

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

في هذا النموذج التقليدي، يشمل البناء والتحقق على حد سواء التنفيذ.

مصدر: @patrickogrady/rys8mdl5p#جعل-الحالة-لتقديم-حالة-التكاثر-المنفصلة-dsmr">vryx: تعزيز تكاثر الحالة المنفصلة

تدفق SMR

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

مصدر: @patrickogrady/rys8mdl5p#تعزيز تكرار الآلة الحالة المفصولة (DSMR): تقديم حالة المفصولة

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

التنفيذ غير المتزامن

النهج المتكامل

هل يمكننا الحصول على أداء أفضل إذا قمنا بتخفيف تلك القيود؟

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

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

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

ربما هذا هو السببيعتقد كيوني أن كل بلوكتشين في النهاية سيستخدم التنفيذ الغير متزامن، وهو جزء أساسي من رؤية تولي النهائية لـ سولانا:

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

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

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

النهج الوحدوي

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

• التسلسل - تتوصل عقدة المتسلسل فقط إلى اتفاق بشأن ترتيب وتوفر بيانات اللف (أي تتسلسل ولكن لا تنفذ).
• تنفيذ - يقوم أجهزة Rollup بتنفيذ بياناتها الخاصة بعد أن يلتزم المسلسل بها.

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

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

في كلتا الحالتين، الأنبوب الكبير والسريع لطلب البيانات هو الأساسي الذي نحتاجه:

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

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

لهذا السبب ليس سهلاً مثل 'لماذا لا نذهب ونستخدم سولانا (أو أي سلسلة أخرى عندما لم يكن هذا هو الهدف التصميمي) كمتتابع للتجميع؟'

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

تقوية SMR المنفصلة

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

لن ننغرق كثيرًا في التفاصيل هنا، ولكن يمكنك الرجوع إلىباتريك أوغراديعمل مذهل على@patrickogrady/rys8mdl5p # تقوية DSMR المنفصل ، تولي لـ vryx للدفاع عنهانهاية التنفيذ الغير متزامن، وتنفيذ موناد لتكاليف النقلكيفية التعامل مع هذه المشاكل. مرة أخرى، تبدو الحلول لهذه المشاكل على الجانبين المتكامل والمتكامل تقريبا نفسها.

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

الممثلون داخل البروتوكول مقابل الممثلون خارج البروتوكول

بشكل هام، يجب أن ندرك أن العمليات أعلاه تحسب بسذاجة فقط للممثلين في البروتوكول. في الواقع، الممثلون خارج البروتوكول يلعبون دورًا هائلاً في سلاسل التوريد لهذه المعاملات. هذا ما رأيناه في وقت سابق للمحققين (داخل البروتوكول) في SMR التقليدي:

مصدر: @patrickogrady/rys8mdl5p#دعم تكاثر ماكينة الحالة المنفصلة

في الممارسة العملية على الرغم من ذلك ، تقريبا جميع المحققين في إيثريوم يستعينون ببناء الكتل من خلال mev-boostمع أفضل ثلاثة مُنشئين (بيفر ، تيتان ، ورسينك) يقومون ببناء معظم هذه الكتل. تُلاحظ أن بيفر ورسينك يراقبان المعاملات المرتبطة بـ OFAC بينما لا يفعل تيتان.

المصدر: ميفبوست.بيكس

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

المصدر:ميفبوست.بيكس

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

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

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

تكامل متزامن عالمي

تعريفات

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

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

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

لاحظ أننا سنناقش "التجميعات" في بقية هذا التقرير، ولكن العديد من هذه المفاهيم تنطبق بالسواء على أنواع أخرى من "L2s" مثل الفاليديومز.أنا فقط لا أريد القتال على wtf هو l2 مرة أخرى.

في الأمثلة التالية:

• r_أ = رولاب
• r_بي‏= لفة أعلى
• تي_{أ 1} = المعاملة 1 على r_أ
• t_ب1 = المعاملة 1 على r_ب
• b_a1= الكتلة 1 على r_أ
• ب_b1= الكتلة 1 على R_بي
  

لاحظ أننا نعرف "الوقت" ليكون "ارتفاع الفتحة" هنا. الوقت نسبي بحت للمراقب. الفكرة الموضوعية الوحيدة للوقت لدينا هي ترتيب نسبي من قبل مراقب مشترك ، أي إجماع مشترك (حيث قد يكون هذا "الإجماع" جهة فاعلة واحدة أو آلية لامركزية).

إذا كان لدى كل من rollups آلية موافقة توفر الترتيب ، فيمكننا التأكيد:

• b_{أ 1} قبل ب_a2
• بي_b1قبل ب_b2

ومع ذلك ، فإن الطريقة الوحيدة للتأكيد:

• ب_a1في نفس الوقت في ب_ب1، وبالتالي
• ت_a1 و ر_b1حدث بتزامن إذا
• يشتركون في ترتيب مقدم من إجماع مشترك لتلك الفتحة المحددة.

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

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

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

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

الإدراج الذري - تسلسل مشترك

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

كما كتبت سابقاً، وهذا يعني أن المتسلسلين المشتركين الكسولين يمكنهم تقديم التزام موثوق به لتضمين حزم متعددة السلاسل (أي مجموعة من المعاملات):

• ذريا - إما ستتم إدراج جميع المعاملات أو لا شيء، و
• بشكل متزامن - في نفس الوقت (ارتفاع الفتحة)

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

فك تجزئة السلسلة العابرة

الآن، كيف نفعل هذا بالضبط دون الثقة الكاملة في البناء و / أو المقترح النشط للمسلسل المشترك؟ إذا قمنا فقط بإرسال صفقتين موقعتين بشكل مستقل (t₁و ت₂) بالنسبة لكل لفة، يمكن للسيكونسر المشترك أن يقرر فقط تضمين إحدى الأخريتين.

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

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

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

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

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

مصدر: بن فيش

ضمانات الاحتواء مقابل ضمانات الدولة

مع الوضع في المكان المذكور أعلاه، لقد أنشأنا الآن كيفية تسلسل مشترك كسول:

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

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

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

افترض مثالا:

• لدينا اثنين من الروابط المتداولة (ra و rb) تشترك في نفس المتسلسلة الكسولة
• أريد استخدام جسر الحرق والطباعة بين ra → rb الذي يحرق في نفس الوقت على ra ويطبع على rb
• يحتاج عقد جسر الإنتاج على RB إلى ضمان انتقال الحالة على RA (الحرق) للإنتاج على RB، ولكن العقد لا يمكنه معرفة ما إذا تم حرق التوكن فعليًا على RA في وقت التنفيذ لأنه ليس لديه وصول إلى حالة RA

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

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

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

لحل هذه المشكلة، نحتاج إلى إضافة آلية أخرى بالإضافة إلى التسلسل المشترك:

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

لديهم خياران بشكل عام:

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

الأمان الاقتصادي للعملات المشفرة - سندات البناء

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

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

سلامة التشفير - Agglayer

ما هو عليه

ال AggLayerهو بروتوكول مركزي يوفر ثلاثة فوائد رئيسية:

1. السلامة من أجل التركيب السريع عبر السلسلة - ينتج براهين ZK التي تمنح AggChains أمانا مشفرا للتشغيل البيني الذري عبر السلسلة عند زمن انتقال منخفض (أي أسرع من كتل الإيثريوم) عند التشغيل بشكل غير متزامن أو متزامن. يعزل التصميم أخطاء السلسلة بشكل فريد بحيث يمكنه دعم أي بيئة تنفيذ و Prover.
2. تبادل الأصول عبر السلاسل - لديها جسر مشترك لضمان تبادل الأصول عبر السلاسل المجتمعة (أي السلاسل التي تستخدمها) بحيث لا ينتهي المستخدمون بمجموعة من الأصول الملفوفة. عقد الجسر على الإيثريوم الذي يعتبر طبقة التسوية. (لاحظ أنه يمكن للسلاسل المختلفة أن تكون لا تزال لها افتراضات أمان مختلفة بسبب التنفيذ، وهو ما يتم تغطيته أكثر أدناه.)
3. تحسين الغاز - إنه يثبت لـ aggchains لتوزيع التكاليف الثابتة عبر العديد من السلاسل. يحسن عقد الوديعة المشترك أيضًا تكاليف الغاز من خلال السماح بالتحويلات المباشرة من L2 إلى L2 دون لمس L1.

المصدر: بريندان فارمر, سلاسل الكتل المجمعة

لتوضيح اثنين من الافتراضات الخاطئة الشائعة حول ما ليست عليه طبقة الاتصال المجمعة:

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

الآن دعونا نتنقل إلى كيف يعمل.

التوصيل سيئ

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

• عبر الجسر الأصلي - ستدفع رسوم الغاز المكلفة لإيثيريوم L1 (أي، الجسر من أورو)_ا→ إيثريوم + إيثريوم → أورو_ب), وسيستغرق الرحلة الذهاب والعودة أكثر من أسبوع (بسبب نافذة البرهان على الخطأ).
• اللفة المباشرة → اللفة - الإثير الملفوف الذي تتلقاه على منصتنا_بيلن تكون قابلة للتبادل بالأثريوم الأصلية لدينا_aتعطل تماثلية المسار الذي يمر من خلال جسور مختلفة ، على سبيل المثال ، إذا كان oru_أإذا تم تصريف الجسر، فإن الإيث المغلف الذي تم نقله إلى Orub سيتم إلغاؤه، بينما يظل الإيث الأصلي على Oru._بسيكون جيدا. تجزيء السيولة أمر غير مرغوب فيه، لذا ليس هذا ما يرغبه المستخدمون. في الواقع، يتم ربط المستخدمين مباشرة عبر مزودي السيولة. سيقدم لك شخص ما الإيث على بوابتنا._بواحتفظ بأموالك في أورو_أ. يمكنهم الانسحاب عبر الجسر الأصلي والانتظار ، لكنهم سيفرضون رسوما باهظة على المخاطر والتكلفة العالية لرأس المال الذي يتكبدونه.

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

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

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

يمكن أن تكون الرموز أيضًا قابلة للتبادل عبر سلسلات الجماعات كنتيجة لذلك. توصيل إث من r_أ→ r_ب أو ص_جيتي→ r_بيحرق ويطبع نفس الرمز. ليس من الأصول المفرّودة والمطبوعة. إنها إيث نيتيف. هذا ممكن لأن جميع الأصول تحت الضمان معًا ويتم تسويتها عبر الجسر الموحد. هذه نقطة ألم كبيرة ل L2s اليوم التي يجب معالجتها.

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

الدلائل المتشائمة

ترسل Aggchains تحديثات الحالة والبراهين الخاصة بها إلى العقد المخزنة في Agglayer التي تقوم بترتيبها ، وتوليد التزامات لجميع الرسائل ، وإنشاء إثباتات متكررة. ثم يقوم agglayer بإنشاء دليل aggreGate.iod zk واحد (والذي يسمونه "دليل متشائم") للاستقرار في Ethereum لجميع aggchains. نظرا لأن تجميع الإثبات هنا يطفئ التكاليف عبر العديد من السلاسل بشكل تعسفي ، فمن العملي من منظور التكلفة نشرها على Ethereum للتسوية السريعة في أسرع وقت ممكن. برنامج الدليل المتشائم مكتوب بكود الصدأ العادي ، باستخدام zkvm sp1 Succinct لسهولة التطوير والأداء العالي.

هذه الأدلة التشاؤمية تفرض:

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

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

تفاعل سريع وآمن بين الشبكات المختلفة

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

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

المصدر: براندان فارمر،سلاسل الكتل المجمعة

استعينا بمثالنا السابق:

• لدينا اثنين من التراكمات (ص_أو r_بي) مشاركة نفس المتسلسل الكسول والطبقة العصابية
• أقوم بتقديم حزمة متقاطعة السلاسل لحرق الإيثريوم بشكل متزامن_أ والنعناع eth على ص_b
• يقوم المنشئ الفائق ببناء كتلة لكلتا السلسلتين للقيام بذلك ، والتي يلتزم بها جهاز التسلسل المشترك
• عقد جسر سك العملة على R_b يمكن أن نعناع بتفاؤل ETH مشروطا بحالة r_أ(في هذه الحالة، تنفيذ حرق الإثير بنجاح)
• تتم تقديم هذه الكتل والبراهين إلى طبقة الاجتماع، والتي تثبت أن السلاسل الاثنين تصرفت بطريقة صحيحة (سواء بشكل مستقل أو مع احترام بعضها البعض) وأن الجسر المشترك تم استخدامه بأمان

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

هناك نقطتان يجب أن تؤخذ بعين الاعتبار فيما يتعلق بهذه الإعادة التنظيم:

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

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

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

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

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

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

الحياد الموثوق به

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

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

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

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

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

إثبات في الوقت الحقيقي

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

• لدينا اثنين من التراكمات (ص_aو ح ر_bمشاركة نفس المتسلسلة الكسولة
• أريد استخدام جسر الحرق والنعناع بين RA → RB الذي يحترق في وقت واحد على RA والنعناع على RB
• ينشئ Super Builder كتلة عبر السلسلة تتضمن حزمة من هذه المعاملات عبر السلسلة. داخل الكتل ، يتضمن المنشئ دليلا على انتقال الحالة الذي يتم تضمينه في مجموعة التحديثات الأخرى.

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

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

مصدر: جاستن دريك ، يثبت في الوقت الحقيقي

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

مصدر: جاستن دريك ، إثبات في الوقت الحقيقي

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

ملخص

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

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

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

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

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

تراكمات مستندة إلى إثريوم

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

سنستخدم الاختصارات التالية طوال الوقت:

• bl - الطبقة الأساسية
• BR - التراكمي القائم على
• preconfs - تأكيدات مسبقة

ما لم يذكر خلاف ذلك ، فإن الـ bl المشار إليه في النقاش هو Ethereum ، والـ brs هي Ethereum brs. ومع ذلك ، تنطبق المفاهيم الأساسية على نطاق واسع حيث يمكنك إطلاق brs في أي مكان.

لفائف مبنية على الفانيليا

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

ثم تم إعادة إحضار برس إلى الضوء في مارس 2023،حيث تم تعريفها على النحو التالي:

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

يجب أن يقدموا الفوائد التالية:

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

على وجه التحديد، تحصل على أمان الوقت الحقيقي للإيثيريوم:

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

أن تكون عبارة عن لفة مبنية على التصميم المنطقي بمجرد اختيار طبقة أساسية:

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

في أبسط صورها ، يمكن لبرس بالتأكيد تحقيق أهداف التصميم المذكورة أعلاه. إذا لم يقم ال Rollup بتنفيذ مسلسله الخاص ، فإن المقترح الحالي لإثيريوم هو الذي يقرر ضم كل 12 ثانية (وقت الفتحة في إثيريوم).

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

• مستخدمو Rollup لا يرغبون في الانتظار لمدة 12 ثانية أو أكثر من أجل كتل Ethereum - preconfs سريعة.
• التدقيقات السابقة الآمنة - في بعض الأحيان تتجرع قطع الإيثيريوم، لذلك يضطر المستخدمون إلى الانتظار لفترة أطول للحصول على الأمان، وهو الأمر الذي لا يعجب المستخدمين مرة أخرى. يمكن للمراقبون أن يقدموا تدقيقات سابقة لا تعتمد على قطع الإيثيريوم غير المؤكدة وبالتالي لا تحتاج إلى تتجرع حتى لو تعرض الإيثيريوم نفسه لتتجرع قصيرة.
• الإرسال الدفعي الفعال - يمكن للمتسلسلات دفع الكثير من البيانات وضغطها ونشرها بشكل دوري إلى البي اللوجي بطريقة محسنة من حيث التكلفة (على سبيل المثال، ضمان استخدام الكتلة الكامل).

تراص اللفات المستندة + preconfs

هل يمكننا أن نحصل على كعكتنا ونأكلها أيضًا؟بريكونفس المستندة.

سنشرح الحدس الذي يقوم على أساس preconfs هنا بشكل موجز نسبياً حتى نتمكن من مقارنة brs + preconfs مقابل تجميعات البيانات التقليدية. في وقت لاحق، سنعود لتحليل preconfs بمزيد من التفصيل بشكل عام (أي br preconfs و bl preconfs على معاملات ethereum l1).

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

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

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

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

على أي حال، النقطة المهمة هي أن أي تأكيد مسبق أسرع من اتفاقية إثريوم (12 ثانية) يتطلب طرفًا ثالثًا موثوقًا (TTP). سواء كان TTP العارض المعاد ضبطه أو العارض المعاد ضبطه، ...مزاد التنفيذ الفائز ، deleGate.iod Gate.ioway ، أو أي شيء آخر - لا يمكنه بشكل أساسي توفير أمان الإيثريوم في الوقت الفعلي. سواء كانت Coinbase تمنحك "preconf القائم" كمقترح Ethereum أو "preconf التقليدي" كتسلسل تراكمي - فأنت تثق في CoinBase. يمكنهم بالمثل وضع رابطة لبعض ETH ، ولكن في كلتا الحالتين هذا مستقل عن أمان إجماع Ethereum.

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

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

لبرس - تتيح ttps preconfs بسرعة، وتوفر البي الأمان النهائي.

نون بنيت لفات + سقوط قائم على الأساس

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

كما لاحظت فيهل اللفائف ترث الأمان؟:

تمتلك الـ rollups القدرة على عرض قواعد التأكيد بخصائص أمان مكافئة لسلسلة المضيف الخاصة بها. يمكنها الحصول على هذه الخصائص بأفضل حالة بسرعة توافق سلسلة المضيف الخاصة بها (وعملياً غالباً ما تكون أبطأ قليلاً اعتمادًا على مدى تكرار rollup على سلسلة المضيف).

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

لاحظ أن الوقت إلى الأمان النهائيهو المتغير الرئيسي لتحسين هنا:

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

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

في هذه الروح، لدى Sovereign labs تصميمالذي يقوم بما يلي:

• تسلسل مرخص - تضع اللفات سلسلة مصرح بها يتم معالجة معاملاتها فور إدراجها في اللفة. نظرًا لأن لديهم قفل كتابة على حالة اللفة ، يمكنهم توفير تأكيدات مسبقة موثوقة بشكل أسرع من وقت الكتلة في اللفة.
• التسلسل القائم - يمكن للمستخدمين أيضا إرسال المعاملات مباشرة إلى BL الخاص بهم ، ولكن تتم معالجتها بتأخير كتلة n (حيث تكون n صغيرة بما فيه الكفاية). هذا يقلل بشكل كبير من "وقت الأمان النهائي" ، وفي الواقع يطلقون على التصميم "التسلسل القائم مع التأكيدات الناعمة" بسبب ذلك! (لاحظ أن تعريف BRS هذا يتعارض مع التعريف الذي قدمناه سابقا ، أي أن مقترح bl يجب أن يكون له الحق في تسلسل br أو أن يكون deleGate.iod من قبلهم.)

بالنسبة لغير BRS - توفر ttps تأكيدات سريعة، والشبكة البيانية توفر أمانًا نهائيًا.

لماذا؟

كما نرى ، فإن كلا المسارين الموصوفين أعلاه ينتجان نفس النتيجة الفعالة:

هذه brs مع preconfs لم تعد توفر بساطة أو أمانًا في الوقت الحقيقي للإيثيريوم. إذا ما هو الهدف من كل هذا الآن؟ لماذا لا نقوم بتشديد الإجراءات الاحتياطية على ال rollups "التقليدية"؟ ما هو حتى "based rollup" في هذا الوقت؟

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

1) الفنية (التزامات المقترحة) - لا يوجد طريقة لتجاوز هذا - إذا كنت تريد التزاما موثوقًا بترتيب كتلة Ethereum ، فيجب أن يأتي ذلك من المحققين الفنية لـ Ethereum.تعزيز MEV++هو مثال واحد على تطبيق وهمي يمكن أن يندرج تحت هذا الفراغ.

2) الاجتماعية - أرى محاذاة Ethereum كحالة الاستخدام الأساسية لمعظم تطبيقات إعادة الاستعادة اليوم ، وليس تجميع الأمن الاقتصادي أو اللامركزية. انها تحصل على القول "انظر، نحن مشروع Ethereum!” إنه نفس السبب تمامًا لماذا تستمر السلاسل في تسمية أنفسها بأنها Ethereum L2sبغض النظر عن التنظيم.

يمكننا تحديث هذا في سياق السؤال ما هي قيمة "BR + preconfs" على "مجموعة التحديثات التقليدية + الاحتياطي السريع"؟

1) التقنية (التزامات المقترح) - تتمتع Ethereum BRs مع preconfs بفائدة تقنية أساسية واحدة - يمكنهم الحصول على التزام موثوق به من مقترح Ethereum الحالي فيما يتعلق بتضمين وترتيب محتويات كتلة Ethereum. من المحتمل أن يكون هذا ذا قيمة لنفس الأسباب الدقيقة التي قد نرغب في الحصول على مجموعة من عمليات التجميع لمشاركة جهاز التسلسل. إذا كان مقترح BL هو أيضا مقترح BR (أي جهاز التسلسل) ، فيمكنه توفير نفس ضمانات التضمين الذري مع BL كما يمكنك الحصول عليها بين أي تراكمات تشترك في جهاز التسلسل. لديهم احتكار على كلتا السلسلتين. الآن ، ما مدى قيمة هذا؟ سنعود إلى ذلك بعد قليل.

2) الاجتماعية (التوافق / الحياد الموثوق به) - أحبها أو اكرهها،محاذاة الإيثريوم هي نقطة بيع لتكون Br. سأكون صادقا ، لا أعرف الكثير عن التايكو بخلاف "إنهم رجال BR" ، وربما لن أعرف من هم إذا لم يكونوا رجال BR. الجميع يريد بعض التسويق المشترك الجيد. هناك قيمة لكونك المحرك الأول هنا ، لكنني أظن أن هذه ليست دعامة قيمة دائمة ولا تنتقل إلى العديد من BRs المحتملين في المستقبل. وبالمثل ، سمعنا جميعا عن أول حفنة من AVSS ، ولكن هل يمكنك تسمية جميع الأنواع الحالية؟ لا أستطيع.

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

يعتبر هذا الحياد الموثوق به أكثر قيمة على الأرجح بالنسبة لمطوري الروابط الجانبية الذين يحاولون جذب مستخدمي النظام الإيكولوجي المتقاطع (على سبيل المثال ، التطبيقات ذات البنية التحتية الأساسية مثل ens). قد يكونوا مترددين في استخدام متتابع optimism إذا كان سيبعد مستخدمي arbitrum ، أو العكس بالعكس.

سنغطي كل من هذه بالتفصيل أدناه.

الحياد الموثوق به

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

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

هناك عدة أسئلة مفتوحة بخصوص الضمان هنا:

حجم الضمان

تفترض التصميمات الأولية أن يضع المقترحون بشكل شخصي كمية عالية جدًا من الضمانات بحوالي 1000 إيثر. المشكلة في الأمر هي أن المقترح في الأساس يمكنه دائمًا التراجع عن وعده لـ Gate.io وبناء كتلة بنفسه، متناقضًا فيما يتعلق بـ preconfs. يمكن أن يكون ذلك قيّمًا للغاية، و 1000 إيثر يكفي بسهولة للأجور الأعلى التي تمت المرور عبر mev-boost منذ بدايته. العيب في ذلك هو أن هذا بالطبع يخلق عائقًا عاليًا للمقترحين الأصغر حجمًا، بينما يمكن للمقترحين الأكبر (مثل coinbase) وضع 1000 إيثر بشكل أكثر معقولية وكسب مكافآت على جميع حصصهم> 13% من إجمالي الإيثيريوم المرهون) لأن المسجلين يمكنهم وضع كفالة واحدة لجميع المحققين الخاصة بهم. هناك أفكار أخرى للسماح للمقترحين بسندات أصغر بكثير، على الرغم من ذلك، فإنها تأتي بتنازلات. الفضاء التصميم هنا غير مؤكد.

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

المصدر:بارنابي مونوت ، من ميف-بوست إلى إيبس إلى إيبس

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

نوع الضمان

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

منصة

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

سيكون الاعتماد على معايير الخير العام ضروريًا لجعل تصاميم القبلية المعتمدة محايدة بشكل معقول.

preconfirmations

التضمين مقابل المؤتمرات المسبقة للدولة

سنغطي الآن preconfs بمزيد من التفاصيل. بينما تحدثنا عن نوع معين من preconf في وقت سابق (preconfs br على الحالة)، يجب أن نلاحظ أنها مفهوم عام تمامًا. يمكنك تقديم preconfs على المعاملات bl بالإضافة إلى brs، ويمكنك تقديم قوة مختلفة من preconfs:

• الاحتواء الأولي - التزام أضعف بأنه سيتم تضمين المعاملة في نهاية المطاف في السلسلة الرئيسية.
• state preconfs - أقوى التزام بأن المعاملة ستتم إضافتها في وقت لاحق وضمان الحالة الناتجة.

هذا الأخير (State Preconfs) هو بالطبع ما يريد المستخدمون أن تظهره محافظهم لهم:

لقد قمت بتبديل 1 ETH مقابل 4000 دولار أمريكي ودفعت 0.0001 ETH كرسوم

لا تضم الاجتماعات السابقة:

محاولتي للمعاملة الخاصة بتبديل 1 إيثر مقابل 4000 دولار من USDC ودفع ما يصل إلى 0.0001 إيثر في الرسوم ستهبط في النهاية على السلسلة الرئيسية، ولكن ربما تنجح، ربما تفشل، سنرى

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

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

تسعيرة مسبقة

تمييز كبير آخر نحتاج إلى إجرائه هو نوع الدولة التي يلمسها هذه المراجعات المسبقة:

• حالة غير مثيرة للجدل - لا يحتاج أي شخص آخر إلى الوصول إلى هذه الحالة (على سبيل المثال ، تريد أليس نقل USDC إلى BOB)
• حالة مثيرة للجدل - يرغب الآخرون في الوصول إلى هذه الحالة (على سبيل المثال ، الفروقات في بركة eth / usdc amm)

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

هذا بسيط بما فيه الكفاية عندما يكون الخسارة من MEV ~0 (على سبيل المثال ، كما في تحويل USDC). في هذ scenar ، يمكن أن يكون معقولاً تحصيل رسوم ثابتة زهي. لكن لدينا مشكلة كبيرة - كيف نسعر preconfs على الحالة الجدلية؟ يبدو أن سعر preconfs مقدمًا مقابل في الوقت المناسب سيدفع بأقل. كل شيء متساوٍ ، فإنه الأكثر ربحية للباني الانتظار حتى اللحظة الأخيرة الممكنة لالتقاط وتسعير MEV بدقة.

لنفترض، على أية حال، أن هناك طلب كافٍ من المستخدمين للحصول على بيانات مُعدة بسرعة بخصوص الحالة المثيرة للجدل (مع النظر في الباحثين المتطورين ومستخدمي العاديين)، بحيث ستكون هناك أحيانًا سعر تسوية مفيد للجميع. الآن، كيف يمكن تسعير بيانات مُعدة لعملية على قطعة من الحالة المثيرة للجدل التي يمكنك تضمينها في أي وقت خلال الـ 12 ثانية المقبلة، مع التخلي عن فرص أكثر ربحية لن تكون ممكنة بعد الآن؟

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

لقد افترضنا بالفعل أن Gate.ioway والريلي سوف يدمجان. إذا كانوا بحاجة إلى تحديد أسعار البريكونفس بشكل مستمر ، فسيدمجون أيضًا مع المنشئ. كما قبلنا أن USC ستسرع عملية الدمج بين المنشئ والمثبت. يبدو أنه أيضًا،عطاءات التنفيذسيقوم ببيع حقوق المقترح مباشرة للجهات المتقدمة (على الأرجح البنائين) القادرة على تحديد السعر.

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

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

مشكلة التبادل العادل

هناك مشكلة تبادل عادلة مع preconfs حيث لا يتم تحفيز Gate.ioway بشكل مباشر لتحرير preconf.

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

• لدى Gate.ioway الحالي احتكار لمدة 12 ثانية
• يقدم المستخدم طلب معاملة مسبقة التأكيد في بداية الفتحة (t = 0)
• ينتظر Gate.ioway حتى t = 11.5 لتحرير جميع التركيبات المسبقة التي قاموا بها أثناء فتحتهم ، تاركين مخزنا مؤقتا يبلغ 500 مللي ثانية لإدخالهم جميعا مع كتلتهم. في ذلك الوقت ، يمكنهم تحديد أي المؤتمرات المسبقة يجب تضمينها إذا كانت مربحة ، وأيها يجب استبعادها.

في هذ Scenario الحالة، يمكن للمستخدم أن ينتهي بدفع تكلفة preconf حتى لو لم يتلقوها فعليًا حتى نهاية الفتحة. قد يقرر Gate.ioway أيضًا إسقاطها في نهاية الفتحة إذا قرروا أنه لم يكن من الربح تضمينها. هذا الامتناع من Gate.ioway ليس خطأً يمكن تحديده بشكل موضوعي (ولكن يمكن أن يعزى إلى الذات.

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

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

الطبقة الأساسية l1 معايير مسبقة

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

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

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

كل فرق preconf هذه لديها طموحات أكبر (على سبيل المثال ، المؤتمرات المسبقة للولاية ، أو مزادات الكتلة الجزئية ، أو مزادات الفتحات أو الفتحات الجزئية) ، فما الذي يعيقها؟

• المساءلية - يجب أن يكون من السهل إثبات انتهاكات الالتزام على السلسلة للقصاصة الموضوعية. فمن السهل نسبياً إثبات إدراج المعاملة، ولكن ليس من الواضح كيفية فرض التزامات أخرى مثل مزادات الفتحة.
• متطلبات رأس المال - توفير التزامات تعسفية يعني أن قيمة خرق الالتزام يمكن أن تكون عالية بشكل تعسفي. من المحتمل أن ينتهي الأمر ب Gate.ioways إلى الحاجة إلى مشاركة مبالغ ضخمة (على سبيل المثال ، الآلاف من eth) لتوفير هذه. قد ينتهي الأمر بتجميع هذه الكيانات ، مما يفيد أكبر الكيانات (على سبيل المثال ، الشركات التجارية الكبيرة أو Coinbase) وترك الكيانات الأصغر.
• التسعير - هناك الكثير من الأسئلة المفتوحة حول كيفية تسعير شيء مثل تجهيزات الحالة المستمرة المبثوثة حتى لو قررنا أنها ممكنة وقيمة.
• المشاركة في الشبكة - هذه ربما هي النقطة الأكثر أهمية وأساسية. كما ذكرنا، يمكن لمقترح الحالي الوحيد الذي لديه قفل الكتابة على الحالة تقديم التزامات مثل مسبقات الحالة. من النظرية، يمكن لـ 100٪ من مقترحي الأفكار الانضمام إلى هذا النظام والتماثل معه. في الواقع، هذا لن يحدث.

ميف-بوست، منتج أبسط بسجل سنوات من الخبرة الذي يكون مربحًا للغاية في التشغيل، يحتوي>92% المشاركةللسياق (ربما حتى أعلى قليلاً لأن هذا لا يأخذ في الاعتبارأدنى عرض). من المؤكد أن خدمة preconf الجديدة ستحصل على معدل مشاركة أقل بكثير. ولكن حتى لو كان بإمكانه الوصول إلى نطاق ~ 90٪ ، فإن هذا لا يبدو منتجا مفيدا للمستخدمين العاديين. لا يمكنك إخبار المستخدمين بنسبة 10٪ من الوقت "أوه آسف لا توجد مؤتمرات مسبقة متاحة الآن ، تحقق مرة أخرى قليلا".

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

مؤتمرات مسبقة للتراكم القائم على l2

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

بشكل مهم، هذه preconfs br هي preconfs حالة وليس فقط preconfs الاندماج. هذا ممكن لأن brs يختارون تصميمًا حيث يمنحون المسلسل الدوار للمقترحين bl الامتياز الحصري ليكونوا Gate.ioways.

اليوم ، يعمل أحد مدققي Ethereum كمقترح لكل فتحة ، ويعرف جدول Proposer دائما بالحقبة الحالية والحقبة التالية. الحقبة هي 32 فتحة ، لذلك نحن نعرف دائما 32-64 مقترحا في وقت معين. يعمل التصميم من خلال منح جهاز التسلسل النشط التالي (أي جهاز التسلسل التالي في التطلع إلى الأمام) صلاحيات احتكارية لتسلسل المعاملات ل BRS التي اختارت نظام preconf هذا. يجب أن توقع Gate.ioways لتعزيز حالة سلاسل br.

لاحظ أن كل مقترح (حتى أولئك الذين لم يختاروا أن يكونوا Gate.ioway) له الحق ولكن ليس الالتزام بتضمين المعاملات التي تم منحها مسبقا من قبل المتسابقين (أي أولئك المقترحين الذين اختاروا أن يكونوا Gate.ioway). قد يعملون كمتضمن طالما أن لديهم قائمة كاملة بالمعاملات التي تم تأكيدها مسبقا حتى ذلك الوقت (يمكن لجهاز التسلسل إنشاء BL blob يحتوي على معاملات BR والقيل والقال).

المصدر:تسلسل إيثريوم، جاستن دريك

يتم عملية تدفق المعاملات على النحو التالي:

1. يقوم المستخدم بتقديم معاملته إلى المرتب المقبل في البحث المسبق (مقترح فتحة n+1 في الصورة أدناه)
2. يقدم المتسلسل فوراً تأكيدًا مسبقًا للحالة الناتجة (على سبيل المثال، قام المستخدم بتبديل 1 إيثر إلى 4000 دولار أمريكي في السي ودفع 0.0001 إيثر كرسوم)
3. في هذه المرحلة، يمكن لأي مضمن أن يتضمن المعاملة المتسلسلة (يفعل ذلك المقترح للفتحة n في الصورة أدناه)

مصدر: تسلسل إيثريوم، جستن دريك

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

لتبسيط التفسيرات أعلاه، افترضنا فقط أن المقترح L1 سيؤدي هذا الدور قبل المؤتمر. كما هو موضح في وقت سابق، من غير المرجح أن يكون هذا الحال. سيتطلب كيان متطور تسعير الاجتماعات السابقة، وتشغيل العقد الكامل لجميع BRs ، وحماية DOS وعرض نطاق ترددهم الكافي لجميع معاملات BR ، الخ. يريد Ethereum الحفاظ على المقومين بشكل غير متطور جدًا ، لذلك من المحتمل أن يفوض المقترحون الاجتماعات السابقة إلى كيان آخر بنفس الطريقة التي يفوضون بها إنتاج كتلة L1 الكاملة عن طريق MEV-Boost اليوم.

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

مصدر: التسلسل القائم على الأساس، جاستن دريك

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

لفات ايثيريوم - كيف سيكون اعتمادها؟

مع وجود خلفية كافية الآن - هل يجب أن تستند مجموعات Ethereum؟ هناك بالفعل سؤالان مضمن هنا:

1. هل يجب على العديد من Ethereum Rollups مشاركة مسلسل؟
2. إذا كان الجواب نعم، هل يجب أن يكون متسلسلاً بناءً على بروتوكول إثيريوم وهياكل الـ mev المحيطة؟

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

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

هل يجب أن يكون هذا المتسلسل المشترك مبني على إثيريوم؟

التزامات المقترح (الفنية)

لست أرى حجة تقنية قوية لاستخدام متتابع قائم على إيثريوم. أي توافق بين brs و ethereum l1 سيكون محدودًا للغاية بسبب عدم القدرة على تنفيذ موثوق على الحالة l1 (أي عدم وجود قفل كتابة ثابت على حالة l1)، وأوقات الكتل الطويلة (12 ثانية)، وحقيقة أن معاملات br التي ترغب في التفاعل مع l1 ثم ستضطر لإعادة التنظيم بجانبها. ليس هناك وجبة مجانية هنا. هذا لا يفتح أي منتجات ذات قيمة موجهة للمستخدم مقابل أي متتابع مشترك خارجي آخر.

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

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

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

اجتماعي (حياد موثوق)

أرى حجة اجتماعية صحيحة لمتسلسلة مبنية على إثيريوم.

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

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

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

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

لفات سريعة المبنية

طبقات القاعدة السريعة

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

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

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

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

لذلك لماذا لا نستخدم بروكلين سريعًا للتوجيهات؟

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

الطبقات المتعددة قد ماتت، لتحيا طبقات التسلسل!

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

هذا التركيب هو واحد جميل لأنه يكمل بعضه البعض بشكل واضح - حيث توفر Astria كل البنية التحتية للتسلسل ويوفر Celestia التحقق من الثقة بشكل مصغر.أخذ عينات توافر البيانات (DAS).

ومع ذلك، يمكن استخدام Astria بطريقة مماثلة لتتابع Rollup الذي يكون أصليًا لـ Ethereum أو Bitcoin أو Solana أو أي شيء آخر تريده. على سبيل المثال، يمكن إعدادها حتى تستخدم كـ preconfer لـ Ethereum "brs مع preconfs" (على سبيل المثال، بدلاً من Gate.ioway مركزيًا، حيث أن المتتابع الكسول يعد ببساطة إعادة توجيه للحوافز وغير مركزي).

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

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

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

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

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

الطبقة الأساسية السريعة مقابل البطيء + مراجعات مسبقة

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

عندما يكون BL الخاص بك سريعًا ، فلا يحتاج BR الخاص بك إلى إعدادات مسبقة لأنه يحصل فقط على تأكيدات سريعة بسهولة! ثم يحصل ال Rollup الخاص بك على الأمان الفعلي في الوقت الحقيقي لـ BL الخاص بك ، على عكس BRs + preconfs التي تفقد هذا بالضرورة.

BRS بدون تأكيدات مسبقة هي في الواقع الطريقة الأكثر منطقية لبناء Rollup. هذا هو السبب في أن جميع Rollups اليوم بدأت من هناك:

من الواضح أن BL مع الكتل السريعة يعمل على إصلاح معظم مشاكلنا في "التراكمات القائمة + المؤتمرات المسبقة". يتم بناء أجهزة التسلسل المشتركة بشكل طبيعي أكثر من نهج المبادئ الأولى "مرحبا ، يريد مطورو التطبيقات فقط إطلاق سلسلة سريعة وموثوقة ولامركزية - كيف أعطيهم ذلك؟" تؤدي محاولة إضافة preconfs بعد الحقيقة إلى طبقة أساسية أبطأ مثل Ethereum إلى التعقيدات التي وصفناها أعلاه.

نحن جميعًا نبني نفس الشيء

التعددية لا مفر منها

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

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

هل يعني ethereum + preconfs → solana؟

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

في هذه الرؤية ، لدينا مجموعة من BRs هذه باستخدام جهاز التسلسل القائم على Ethereum. تقوم Gate.ioways باستمرار ببث العروض المسبقة الموعودة بمقدم العرض (أي بدون أي وزن إجماع) للمستخدمين في زمن انتقال منخفض ، ثم يلتزم مقترحو الإيثريوم بهم في كتلة كاملة من حين لآخر. قد يبدو هذا مألوفا لأن هذا إلى حد كبير ما وصفناه ل Solana سابقا مع Shred Streaming!

إذا، هل هذا مجرد سولانا أكثر تعقيدا؟ الفارق الكبير هنا هو في أوقات الفتحة:

يحاول إثريوم إضافة هذا إلى سلسلة بطيئة يعرض بوضوح قضايا النظرة الأولى:

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

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

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

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

source: البيانات دائماً

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

على سبيل المثال، دعنا نقول أنك أسرع بـ 100 مللي ثانية من الجميع الآخرين

إذا كان لديك فتحات 1s، يمكنك كسب 10% أكثر من الجميع

إذا كان لديك فتحات بمقدار 10s، يمكنك كسب 1% أكثر من الجميع

- جون شاربونو (@jon_charb4 يونيو 2024

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

أجد شخصياً أنه من الصعب تجاهل أهمية توقيت الألعاب هنا:

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

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

حدثت مؤخرًا في زوبيرلين، وربما ليس من المفاجئ أن الجميع كان يتحدث عن تجمعات مسبقة والتراكمات الأساسية. وكان ذلك كله حقًا رائعًا. ولكنني شخصيًا وجدت محادثة فيتاليكعلىقوائم الاحتواء بمعدل بت واحد لكل موثقوحديث بارنابي عنتحميل المقترح المنفذ بدلاً من ذلك (من mev-boost إلى epbs إلى aps)أن يكون الأكثر أهمية لمستقبل الإيثيريوم.

مصدر: بارنابي مونوت, من mev-boost إلى epbs إلى aps

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

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

المصدر: إثبات الحوكمة

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

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

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

استنتاج

نحن جميعا نبني نفس الشيء.

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

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

أيضًا ، فمن الصعب جدًا التفكير في بعض هذه الأشياء.كما وضح فيتاليك:

ملاحظة واحدة للحذر التي لدي لـ APS هي أنني أعتقد من منظور تقني بحت أنها خفيفة جدًا ونحن قادرون تمامًا على تنفيذها بفرصة ضئيلة جدًا للخطأ التقني... ولكن من منظور اقتصادي هناك فرص أكثر لحدوث أخطاء...

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

ولكن ليس APS مشابهًا لذلك، أليس كذلك؟ والسؤال هو هل ستؤدي APS إلى Citadell أو Jane Street أو Justin Sun أو أي شخص آخر إلى إنتاج 1٪ من جميع كتل Ethereum أم 99٪ من الأمر صعب جدًا، وربما من المستحيل أن نكتشف ذلك من المبادئ الأولى.

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

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

تنويه:

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