بريدا: القطعة الأخيرة من أحجية VM الموازية

تأليف: PREDA المصدر: chainfeeds 

الملخص

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

المستوى الثاني من التوازي هو التوازي على مستوى البيانات، والذي يشير بشكل أساسي إلى البنية المتجهة لتدفق بيانات متعدد لتدفق تعليمات واحد ( سيمد). ظهر أول توازي على مستوى البيانات في ENIAC. كانت آلات المتجهات التي تمثلها Cray تحظى بشعبية كبيرة في الستينيات والسبعينيات من القرن العشرين، بدءًا من Cray-1 وCray-2 وحتى Cray X-MP وCray Y-MP لاحقًا. لقد ظل SIMD خاملًا لفترة من الوقت حتى Cray-4، ولكنه الآن يعود إلى الحياة ويتم استخدامه أكثر فأكثر. على سبيل المثال، يمكن لتعليمات الوسائط المتعددة AVX في X86 استخدام مسار 256 بت لإجراء أربع عمليات 64 بت أو ثماني عمليات 32 بت. كمكمل فعال للتوازي على مستوى التعليمات، يلعب SIMD دورًا مهمًا في مجال وسائط البث. في الأيام الأولى، كان يستخدم بشكل أساسي في المعالجات ذات الأغراض الخاصة، ولكنه أصبح الآن تكوينًا قياسيًا للمعالجات ذات الأغراض العامة. .

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

من منظور تطوير الحوسبة المتوازية، فإن blockchain اليوم في طور التحول من المستوى الأول إلى المستوى الثاني. عادةً ما تعتمد أنظمة blockchain السائدة بنيات أحادية السلسلة أو متعددة السلاسل. تحتوي السلاسل الفردية، مثل Bitcoin وEthereum، على سلسلة واحدة فقط في النظام بأكمله، وتقوم كل عقدة من السلسلة بتنفيذ نفس معاملة العقد الذكي تمامًا وتحافظ على حالة متسقة تمامًا على السلسلة. داخل كل عقدة blockchain، عادةً ما يتم تنفيذ معاملات العقود الذكية بشكل تسلسلي، مما يؤدي إلى انخفاض إنتاجية النظام بأكمله. على الرغم من أن بعض أنظمة blockchain عالية الأداء التي ظهرت مؤخرًا تتبنى بنية السلسلة الواحدة، إلا أنها تدعم أيضًا التنفيذ المتوازي لمعاملات العقود الذكية. اقترح توماس ديكرسون وموريس هيرليهي من جامعة براون وجامعة ييل لأول مرة نموذج تنفيذ متوازي يعتمد على طريقة STM (ذاكرة معاملات البرامج) في ورقتهم البحثية PODC'17. تستخدم هذه الطريقة التوازي المتفائل (التوازي المتفائل) للجمع بين المعاملات المتعددة التي يتم تنفيذها بالتوازي، إذا واجهت المعاملة تعارضًا في الوصول إلى الحالة أثناء التنفيذ المتوازي، فسيتم إرجاع الحالة مرة أخرى من خلال STM، ثم يتم تنفيذ هذه المعاملات ذات تعارضات الحالة بشكل تسلسلي. تم تطبيق هذه الطريقة على العديد من مشاريع blockchain عالية الأداء، بما في ذلك Aptos وSei وMonad وما إلى ذلك. في المقابل، يعتمد نموذج التنفيذ الموازي الآخر على التزامن المتشائم (التوازي المتشائم)، أي أنه قبل تنفيذ المعاملة بالتوازي، من الضروري اكتشاف ما إذا كان هناك تعارض في الحالة التي يمكن الوصول إليها من خلال المعاملة يتم تنفيذها بالتوازي. عادةً ما يعتمد هذا النوع من الأساليب طريقة ما قبل الحساب، باستخدام أدوات تحليل البرنامج لتحليل كود العقد الذكي بشكل ثابت وبناء تبعيات الحالة، مثل الرسم البياني غير الدوري الموجه (DAG). عندما يتم إرسال معاملة متزامنة إلى النظام، يحدد النظام ما إذا كان يمكن تنفيذ المعاملة بالتوازي بناءً على الحالات التي تحتاج المعاملة للوصول إليها والتبعيات بين الحالات. سيتم تنفيذ المعاملات التي ليس لها تبعيات حالة على بعضها البعض بالتوازي فقط. تم تطبيق هذا النوع من الأساليب على مشاريع blockchain عالية الأداء مثل Zilliqa (إصدار CoSplit) وSui. يمكن لنماذج التنفيذ المتوازي المذكورة أعلاه تحسين إنتاجية النظام بشكل كبير. يتوافق هذان الحلان مع توازي مستوى التعليم المذكور أعلاه. ومع ذلك، تعاني هذه الأعمال من مشكلتين: 1) مشكلة قابلية التوسع و2) مشكلة التعبير الدلالي الموازي، والتي سنتناولها بالتفصيل أدناه.

