TL;DR

1. يمثل EVMs المتوازية سردًا جديدًا يظهر عندما تصل أحجام المعاملات على السلسلة إلى مستوى معين. تنقسم أساسًا إلى سلاسل كتلية موحدة وسلاسل كتلية مودولارية، حيث يتم تصنيف السلاسل المتوازية الكتلية إلى L1 و L2، وتنقسم سلاسل L1 العامة المتوازية إلى معسكرين: EVM و non-EVM. حاليًا، يتمتع السرد المتوازي لـ EVM بمراحله الأولى من التطوير.
2. يتضمن مسار التنفيذ التقني لـ EVMs المتوازية آلات افتراضية وآليات تنفيذ متوازية. في سياق البلوكتشين، الجهاز الظاهري هو جهاز ظاهري يظاهر الجهاز الظاهري الموزع لتنفيذ العقود.
3. التنفيذ المتوازي يشير إلى استغلال المعالجات متعددة النوى لتنفيذ عدة معاملات بشكل متزامن بقدر الإمكان مع ضمان أن الحالة النهائية متسقة مع ما يمكن تحقيقه من خلال التنفيذ التسلسلي.
4. آليات التنفيذ المتوازي تنقسم إلى ثلاث فئات: تمرير الرسائل، الذاكرة المشتركة، وقوائم الوصول إلى الحالة الصارمة. الذاكرة المشتركة تنقسم بدورها إلى نموذج قفل الذاكرة والتوازي المتفائل. بغض النظر عن الآلية، يزيد كل منها من التعقيد التقني.
5. تتضمن سرد الـ EVMs المتوازية ليس فقط عوامل النمو الجوهرية للصناعة ولكن أيضًا يتطلب من الممارسين الانتباه الوثيق إلى القضايا الأمنية المحتملة.
6. كل مشروع EVM متوازي يقدم نهجًا فريدًا للتنفيذ المتوازي، مما يظهر كل من التشابه التقني والابتكارات المميزة.

1. نظرة عامة على الصناعة

1.1 تطور تاريخي

أصبحت الأداء عائقًا أمام المزيد من التطور في الصناعة. تقوم شبكات البلوكتشين بإنشاء أساس جديد ولامركزي للثقة للمعاملات بين الأفراد والشركات.

شبكات البلوكتشين من الجيل الأول، الممثلة بواسطة بيتكوين، رسخت نمطًا جديدًا لعمليات العملات الإلكترونية اللامركزية من خلال تكنولوجيا الدفتر الموزع، مما ثور عصرًا جديدًا. الجيل الثاني، المثالي بواسطة إيثيريوم، استغل بالكامل الخيال لاقتراح التطبيقات اللامركزية (dApps) من خلال نهج الآلة الحالية الموزعة.

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

Web3، كشكل منتج جديد "غير مسبوق في التاريخ"، يجب أن يبتكر في تلبية احتياجات المستخدمين (المتطلبات الوظيفية) مع التوازن بين الأمان والأداء (المتطلبات غير الوظيفية). منذ بدايته، تم اقتراح حلول مختلفة لمعالجة مشاكل الأداء.

يمكن تصنيف هذه الحلول عمومًا إلى نوعين: حلول توسيع السلسلة، مثل التجزئة والرسوم البيانية المستقلة الموجهة (DAGs)، وحلول توسيع السلسلة، مثل بلازما وشبكات البرق وسلاسل جانبية وRollups. ومع ذلك، فإن هذه الحلول لا تزال بعيدة عن مواكبة النمو السريع للمعاملات على السلسلة.

خاصة بعد صيف ديفي في عام 2020 والنمو الانفجاري للتسجيلات في نظام بيتكوين نحو نهاية عام 2023 ، تحتاج الصناعة بشكل ملح لحلول تحسين الأداء الجديدة لتلبية الطلب على "أداء عالي ورسوم منخفضة". وُلِدت سلاسل الكتل متوازية في هذا السياق.

1.2 حجم السوق

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

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

صرحت شركة Sei في مقترح الترقية الخاص بها بالإصدار 2 بصوت عالٍ أنها ستصبح "أول سلسلة كتلية EVM متوازية"، برأس مال سوقي حالي يبلغ 2.1 مليار دولار وإمكانية لمزيد من النمو. سلسلة كتلية EVM المتوازية الجديدة Monad، وهي حالياً الأكثر سخونة في حماس التسويق، محظوظة للغاية من قبل المستثمرين ولديها إمكانية كبيرة. في الوقت نفسه، أعلنت سلسلة كتلة L1 Canto، التي تبلغ قيمتها السوقية 170 مليون دولار والتي تمتلك بنيتها التحتية العامة المجانية الخاصة، مقترح ترقية EVM المتوازية الخاصة بها أيضاً.

بالإضافة إلى ذلك، يعمل العديد من مشاريع L2 في المراحل الأولى على تعزيز أداء النظام البيئي عبر تكامل قدرات عدة سلاسل L1. بغض النظر عن Neon الذي حقق قيمة سوقية تبلغ 69 مليون دولار، تفتقر المشاريع الأخرى للبيانات ذات الصلة. من المتوقع أن تنضم المزيد من مشاريع L1 و L2 إلى ساحة المعركة الموازية للبلوكتشين في المستقبل.

ليس هناك فقط إمكانية كبيرة لنمو السوق للسرد بالتوازي لـ EVM، ولكن القطاع الأوسع للبلوكشينات الموازية التي ينتمي إليها EVM أيضًا يحمل إمكانية كبيرة لنمو السوق، مما يعد بتوقعات سوقية واسعة النطاق.

