تحسين التوازي في EVM: تعزيز كفاءة معالجة معاملات إثيريوم
تعتبر EVM محرك التنفيذ الأساسي لإثيريوم، حيث يتم تحديد دورها "بيئة تنفيذ العقود الذكية". لضمان الحصول على نتائج متسقة للعقود الذكية على مختلف العقد، توفر EVM بيئة افتراضية متعددة المنصات، مشابهة لآلة جافا الافتراضية JVM.
تُترجم العقود الذكية عند نشرها إلى كود بايت EVM وتُخزن على السلسلة. عند تنفيذ العقد، يقرأ EVM هذا الكود بايت بشكل متسلسل، ولكل أمر تكلفة غاز معينة. يتتبع EVM استهلاك الغاز أثناء تنفيذ الأوامر، ويعتمد مقدار الاستهلاك على تعقيد العمليات.
تستخدم EVM التقليدية معالجة المعاملات بطريقة تسلسلية، حيث يتم تنفيذ جميع المعاملات في قائمة واحدة وفق ترتيب محدد. تصميم هذه الطريقة بسيط وسهل الصيانة، ولكن مع زيادة حجم المستخدمين وتطبيق تقنية Rollup، أصبحت عنق الزجاجة في الأداء الناتج عن التنفيذ التسلسلي بارزة بشكل متزايد.
في بنية Rollup، تتولى Sequencer كعنصر أساسي في Layer2 جميع مهام العمليات. إذا كانت كفاءة الوحدات الخارجية الأخرى مرتفعة بما فيه الكفاية، فإن التنفيذ التسلسلي لـ Sequencer نفسه سيصبح أكبر عنق زجاجة. تمكنت بعض الفرق من تحسين Sequencer بشكل كبير بحيث يمكنه تنفيذ أكثر من 2000 عملية تحويل ERC-20 في الثانية، ولكن بالنسبة للمعاملات الأكثر تعقيدًا، ستظل TPS تنخفض بشكل كبير. لذلك، فإن معالجة المعاملات بشكل متوازي أصبحت الاتجاه المستقبلي.
بخلاف EVM، المكون الرئيسي الآخر المرتبط بتنفيذ المعاملات في go-ethereum هو stateDB، الذي يُستخدم لإدارة حالة الحسابات وتخزين البيانات. تستخدم إثيريوم هيكل شجرة Merkle Patricia Trie كفهرس قاعدة بيانات، حيث يتم تغيير بيانات stateDB في كل مرة يتم فيها تنفيذ صفقة بواسطة EVM، مما ينعكس في شجرة الحالة العالمية.
تتحمل stateDB مسؤولية الحفاظ على حالة جميع حسابات إثيريوم، بما في ذلك أرصدة الحسابات، وشفرات العقود الذكية، وغيرها. خلال تنفيذ المعاملات، ستقوم stateDB بقراءة وكتابة بيانات الحسابات المعنية، وبعد انتهاء التنفيذ، سيتم تقديم الحالة الجديدة إلى قاعدة البيانات الأساسية للتخزين.
تتعاون EVM و stateDB لبناء بيئة تنفيذ المعاملات لإثيريوم. EVM مسؤولة عن تفسير وتنفيذ تعليمات العقود الذكية، وتغيير حالة blockchain بناءً على نتائج الحساب، بينما تعمل stateDB كخزن للحالة العالمية، وتدير جميع تغييرات حالة الحسابات والعقود.
في وضع التنفيذ التسلسلي، يتم معالجة المعاملات داخل الكتلة واحدة تلو الأخرى. تستخدم كل معاملة مثيل EVM مستقل، ولكن جميع المعاملات تشارك نفس stateDB. يحتاج EVM أثناء التنفيذ إلى التفاعل المستمر مع stateDB، لقراءة البيانات ذات الصلة وإعادة كتابة نتائج التغييرات.
بعد تنفيذ جميع المعاملات داخل الكتلة، ستتم إضافة البيانات في stateDB إلى شجرة الحالة العالمية، مما ينتج عنه جذر حالة جديد. تعتبر هذه الوضعية المتسلسلة من القيود الرئيسية أن المعاملات يجب أن تتكدس للتنفيذ، مما يمنع الاستفادة الكاملة من موارد الأجهزة، وخاصة عند مواجهة معاملات العقود الذكية المعقدة حيث تكون الكفاءة منخفضة.
لزيادة كفاءة معالجة الصفقات، بدأت بعض المشاريع في تجربة تحسينات تزامنية متعددة الخيوط لـ EVM. يشبه هذا فتح عدة نوافذ في البنك لخدمة العملاء في نفس الوقت، مما يمكن أن يزيد من سرعة المعالجة عدة مرات، ولكن يجب حل مشكلات التعارض المحتملة في الحالة.
فكرة تحسين التوازي لـ ZKRollup معينة لـ EVM هي تخصيص قاعدة بيانات حالة مؤقتة لكل خيط (pending-stateDB). تشمل التنفيذات المحددة:
تنفيذ المعاملات بالتوازي متعدد الخيوط، دون تداخل.
كل خيط لديه قاعدة بيانات الحالة المعلقة المستقلة، يتم تسجيل تغيرات الحالة هنا أولاً عند تنفيذ المعاملات.
بعد الانتهاء من تنفيذ جميع المعاملات، سيتم مزامنة التغييرات من pending-stateDB إلى global stateDB.
تم تحسين هذا الحل لعمليات القراءة والكتابة:
عند إجراء عملية القراءة، تحقق أولاً من ReadSet في pending-stateDB، إذا كانت البيانات المطلوبة موجودة، قم بالقراءة مباشرة، وإلا استرجع الحالة التاريخية من stateDB العالمية.
لا تكتب العمليات الكتابية مباشرة إلى stateDB العالمي، بل تسجل أولاً في WriteSet الخاص بـ pending-stateDB.
لمعالجة تعارض الحالة، تم إدخال آلية كشف التعارض:
مراقبة ReadSet و WriteSet لصفقات مختلفة، وعند اكتشاف عدة صفقات تقرأ وتكتب نفس العناصر الحالة تعتبر كتصادم.
سيتم وضع علامة على المعاملات المتضاربة على أنها بحاجة إلى إعادة التنفيذ.
بعد تنفيذ جميع المعاملات، سيتم دمج سجلات التغييرات المتعددة في pending-stateDB في global stateDB، وبعد النجاح، سيتم تقديمها إلى شجرة الحالة العالمية وتوليد جذر حالة جديدة.
تظهر الأبحاث أنه في أحمال العمل ذات التداخل المنخفض، فإن TPS لـ EVM المتوازي يزيد بمقدار 3-5 مرات مقارنةً بالتنفيذ التسلسلي التقليدي. في أحمال العمل ذات التداخل العالي، يمكن أن تصل الزيادة theoretically حتى 60 مرة.
هذه الخطة لتحسين الأداء المتوازي باستخدام خيوط متعددة، من خلال مكتبة الحالة المؤقتة والتنفيذ المتوازي، قد زادت بشكل ملحوظ من قدرة معالجة المعاملات في EVM. تحسين عمليات القراءة والكتابة وإدخال آلية الكشف عن التعارض، جعلت من الممكن تحقيق تنفيذ المعاملات بالتوازي على نطاق واسع مع ضمان تماسك الحالة، مما حل قيد الأداء للتنفيذ التسلسلي، وأسس لمستقبل تطوير إثيريوم Rollup.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 10
أعجبني
10
5
مشاركة
تعليق
0/400
AirdropHunterZhang
· 07-29 02:07
لن يحدث ذلك، 60 مرة يوميًا، السعر لا يزال كما هو.
شاهد النسخة الأصليةرد0
GateUser-afe07a92
· 07-28 22:11
فقط زيادة طفيفة في TPS
شاهد النسخة الأصليةرد0
ZKProofEnthusiast
· 07-28 22:09
ما مدى سرعة التحقق من TPS على داخل السلسلة؟
شاهد النسخة الأصليةرد0
¯\_(ツ)_/¯
· 07-28 21:56
استمر في التعدين كما تريد
شاهد النسخة الأصليةرد0
GateUser-aa7df71e
· 07-28 21:48
اركبوا السيارة ، أيها الإخوة ، يرتفع TPS بشكل كبير قادم
تحسين التوازي في EVM: زيادة كفاءة معالجة معاملات إثيريوم بنسبة 5-60 مرة
تحسين التوازي في EVM: تعزيز كفاءة معالجة معاملات إثيريوم
تعتبر EVM محرك التنفيذ الأساسي لإثيريوم، حيث يتم تحديد دورها "بيئة تنفيذ العقود الذكية". لضمان الحصول على نتائج متسقة للعقود الذكية على مختلف العقد، توفر EVM بيئة افتراضية متعددة المنصات، مشابهة لآلة جافا الافتراضية JVM.
تُترجم العقود الذكية عند نشرها إلى كود بايت EVM وتُخزن على السلسلة. عند تنفيذ العقد، يقرأ EVM هذا الكود بايت بشكل متسلسل، ولكل أمر تكلفة غاز معينة. يتتبع EVM استهلاك الغاز أثناء تنفيذ الأوامر، ويعتمد مقدار الاستهلاك على تعقيد العمليات.
تستخدم EVM التقليدية معالجة المعاملات بطريقة تسلسلية، حيث يتم تنفيذ جميع المعاملات في قائمة واحدة وفق ترتيب محدد. تصميم هذه الطريقة بسيط وسهل الصيانة، ولكن مع زيادة حجم المستخدمين وتطبيق تقنية Rollup، أصبحت عنق الزجاجة في الأداء الناتج عن التنفيذ التسلسلي بارزة بشكل متزايد.
في بنية Rollup، تتولى Sequencer كعنصر أساسي في Layer2 جميع مهام العمليات. إذا كانت كفاءة الوحدات الخارجية الأخرى مرتفعة بما فيه الكفاية، فإن التنفيذ التسلسلي لـ Sequencer نفسه سيصبح أكبر عنق زجاجة. تمكنت بعض الفرق من تحسين Sequencer بشكل كبير بحيث يمكنه تنفيذ أكثر من 2000 عملية تحويل ERC-20 في الثانية، ولكن بالنسبة للمعاملات الأكثر تعقيدًا، ستظل TPS تنخفض بشكل كبير. لذلك، فإن معالجة المعاملات بشكل متوازي أصبحت الاتجاه المستقبلي.
بخلاف EVM، المكون الرئيسي الآخر المرتبط بتنفيذ المعاملات في go-ethereum هو stateDB، الذي يُستخدم لإدارة حالة الحسابات وتخزين البيانات. تستخدم إثيريوم هيكل شجرة Merkle Patricia Trie كفهرس قاعدة بيانات، حيث يتم تغيير بيانات stateDB في كل مرة يتم فيها تنفيذ صفقة بواسطة EVM، مما ينعكس في شجرة الحالة العالمية.
تتحمل stateDB مسؤولية الحفاظ على حالة جميع حسابات إثيريوم، بما في ذلك أرصدة الحسابات، وشفرات العقود الذكية، وغيرها. خلال تنفيذ المعاملات، ستقوم stateDB بقراءة وكتابة بيانات الحسابات المعنية، وبعد انتهاء التنفيذ، سيتم تقديم الحالة الجديدة إلى قاعدة البيانات الأساسية للتخزين.
تتعاون EVM و stateDB لبناء بيئة تنفيذ المعاملات لإثيريوم. EVM مسؤولة عن تفسير وتنفيذ تعليمات العقود الذكية، وتغيير حالة blockchain بناءً على نتائج الحساب، بينما تعمل stateDB كخزن للحالة العالمية، وتدير جميع تغييرات حالة الحسابات والعقود.
في وضع التنفيذ التسلسلي، يتم معالجة المعاملات داخل الكتلة واحدة تلو الأخرى. تستخدم كل معاملة مثيل EVM مستقل، ولكن جميع المعاملات تشارك نفس stateDB. يحتاج EVM أثناء التنفيذ إلى التفاعل المستمر مع stateDB، لقراءة البيانات ذات الصلة وإعادة كتابة نتائج التغييرات.
بعد تنفيذ جميع المعاملات داخل الكتلة، ستتم إضافة البيانات في stateDB إلى شجرة الحالة العالمية، مما ينتج عنه جذر حالة جديد. تعتبر هذه الوضعية المتسلسلة من القيود الرئيسية أن المعاملات يجب أن تتكدس للتنفيذ، مما يمنع الاستفادة الكاملة من موارد الأجهزة، وخاصة عند مواجهة معاملات العقود الذكية المعقدة حيث تكون الكفاءة منخفضة.
لزيادة كفاءة معالجة الصفقات، بدأت بعض المشاريع في تجربة تحسينات تزامنية متعددة الخيوط لـ EVM. يشبه هذا فتح عدة نوافذ في البنك لخدمة العملاء في نفس الوقت، مما يمكن أن يزيد من سرعة المعالجة عدة مرات، ولكن يجب حل مشكلات التعارض المحتملة في الحالة.
فكرة تحسين التوازي لـ ZKRollup معينة لـ EVM هي تخصيص قاعدة بيانات حالة مؤقتة لكل خيط (pending-stateDB). تشمل التنفيذات المحددة:
تنفيذ المعاملات بالتوازي متعدد الخيوط، دون تداخل.
كل خيط لديه قاعدة بيانات الحالة المعلقة المستقلة، يتم تسجيل تغيرات الحالة هنا أولاً عند تنفيذ المعاملات.
بعد الانتهاء من تنفيذ جميع المعاملات، سيتم مزامنة التغييرات من pending-stateDB إلى global stateDB.
تم تحسين هذا الحل لعمليات القراءة والكتابة:
عند إجراء عملية القراءة، تحقق أولاً من ReadSet في pending-stateDB، إذا كانت البيانات المطلوبة موجودة، قم بالقراءة مباشرة، وإلا استرجع الحالة التاريخية من stateDB العالمية.
لا تكتب العمليات الكتابية مباشرة إلى stateDB العالمي، بل تسجل أولاً في WriteSet الخاص بـ pending-stateDB.
لمعالجة تعارض الحالة، تم إدخال آلية كشف التعارض:
مراقبة ReadSet و WriteSet لصفقات مختلفة، وعند اكتشاف عدة صفقات تقرأ وتكتب نفس العناصر الحالة تعتبر كتصادم.
سيتم وضع علامة على المعاملات المتضاربة على أنها بحاجة إلى إعادة التنفيذ.
بعد تنفيذ جميع المعاملات، سيتم دمج سجلات التغييرات المتعددة في pending-stateDB في global stateDB، وبعد النجاح، سيتم تقديمها إلى شجرة الحالة العالمية وتوليد جذر حالة جديدة.
تظهر الأبحاث أنه في أحمال العمل ذات التداخل المنخفض، فإن TPS لـ EVM المتوازي يزيد بمقدار 3-5 مرات مقارنةً بالتنفيذ التسلسلي التقليدي. في أحمال العمل ذات التداخل العالي، يمكن أن تصل الزيادة theoretically حتى 60 مرة.
هذه الخطة لتحسين الأداء المتوازي باستخدام خيوط متعددة، من خلال مكتبة الحالة المؤقتة والتنفيذ المتوازي، قد زادت بشكل ملحوظ من قدرة معالجة المعاملات في EVM. تحسين عمليات القراءة والكتابة وإدخال آلية الكشف عن التعارض، جعلت من الممكن تحقيق تنفيذ المعاملات بالتوازي على نطاق واسع مع ضمان تماسك الحالة، مما حل قيد الأداء للتنفيذ التسلسلي، وأسس لمستقبل تطوير إثيريوم Rollup.