داخل Monad: ابتكار EVM يعيد تعريف سرعة المعاملات

المؤلف: Decentralised.Co المصدر: X، @Decentralisedco الترجمة: شان أوبا، Golden Finance< / p>

كانت قابلية التوسع في المعاملات دائمًا موضوعًا ساخنًا للمناقشة في الصناعة. على مدى الأسابيع القليلة الماضية، كنا نستكشف كيف يمكن أن تساعد الوحدات الأحادية في تحسين سرعة معالجة المعاملات (TPS). تشرح هذه المقالة بالتفصيل كيفية عمل Monads.

TPS هو المقياس الذي كنا نهتم به. نأمل أن يتمكن blockchain من دعم TPS أعلى لاستيعاب المزيد من المستخدمين والتطبيقات. يوضح الرسم البياني أدناه أرقام TPS لـ Ethereum وL2. حتى الآن، لم تتمكن أي سلسلة من اختراق علامة 100 TPS. من المهم ملاحظة أن TPS هو مصطلح عام يستخدم لقياس قابلية التوسع. وبما أن جميع المعاملات ليست معقدة بنفس القدر، فإن بيانات TPS وحدها ليست دقيقة بما فيه الكفاية. ولكن من أجل الراحة، ما زلنا نعتبر TPS كمقياس لقابلية التوسع.

p>

ما هي طرق تحسين TPS؟

أحد الأساليب هو بناء نظام جديد تمامًا من الصفر، كما فعل سولانا. يضحي Solana بالتوافق مع EVM من أجل السرعة. يستخدم التنفيذ متعدد الخيوط بدلاً من التنفيذ أحادي الخيوط (يمكن مقارنته بوحدة المعالجة المركزية متعددة النواة ووحدة المعالجة المركزية أحادية النواة)، ويعالج المعاملات بالتوازي، ويستخدم آلية إجماع مختلفة.

الأسلوب الثاني هو استخدام التنفيذ خارج السلسلة واستخدام أمر مركزي لتوسيع نطاق Ethereum.

الأسلوب الثالث هو تحليل EVM إلى مكونات منفصلة وتحسينها لتحسين قابلية التوسع.

Monad عبارة عن blockchain L1 متوافق مع EVM تم جمعه حديثًا بقيمة 225 مليون دولار والذي اختار إنشاء EVM من الصفر بدلاً من استخدام الإصدار الحالي مباشرةً. يتخذ Monad نهجًا ثالثًا لتحسين قابلية التوسع.

سنناقش أدناه بعض التغييرات الرئيسية التي أدخلتها Monads.

التنفيذ المتوازي

ينفذ جهاز Ethereum الظاهري (EVM) المعاملات بشكل تسلسلي. يجب أن تنتظر المعاملة التالية قبل اكتمال تنفيذ المعاملة السابقة. على سبيل المثال: تخيل منصة لمستودع تجميع الدراجات النارية. تصل شاحنات متعددة محملة بأجزاء الدراجات النارية (تحتوي كل شاحنة على جميع الأجزاء اللازمة لبناء 50 دراجة نارية). يحتوي مستودع التجميع على أربع وظائف متميزة، يتولى كل منها فريق متخصص - التفريغ والفرز والتجميع والتحميل.

في إعداد EVM الحالي، توجد منصة واحدة فقط ويتم استخدام نفس الموقع لتحميل وتفريغ البضائع. لذلك عندما تكون الشاحنة متوقفة، يتم تفريغ أجزاء الدراجة النارية وفرزها وتجميعها وتحميلها على نفس الشاحنة. بينما يعمل فريق التصنيف، تنتظر الفرق الأخرى. لذا، إذا كنت تعتقد أن وظائفهم هي فترات منفصلة، ​​فسيعمل كل فريق مرة واحدة فقط في كل أربع فترات. وأدى ذلك إلى أوجه قصور كبيرة وسلط الضوء على الحاجة إلى نهج أكثر بساطة.

تخيل الآن أربع منصات بمناطق تحميل وتفريغ منفصلة. حتى لو كان بإمكان فريق التفريغ التعامل مع شاحنة واحدة فقط في كل مرة، فلن يضطروا إلى انتظار الفترات الثلاثة التالية للعمل عليها. يمكنهم الانتقال مباشرة إلى الشاحنة التالية وبدء العمل.