حاليا، إجمالي رأس المال السوقي للطبقة 1 والطبقة 2 هو 752.123 مليار دولار، مع وجود سلاسل كتل موازية لها رأس مال سوقي يبلغ 52.539 مليار دولار، ما يمثل حوالي 7٪. ضمن هذا، تمتلك المشاريع المتعلقة بالسرد الزمني EVM الموازي رأس المال سوقي يبلغ 2.339 مليار دولار، ممثلة فقط 4٪ من رأس المال السوقي لسلاسل الكتل الموازية.

1.3 خريطة الصناعة

تقسم الصناعة عمومًا شبكات البلوكتشين إلى هيكل ذو أربع طبقات:

الطبقة 0 (الشبكة): هذه هي الطبقة الأساسية لشبكة البلوكتشين الأساسية التي تتعامل مع بروتوكولات الاتصال الشبكي الأساسية.

الطبقة 1 (البنية التحتية): تعتمد هذه الطبقة على آليات توافق متنوعة للتحقق من المعاملات ضمن شبكة لامركزية.

الطبقة 2 (التوسيع): تعتمد على الطبقة 1، وتشمل مختلف البروتوكولات من الطبقة الثانية التي تهدف إلى معالجة القيود التي تواجهها الطبقة 1، خاصة من حيث التوسع الأفقي.

الطبقة 3 (التطبيق): تعتمد على الطبقة 2 أو الطبقة 1، تُستخدم هذه الطبقة لبناء مختلف التطبيقات اللامركزية (dApps).

يتم تقسيم مشاريع السرد المتزامنة لـ EVM (الجهاز الظاهري لـ Ethereum) في الغالب إلى سلاسل كتلية وحزم كتلية، مع تقسيم سلاسل الكتل الكتلية إلى L1 و L2. من إجمالي عدد المشاريع وتطور عدة مسارات رئيسية، يمكن رؤية أن نظم سلاسل الكتل العامة L1 المتزامنة لـ EVM لا تزال تمتلك مساحة كبيرة للنمو مقارنة بنظام Ethereum.

في المسار DeFi ، هناك طلب على "سرعة عالية ورسوم منخفضة"، بينما يطالب مسار الألعاب بـ "تفاعل في الوقت الحقيقي القوي"؛ كلاهما يتطلب سرعة تنفيذ معينة. سيحمل EVMs الموازية بالضرورة تجارب مستخدم أفضل لهذه المشاريع، مما يدفع بتطوير الصناعة إلى مرحلة جديدة.

يُمثل L1 سلاسل عامة جديدة بقدرات تنفيذ متوازية ذاتية ويعمل كبنية تحتية ذات أداء عالي. في هذه الفئة، قامت مشاريع مثل Sei v2 وMonad وCanto بتصميم EVMs متوازية بشكل مستقل، والتي تتوافق مع نظام الإيثيريوم وتوفر قدرات عالية لتحقيق حجم معاملات كبير.

L2، من خلال دمج قدرات سلاسل L1 الأخرى، يقدم قدرة موسعة للتعاون بين النظام البيئي المتقاطع وهو مثال بارز على تكنولوجيا الرول أب. في هذه الفصيل، يعمل Neon كمحاكي EVM على شبكة Solana، بينما ينفذ Eclipse المعاملات على Solana ولكن يتم التسوية على EVM. Lumio مماثلة لـ Eclipse، باستثناء أن طبقة التنفيذ تم تبديلها إلى Aptos.

بالإضافة إلى الحلول الفردية المستقلة المذكورة أعلاه، قدم Fuel مفهوم سلسلة كتلية معماري خاص به. في الإصدار الثاني، يهدف إلى تموضع نفسه كنظام تشغيل Ethereum rollup، يقدم إمكانيات تنفيذ معمارية أكثر مرونة وشمولية.

يتركز الوقود على تنفيذ المعاملات، مع تفويض مكونات أخرى إلى طبقات مستقلة واحدة أو أكثر من البلوكتشين، مما يسمح بمزيد من التركيبات المرنة: يمكن أن يعمل كطبقة 2، أو طبقة 1، أو حتى كسلسلة فرعية أو قناة حالة. حاليًا، هناك 17 مشروعًا ضمن نظام الوقود، مركزة بشكل أساسي على DeFi وNFTs والبنية التحتية.

ومع ذلك، تم استخدام إسقاط سلسلة الأوامر فقط. تم إطلاق منصة الإقراض اللامركزية Swaylend ومنصة تداول العقود الدائمة SPARK على شبكات الاختبار، بينما لا تزال المشاريع الأخرى قيد التطوير.

2. مسارات التنفيذ التقني

لتحقيق تنفيذ المعاملات اللامركزية، يجب على شبكات البلوكتشين أن تقوم بأربع مسؤوليات:

• التنفيذ: تنفيذ وتحقق الصفقات.
• توافر البيانات: توزيع الكتل الجديدة على جميع العقد في شبكة البلوكتشين.
• آلية التوافق: التحقق من الكتل وتحقيق التوافق.
• تسوية: تسوية وتسجيل الحالة النهائية للمعاملات.

تركز EVM المتوازي في المقام الأول على تحسين أداء طبقة التنفيذ. يتم تقسيم ذلك إلى حلول الطبقة 1 (L1) وحلول الطبقة 2 (L2). تقدم حلول L1 آلية لتنفيذ المعاملات بشكل متواز في داخل الجهاز الظاهري قدر الإمكان. تستفيد حلول L2 في الأساس من الجهاز الظاهري L1 المتوازي بالفعل لتحقيق مستوى معين من "التنفيذ خارج السلسلة + التسوية داخل السلسلة".

لذا، لفهم المبادئ التقنية لـ EVM المتوازي، من الضروري تفكيكها: أولاً، فهم ما هي الآلة الافتراضية (VM)، ثم فهم ماذا يعني التنفيذ المتوازي.

