تحسين التوازي EVM: من خلال Reddio لاستكشاف طرق تحسين الأداء
من المعروف أن EVM هو أحد المكونات الأساسية في الإيثيريوم، حيث يلعب دور "محرك التنفيذ" و"بيئة تشغيل العقود الذكية". في شبكة blockchain المفتوحة التي تتكون من آلاف العقد، قد تختلف تكوينات الأجهزة بين العقد المختلفة. لضمان الحصول على نتائج تنفيذ متسقة للعقود الذكية عبر جميع العقد، أصبحت تقنية الآلة الافتراضية هي الحل المثالي.
يمكن لـ EVM تشغيل العقود الذكية بنفس الطريقة على أنظمة التشغيل والأجهزة المختلفة، وتضمن هذه التوافقية عبر المنصات حصول كل عقد على نتائج متسقة بعد تنفيذ العقد. هذا مشابه لمبدأ آلة جافا الافتراضية JVM.
العقود الذكية التي نراها في متصفح الكتلة، يتم تحويلها أولاً إلى بايت كود EVM، ثم تُخزن على السلسلة. عند تنفيذ العقد، يقوم EVM بقراءة هذه البايت كود بالتسلسل، وكل تعليمة لها تكلفة غاز محددة. يتتبع EVM استهلاك الغاز أثناء تنفيذ كل تعليمة، ويعتمد مقدار الاستهلاك على درجة تعقيد العملية.
كـنظام تنفيذ مركزي لإيثيريوم، يتبنى EVM معالجة المعاملات بطريقة تسلسلية، حيث يتم ترتيب جميع المعاملات في قائمة واحدة وتنفيذها بالتتابع وفقًا لترتيب محدد. السبب وراء عدم اعتماد الطريقة المتوازية هو أن البلوكشين يحتاج إلى ضمان صارم للتناسق، حيث يجب معالجة نفس مجموعة المعاملات بنفس الترتيب عبر جميع العقد. إذا تم مواكبة معالجة المعاملات بشكل متوازي، سيكون من الصعب التنبؤ بدقة بترتيب المعاملات، ما لم يتم إدخال خوارزميات جدولة معقدة.
في عامي 2014-2015، اختار فريق مؤسسي الإيثيريوم تصميم طريقة تنفيذ متسلسل بسيطة وسهلة الصيانة بسبب ضيق الوقت. ومع ذلك، مع تطور تقنية البلوكشين وزيادة حجم المستخدمين، أصبح الطلب على TPS والسعة أعلى. بعد ظهور تقنية Rollup ونضوجها، أصبحت قيود الأداء الناتجة عن التنفيذ المتسلسل لـ EVM واضحة بشكل ملحوظ على شبكة الإيثيريوم من الطبقة الثانية.
يعد Sequencer مكونًا رئيسيًا في Layer2، حيث يتحمل جميع مهام الحساب بشكل فردي على خادم واحد. إذا كانت كفاءة الوحدات الخارجية المتصلة بـ Sequencer عالية بما يكفي، فإن الاختناق النهائي سيعتمد على كفاءة Sequencer نفسه، وفي هذه الحالة ستصبح التنفيذ التسلسلي عقبة كبيرة.
قامت إحدى الفرق من خلال تحسينات متطرفة في طبقة DA ووحدة قراءة وكتابة البيانات، بجعل Sequencer قادراً على تنفيذ أكثر من 2000 معاملة ERC-20 في الثانية. يبدو أن هذا الرقم مرتفع جداً، ولكن إذا كانت المعاملات التي يتعين معالجتها أكثر تعقيدًا بكثير من معاملات ERC-20، فمن المؤكد أن قيمة TPS ستنخفض بشكل كبير. لذا، فإن معالجة المعاملات بشكل متوازي ستكون الاتجاه الحتمي في المستقبل.
العنصران الأساسيان في تنفيذ معاملات الإيثريوم
بخلاف EVM، فإن المكون الأساسي الآخر المرتبط بتنفيذ المعاملات في go-ethereum هو stateDB، والذي يُستخدم لإدارة حالة الحسابات وبيانات التخزين في Ethereum. تستخدم Ethereum بنية شجرية تُسمى Merkle Patricia Trie كفهرس قاعدة البيانات، حيث يقوم EVM بتغيير بعض البيانات المخزنة في stateDB مع كل تنفيذ للمعاملة، وستنعكس هذه التغييرات في النهاية في الشجرة العالمية للحالة.
تتحمل stateDB مسؤولية صيانة حالة جميع حسابات الإيثريوم، بما في ذلك حسابات EOA وحسابات العقود، والبيانات المخزنة تشمل رصيد الحساب، وكود العقد الذكي، وغيرها. خلال عملية تنفيذ الصفقة، تقوم stateDB بقراءة وكتابة البيانات الخاصة بالحسابات المعنية. بعد انتهاء تنفيذ الصفقة، تحتاج stateDB إلى تقديم الحالة الجديدة إلى قاعدة البيانات الأساسية لمعالجتها بشكل دائم.
بشكل عام، فإن EVM مسؤولة عن تفسير وتنفيذ تعليمات العقود الذكية، وتغيير حالة blockchain بناءً على نتائج الحساب، بينما تعمل stateDB كخزن للحالة العالمية، تدير جميع تغييرات حالة الحسابات والعقود. يعمل الاثنان معًا لبناء بيئة تنفيذ المعاملات في Ethereum.
عملية التنفيذ المتسلسل المحددة
تنقسم أنواع معاملات الإيثريوم إلى تحويلات EOA ومعاملات العقود. تحويلات EOA هي أبسط أنواع المعاملات، وهي تحويل ETH بين الحسابات العادية، دون استدعاء العقود، وسرعة المعالجة سريعة جدًا، والرسوم الغازية المفروضة منخفضة.
تتضمن تداول العقود استدعاء وتنفيذ العقود الذكية. عند معالجة تداول العقود، يحتاج EVM إلى تفسير وتنفيذ تعليمات بايت كود في العقد الذكي واحدة تلو الأخرى، فكلما كانت منطق العقد أكثر تعقيدًا، زادت التعليمات المعنية، وبالتالي زادت الموارد المستهلكة.
على سبيل المثال، يستغرق وقت معالجة تحويل ERC-20 حوالي ضعف وقت تحويل EOA، بينما قد يستغرق تنفيذ العمليات المعقدة للعقود الذكية، مثل عمليات التداول على بعض DEX، أضعاف وقت تحويل EOA. وذلك لأن بروتوكولات DeFi تحتاج إلى معالجة منطق معقد مثل أحواض السيولة، حساب الأسعار، وتبادل الرموز أثناء المعاملات، مما يتطلب إجراء حسابات كثيفة.
في وضع التنفيذ التسلسلي، تتعاون مكونا EVM و stateDB لمعالجة المعاملات بالطريقة التالية:
في تصميم الإيثيريوم، يتم معالجة المعاملات داخل الكتلة واحدة تلو الأخرى حسب الترتيب، حيث يتم تنفيذ كل معاملة من خلال نموذج مستقل يقوم بالعمليات المحددة. على الرغم من أن كل معاملة تستخدم نموذج EVM مختلف، إلا أن جميع المعاملات تشترك في نفس قاعدة بيانات الحالة stateDB.
خلال تنفيذ المعاملة، يحتاج EVM إلى التفاعل المستمر مع stateDB، لقراءة البيانات ذات الصلة من stateDB، وكتابة البيانات التي تم تغييرها مرة أخرى إلى stateDB.
عندما تكتمل جميع المعاملات في كتلة، يتم تقديم البيانات الموجودة في stateDB إلى شجرة الحالة العالمية، ويتم إنشاء جذر حالة جديدة. جذر الحالة هو معلمة مهمة في كل كتلة، حيث يسجل "نتيجة مضغوطة" للحالة العالمية الجديدة بعد تنفيذ الكتلة.
تظهر قيود وضع التنفيذ المتسلسل لـ EVM بوضوح: يجب تنفيذ المعاملات بالتسلسل، وإذا حدثت معاملة عقد ذكي تستغرق وقتًا طويلاً، يجب أن تنتظر المعاملات الأخرى حتى يتم معالجتها، وهذا بالطبع لا يمكن أن يستفيد بشكل كامل من موارد الأجهزة مثل وحدة المعالجة المركزية، مما يضع قيودًا كبيرة على الكفاءة.
خطة تحسين التوازي المتعدد الخيوط لـ EVM
يمكن تشبيه التنفيذ التسلسلي والتنفيذ المتوازي بوجود مكتب واحد فقط في البنك ووجود مكاتب متعددة في البنك. في وضع التوازي، يمكن فتح عدة خيوط لمعالجة عدة معاملات في نفس الوقت، مما يمكن أن يزيد الكفاءة عدة أضعاف، لكن المشكلة المعقدة هي مشكلة تعارض الحالة.
إذا كانت هناك عدة معاملات تعلن عن تعديل بيانات حساب معين، فعند معالجتها في نفس الوقت، ستحدث تعارضات. على سبيل المثال، إذا كان من الممكن سك NFT واحد فقط، وكانت المعاملة 1 والمعاملة 2 تعلنان عن رغبتهما في سك نفس NFT، إذا تم تلبية الطلبين، فمن الواضح أن هناك خطأ. في العمليات الفعلية، تحدث تعارضات الحالة بشكل أكثر تكرارًا، لذا يجب أن تتضمن معالجة المعاملات المتوازية تدابير للتعامل مع تعارضات الحالة.
مبدأ تحسين التوازي لـ Reddio على EVM
مشروع ZKRollup معين يتبنى فكرة تحسين التوازي لـ EVM من خلال تخصيص معاملة لكل خيط، وتوفير قاعدة بيانات حالة مؤقتة في كل خيط تُسمى pending-stateDB. التفاصيل المحددة على النحو التالي:
تنفيذ المعاملات بالتوازي متعدد الخيوط: إعداد عدة خيوط لمعالجة معاملات مختلفة في نفس الوقت، دون تدخل بين الخيوط. يمكن أن يزيد هذا من سرعة معالجة المعاملات عدة مرات.
تخصيص قاعدة بيانات حالة مؤقتة لكل خيط: يتم تخصيص قاعدة بيانات حالة مؤقتة مستقلة لكل خيط (pending-stateDB). أثناء تنفيذ المعاملات من قبل الخيوط المختلفة، لا يتم تعديل قاعدة بيانات الحالة العالمية مباشرة، بل يتم تسجيل نتائج التغييرات في الحالة مؤقتًا في pending-stateDB.
تغيير الحالة المتزامن: بعد تنفيذ جميع المعاملات داخل كتلة واحدة، سيقوم EVM بمزامنة نتائج تغييرات الحالة المسجلة في كل pending-stateDB إلى global stateDB بالتتابع. إذا لم تحدث أي تعارضات في الحالة أثناء تنفيذ المعاملات المختلفة، يمكن دمج السجلات من pending-stateDB بسلاسة في global stateDB.
لقد تم تحسين طريقة معالجة عمليات القراءة والكتابة في المشروع لضمان إمكانية الوصول الصحيح لبيانات الحالة وتجنب التعارضات:
عمليات القراءة: عندما تحتاج المعاملة إلى قراءة الحالة، يقوم EVM أولاً بالتحقق من ReadSet في الحالة المعلقة. إذا كان ReadSet يحتوي على البيانات المطلوبة، يتم قراءتها مباشرة من pending-stateDB. إذا لم يتم العثور على الزوج المفتاح-القيمة المقابل في ReadSet، يتم قراءة بيانات الحالة التاريخية من global stateDB للكتلة السابقة.
عمليات الكتابة: جميع عمليات الكتابة ( أي تعديل على الحالة ) لن يتم كتابتها مباشرة إلى قاعدة بيانات الحالة العالمية stateDB، بل ستسجل أولاً في مجموعة الكتابة WriteSet في حالة الانتظار Pending-state. بعد الانتهاء من تنفيذ المعاملة، سيتم محاولة دمج نتائج تغيير الحالة في قاعدة بيانات الحالة العالمية stateDB بعد إجراء اختبار التصادم.
تتمثل المشكلة الرئيسية في التنفيذ المتوازي في تعارض الحالة، عندما تحاول عدة معاملات قراءة وكتابة حالة نفس الحساب، تكون هذه المشكلة بارزة بشكل خاص. ولهذا تم إدخال آلية الكشف عن التعارض:
كشف التداخل: أثناء تنفيذ المعاملات، يقوم EVM بمراقبة ReadSet و WriteSet لمعاملات مختلفة. إذا اكتشف أن عدة معاملات تحاول قراءة وكتابة نفس عنصر الحالة، فإن ذلك يعتبر حدوث تداخل.
معالجة النزاعات: عند اكتشاف نزاع، سيتم وضع علامة على الصفقة المتنازع عليها بأنها تحتاج إلى إعادة التنفيذ.
بعد الانتهاء من تنفيذ جميع المعاملات، سيتم دمج سجلات التغييرات المتعددة من عدة pending-stateDB في global stateDB. إذا تم الدمج بنجاح، ستقوم EVM بتقديم الحالة النهائية إلى شجرة الحالة العالمية، وتوليد جذر حالة جديد.
تحسين التوازي متعدد الخيوط له تأثير ملحوظ على الأداء، خاصة عند التعامل مع معاملات العقود الذكية المعقدة. تظهر الأبحاث أنه في مجموعة معاملات ( ذات الحمل المنخفض من حيث التضارب، حيث توجد معاملات أقل تعارضًا أو تتشارك نفس الموارد، فإن اختبار TPS مقارنة بالتنفيذ التسلسلي التقليدي قد زاد بنحو 3-5 مرات. في حالات الحمل العالي من حيث التضارب، نظريًا، إذا تم استخدام جميع وسائل التحسين، يمكن أن تصل الزيادة إلى 60 مرة.
![باستخدام Reddio كمثال، توضيح طريق تحسين EVM المتوازية])https://img-cdn.gateio.im/webp-social/moments-4966960247a4550afa25f04eaaabbbd8.webp(
ملخص
تساهم خطة تحسين تعدد الخيوط في EVM الخاصة بالمشروع، من خلال تخصيص مكتبات حالة مؤقتة لكل معاملة، وتنفيذ المعاملات بشكل متوازي في خيوط مختلفة، في تحسين القدرة على معالجة المعاملات في EVM بشكل كبير. من خلال تحسين عمليات القراءة والكتابة وإدخال آلية كشف التصادم، يمكن لسلسلة الكتل العامة EVM تحقيق التوازي الواسع للمعاملات مع ضمان اتساق الحالة، مما يحل اختناقات الأداء الناتجة عن نماذج التنفيذ التسلسلي التقليدية. وهذا يضع أساسًا مهمًا لتطور Rollup في Ethereum في المستقبل.
![باستخدام Reddio كمثال، توضيح طريق تحسين EVM المتوازي])https://img-cdn.gateio.im/webp-social/moments-af377193cf86df94c08df49ba217e327.webp(
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 20
أعجبني
20
5
إعادة النشر
مشاركة
تعليق
0/400
SocialFiQueen
· 08-05 12:02
إنها تنافس هونغ مينغ
شاهد النسخة الأصليةرد0
SerumSquirter
· 08-05 00:36
قم بتسجيل الدخول إلى reddio وابدأ العمل بسرعة
شاهد النسخة الأصليةرد0
SocialAnxietyStaker
· 08-03 20:27
متعدد الخيوط رائع啊
شاهد النسخة الأصليةرد0
GamefiEscapeArtist
· 08-03 20:25
لقد كانت عملية التحسين لفترة طويلة جدا ولكن v1 لا يزال غير جيد.
شاهد النسخة الأصليةرد0
AllInDaddy
· 08-03 20:00
من يفهم reddio مثل أخو السكين عندما يخرج من الماء.
تحسين التوازي متعدد الخيوط لـ EVM: فتح اختناق أداء Rollup
تحسين التوازي EVM: من خلال Reddio لاستكشاف طرق تحسين الأداء
من المعروف أن EVM هو أحد المكونات الأساسية في الإيثيريوم، حيث يلعب دور "محرك التنفيذ" و"بيئة تشغيل العقود الذكية". في شبكة blockchain المفتوحة التي تتكون من آلاف العقد، قد تختلف تكوينات الأجهزة بين العقد المختلفة. لضمان الحصول على نتائج تنفيذ متسقة للعقود الذكية عبر جميع العقد، أصبحت تقنية الآلة الافتراضية هي الحل المثالي.
يمكن لـ EVM تشغيل العقود الذكية بنفس الطريقة على أنظمة التشغيل والأجهزة المختلفة، وتضمن هذه التوافقية عبر المنصات حصول كل عقد على نتائج متسقة بعد تنفيذ العقد. هذا مشابه لمبدأ آلة جافا الافتراضية JVM.
العقود الذكية التي نراها في متصفح الكتلة، يتم تحويلها أولاً إلى بايت كود EVM، ثم تُخزن على السلسلة. عند تنفيذ العقد، يقوم EVM بقراءة هذه البايت كود بالتسلسل، وكل تعليمة لها تكلفة غاز محددة. يتتبع EVM استهلاك الغاز أثناء تنفيذ كل تعليمة، ويعتمد مقدار الاستهلاك على درجة تعقيد العملية.
كـنظام تنفيذ مركزي لإيثيريوم، يتبنى EVM معالجة المعاملات بطريقة تسلسلية، حيث يتم ترتيب جميع المعاملات في قائمة واحدة وتنفيذها بالتتابع وفقًا لترتيب محدد. السبب وراء عدم اعتماد الطريقة المتوازية هو أن البلوكشين يحتاج إلى ضمان صارم للتناسق، حيث يجب معالجة نفس مجموعة المعاملات بنفس الترتيب عبر جميع العقد. إذا تم مواكبة معالجة المعاملات بشكل متوازي، سيكون من الصعب التنبؤ بدقة بترتيب المعاملات، ما لم يتم إدخال خوارزميات جدولة معقدة.
في عامي 2014-2015، اختار فريق مؤسسي الإيثيريوم تصميم طريقة تنفيذ متسلسل بسيطة وسهلة الصيانة بسبب ضيق الوقت. ومع ذلك، مع تطور تقنية البلوكشين وزيادة حجم المستخدمين، أصبح الطلب على TPS والسعة أعلى. بعد ظهور تقنية Rollup ونضوجها، أصبحت قيود الأداء الناتجة عن التنفيذ المتسلسل لـ EVM واضحة بشكل ملحوظ على شبكة الإيثيريوم من الطبقة الثانية.
يعد Sequencer مكونًا رئيسيًا في Layer2، حيث يتحمل جميع مهام الحساب بشكل فردي على خادم واحد. إذا كانت كفاءة الوحدات الخارجية المتصلة بـ Sequencer عالية بما يكفي، فإن الاختناق النهائي سيعتمد على كفاءة Sequencer نفسه، وفي هذه الحالة ستصبح التنفيذ التسلسلي عقبة كبيرة.
قامت إحدى الفرق من خلال تحسينات متطرفة في طبقة DA ووحدة قراءة وكتابة البيانات، بجعل Sequencer قادراً على تنفيذ أكثر من 2000 معاملة ERC-20 في الثانية. يبدو أن هذا الرقم مرتفع جداً، ولكن إذا كانت المعاملات التي يتعين معالجتها أكثر تعقيدًا بكثير من معاملات ERC-20، فمن المؤكد أن قيمة TPS ستنخفض بشكل كبير. لذا، فإن معالجة المعاملات بشكل متوازي ستكون الاتجاه الحتمي في المستقبل.
العنصران الأساسيان في تنفيذ معاملات الإيثريوم
بخلاف EVM، فإن المكون الأساسي الآخر المرتبط بتنفيذ المعاملات في go-ethereum هو stateDB، والذي يُستخدم لإدارة حالة الحسابات وبيانات التخزين في Ethereum. تستخدم Ethereum بنية شجرية تُسمى Merkle Patricia Trie كفهرس قاعدة البيانات، حيث يقوم EVM بتغيير بعض البيانات المخزنة في stateDB مع كل تنفيذ للمعاملة، وستنعكس هذه التغييرات في النهاية في الشجرة العالمية للحالة.
تتحمل stateDB مسؤولية صيانة حالة جميع حسابات الإيثريوم، بما في ذلك حسابات EOA وحسابات العقود، والبيانات المخزنة تشمل رصيد الحساب، وكود العقد الذكي، وغيرها. خلال عملية تنفيذ الصفقة، تقوم stateDB بقراءة وكتابة البيانات الخاصة بالحسابات المعنية. بعد انتهاء تنفيذ الصفقة، تحتاج stateDB إلى تقديم الحالة الجديدة إلى قاعدة البيانات الأساسية لمعالجتها بشكل دائم.
بشكل عام، فإن EVM مسؤولة عن تفسير وتنفيذ تعليمات العقود الذكية، وتغيير حالة blockchain بناءً على نتائج الحساب، بينما تعمل stateDB كخزن للحالة العالمية، تدير جميع تغييرات حالة الحسابات والعقود. يعمل الاثنان معًا لبناء بيئة تنفيذ المعاملات في Ethereum.
عملية التنفيذ المتسلسل المحددة
تنقسم أنواع معاملات الإيثريوم إلى تحويلات EOA ومعاملات العقود. تحويلات EOA هي أبسط أنواع المعاملات، وهي تحويل ETH بين الحسابات العادية، دون استدعاء العقود، وسرعة المعالجة سريعة جدًا، والرسوم الغازية المفروضة منخفضة.
تتضمن تداول العقود استدعاء وتنفيذ العقود الذكية. عند معالجة تداول العقود، يحتاج EVM إلى تفسير وتنفيذ تعليمات بايت كود في العقد الذكي واحدة تلو الأخرى، فكلما كانت منطق العقد أكثر تعقيدًا، زادت التعليمات المعنية، وبالتالي زادت الموارد المستهلكة.
على سبيل المثال، يستغرق وقت معالجة تحويل ERC-20 حوالي ضعف وقت تحويل EOA، بينما قد يستغرق تنفيذ العمليات المعقدة للعقود الذكية، مثل عمليات التداول على بعض DEX، أضعاف وقت تحويل EOA. وذلك لأن بروتوكولات DeFi تحتاج إلى معالجة منطق معقد مثل أحواض السيولة، حساب الأسعار، وتبادل الرموز أثناء المعاملات، مما يتطلب إجراء حسابات كثيفة.
في وضع التنفيذ التسلسلي، تتعاون مكونا EVM و stateDB لمعالجة المعاملات بالطريقة التالية:
في تصميم الإيثيريوم، يتم معالجة المعاملات داخل الكتلة واحدة تلو الأخرى حسب الترتيب، حيث يتم تنفيذ كل معاملة من خلال نموذج مستقل يقوم بالعمليات المحددة. على الرغم من أن كل معاملة تستخدم نموذج EVM مختلف، إلا أن جميع المعاملات تشترك في نفس قاعدة بيانات الحالة stateDB.
خلال تنفيذ المعاملة، يحتاج EVM إلى التفاعل المستمر مع stateDB، لقراءة البيانات ذات الصلة من stateDB، وكتابة البيانات التي تم تغييرها مرة أخرى إلى stateDB.
عندما تكتمل جميع المعاملات في كتلة، يتم تقديم البيانات الموجودة في stateDB إلى شجرة الحالة العالمية، ويتم إنشاء جذر حالة جديدة. جذر الحالة هو معلمة مهمة في كل كتلة، حيث يسجل "نتيجة مضغوطة" للحالة العالمية الجديدة بعد تنفيذ الكتلة.
تظهر قيود وضع التنفيذ المتسلسل لـ EVM بوضوح: يجب تنفيذ المعاملات بالتسلسل، وإذا حدثت معاملة عقد ذكي تستغرق وقتًا طويلاً، يجب أن تنتظر المعاملات الأخرى حتى يتم معالجتها، وهذا بالطبع لا يمكن أن يستفيد بشكل كامل من موارد الأجهزة مثل وحدة المعالجة المركزية، مما يضع قيودًا كبيرة على الكفاءة.
خطة تحسين التوازي المتعدد الخيوط لـ EVM
يمكن تشبيه التنفيذ التسلسلي والتنفيذ المتوازي بوجود مكتب واحد فقط في البنك ووجود مكاتب متعددة في البنك. في وضع التوازي، يمكن فتح عدة خيوط لمعالجة عدة معاملات في نفس الوقت، مما يمكن أن يزيد الكفاءة عدة أضعاف، لكن المشكلة المعقدة هي مشكلة تعارض الحالة.
إذا كانت هناك عدة معاملات تعلن عن تعديل بيانات حساب معين، فعند معالجتها في نفس الوقت، ستحدث تعارضات. على سبيل المثال، إذا كان من الممكن سك NFT واحد فقط، وكانت المعاملة 1 والمعاملة 2 تعلنان عن رغبتهما في سك نفس NFT، إذا تم تلبية الطلبين، فمن الواضح أن هناك خطأ. في العمليات الفعلية، تحدث تعارضات الحالة بشكل أكثر تكرارًا، لذا يجب أن تتضمن معالجة المعاملات المتوازية تدابير للتعامل مع تعارضات الحالة.
مبدأ تحسين التوازي لـ Reddio على EVM
مشروع ZKRollup معين يتبنى فكرة تحسين التوازي لـ EVM من خلال تخصيص معاملة لكل خيط، وتوفير قاعدة بيانات حالة مؤقتة في كل خيط تُسمى pending-stateDB. التفاصيل المحددة على النحو التالي:
تنفيذ المعاملات بالتوازي متعدد الخيوط: إعداد عدة خيوط لمعالجة معاملات مختلفة في نفس الوقت، دون تدخل بين الخيوط. يمكن أن يزيد هذا من سرعة معالجة المعاملات عدة مرات.
تخصيص قاعدة بيانات حالة مؤقتة لكل خيط: يتم تخصيص قاعدة بيانات حالة مؤقتة مستقلة لكل خيط (pending-stateDB). أثناء تنفيذ المعاملات من قبل الخيوط المختلفة، لا يتم تعديل قاعدة بيانات الحالة العالمية مباشرة، بل يتم تسجيل نتائج التغييرات في الحالة مؤقتًا في pending-stateDB.
تغيير الحالة المتزامن: بعد تنفيذ جميع المعاملات داخل كتلة واحدة، سيقوم EVM بمزامنة نتائج تغييرات الحالة المسجلة في كل pending-stateDB إلى global stateDB بالتتابع. إذا لم تحدث أي تعارضات في الحالة أثناء تنفيذ المعاملات المختلفة، يمكن دمج السجلات من pending-stateDB بسلاسة في global stateDB.
لقد تم تحسين طريقة معالجة عمليات القراءة والكتابة في المشروع لضمان إمكانية الوصول الصحيح لبيانات الحالة وتجنب التعارضات:
عمليات القراءة: عندما تحتاج المعاملة إلى قراءة الحالة، يقوم EVM أولاً بالتحقق من ReadSet في الحالة المعلقة. إذا كان ReadSet يحتوي على البيانات المطلوبة، يتم قراءتها مباشرة من pending-stateDB. إذا لم يتم العثور على الزوج المفتاح-القيمة المقابل في ReadSet، يتم قراءة بيانات الحالة التاريخية من global stateDB للكتلة السابقة.
عمليات الكتابة: جميع عمليات الكتابة ( أي تعديل على الحالة ) لن يتم كتابتها مباشرة إلى قاعدة بيانات الحالة العالمية stateDB، بل ستسجل أولاً في مجموعة الكتابة WriteSet في حالة الانتظار Pending-state. بعد الانتهاء من تنفيذ المعاملة، سيتم محاولة دمج نتائج تغيير الحالة في قاعدة بيانات الحالة العالمية stateDB بعد إجراء اختبار التصادم.
تتمثل المشكلة الرئيسية في التنفيذ المتوازي في تعارض الحالة، عندما تحاول عدة معاملات قراءة وكتابة حالة نفس الحساب، تكون هذه المشكلة بارزة بشكل خاص. ولهذا تم إدخال آلية الكشف عن التعارض:
كشف التداخل: أثناء تنفيذ المعاملات، يقوم EVM بمراقبة ReadSet و WriteSet لمعاملات مختلفة. إذا اكتشف أن عدة معاملات تحاول قراءة وكتابة نفس عنصر الحالة، فإن ذلك يعتبر حدوث تداخل.
معالجة النزاعات: عند اكتشاف نزاع، سيتم وضع علامة على الصفقة المتنازع عليها بأنها تحتاج إلى إعادة التنفيذ.
بعد الانتهاء من تنفيذ جميع المعاملات، سيتم دمج سجلات التغييرات المتعددة من عدة pending-stateDB في global stateDB. إذا تم الدمج بنجاح، ستقوم EVM بتقديم الحالة النهائية إلى شجرة الحالة العالمية، وتوليد جذر حالة جديد.
تحسين التوازي متعدد الخيوط له تأثير ملحوظ على الأداء، خاصة عند التعامل مع معاملات العقود الذكية المعقدة. تظهر الأبحاث أنه في مجموعة معاملات ( ذات الحمل المنخفض من حيث التضارب، حيث توجد معاملات أقل تعارضًا أو تتشارك نفس الموارد، فإن اختبار TPS مقارنة بالتنفيذ التسلسلي التقليدي قد زاد بنحو 3-5 مرات. في حالات الحمل العالي من حيث التضارب، نظريًا، إذا تم استخدام جميع وسائل التحسين، يمكن أن تصل الزيادة إلى 60 مرة.
![باستخدام Reddio كمثال، توضيح طريق تحسين EVM المتوازية])https://img-cdn.gateio.im/webp-social/moments-4966960247a4550afa25f04eaaabbbd8.webp(
ملخص
تساهم خطة تحسين تعدد الخيوط في EVM الخاصة بالمشروع، من خلال تخصيص مكتبات حالة مؤقتة لكل معاملة، وتنفيذ المعاملات بشكل متوازي في خيوط مختلفة، في تحسين القدرة على معالجة المعاملات في EVM بشكل كبير. من خلال تحسين عمليات القراءة والكتابة وإدخال آلية كشف التصادم، يمكن لسلسلة الكتل العامة EVM تحقيق التوازي الواسع للمعاملات مع ضمان اتساق الحالة، مما يحل اختناقات الأداء الناتجة عن نماذج التنفيذ التسلسلي التقليدية. وهذا يضع أساسًا مهمًا لتطور Rollup في Ethereum في المستقبل.
![باستخدام Reddio كمثال، توضيح طريق تحسين EVM المتوازي])https://img-cdn.gateio.im/webp-social/moments-af377193cf86df94c08df49ba217e327.webp(