التنفيذ الموازي لأبحاث نظام blockchain

تأليف: PREDA؛ إعداد: ChainFeeds Research

محتوى هذه المقالة والغرض منها

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

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

نعتقد أنه من بين العديد من أنظمة blockchain عالية الأداء التي تدعم الأجهزة الافتراضية المتوازية وSei (V2) وAptos وSui وCrystality وبريدا النظام الأكثر تمثيلاً، يتمتع كل نظام بمزايا فريدة في التصميم.

في بداية هذا المقال نعرض المجموعة الأولى من النتائج التجريبية. يوضح الرسم البياني أدناه القيمة المطلقة للمعاملات في الثانية (TPS) لـ Sei وAptos وSui وCrystality وPREDA عند تنفيذ نفس العقد الذكي ERC20 على جهاز ذو 128 نواة. من هذه المجموعة من النتائج التجريبية، يتمتع نموذج PREDA بميزة كبيرة في مقارنة TPS وقابلية التوسع لخمسة أنظمة تنفيذ متوازية.

سوف نتوسع في البيانات التجريبية الأخرى والتحليلات بالتفصيل لاحقًا.

قمنا أولاً بمقارنة قيم TPS، أي الإنتاجية، للأنظمة الخمسة. أحجام المعاملات المستخدمة في تجارب مقارنة TPS التي تم إجراؤها على سلاسل مختلفة هي نفسها.

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

للحصول على جميع البيانات التجريبية التفصيلية، بما في ذلك قيم TPS المطلقة ونسب التسريع، يرجى الرجوع إلى تقرير التجربة الكامل .

يوضح الجدول التالي مصادر البيانات وعملية التنفيذ وطرق التقييم المستخدمة في التجربة.

نظرة عامة على نماذج التنفيذ المتوازي

يستمد كل من مشروعي Aptos وSui من مشروع blockchain الفاشل Diem of Meta (المعروف سابقًا باسم Facebook). تم تأسيس كلا المشروعين من قبل مهندسي Meta السابقين - Aptos بواسطة Avery Ching وSui بواسطة Sam Blackshear. كانت الطرق التقنية التي اتبعها الاثنان مختلفة، حيث اتبعت Aptos بدقة لغة برمجة Move الأصلية التي تم تطويرها لـ Diem، لكن Sui أجرى الكثير من التعديلات على Move.

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

Aptos: الطبقة الأولى عالية الأداء باستخدام الموازاة المتفائلة

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

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

تستخدم Aptos لغة برمجة MOVE لتطوير العقود الذكية وتستخدم آلة Aptos MOVE الافتراضية في تنفيذ النظام.

Sui: الطبقة 1 عالية الأداء مع موازاة متشائمة

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

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

تستخدم Sui أيضًا لغة برمجة MOVE، ولكن لديها امتدادات Sui MOVE الخاصة بها وتستخدم جهاز Sui MOVE الظاهري في تنفيذ النظام.

Sei: موازاة متفائلة متوافقة مع Solidity وEVM

عندما أطلقت Sei السلسلة العامة لأول مرة، تم وضعها كسلسلة تطبيقات معاملات مبنية على Cosmos SDK، والآن تمت ترقيتها إلى سلاسل Parallelize EVM الأولى. وعلى مستوى التنفيذ المتوازي، تتبنى Sei منهجًا مشابهًا لنموذج Aptos، وهو ما نسميه بالتوازي المتفائل.

يعد التوازي المتفائل الذي تتبناه Sei (V2) فريدًا من حيث أنه يستخدم لغة برمجة Solidity وجهاز Ethereum الظاهري القياسي (EVM) لضمان توافق EVM وSolidity.

Crystality وPREDA: بنية تنفيذ الترحيل المتوازي

يدعم كل من Crystalality وPREDA البنية الموزعة لتنفيذ الترحيل المتوازي. تم تصميم PREDA خصيصًا للعقود الذكية ذات الأغراض العامة المتوازية في بنيات blockchain متعددة EVM. العلاقة بين الاثنين هي أن Crystality هي لغة برمجة لـ EVM/GPU المتوازي بناءً على نموذج PREDA. من منظور النظام، تتيح PREDA لأول مرة في مجال blockchain تحقيق الموازاة الكاملة لوظائف العقد، وبالتالي زيادة التزامن لمجموعة من المعاملات. ويضمن ذلك الاستخدام الفعال لجميع مثيلات EVM، مما يؤدي إلى الأداء الأمثل وقابلية التوسع لتكوين جهاز معين.

يختلف نموذج PREDA عن التنفيذ المتسلسل لـ Solidity and Move، والتصميم المعماري لـ Shared Everything، ويعتمد بنية Shared Nothing لأول مرة لكسر تبعية الحالة في التنفيذ المتوازي وضمان وجود EVM مختلف. لن تصل المثيلات أبدًا إلى نفس جزء حالة العقد، وبالتالي تتجنب تعارضات الكتابة بشكل كامل تقريبًا.

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

بيانات تجريبية لخمسة عقود تمثيلية