2.1 آلة افتراضية

في علم الحاسوب، تشير الآلة الافتراضية إلى تحجيم أو تقليد نظام الحاسوب.

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

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

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

تعتمد السلاسل العامة الناشئة وراء إيثريوم غالبًا على آلات افتراضية تعتمد على تعليمات WASM أو eBPF. يعتمد WASM على تنسيق تعليمات مدمج وسريع التحميل وقابل للنقل استنادًا إلى آليات أمان الحاوية الرملية. يمكن للمطورين كتابة عقود ذكية بلغات برمجة مختلفة (C، C++، Rust، Go، Python، Java، أو حتى TypeScript)، تجميعها إلى تعليمات WASM، وتنفيذها. تستخدم عقود الذكاء التنفيذي على سلاسل Sei هذا التنسيق لتعليمات WASM.

البي بي أف نشأ من بي بي أف (Berkeley Packet Filter)، وكان يُستخدم في البداية لتصفية الحزم الشبكية بكفاءة، وتطور إلى البي بي أف القابل للتنفيذ، الذي يوفر مجموعة تعليمات أكثر ثراءً.

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

تستخدم سلاسل L1 العامة الأخرى مثل Aptos و Sui لغة برمجة العقد الذكية Move، مترجمة إلى بايت كود ملكي يتم تشغيله على الجهاز الظاهري Move. قامت Monad بتصميم جهاز ظاهري خاص بها متوافق مع بايت كود EVM opcode (Shanghai fork).

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

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

في شبكات البلوكتشين، يُستخدم TPS (المعاملات في الثانية) عادةً كمؤشر تقني لقياس سرعة المعالجة. آلية التنفيذ المتوازي معقدة وتشكل تحديًا لمهارات المطورين التقنية، مما يجعل من الصعب شرحها. هنا، سنستخدم مثال "البنك" لشرح ما هو التنفيذ المتوازي.

(1) أولاً، ما هي التنفيذ التسلسلي؟

سيناريو 1: إذا رأينا النظام كبنك ومعالج المهام كمعاملة العداد، فإن تنفيذ المهام التسلسلي يشبه هذا البنك الذي يحتوي فقط على عداد واحد متاح للخدمة. في هذه الحالة، يجب على العملاء (المهام) القادمين إلى البنك تشكيل طابور طويل والتعامل مع أعمالهم واحدة تلو الأخرى. بالنسبة لكل عميل، يجب على موظفي العداد تكرار نفس الإجراءات (تنفيذ التعليمات) لخدمة العميل. يجب على العملاء انتظار دورهم، مما يؤدي إلى زمن المعاملة الممتد.

(2) إذا، ما هو التنفيذ المتوازي؟

سيناريو 2: إذا رأت البنك أنه مكتظ بالزوار، فقد يفتح عدة نوافذ للتعامل مع الأعمال، مع عمل أربعة كتبة في النوافذ بشكل متزامن. يزيد ذلك من السرعة بشكل تقريبي أربع مرات مقارنة بالأصل، ويتم تقليل الوقت الذي يقضيه العملاء في الصف إلى حوالي ربع الأصلي. وبالتالي، يتم زيادة سرعة التعامل مع الأعمال في البنك.

(3) ما هي الخطأ الذي يحدث إذا لم تكن هناك حماية موجودة وشخصان يقومان بنقل الأموال إلى شخص آخر في نفس الوقت؟

السيناريو 3: دعونا نأخذ في اعتبارنا A و B و C، الذين لديهم 2 ETH و 1 ETH و 0 ETH في حساباتهم على التوالي. الآن، A و B يرغبان في تحويل 0.5 ETH إلى C. في نظام ينفذ المعاملات بشكل تسلسلي، لن تحدث مشاكل (السهم الأيسر "<=" يشير إلى القراءة من دفتر الأستاذ، والسهم الأيمن "=>" يشير إلى الكتابة إلى دفتر الأستاذ، كما فيما يلي):

ومع ذلك، فإن التنفيذ المتوازي ليس بسيطًا كما يبدو. هناك العديد من التفاصيل الدقيقة التي يمكن أن تؤدي إلى أخطاء خطيرة إذا لم يتم التعامل معها بعناية. إذا تم تنفيذ معاملات A و B التحويل إلى C بشكل متوازي، فإن تسلسل الخطوات يمكن أن يؤدي إلى نتائج غير متناسقة:

المهمة المتوازية 1 تنفذ التحويل من A إلى C، والمهمة المتوازية 2 تنفذ التحويل من B إلى C. الخطوات المشار إليها برمز النجمة هي المشكلة: لأن المهام تُنفذ بشكل متوازي، في الخطوة 2، لم يتم كتابة حساب الرصيد الذي قامت بحسابه المهمة المتوازية 1 بعد في دفتر الأستاذ. في الخطوة 3، تقرأ المهمة المتوازية 2 رصيد حساب C (والذي لا يزال 0) وتقوم بحساب الرصيد بشكل خاطئ استنادًا إلى ذلك في الخطوة 5. ثم، في عملية تحديث دفتر الأستاذ في الخطوة 6، يقوم بتحديث حساب الرصيد بشكل خاطئ، حيث تم تحديثه بالفعل إلى 0.5 في الخطوة 4، إلى 0.5 مرة أخرى. يؤدي ذلك إلى أن رصيد حساب C يكون فقط 0.5 ETH، على الرغم من أن كل من A و B قاموا بنقل 0.5 ETH لكل منهما، مما يؤدي بشكل فعال إلى اختفاء الـ 0.5 ETH الأخرى.

