هل تستطيع MegaETH حقًا تنفيذ تقنية blockchain في الوقت الفعلي؟

المؤلف: العارف، التشفير KOL الترجمة: Golden Finance xiaozou

1< /strong>、MegaETHمقدمة

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

يعد موقع MegaETH رائعًا لأنه يحتوي على أرنب ميكانيكي مع نظام ألوان ملفت للنظر للغاية. قبل ذلك، لم يكن هناك سوى Github واحد - فوجود موقع ويب يجعل كل شيء أسهل بكثير.

لقد تصفحت MegaETH Github وعلمت أنهم يطورون نوعًا ما من طبقة التنفيذ، لكن يجب أن أكون صادقًا، ربما كنت مخطئًا بشأن هذا. الحقيقة هي أنني لم أكن أعرف ما يكفي عن MegaETH وهي الآن موضوع ساخن على EthCC.

أحتاج إلى معرفة كل شيء والتأكد من أن التكنولوجيا التي أراها هي نفس ما يراه الرجال الرائعون.

تشير الورقة البيضاء لـ MegaETH إلى أنها عبارة عن blockchain في الوقت الفعلي متوافق مع EVM ومصمم لتقديم أداء يشبه web2 إلى عالم العملات المشفرة. هدفهم هو تحسين تجربة استخدام Ethereum L2 من خلال توفير سمات مثل أكثر من 100000 معاملة في الثانية، وأوقات الحظر أقل من ميلي ثانية واحدة، ورسوم المعاملات البالغة سنتًا واحدًا.

تسلط ورقتهم البيضاء الضوء على أن أرقام L2 آخذة في النمو (تمت مناقشتها في إحدى مشاركاتي السابقة، على الرغم من ارتفاع هذا الرقم إلى أكثر من 50، إلا أن هناك المزيد من أرقام L2 في " التطوير النشط") وافتقارهم إلى PMF في عالم التشفير. يعد Ethereum و Solana أكثر سلاسل الكتل شيوعًا، وسوف ينجذب المستخدمون إلى أحدهما وسيختارون L2 الآخر فقط إذا كانت هناك رموز مميزة لاستخراجها.

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

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

أداء اللغة الثانية المتوفرة لدينا حاليًا مرتفع، لكنه ليس كافيًا. تقول الورقة البيضاء الخاصة بـ MegaETH أنه حتى مع معدل 100 ميجا غاز/ثانية المرتفع (نسبيًا) لـ opBNB، فإن هذا يعني فقط 650 معاملة Uniswap في الثانية - يمكن للبنية التحتية الحديثة أو web2 إجراء مليون معاملة في الثانية.

نحن نعلم أنه على الرغم من مزايا التشفير التي تأتي من اللامركزية وتمكين المدفوعات غير المصرح بها، إلا أنها لا تزال بطيئة جدًا. إذا أرادت شركة تطوير ألعاب مثل Blizzard جلب Overwatch على السلسلة، فلن تتمكن من فعل ذلك - فنحن بحاجة إلى نسبة نقر إلى ظهور أعلى لتوفير حماية الأصناف النباتية في الوقت الفعلي وميزات أخرى توفرها ألعاب web2 بشكل طبيعي.

أحد حلول MegaETH لمعضلة L2 هو تفويض مقاومة الأمن والرقابة إلى Ethereum وEigenDA على التوالي، مما يحول MegaETH إلى L2 الأعلى أداءً في العالم دون أي المقايضات.

يتطلب L1 عادةً عقدًا متماثلة تؤدي نفس المهام، دون وجود مجال للتخصص. في هذه الحالة، يشير التخصص إلى العمل مثل التسلسل أو الإثبات. يتحايل L2 على هذه المشكلة، مما يسمح باستخدام العقد غير المتجانسة، وفصل المهام لتحسين قابلية التوسع أو تخفيف بعض العبء. ويمكن ملاحظة ذلك في تزايد شعبية أجهزة التسلسل المشتركة مثل Astria أو Espresso وظهور خدمات إثبات zk المتخصصة مثل Succinct أو Axiom.

