النظر في مسار تحسين EVM الموازي من Reddio

المؤلف: Wuyue, Geek web3

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

يمكن للآلة الافتراضية لـ Ethereum تشغيل الذكاء بنفس الطريقة على أنظمة تشغيل مختلفة (مثل Windows وLinux وmacOS) والأجهزة. يضمن هذا التوافق عبر الأنظمة الأساسية حصول كل عقدة على نتائج متسقة بعد تشغيل العقد. المثال الأكثر شيوعًا هو جهاز Java الظاهري JVM.

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

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

اختار الفريق المؤسس لشركة Ethereum في الفترة من 2014 إلى 2015 طريقة التنفيذ التسلسلي بسبب ضيق الوقت. لأنه مصمم ليكون بسيطًا وسهل الصيانة. ومع ذلك، مع تكرار تقنية blockchain وقاعدة المستخدمين المتنامية، أصبحت blockchain لديها متطلبات أعلى وأعلى لـ TPS والإنتاجية بعد ظهور تقنية Rollup وتنفيذها الناضج، مما لا شك فيه أن اختناق الأداء الناجم عن التنفيذ التسلسلي لـ EVM قد تم كشفه على الشبكة. الطبقة الثانية من الايثيريوم.

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

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

سنبدأ الآن بتفاصيل أكثر تحديدًا لشرح قيود EVM التقليدية ومزايا EVM المتوازية.

مكونان أساسيان لتنفيذ معاملات Ethereum

في على مستوى وحدة التعليمات البرمجية،بالإضافة إلى EVM، هناك مكون أساسي آخر يتعلق بتنفيذ المعاملات في go-ethereum وهو StateDB، والذي يستخدم لإدارة حالة الحساب وتخزين البيانات في Ethereum. يستخدم Ethereum بنية شجرية تسمى Merkle Patricia Trie لتكون بمثابة فهرس قاعدة بيانات (دليل). سيؤدي كل تنفيذ معاملة لـ EVM إلى تغيير بعض البيانات المخزنة في StateDB، وستنعكس هذه التغييرات في النهاية في Merkle Patricia Trie (لاحقًا يشار إليها باسم شجرة الحالة العالمية).

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

بشكل عام، تكون EVM مسؤولة عن تفسير وتنفيذ تعليمات العقد الذكي وتغيير الحالة على blockchain بناءً على نتائج الحساب، بينما تعمل StateDB كمخزن حالة عالمي. إدارة تغييرات الحالة لجميع الحسابات والعقود. يتعاون الاثنان لبناء بيئة تنفيذ المعاملات الخاصة بـ Ethereum.

العملية المحددة للتنفيذ التسلسلي

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

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

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

إذًاكيف يتعاون المكونان EVM وstateDB لمعالجة المعاملات في وضع التنفيذ التسلسلي؟

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

أثناء عملية تنفيذ المعاملة، يحتاج EVM إلى التفاعل المستمر مع StateDB، وقراءة البيانات ذات الصلة من StateDB، وكتابة البيانات المتغيرة مرة أخرى إلى StateDB.

دعونا نلقي نظرة تقريبية على كيفية تعاون EVM وstateDB لتنفيذ المعاملات من منظور التعليمات البرمجية:

1. processBlock ستستدعي الدالة () الدالة Process() لمعالجة المعاملات المضمنة في الكتلة؛

< img src=" https://img.jinse.cn/7313550_image3.png">

2. يتم تعريف A for في Process(). وظيفة حلقة، يمكنك أن ترى أن المعاملات يتم تنفيذها واحدة تلو الأخرى؛

3. بعد معالجة كافة المعاملات، تقوم الدالة processBlock() باستدعاء الدالة writeBlockWithState() ، ثم يستدعي الدالةstateb .Commit()،ويرسل نتيجة تغيير الحالة.

