استكشاف عنق الزجاجة في التنفيذ التسلسلي لـ EVM وتحسين المعالجة المتوازية

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

تستطيع EVM تنفيذ العقود الذكية بطريقة موحدة على أنظمة تشغيل وأجهزة مختلفة، مما يضمن أن كل عقد يعمل على كل عقدة يحصل على نتائج متسقة. هذا مشابه لآلية عمل Java Virtual Machine (JVM).

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

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

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

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

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

المكونان الرئيسيان لتنفيذ معاملات الإيثريوم

بخلاف EVM، المكون الأساسي الآخر المرتبط بتنفيذ المعاملات هو stateDB، والذي يُستخدم لإدارة حالة الحسابات وتخزين البيانات في Ethereum. تستخدم Ethereum بنية شجرة Merkle Patricia Trie كفهرس لقاعدة البيانات، حيث أن كل تنفيذ لمعاملة من قبل EVM سيُغير بعض البيانات في stateDB، وستنعكس هذه التغييرات في النهاية في شجرة الحالة العالمية.

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

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

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

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

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

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

في وضع التنفيذ التسلسلي، تكون عملية تعاون مكوني EVM و stateDB لمعالجة المعاملات كما يلي:

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

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

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

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

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

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

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

مبدأ تحسين التوازي لـ EVM في مشروع معين

تتعلق فكرة تحسين التوازي لمشروع ZKRollup معين بـ EVM بتخصيص معاملة لكل خيط، وتوفير قاعدة بيانات حالة مؤقتة في كل خيط، تُعرف باسم pending-stateDB. التفاصيل المحددة هي كما يلي:

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

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

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

لقد تم تحسين طريقة معالجة عمليات القراءة والكتابة في هذا المشروع لضمان إمكانية الوصول الصحيح للبيانات الحالة وتجنب النزاعات:

• عمليات القراءة: عندما تحتاج المعاملة إلى قراءة الحالة، يتحقق EVM أولاً من ReadSet في الحالة المعلقة. إذا كانت البيانات المطلوبة موجودة في ReadSet، يتم القراءة مباشرة من pending-stateDB. إذا لم يتم العثور على زوج المفتاح والقيمة المقابل في ReadSet، يتم قراءة بيانات الحالة التاريخية من global stateDB للكتلة السابقة.

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

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

• الكشف عن النزاعات: خلال عملية تنفيذ المعاملات، يقوم EVM بمراقبة مجموعة القراءة (ReadSet) ومجموعة الكتابة (WriteSet) لمعاملات مختلفة. إذا اكتشف أن معاملات متعددة تحاول قراءة وكتابة نفس عنصر الحالة، فإن ذلك يعتبر حدوث نزاع.

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

بعد الانتهاء من تنفيذ جميع الصفقات، ستتم دمج سجلات التغييرات المتعددة في pending-stateDB إلى global stateDB. إذا تم الدمج بنجاح، ستقوم EVM بتقديم الحالة النهائية إلى شجرة الحالة العالمية، وتوليد جذر حالة جديد.

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

ملخص

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

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