"يتضمن إنشاء blockchain في الوقت الفعلي أكثر من مجرد استخدام عميل تنفيذ Ethereum الجاهز وإضافة أجهزة التسلسل. على سبيل المثال، تظهر تجارب الأداء لدينا أنه حتى مع وجود خادم قوي مزود بـ ذاكرة وصول عشوائي (RAM) سعة 512 جيجابايت، لا يمكن لـ Reth تحقيق سوى حوالي 1000 TPS في إعداد المزامنة في الوقت الفعلي على كتل Ethereum الحديثة >، أي ما يعادل تقريبًا 100 ميجا غاز/ثانية”

تنفذ MegaETH المعاملات عن طريق استخلاصها من العقد الكاملة لتوسيع هذا التقسيم، استخدم فقط جهاز التسلسل "النشط" للتخلص من عبء الإجماع في تنفيذ المعاملة النموذجية. "تتلقى معظم العقد الكاملة اختلافات الحالة من هذا الترتيب عبر شبكةp2pوتطبق الاختلافات مباشرةً لتحديث الحالة المحلية. والجدير بالذكر أنها لا تعيد تنفيذ المعاملات؛ وبدلاً من ذلك، تستخدم المُثبتات ( Prover) دليلاً يتحقق بشكل غير مباشر من الكتلة ”

إلى جانب "إنه سريع" أو بصرف النظر عن "إنه "تعليقات رخيصة"، لم أقرأ الكثير من التحليلات حول مدى جودة MegaETH، لذلك سأحاول تحليل بنيتها بعناية ومقارنتها بأنظمة L2 الأخرى.

تستخدم MegaETH EigenDA للتعامل مع توفر البيانات، وهي ممارسة قياسية إلى حد ما هذه الأيام. تتيح لك الأنظمة الأساسية لمجموعة التحديثات كخدمة (RaaS: مجموعة التحديثات كخدمة) مثل Conduit اختيار Celestia أو EigenDA أو حتى Ethereum (إذا كنت تفضل ذلك) كموفر توفر البيانات للمجموعة. الفرق بين الاثنين تقني إلى حد ما وغير ذي صلة تمامًا، ويبدو أن قرار اختيار أحدهما على الآخر يعتمد على الصدى أكثر من أي شيء آخر.

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

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

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

تجميع كل هذا معًا هو مهمة شبكة العقد الكاملة، والتي تعمل كنوع من التجميع بين المُثبتين والأمرين وEigenDA لتمكين (نأمل) من سحر MegaETH يصبح حقيقة.

يعتمد تصميم MegaETH على سوء فهم أساسي لـ EVM. على الرغم من أن L2 غالبًا ما يلوم EVM على أدائه الضعيف (الإنتاجية)، فقد وجد أن معدل الدوران قادر على الوصول إلى 14000 TPS. إذا لم يكن EVM، ما هو السبب؟

2، مشكلات قابلية التوسع الحالية

تؤدي إلى الأداء ثلاثة أوجه قصور رئيسية في إدارة قيمة الأصول (EVM) والتي تمثل عنق الزجاجة هي الافتقار إلى التنفيذ المتوازي، وعبء المترجم الفوري، وزمن الوصول العالي للوصول إلى الحالة.

نظرًا لوفرة ذاكرة الوصول العشوائي، فإن MegaETH قادرة على تخزين حالة blockchain بالكامل. تبلغ ذاكرة الوصول العشوائي الدقيقة لـ Ethereum 100 جيجابايت. يعمل هذا الإعداد على تسريع الوصول إلى الحالة بشكل ملحوظ من خلال إزالة زمن انتقال القراءةSSD.

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

شيء آخر يجب أن أذكره هو أنني لا أريد أن أكون انتقائيًا للغاية. فكرتي هي عدم دعم بروتوكول على آخر، أو حتى تقييمهما بشكل متساوٍ في المقام الأول - أفعل هذا فقط من أجل فهم أفضل، ولمساعدة أي شخص يقرأ هذا على اكتساب نفس الفهم في نفس الوقت.

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

إذا كانت المعاملة B تعتمد على نتيجة المعاملة A، فلا يمكنك تنفيذ معاملتين في نفس الوقت. إذا كانت 50% من معاملات الكتلة مترابطة كما في هذه الحالة، فإن التنفيذ الموازي لا يمثل تحسنًا كبيرًا كما يُزعم. على الرغم من أن هذا مبالغ فيه بعض الشيء (وربما غير صحيح إلى حد ما)، إلا أنني أعتقد أنه يصل إلى الهدف.