(4) إذا لم تكن هناك حماية موجودة، يمكن أن تُنفذ مهمتان لا تعتمدان على بعضهما البعض بشكل متوازٍ دون أخطاء

السيناريو 4: تنفيذ مهمة موازية 1 لنقل 0.5 إيثريوم من A (رصيد 2 إيثريوم) إلى C (رصيد 0 إيثريوم)، وتنفيذ مهمة موازية 2 لنقل 0.5 إيثريوم من B (رصيد 1 إيثريوم) إلى D (رصيد 0 إيثريوم). ومن الواضح أنه لا توجد تبعية بين هاتين المهمتين للنقل. بغض النظر عن كيفية تتشابك خطوات المهمتين، فإنهما لن يواجها المشاكل الموصوفة أعلاه:

من مقارنة هذه السيناريوهات، يمكن تحليل أنه طالما هناك تبعية بين المهام، فقد تحدث أخطاء في تحديثات الحالة أثناء التنفيذ المتوازي؛ وإلا فلن تحدث أخطاء. تُعتبر المهمة (المعاملة) لها علاقة تبعية إذا توافقت مع أحد الشرطين التاليين:

1. مهمة تكتب إلى عنوان الإخراج الذي يقرأ منه مهمة أخرى كعنوان إدخال؛
2. مخرجات مهمتين إلى نفس العنوان.

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

اقترحت الصناعة ثلاث آليات لحل مشكلات سباق البيانات في التنفيذ المتوازي: آليات تمرير الرسائل، آليات الذاكرة المشتركة، وآليات قائمة الوصول إلى الحالة الصارمة.

آلية تمرير الرسائل 2.3

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

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

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

مزايا نموذج الممثل:

كل ممثل لديه فقط وصول إلى بياناته الخاصة، وبالتالي تجنب مشاكل حالة السباق.

عيوب نموذج الممثل:

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

لا يوجد رؤية عالمية لحالة النظام الحالية. إذا كانت عمليات النظام معقدة، يصبح من الصعب فهم الوضع العام، وتحديد مواقع وإصلاح الأخطاء.

آلية الذاكرة المشتركة 2.4

2.4.1 Memory Lock Model

السيناريو 6: تخيل بنكًا يحتوي على دفتر حسابات كبير واحد فقط يسجل أرصدة حسابات جميع عملائه. بجوار الدفتر، يتوفر قلم واحد فقط لإجراء تعديلات عليه.

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

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

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

منصات البلوكتشين مثل سولانا، سوي، وسي الإصدار ١ تستخدم نموذج ذاكرة مشتركة يعتمد على قفل الذاكرة. قد يبدو هذا الآلية بسيطة، ولكنها معقدة في التنفيذ وتتطلب من المطورين أن يكونوا لديهم مهارات متقدمة في برمجة التعددية. الإهمال قد يؤدي إلى ظهور العديد من الثغرات:

سيناريو 1: مهمة تقوم بقفل مورد مشترك ولكن تتعطل أثناء التنفيذ، مما يترك المورد غير متاح.

سيناريو 2: مهمة تقوم بقفل مورد ولكن تنتهي بقفله مرة أخرى بسبب البطريقة التجارية المتداخلة، مما يؤدي إلى حدوث مأزق حيث تنتظر نفسها.

يعاني نموذج قفل الذاكرة من مشاكل مثل العالقات الداخلية والحية والجوع:

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

تفاؤلي التوازن الموازي 2.4.2

السيناريو ٧

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

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

خلال المرحلة ١، يتم تنفيذ المهام ١، ٢، و ٣ بشكل متوازي. ومع ذلك، تقوم المهام ٢ و ٣ بالوصول إلى المورد المشترك B في نفس الوقت، مما يتسبب في تعارض، لذا تم إعادة جدولة المهمة ٣ للمرحلة القادمة. في المرحلة ٢، تقوم المهام ٣ و ٤ بالوصول إلى المورد B، مما يؤدي إلى إعادة جدولة المهمة ٤، وهكذا، حتى يتم استكمال جميع المهام. كما يمكن رؤية أن المهام التي تواجه تعارضات يتم إعادة تنفيذها بشكل متكرر.

نموذج التوازن المتفائل

يستخدم نموذج التوازي المتفائل هيكل بيانات في الذاكرة متعدد الإصدارات لتسجيل كل قيمة مكتوبة ومعلومات إصدارها (مشابهة للتسميات المستخدمة من قبل كتب البنوك).

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

ظهر نموذج التوازي المتفائل من ذاكرة النقل البرمجيات (STM)، وهي آلية برمجة خالية من القفل في مجال قواعد البيانات. نظرًا لأن شبكات البلوكتشين تحتفظ بشكل أساسي بترتيب محدد للمعاملات، فقد تم تقديم هذا المفهوم وتطوره إلى آلية Block-STM. منصات البلوكتشين مثل Aptos وMonad اعتمدت Block-STM كآلية تنفيذ متوازي.

من الجدير بالذكر أن سلسلة Sei العامة، في الإصدار القادم الخاص بها v2، قد تخلت عن نموذج قفل الذاكرة الأصلي لصالح نموذج التوازن التفاؤلي. تنفذ كتلة-STM المعاملات بوتيرة سريعة للغاية؛ في بيئة الاختبار، وصلت Aptos إلى سرعة تنفيذ معاملات مذهلة تبلغ 160 ألف معاملة في الثانية (tps)، وهو أسرع بمعدل 18 مرة من معالجة المعاملات التسلسلية.

يُفوِّض Block-STM تنفيذ المعاملات المعقدة والتحقق منها إلى فريق التطوير الأساسي، مما يتيح للمطورين كتابة العقود الذكية بسهولة تامة كما لو كانوا يبرمجون في بيئة تنفيذ تسلسلي.