في تقييمنا، اختبرنا خمسة عقود ذكية مستخدمة على نطاق واسع - ETH TokenTransfer، والتصويت، وAirdrop، وCryptoKitties، وMillionPixel، وMyToken ( ERC20). يتم تنفيذ هذه العقود على أنظمة blockchain المختلفة بما في ذلك Sei وAptos وSui وCrystality وPREDA. لقد أجرينا تجارب تفصيلية لمقارنة أداء أنظمة التنفيذ المتوازية المختلفة، مع التركيز على المعاملات في الثانية (TPS) والتسريع، والتي تقيس الأداء عند التنفيذ على أجهزة افتراضية متعددة مقارنة بجهاز افتراضي واحد لكل نظام.

للحصول على جميع البيانات التجريبية التفصيلية، بما في ذلك قيم TPS المطلقة ونسب التسريع، يرجى الرجوع إلى تقرير التجربة الكامل .

1. عقد نقل رمز ETH: تستخدم هذه التجربة نفس معاملات ETH التاريخية الفعلية مثل العقد الذكي القياسي ERC20.

2. عقد التصويت: يعد عقد التصويت مثالًا ممتازًا لكيفية تبسيط نموذج PREDA لخوارزميات التصويت الموازية. إنه يعزز آليات تقسيم البيانات وترحيلها وتنفيذها في Crystality وPREDA، ويتفوق في الأداء على أساليب الموازاة المتفائلة (Aptos) والمتشائمة (Sui) في كل من TPS المطلق والتسريع. تسمح الآن الخوارزميات التسلسلية الموجودة أصلاً في Solidity بالتصويت بالتوازي عبر الأجهزة الافتراضية، مع تجميع النتائج من المصفوفات المؤقتة.

3. AirDrop: يؤدي هذا العقد إلى عمليات نقل متعددة للرموز المميزة أو NFTs من عنوان واحد إلى عناوين متعددة. لديها نمط تغيير حالة واحد إلى متعدد. في هذه الحالة، لا يمكن تنفيذ معاملتين في Sei أو Aptos أو Sui بالتوازي. فقط من خلال نموذج PREDA ذو التفاصيل المتوازية الأعلى يمكن معالجة هذه المعاملات بالتوازي في وضع خط الأنابيب.

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

5. MillionPixel: في عقد اللعبة هذا على Ethereum، يجب أن يكون المستخدمون أول من يضع علامة على الإحداثيات على الخريطة. يُستخدم هذا العقد الذكي لإثبات مرونة نموذج PREDA. بالإضافة إلى تقسيم حالة العقد حسب العنوان، يمكن للمبرمجين أيضًا تخصيص مفتاح القسم، مثل التبديل من نوع العنوان إلى نوع uint32 في هذه الحالة.

   

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

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

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

الإلهام من النتائج التجريبية

حصلنا على الإلهام التالي من النتائج التجريبية:

مقارنة الطرق المتوازية المتفائلة والمتشائمة

Aptos يقدم كل من Sui وSui أفضل أداء في سيناريوهات محددة مختلفة. في حالة عمليات نقل ERC20، يكون أداء Aptos أفضل من Sui لأن عمليات نقل ERC20 تستخدم عناوين تم إنشاؤها عشوائيًا في كل معاملة، مما يؤدي إلى عدد قليل جدًا من التعارضات. في المقابل، في حالة اختبار ETH، تفوقت Sui على Aptos نظرًا للعدد الكبير من التعارضات التي حدثت من خلال إعادة تشغيل المعاملات التاريخية لـ ETH.

تحليل الوقت في تنفيذ Aptos

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

يتضمن تنفيذ معاملات Aptos كلا من التنفيذ والتنفيذ التحقق في هذه الخطوة، توضح بيانات الاختبار أن عددًا كبيرًا من حالات تنفيذ المعاملات تم وضع علامة "معلق" عليها (معلق)، وأن تنفيذ هذه المعاملات يستغرق وقتًا طويلاً. "تعليق" يعني تعليق تنفيذ المعاملة حتى يتم حل تبعيات الحالة الخاصة بها قبل استئناف التنفيذ. بالنسبة للمعاملات العشوائية على 64 جهازًا افتراضيًا، يبلغ إجمالي عدد عمليات التنفيذ والتحقق 102,219 و139,426 على التوالي. بالنسبة للمعاملات التاريخية، ارتفعت هذه الأرقام إلى 186,948 و667,148، مع زيادة المعاملات المعلقة من 66 إلى 46,913. ومن ثم، عندما يحدث عدد كبير من تعارضات الحالة في تنفيذ المعاملة، يصبح التراجع عبئًا ثقيلًا للتوازي المتفائل.

تحليل وقت تنفيذ Sui

