طريق سلسلة BNB إلى الكتل الكبيرة

طريق الكتل الكبيرة على سلسلة BNB

على غرار Solana وHeco وغيرها من السلاسل العامة التي تدعمها البورصات، سعت سلسلة BNB Smart Chain (BSC) العامة لسلسلة BNB منذ فترة طويلة إلى الأداء العالي. منذ إطلاقها في عام 2020، حددت BSC الحد الأقصى لسعة الغاز لكل كتلة إلى 30 مليونًا، مع فاصل زمني ثابت للكتلة قدره 3 ثوانٍ. باستخدام هذه المعلمات، حققت BSC حدًا أقصى لـ TPS (TPS مع المعاملات المختلفة المختلطة معًا) يزيد عن 100. وفي يونيو 2021، تمت زيادة الحد الأقصى لكتلة الغاز في BSC إلى 60 مليونًا. ومع ذلك، في يوليو من نفس العام، انتشرت لعبة متسلسلة تسمى CryptoBlades على BSC، مما تسبب في تجاوز حجم المعاملات اليومية 8 ملايين وأدى إلى ارتفاع الرسوم. وتبين أن عنق الزجاجة في كفاءة BSC كان لا يزال واضحًا تمامًا في ذلك الوقت.

(المصدر: BscScan)

ولمعالجة مشكلات أداء الشبكة، قامت BSC مرة أخرى برفع حد الغاز لكل كتلة، والذي ظل مستقرًا عند حوالي 80-85 مليونًا لفترة طويلة. وفي سبتمبر 2022، تمت زيادة حد الغاز لكل كتلة من سلسلة BSC إلى 120 مليونًا، وبحلول نهاية العام، تم رفعه إلى 140 مليونًا، أي ما يقرب من خمسة أضعاف ما كان عليه في عام 2020. في السابق، خططت BSC لزيادة الحد الأقصى لسعة الغاز إلى 300 مليون، ولكن ربما بالنظر إلى العبء الثقيل على عقد Validator، لم يتم تنفيذ الاقتراح الخاص بمثل هذه الكتل الكبيرة جدًا.

المصدر: YCHARTS

في وقت لاحق، بدا أن سلسلة BNB تركز أكثر على المسار المعياري/الطبقة الثانية بدلاً من الاستمرار في توسيع الطبقة الأولى. وقد أصبحت هذه النية واضحة بشكل متزايد منذ إطلاق zkBNB في النصف الثاني من العام الماضي إلى GreenField في بداية هذا العام. انطلاقًا من الاهتمام القوي بوحدات blockchain/Layer2 المعيارية، سيستخدم مؤلف هذه المقالة opBNB ككائن بحثي للكشف عن اختناقات أداء Rollup من خلال مقارنتها مع Ethereum Layer2.

تعزيز الإنتاجية العالية لـ BSC إلى طبقة DA الخاصة بـ opBNB

كما نعلم جميعًا، قامت Celestia بتلخيص أربعة مكونات رئيسية وفقًا لسير عمل blockchain المعياري: طبقة التنفيذ: تنفيذ كود العقد وإكمال انتقالات الحالة؛ طبقة التسوية: تتعامل مع إثباتات الاحتيال/إثباتات الصلاحية وتعالج مشكلات الجسر بين L2 وL1. طبقة الإجماع: تصل إلى الإجماع بشأن طلب المعاملات. طبقة توفر البيانات (DA): تنشر البيانات المتعلقة بدفتر الأستاذ blockchain، مما يسمح للمدققين بتنزيل هذه البيانات.

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