2.5 قائمة الوصول إلى الحالة الصارمة

يعتمد آليات تمرير الرسائل والذاكرة المشتركة على نموذج بيانات الحساب/الرصيد، الذي يسجل معلومات الرصيد لكل حساب على البلوكتشين. إنه مشابه لكيفية تظهر دفتر البنك أن العميل أ لديه رصيد بقيمة 1,000 وحدة والعميل ب لديه رصيد بقيمة 600 وحدة. يتم معالجة المعاملات ببساطة عن طريق تحديث حالة الرصيد للحسابات.

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

• العميل أ يفتح حسابًا ويقوم بإيداع 1,000 وحدة؛
• العميل ب يفتح حسابًا (0 وحدة)؛
• العميل أ يحول 100 وحدة إلى العميل ب.

من خلال قراءة وحساب دفتر الأستاذ، يمكن تحديد أن العميل أ لديه رصيد قدره 900 وحدة، والعميل ب لديه رصيد قدره 100 وحدة.

UTXO (Unspent Transaction Output) مشابه لنموذج بيانات دفتر الحسابات لهذه المعاملة. يمثل طريقة للدلالة على العملة الرقمية في بيتكوين، وهو بلوكشين الجيل الأول. كل معاملة لها مدخلات (كيف تم استلام الأموال) ومخرجات (كيف تم إنفاق الأموال) ويمكن فهم UTXOs ببساطة على أنها إيصالات للأموال التي لم تُنفق بعد.

على سبيل المثال، إذا كان العميل أ لديه 6 بيتكوين وقام بتحويل 5.2 بيتكوين إلى العميل ب، متبقية 0.8 بيتكوين، من منظور UTXO يبدو الأمر كالتالي: يتم تدمير 6 UTXOs تقدر قيمتها بـ 1 بيتكوين لكل منها، ويتلقى ب UTXO جديدة بقيمة 5.2 بيتكوين، بينما يتلقى أ UTXO جديدة بقيمة 0.8 بيتكوين كباقي. وبالتالي، يتم تدمير 6 UTXOs لإنشاء 2 UTXOs جديدة.

ترتبط مداخل ومخارج عملية معًا وتستخدم تواقيع رقمية لتسجيل معلومات الملكية، وبالتالي تشكيل نموذج UTXO. تحتاج البلوكشينات التي تعتمد هذا النموذج البياناتي إلى جمع جميع UTXOs لعنوان حساب معين لتحديد رصيد الحساب الحالي. تعتمد Strict State Access List (SSAL) على نموذج UTXO وتمكّن التنفيذ المتوازي. يقوم بحساب عناوين الحسابات التي ستصل إليها كل عملية مسبقًا، مكوّنًا قائمة وصول.

قائمة الوصول تخدم غرضين:

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

3. سائقي نمو الصناعة

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

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

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

بالنسبة لتطوير الصناعة، على الرغم من أن مختلف الابتكارات التكنولوجية ونماذج الأعمال تظهر باستمرار، إلا أن الإمكانات الكامنة لنمو Web3 تظل غير مستغلة إلى حد كبير. يمكن للشبكات المركزية التعامل مع أكثر من 50،000 رسالة في الثانية، وإرسال 3.4 مليون بريد إلكتروني، وإكمال 100،000 بحث في جوجل، ودعم عشرات الآلاف من اللاعبين عبر الإنترنت في نفس الوقت، وهي إنجازات لم تتحقق بعد من قبل الشبكات اللامركزية. بالنسبة للأنظمة اللامركزية للتنافس ونحت أراضيها، فإن تحسين آليات التنفيذ المتوازي وتعزيز كمية المعاملات بشكل مستمر ضروري.

من وجهة نظر التطبيقات اللامركزية، يتطلب جذب المزيد من المستخدمين جهودًا كبيرة في تحسين تجربة المستخدم. تحسين الأداء هو اتجاه رئيسي واحد لتعزيز تجربة المستخدم. بالنسبة لمستخدمي DeFi، فإن تلبية الطلبات على سرعة المعاملات العالية والرسوم المنخفضة أمر حاسم. بالنسبة لمستخدمي GameFi، فإن التفاعل في الوقت الحقيقي ضروري. كل هذه المتطلبات مدعومة بقوة التنفيذ الموازي.

4.المشاكل القائمة

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

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

هناك على الأقل ثلاث وجهات نظر تقييمية لأمان المشروع:

1. خلفية الفريق: الفرق ذات الخبرة في برمجة النظم ماهرة في البرمجة متعددة الخيوط ويمكنها التعامل مع 80% من المشاكل المعقدة. تشمل برمجة النظم عادة المجالات التالية:

• أنظمة التشغيل
• مختلف مشغلات الجهاز
• أنظمة الملفات
• قواعد البيانات
• أنظمة مضمنة
• التشفير
• ترميزات الوسائط المتعددة
• إدارة الذاكرة
• الشبكات
• تجسيد الكيان
• ألعاب الفيديو
• لغات البرمجة المتقدمة

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

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

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

5. ترتيب الهدف

5.1 استنادًا إلى نموذج التوازي التفاؤلي

5.1.1 من قفل الذاكرة إلى التوازي التفاؤلي

سي هو بلوكتشين عام يستند إلى تقنية مفتوحة المصدر، تأسس في عام 2022. المؤسسون هم خريجو جامعة كاليفورنيا، بيركلي، وأعضاء الفريق الآخرين لديهم خلفيات من الجامعات الرصينة في الخارج.

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

في أغسطس 2023، أطلق Sei على شبكتها الرئيسية، مدعيًا أنه أسرع سلسلة كتل عامة من النوع L1، قادرة على معالجة 12،500 معاملة في الثانية، مع تحقيق النهوض في 380 مللي ثانية فقط. حاليًا، يبلغ رأس المال السوقي له حوالي 2.2 مليار دولار.