التصميم المتوازي

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

سولانا

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

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

Monad

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

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

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

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

p>

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

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

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

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

فهل هناك حل جاهز؟

نموذج البرمجة المتوازية

قبل تقديم PREDA، نود أن نطرح سؤالًا طبيعيًا: :لماذا نستخدم البرمجة المتوازية؟ خلال السبعينيات والثمانينيات وحتى جزء من التسعينيات، كنا راضين تمامًا عن البرمجة أحادية الخيط، والمعروفة أيضًا باسم البرمجة التسلسلية. يمكنك كتابة برنامج لإنجاز مهمة ما. وبعد التنفيذ سوف يعطيك النتيجة . تم إنجاز المهمة، وسيكون الجميع سعداء! تم إنجاز المهمة، ولكن إذا كنت تقوم بمحاكاة الجسيمات التي تتطلب ملايين أو مليارات العمليات الحسابية في الثانية، أو تقوم بمعالجة الصور بعشرات الآلاف من وحدات البكسل، فستحتاج إلى تشغيل البرنامج بشكل أسرع، مما يعني أنك بحاجة إلى وحدة معالجة مركزية أسرع.
قبل عام 2004، كان بإمكان الشركات المصنعة لوحدة المعالجة المركزية IBM وIntel وAMD أن توفر لك معالجات أسرع فأسرع. وقد زاد تردد ساعة المعالج من 16 ميجاهرتز، و20 ميجاهرتز، و66 ميجاهرتز، و100 ميجاهرتز، ثم زاد تدريجيًا إلى 200 ميجاهرتز. 333 ميجا هرتز، 466 ميجا هرتز... يبدو أنه يمكنهم زيادة سرعة وحدة المعالجة المركزية بشكل مستمر، أي أنه يمكنهم تحسين أداء وحدة المعالجة المركزية بشكل مستمر. ولكن بحلول عام 2004، كان من الواضح بالفعل أن الزيادات في سرعة وحدة المعالجة المركزية لا يمكن أن تستمر بسبب القيود التقنية. وهذا يتطلب تقنيات أخرى لمواصلة تقديم أداء أعلى. كان الحل الذي قدمته الشركات المصنعة لوحدة المعالجة المركزية هو وضع وحدتي CPU في وحدة معالجة مركزية واحدة، على الرغم من أن كلتا الوحدتين تعملان بشكل أبطأ من وحدة معالجة مركزية واحدة. على سبيل المثال، يمكن لوحدتين من وحدات المعالجة المركزية (تسميهما الشركات المصنعة النوى) تعملان بسرعة 200 ميجاهرتز معًا إجراء عمليات حسابية في الثانية (أي بشكل حدسي) أكثر من وحدة المعالجة المركزية أحادية النواة التي تعمل بسرعة 300 ميجاهرتز. انظر إلى 2×200 >
لقد أصبحت القصة التي تبدو وكأنها حلم "وحدة معالجة مركزية واحدة ومتعددة النوى" حقيقة واقعة، مما يعني أنه يجب على المبرمجين الآن تعلم أساليب البرمجة المتوازية للاستفادة من هاتين النواتين. إذا كانت وحدة المعالجة المركزية قادرة على تنفيذ برنامجين في وقت واحد، فيجب على المبرمج كتابة كلا البرنامجين. ولكن هل يترجم هذا إلى ضعف سرعة البرنامج؟ إذا لم يكن الأمر كذلك، فهناك خطأ ما في فكرتنا 2×200 > ماذا يحدث إذا لم يحصل أحد النواة على ما يكفي من العمل؟ وهذا يعني أن نواة واحدة فقط مشغولة حقًا بينما لا تفعل النواة الأخرى شيئًا؟ في هذه الحالة، من الأفضل استخدام نواة واحدة بسرعة 300 ميجاهرتز. ظهرت العديد من المشكلات المماثلة إلى الواجهة مع إدخال النوى المتعددة، ولا يمكن تحقيق الاستخدام الفعال لهذه النوى إلا من خلال البرمجة.

p>

في الصورة أدناه نتخيل بوب وأليس كباحثين عن الذهب، ويتطلب تعدين الذهب أربع خطوات:

1. توجه إلى المنجم

2. التعدين

تحميل الخام

3. التخزين والتلميع

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

هذا أيضًا هو جوهر المشاركة الأساسية للجهاز الظاهري المتوازي لـ Solana.

المشاركة الأساسية