ومع ذلك، بالنسبة لـ Ethereum Layer2، أصبح إنتاجية البيانات لطبقة DA (Ethereum) أكبر عنق الزجاجة الذي يقيد أداء التراكمي. وذلك لأن معدل نقل البيانات الحالي لـ Ethereum منخفض جدًا، مما يجبر Rollup على قمع TPS الخاص به قدر الإمكان لمنع شبكة Ethereum الرئيسية من عدم القدرة على تحمل البيانات التي تم إنشاؤها بواسطة L2. وفي الوقت نفسه، يؤدي انخفاض إنتاجية البيانات إلى أن يكون عدد كبير من تعليمات المعاملات داخل شبكة إيثريوم في حالة انتظار، مما يؤدي إلى دفع رسوم الغاز إلى مستويات عالية للغاية وزيادة تكلفة نشر البيانات لـ Layer2. أخيرًا، يتعين على العديد من شبكات Layer2 أن تتبنى طبقات DA خارج Ethereum، مثل Celestia، وقد اختارت opBNB، القريبة من الماء، استخدام الإنتاجية العالية لـ BSC مباشرة لتنفيذ DA لحل مشكلة اختناق نشر البيانات. لسهولة الفهم، دعنا نقدم طريقة نشر بيانات DA الخاصة بالتراكمي. بأخذ Arbitrum كمثال، فإن سلسلة Ethereum التي يتم التحكم فيها بواسطة عنوان EOA لجهاز التسلسل Layer2 سترسل المعاملات بشكل دوري إلى العقد المحدد. في بيانات استدعاء معلمات الإدخال لهذه التعليمات، تتم كتابة بيانات المعاملات المجمعة، ويتم تشغيل الأحداث المقابلة على السلسلة، مما يترك سجلاً دائمًا في سجلات العقد.

بهذه الطريقة، يتم تخزين بيانات المعاملات الخاصة بـ Layer2 في كتل Ethereum لفترة طويلة. يمكن للأشخاص القادرين على تشغيل عقد L2 تنزيل السجلات المقابلة وتحليل البيانات المقابلة، لكن عقد Ethereum نفسها لا تنفذ معاملات L2 هذه. من السهل أن نرى أن L2 يقوم فقط بتخزين بيانات المعاملات في كتل Ethereum، مما يؤدي إلى تحمل تكاليف التخزين، في حين تتحمل عقد L2 نفسها التكاليف الحسابية لتنفيذ المعاملات. ما سبق هو طريقة تنفيذ DA الخاصة بـ Arbitrum، بينما يستخدم Optimism عنوان EOA يتحكم فيه جهاز التسلسل للانتقال إلى عنوان EOA محدد آخر، ويحمل دفعة جديدة من بيانات معاملات Layer2 في البيانات الإضافية. أما بالنسبة لـ opBNB، الذي يستخدم OP Stack، فإن طريقة نشر بيانات DA الخاصة به هي في الأساس نفس طريقة Optimism.

من الواضح أن إنتاجية طبقة DA ستحد من حجم البيانات التي يمكن أن ينشرها Rollup في وحدة زمنية، مما يحد من TPS. وبالنظر إلى أنه بعد EIP1559، استقرت سعة الغاز لكل كتلة ETH عند 30 مليونًا، وكان وقت الكتلة بعد الدمج حوالي 12 ثانية، ويمكن لـ Ethereum التعامل مع 2.5 مليون غاز فقط كحد أقصى في الثانية. في معظم الأحيان، يكون الغاز المستهلك من خلال استيعاب بيانات معاملات L2 لكل بايت في بيانات الاتصال هو 16، لذلك يمكن لـ Ethereum التعامل مع الحد الأقصى لحجم بيانات الاتصال وهو 150 كيلو بايت فقط في الثانية. في المقابل، يبلغ الحد الأقصى لمتوسط حجم بيانات المكالمات التي تتم معالجتها في BSC في الثانية حوالي 2910 كيلو بايت، وهو ما يعادل 18.6 ضعف حجم Ethereum. الفرق بين الاثنين كطبقات DA واضح.

للتلخيص، يمكن لـ Ethereum أن يحمل حوالي 150 كيلو بايت من بيانات معاملات L2 في الثانية. حتى بعد إطلاق EIP 4844، لن يتغير هذا الرقم كثيرًا، بل سيؤدي فقط إلى تقليل رسوم DA. إذن، كم عدد بيانات المعاملات التي يمكن تضمينها في حوالي 150 كيلو بايت في الثانية؟ نحن هنا بحاجة إلى شرح معدل ضغط البيانات في التراكمي. كان Vitalik مفرطًا في التفاؤل في عام 2021، حيث قدر أن Optimistic Rollup يمكنه ضغط حجم بيانات المعاملة إلى 11% من الحجم الأصلي. على سبيل المثال، يمكن ضغط نقل ETH الأساسي، الذي كان يشغل في الأصل حجم بيانات اتصال يبلغ 112 بايت، إلى 12 بايت بواسطة Optimistic Rollup، ويمكن ضغط عمليات نقل ERC-20 إلى 16 بايت، ويمكن ضغط معاملات المبادلة على Uniswap إلى 14 بايت. وفقًا لتقديراته، يمكن للإيثيريوم تسجيل حوالي 10000 معاملة L2 في الثانية (مع خلط أنواع مختلفة معًا). ومع ذلك، وفقًا للبيانات التي كشف عنها فريق Optimism في عام 2022، يمكن أن يصل معدل ضغط البيانات الفعلي إلى حد أقصى يبلغ حوالي 37% فقط، وهو أقل بمقدار 3.5 مرة من تقديرات فيتاليك.

