استكشاف تحسين EVM المتوازي: الطريق الرئيسي لتحسين كفاءة معالجة المعاملات
تؤثر أداء EVM، باعتباره محرك التنفيذ الأساسي للإيثريوم، بشكل مباشر على سعة الشبكة بأكملها. مع توسع قاعدة المستخدمين وتنوع سيناريوهات التطبيقات، أصبحت قيود نمط التنفيذ التسلسلي التقليدي أكثر وضوحًا. خاصة في حلول Layer 2، يكون اختناق أداء EVM أكثر وضوحًا. لذلك، فإن استكشاف حلول التنفيذ المتوازي أصبح اتجاهًا مهمًا لزيادة كفاءة EVM.
المكونات الأساسية لـ EVM وعملية التنفيذ المتسلسلة
EVM و stateDB هما العنصران الأساسيان في تنفيذ معاملات الإيثريوم. EVM مسؤول عن تفسير وتنفيذ تعليمات العقود الذكية، بينما تدير stateDB تخزين الحالة العالمية. في وضع التنفيذ التسلسلي التقليدي، يتم معالجة المعاملات واحدة تلو الأخرى، حيث تستخدم كل معاملة مثيلاً مستقلاً من EVM، لكن تشترك في نفس stateDB.
العملية التنفيذية المحددة كالتالي:
استدعاء دالة processBlock() لمعالجة المعاملات داخل الكتلة باستخدام دالة Process()
يتم تنفيذ دالة Process() من خلال حلقة for لتنفيذ المعاملات واحدة تلو الأخرى.
بعد الانتهاء من معالجة جميع المعاملات، استدعاء statedb.Commit() لتقديم تغيير الحالة
المشكلة الرئيسية في هذا النمط التسلسلي هي: أن المعاملات المعقدة ستعوق المعاملات اللاحقة، مما يحول دون الاستفادة الكاملة من موارد الأجهزة، مما يحد بشكل خطير من كفاءة المعالجة.
أفكار تحسين EVM المتوازية
لحل مشكلة عنق الزجاجة في كفاءة التنفيذ التسلسلي، اقترحت الصناعة خطة تحسين تنفيذ متوازٍ. الفكرة الأساسية هي: استخدام خيوط متعددة لمعالجة العديد من المعاملات في نفس الوقت، مما يزيد بشكل كبير من معدل المعالجة. لكن التحدي الرئيسي الذي يواجهه التنفيذ المتوازي هو كيفية معالجة مشكلة تعارض الحالة.
قدمت إحدى الفرق في هذا المجال خطة تحسين EVM متوازية، وتتميز بالخصائص الرئيسية التالية:
تنفيذ المعاملات بالتوازي عبر خيوط متعددة
تخصيص قاعدة بيانات الحالة المؤقتة (pending-stateDB) لكل خيط.
بعد إتمام تنفيذ الصفقة، يتم تحديث الحالة إلى stateDB العالمي
تم تحسين هذا الحل لعمليات القراءة والكتابة:
عملية القراءة: الأولوية لقراءة من pending-stateDB، وإذا لم يكن هناك، يتم القراءة من global stateDB
عمليات الكتابة: يتم أولاً تسجيل WriteSet في pending-stateDB، ثم يتم دمجه لاحقًا في global stateDB.
لحل النزاعات في الحالة، أدخلت الخطة آلية الكشف عن النزاعات:
مراقبة ReadSet و WriteSet لمعاملات مختلفة
عند اكتشاف تضارب، يتم وضع علامة على المعاملات ذات الصلة لإعادة التنفيذ
بعد الانتهاء من تنفيذ جميع المعاملات، دمج pending-stateDB في global stateDB
تحسين الأداء المتوازي
أدى تحسين التوازي متعدد الخيوط بشكل كبير إلى تعزيز أداء EVM، خاصة عند التعامل مع معاملات العقود الذكية المعقدة. وفقًا لبيانات البحث:
تحت أحمال العمل ذات التداخل المنخفض، يرتفع TPS بمقدار 3-5 مرات
في أحمال العمل عالية التوتر، يمكن أن يرتفع الأداء理论يًا حتى 60 مرة
تؤسس هذه الخطة المتوازية لزيادة أداء Ethereum وحلول Layer 2 في المستقبل. مع المزيد من تطور التكنولوجيا، مثل تحسين كفاءة التخزين، وتسريع GPU، من المتوقع أن يشهد أداء EVM تحسينات أكبر.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 16
أعجبني
16
6
مشاركة
تعليق
0/400
Whale_Whisperer
· منذ 6 س
فهم كيف نتعامل مع عنق الزجاجة في l2 أشعر أن eth على وشك الانهيار
شاهد النسخة الأصليةرد0
ContractCollector
· 08-05 12:14
من يشرح لي ما هو stateDB؟ أنا فقط أفهم أن DB تعني قاعدة بيانات.
شاهد النسخة الأصليةرد0
ApeWithNoChain
· 08-05 09:58
إذا كانت ETH قديمة جداً، فلا داعي للعب بـ parallel، من الأفضل عدم العبث بها.
شاهد النسخة الأصليةرد0
SchrodingerGas
· 08-05 09:44
غاز تحسين تحسين حقا ليس أفضل من ضبط حد الغاز العالي على L2
شاهد النسخة الأصليةرد0
CryptoMotivator
· 08-05 09:42
لم يعد لدى عائلة الإقطاعي أي طعام متبقي، حتى L2 لا يمكنه إنقاذ ETH.
شاهد النسخة الأصليةرد0
GasFeeCrier
· 08-05 09:36
أنت تريد أن تهتز المحفظة قليلاً، L2 ليس رخيصاً أيضاً.
تحسين EVM المتوازي: اتجاه جديد لزيادة كفاءة معالجة معاملات إثيريوم
استكشاف تحسين EVM المتوازي: الطريق الرئيسي لتحسين كفاءة معالجة المعاملات
تؤثر أداء EVM، باعتباره محرك التنفيذ الأساسي للإيثريوم، بشكل مباشر على سعة الشبكة بأكملها. مع توسع قاعدة المستخدمين وتنوع سيناريوهات التطبيقات، أصبحت قيود نمط التنفيذ التسلسلي التقليدي أكثر وضوحًا. خاصة في حلول Layer 2، يكون اختناق أداء EVM أكثر وضوحًا. لذلك، فإن استكشاف حلول التنفيذ المتوازي أصبح اتجاهًا مهمًا لزيادة كفاءة EVM.
المكونات الأساسية لـ EVM وعملية التنفيذ المتسلسلة
EVM و stateDB هما العنصران الأساسيان في تنفيذ معاملات الإيثريوم. EVM مسؤول عن تفسير وتنفيذ تعليمات العقود الذكية، بينما تدير stateDB تخزين الحالة العالمية. في وضع التنفيذ التسلسلي التقليدي، يتم معالجة المعاملات واحدة تلو الأخرى، حيث تستخدم كل معاملة مثيلاً مستقلاً من EVM، لكن تشترك في نفس stateDB.
العملية التنفيذية المحددة كالتالي:
المشكلة الرئيسية في هذا النمط التسلسلي هي: أن المعاملات المعقدة ستعوق المعاملات اللاحقة، مما يحول دون الاستفادة الكاملة من موارد الأجهزة، مما يحد بشكل خطير من كفاءة المعالجة.
أفكار تحسين EVM المتوازية
لحل مشكلة عنق الزجاجة في كفاءة التنفيذ التسلسلي، اقترحت الصناعة خطة تحسين تنفيذ متوازٍ. الفكرة الأساسية هي: استخدام خيوط متعددة لمعالجة العديد من المعاملات في نفس الوقت، مما يزيد بشكل كبير من معدل المعالجة. لكن التحدي الرئيسي الذي يواجهه التنفيذ المتوازي هو كيفية معالجة مشكلة تعارض الحالة.
قدمت إحدى الفرق في هذا المجال خطة تحسين EVM متوازية، وتتميز بالخصائص الرئيسية التالية:
تم تحسين هذا الحل لعمليات القراءة والكتابة:
لحل النزاعات في الحالة، أدخلت الخطة آلية الكشف عن النزاعات:
تحسين الأداء المتوازي
أدى تحسين التوازي متعدد الخيوط بشكل كبير إلى تعزيز أداء EVM، خاصة عند التعامل مع معاملات العقود الذكية المعقدة. وفقًا لبيانات البحث:
تؤسس هذه الخطة المتوازية لزيادة أداء Ethereum وحلول Layer 2 في المستقبل. مع المزيد من تطور التكنولوجيا، مثل تحسين كفاءة التخزين، وتسريع GPU، من المتوقع أن يشهد أداء EVM تحسينات أكبر.