1. نظام البرهان والبرهان المتفائل

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

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

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

1.1 حالة نظام البرهان - ZK و OP

كان من المعتقد في وقت ما أن نظام البرهان zk سيصبح سائدًا قريبًا، مع نظام البرهان التفاؤلي يفقد أرضية. من المتوقع عمومًا أن يوفر نظام البرهان zk تكلفة أقل واتساعًا أسرع للرول أبس. تم رصد تقدمات كبيرة فيما يتعلق بإنتاج البراهين، مع إجراء تجارب على بناء zkVMs متعددة الأغراض استنادًا إلى MIPS، RISC-V، و Wasm. وتشمل هذه المشاريع مثل ZKM، RiscZero، Succint Labs، و Fluent. على الرغم من الفوائد الواضحة للرول أبس zk، فإن التحديات المتعلقة بتطوير إصدارات فعالة من حيث التكلفة وآمنة تعتبر كبيرة. يشكل تحديًا أيضًا تحديث VMs مثل EVM، حيث يصعب دمج ميزات جديدة دون التسبب في تغييرات تكسيرية.

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

المصدر: البلوكتشينات (L2) | الأسواق | محطة الرموز

1.2 ما ينتظر نظام البرهان المتفائل في المستقبل؟

تجري أبحاث وتطورات نشطة لتحسين نظام البرهان المتفائل ويتم ذلك في ثلاث نقاط رئيسية مثلما هو مبين أدناه:

1. تخفيض التكلفة
2. تمرير التسلسل، والتحدي وعملية الإنهاء متمركزة
3. تقليل النهوض النهائي الليّن والصلب

تم بذل جهود كبيرة في جميع النطاقات الثلاثة، وبعض الأمثلة تشمل الترقية الأخيرة لـ Dencun التي تضمنت EIP-4844، وضغط البيانات المحسن، وتطوير نظام البرهان التفاعلي. كان لـ Arbitrum تحديثات جديدة لهم

قبل الانغماس في استكشاف التطورات الأخيرة في "الجزء4"، من الضروري أن يكون لدينا فهم شامل للمفاهيم الموجودة والوضع الحالي. للبدء، يجب أن نلقي نظرة على تطور المجال في "2. تطور - تاريخ نظام البرهان المتفائل"، وننغمس في الوضع الحالي لمشاريع البرهان المتفائلة في "3. الوضع الحالي".

2. التطوير - تاريخ نظام البرهان التفاؤلي

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

2.1 الماضي - العودة إلى التاريخ

تم اقتراح البكرات التفاؤلية لأول مرة من قبل الباحث في إيثريومجون آدلر في عام 2019 كحل تحجيم طبقة 2 ل Ethereum. الفكرة الأساسية وراء عمليات التجميع المتفائلة هي نقل الحوسبة وتخزين البيانات من شبكة Ethereum الرئيسية إلى سلسلة منفصلة من الطبقة 2 ، مع الاستمرار في وراثة ضمانات أمان Ethereum. كان الدافع الأساسي لتطوير Optimistic Rollups هو الازدحام ورسوم المعاملات المرتفعة على شبكة Ethereum الرئيسية. مع زيادة اعتماد بروتوكولات DeFi و NFTs ، واجهت Ethereum مشكلات قابلية التوسع التي أعاقت تجربة المستخدم والكفاءة الاقتصادية.

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

المصدر: قيمة القرض العاملية لأربيتروم بالدولار الأمريكي

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

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

2.2 الحالي - تحسين ولكن يواجه تحديات

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

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

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

3. المناظر الحالية

لنفحص الوضع الحالي للرول ابس، مركزين على المشاريع العاملة بنظام البرهان المتفائل وتطوراتها.

في الوقت الحالي، تعمل كيانان - Arbitrum و Optimism - في المقام الأول على تعزيز نظام البرهان التفاؤلي. تعمل مشاريع أخرى مثل Initia و Dymension و Rollkit على تطوير الأطر لبيئتها البيانية.

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

