لكن لا يزال هذا موضوعًا متخصصًا للغاية، لدرجة أنه إذا نظرت إلى الملخصات السنوية وتوقعات الاتجاه للعديد من المؤسسات البحثية، فلن يتم ذكر Parallel EVM. لذلك لا يزال هذا مفهومًا جديدًا لم يشكل بعد إجماعًا واسع النطاق. علاوة على ذلك، فإن هذا المفهوم يشبه موضوعات مثل خوارزمية الإجماع وDA. وكلها مرتبطة بالتكنولوجيا بحتة، لذلك هناك عدد أقل من الأشخاص الذين يهتمون بها.
وفقًا لـ "Fortune"< a href="https://fortune.com/crypto/2024/03/11/monad-paradigm-venture-capital-crypto-jump-bitcoin/" style="font -size: 18px; text-align: justify; ">التقاريرتخطط Paradigm لقيادة الجولة الأخيرة من استثمار Monad، وجمع 200 دولار مليون دولار بقيمة 3 مليارات دولار. على الرغم من أن هذا هو أول فريق مفهوم Parallel EVM تخطط Paradigm للاستثمار فيه، إلا أنهم كانوا في الواقع يهتمون بهذه التكنولوجيا لسنوات عديدة. أعلن جورجيوس كونستانتوبولوس (CTO في Paradigm) ذات مرة عن ذلك في عام 2021الإشارات هذه الكلمة.
عندما تم إطلاق Reth، اتهمها أعضاء فريق Erigon بسرقة حقوقها الأدبية. كود أكولا مفتوح المصدر، وقد أدى ذلك أيضًا إلى توقف مشروع أكولا بسبب نقص الأموال. أجاب جورجيوس بأن Reth ليست شوكة لأي عميل آخر، ولا يأتي الكود من أي عميل آخر، ولكنه بالفعل متأثر وملهم بـ Geth وErigan وAkula. (https://thedefiant.io/paradigm-accused-copying-code)
المشارك الأساسي الآخر هو Jump Trading وJump Capital. مؤسس Monad يأتي من Jump Trading ولديه خبرة غنية في التداول عالي التردد؛ وهو مستثمر في Sei هناك شركة Jump Capital، وقد شاركت شركة Jump بشكل كبير في نظام Solana البيئي، بما في ذلك البنية التحتية والمشاريع.
Dragonfly، أحد المستثمرين الأوائل في Monad، كان أيضًا مهتمًا بالمسارات ذات الصلة. وقد استثمر في NEAR، الذي يركز على تكنولوجيا التقسيم، بالإضافة إلى الجمهور سلاسل مثل Aptos وAvalanche وNervos.
ترقية خوارزمية الإجماع ليست كافية، إنها أخيرًا دور طبقة التنفيذ
في المرات القليلة الماضية، في حرب السلسلة العامة، تم تجاهل طبقة التنفيذ دائمًا، وكانوا يتحدثون فقط تقريبًا عن ابتكار خوارزميات الإجماع، سواء كانت Solana أو Avalanche أو EOS. على الرغم من أن لديهم الكثير من الابتكارات في طبقة التنفيذ، إلا أن المجتمع لا يزال يتذكر خوارزمية الإجماع التي استخدموها، ويعتقد المجتمع بأكمله أيضًا أن أداء هذه السلاسل العامة عالية الأداء يأتي من ابتكار خوارزمية الإجماع.
لكن الأمر ليس كذلك. إذا كنت ترغب في الحصول على سلسلة عامة عالية الأداء، فيجب مطابقة خوارزمية الإجماع وطبقة التنفيذ، وهو أمر ضروري أيضًا بما يتماشى مع عيوب البرميل الخشبي. بالنسبة لتلك السلاسل العامة التي تعتمد على EVM والتي تعمل فقط على تحسين خوارزمية الإجماع، هناك حاجة إلى عقد أقوى لتحسين الأداء. على سبيل المثال، يحد BSC من الغاز الذي يمكن معالجته بواسطة الكتلة إلى مستوى 2000 TPS، الأمر الذي يتطلب تكوين الجهاز عدة أضعاف استثمار عقدة Ethereum الكاملة. يمكن أن يصل Polygon نظريًا إلى 1000 TPS، وهو عادةً ما يكون فقط بضعة عشرة إلى مئات.
عقدة أرشيف BSCيتطلب في وحدة معالجة مركزية تحتوي على 16 نواة على الأقل وذاكرة سعة 128 جيجا، عقدة الإيثريومفقط أحتاج على الأقل وحدة معالجة مركزية رباعية النواة وذاكرة 16 جيجا.
لقد كان فريق BSC على علم بهذه المشكلات منذ فترة طويلة، لذلك فهو يعمل أيضًا مع NodeReal التطوير التعاوني تقنية Parallel EVM. بهذه الطريقة فقط يمكن زيادة عدد المعاملات التي يمكن معالجة كل كتلة، ويمكن تنفيذ المزيد من المعاملات بالتوازي، ويمكن زيادة الحد الأعلى لـ TPS.
بالتوازي: لا يقتصر الأمر على الترقية من وحدة المعالجة المركزية أحادية النواة إلى وحدة المعالجة المركزية متعددة النواة
في معظم الأحيان الكتل في نظام السلسلة، يتم تنفيذ المعاملات بشكل كامل بالتسلسل، ويمكنك اعتبارها وحدة معالجة مركزية أحادية النواة، ولا يمكن إجراء الحساب التالي إلا بعد اكتمال الحساب الحالي. على الرغم من أن هذه الطريقة بطيئة، إلا أن مميزاتها هي البساطة وانخفاض تعقيد النظام.
ولكن إذا كان نظام blockchain المستقبلي يحتاج إلى الوصول إلى نطاق مستخدم على مستوى الإنترنت، فمن المؤكد أن وحدة المعالجة المركزية أحادية النواة لن تكون كافية. لذلك، يمكن للترقية إلى جهاز ظاهري متوازي مزود بوحدة معالجة مركزية متعددة النواة معالجة معاملات متعددة في نفس الوقت وزيادة الإنتاجية. ومع ذلك، هناك العديد من التحديات في التنفيذ الهندسي، على سبيل المثال، ماذا علي أن أفعل إذا تمت معالجة معاملتين في نفس الوقت لكتابة البيانات إلى نفس العقد الذكي؟ ومن الضروري تصميم آلية جديدة لحل هذا التناقض. بالنسبة للتنفيذ الموازي للعقود الذكية الأخرى غير المرتبطة تمامًا، يمكن زيادة الإنتاجية وفقًا لعدد سلاسل المعالجة المتوازية والمقياس.
بالإضافة إلى ذلك، لا يعمل Parallel EVM على تحسين القدرات المتوازية فحسب، بل يعمل أيضًا على تحسين كفاءة التنفيذ أحادي الترابط. الرئيس التنفيذي لشركة Monad Keone Hon قال، "... عنق الزجاجة الحقيقي (في EVM) هو عندما تكون الأمور على ما يرام تتم معالجتها بشكل متكرر حالة القراءة والكتابة...". وقال أيضًا إن التنفيذ الموازي ليس سوى جزء من خريطة الطريق، وأن مهمة Monad الأكبر تدور حول EVM لجعلها فعالة قدر الإمكان.
لذا، على الرغم من أن Parallel EVM تعني حرفيًا "الموازاة"، إلا أنها في الواقع عبارة عن تحسين خاص لأداء كل مكون من مكونات EVM، لذا فإن الجهد المبذول هو من المحتمل أن يمثل حد الأداء بموجب معيار EVM.
EVM لا يساوي Solidity
كتابة العقود الذكية هي الأغلبية من الكتل المهارات الأساسية لمطوري السلسلة. يمكن للمهندسين استخدام Solidity أو غيرها من لغات العقود الذكية عالية المستوى لكتابة تطبيقات منطقية مقابلة بناءً على احتياجات العمل. ومع ذلك، لا يمكن لـ EVM أن يفهم بشكل مباشر منطق Solidity، بل يحتاج إلى المرور عبر بعض "الترجمة" وترجمتها (تجميعها) إلى لغة منخفضة المستوى يمكن للجهاز فهمها (رمز تشغيل كود التشغيل / كود بايت كود بايت) قبل أن يتمكن من ذلك. يمكن قراءتها بواسطة الجهاز الظاهري. لا يحتاج مطورو Solidity إلى فهم عملية الترجمة هذه، نظرًا لوجود أدوات ناضجة بالفعل لتنفيذها.
في النهاية، إنها "ترجمة"، لذلك سيكون هناك أيضًا بعض النفقات العامة (النفقات الإضافية). بالنسبة للمهندسين ذوي الخبرة في البرمجة منخفضة المستوى، يمكنهم كتابة منطق البرنامج مباشرة باستخدام أكواد التشغيل في Solidity، وهذا يمكن أن يحقق أعلى أداء، مما يعني أنه يمكن للمستخدمين توفير الطاقة أثناء المعاملات. على سبيل المثال، يستخدم بروتوكول Seaport الذي أطلقته Opensea التجميع المضمن على نطاق واسع في العقود الذكية لتقليل نفقات الغاز للمستخدمين قدر الإمكان.
لذلك، إذا كان من الممكن تنفيذ Parallel EVM أخيرًا، فلن يؤدي ذلك إلى توفير إمكانات الموازاة فحسب، بل سيؤدي أيضًا إلى تحسين أداء مكدس EVM بأكمله. لا يحتاج مطورو التطبيقات العاديون إلى إنفاق الكثير من الطاقة على التحسين فقط لتوفير القليل من الجهد، لأن الآلة الافتراضية الأساسية قوية بما يكفي لحل هذه الاختلافات.
يختلف أداء EVM، و"قياسي" لا يساوي "الممارسة الهندسية"
" يمكن أيضًا تسمية "الآلة الافتراضية" بـ "طبقة التنفيذ"، وهي المحرك الذي يقوم في النهاية بحساب ومعالجة العقود الذكية بعد تجميعها في أكواد التشغيل. أصبح "الرمز الثانوي" الذي تحدده آلة الإيثريوم الافتراضية (EVM) الآن معيارًا صناعيًا. سواء كانت شبكة من الطبقة الثانية تعتمد على إيثريوم أو غيرها من السلاسل العامة المستقلة، فهي أكثر استعدادًا لتكون متوافقة بشكل مباشر وكامل مع EVM المعيار قبل التطوير يمكن للمؤلفين كتابة العقود الذكية مرة واحدة ونشرها على شبكات متعددة، وهو أمر فعال للغاية من حيث التكلفة.
لذلك طالما أنه متوافق تمامًا مع معيار "bytecode" الخاص بـ EVM، فيمكن أن يطلق عليه EVM، ولكن يمكن أن تختلف طرق التنفيذ على نطاق واسع. على سبيل المثال، يستخدم عميل Ethereum Geth لغة Go لتنفيذ معيار EVM. ومع ذلك، Ipsilon يحتفظ بتطبيق مستقل لـ EVM تم تطويره في C++، وعملاء Ethereum الآخرين، ويمكن استدعاء هذه المكتبة مباشرة للتنفيذ كـ EVM.
على سبيل المثال، العديد من المنتجات المنتجة صناعيًا لها معاييرها الدولية المقابلة. على سبيل المثال، عندما عندما يغادر المنتج المصنع، يجب أن يكون عدد المستعمرات أقل من قيمة معينة قبل أن يتم بيعه، وهذا هو "المعيار". ولكن كيفية تلبية معيار المصنع هذا، يمكن لكل مصنع الاختيار من بين العشرات من طرق التعقيم المختلفة، ويمكن لبعض المصانع إيجاد طرق أكثر فعالية من حيث التكلفة لتلبية هذا المطلب، هذه هي "الممارسة".
نظرًا لوجودevmone بطرق أخرى. لذا في هذا المثال لـ EVM، يحدد معيار EVM بعض طرق التشغيل الأساسية "الرمز الثانوي" (مثل دعم العمليات الحسابية الأساسية مثل الجمع والطرح والضرب وما إلى ذلك). عندما يكون لكل رمز بايت مدخلات معينة، يكون هناك مخرجات محددة . عندما يتعلق الأمر باستيفاء هذا المعيار، تختلف التطبيقات (والممارسات) بشكل كبير، مع وجود مجال كبير للتخصيص وإمكانيات التحسين الهندسي.
أوجه التشابه والاختلاف بين EVM الموازي
في مسار EVM الموازي، باستثناء معظمها بالإضافة إلى ذلك، هناك Sei وMegaETH وPolygon وNeon EVM وBSC إلخ. ويريد عميل Paradigm's Reth أيضًا تنفيذ وظيفة الموازاة.
من منظور تحديد المواقع، تعد Monad وSei وPolygon وBSC جميعها من سلاسل الكتل من الطبقة الأولى، بينما قد تكون MegaETH من الطبقة الثانية وNeon EVM. لأنه يقوم على شبكة سولانا. بالإضافة إلى ذلك، Reth هو عميل مفتوح المصدر، وسيستمر تطوير MegaETH جزئيًا استنادًا إلى مشاريع Reth.
وبطبيعة الحال، لا تزال هناك منافسة بين هذه الفرق، ولم يتم الكشف عن جميع التفاصيل الفنية والوثائق الهندسية بشكل كامل. وسيتعين انتظار المزيد من المقارنات حتى يتم إجراؤها. ولا يمكن أن تتكشف إلا بشكل تدريجي عندما تصبح علنية. ولعل هذا يشبه سباق التسلح مرة أخرى، مثل طبقة بيتكوين 2، وريستاكين، وطبقة إيثريوم 2. وعلى الرغم من وجود اختلافات طفيفة بين التقنيات (والمصدر المفتوح)، فإن الأهم هو كيفية بناء تفرد النظام البيئي.
الصعوبات الفنية في Parallel EVM
بالنسبة للمعاملات المنفذة بشكل تسلسلي، فإن عنق الزجاجة هو وحدة المعالجة المركزية و عملية القراءة والكتابة الحالة. لكن الميزة هي أن هذه الطريقة بسيطة بما فيه الكفاية، وخالية من الأخطاء، ويمكن إكمال جميع المهام خطوة بخطوة. بالنسبة للأجهزة الافتراضية التي يتم تنفيذها بالتوازي، قد يكون هناك تعارض في الحالة، لذلك يجب إضافة هذا الجزء من الحكم قبل التنفيذ أو بعده.
مثال بسيط هو أنه إذا كان الجهاز الظاهري يدعم أربعة سلاسل عمليات للتنفيذ المتوازي، ويمكن لكل مؤشر ترابط معالجة معاملة في نفس الوقت، في حالة هذه الأربعة المعاملات هي جميع المعاملات في نفس مجمع التداول على Uniswap، لذلك لا يمكن حسابها بالتوازي، لأن كل معاملة ستؤثر على سعر المعاملة في مجمع التداول هذا. ولكن إذا كانت هذه الخيوط الأربعة تعمل على أربعة أشياء غير مرتبطة تمامًا في نفس الوقت، فلا توجد مشكلة.
سيتضمن ذلك التصميم والتنفيذ الهندسي لفرق مختلفة، ولكن على الأقل ما يجب التأكد منه هو أنه بعد التنفيذ المتوازي، هناك حاجة إلى وحدة لاكتشاف التعارضات. في حالة مواجهة تعارضات، ما عليك سوى إعادة التنفيذ. بالطبع، إذا كان من الممكن التنبؤ بالمعاملات التي قد تتعارض وفحصها مسبقًا، فيمكن أيضًا زيادة الكفاءة الموازية للجهاز الظاهري بأكمله.
بالإضافة إلى الاختلافات في التنفيذ الهندسي للجهاز الظاهري Parallel EVM، سيقوم كل فريق بشكل عام بإعادة تصميم وتحسين أداء القراءة والكتابة لقاعدة بيانات الحالة. وتصميم خوارزمية توافقية وفقًا لذلك، مثل MonadDb وMonadBFT التي صممتها Monad.
التحديات
بالنسبة إلى Parallel EVM، هناك تحديان محتملان: هل الهندسة طويلة المدى يتم التقاط القيمة بواسطة Ethereum، مركزية العقد.
نظرًا لأن كل فريق لا يزال في مرحلة التطوير والاختبار لتقنية Parallel EVM، فإنهم لم يختاروا بعد فتح المصدر لجميع التفاصيل الهندسية. وهذا أحد أهم الخنادق الحالية. ومع ذلك، بعد الدخول إلى شبكة الاختبار والشبكة الرئيسية، سيتم نشر وثائق المشروع هذه وقد يتم استيعابها أيضًا بواسطة Ethereum أو السلاسل العامة الأخرى. لذلك، في ذلك الوقت، من الضروري تعزيز البناء البيئي بشكل أسرع وبناء المزيد من الخنادق البيئية.
ومع ذلك، فإن هذه المشكلة ليست خطيرة جدًا. فمن ناحية، بالنسبة لمطوري العملات المشفرة، يوجد الآن المزيد من التراخيص مفتوحة المصدر للاختيار من بينها (مثل Uniswap's). يمكن نشر الكود للعامة، لكن لا يُسمح للشوكة أن تكون ترخيصًا لمشروع تجاري).من ناحية أخرى، يختلف موضع Monad بطبيعته عن Ethereum. حتى لو تمكنت إيثريوم من تحقيق نهائية المقبس الواحد (SSF) في المستقبل، فإن نهائية المعاملات ستظل على الأقل 12 ثانية، وهو بعيد عن أن يكون كافيًا لسيناريوهات التطبيقات ذات التردد العالي.
التحدي الآخر الذي يواجه جميع السلاسل العامة عالية الأداء هو التحدي الآخر وهو كيفية نشر المزيد من العقد لتلبية احتياجات المستخدمين غير المصرح بها وغير الموثوقة. ) المتطلبات الأساسية: اللامركزية . ربما يمكن قياس بعض المؤشرات، مثل "TPS مقسومًا على متطلبات الأجهزة للعقدة"، حتى نتمكن من التحكم في المتغيرات ومقارنة السلسلة العامة/العميل الذي لديه TPS أعلى بناءً على متطلبات الأجهزة المحددة. بعد كل شيء، كلما انخفضت متطلبات الأجهزة للعقدة، زاد عدد العقد الممكنة.
بعد ذلك، سنستمر في تتبع التقدم المحرز في كل مشروع Parallel EVM ومناقشة التقنيات والاختلافات الخاصة بها بالتفصيل.
JinseFinance
Olive
Cheng Yuan
Clement
Coinlive 
Cointelegraph
链向资讯