(إن تقدير Vitalik لتأثير قابلية التوسع التراكمي ينحرف بشكل كبير عن الظروف الفعلية)

(معدلات الضغط الفعلية التي حققتها خوارزميات الضغط المختلفة التي كشفت عنها التفاؤل)

لذلك دعونا نعطي رقمًا معقولًا: حتى إذا وصل Ethereum إلى الحد الأقصى للإنتاجية، فإن الحد الأقصى لعدد TPS لجميع عمليات التجميع المتفائلة مجتمعة يزيد قليلاً عن 2000. بمعنى آخر، إذا تم استخدام كتل Ethereum بالكامل لنقل البيانات المنشورة بواسطة Optimistic Rollups، مثل تلك الموزعة بين Arbitrum وOptimism وBase وBoba، فإن TPS المجمعة لهذه المجموعات المتفائلة لن تصل حتى إلى 3000، حتى في ظل معظم خوارزميات الضغط الفعالة. بالإضافة إلى ذلك، يجب أن نأخذ في الاعتبار أنه بعد EIP1559، يبلغ متوسط سعة الغاز لكل كتلة 50٪ فقط من القيمة القصوى، لذلك يجب تخفيض الرقم المذكور أعلاه إلى النصف. بعد إطلاق EIP4844، على الرغم من أن رسوم المعاملات لنشر البيانات سيتم تخفيضها بشكل كبير، فإن الحد الأقصى لحجم كتلة Ethereum لن يتغير كثيرًا (نظرًا لأن الكثير من التغيير قد يؤثر على أمان سلسلة ETH الرئيسية)، وبالتالي فإن القيمة المقدرة أعلاه لن تتقدم كثيراً.

وفقًا لبيانات من Arbiscan وEtherscan، تحتوي مجموعة المعاملات على Arbitrum على 1115 معاملة، تستهلك 1.81 مليون غاز على Ethereum. من خلال الاستقراء، إذا تم ملء طبقة DA في كل كتلة، فإن حد TPS النظري لـ Arbitrum يبلغ حوالي 1500. بالطبع، بالنظر إلى مسألة إعادة تنظيم كتلة L1، لا تستطيع Arbitrum نشر دفعات المعاملات على كل كتلة إيثريوم، وبالتالي فإن الأرقام المذكورة أعلاه هي حاليًا نظرية فقط. بالإضافة إلى ذلك، مع الاعتماد الواسع النطاق للمحافظ الذكية المتعلقة بـ EIP 4337، ستصبح مشكلة DA أكثر خطورة. لأنه مع دعم EIP 4337، يمكن تخصيص الطريقة التي يتحقق بها المستخدمون من هويتهم، مثل تحميل البيانات الثنائية لبصمات الأصابع أو قزحية العين، مما سيؤدي إلى زيادة حجم البيانات التي تشغلها المعاملات العادية. لذلك، فإن انخفاض إنتاجية البيانات في Ethereum هو أكبر اختناق يحد من كفاءة التراكم، وقد لا يتم حل هذه المشكلة بشكل صحيح لفترة طويلة. من ناحية أخرى، في سلسلة BNB التابعة لسلسلة BSC العامة، يبلغ الحد الأقصى لمتوسط حجم بيانات المكالمات التي تتم معالجتها في الثانية حوالي 2910 كيلو بايت، وهو ما يعادل 18.6 ضعف حجم Ethereum. بمعنى آخر، طالما أن طبقة التنفيذ قادرة على مواكبة ذلك، يمكن أن يصل الحد الأعلى النظري لـ TPS للطبقة 2 داخل النظام البيئي لسلسلة BNB إلى ما يقرب من 18 مرة من ARB أو OP. يتم حساب هذا الرقم بناءً على السعة القصوى لكتلة الغاز لسلسلة BNB الحالية والتي تبلغ 140 مليونًا، مع وقت كتلة يبلغ 3 ثوانٍ.