3.1 Arbitrum - Multi-Round Proof and BoLD

3.1.1 دليل متعدد الجولات

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

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

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

الخطوات كما يلي:

1. لديهما الفاحصان خلاف حول حالة Arbitrum.
2. تقليل النزاع تدريجياً إلى خطوة حسابية واحدة فقط.
3. يتم تشغيل هذه الخطوة على Layer 1 لـ Ethereum للتحقق من صحة العارض.

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

3.1.2 Arbitrum BoLD

مصدر: مقدمة لطيفة: BOLD | Arbitrum Docs

تم تصميم BoLD (Bounded Liquidity Delay) كبروتوكول جديد لحل النزاعات مُصمم خصيصًا لـ Optimistic Rollups على سلاسل Arbitrum، بهدف تسهيل التحقق بدون إذن. يُخفف هذا الآلية من المخاطر المرتبطة بهجمات التأخير عن طريق ضمان حل النزاعات خلال نافذة زمنية محددة مُسبقًا.

تقدم BoLD عدة ميزات رئيسية تعتبر أساسية لوظائفها. أولاً، تقدم التحقق بدون إذن، مما يسمح لأي طرف نزيه بالتحقق وربط أمواله لنشر تأكيدات الحالة الفرعية الصحيحة L2. تتيح هذه الميزة للمحققين النزهاء تحدي والفوز في النزاعات ضد الجهات الخبيثة. ثانيًا، تضمن BoLD أن النزاعات ستُحل خلال نافذة زمنية ثابتة، مُحددة حاليًا بفترة تحدي واحدة (تقريبًا 6.4 أيام) لـ Arbitrum One و Nova. بالإضافة إلى ذلك، الوقت الإجمالي الأقصى لحل النزاعات يشمل ما يصل إلى فترتي تحدي بالإضافة إلى فترة سماح لمدة يومين لتدخل مجلس الأمن الأمني. أخيرًا، يدعم BoLD تقدم Arbitrum إلى تطور Stage 2 rollup، مما يضمن أن أي شخص يمكنه التحقق من الحالة الفرعية L2 وتقديم أدلة الاحتيال إلى Ethereum، مما يعزز اللامركزية والأمان في المنصة.

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

3.2 التفاؤل - كانون، وحدة التحقق من الأخطاء

المصدر: VM المضمون - مدفع | توثيق التفاؤل

نظام البرهان في OP-Stack مصمم لتحدي وتخفيف الأنشطة الخبيثة داخل الشبكة. سيكون الـ Fault Proof VM القادم هو التحسين الرئيسي. يتكون هذا النظام من ثلاث مكونات أساسية: برنامج البرهان (FPP)، آلة البرهان الافتراضية (FPVM)، وبروتوكول لعبة النزاع. يقوم الـ FPP بفحص تحويل حالة اللفة للتحقق من إخراج L2 من المدخلات L1، وفرز أي نزاعات على المخرجات على L1. تتيح هذه البنية المعمارية القابلة للتوسيع تطوير ونشر أنظمة برهان متعددة وألعاب نزاع فريدة بشكل مستقل، مما يعزز بشكل كبير من مرونة النظام وأمانه.

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

3.3 Initia - تم تنصيب OP-Stack، OPinit

المصدر: OPinit Stack | Initia Docs

إن إيتيا هو سلسلة كتل Comsos L1، حيث يتم بناء نظام بكتل موحّد ومتداخل. يشبه بشكل وثيق نظام بكتل في إيثيريوم، ولكنه مصمم من الأساس لنظام بكتل. يقوم محققو إيتيا L1 بتشغيل المتسلسلون لنظام البكتل والتسوية القائمة على الإثبات التفاؤلي مضمنة في سلسلة الكتل L1. دعنا نرى كيف تعمل البكتل، التي تم بناؤها بواسطة OPinit Stack الذي يدعم EVM، WasmVM، MoveVM مع التوافق الأصلي بواسطة IBC.