الأمر نفسه ينطبق على فرق الفرز والتجميع والتحميل. عند الانتهاء من تفريغ الشاحنة، تتجه إلى منطقة التحميل لانتظار قيام فريق التحميل بتحميل الدراجات النارية المجمعة. ولذلك، فإن المستودع الذي يحتوي على منصة واحدة فقط ومناطق التحميل والتفريغ يقوم بجميع العمليات بشكل تسلسلي، في حين أن المستودع الذي يحتوي على 4 منصات ومناطق تحميل وتفريغ مختلفة يمكنه معالجة المهام بالتوازي.

يمكنك التفكير في Monad كبنية تحتية للمستودع تحتوي على منصات شاحنات متعددة، ولكنها أكثر تعقيدًا من هذا المثال. يزداد التعقيد عندما تكون هناك تبعيات بين الشاحنات. على سبيل المثال، ماذا لو لم تكن شاحنة واحدة تحتوي على جميع الأجزاء اللازمة لبناء 50 دراجة نارية؟ المعاملات ليست دائما مستقلة. لذلك، يجب على Monad التعامل مع المعاملات المترابطة عند تنفيذها بالتوازي.

كيف نفعل هذا؟ إنه ينفذ ما يسمى بالتنفيذ الموازي المتفائل. يمكن للبروتوكول تنفيذ المعاملات المستقلة بالتوازي فقط. على سبيل المثال، ضع في اعتبارك 4 معاملات حيث رصيد جويل هو 1 إيثريوم:

• يرسل جويل 0.2 إيثريوم إلى سوراب.

• Sid يصدر NFT.

• يرسل جويل 0.1 إيثريوم إلى ألمانيا الغربية.

• شلوك يشتري PEPE.

يتم تنفيذ جميع هذه المعاملات بالتوازي، مع إرسال النتائج المعلقة واحدة تلو الأخرى. إذا تعارضت النتيجة المعلقة مع الإدخال الأصلي لأي معاملة، فسيتم إعادة تنفيذ المعاملة. المعاملات 2 و4 مستقلة عن بعضها البعض، لذا فإن نتائجها المعلقة لا تتعارض مع المدخلات من المعاملات الأخرى. لكن 1 و 4 ليسا مستقلين.

يرجى ملاحظة أنه نظرًا لأن جميع المعاملات الأربعة تبدأ من نفس الحالة الأولية (رصيد جويل هو 1 إيثريوم)، فإن التركيز هنا هو رصيد جويل. بعد إرسال 0.2 إيثريوم، يصبح رصيد جويل 0.8 إيثريوم. وبعد إرسال 0.1 إيثريوم إلى ألمانيا الغربية، أصبح رصيده 0.9 إيثريوم. يتم إرسال النتائج واحدة تلو الأخرى، مما يضمن عدم تعارض المخرجات مع أي مدخلات. بعد إرسال النتيجة المعلقة 1، يصبح رصيد جويل الجديد 0.8 إيثريوم.

يتعارض هذا الإخراج مع إدخال 3. والآن أعد تنفيذ 3 بإدخال 0.8 ETH. بعد تنفيذ 3، يصبح رصيد جويل 0.7 إيثريوم.

MonadDb

في هذه المرحلة، السؤال الواضح هو، كيف نعرف أنه ليس علينا إعادة تنفيذ معظم المعاملات؟ الجواب هو أن إعادة التنفيذ ليست هي عنق الزجاجة. يكمن عنق الزجاجة في الوصول إلى ذاكرة Ethereum. اتضح أن الطريقة التي يخزن بها Ethereum حالته في قاعدة بيانات تجعل الوصول إلى الحالة أمرًا صعبًا (يستغرق وقتًا طويلاً ومكلفًا). هذا هو المكان الذي يأتي فيه تحسين آخر لـ Monad - MonadDb. تقوم Monad ببناء قاعدة البيانات الخاصة بها بطريقة تقلل من الحمل المرتبط بعمليات القراءة.

عندما تحتاج المعاملة إلى إعادة التنفيذ، يتم تخزين جميع المدخلات مؤقتًا في ذاكرة التخزين المؤقت مقارنة بالوصول إلى الحالة العامة، وسرعة الوصول إلى ذاكرة التخزين المؤقت الذاكرة أسرع بكثير.

يمتلك Solana 50000 TPS على شبكة الاختبار، ولكن حوالي 1000 TPS فقط على الشبكة الرئيسية. تدعي Monad أنها حققت 10000 TPS فعليًا على شبكة الاختبار الداخلية الخاصة بها. على الرغم من أن هذا لا يمثل دائمًا أداءً حقيقيًا، إلا أننا لا نستطيع الانتظار لنرى كيفية أداء Monad في تطبيقات العالم الحقيقي.