بمعنى آخر، فإن الحد الإجمالي الحالي لـ TPS لجميع عمليات التجميع داخل النظام البيئي لسلسلة BNB هو 18.6 مرة أكثر من Ethereum (حتى عند النظر في ZKRollup). من هذا المنظور، من السهل أن نفهم سبب استخدام العديد من مشاريع Layer2 لطبقة DA ضمن سلسلة Ethereum لنشر البيانات، حيث أن الفرق واضح تمامًا. ومع ذلك، فإن المسألة ليست بهذه البساطة. إلى جانب مشكلة إنتاجية البيانات، يمكن أن يؤثر استقرار الطبقة 1 نفسها أيضًا على الطبقة 2. على سبيل المثال، غالبًا ما تنتظر معظم المجموعات المجمعة عدة دقائق قبل نشر مجموعة من المعاملات إلى إيثريوم، مع الأخذ في الاعتبار إمكانية إعادة تنظيم كتلة الطبقة الأولى. إذا تمت إعادة تنظيم كتلة Layer1، فسيؤثر ذلك على دفتر الأستاذ blockchain للطبقة 2. لذلك، سينتظر جهاز التسلسل حتى يتم نشر عدة كتل Layer1 جديدة بعد كل إصدار لمجموعة معاملات L2، مما يقلل بشكل كبير من احتمالية التراجع عن الكتلة، قبل نشر دفعة معاملات L2 التالية. يؤدي هذا في الواقع إلى تأخير الوقت الذي يتم فيه تأكيد كتل L2 أخيرًا، مما يقلل من سرعة تأكيد المعاملات الكبيرة (تتطلب المعاملات الكبيرة نتائج لا رجعة فيها لضمان الأمان). باختصار، المعاملات التي تحدث في L2 تصبح غير قابلة للإلغاء إلا بعد نشرها في كتل طبقة DA وبعد أن تقوم طبقة DA بإنشاء عدد معين من الكتل الجديدة. وهذا سبب مهم يحد من أداء التراكمي. ومع ذلك، تتمتع إيثريوم بسرعة بطيئة في إنشاء الكتلة، حيث تستغرق 12 ثانية لإنتاج الكتلة. بافتراض أن مجموعة التحديثات تنشر دفعة من معاملات L2 كل 15 كتلة، سيكون هناك فاصل زمني مدته 3 دقائق بين الدُفعات المختلفة، وبعد نشر كل دفعة، لا تزال بحاجة إلى الانتظار حتى يتم إنشاء كتل Layer1 متعددة قبل أن تصبح غير قابلة للإلغاء (بافتراض أنها لا تحدي). من الواضح أن الوقت المنقضي منذ بدء المعاملات حتى عدم إمكانية الرجوع عنها على الطبقة الثانية من Ethereum طويل جدًا، مما يؤدي إلى بطء سرعة التسوية؛ في حين أن سلسلة BNB تستغرق 3 ثوانٍ فقط لإنتاج كتلة، وتصبح الكتل غير قابلة للتراجع في 45 ثانية فقط (الوقت الذي يستغرقه إنتاج 15 كتلة جديدة). استنادًا إلى المعلمات الحالية، بافتراض نفس عدد معاملات L2 والنظر في عدم إمكانية الرجوع عن كتل L1، يمكن أن يصل عدد المرات التي يمكن لـ opBNB نشر بيانات المعاملات في وحدة زمنية إلى ما يصل إلى 8.53 أضعاف عدد Arbitrum (مرة واحدة كل 45 ثانية لـ الأول، ومرة واحدة كل 6.4 دقيقة للأخير). من الواضح أن سرعة تسوية المعاملات الكبيرة على opBNB أسرع بكثير منها على طبقة Layer2 الخاصة بـ Ethereum. بالإضافة إلى ذلك، يمكن أن يصل الحد الأقصى لحجم البيانات التي تنشرها opBNB في كل مرة إلى 4.66 أضعاف حجم الطبقة الثانية من Ethereum (الحد الأقصى لغاز الكتلة L1 للأول هو 140 مليونًا، بينما يبلغ الحد الأخير 30 مليونًا). 8.53 * 4.66 = 39.74. يمثل هذا الفجوة بين opBNB وArbitrum من حيث حد TPS في التنفيذ العملي (حاليًا، لأسباب أمنية، يبدو أن ARB يعمل على تقليل TPS بشكل فعال، ولكن من الناحية النظرية، إذا تمت زيادة TPS، فسيظل أقل بعدة مرات مقارنة بـ opBNB ).