تم تصميم كومة OPinit لإطلاق Minitia L2 على رأس سلسلة تكوين Initia L1. تم بناء هذه الكومة بشكل خاص باستخدام CosmosSDK، الذي يساعد في بناء Optimistic Rollups الخالية من vm، وهي مستندة تمامًا إلى واجهة Bedrock لـ Optimism. من خلال الاستفادة من نموذج حوكمة Initia L1، يتعامل بكفاءة مع النزاعات الخاصة بدليل الاحتيال، مما يضمن التحقق الثابت للمعاملات وحل النزاعات بشكلموثوق. يحدث التحدي مثل نظام التحدي في Bedrock، حيث يمكن للمتحدين ذوي الأذونات مسح الناتج غير المنتهي. أيضًا، من خلال اقتراح L1، يمكن تغيير مُقدم الناتج.

ضروري لتكوين OPinit هما وحدتان أساسيتان: OPHost و OPChild:

1. تم تصميم وحدة OPHost لعمليات الطبقة 1 داخل نظام Initia، مستفيدة من وظائف Cosmos SDK. تتضمن أنواع رسائل مختلفة وأساليب معالجة RPC لتيسير الأنشطة الأساسية مثل تقديم الدُفعات، إنشاء الجسور، مقترحات بيانات الإخراج، وحذف الإخراج.
2. يتمحور وحدة OPChild على العمليات من الطبقة 2، وتوفير آليات لدعم تحويلات الرمز الرمزي، وإدارة حوض الرسوم. كما تتضمن أنواع رسائل محددة ومعالجي RPC لتنفيذ الرسائل، وإنهاء الودائع الرمزية، وبدء سحب الرموز من L2 إلى L1، مما يضمن وظائف L2 ميسرة ضمن بنية Initia.

3.4 Taiko - نظام متعدد البروف

المصدر: نظرة عامة على بروتوكول تايكو - مختبرات تايكو

تايكو هو رول اب متفائل بشكل افتراضي، من خلال نظام تحقيق متعدد الأدلة. يجمع هذا النظام بين نهج متفائل مع استخدام ZK-proofs.

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

بشكل مثير للاهتمام، يقدر Taiko أن حوالي 1% من الكتل ستتطلب ZK-proof، مما يساعد على تقليل العبء الحسابي مع ضمانات الصحة. لتعزيز صمودها، يدعم Taiko العديد من واجهات الإثبات مثل PLONK، Halo2، و SGX لحماية ضد الثغرات أو الضعف المحتملة. يسمح هذا النهج لتطبيقات اللامركزية بتعيين افتراضات الثقة الخاصة بها ومستويات الأمان، مما يظهر إسهام Taiko في قابلية توسع البلوكتشين وأمانه.

3.5 أخرى - Dymension و Rollkit

3.5.1 Dymension

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

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

فترة النزاع الحالية على mainnet لـ Dymension مضبوطة لحوالي 120،000 كتلة. نظرًا لأن الكتلة الحالية تنتج كل 6 ثوانٍ، فإن الاستقرار حوالي 8 أيام.

3.5.2 Rollkit

مصدر: rollkit/specs/lazy-adr/adr-009-state-fraud-proofs.md في الرئيسية · rollkit/rollkit

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

4. التطورات القادمة: المشاكل والحلول

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

في هذا القسم، دعونا نفحص بعض هذه المشاكل الرئيسية والحلول المحتملة:

1. تمركز العمل
2. تكاليف تشغيلية مرتفعة
3. الانتهاء البطيء

4.1 اللامركزية - التحقق دون إذن

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

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

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

4.1.2 الحل 1. التحقق بدون إذن

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

