تحسين التوازي في EVM: المفتاح لكسر عنق الزجاجة في الأداء

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

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

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

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

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

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

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

بعد ذلك، سنستكشف بعمق قيود EVM التقليدي ومزايا EVM المتوازي.

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

على مستوى وحدات التعليمات البرمجية، بالإضافة إلى EVM، المكون الأساسي الآخر المرتبط بتنفيذ المعاملات في go-ethereum هو stateDB، والذي يُستخدم لإدارة حالة الحسابات وبيانات التخزين في الإيثريوم. يعتمد الإيثريوم على هيكل شجري يسمى 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.

من وجهة نظر الشيفرة، فإن العملية العامة لتنفيذ المعاملات بالتعاون بين EVM و stateDB كما يلي:

1. يتم استدعاء دالة processBlock)( لاستدعاء دالة Process)( لمعالجة المعاملات داخل كتلة.

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

3. بعد الانتهاء من معالجة جميع المعاملات، يتم استدعاء دالة processBlock)( لاستدعاء دالة writeBlockWithState)(، ثم يتم استدعاء دالة statedb.Commit)( لتقديم نتائج تغييرات الحالة.

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

![باستخدام Reddio كمثال، توضيح طريق تحسين EVM المتوازي])https://img-cdn.gateio.im/webp-social/moments-404bb55ec4d21fe81783881149ac0ad6.webp(

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

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

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

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

![باستخدام Reddio كمثال، توضيح طريق تحسين EVM المتوازي])https://img-cdn.gateio.im/webp-social/moments-fc9301b18b6299dc8f792e68961977cd.webp(

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

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

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

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

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

![باستخدام Reddio كمثال، توضيح طريق تحسين EVM المتوازي])https://img-cdn.gateio.im/webp-social/moments-c62d7268de0c9ada677dc15618b1e024.webp(

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

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

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

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

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

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

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

![توضيح طريق تحسين EVM المتوازي باستخدام Reddio كمثال])https://img-cdn.gateio.im/webp-social/moments-75575d5ea4bfa2edcc71ad93d3277caf.webp(

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

ملخص

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

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

![باستخدام Reddio كمثال، توضيح طريق تحسين EVM المتوازي])https://img-cdn.gateio.im/webp-social/moments-6274c33f6c958750df5cf3e53949b7fb.webp(