يوضح الرسم البياني التالي Sui في اختبار عقد نقل رمز ETH ووقت اختبار عقد التصويت - تفاصيل المستهلكة. هناك ثلاث خطوات رئيسية في محرك التنفيذ المتوازي لـ Sui: (1) وقت الانتظار: وقت الانتظار قبل تحديد المعاملة من قبل مدير المعاملات (2) وقت إدارة المهام: يتم وضع المعاملة في خريطة تجزئة Txns التنفيذية الخاصة بـ Sui أو في انتظار المراجعة خريطة تجزئة Txns، الوقت بين وقت استلامها بواسطة برنامج تشغيل التنفيذ الخاص بـ Sui؛ (3) وقت تنفيذ الوظيفة: الوقت الذي يتم فيه تنفيذ وظيفة العقد بواسطة مؤشر ترابط العامل في برنامج تشغيل التنفيذ.

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

القيود المفروضة على Aptos وSui

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

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

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

أداء Crystalality وPREDA

في جميع اختبارات العقود، كانت بيانات أداء Crystalality وPREDA أفضل بكثير من Sei وAptos وSui، ومن بينها أداء PREDA جيد بشكل خاص لأنه يتم تنفيذه في الوضع الثنائي الأصلي بدلاً من WASM. يرجع هذا الأداء العالي إلى التنفيذ المتوازي الخالي من الصراعات تقريبًا. لقد أخذت PREDA في الاعتبار الجانبين الرئيسيين التاليين منذ بداية تصميمها:

1. حدد نطاقات مختلفة لحالة العقد، وسيقوم النظام بضبط الحالة بناءً على هذا النطاق، قم بالتقسيم والصيانة.

2. لتبديل تدفق تنفيذ المعاملة من جهاز افتراضي إلى جهاز افتراضي آخر.

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

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

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

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

على سبيل المثال، يمكن لمعاملات نقل الرمز المميز Txn 0 (نقل الرموز المميزة من حالة العنوان A إلى الحالة B) وTxn 1 (النقل من الحالة A إلى الحالة C) الوصول إلى A مرتين بالتسلسل (على التوالي لـ Txn 0 وTxn 0) Txn 1)، ثم قم بالوصول إلى B وC بالتوازي.

مقارنة معمارية للتنفيذ المتوازي في Aptos وSei وPREDA

القيود على PREDA والبلورية

بالرغم من ذلك يمكن لـ PREDA وCrystality تمكين أنظمة blockchain وتوفير مزايا كبيرة في الأداء، وتنعكس قيودهما أيضًا في الجوانب التالية.

اختلال توازن عبء العمل بين أجهزة EVM المتوازية

قد تتسبب آلية تقسيم البيانات وإعادة توجيه تدفق التنفيذ في Crystal في تعرض أجهزة EVM المتوازية للتحميل في وقت التشغيل مشكلة عدم التوازن. لقد لاحظنا هذه المشكلة عند استخدام عقد MyToken لإعادة تشغيل معاملات نقل ETH Token التاريخية.

لتقييم توزيع الحمل، قمنا بحساب عدد المعاملات التي تم تنفيذها على كل EVM، سواء كانت أولية أو مرحّلة، ثم قمنا بحساب النطاق والانحراف المعياري لهذه الأرقام. تظهر النتائج أن عدد المعاملات المنفذة على 64 جهازًا إلكترونيًا يختلف تمامًا عن النطاق الموجود على جهازين إلكترونيين، مما يعني أن هناك نقاطًا فعالة في عناوين معينة لآلات التصويت الإلكتروني (أي، حدث تركيز للمعاملات التاريخية على مجموعة فرعية من العناوين). وجد المزيد من التحقيق في مجموعة بيانات ETH أن كل عنوان ساخن شارك في أكثر من 4000 معاملة. ولا بد من الإشارة هنا إلى أنه، على حد علمنا، لا يمكن لـ Aptos وSui تنفيذ التنفيذ المتوازي في هذه الحالة.

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

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

إعادة كتابة البرنامج

هناك قيود مهمة أخرى على PREDA وCrystality وهي أن المطورين بحاجة إلى استخدام التوجيهات لإعادة كتابة العقود الذكية. إذا كانت هناك أداة يمكنها تلقائيًا ترجمة العقود الذكية الحالية المكتوبة بلغة Solidity أو Move أو Rust إلى عقود ذكية مكافئة لـ Crystality، فمن شأنها تحسين تجربة المطور بشكل كبير. انطلاقًا من التجارب السابقة، ليس من الصعب تحقيق ذلك، فقد كانت هناك بعض الدراسات التي تستكشف الترجمة بين اللغات المختلفة، مثل من Solidity إلى Move ومن Python إلى Solidity.

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

الاستنتاج

تسلط مقارنة الأداء بين Sei وAptos وSui وCrystality/PREDA الضوء على المجال المتطور لموازاة blockchain. يُظهر Aptos (مع Sei) وSui إمكانات آليات الموازاة المتفائلة والمتشائمة على التوالي، حيث يُظهر كل منهما مزايا في سيناريوهات مختلفة. ومع ذلك، تشير التحسينات الكبيرة في أداء Crystalality وPREDA إلى أن نماذج الموازاة الأكثر تقدمًا قد تكون المفتاح لفتح مستويات أعلى من قابلية التوسع والكفاءة.

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