• أربيترم:يعمل Arbitrum نحو تحقيق التحقق دون إذن من خلال بروتوكول التحقق الجديد الخاص به المسمى BoLD (Bounded Liquidity Delay). تم تصميم BOLD بشكل خاص لجعل التحقق من سلاسل Arbitrum آمنًا بشكل دون إذن، يسمح البروتوكول لأي طرف نزيه بالمشاركة في عملية التحقق من خلال ربط أموالهم لنشر تأكيدات الحالة الطبقية 2 (L2) الصحيحة. يزيل هذا الأمر الحاجة إلى سلطة مركزية لإدارة المحققين ويتيح حل النزاعات استنادًا إلى صحة الحالة بدلاً من هوية المحقق. يمكن العثور على شرح مفصل أكثر في "الجزء 3.1 Arbitrum".
• تفاؤل:التفاؤل هوتهدف إلى تحقيق التحقق دون إذنمن خلال الانتقال إلى نظام لامركزي مضاد للأخطاء. في البداية، اعتمد Optimism على محافظ متعددة التوقيع تحكمها مجلس أمان Optimism ومؤسسة Optimism. ولتحقيق المزيد من اللامركزية، قدم Optimism Cannon، وهو نظام مضاد للأخطاء خارج السلسلة يتم نشره حاليًا على OP Sepolia للفحص. من خلال استخدام Cannon، يحاول Optimism الانتقال من نظام يتطلب أذونات صريحة إلى نظام يمكن لأي مشارك المشاركة في التحقق من المعاملات وحل النزاعات. يسمح هذا النظام لأي شخص بالمشاركة في عملية التحقق عن طريق تقديم مطالبات سحب مدعومة بسندات.هذا الآن متوفر في الشبكة الرئيسية.)

4.1.3 الحل 2. تمرير الترتيب اللامركزي

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

1. متسلسلات مشتركة: تفويض تسلسل البيانات لخدمات الطرف الثالث مثل Espresso و Radius.
2. تقنية المُسَلّسِل المُوَزّع (DST): باستخدام مجموعة من الآلات لتوزيع مهام المسلسل، مما يوفر تحملًا عاليًا للأخطاء. يمكن اعتبار هذا مشابهًا لحلول DVT مثل الشبكة Obol التي تقوم ببنائها لمُحَقِّقي PoS.

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

مصدر: تقنية المُسَلِّسَ المُوَزَّع — طريق نحو التسلسل اللامركزي | بقلم Figment Capital | متوسط

4.2 تكلفة أقل - نظام DA والبرهان التفاعلي

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

4.2.1 الحل 1. DA أرخص

اللفات التفاؤلية تستفيد بشكل فعال من تجميعات إيثريوم وحلول توافر البيانات البديلة (DA) مثل Celestia لمعالجة التكاليف العالية المرتبطة بنشر بيانات دفعة المعاملات.

في سياق إيثريوم، تستخدم اللفائف التفاؤلية لنشر بيانات المعاملات إلى الشبكة الرئيسية كبيانات الاتصال، والتي كانت تشكل تكلفة كبيرة. ومع الترقية إلى دينكون، يتم الآن استخدام تنسيق تخزين البيانات الجديد المسمى الكتل، مما يقلل من التكلفة الإجمالية بنسبة تزيد عن 90٪.

المصدر: تفاؤل: سلاسل OP (سوبر تشين) - نشاط L2، اقتصاد السلسلة، تكاليف DA للمستوى 1

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

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

4.2.2 الحل2. نظام البرهان التفاعلي

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

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

4.3 الانتهاء البطيء - تنفيذ أسرع ونظام دليل هجين

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

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

4.3.1 الحل الأول. تنفيذ أسرع

من حيث النهائية الناعمة، العملية تتمثل في تنفيذ انتقال الحالة وحفظ دفعات المعاملات في إيثريوم. شهدت عملية التنفيذ قيودًا بسبب مواصفات EVM التي لا تدعم التنفيذ المتوازي أو تحسين قاعدة البيانات. ومع ذلك، هناك مشاريع مثل MegaETHوHeikoالتي تقوم ببناء بيئة التنفيذ الموازي، مع نظام دليل متفائل.

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

