استكشاف مساحة التصميم لسلاسل الكتل المتوازية

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

ستوضح هذه المقالة بنية التصميم الموازية لـ blockchain، مع استعارة ثلاثة أمثلة ذات صلة: Solana وSei وMonad. تسلط هذه المقالة الضوء على الفرق بين التوازي المتفائل والحتمي، وتتفهم الفروق الدقيقة في الوصول إلى الحالة والذاكرة في هذه السلاسل.

1، مقدمة

في عام 1837، صمم عالم الكمبيوتر وعالم الرياضيات تشارلز باباج "المحرك التحليلي" الذي وضع الأساس النظري لـ الحوسبة المتوازية. يعد التوازي موضوعًا رئيسيًا في عالم العملات المشفرة هذه الأيام، وتحاول سلاسل الكتل دفع حدود المعالجة والكفاءة والإنتاجية.

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

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

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

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

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

2، النظام الموازي غير المشفر

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

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

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

• Unityمحرك اللعبة:يستخدم محرك Unity قوة وحدة معالجة الرسومات (المصممة لأحمال عمل الرسومات واسعة النطاق) للمساعدة في تحسين الأداء والسرعة. تم تجهيز المحرك بقدرات معالجة متعددة الخيوط ومتوازية للحصول على تجربة لعب سلسة والقدرة على إنشاء بيئات ألعاب معقدة وواقعية.

دعونا نلقي نظرة على ثلاث سلاسل من الكتل التي نشرت بيئات تنفيذ متوازية. أولاً، ننظر إلى Solana، ثم إلى سلسلتين قائمتين على EVM - Monad وSei.

3، نظرة عامة على التصميم المتزامن

(1) سولانا

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

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

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

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

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

من خلال هذه الابتكارات، يمكننا أن نرى أن Solana مصمم عمدًا لدعم التوازي.

(2) Sei

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

يستخدم Sei Blockchain آلية "التحكم المتفائل في التزامن (OCC)" لتنفيذ المعاملات. تحدث معالجة المعاملات المتزامنة عندما تكون هناك معاملات متعددة نشطة في النظام في نفس الوقت. تتكون طريقة التداول هذه من مرحلتين: التنفيذ والتحقق.

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

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

(3) Monad

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

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

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

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

4، نهج فريد للوصول إلى الحالة والذاكرة

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

(1) Solanaالوصول الحالة: AccountsDB / Cloudbreak

تستفيد Solana من التوسع الأفقي من أجل توزيع وإدارة بيانات الحالة عبر أجهزة SSD متعددة. اليوم، تستخدم العديد من سلاسل الكتل قواعد بيانات للأغراض العامة (مثل LevelDB)، والتي لها قيود في التعامل مع كميات كبيرة من عمليات القراءة والكتابة المتزامنة لبيانات الحالة. ولتجنب ذلك، استفادت Solana من Cloudbreak لبناء قاعدة بيانات الحسابات المخصصة الخاصة بها.

تم تصميم Cloudbreak للوصول المتوازي عبر عمليات الإدخال/الإخراج، بدلاً من الاعتماد فقط على ذاكرة الوصول العشوائي (RAM) السريعة بطبيعتها. عمليات الإدخال/الإخراج (الإدخال/الإخراج) هي العمليات التي تقرأ البيانات من أو تكتب البيانات إلى مصدر خارجي مثل القرص أو الشبكة أو الجهاز الطرفي. في البداية، استخدمت Cloudbreak فهرسًا داخليًا لذاكرة الوصول العشوائي (RAM) لتعيين المفاتيح العامة للحسابات التي تحتفظ بالأرصدة والبيانات. ومع ذلك، حتى كتابة هذه السطور، تم نقل مؤشر V1.9 من ذاكرة الوصول العشوائي (RAM) إلى SSD. يتيح هذا التحول لـ Cloudbreak التعامل مع 32 عملية (إدخال/إخراج) في وقت واحد في قائمة الانتظار الخاصة بها، مما يعزز الإنتاجية عبر محركات أقراص SSD متعددة. لذلك، يمكن الوصول إلى بيانات blockchain مثل الحسابات والمعاملات بكفاءة تمامًا كما هو الحال في ذاكرة الوصول العشوائي (RAM) باستخدام ملفات الذاكرة المعينة. ويوضح الشكل التالي بنية الذاكرة. على الرغم من أن ذاكرة الوصول العشوائي (RAM) أسرع، إلا أنها تتمتع بسعة أصغر من SSD وتكون أكثر تكلفة بشكل عام:

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