عنصر التصميم النهائي لـ Solana هو < strong>"خط الأنابيب". يحدث خط الأنابيب عندما يلزم معالجة البيانات من خلال سلسلة من الخطوات وتكون الأجهزة المختلفة مسؤولة عن كل خطوة. الفكرة الأساسية هنا هي أخذ البيانات التي يجب تشغيلها بشكل تسلسلي وموازتها باستخدام خط الأنابيب. يمكن تشغيل خطوط الأنابيب هذه بالتوازي، ويمكن لكل مرحلة من مراحل الأنابيب معالجة مجموعة مختلفة من المعاملات. كلما زادت سرعة معالجة الأجهزة (سعة حمولة شاحنة التعدين)، زاد التوازي طوال الوقت. اليوم، تركت متطلبات عقدة أجهزة Solana لمشغلي العقد خيارًا واحدًا فقط - مراكز البيانات، التي توفر الكفاءة ولكنها تهزم غرض blockchain.

لا يتم تقسيم تبعيات البيانات (مشاركة موارد الذاكرة)

بعد ترقية مركبة التعدين في المستقبل، نظرًا لعدم قدرة الطاقة الإنتاجية للتعدين على المواكبة، لم تكن مركبات التعدين في كثير من الأحيان محملة بالكامل. لذلك قام بوب بشراء آلة تعدين بسعر مرتفع لتحسين كفاءة التعدين (ترقية وحدة التنفيذ). في نفس الـ 15 دقيقة، يمكن إنتاج 10 معادن، ولكن نظرًا لأن عمل طحن الخام لا يزال يتم يدويًا كما كان من قبل، لا يمكن تحويل المزيد من الخامات المنتجة لكل وحدة زمنية إلى المزيد من الذهب، ويتم ضغط المزيد من الخامات في المستودع يوضح ما يحدث عند الوصول إلى الذاكرة وهو العامل الذي يحد من سرعة تنفيذ برنامجنا. لم يعد يهم مدى سرعة معالجة البيانات (أي سرعة التشغيل الأساسية). سنقتصر على سرعة الحصول على البيانات.
سوف تزعجنا سرعات الإدخال/الإخراج الأبطأ بشكل خطير، لأن الإدخال/الإخراج هو أبطأ جزء في الكمبيوتر، وستصبح القراءة غير المتزامنة للبيانات (الإدخال/الإخراج غير المتزامن) أمرًا بالغ الأهمية.
حتى لو كان لدى بوب آلة تعدين يمكنها استخراج 10 معادن في 15 دقيقة، إذا كان هناك تنافس على الوصول إلى الذاكرة، فسيظل يقتصر على معدنين كل 15 دقيقة. تنقسم حلول blockchain الموازية الحالية لهذه المشكلة إلى معسكرين – التنفيذ المتشائم والتنفيذ المتفائل.
يتطلب الأول ضرورة تحديد تبعيات حالة البيانات بوضوح قبل كتابة البيانات وقراءتها، الأمر الذي يتطلب من المطورين وضع افتراضات تبعية التحكم المسبق في مجال برمجة العقود الذكية، غالبًا ما تنحرف هذه الافتراضات عن الواقع. . ولا يقدم الأخير أي افتراضات أو قيود على كتابة البيانات، ويتراجع في حالة حدوث تعارض.
لنأخذ خطة التنفيذ المتفائلة لـ Monad كمثال: الحقيقة هي أن معظم عبء العمل هو تنفيذ المعاملات، وليس هناك العديد من السيناريوهات الموازية كما يتصور. يوضح الشكل أدناه أنواع مصادر استهلاك رسوم الغاز للإيثريوم في يوم واحد، وستجد أنه على الرغم من أن هذا التوزيع ليس مرتفعًا مثل العقود الذكية الشائعة، إلا أنه في الواقع، لا يتم توزيع الأنواع المختلفة من أنواع المعاملات بالتساوي. يعد المنطق الموازي مع التنفيذ المتفائل ممكنًا في عصر Web2، نظرًا لأن جزءًا كبيرًا من طلبات تطبيقات Web2 عبارة عن عمليات وصول وليست تعديلات مثل Taobao وDouyin، فليس لديك في الواقع العديد من الفرص لتعديل حالة هذه التطبيقات. ولكن في مجال Web3، فإن معظم طلبات العقود الذكية تهدف فقط إلى تعديل الحالة - تحديث دفتر الأستاذ، سيؤدي ذلك في الواقع إلى المزيد من التراجعات غير المتوقعة، مما يجعل السلسلة غير متاحة.

p>

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

p>

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

التوازي غير المتزامن

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

p>

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

التعبير الدلالي للغات البرمجة المتوازية

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

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

يقوم نموذج البرمجة الموزعة هذا الذي اقترحته PREDA بتقسيم دقيق لحالة العقد من خلال نطاق العقد البرمجي، ويستخدم دلالات الترحيل الوظيفي (التتابع الوظيفي) لتحليل تنفيذ المعاملة التدفق وتوزيعه للتنفيذ على محركات تنفيذ متوازية متعددة.

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

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

الاستنتاج

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

p>

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