من المعروف أن EVM هو أحد المكونات الأساسية الأكثر أهمية في Ethereum، حيث يلعب دور "محرك التنفيذ" و "بيئة تنفيذ العقود الذكية" بشكل حاسم. في شبكة البلوكتشين العامة المكونة من آلاف العقد، يضمن وجود الآلة الافتراضية أن العقود الذكية يمكن أن تعمل بنفس الطريقة على عقد ذات تكوينات أجهزة مختلفة، مما يضمن اتساق النتائج. هذه التوافقية عبر الأنظمة الأساسية تشبه إلى حد كبير آلة جافا الافتراضية JVM.
يتم تجميع العقود الذكية إلى بايت كود EVM قبل أن تُرفع إلى السلسلة. عند تنفيذ EVM للعقد، يقوم بقراءة هذه البايت كود بالتسلسل، وكل تعليمات لها تكلفة غاز معينة. تتعقب EVM استهلاك الغاز خلال عملية تنفيذ التعليمات، ويعتمد مقدار الاستهلاك على تعقيد العمليات.
كنظام تنفيذ أساسي للإيثيريوم، يعتمد EVM على معالجة المعاملات بطريقة تنفيذ تسلسلي. يتم ترتيب جميع المعاملات في قائمة واحدة، ويتم تنفيذها بالتتابع وفقًا لترتيب مؤكد. هذه التصميم بسيط وسهل الصيانة، ولكن مع زيادة عدد المستخدمين وتطور التكنولوجيا، أصبحت عنق الزجاجة في الأداء أكثر وضوحًا، خاصة بعد نضوج تقنية Rollup، حيث يظهر ذلك بشكل واضح في الشبكة الثانية للإيثيريوم.
يعتبر Sequencer مكونًا رئيسيًا في Layer2، حيث يتحمل جميع مهام الحساب بشكل فردي على شكل خادم واحد. إذا كانت كفاءة الوحدات الخارجية المساعدة مرتفعة بما فيه الكفاية، فإن الزجاجة النهائية ستعتمد على كفاءة Sequencer نفسه، وفي هذه الحالة، ستصبح التنفيذ المتسلسل عقبة كبيرة.
قامت إحدى الفرق من خلال تحسينات قصوى في طبقة DA ووحدة قراءة وكتابة البيانات، بجعل الـ Sequencer قادرًا على تنفيذ أكثر من 2000 عملية تحويل ERC-20 في الثانية. يبدو أن هذا الرقم مرتفع، ولكن بالنسبة للمعاملات المعقدة، فإن قيمة TPS ستتأثر حتمًا بشكل كبير. لذلك، فإن المعالجة المتوازية للمعاملات ستكون الاتجاه الحتمي في المستقبل.
المكونان الرئيسيان لتنفيذ معاملات الإيثيريوم
بالإضافة إلى EVM، فإن المكون الأساسي الآخر المرتبط بتنفيذ المعاملات في go-ethereum هو stateDB، والذي يُستخدم لإدارة حالة الحسابات وبيانات التخزين في الإيثيريوم. يعتمد الإيثيريوم على هيكل شجرة Merkle Patricia Trie كفهرس قاعدة بيانات، وكل تنفيذ لمعاملة بواسطة EVM سيؤدي إلى تغيير بعض البيانات في stateDB، وتعكس هذه التغييرات في النهاية في شجرة الحالة العالمية.
تتحمل stateDB مسؤولية الحفاظ على حالة جميع حسابات الإيثريوم، بما في ذلك حسابات EOA وحسابات العقود. تشمل البيانات المخزنة رصيد الحساب، ورمز العقد الذكي، وغيرها. خلال عملية تنفيذ الصفقة، تقوم stateDB بقراءة وكتابة البيانات الخاصة بالحسابات المعنية. بعد انتهاء تنفيذ الصفقة، تحتاج stateDB إلى تقديم الحالة الجديدة إلى قاعدة البيانات الأساسية لمعالجتها بشكل دائم.
بشكل عام، يتولى EVM تفسير وتنفيذ تعليمات العقود الذكية، ويقوم بتغيير حالة البلوكشين استنادًا إلى نتائج الحساب، بينما تعمل stateDB كخزانة للحالة العالمية، تدير جميع تغييرات حالة الحسابات والعقود. يتعاون الاثنان لبناء بيئة تنفيذ المعاملات في إيثريوم.
عملية التنفيذ التسلسلي بالتفصيل
تنقسم أنواع معاملات الإيثريوم إلى تحويلات EOA ومعاملات العقود. تحويلات EOA هي أبسط نوع من المعاملات، وهي تحويلات ETH بين الحسابات العادية، ولا تتضمن استدعاء العقود، وسرعة المعالجة سريعة جداً، ورسوم الغاز منخفضة جداً.
تشمل معاملات العقود استدعاء وتنفيذ العقود الذكية. عند معالجة معاملات العقود، يحتاج EVM إلى تفسير وتنفيذ تعليمات بايت كود في العقد الذكي واحدة تلو الأخرى. كلما كانت منطق العقد أكثر تعقيدًا، زادت التعليمات المعنية، وزادت الموارد المستهلكة.
على سبيل المثال، يستغرق وقت معالجة تحويل ERC-20 حوالي ضعف وقت تحويل EOA، بينما يمكن أن تستغرق العمليات الأكثر تعقيدًا في العقود الذكية، مثل عمليات التداول على بعض DEX، أضعاف أوقات تحويل EOA. وذلك لأن بروتوكولات DeFi تحتاج عند إجراء المعاملات إلى معالجة منطق معقد مثل تجمعات السيولة، حساب الأسعار، وتبادل الرموز، مما يتطلب إجراء حسابات معقدة للغاية.
في وضع التنفيذ التسلسلي، تكون عملية التعاون بين EVM و stateDB كما يلي:
يتم معالجة المعاملات داخل الكتلة واحدة تلو الأخرى حسب الترتيب، حيث يتم تنفيذ كل معاملة في مثيل مستقل يقوم بإجراء العمليات المحددة.
على الرغم من أن كل معاملة تستخدم مثيل EVM مختلف، إلا أن جميع المعاملات تشترك في نفس قاعدة بيانات الحالة stateDB.
أثناء تنفيذ الصفقة، يحتاج EVM إلى التفاعل باستمرار مع stateDB، لقراءة البيانات ذات الصلة وكتابة البيانات المعدلة مرة أخرى إلى stateDB.
بعد الانتهاء من معالجة جميع المعاملات، سيتم تقديم البيانات في stateDB إلى شجرة الحالة العالمية، وسيتم إنشاء جذر حالة جديدة.
تظهر قيود وضع التنفيذ التسلسلي لـ EVM بوضوح: يجب تنفيذ المعاملات بالتسلسل، وإذا كانت هناك معاملات عقود ذكية تستغرق وقتًا طويلاً، يتعين على المعاملات الأخرى الانتظار، مما يمنع الاستفادة الكاملة من موارد الأجهزة، مما يحد من الكفاءة بشكل كبير.
خطة تحسين التوازي متعدد الخيوط لـ EVM
EVM المتوازي يشبه بنكًا يحتوي على عدة نوافذ، يمكنه فتح عدة خيوط لمعالجة معاملات متعددة في نفس الوقت، مما يمكن أن يزيد الكفاءة بمعدل عدة مرات. ولكن المشكلة المعقدة هي مشكلة تعارض الحالة، والتي تحتاج إلى معالجة منسقة.
فكرة تحسين التوازي لـ EVM لمشروع ZKRollup معين هي كما يلي:
تنفيذ المعاملات بالتوازي باستخدام عدة خيوط: إعداد عدة خيوط لمعالجة معاملات مختلفة في نفس الوقت، دون تدخل بين الخيوط، مما يمكن أن يزيد من سرعة معالجة المعاملات عدة مرات.
تخصيص قاعدة بيانات حالة مؤقتة لكل خيط: يتم تخصيص قاعدة بيانات حالة مؤقتة مستقلة (pending-stateDB) لكل خيط. عند تنفيذ المعاملات، لا يقوم كل خيط بتعديل قاعدة بيانات الحالة العالمية مباشرة، بل يتم تسجيل نتائج التغييرات في الحالة مؤقتًا في pending-stateDB.
مزامنة تغييرات الحالة: بعد تنفيذ جميع المعاملات في كتلة واحدة، يقوم EVM بمزامنة نتائج تغييرات الحالة المسجلة في كل pending-stateDB إلى global stateDB. إذا لم تحدث أي تعارضات في الحالة خلال تنفيذ المعاملات المختلفة، يمكن دمج السجلات الموجودة في pending-stateDB بسلاسة في global stateDB.
تم تحسين معالجة عمليات القراءة والكتابة في هذا المشروع لضمان أن تتمكن المعاملات من الوصول بشكل صحيح إلى بيانات الحالة وتجنب التعارضات:
عمليات القراءة: عندما تحتاج المعاملات إلى قراءة الحالة، يتحقق EVM أولاً من ReadSet في الحالة المعلقة. إذا كانت البيانات المطلوبة موجودة، يتم قراءتها مباشرة من pending-stateDB. إذا لم يتم العثور على الزوج المفتاح-القيمة المقابل في ReadSet، يتم قراءة بيانات الحالة التاريخية من global stateDB الخاص بالكتلة السابقة.
عمليات الكتابة: جميع عمليات الكتابة لا تُكتب مباشرةً إلى قاعدة بيانات الحالة العالمية (stateDB)، بل يتم تسجيلها أولاً في مجموعة الكتابة (WriteSet) لحالة الانتظار (Pending-state). بعد اكتمال تنفيذ المعاملة، يتم محاولة دمج نتائج تغييرات الحالة إلى قاعدة بيانات الحالة العالمية (stateDB) بعد إجراء كشف التعارض.
تم إدخال آلية كشف التضارب لحل مشكلة تضارب الحالة:
كشف التعارض: يقوم EVM بمراقبة ReadSet و WriteSet لعمليات التداول المختلفة. إذا اكتشف أن عدة عمليات تداول تحاول قراءة وكتابة نفس عنصر الحالة، فإن ذلك يعتبر تعارضاً.
معالجة النزاعات: عند اكتشاف نزاع، ستُعلَّم الصفقة المتنازعة على أنها تحتاج إلى إعادة التنفيذ.
بعد الانتهاء من تنفيذ جميع المعاملات، ستتم دمج سجلات التغييرات المتعددة في pending-stateDB في global stateDB. إذا كانت الدمج ناجحة، ستقوم EVM بتقديم الحالة النهائية إلى شجرة الحالة العالمية وتوليد جذر حالة جديدة.
تحسين التوازي متعدد الخيوط له تأثير كبير على الأداء، لا سيما عند التعامل مع معاملات العقود الذكية المعقدة. تظهر الدراسات أنه في أحمال العمل ذات التداخل المنخفض، زادت TPS في الاختبارات المعيارية من 3 إلى 5 مرات مقارنةً بالتنفيذ التسلسلي التقليدي. في أحمال العمل ذات التداخل العالي، نظريًا إذا تم استخدام جميع وسائل التحسين، يمكن أن يصل حتى إلى 60 مرة من التحسين.
ملخص
تعمل خطة تحسين التوازي المتعدد للـ EVM على تحسين قدرة معالجة المعاملات بشكل كبير من خلال تخصيص مكتبة حالة مؤقتة لكل معاملة، وتنفيذ المعاملات بشكل متوازي في خيوط مختلفة. من خلال تحسين عمليات القراءة والكتابة وإدخال آلية الكشف عن تضارب، تستطيع شبكة الـ EVM العامة تحقيق التوازي الكبير للمعاملات مع ضمان تناسق الحالة، مما يحل عنق الزجاجة في الأداء الناتج عن نمط التنفيذ التسلسلي التقليدي. وهذا يشكل أساساً مهماً لتطوير Rollup الخاص بالإيثيريوم في المستقبل.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تحسين EVM: زيادة كفاءة معالجة المعاملات من خلال المعالجة المتزامنة المتعددة
طريق تحسين التوازي في EVM
من المعروف أن EVM هو أحد المكونات الأساسية الأكثر أهمية في Ethereum، حيث يلعب دور "محرك التنفيذ" و "بيئة تنفيذ العقود الذكية" بشكل حاسم. في شبكة البلوكتشين العامة المكونة من آلاف العقد، يضمن وجود الآلة الافتراضية أن العقود الذكية يمكن أن تعمل بنفس الطريقة على عقد ذات تكوينات أجهزة مختلفة، مما يضمن اتساق النتائج. هذه التوافقية عبر الأنظمة الأساسية تشبه إلى حد كبير آلة جافا الافتراضية JVM.
يتم تجميع العقود الذكية إلى بايت كود EVM قبل أن تُرفع إلى السلسلة. عند تنفيذ EVM للعقد، يقوم بقراءة هذه البايت كود بالتسلسل، وكل تعليمات لها تكلفة غاز معينة. تتعقب EVM استهلاك الغاز خلال عملية تنفيذ التعليمات، ويعتمد مقدار الاستهلاك على تعقيد العمليات.
كنظام تنفيذ أساسي للإيثيريوم، يعتمد EVM على معالجة المعاملات بطريقة تنفيذ تسلسلي. يتم ترتيب جميع المعاملات في قائمة واحدة، ويتم تنفيذها بالتتابع وفقًا لترتيب مؤكد. هذه التصميم بسيط وسهل الصيانة، ولكن مع زيادة عدد المستخدمين وتطور التكنولوجيا، أصبحت عنق الزجاجة في الأداء أكثر وضوحًا، خاصة بعد نضوج تقنية Rollup، حيث يظهر ذلك بشكل واضح في الشبكة الثانية للإيثيريوم.
يعتبر Sequencer مكونًا رئيسيًا في Layer2، حيث يتحمل جميع مهام الحساب بشكل فردي على شكل خادم واحد. إذا كانت كفاءة الوحدات الخارجية المساعدة مرتفعة بما فيه الكفاية، فإن الزجاجة النهائية ستعتمد على كفاءة Sequencer نفسه، وفي هذه الحالة، ستصبح التنفيذ المتسلسل عقبة كبيرة.
قامت إحدى الفرق من خلال تحسينات قصوى في طبقة DA ووحدة قراءة وكتابة البيانات، بجعل الـ Sequencer قادرًا على تنفيذ أكثر من 2000 عملية تحويل ERC-20 في الثانية. يبدو أن هذا الرقم مرتفع، ولكن بالنسبة للمعاملات المعقدة، فإن قيمة TPS ستتأثر حتمًا بشكل كبير. لذلك، فإن المعالجة المتوازية للمعاملات ستكون الاتجاه الحتمي في المستقبل.
المكونان الرئيسيان لتنفيذ معاملات الإيثيريوم
بالإضافة إلى EVM، فإن المكون الأساسي الآخر المرتبط بتنفيذ المعاملات في go-ethereum هو stateDB، والذي يُستخدم لإدارة حالة الحسابات وبيانات التخزين في الإيثيريوم. يعتمد الإيثيريوم على هيكل شجرة Merkle Patricia Trie كفهرس قاعدة بيانات، وكل تنفيذ لمعاملة بواسطة EVM سيؤدي إلى تغيير بعض البيانات في stateDB، وتعكس هذه التغييرات في النهاية في شجرة الحالة العالمية.
تتحمل stateDB مسؤولية الحفاظ على حالة جميع حسابات الإيثريوم، بما في ذلك حسابات EOA وحسابات العقود. تشمل البيانات المخزنة رصيد الحساب، ورمز العقد الذكي، وغيرها. خلال عملية تنفيذ الصفقة، تقوم stateDB بقراءة وكتابة البيانات الخاصة بالحسابات المعنية. بعد انتهاء تنفيذ الصفقة، تحتاج stateDB إلى تقديم الحالة الجديدة إلى قاعدة البيانات الأساسية لمعالجتها بشكل دائم.
بشكل عام، يتولى EVM تفسير وتنفيذ تعليمات العقود الذكية، ويقوم بتغيير حالة البلوكشين استنادًا إلى نتائج الحساب، بينما تعمل stateDB كخزانة للحالة العالمية، تدير جميع تغييرات حالة الحسابات والعقود. يتعاون الاثنان لبناء بيئة تنفيذ المعاملات في إيثريوم.
عملية التنفيذ التسلسلي بالتفصيل
تنقسم أنواع معاملات الإيثريوم إلى تحويلات EOA ومعاملات العقود. تحويلات EOA هي أبسط نوع من المعاملات، وهي تحويلات ETH بين الحسابات العادية، ولا تتضمن استدعاء العقود، وسرعة المعالجة سريعة جداً، ورسوم الغاز منخفضة جداً.
تشمل معاملات العقود استدعاء وتنفيذ العقود الذكية. عند معالجة معاملات العقود، يحتاج EVM إلى تفسير وتنفيذ تعليمات بايت كود في العقد الذكي واحدة تلو الأخرى. كلما كانت منطق العقد أكثر تعقيدًا، زادت التعليمات المعنية، وزادت الموارد المستهلكة.
على سبيل المثال، يستغرق وقت معالجة تحويل ERC-20 حوالي ضعف وقت تحويل EOA، بينما يمكن أن تستغرق العمليات الأكثر تعقيدًا في العقود الذكية، مثل عمليات التداول على بعض DEX، أضعاف أوقات تحويل EOA. وذلك لأن بروتوكولات DeFi تحتاج عند إجراء المعاملات إلى معالجة منطق معقد مثل تجمعات السيولة، حساب الأسعار، وتبادل الرموز، مما يتطلب إجراء حسابات معقدة للغاية.
في وضع التنفيذ التسلسلي، تكون عملية التعاون بين EVM و stateDB كما يلي:
تظهر قيود وضع التنفيذ التسلسلي لـ EVM بوضوح: يجب تنفيذ المعاملات بالتسلسل، وإذا كانت هناك معاملات عقود ذكية تستغرق وقتًا طويلاً، يتعين على المعاملات الأخرى الانتظار، مما يمنع الاستفادة الكاملة من موارد الأجهزة، مما يحد من الكفاءة بشكل كبير.
خطة تحسين التوازي متعدد الخيوط لـ EVM
EVM المتوازي يشبه بنكًا يحتوي على عدة نوافذ، يمكنه فتح عدة خيوط لمعالجة معاملات متعددة في نفس الوقت، مما يمكن أن يزيد الكفاءة بمعدل عدة مرات. ولكن المشكلة المعقدة هي مشكلة تعارض الحالة، والتي تحتاج إلى معالجة منسقة.
فكرة تحسين التوازي لـ EVM لمشروع ZKRollup معين هي كما يلي:
تنفيذ المعاملات بالتوازي باستخدام عدة خيوط: إعداد عدة خيوط لمعالجة معاملات مختلفة في نفس الوقت، دون تدخل بين الخيوط، مما يمكن أن يزيد من سرعة معالجة المعاملات عدة مرات.
تخصيص قاعدة بيانات حالة مؤقتة لكل خيط: يتم تخصيص قاعدة بيانات حالة مؤقتة مستقلة (pending-stateDB) لكل خيط. عند تنفيذ المعاملات، لا يقوم كل خيط بتعديل قاعدة بيانات الحالة العالمية مباشرة، بل يتم تسجيل نتائج التغييرات في الحالة مؤقتًا في pending-stateDB.
مزامنة تغييرات الحالة: بعد تنفيذ جميع المعاملات في كتلة واحدة، يقوم EVM بمزامنة نتائج تغييرات الحالة المسجلة في كل pending-stateDB إلى global stateDB. إذا لم تحدث أي تعارضات في الحالة خلال تنفيذ المعاملات المختلفة، يمكن دمج السجلات الموجودة في pending-stateDB بسلاسة في global stateDB.
تم تحسين معالجة عمليات القراءة والكتابة في هذا المشروع لضمان أن تتمكن المعاملات من الوصول بشكل صحيح إلى بيانات الحالة وتجنب التعارضات:
عمليات القراءة: عندما تحتاج المعاملات إلى قراءة الحالة، يتحقق EVM أولاً من ReadSet في الحالة المعلقة. إذا كانت البيانات المطلوبة موجودة، يتم قراءتها مباشرة من pending-stateDB. إذا لم يتم العثور على الزوج المفتاح-القيمة المقابل في ReadSet، يتم قراءة بيانات الحالة التاريخية من global stateDB الخاص بالكتلة السابقة.
عمليات الكتابة: جميع عمليات الكتابة لا تُكتب مباشرةً إلى قاعدة بيانات الحالة العالمية (stateDB)، بل يتم تسجيلها أولاً في مجموعة الكتابة (WriteSet) لحالة الانتظار (Pending-state). بعد اكتمال تنفيذ المعاملة، يتم محاولة دمج نتائج تغييرات الحالة إلى قاعدة بيانات الحالة العالمية (stateDB) بعد إجراء كشف التعارض.
تم إدخال آلية كشف التضارب لحل مشكلة تضارب الحالة:
بعد الانتهاء من تنفيذ جميع المعاملات، ستتم دمج سجلات التغييرات المتعددة في pending-stateDB في global stateDB. إذا كانت الدمج ناجحة، ستقوم EVM بتقديم الحالة النهائية إلى شجرة الحالة العالمية وتوليد جذر حالة جديدة.
تحسين التوازي متعدد الخيوط له تأثير كبير على الأداء، لا سيما عند التعامل مع معاملات العقود الذكية المعقدة. تظهر الدراسات أنه في أحمال العمل ذات التداخل المنخفض، زادت TPS في الاختبارات المعيارية من 3 إلى 5 مرات مقارنةً بالتنفيذ التسلسلي التقليدي. في أحمال العمل ذات التداخل العالي، نظريًا إذا تم استخدام جميع وسائل التحسين، يمكن أن يصل حتى إلى 60 مرة من التحسين.
ملخص
تعمل خطة تحسين التوازي المتعدد للـ EVM على تحسين قدرة معالجة المعاملات بشكل كبير من خلال تخصيص مكتبة حالة مؤقتة لكل معاملة، وتنفيذ المعاملات بشكل متوازي في خيوط مختلفة. من خلال تحسين عمليات القراءة والكتابة وإدخال آلية الكشف عن تضارب، تستطيع شبكة الـ EVM العامة تحقيق التوازي الكبير للمعاملات مع ضمان تناسق الحالة، مما يحل عنق الزجاجة في الأداء الناتج عن نمط التنفيذ التسلسلي التقليدي. وهذا يشكل أساساً مهماً لتطوير Rollup الخاص بالإيثيريوم في المستقبل.