الطريق نحو التوازي في EVM: من التنفيذ التسلسلي إلى التنفيذ متعدد الخيوط
من المعروف أن EVM هو محرك التنفيذ الأساسي للإيثريوم، المسؤول عن تشغيل العقود الذكية. لضمان أن العقود الذكية على عقد مختلفة يمكن أن تحصل على نفس نتائج التنفيذ، يوفر EVM بيئة افتراضية موحدة، تشبه إلى حد كبير JVM الخاصة بلغة Java.
عند نشر العقود الذكية على البلوكتشين، يتم أولاً تجميعها إلى كود بايت EVM. عند تنفيذ العقد، يقوم EVM بقراءة هذا الكود البايت بالتسلسل، ولكل تعليمات تكلفة غاز معينة. يتتبع EVM استهلاك الغاز لكل تعليمات يتم تنفيذها، والكمية المستهلكة تعتمد على تعقيد العملية.
تستخدم EVM التقليدية طريقة المعالجة المتسلسلة للمعاملات، حيث يتم وضع جميع المعاملات في قائمة انتظار واحدة وتنفيذها بالتسلسل. هذه التصميم بسيط وسهل الصيانة، ولكن مع زيادة عدد المستخدمين وارتفاع متطلبات TPS، أصبحت عنق الزجاجة في الأداء الناتج عن التنفيذ المتسلسل واضحة بشكل متزايد، خاصة في حلول Layer 2.
بخلاف EVM، فإن المكون الأساسي الآخر لتنفيذ معاملات الإيثيريوم هو stateDB، الذي يستخدم لإدارة حالة الحسابات وتخزين البيانات. يقوم EVM بتحديث البيانات في stateDB في كل مرة يتم فيها تنفيذ معاملة، وتعكس هذه التغييرات في النهاية في شجرة الحالة العالمية.
في وضع التنفيذ التسلسلي، تكون عملية تعاون EVM و stateDB في معالجة المعاملات كما يلي:
تتم معالجة المعاملات داخل الكتلة الواحدة واحدة تلو الأخرى.
كل معاملة تستخدم مثيل EVM مستقل، لكنها تشترك في نفس stateDB
خلال عملية تنفيذ EVM، يتم التفاعل باستمرار مع stateDB، لقراءة وكتابة البيانات.
بعد معالجة جميع المعاملات، سيتم提交 التغييرات في stateDB إلى شجرة الحالة العالمية.
المشكلة الرئيسية في نمط السلسلة هذا هي أن معاملات العقود الذكية المعقدة ستعوق المعاملات الأخرى، مما يمنع الاستفادة الكاملة من موارد الأجهزة.
لحل هذه المشكلة، بدأت بعض المشاريع في استكشاف حلول تحسين التوازي لـ EVM. كمثال على مشروع Layer 2 معين، فإن الفكرة الأساسية هي تخصيص قاعدة بيانات حالة مؤقتة لكل خيط (pending-stateDB):
تنفيذ معاملات مختلفة بشكل متوازي متعدد الخيوط
كل خيط يستخدم سجل حالة مستقل pending-stateDB لتسجيل تغييرات الحالة
بعد انتهاء جميع المعاملات، سيتم مزامنة التغييرات من pending-stateDB إلى global stateDB.
تمت معالجة عمليات القراءة والكتابة بشكل خاص في هذه الخطة:
عمليات القراءة تعطي الأولوية لفحص pending-stateDB، وإذا لم توجد بيانات يتم قراءة global stateDB.
عمليات الكتابة مؤقتة في pending-stateDB، ولا تعدل stateDB العالمية مباشرة.
لتجنب تعارض الحالة، قدمت هذه الخطة آلية كشف التعارض:
رصد ما إذا كانت هناك تداخلات في مجموعات القراءة والكتابة لمعاملات مختلفة
عند اكتشاف تعارض، يجب إعادة تنفيذ المعاملات ذات الصلة
أخيرًا، يتم دمج التغييرات المتعددة في pending-stateDB في global stateDB، لإنشاء جذر حالة جديدة.
يمكن أن يزيد هذا الحل الأمثل المتوازي من معدل المعاملات في الثانية (TPS) من 3 إلى 5 مرات تحت أحمال العمل ذات الصراع المنخفض. في حالات الصراع العالي، يمكن أن تصل الزيادة نظريًا إلى 60 مرة.
بشكل عام، تعتبر التوازي في EVM اتجاهًا مهمًا لتحسين أداء Ethereum و Layer 2 الخاص بها. من خلال تقنيات مثل التنفيذ المتوازي متعدد الخيوط ومكتبات الحالة المؤقتة، يمكن زيادة قدرة معالجة المعاملات بشكل كبير مع ضمان التناسق. في المستقبل، يمكن أيضًا تحسين أداء EVM من خلال تحسين كفاءة التخزين، وتحسين استراتيجيات معالجة التضارب، وغيرها من الوسائل.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 8
أعجبني
8
5
مشاركة
تعليق
0/400
FlatTax
· 07-24 20:11
60倍؟ ثور不上税
شاهد النسخة الأصليةرد0
FastLeaver
· 07-22 02:02
ليس سيئًا، يمكن أن يزيد TPS بمقدار 60 مرة
شاهد النسخة الأصليةرد0
NftDeepBreather
· 07-22 00:27
بعد ذلك، عودة ملك البيتكوين
شاهد النسخة الأصليةرد0
CounterIndicator
· 07-22 00:11
صاعد يعني القمة، هبوط يعني القاع
شاهد النسخة الأصليةرد0
SerumDegen
· 07-22 00:10
مجرد ضخة سعر أخرى لكوبيم لإثراء الإيثيريوم بصراحة... يظهر لي الأرقام الحقيقية لسرعة المعاملات أولاً
اختراق توازي EVM: تنفيذ متعدد الخيوط يعزز قدرة معالجة المعاملات
الطريق نحو التوازي في EVM: من التنفيذ التسلسلي إلى التنفيذ متعدد الخيوط
من المعروف أن EVM هو محرك التنفيذ الأساسي للإيثريوم، المسؤول عن تشغيل العقود الذكية. لضمان أن العقود الذكية على عقد مختلفة يمكن أن تحصل على نفس نتائج التنفيذ، يوفر EVM بيئة افتراضية موحدة، تشبه إلى حد كبير JVM الخاصة بلغة Java.
عند نشر العقود الذكية على البلوكتشين، يتم أولاً تجميعها إلى كود بايت EVM. عند تنفيذ العقد، يقوم EVM بقراءة هذا الكود البايت بالتسلسل، ولكل تعليمات تكلفة غاز معينة. يتتبع EVM استهلاك الغاز لكل تعليمات يتم تنفيذها، والكمية المستهلكة تعتمد على تعقيد العملية.
تستخدم EVM التقليدية طريقة المعالجة المتسلسلة للمعاملات، حيث يتم وضع جميع المعاملات في قائمة انتظار واحدة وتنفيذها بالتسلسل. هذه التصميم بسيط وسهل الصيانة، ولكن مع زيادة عدد المستخدمين وارتفاع متطلبات TPS، أصبحت عنق الزجاجة في الأداء الناتج عن التنفيذ المتسلسل واضحة بشكل متزايد، خاصة في حلول Layer 2.
بخلاف EVM، فإن المكون الأساسي الآخر لتنفيذ معاملات الإيثيريوم هو stateDB، الذي يستخدم لإدارة حالة الحسابات وتخزين البيانات. يقوم EVM بتحديث البيانات في stateDB في كل مرة يتم فيها تنفيذ معاملة، وتعكس هذه التغييرات في النهاية في شجرة الحالة العالمية.
في وضع التنفيذ التسلسلي، تكون عملية تعاون EVM و stateDB في معالجة المعاملات كما يلي:
المشكلة الرئيسية في نمط السلسلة هذا هي أن معاملات العقود الذكية المعقدة ستعوق المعاملات الأخرى، مما يمنع الاستفادة الكاملة من موارد الأجهزة.
لحل هذه المشكلة، بدأت بعض المشاريع في استكشاف حلول تحسين التوازي لـ EVM. كمثال على مشروع Layer 2 معين، فإن الفكرة الأساسية هي تخصيص قاعدة بيانات حالة مؤقتة لكل خيط (pending-stateDB):
تمت معالجة عمليات القراءة والكتابة بشكل خاص في هذه الخطة:
لتجنب تعارض الحالة، قدمت هذه الخطة آلية كشف التعارض:
أخيرًا، يتم دمج التغييرات المتعددة في pending-stateDB في global stateDB، لإنشاء جذر حالة جديدة.
يمكن أن يزيد هذا الحل الأمثل المتوازي من معدل المعاملات في الثانية (TPS) من 3 إلى 5 مرات تحت أحمال العمل ذات الصراع المنخفض. في حالات الصراع العالي، يمكن أن تصل الزيادة نظريًا إلى 60 مرة.
بشكل عام، تعتبر التوازي في EVM اتجاهًا مهمًا لتحسين أداء Ethereum و Layer 2 الخاص بها. من خلال تقنيات مثل التنفيذ المتوازي متعدد الخيوط ومكتبات الحالة المؤقتة، يمكن زيادة قدرة معالجة المعاملات بشكل كبير مع ضمان التناسق. في المستقبل، يمكن أيضًا تحسين أداء EVM من خلال تحسين كفاءة التخزين، وتحسين استراتيجيات معالجة التضارب، وغيرها من الوسائل.