(2) Seiالوصول إلى الحالة: SeiDB

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

في Sei V2، يستخدم التزام الحالة بنية شجرة IAVL المعينة للذاكرة (MemIAVL). تقوم أشجار IAVL المعينة للذاكرة بتخزين بيانات تعريف أقل، مما يقلل من تخزين الحالة ووقت مزامنة الحالة ويجعل تشغيل العقد الكاملة أسهل. يتم تمثيل شجرة IAVL المعينة للذاكرة على هيئة ثلاثة ملفات على القرص (ملف kv، وملف فرعي، وملف ورقي)؛ وبالتالي، هناك بيانات تعريف أقل لتتبعها، مما يساعد على تقليل تخزين الحالة بأكثر من 50%. تساعد بنية MemIAVL الجديدة على تقليل عامل تضخيم الكتابة لأنها تقلل بيانات التعريف المطلوبة للحفاظ على بنية البيانات.

يتيح SeiDB المحدث دعمًا مرنًا للواجهة الخلفية لقاعدة البيانات لطبقة تخزين الحالة. يعتقد Sei أن مشغلي العقد المختلفين لديهم احتياجات واحتياجات تخزين مختلفة. لذلك، تم تصميم SS للتكيف مع احتياجات الواجهة الخلفية المختلفة وتزويد المشغلين بالحرية والمرونة، مثل PebbleDB وRocksDB وSQLite وما إلى ذلك.

(3) Monadالوصول إلى الحالة: MonadDB

يتمتع الوصول إلى حالة Monad ببعض الأهمية الفروق الدقيقة. أولاً، يستخدم معظم عملاء Ethereum نوعين من قواعد البيانات: قواعد بيانات B-Tree (أي LMDB) أو قواعد بيانات شجرة الدمج المنظمة بالسجل (LSM) (أي RocksDB، وLevelDB). كلاهما عبارة عن هياكل بيانات ذات أغراض عامة وليست مصممة خصيصًا لـ blockchain. علاوة على ذلك، لا تستفيد قواعد البيانات هذه من أحدث التطورات في تكنولوجيا Linux، خاصة في العمليات غير المتزامنة وتحسين الإدخال/الإخراج. أخيرًا، تدير Ethereum نفسها الحالة باستخدام أشجار MPT، المخصصة للتشفير والتحقق والإثبات. تكمن المشكلة الرئيسية في أنه يتعين على العميل دمج شجرة MPT المحددة هذه في قاعدة بيانات أكثر عمومية (مثل B-Tree/LSM)، مما يؤدي إلى عيوب خطيرة في الأداء مثل الوصول الزائد إلى القرص.

ساعد كل هذا في إرساء الأساس لقرار Monad بإنشاء قاعدة بيانات MonadDB مخصصة مصممة للتعامل مع بيانات blockchain والوصول إلى الحالة بشكل أكثر كفاءة. تتضمن بعض الميزات الرئيسية لـ MonadDB الوصول المتوازي إلى قاعدة البيانات، وقاعدة بيانات مخصصة محسنة لبيانات Merkle Trie، والوصول الفعال إلى الحالة عبر الاستخدام القياسي لذاكرة الوصول العشوائي (RAM)، واللامركزية وقابلية التوسع.

تم تصميم MonadDB خصيصًا لتقنية blockchain، مما يجعلها أكثر أداءً من استخدام قاعدة بيانات للأغراض العامة. تم تصميم MonadDB المخصص لإدارة بيانات نوع Merkle Trie بكفاءة ويدعم الوصول المتوازي إلى عقد Trie المتعددة في نفس الوقت. على الرغم من أن تكلفة قراءة MonadDB هي نفس تكلفة بعض قواعد البيانات العامة المذكورة أعلاه، إلا أن الميزة الرئيسية لـ MonadDB هي أنه يمكنه تشغيل عمليات قراءة متعددة بالتوازي، مما يؤدي إلى عمليات تسريع هائلة.

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

5 . الخلاصة

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

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

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