حاليًا، تتكون نظام سي من 118 مشروعًا، تركز أساسًا على DeFi والبنية التحتية وNFTs والألعاب والمحافظ. المجتمع حاليًا يضم 650,000 عضو على تويتر و600,000 على ديسكورد و40,000 على تليجرام.

في نهاية نوفمبر 2023، أعلنت Sei على مدونتها الرسمية أنها ستبدأ أكبر تحديث للإصدار منذ إطلاق الشبكة الرئيسية في النصف الأول من عام 2024: Sei v2. يتم ترويج Sei v2 كأول بلوكتشين EVM موازي. سيقدم هذا التحديث للإصدار ميزات جديدة التالية:

• التوافق المتوازي لعقود الذكاء الاصطناعي الافتراضية: يمكن للمطورين ترحيل ونشر عقود الذكاء الاصطناعي الافتراضية دون تعديل الشيفرة.
• قابلية إعادة الاستخدام للأدوات / التطبيقات الشائعة مثل Metamask.
• التوازي المتفائل: سيتخلف Sei v2 عن آلية الوصول المشترك لأقفال الذاكرة لصالح التوازي المتفائل.
• SeiDB: تحسين طبقة التخزين.
• دعم للتوافق السلس بين إيثيريوم وسلاسل أخرى.

في الأصل، كان تنفيذ المعاملات الموازي في شبكة Sei Network يعتمد على نموذج قفل الذاكرة. قبل التنفيذ، تم حل جميع التبعيات بين المعاملات المعلقة وتم إنشاء DAG، ثم بناءً على DAG، تم ترتيب ترتيب تنفيذ المعاملات بدقة. هذه الطريقة زادت العبء العقلي على مطوري العقود لأن عليهم أن يدمجوا المنطق في الكود أثناء التطوير.

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

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

5.1.2 العائق المحتمل في المسار L1: Monad

إذا فاتك تطور البلوكتشين العام المذكور أعلاه، فبالتأكيد يجب ألا تفوت Monad. يُشاع أنه محطم محتمل في المسار L1.

تأسست Monad من قبل مهندسين كبيرين من Jump Crypto في عام 2022. اكتملت المشروع جولة تمويل بذري بقيمة 19 مليون دولار في فبراير 2023. في مارس 2024، قادت Paradigm المفاوضات لجولة تمويل بأكثر من 200 مليون دولار لـ Monad. إذا نجحت، فسيكون هذا أكبر تمويل للعملات المشفرة منذ بداية العام.

لقد حقق المشروع بالفعل الإنجاز الرئيسي لإطلاق شبكة اختبار داخلية ويعمل نحو الخطوة التالية لفتح شبكة اختبار عامة.

يحظى Monad بتفضيل كبير من قبل رأس المال لسببين بارزين: الأول هو خلفيته التقنية الصلبة، والثاني هو كفاءته في التسويق الهاب. تتألف الفريق الأساسي لشركة Monad Labs من 30 عضوًا، جميعهم لديهم عقود من الخبرة العميقة في التداول بتردد عال، وبرامج تشغيل النواة، وتكنولوجيا التمويل، وخبرة تطويرية واسعة النطاق في أنظمة المعلومات الموزعة.

تشارك المشروع يوميًا في عمليات متجذرة للغاية: تشارك باستمرار في "التسويق السحري" مع 200،000 متابع على تويتر و 150،000 عضو في ديسكورد. على سبيل المثال، استضافة مسابقات الكركات الأسبوعية، وجمع العديد من الرموز التعبيرية البنفسجية الغريبة أو مقاطع الفيديو من المجتمع، لأداء "نشر روحي".

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

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

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

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

حاليًا، يصل أداؤه إلى 10,000 TPS ويمكنه إنتاج كتل في غضون ثانية واحدة. مع تقدم المشروع، سيركز الفريق الأساسي على استكشاف آليات تحسين إضافية.

5.1.3 مشروع L1 مرتفع اللامركزية: كانتو

تأسست في عام 2022، Canto هو مشروع L1 ذو لامركزية عالية مبني على Cosmos SDK. يعمل بدون مؤسسة رسمية، ولا يشارك في مبيعات مسبقة، ولا ينتمي إلى أي منظمة، ولا يسعى إلى تمويل، ويتم توجيهه بالكامل من قبل المجتمع. حتى فريق العمل الأساسي يظل مجهولًا، يعمل بطريقة منظمة بشكل فضفاض.

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

1. تبادلات لامركزية (DEX) مثل يوني سواب وسوشي سواب؛
2. منصات الإقراض مثل Compound و Aave؛
3. الرموز المشفرة اللامركزية مثل DAI، USDC، أو USDT.

ومع ذلك، تشترك أنظمة الديفي التقليدية في النهاية في مصير مشترك: إصدار رموز بروتوكول الحوكمة، التي تعتمد قيمتها على مقدار رسوم الاستخدام التي يمكن للنظام البيئي استخلاصها من مستخدميه المستقبليين - كلما تم استخلاص المزيد، زادت القيمة. هذا يشبه كل بروتوكول ديفي يكون موقف سيارات خاص يفرض رسومًا بالساعة - كلما استخدم، زاد تقديره.

كانتو تتبع نهجًا آخر: بناء بنية تحتية عامة مجانية لـ DeFi (بنية تحتية عامة مجانية)، تجعل نفسها موقف estacionamento مجانيًا لمشاريعها البيئية.