عند تنفيذ جميع المعاملات في الكتلة، سيتم تخصيص البيانات الموجودة في StateDB إلى شجرة الحالة العالمية (Merkle Patricia Trie) المذكورة سابقًا، وسيتم إنشاء جذر حالة جديد (stateRoot). يعد جذر الحالة معلمة مهمة في كل كتلة، فهو يسجل "نتيجة الضغط" للحالة العالمية الجديدة بعد تنفيذ الكتلة.

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

حل التحسين المتوازي متعدد الخيوط من EVM

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

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

مبدأ التحسين الموازي لـ Reddio لـ EVM

يمكننا أن نأخذ نظرة على أفكار التحسين المتوازية لمشروع ZKRollup Reddio لـ EVM. تتمثل فكرة Reddio في تخصيص معاملة لكل مؤشر ترابط وتوفير قاعدة بيانات حالة مؤقتة في كل مؤشر ترابط، تسمى انتظار حالة قاعدة البيانات. التفاصيل المحددة هي كما يلي:

1. تنفيذ المعاملات متعددة الخيوط بالتوازي: يقوم Reddio بإعداد سلاسل رسائل متعددة لمعالجة معاملات مختلفة في نفس الوقت، دون التدخل بين سلاسل الرسائل. . يمكن أن يؤدي ذلك إلى تسريع معالجة المعاملات عدة مرات.

2. تخصيص قاعدة بيانات حالة مؤقتة لكل موضوع: يخصص Reddio قاعدة بيانات حالة مؤقتة مستقلة (في انتظار -stateDB). عندما ينفذ كل مؤشر ترابط معاملة، فإنه لن يقوم بتعديل قاعدة بيانات الحالة العامة مباشرةً، ولكنه سيسجل مؤقتًا نتائج تغيير الحالة في قاعدة بيانات الحالة المعلقة.

3. تغيير حالة المزامنة: بعد تنفيذ جميع المعاملات في الكتلة، سيغير EVM كل معاملة معلقة - يتم تسجيل نتائج تغيير الحالة في StateDB تتم مزامنتها مع StateDB العالمية بدورها. إذا لم يكن هناك تعارض في الحالة أثناء تنفيذ المعاملات المختلفة، فيمكن دمج السجلات الموجودة في قاعدة بيانات الحالة المعلقة بنجاح في قاعدة بيانات الحالة العامة.

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

·عملية القراءة: عندما تحتاج المعاملة إلى قراءة الحالة، سيتحقق جهاز EVM أولاً من مجموعة القراءة للمعاملة المعلقة -ولاية . إذا أظهر ReadSet أن البيانات المطلوبة موجودة، فإن EVM يقرأ البيانات مباشرة من قاعدة بيانات الحالة المعلقة. إذا لم يتم العثور على قيمة المفتاح المقابلة (زوج قيمة المفتاح) في مجموعة القراءة، فستتم قراءة بيانات الحالة التاريخية من قاعدة البيانات العامة StateDB المقابلة للكتلة السابقة.

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

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

· اكتشاف التضارب: أثناء عملية تنفيذ المعاملة، ستقوم EVM بمراقبة ReadSet للمعاملات المختلفة وWriteSet. إذا تم العثور على معاملات متعددة تحاول قراءة أو كتابة نفس عنصر الحالة، فسيتم اعتبار ذلك تعارضًا.

· معالجة التعارض: عند اكتشاف تعارض، سيتم وضع علامة على المعاملة المتعارضة على أنها تتطلب إعادة التنفيذ.

بعد تنفيذ جميع المعاملات، سيتم دمج سجلات التغيير في قاعدة بيانات الحالة المعلقة المتعددة في قاعدة بيانات الحالة العامة. إذا نجح الدمج، فسيقوم جهاز EVM بإلزام الحالة النهائية بشجرة الحالة العامة وإنشاء جذر حالة جديد.

إن تحسين أداء التحسين المتوازي متعدد الخيوط أمر واضح، خاصة عند التعامل مع معاملات العقود الذكية المعقدة.

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

الملخص

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

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