الفجوة بين Revm والتنفيذ الأصلي واضحة جدًا، خاصة أن revm لا يزال أبطأ بمقدار 1-2 OOMs ولا يستحق أن يكون بيئة VM مستقلة. تم اكتشاف أيضًا أنه لا يوجد حاليًا ما يكفي من العقود المكثفة حسابيًا لضمان استخدام المراجعة. "على سبيل المثال، قمنا بتحليل الوقت المستغرق لكل كود تشغيل أثناء عمليات المزامنة التاريخية ووجدنا أن ما يقرب من 50% من الوقت في revm تم إنفاقه على "المضيف"< / strong>و"نظام"رمز التشغيل"

فيما يتعلق بمزامنة الحالة، MegaETH المزيد من المشاكل تم اكتشافها. يتم وصف مزامنة الحالة ببساطة على أنها عملية مزامنة العقد الكاملة مع نشاط الطلب، وهي مهمة يمكن أن تستهلك بسرعة النطاق الترددي لمشروع مثل MegaETH. فيما يلي مثال لتوضيح ذلك: إذا كان الهدف هو مزامنة 100000 عملية نقل ERC20 في الثانية، فسيستهلك هذا حوالي 152.6 ميجابت في الثانية من عرض النطاق الترددي. يقال إن سرعة 152.6 ميجابت في الثانية تتجاوز تقديرات (أو أداء) MegaETH وتقدم بشكل أساسي مهمة مستحيلة.

يأخذ هذا في الاعتبار فقط عمليات نقل الرموز البسيطة ويتجاهل إمكانية الاستهلاك الأعلى إذا كانت المعاملة أكثر تعقيدًا. وهذا سيناريو محتمل نظرًا لتنوع النشاط على السلسلة في العالم الحقيقي. كتبت MegaETH أن معاملة Uniswap عدلت 8 فتحات تخزين (في حين أن نقل ERC20 عدل 3 فتحات تخزين فقط)، وبذلك يصل إجمالي استهلاك النطاق الترددي لدينا إلى 476.1 ميجابت في الثانية، وهو هدف أقل جدوى.

هناك مشكلة أخرى في تنفيذ blockchain عالي الأداء بسرعة 100 كيلو TPS وهي حل تحديث جذر حالة السلسلة، وهو إدارة إرسال أدلة التخزين إلى العملاء الخفيفين. مهمة. حتى مع العقد الاحترافية، لا تزال العقد الكاملة بحاجة إلى استخدام عقد التسلسل الخاصة بالشبكة للحفاظ على جذر الحالة. إذا أخذنا المشكلة المذكورة أعلاه والمتمثلة في مزامنة 100000 عملية نقل ERC20 في الثانية كمثال، فإن هذا سيؤدي إلى تكلفة تحديث 300000 مفتاح في الثانية.

يستخدم Ethereum بنية بيانات MPT (Merkle Patricia Trie: Merkle Prefix Tree) لحساب الحالة بعد كل كتلة. لتحديث 300000 مفتاح في الثانية، ستحتاج Ethereum إلى "تحويل 6 ملايين قراءة لقاعدة البيانات غير المخزنة مؤقتًا"، وهو ما يزيد بكثير عن قدرة أي SSD من فئة المستهلك على القيام به اليوم. كتبت MegaETH أن هذا التقدير لا يشمل حتى عمليات الكتابة (أو تقديرات المعاملات عبر السلسلة مثل معاملات Uniswap)، مما يجعل التحدي أقرب إلى مسعى سيزيف مما قد يفضله معظمنا.

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

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

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

يُذكر بعد ذلك أن سرعة EVM الموازية تعتمد على عبء العمل، ويخضع أدائها لـ "سلاسل التبعية الطويلة" التي تقلل من "التسارع" المفرط لـ blockchain وظائف "قيود عنق الزجاجة. الطريقة الوحيدة لحل هذه المشكلة هي تقديم تسعير الغاز متعدد الأبعاد (تشير MegaETH إلى سوق الرسوم المحلية في Solana)، والذي لا يزال من الصعب تنفيذه. لست متأكدًا مما إذا كان هناك EIP مخصص، أو كيف سيعمل مثل هذا EIP على EVM، ولكن أعتقد أن هذا هو الحل من الناحية الفنية.