تتكون البنية التحتية من 3 بروتوكولات: بورصة كانتو المركزية للصرف ، ومنصة الإقراض المجمعة كانتو للتمويل (CLM) المشوهة من Compound v2 ، والعملة الثابتة NOTE التي يمكن إقراضها من CLM من خلال الأصول الرهنية.

اعتمد كانتو نهجًا جديدًا: بناء بنية تحتية عامة مجانية مستهدفة لديفي، متمثلة في نفسها كموقف سيارات مجاني متاح لمشاريع النظام البيئي الخاص بها لاستخدامه بدون تكلفة.

تتكون البنية التحتية من ثلاث بروتوكولات: بورصة Canto DEX المركزية، ومنصة إقراض السيولة المجمعة Canto Lending Market (CLM) المشتقة من Compound v2، والعملة المستقرة NOTE، التي يمكن استعارتها من CLM باستخدام الأصول المرهونة.

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

يتم التحكم في حوكمة منصة الإقراض CLM من قبل أصحاب المصلحة، الذين يستفيدون بالكامل من نمو النظام البيئي وبالتالي يخلقون أفضل بيئة للمطورين ومستخدمي DeFi، محفزين إياهم بشكل مستمر للمساهمة. يتم دفع الفائدة المُولدة من القروض المُصدرة في NOTE إلى المقترضين، دون أن يأخذ البروتوكول أي قطعة منها.

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

من خلال وسائل مختلفة، تحفز Canto مطوري النظام البيئي والمستخدمين على الانضمام إلى النظام البيئي وإثرائه باستمرار. من خلال التحكم بإحكام في "حقوق سك العملة" ، تخلق Canto إمكانيات للسيولة عبر التطبيقات بين مختلف التطبيقات اللامركزية. مع ازدهار النظام البيئي ، تزداد قيمة رموزه. بعد الموافقة على اقتراح المسؤولية الاجتماعية للشركات من خلال تصويت المجتمع في 26 يناير 2024 ، شهد رمز $CANTO ارتفاعا في الأسعار.

بعد هذه السلسلة من الابتكارات في نموذج الأعمال، في 18 مارس 2024، أعلنت كانتو عن آخر جولة من التحسينات التقنية على مدونتها الرسمية.

بالإضافة إلى اعتماد نسخة جديدة من Cosmos SDK ودمج تقنيات جديدة لتقليل Eng: storage access bottlenecks، سوف يقوم Canto أيضًا بالترقية إلى EVMs متوازية: مدخلًا توازنًا تفاؤليًا من خلال تنفيذ Cyclone EVM.

يقوم Cosmos SDK المستخدم بواسطة Canto بتقسيم معالجة المعاملات إلى ثلاث مراحل: الاقتراح، التصويت، والاستكمال. يتولى عملية ProcessProposal الفرعية خلال التصويت مسؤولية التنفيذ المتوازي للمعاملات. يتولى محرك التنفيذ المتوازي التنفيذ، بينما يتحقق محرك اكتشاف الصراع من صحة المعاملات.

إذا كانت الصفقة غير صالحة، يتم إرجاعها إلى محرك التنفيذ لإعادة التنفيذ؛ إذا كانت صالحة، يتم التعهد بها لتدفق المعالجة التالي. يُعتقد أن هذا الجولة من الترقيات التكنولوجية ستجعل عملات Canto أكثر جاذبية حتى.

5.2 استناداً إلى قوائم الوصول إلى الحالة الصارمة: الوقود

وقود، المكون من الجهاز الظاهري FuelVM، لغة تطوير العقود Sway مستوحاة من Rust، وسلسلة أدواته المرتبطة، هو “نظام تشغيل rollup الأثيريوم المخصص المبني بشكل موديل.” تم إنشاء مشروع Fuel في عام 2019، وفي ديسمبر 2020، أطلقت Fuel Labs الطبقة التنفيذية الأولية المتفائلة على الأثيريوم، Fuel v1. بعد أكثر من ثلاث سنوات من التطوير، من المقرر أخيرًا إطلاق شبكته الرئيسية في الربع الثالث من عام 2024.

أكملت Fuel جولات تمويل بقيمة 1.5 مليون دولار و 80 مليون دولار في عامي 2021 و 2022 على التوالي. يتكون الفريق الأساسي من أكثر من 60 مهندسًا، حيث يكون المؤسس جون آدلر أيضًا مؤسسًا مشاركًا في حل متوفرية البيانات Celestia Labs وأحد أوائل داعمي نهج الـ optimistic rollup. من حيث العمليات، يحتوي المشروع على 270,000 عضو على تويتر و 390,000 على ديسكورد.

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

الرول أب هو حلاً لتوسيع القدرة يعمل خارج L1، ينفذ المعاملات بدفعات خارج السلسلة ومن ثم يرسل بيانات المعاملة أو دلائل التنفيذ إلى L1. يضمن ذلك الأمان من خلال طبقة DA وتسوي المعاملات. هناك نوعان رئيسيان من الرول أب: التفاؤلي والمعرفة الصفرية (ZK).

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

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

يستخدم الوقود نموذج بيانات UTXO، الذي يتمتع بميزة أن مخرجات المعاملات الخاصة به تكون لها حالتان فقط: إما أن تكون قد أُنفقت وسُجلت بشكل دائم في تاريخ معاملات الكتلة، أو أن تكون لم تُنفق بعد ومتاحة للمعاملات المستقبلية. وهذا يقلل من البيانات الحالية المخزنة على كل عقد في السلسلة. استنادًا إلى هذا، يقوم الوقود بفحص معلومات الحساب التي تم الوصول إليها من قبل كل معاملة قبل التنفيذ، محددًا التبعيات وجدولة المعاملات التي ليس لها تبعيات ليتم تنفيذها بشكل متوازٍ، مما يعزز إنتاجية معالجة المعاملات.

