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

مقدمة

في عام 1837، قام عالم الكمبيوتر والرياضيات تشارلز باباج بتصميم ال“محرك تحليلي, التي وضعت الأسس النظرية للحساب المتوازي. اليوم، تعد التوازي هي موضوع محوري داخل عالم العملات الرقمية حيث تحاول التقنيات الحديثة دفع حدود المعالجة والكفاءة ومعدل التدفق.

الكون الموازي

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

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

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

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

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

1. نظرة عامة على أنظمة العملات المشفرة المتوازية
2. أساليب الوصول إلى الذاكرة والحالة
3. فرص تصميم متوازية

أنظمة موازية غير العملات المشفرة

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

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

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

نظرة عامة على التصميم الموازي - سولانا

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

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

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

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

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

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

نظرة عامة على التصميم المتوازي - سي

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

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

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

المصدر: https://blog.sei.io/sei-v2-the-first-parallelized-evm/

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

نظرة عامة على التصميم الموازي - Monad

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

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

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

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

طرق فريدة للوصول إلى الحالة والذاكرة

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

وصول حالة سولانا: حسابات قاعدة البيانات / كلودبريك

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

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

رسم توضيحي لهرم الذاكرة

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

الوصول الى حالة Sei: SeiDB

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

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

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

الوصول إلى الدولة: MonadDB

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

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

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

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

ملخص المقارنات بين سولانا مقابل سي مقابل موناد

استنتاج

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

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

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

في الجزء الثاني من هذه السلسلة، سنقوم بالغوص في الآثار الاقتصادية والتنازلات المرتبطة بأنظمة التصميم المتوازية هذه.

إخلاء المسؤولية:

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