4.3.2 الحل 2. نظام البرهان الهجين

أنظمة البراهين الهجينة، لا سيما تلك التي تستفيد من البراهين ZK المدمجة مع الـ optimistic rollups، تعزز بشكل كبير نهائية معاملات البلوكشين عن طريق تقليل الوقت المطلوب للتحقق النهائي منها. الـ optimistic rollups، مثل تلك المستخدمة في OP Stack التابعة لـ Optimism، تعتمد بشكل طبيعي على افتراض أن المعاملات صالحة ما لم يتم تحديها. هذا يؤدي إلى ضرورة وجود فترة نزاع أو تحدي، حيث يمكن تع contest المعاملات غير الصالحة بشكل محتمل. ومع ذلك، تقوم هذه الفترة التحديية بإدخال تأخيرات في نهائية المعاملة حيث يجب أن تكون كافية الطول لضمان التحقق القوي والسماح بأي تحديات محتملة.

Zeth، الذي يعتمد على RISC Zero zkVM، يسمح بفحص الصحة الفوري للمعاملات من خلال توفير دليل تشفيري على أن كتلة المعاملات صحيحة دون الكشف عن تفاصيل المعاملات أنفسها. يقلل هذا من الاعتماد على نوافذ النزاع الممتدة المطلوبة للتراكم المتفائل ويقصر بشكل كبير وقت الاستقرار النهائي.

تضمن أدوات مثل Zeth أن تظل سلاسل المعاملات وآليات توفر البيانات محافظة بشكل موثوق عليها، ومن خلال تقليل فترة التحدي من أيام بالإمكان إلى ساعات أو حتى دقائق، يتم تعزيز كفاءة الحلول من الطبقة 2، مثل Optimism. قامت مشاريع مثل ZKM أيضًا بتطوير @benjamin.wynn_45604/الدمج-ميتيس-zkm-الأول-المتخصص-على-إيثريم-3cd896130f9">نظام-الدليل-المتخصص-لميتيس.

المصدر: تغريدة بواسطة zerokn0ledge

5. النظر إلى المستقبل - هل سيتم استبدال التجميع المتفائل؟

في رأيي، لن يتم استبدال الـ optimistic rollup قريبًا. هناك العديد من التحسينات التي يتم إجراؤها عليه، ومن المحتمل أن تكون بساطته قد اعتمدت أيضًا في بيئات نظامية أخرى. في مقال مستقبلي، سأحاول التعمق في "حالة نظام ZK Proof"، مناقشة التطورات الحديثة والإصدارات القادمة والمقارنة مع الـ optimistic rollups. ومع ذلك، تتسارع اعتماد الأطر مثل Arbitrum Orbit و OP-Stack، وآمل أن يكون هناك تنسيق محسن لتحسين البنية التحتية والأدوات في كل بيئة نظامية.

واحدة من المشاكل التي أراها في مجال التكدس هي القدرة على التوسع. يعمل مشاريع الطبقة1 مثل Sei و Sui و Solana على تطوير البنية التحتية لتمكين تنفيذ المعاملات المتوازية القوية وتحسين قاعدة البيانات، بهدف جعل التكنولوجيا البلوكشين أكثر إمكانية للجميع. (يرجى الاطلاع على مقالنا حول أربعة محاور عن التنفيذ المتوازيسيوسوي)التراكمات الحالية قد لا تكون قادرة على معالجة العديد من المعاملات والوصول إلى الاستقرار السريع مثل Sui. ومع ذلك، مع مشاريع مثل شبكة الوقود, ميغا إيثوHeikoمع تمكين التنفيذ المتوازي، يمكننا توقع تحسينات في الأداء في rollups قريبًا.

تنصل:

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