5.3 التكامل العابر للسلاسل L1 مع حلول L2: Neno، Eclipse، و Lumio

تشترك حلول L2 في ميزة مشتركة: إنها تجمع بين قدرات نوعين من الآلات الافتراضية لتعزيز سرعة تنفيذ المعاملات. وتتضمن هذه النقطة تحديدًا استخدام L1 موازية لتنفيذ المعاملات مع الحفاظ على التوافق مع سلاسل أخرى (دعم الآلة الافتراضية المزدوجة). ومع ذلك، تختلف آليات التوافق التي تتبناها مشاريع مختلفة. من هذا المنظور، تكون Neon وEclipse وLumio ممثلة بشكل خاص.

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

المشاريع الأخريتين لا تزال في مراحل مبكرة نسبيًا. تجمع Lumio بين Aptos وEthereum لإنشاء بروتوكول تراصفي تحفيزي L2، ينفذ تطبيقات Ethereum بكفاءة بسرعة حركة VM.

من حيث التمويل، أكملت نيون جمع تبرعات بقيمة 40 مليون دولار في نوفمبر 2021 و 5 ملايين دولار في يونيو 2023، بإجمالي قدره 45 مليون دولار. أكملت إكليبس جمع تبرعات بقيمة 6 ملايين دولار في أغسطس 2022، و 9 ملايين دولار في سبتمبر 2022، و 50 مليون دولار في مارس 2024، بإجمالي قدره 65 مليون دولار. لميو لم تقم بجمع التمويل بعد.

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

من وجهة نظر الآلية، نيون هو محاكي EVM على شبكة سولانا، يعمل كعقد ذكي. يمكن للمطورين استخدام لغات مثل Solidity و Vyper لكتابة تطبيقات dApp، ويمكنهم استخدام سلاسل أدوات Ethereum وواجهات برمجة تطبيقات RPC Ethereum المتوافقة، حسابات، تواقيع، ومعايير الرموز، مثل MetaMask، Hardhat، وRemix. في الوقت نفسه، يتمتعون بفوائد الرسوم المنخفضة، وسرعة تنفيذ المعاملات العالية، وقدرات المعالجة المتوازية التي يوفرها سولانا.

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

إكليبس يعتمد نهج تنفيذ مختلف: تنفيذ المعاملات من خلال SVM وتسوية المعاملات من خلال EVM. إكليبس يستخدم البنية المعمارية للبلوكتشين النمطي، حيث يتعامل فقط مع تنفيذ المعاملات ويستعين بالمسؤوليات الأخرى، ويشكل حلا موحدا من خلال التركيبات النمطية.

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

يعتمد Lumio على فلسفة تصميم مستقلة عن طبقات التنفيذ والتسوية، وتدعم العديد من الآلات الافتراضية ومتوافقة مع شبكات L1/L2 المتعددة: Ethereum، Aptos، Optimism، Avalanche، zkSync، وغيرها. ينفذ الصفقات من خلال Move VM ويُسويها من خلال EVM، مما يربط بين نظامي Ethereum و Aptos.

ومع ذلك، لا تتوقف طموحات لوميو هنا. رؤيتها هي توفير مكالمات عابرة للآلة الافتراضية لتحقيق توصيل سيولة متعددة البلوكتشين بأسرع سرعة وأقل أسعار.

المشاريع الرئيسية المتعلقة حاليًا بالسرد المتوازي EVM المذكور أعلاه، كما هو موضح في الرسم البياني التالي.

6. الاستنتاج والنظرة المستقبلية

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

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

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

من ناحية واحدة، تشترك EVMs المتوازية في المبادئ التقنية المشتركة. أولاً، نموذج التوازن التفاؤلي هو اتفاق لبلوكتشينات L1 العامة. ومع ذلك، هذا لا يعني أن نموذج قفل الذاكرة غير مفيد. التفوق التكنولوجي لا يوجد؛ بل هو مستوى مهارة المطورين الذي يتفاوت.

ثانياً، يعتقد مشاريع مثل Fuel بقوة أن آليات التوسيع خارج السلسلة يمكن أن تحقق أداءها الأقصى بعد تقسيمها إلى وحدات. وأخيرًا، تسعى العديد من مشاريع L2 إلى تعزيز قدرة معالجة المعاملات عن طريق التكامل مع سلاسل L1 العامة المتوازية، وبالتالي تحقيق قدرات توسيع النظام البيئي متقاطعة.

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

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

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

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

الـEVMs المتوازية لا تزال في مراحل التطوير الأولية، مع مشاريع مثل Neon، Monad، Canto، Eclipse، Fuel، وLumio في المرحلة التي لم يتم فيها تحقيق قيمتها بالكامل. خاصة، Monad، Canto، وFuel.

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

بيان:

1. هذه المقالة مأخوذة من Gryphsis Academy) ، العنوان الأصلي هو “تفسير عشرة آلاف كلمة لـ Parallel EVM: كيفية تجاوز عقبة أداء البلوكتشين؟”، حقوق النشر تعود إلى الكاتب الأصلي [@leesper6], إذا كان لديك أي اعتراض على إعادة الطبع، يرجى الاتصال فريق بوابة التعلم، سيقوم الفريق بالتعامل معه في أقرب وقت ممكن وفقا للإجراءات ذات الصلة.

2. تنويه: تعبر الآراء والآراء المعبر عنها في هذه المقالة فقط عن آراء الكاتب الشخصية ولا تشكل أي نصيحة استثمارية.

3. تتم ترجمة النسخ الأخرى من المقال بواسطة فريق Gate Learn ولا يتم ذكرها فيهاGate.ioقد لا يُعيد ترجمة المقال، توزيعه، أو نسخه.