(ينشر مُسلسِل Arbitrum دفعة من المعاملات كل 6-7 دقائق)

(ينشر مُسلسِل opBNB دفعة من المعاملات كل دقيقة أو دقيقتين، ويستغرق أسرعها 45 ثانية فقط). بالطبع، هناك مسألة حاسمة أخرى يجب مراعاتها، وهي رسوم الغاز في طبقة DA. في كل مرة ينشر L2 دفعة معاملة، تكون هناك تكلفة ثابتة تبلغ 21000 غاز غير مرتبطة بحجم بيانات الاتصال، وهو ما يعد بمثابة نفقات. إذا كانت رسوم الغاز لطبقة DA/L1 مرتفعة، مما يتسبب في بقاء التكلفة الثابتة لنشر مجموعة المعاملات على L2 مرتفعة، فسيعمل جهاز التسلسل على تقليل تكرار نشر دفعات المعاملات. بالإضافة إلى ذلك، عند النظر في مكونات رسوم L2، تكون تكلفة طبقة التنفيذ منخفضة جدًا ويمكن تجاهلها غالبًا، مع التركيز فقط على تأثير تكاليف DA على رسوم المعاملات. باختصار، في حين أن نشر بيانات الاتصال بنفس الحجم يستهلك نفس الكمية من الغاز على Ethereum وBNB Chain، فإن سعر الغاز الذي تتقاضاه Ethereum أعلى بنحو 10 إلى عشرات المرات من سعر سلسلة BNB. تُترجم رسوم معاملات المستخدم الحالية على Ethereum Layer2 إلى رسوم معاملات L2، وهي أيضًا أعلى بحوالي 10 إلى عشرات المرات من تلك الموجودة على opBNB. بشكل عام، فإن الاختلافات بين opBNB وOptimistic Rollup على Ethereum واضحة تمامًا.

(المعاملة التي تستهلك 150.000 غاز على Optimism تكلف 0.21 دولار)

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

تعزيز opBNB في طبقة التنفيذ: تحسين ذاكرة التخزين المؤقت

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

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

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

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

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

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

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

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

باختصار، يمكن لـ opBNB معالجة ما يصل إلى 4761 عملية تحويل بسيطة في الثانية، و15003000 عملية نقل رمزية ERC20 في الثانية، وحوالي 5001000 عملية SWAP في الثانية بناءً على بيانات المعاملات التي تمت ملاحظتها في مستكشفات blockchain. بمقارنة المعلمات الحالية، فإن حد TPS الخاص بـ opBNB هو 40 ضعف حد Ethereum، وأكثر من ضعف حد BNB Chain، وأكثر من 6 أضعاف حد Optimism.

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

بالنسبة لسلسلة BNB ذات طبقة DA ذات إنتاجية عالية مثل opBNB، يعد التأثير المضاعف للقياس ذا قيمة، خاصة بالنظر إلى أن BNB Chain يمكنها استضافة العديد من مشاريع التوسع هذه. يمكن توقع أن BNB Chain قد قامت بالفعل بدمج حلول Layer2 التي تقودها opBNB في خططها الإستراتيجية، وستستمر في تضمين المزيد من مشاريع blockchain المعيارية، بما في ذلك إدخال أدلة ZK في opBNB وتوفير طبقات DA عالية التوفر مع بنية تحتية تكميلية مثل GreenField، في محاولة للتنافس أو التعاون مع النظام البيئي Ethereum Layer2.

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

تنصل:

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