أخيرًا، لن يتفاعل المستخدمون مباشرةً مع عقدة الفرز، ولن يقوم معظم المستخدمين بتشغيل عقدة كاملة في المنزل. ولذلك، فإن تجربة المستخدم الفعلية لـ blockchain تعتمد بشكل كبير على بنيتها التحتية الأساسية، مثل عقد RPC والمفهرسات. بغض النظر عن مدى سرعة تشغيل blockchain في الوقت الفعلي، إذا لم تتمكن عقد RPC من التعامل بكفاءة مع العدد الكبير من طلبات القراءة خلال أوقات الذروة، فقم بنشر المعاملات بسرعة إلى عقد التسلسل، أو لا يمكن للمفهرسين التحديث بسرعة كافية يمكن لعروض التطبيقات مواكبة سرعة السلسلة، لذلك لا يهم مدى سرعة تشغيل blockchain في الوقت الفعلي. ”

ربما يكون هناك الكثير مما يمكن قوله، ولكن من المهم جدًا أن نعتمد جميعًا على Infura وAlchemy وQuickNode وما إلى ذلك تشغيل البنية التحتية التي تدعم على الأرجح جميع معاملاتنا تأتي من الخبرة إذا كنت قد حاولت المطالبة بالإنزال الجوي خلال أول 2-3 ساعات من الإنزال الجوي L2، فسوف تفهم كيف يدير RPC هذا الأمر. p>

3، الاستنتاج

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

يسرد Github الخاص بـ MegaETH بعض التحسينات الرئيسية، بما في ذلك على سبيل المثال لا الحصر: EVM Bytecode→EVMالمتوازي، يسمى evmone. على الرغم من أنني لست ماهرًا بما يكفي في البرمجة لمعرفة آلية العمل الأساسية، لقد بذلت قصارى جهدي لمعرفة ذلك.

evmone هو نشر C++ لـ EVM. فهو يأخذ واجهة برمجة تطبيقات EVMC ويحولها إلى وحدة تنفيذ لعملاء Ethereum ويذكر بعض الميزات الأخرى التي لا أفهمها، مثل نهج المترجم المزدوج (الأساسي والمتقدم)، ومكتبة intx وethash باختصار، يوفر evmone معالجة أسرع للمعاملات (من خلال عقد ذكي أسرع التنفيذ)، مرونة أكبر في التطوير وقابلية توسع أعلى (بافتراض أن عمليات نشر EVM المختلفة يمكن أن تكون كتلًا للتعامل مع المزيد من المعاملات)

هناك عدد قليل من مكتبات التعليمات البرمجية الأخرى، ولكن معظمها منها قياسية جدًا وليس لها نفس الوظيفة، MegaETH (reth، geth) ذات صلة بشكل خاص، وأعتقد أنني انتهيت إلى حد كبير من الورقة البيضاء، لذا أترك السؤال الآن لأي شخص يقرأ هذا: ما هو الخطوة التالية لـ MegaETH هل من الممكن حقًا تنفيذ التوسع الفعال؟ كم من الوقت سيستغرق حدوث ذلك؟

أنا متحمس لذلك لنرى ما إذا كان هذا ممكنًا. الكثير من المال وحان الوقت للتغيير، ولكن هذا التغيير لا يزال يبدو بعيد المنال بشكل متزايد ومن غير المرجح أن يحدث في أي وقت قريب

على الرغم من محتوى تدور هذه المقالة بشكل أساسي حول التحسينات المعمارية وقابلية التوسع، ولكن لا تزال هناك حاجة إلى السيولة المشتركة الداخلية وأدوات السلسلة المتقاطعة لجعل تجربة المجموعة "أ" متسقة مع المجموعة "ب". لم نصل إلى هذه المرحلة بعد، ولكن ربما بحلول عام 2037، سيكون الجميع كذلك. نجلس جميعًا ونتذكر مدى هوسنا بـ "إصلاح" مشكلات قابلية التوسع.