طريق تحسين التوازي لـ EVM

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

كمثال على فكرة التحسين المتوازية لمشروع ZKRollup Reddio، تشمل الميزات الرئيسية ما يلي:

1. تنفيذ الصفقات بالتوازي متعدد الخيوط: إعداد عدة خيوط لمعالجة صفقات مختلفة في نفس الوقت، دون تداخل بين الخيوط، مما قد يزيد من سرعة معالجة الصفقات عدة مرات.

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

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

Reddio قامت بتحسين معالجة عمليات القراءة والكتابة:

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

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

لحل مشكلة تعارض الحالة، قامت Reddio بإدخال آلية كشف التعارض:

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

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

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

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

ملخص

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

يمكن مناقشة التفاصيل التنفيذية لـ Reddio في المستقبل، بما في ذلك كيفية تحسين كفاءة التخزين، وخطط التحسين في حالات التعارض العالي، وكيفية استخدام GPU في التحسين.