توازي EVM: المفتاح لحل عنق الزجاجة في أداء إثيريوم
EVM كأداة تنفيذ لإيثريوم وبيئة تشغيل العقود الذكية، هي واحدة من المكونات الأساسية. لضمان أن العقود الذكية تحقق نفس النتائج على العقد المختلفة، وتلبية متطلبات التناسق، أصبحت تقنية الآلات الافتراضية الخيار الأفضل. يمكن لـ EVM تشغيل العقود الذكية بنفس الطريقة على أنظمة تشغيل وأجهزة مختلفة، مما يضمن التوافق عبر المنصات.
يتم تجميع العقود الذكية إلى بايت كود EVM قبل أن يتم تحميلها على السلسلة. عند تنفيذ العقد، تقرأ EVM هذه البايت كود بالترتيب، ولدى كل تعليمات تكلفة غاز متناسبة. تتبع EVM استهلاك الغاز أثناء تنفيذ كل تعليمات، ويعتمد مقدار الاستهلاك على تعقيد العملية.
كنواة لمحرك التنفيذ، تعتمد EVM على معالجة المعاملات بطريقة تسلسلية، حيث يتم ترتيب جميع المعاملات في قائمة واحدة وتنفيذها وفقًا لترتيب مؤكد. هذه التصميم بسيط وسهل الصيانة، ولكن مع توسع قاعدة المستخدمين وتطور التكنولوجيا، بدأت قيود أدائها تبرز بشكل متزايد، خاصة في Layer2.
بالنسبة لمكون Layer2 الرئيسي Sequencer، إذا كانت كفاءة الوحدات المساعدة مرتفعة بما فيه الكفاية، فإن الاختناق النهائي سيعتمد على كفاءة Sequencer نفسه. لقد تمكنت بعض الفرق من تحقيق تحسينات كبيرة، مما جعل Sequencer قادرًا على تنفيذ حوالي 2000 عملية تحويل ERC-20 في الثانية. لكن بالنسبة للمعاملات الأكثر تعقيدًا، من المؤكد أن TPS ستنخفض بشكل كبير. لذلك، فإن توازي معالجة المعاملات أصبح الاتجاه الحتمي في المستقبل.
مكونات تنفيذ معاملات إثيريوم الأساسية
بصرف النظر عن EVM، فإن المكون الأساسي الآخر المرتبط ارتباطًا وثيقًا بتنفيذ المعاملات هو stateDB، الذي يُستخدم لإدارة حالة حسابات إثيريوم وبيانات التخزين. يستخدم إثيريوم هيكل شجرة Merkle Patricia Trie كفهرس قاعدة بيانات. كل تنفيذ معاملة يحدث تغييرًا في بعض البيانات في stateDB، وهذه التغييرات تنعكس في النهاية على شجرة الحالة العالمية.
تتحمل stateDB مسؤولية الحفاظ على حالة جميع حسابات إثيريوم، بما في ذلك حسابات EOA وحسابات العقود، وتخزين رصيد الحسابات، ورموز العقود الذكية، وغيرها من البيانات. خلال عملية تنفيذ المعاملات، تقوم stateDB بقراءة وكتابة بيانات الحسابات المعنية. بعد انتهاء تنفيذ المعاملة، تقوم stateDB بتقديم الحالة الجديدة إلى قاعدة البيانات الأساسية للتخزين الدائم.
بشكل عام، فإن EVM مسؤول عن تفسير وتنفيذ تعليمات العقود الذكية، وتغيير حالة البلوكشين بناءً على نتائج الحساب، بينما تعد stateDB بمثابة تخزين الحالة العالمية، تدير جميع التغييرات في حالة الحسابات والعقود. يعمل الاثنان معًا لبناء بيئة تنفيذ المعاملات لإثيريوم.
قيود التنفيذ التسلسلي
تُقسم معاملات إثيريوم إلى فئتين: تحويل EOA ومعاملات العقود. تحويل EOA هو أبسط نوع من المعاملات، حيث يكون سرعة المعالجة عالية وتكلفة الغاز منخفضة. بينما تتضمن معاملات العقود استدعاء وتنفيذ العقود الذكية، حيث يحتاج EVM إلى تفسير وتنفيذ تعليمات البايت كود في العقد واحدة تلو الأخرى، مما يزيد من التعقيد واستهلاك الموارد.
في وضع التنفيذ المتسلسل، تتم معالجة المعاملات داخل الكتلة واحدة تلو الأخرى وفقًا للتسلسل. كل معاملة لديها مثيل مستقل من EVM، لكن جميع المعاملات تشترك في نفس stateDB. يحتاج EVM أثناء التنفيذ إلى التفاعل المستمر مع stateDB، لقراءة البيانات وإعادة كتابة النتائج المتغيرة.
من الواضح أن عنق الزجاجة في وضع التنفيذ التسلسلي هذا هو: يجب أن تنتظر المعاملات في طابور للتنفيذ، وإذا ظهرت معاملات عقود ذكية تستغرق وقتًا طويلاً، فإن المعاملات الأخرى يمكن أن تنتظر فقط، مما لا يسمح بالاستفادة الكاملة من موارد الأجهزة، مما يحد من الكفاءة بشكل كبير.
تحسين التوازي المتعدد الخيوط لـ EVM
لتجاوز قيود التنفيذ التسلسلي، اقترحت الصناعة خطة تحسين متعددة الخيوط لـ EVM. هذه الخطة مشابهة لبنك يقدم خدمات متعددة في نفس الوقت، حيث يمكنه معالجة عدة معاملات في وقت واحد، مما يعزز الكفاءة بشكل ملحوظ. لكن التحدي الرئيسي الذي تواجهه التنفيذ المتوازي هو مشكلة تعارض الحالة، مما يتطلب اتخاذ تدابير خاصة للتعامل معها.
فكرة تحسين التوازي لـ EVM لمشروع معين هي كما يلي:
إعداد عدة خيوط لمعالجة معاملات مختلفة في نفس الوقت، دون تداخل بين الخيوط.
تخصيص قاعدة بيانات حالة مؤقتة مستقلة (pending-stateDB) لكل خيط. عند تنفيذ المعاملات، يتم تسجيل التغييرات في الحالة مؤقتًا في pending-stateDB بدلاً من تعديل stateDB العالمي مباشرة.
بعد الانتهاء من تنفيذ جميع المعاملات داخل الكتلة، سيتم مزامنة تغييرات الحالة من كل pending-stateDB إلى global stateDB بالتتابع. إذا لم يكن هناك تعارض، يمكن دمج السجلات بسلاسة.
تم تحسين هذا الحل لعمليات القراءة والكتابة:
عملية القراءة: تحقق أولاً من ReadSet في حالة الانتظار، إذا كانت البيانات المطلوبة موجودة قم بقراءتها مباشرة؛ وإلا قم بقراءة الحالة التاريخية من قاعدة بيانات الحالة العالمية للكتلة السابقة.
عمليات الكتابة: يتم تسجيل جميع التعديلات أولاً في WriteSet في حالة الانتظار، ثم يتم محاولة دمجها في stateDB العالمي بعد الانتهاء من تنفيذ المعاملة.
لحل مشكلة تعارض الحالة، تم إدخال آلية كشف التعارض:
مراقبة ReadSet و WriteSet للتعاملات المختلفة، واعتبار محاولة عدة معاملات لقراءة وكتابة نفس عنصر الحالة بمثابة تعارض.
تحديد المعاملات المتعارضة على أنها تحتاج إلى إعادة التنفيذ.
بعد الانتهاء من تنفيذ جميع المعاملات، يتم دمج سجلات التغييرات المتعددة في pending-stateDB إلى global stateDB. بعد نجاح الدمج، يتم تقديم الحالة النهائية إلى شجرة الحالة العالمية، مما ينتج عنه جذر حالة جديدة.
أظهرت الدراسات أنه في أحمال العمل ذات النزاعات المنخفضة، فإن تنفيذ TPS بالتوازي يزيد بمعدل 3-5 مرات مقارنة بالتنفيذ التسلسلي التقليدي. في أحمال العمل ذات النزاعات العالية، يمكن أن تصل الزيادة إلى 60 مرة في حالة التحسين الكامل نظريًا.
ملخص
تُحسن خطة تحسين التشغيل المتوازي متعدد الخيوط لـ EVM بشكل كبير من قدرة معالجة المعاملات من خلال تخصيص مكتبات حالة مؤقتة لكل معاملة وتنفيذ المعاملات بشكل متوازي في خيوط مختلفة. من خلال تحسين عمليات القراءة والكتابة وإدخال آلية كشف التعارض، تم تحقيق التوازي الكبير في المعاملات مع ضمان اتساق الحالة، مما حل اختناقات الأداء في نماذج التنفيذ التسلسلي التقليدية. هذا يمهد الطريق لتطور مهم لمستقبل إثيريوم Rollup.
في المستقبل، يمكن استكشاف كيفية تحسين كفاءة التخزين، والتعامل مع حالات التصادم العالية، وكذلك استخدام GPU لتحقيق تحسينات، لتعزيز أداء EVM بشكل أكبر.
This page may contain third-party content, which is provided for information purposes only (not representations/warranties) and should not be considered as an endorsement of its views by Gate, nor as financial or professional advice. See Disclaimer for details.
تسجيلات الإعجاب 6
أعجبني
6
6
مشاركة
تعليق
0/400
down_only_larry
· منذ 7 س
لقد فتح الإله الخامس عقله أخيرا
شاهد النسخة الأصليةرد0
BlockTalk
· منذ 7 س
أحب أن أرى أو لا أرى على أي حال، ارتفع tps.
شاهد النسخة الأصليةرد0
LiquidityOracle
· منذ 7 س
مرة أخرى أثار الضجة في السماء
شاهد النسخة الأصليةرد0
All-InQueen
· منذ 7 س
أي أنه تم تسريع التحويلات؟
شاهد النسخة الأصليةرد0
ProveMyZK
· منذ 7 س
هذه الموجة من تحسين الأداء تنتمي إلى اللاعبين من المستوى الأعلى.
شاهد النسخة الأصليةرد0
SmartContractPlumber
· منذ 8 س
انظر مباشرة إلى مخاطر قابلية التوسع تصميم آلية القفل ساذج للغاية
التوازي في EVM: نقطة انطلاق لتحسين أداء إثيريوم
توازي EVM: المفتاح لحل عنق الزجاجة في أداء إثيريوم
EVM كأداة تنفيذ لإيثريوم وبيئة تشغيل العقود الذكية، هي واحدة من المكونات الأساسية. لضمان أن العقود الذكية تحقق نفس النتائج على العقد المختلفة، وتلبية متطلبات التناسق، أصبحت تقنية الآلات الافتراضية الخيار الأفضل. يمكن لـ EVM تشغيل العقود الذكية بنفس الطريقة على أنظمة تشغيل وأجهزة مختلفة، مما يضمن التوافق عبر المنصات.
يتم تجميع العقود الذكية إلى بايت كود EVM قبل أن يتم تحميلها على السلسلة. عند تنفيذ العقد، تقرأ EVM هذه البايت كود بالترتيب، ولدى كل تعليمات تكلفة غاز متناسبة. تتبع EVM استهلاك الغاز أثناء تنفيذ كل تعليمات، ويعتمد مقدار الاستهلاك على تعقيد العملية.
كنواة لمحرك التنفيذ، تعتمد EVM على معالجة المعاملات بطريقة تسلسلية، حيث يتم ترتيب جميع المعاملات في قائمة واحدة وتنفيذها وفقًا لترتيب مؤكد. هذه التصميم بسيط وسهل الصيانة، ولكن مع توسع قاعدة المستخدمين وتطور التكنولوجيا، بدأت قيود أدائها تبرز بشكل متزايد، خاصة في Layer2.
بالنسبة لمكون Layer2 الرئيسي Sequencer، إذا كانت كفاءة الوحدات المساعدة مرتفعة بما فيه الكفاية، فإن الاختناق النهائي سيعتمد على كفاءة Sequencer نفسه. لقد تمكنت بعض الفرق من تحقيق تحسينات كبيرة، مما جعل Sequencer قادرًا على تنفيذ حوالي 2000 عملية تحويل ERC-20 في الثانية. لكن بالنسبة للمعاملات الأكثر تعقيدًا، من المؤكد أن TPS ستنخفض بشكل كبير. لذلك، فإن توازي معالجة المعاملات أصبح الاتجاه الحتمي في المستقبل.
مكونات تنفيذ معاملات إثيريوم الأساسية
بصرف النظر عن EVM، فإن المكون الأساسي الآخر المرتبط ارتباطًا وثيقًا بتنفيذ المعاملات هو stateDB، الذي يُستخدم لإدارة حالة حسابات إثيريوم وبيانات التخزين. يستخدم إثيريوم هيكل شجرة Merkle Patricia Trie كفهرس قاعدة بيانات. كل تنفيذ معاملة يحدث تغييرًا في بعض البيانات في stateDB، وهذه التغييرات تنعكس في النهاية على شجرة الحالة العالمية.
تتحمل stateDB مسؤولية الحفاظ على حالة جميع حسابات إثيريوم، بما في ذلك حسابات EOA وحسابات العقود، وتخزين رصيد الحسابات، ورموز العقود الذكية، وغيرها من البيانات. خلال عملية تنفيذ المعاملات، تقوم stateDB بقراءة وكتابة بيانات الحسابات المعنية. بعد انتهاء تنفيذ المعاملة، تقوم stateDB بتقديم الحالة الجديدة إلى قاعدة البيانات الأساسية للتخزين الدائم.
بشكل عام، فإن EVM مسؤول عن تفسير وتنفيذ تعليمات العقود الذكية، وتغيير حالة البلوكشين بناءً على نتائج الحساب، بينما تعد stateDB بمثابة تخزين الحالة العالمية، تدير جميع التغييرات في حالة الحسابات والعقود. يعمل الاثنان معًا لبناء بيئة تنفيذ المعاملات لإثيريوم.
قيود التنفيذ التسلسلي
تُقسم معاملات إثيريوم إلى فئتين: تحويل EOA ومعاملات العقود. تحويل EOA هو أبسط نوع من المعاملات، حيث يكون سرعة المعالجة عالية وتكلفة الغاز منخفضة. بينما تتضمن معاملات العقود استدعاء وتنفيذ العقود الذكية، حيث يحتاج EVM إلى تفسير وتنفيذ تعليمات البايت كود في العقد واحدة تلو الأخرى، مما يزيد من التعقيد واستهلاك الموارد.
في وضع التنفيذ المتسلسل، تتم معالجة المعاملات داخل الكتلة واحدة تلو الأخرى وفقًا للتسلسل. كل معاملة لديها مثيل مستقل من EVM، لكن جميع المعاملات تشترك في نفس stateDB. يحتاج EVM أثناء التنفيذ إلى التفاعل المستمر مع stateDB، لقراءة البيانات وإعادة كتابة النتائج المتغيرة.
من الواضح أن عنق الزجاجة في وضع التنفيذ التسلسلي هذا هو: يجب أن تنتظر المعاملات في طابور للتنفيذ، وإذا ظهرت معاملات عقود ذكية تستغرق وقتًا طويلاً، فإن المعاملات الأخرى يمكن أن تنتظر فقط، مما لا يسمح بالاستفادة الكاملة من موارد الأجهزة، مما يحد من الكفاءة بشكل كبير.
تحسين التوازي المتعدد الخيوط لـ EVM
لتجاوز قيود التنفيذ التسلسلي، اقترحت الصناعة خطة تحسين متعددة الخيوط لـ EVM. هذه الخطة مشابهة لبنك يقدم خدمات متعددة في نفس الوقت، حيث يمكنه معالجة عدة معاملات في وقت واحد، مما يعزز الكفاءة بشكل ملحوظ. لكن التحدي الرئيسي الذي تواجهه التنفيذ المتوازي هو مشكلة تعارض الحالة، مما يتطلب اتخاذ تدابير خاصة للتعامل معها.
فكرة تحسين التوازي لـ EVM لمشروع معين هي كما يلي:
إعداد عدة خيوط لمعالجة معاملات مختلفة في نفس الوقت، دون تداخل بين الخيوط.
تخصيص قاعدة بيانات حالة مؤقتة مستقلة (pending-stateDB) لكل خيط. عند تنفيذ المعاملات، يتم تسجيل التغييرات في الحالة مؤقتًا في pending-stateDB بدلاً من تعديل stateDB العالمي مباشرة.
بعد الانتهاء من تنفيذ جميع المعاملات داخل الكتلة، سيتم مزامنة تغييرات الحالة من كل pending-stateDB إلى global stateDB بالتتابع. إذا لم يكن هناك تعارض، يمكن دمج السجلات بسلاسة.
تم تحسين هذا الحل لعمليات القراءة والكتابة:
عملية القراءة: تحقق أولاً من ReadSet في حالة الانتظار، إذا كانت البيانات المطلوبة موجودة قم بقراءتها مباشرة؛ وإلا قم بقراءة الحالة التاريخية من قاعدة بيانات الحالة العالمية للكتلة السابقة.
عمليات الكتابة: يتم تسجيل جميع التعديلات أولاً في WriteSet في حالة الانتظار، ثم يتم محاولة دمجها في stateDB العالمي بعد الانتهاء من تنفيذ المعاملة.
لحل مشكلة تعارض الحالة، تم إدخال آلية كشف التعارض:
بعد الانتهاء من تنفيذ جميع المعاملات، يتم دمج سجلات التغييرات المتعددة في pending-stateDB إلى global stateDB. بعد نجاح الدمج، يتم تقديم الحالة النهائية إلى شجرة الحالة العالمية، مما ينتج عنه جذر حالة جديدة.
! خذ Reddio كمثال لتوضيح مسار تحسين EVM المتوازي
أظهرت الدراسات أنه في أحمال العمل ذات النزاعات المنخفضة، فإن تنفيذ TPS بالتوازي يزيد بمعدل 3-5 مرات مقارنة بالتنفيذ التسلسلي التقليدي. في أحمال العمل ذات النزاعات العالية، يمكن أن تصل الزيادة إلى 60 مرة في حالة التحسين الكامل نظريًا.
ملخص
تُحسن خطة تحسين التشغيل المتوازي متعدد الخيوط لـ EVM بشكل كبير من قدرة معالجة المعاملات من خلال تخصيص مكتبات حالة مؤقتة لكل معاملة وتنفيذ المعاملات بشكل متوازي في خيوط مختلفة. من خلال تحسين عمليات القراءة والكتابة وإدخال آلية كشف التعارض، تم تحقيق التوازي الكبير في المعاملات مع ضمان اتساق الحالة، مما حل اختناقات الأداء في نماذج التنفيذ التسلسلي التقليدية. هذا يمهد الطريق لتطور مهم لمستقبل إثيريوم Rollup.
في المستقبل، يمكن استكشاف كيفية تحسين كفاءة التخزين، والتعامل مع حالات التصادم العالية، وكذلك استخدام GPU لتحقيق تحسينات، لتعزيز أداء EVM بشكل أكبر.