تحسين التوازي في EVM: المفتاح لتعزيز أداء البلوكتشين
تعتبر EVM كأداة التنفيذ الأساسية للإيثريوم، وقد اعتمدت دائمًا على معالجة المعاملات بطريقة تسلسلية. هذه الطريقة على الرغم من أنها بسيطة وسهلة الصيانة، إلا أنه مع توسع قاعدة المستخدمين والتقدم التكنولوجي، أصبحت عوائق أدائها بارزة بشكل متزايد. خاصة في ظل الاستخدام الواسع لتقنية Rollup اليوم، أصبحت التنفيذ التسلسلي للEVM عاملاً مقيدًا لتطور الشبكات من المستوى الثاني.
تعتبر Sequencer العنصر الأساسي في Layer2، حيث تتحمل جميع مهام الحساب في شكل خادم واحد. عندما تكون كفاءة الوحدات الأخرى مرتفعة بما فيه الكفاية، تصبح قدرة معالجة Sequencer نفسها هي الاختناق النهائي. قامت بعض الفرق من خلال تحسين طبقة DA ووحدات قراءة وكتابة البيانات، بجعل Sequencer قادرًا على تنفيذ حوالي 2000 معاملة ERC-20 في الثانية. يبدو أن هذا الرقم ليس منخفضًا، ولكن عند مواجهة معاملات أكثر تعقيدًا، ستنخفض TPS بشكل كبير. لذلك، فإن توازي معالجة المعاملات أصبح الاتجاه الحتمي للتطور في المستقبل.
في هيكلية كود الإيثيريوم، بالإضافة إلى EVM، فإن stateDB هو أيضاً مكون أساسي مرتبط بشكل وثيق بتنفيذ المعاملات. إنه مسؤول عن إدارة حالة الحسابات وبيانات التخزين في الإيثيريوم. كل مرة يقوم فيها EVM بتنفيذ معاملة، فإنه يغير بعض البيانات في stateDB، وهذه التغييرات تنعكس في شجرة الحالة العالمية في النهاية.
تقوم stateDB بالحفاظ على حالة جميع حسابات الإيثيريوم، بما في ذلك الحسابات العادية وحسابات العقود، وتخزين رصيد الحساب، ورمز العقد الذكي، وغيرها من المعلومات. خلال عملية تنفيذ المعاملات، تقوم stateDB بقراءة وكتابة بيانات الحسابات المعنية، وبعد انتهاء التنفيذ، يتم تقديم الحالة الجديدة إلى قاعدة البيانات الأساسية لحفظها بشكل دائم.
في نموذج التنفيذ التسلسلي التقليدي، يتم معالجة المعاملات داخل كتلة واحدة بالتتابع. كل معاملة لديها مثيل EVM مستقل ينفذ العمليات المحددة، لكن جميع المعاملات تشارك نفس stateDB. يحتاج EVM خلال عملية التنفيذ إلى التفاعل بشكل متكرر مع stateDB، لقراءة وكتابة البيانات ذات الصلة.
عيوب نمط التنفيذ المتسلسل واضحة للغاية: يجب أن تنتظر المعاملات في طوابير للتنفيذ، وإذا واجهت معاملات عقود معقدة تستغرق وقتًا طويلاً، يجب أن تنتظر المعاملات اللاحقة بشكل قسري، مما يمنع الاستفادة الكاملة من موارد الأجهزة، مما يحد بشكل كبير من كفاءة المعالجة.
لتجاوز هذه العقبة، اقترحت الصناعة خطة تحسين متعددة الخيوط لـ EVM. الفكرة الأساسية هي فتح عدة خيوط لمعالجة العديد من المعاملات في وقت واحد، مما يزيد الكفاءة بشكل كبير. ومع ذلك، فإن التحدي الرئيسي الذي يواجه التنفيذ المتوازي هو كيفية التعامل مع مشكلة تعارض الحالة.
تستحق فكرة تحسين التوازي لـ EVM لمشروع معين الاهتمام. لقد خصصوا صفقة واحدة وقاعدة بيانات حالة مؤقتة (pending-stateDB) لكل خيط. الخطوات المحددة على النحو التالي:
تنفيذ المعاملات بالتوازي عبر خيوط متعددة، حيث لا تتداخل الخيوط مع بعضها.
كل خيط لديه قاعدة بيانات حالة مؤقتة مستقلة، وعند تنفيذ المعاملات لا يتم تعديل قاعدة بيانات الحالة العالمية مباشرة، بل يتم تخزين تغييرات الحالة مؤقتًا في قاعدة بيانات الحالة المؤقتة.
بعد الانتهاء من تنفيذ جميع المعاملات داخل الكتلة، سيقوم EVM بمزامنة التغييرات في الحالة من قاعدة بيانات الحالة المعلقة إلى قاعدة بيانات الحالة العالمية.
لقد قام هذا المشروع أيضًا بتحسين عمليات القراءة والكتابة:
أثناء عملية القراءة، تتحقق EVM أولاً من ReadSet في الحالة المعلقة. إذا كانت البيانات المطلوبة موجودة، يتم قراءتها مباشرة من pending-stateDB؛ وإلا يتم قراءة الحالة التاريخية من global stateDB للكتلة السابقة.
لا تكتب العمليات مباشرة في stateDB العالمي، بل تسجل أولاً في WriteSet الخاص بحالة الانتظار. بعد الانتهاء من تنفيذ المعاملة، يتم محاولة دمجها في stateDB العالمي من خلال الكشف عن التعارض.
لحل مشكلة تعارض الحالة، قدم المشروع آلية كشف التعارض:
خلال عملية التنفيذ، يتم مراقبة ReadSet و WriteSet لمعاملات مختلفة، وعند اكتشاف أن معاملات متعددة تقرأ وتكتب نفس عناصر الحالة، تعتبر هذه حالة تضارب.
وسم المعاملات المتضاربة على أنها تحتاج إلى إعادة التنفيذ.
بعد تنفيذ جميع المعاملات، يتم دمج سجلات التغييرات في قاعدة البيانات ذات الحالة المعلقة المتعددة في قاعدة البيانات العالمية ذات الحالة. بعد الدمج بنجاح، يتم تقديم الحالة النهائية إلى شجرة الحالة العالمية، مما ينتج عنه جذر حالة جديد.
تحسينات التوازي متعددة الخيوط قد عززت الأداء بشكل ملحوظ، خاصة عند معالجة صفقات العقود الذكية المعقدة. تشير الأبحاث إلى أن اختبار TPS تحت أحمال العمل ذات التداخل المنخفض قد زاد بمعدل 3-5 مرات مقارنة بالتنفيذ التسلسلي التقليدي. في أحمال العمل ذات التداخل العالي، يمكن نظريًا أن تصل الزيادة إلى 60 مرة عند استخدام جميع وسائل التحسين.
تعمل هذه الخطة لتحسين التوازي متعدد الخيوط لـ EVM على تحسين قدرة معالجة المعاملات بشكل كبير من خلال تخصيص مكتبة حالة مؤقتة لكل معاملة وتنفيذها بشكل متوازي في خيوط مختلفة. من خلال تحسين عمليات القراءة والكتابة وإدخال آلية الكشف عن التصادم، تم تحقيق التوازي على نطاق واسع للمعاملات مع ضمان اتساق الحالة، مما يحل بشكل فعال عنق الزجاجة في أداء نموذج التنفيذ التسلسلي التقليدي. وهذا يضع أساسًا مهمًا لتوسيع نظام Ethereum البيئي في المستقبل.
قد تشمل اتجاهات البحث المستقبلية تحسين كفاءة التخزين بشكل أكبر، وتحسين الحلول في حالات التعارض العالي، واستكشاف استخدام GPU في التحسين. ستوفر هذه التقدمات دافعاً جديداً للتطور المستمر لتكنولوجيا البلوكتشين.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 14
أعجبني
14
7
إعادة النشر
مشاركة
تعليق
0/400
MEVVictimAlliance
· منذ 17 س
تسابق للحصول على الأمور، لقد أوقفتني!
شاهد النسخة الأصليةرد0
MelonField
· منذ 17 س
لا تزال تتحدث عن evm، والمظهر ليس جميلاً.
شاهد النسخة الأصليةرد0
MetaDreamer
· منذ 17 س
تحسين الأداء بمقدار 60 مرة؟ gm عليه أن يبدأ في العمل مرة أخرى.
شاهد النسخة الأصليةرد0
TestnetScholar
· منذ 17 س
هذه البطاقة، أسرع في تحسينها
شاهد النسخة الأصليةرد0
faded_wojak.eth
· منذ 17 س
كارلا للقمر啊
شاهد النسخة الأصليةرد0
BugBountyHunter
· منذ 17 س
إذا توقفت فعليك أن تتعاون وتعمل بجد!
شاهد النسخة الأصليةرد0
DefiPlaybook
· منذ 17 س
هذا الاختناق لا ينتظر سوى أن يتم سحبه، بوتات الهجوم في قمة الفرح.
تحسين التوازي في EVM: التقنية الرئيسية لزيادة أداء البلوكتشين بمقدار 60 ضعفًا
تحسين التوازي في EVM: المفتاح لتعزيز أداء البلوكتشين
تعتبر EVM كأداة التنفيذ الأساسية للإيثريوم، وقد اعتمدت دائمًا على معالجة المعاملات بطريقة تسلسلية. هذه الطريقة على الرغم من أنها بسيطة وسهلة الصيانة، إلا أنه مع توسع قاعدة المستخدمين والتقدم التكنولوجي، أصبحت عوائق أدائها بارزة بشكل متزايد. خاصة في ظل الاستخدام الواسع لتقنية Rollup اليوم، أصبحت التنفيذ التسلسلي للEVM عاملاً مقيدًا لتطور الشبكات من المستوى الثاني.
تعتبر Sequencer العنصر الأساسي في Layer2، حيث تتحمل جميع مهام الحساب في شكل خادم واحد. عندما تكون كفاءة الوحدات الأخرى مرتفعة بما فيه الكفاية، تصبح قدرة معالجة Sequencer نفسها هي الاختناق النهائي. قامت بعض الفرق من خلال تحسين طبقة DA ووحدات قراءة وكتابة البيانات، بجعل Sequencer قادرًا على تنفيذ حوالي 2000 معاملة ERC-20 في الثانية. يبدو أن هذا الرقم ليس منخفضًا، ولكن عند مواجهة معاملات أكثر تعقيدًا، ستنخفض TPS بشكل كبير. لذلك، فإن توازي معالجة المعاملات أصبح الاتجاه الحتمي للتطور في المستقبل.
في هيكلية كود الإيثيريوم، بالإضافة إلى EVM، فإن stateDB هو أيضاً مكون أساسي مرتبط بشكل وثيق بتنفيذ المعاملات. إنه مسؤول عن إدارة حالة الحسابات وبيانات التخزين في الإيثيريوم. كل مرة يقوم فيها EVM بتنفيذ معاملة، فإنه يغير بعض البيانات في stateDB، وهذه التغييرات تنعكس في شجرة الحالة العالمية في النهاية.
تقوم stateDB بالحفاظ على حالة جميع حسابات الإيثيريوم، بما في ذلك الحسابات العادية وحسابات العقود، وتخزين رصيد الحساب، ورمز العقد الذكي، وغيرها من المعلومات. خلال عملية تنفيذ المعاملات، تقوم stateDB بقراءة وكتابة بيانات الحسابات المعنية، وبعد انتهاء التنفيذ، يتم تقديم الحالة الجديدة إلى قاعدة البيانات الأساسية لحفظها بشكل دائم.
في نموذج التنفيذ التسلسلي التقليدي، يتم معالجة المعاملات داخل كتلة واحدة بالتتابع. كل معاملة لديها مثيل EVM مستقل ينفذ العمليات المحددة، لكن جميع المعاملات تشارك نفس stateDB. يحتاج EVM خلال عملية التنفيذ إلى التفاعل بشكل متكرر مع stateDB، لقراءة وكتابة البيانات ذات الصلة.
عيوب نمط التنفيذ المتسلسل واضحة للغاية: يجب أن تنتظر المعاملات في طوابير للتنفيذ، وإذا واجهت معاملات عقود معقدة تستغرق وقتًا طويلاً، يجب أن تنتظر المعاملات اللاحقة بشكل قسري، مما يمنع الاستفادة الكاملة من موارد الأجهزة، مما يحد بشكل كبير من كفاءة المعالجة.
لتجاوز هذه العقبة، اقترحت الصناعة خطة تحسين متعددة الخيوط لـ EVM. الفكرة الأساسية هي فتح عدة خيوط لمعالجة العديد من المعاملات في وقت واحد، مما يزيد الكفاءة بشكل كبير. ومع ذلك، فإن التحدي الرئيسي الذي يواجه التنفيذ المتوازي هو كيفية التعامل مع مشكلة تعارض الحالة.
تستحق فكرة تحسين التوازي لـ EVM لمشروع معين الاهتمام. لقد خصصوا صفقة واحدة وقاعدة بيانات حالة مؤقتة (pending-stateDB) لكل خيط. الخطوات المحددة على النحو التالي:
تنفيذ المعاملات بالتوازي عبر خيوط متعددة، حيث لا تتداخل الخيوط مع بعضها.
كل خيط لديه قاعدة بيانات حالة مؤقتة مستقلة، وعند تنفيذ المعاملات لا يتم تعديل قاعدة بيانات الحالة العالمية مباشرة، بل يتم تخزين تغييرات الحالة مؤقتًا في قاعدة بيانات الحالة المؤقتة.
بعد الانتهاء من تنفيذ جميع المعاملات داخل الكتلة، سيقوم EVM بمزامنة التغييرات في الحالة من قاعدة بيانات الحالة المعلقة إلى قاعدة بيانات الحالة العالمية.
لقد قام هذا المشروع أيضًا بتحسين عمليات القراءة والكتابة:
أثناء عملية القراءة، تتحقق EVM أولاً من ReadSet في الحالة المعلقة. إذا كانت البيانات المطلوبة موجودة، يتم قراءتها مباشرة من pending-stateDB؛ وإلا يتم قراءة الحالة التاريخية من global stateDB للكتلة السابقة.
لا تكتب العمليات مباشرة في stateDB العالمي، بل تسجل أولاً في WriteSet الخاص بحالة الانتظار. بعد الانتهاء من تنفيذ المعاملة، يتم محاولة دمجها في stateDB العالمي من خلال الكشف عن التعارض.
لحل مشكلة تعارض الحالة، قدم المشروع آلية كشف التعارض:
خلال عملية التنفيذ، يتم مراقبة ReadSet و WriteSet لمعاملات مختلفة، وعند اكتشاف أن معاملات متعددة تقرأ وتكتب نفس عناصر الحالة، تعتبر هذه حالة تضارب.
وسم المعاملات المتضاربة على أنها تحتاج إلى إعادة التنفيذ.
بعد تنفيذ جميع المعاملات، يتم دمج سجلات التغييرات في قاعدة البيانات ذات الحالة المعلقة المتعددة في قاعدة البيانات العالمية ذات الحالة. بعد الدمج بنجاح، يتم تقديم الحالة النهائية إلى شجرة الحالة العالمية، مما ينتج عنه جذر حالة جديد.
تحسينات التوازي متعددة الخيوط قد عززت الأداء بشكل ملحوظ، خاصة عند معالجة صفقات العقود الذكية المعقدة. تشير الأبحاث إلى أن اختبار TPS تحت أحمال العمل ذات التداخل المنخفض قد زاد بمعدل 3-5 مرات مقارنة بالتنفيذ التسلسلي التقليدي. في أحمال العمل ذات التداخل العالي، يمكن نظريًا أن تصل الزيادة إلى 60 مرة عند استخدام جميع وسائل التحسين.
تعمل هذه الخطة لتحسين التوازي متعدد الخيوط لـ EVM على تحسين قدرة معالجة المعاملات بشكل كبير من خلال تخصيص مكتبة حالة مؤقتة لكل معاملة وتنفيذها بشكل متوازي في خيوط مختلفة. من خلال تحسين عمليات القراءة والكتابة وإدخال آلية الكشف عن التصادم، تم تحقيق التوازي على نطاق واسع للمعاملات مع ضمان اتساق الحالة، مما يحل بشكل فعال عنق الزجاجة في أداء نموذج التنفيذ التسلسلي التقليدي. وهذا يضع أساسًا مهمًا لتوسيع نظام Ethereum البيئي في المستقبل.
قد تشمل اتجاهات البحث المستقبلية تحسين كفاءة التخزين بشكل أكبر، وتحسين الحلول في حالات التعارض العالي، واستكشاف استخدام GPU في التحسين. ستوفر هذه التقدمات دافعاً جديداً للتطور المستمر لتكنولوجيا البلوكتشين.