تضحي سلسلة الكتل بكفاءتها بسبب تصميمها اللامركزي، لذلك فإن تسريع سرعة التنفيذ يعد واحدًا من التحديات الملحة. تعتبر 'طبقة التنفيذ' في سلسلة الكتل الجزء الحاسم في معالجة كل معاملة وإضافتها إلى السلسلة. من أجل تسريع القدرة على المعالجة، يصبح تحسين طبقة التنفيذ استراتيجية رئيسية، حيث يعد التنفيذ المتوازي أحد أهم الاختراقات في هذا الجانب.
تستخدم سلاسل الكتل التقليدية عادة أسلوب المعالجة التسلسلي، مما يحد من سرعة المعاملات، خاصة في الشبكات ذات الكثافة العالية من المعاملات، مما يؤدي إلى الازدحام. ومع ذلك، من خلال التنفيذ المتوازي، يمكن معالجة عدة معاملات في نفس الوقت، مما يزيد بشكل كبير من كفاءة التنفيذ ويخفف الضغط على السلسلة.
لفهم ما هو التوازي بشكل أفضل، سنبدأ بشرح التنفيذ، مع استخدام نموذج PBS بعد الدمج في الإيثريوم كمثال، لشرح ما هو التنفيذ، مع عرض الموقع الذي يحتله التنفيذ في دورة حياة المعاملة بأكملها.
الخطوات المحددة لتنفيذ المعاملات
تدخل المعاملة إلى تجمع الذاكرة وتتم تصفيتها وترتيبها: هذه هي المرحلة المسبقة لمعالجة المعاملة بعد تقديمها، وتشمل تفاعل تجمع الذاكرة والباحث والباني، لإكمال تصفية وترتيب المعاملات.
يبني الباني الكتلة (لكن لا ينفذها): يقوم الباني بترتيب المعاملات المربحة في كتلة، لإكمال عملية التعبئة والترتيب للمعاملات.
يقوم المقترح بالتحقق من الكتلة وتقديمها: بعد اكتمال بناء الكتلة، يرسل الباني اقتراح الكتلة إلى المقترح. يتحقق المقترح من هيكل الكتلة ومحتوى المعاملات، ثم يقدم الكتلة رسميًا إلى الشبكة لبدء التنفيذ.
تنفيذ المعاملة: بعد تقديم الكتلة، يقوم العقد بتنفيذ المعاملات داخل الكتلة واحدة تلو الأخرى. هذه هي المرحلة الحيوية لتحديث الحالة، حيث تؤدي كل معاملة إلى استدعاء عقد ذكي أو تغيير في رصيد الحساب أو تغيير في الحالة.
شهادة الشهود: يقوم المدققون بشهادة نتائج تنفيذ الكتلة وجذر الحالة، ويعتبرونها تأكيدًا نهائيًا. هذا يضمن صحة وفاعلية الكتلة على مستوى التنفيذ، ويمنع التناقض.
مزامنة الحالة: يقوم كل عقد بمزامنة نتائج تنفيذ الكتلة (مثل رصيد الحساب، تحديث حالة العقد، إلخ) إلى حالته المحلية، بعد تنفيذ كل معاملة، يقوم العقد بحساب وتخزين جذر حالة جديدة، ليكون كحالة أولية في الكتلة التالية.
بالطبع، هذه هي مزامنة الحالة للمعاملات على أساس الكتل، للحفاظ على أحدث حالة على السلسلة، عادةً، يقوم العقد بمزامنة البيانات كتلة واحدة تلو الأخرى، والتحقق المستمر من الكتل والحالة. ولكن للوصول إلى النهاية في آلية POS، يحتاج المجمع إلى تجميع توقيعات الشهود من كل Slot في توقيع كامل، ثم تمريره إلى مقترح Slot التالي، ويحتاج المدققون إلى تأكيد حالة جميع الكتل في ذلك Epoch بناءً على عدد الأصوات بعد مرور Epoch واحدة، مما يشكل نقطة تفتيش مؤقتة لحالة الإجماع. بعد أن يحصل عدد كبير من المدققين على دعم الشهود خلال Epochين متتالين، فقط بعد ذلك ستصل الكتل والمعاملات إلى النهاية.
من منظور دورة حياة المعاملة بأكملها، يحدث التنفيذ بعد أن يتحقق المقترح من هيكل الكتلة ومحتوى المعاملات المرسلة من الباني. تتطلب عملية التنفيذ الفعلية معالجة كل معاملة واحدة تلو الأخرى، وتحديث الحالة الخاصة بالحساب أو العقد ذات الصلة. بعد الانتهاء من تنفيذ جميع المعاملات، يقوم المقترح بحساب جذر حالة جديدة (جذر ميركل)، وهو ملخص لنتائج تنفيذ جميع المعاملات في الكتلة الحالية والحالة العالمية النهائية. باختصار، تشمل عملية تنفيذ الكتلة الكاملة سلسلة من الحسابات اللازمة لتحويل الإيثريوم من حالة سابقة إلى حالة لاحقة، بدءًا من تنفيذ كل معاملة إلى حساب جذر ميركل.
التنفيذ التسلسلي
على النقيض من التوازي، فإن التنفيذ التسلسلي هو الطريقة الأكثر شيوعًا في سلسلة الكتل. عادةً، يتم تنفيذ المعاملات خطوة بخطوة حسب الترتيب. عند الانتهاء من تنفيذ معاملة، يقوم الإيثريوم بتحديث حالة الحساب والمعلومات ذات الصلة (مثل الرصيد وبيانات تخزين العقد) في شجرة حالة الحساب، ويتم إنشاء هاش حالة حساب جديدة. بعد تحديث جميع أشجار حالة الحساب، يتم إنشاء هاش جذر ميركل للحالة المعروفة. بعد الانتهاء من جذر ميركل للحالة وجذر ميركل للمعاملات وجذر ميركل للإيصالات، يتم حساب هاش رأس الكتلة، مما يولد هاش الكتلة.
وفي هذا السياق، فإن ترتيب تنفيذ المعاملات يعد أمرًا بالغ الأهمية. نظرًا لأن شجرة ميركل هي شجرة ثنائية من قيم الهاش، فإن القيم الناتجة عن جذر ميركل الناتجة عن الترتيبات المختلفة ستكون مختلفة.
التنفيذ المتوازي
في بيئة التنفيذ المتوازي، سيحاول العقد معالجة المعاملات في الكتلة بشكل متوازي. لا يتم تنفيذ المعاملات واحدة تلو الأخرى بالتسلسل، بل يتم توزيع المعاملات على مسارات تنفيذ مختلفة، مما يسمح لها بالتنفيذ في نفس الوقت. من خلال التنفيذ المتوازي، يمكن للنظام معالجة المعاملات في الكتلة بشكل أكثر كفاءة، مما يزيد من الإنتاجية.
بعد الانتهاء من تنفيذ جميع المعاملات، يقوم العقد بتجميع نتائج التنفيذ (أي تحديث الحالة الناتجة عن تأثير المعاملات)، لتشكيل حالة جديدة للكتلة. ستتم إضافة هذه الحالة إلى سلسلة الكتل، مما يمثل أحدث حالة عالمية على السلسلة.
تعارض الحالة
نظرًا لأن التوازي يعالج المعاملات على مسارات مختلفة في نفس الوقت، فإن أحد التحديات الكبيرة للتوازي هو تعارض الحالة. أي أنه قد توجد معاملات متعددة تحاول قراءة أو كتابة على نفس الجزء من البيانات (الحالة) على سلسلة الكتل في نفس الوقت. إذا لم تتم معالجة هذه الحالة بشكل صحيح، فقد يؤدي ذلك إلى نتائج تنفيذ غير مؤكدة. نظرًا لاختلاف ترتيب تحديث الحالة، ستختلف النتائج الحسابية النهائية أيضًا. على سبيل المثال،
افترض أن هناك معاملتين، المعاملة A والمعاملة B، كلاهما يحاول تحديث رصيد نفس الحساب:
المعاملة A: زيادة رصيد الحساب بمقدار 10.
المعاملة B: زيادة رصيد الحساب بمقدار 20.
الرصيد الابتدائي للحساب هو 100.
إذا قمنا بتنفيذها بشكل متسلسل، فإن نتيجة ترتيب التنفيذ ستكون محددة:
1. تنفيذ المعاملة A أولاً، ثم تنفيذ المعاملة B:
زاد رصيد الحساب أولاً بمقدار 10، ليصبح 110.
قم بزيادة 20، ليصبح المجموع النهائي 130.
2. تنفيذ المعاملة B أولاً، ثم تنفيذ المعاملة A:
زاد رصيد الحساب أولاً بمقدار 20، ليصبح 120.
ثم زاد بمقدار 10، ليصبح المجموع النهائي 130.
في كلا الترتيبين، يكون الرصيد النهائي 130، لأن النظام يضمن تناسق ترتيب تنفيذ المعاملات.
لكن في بيئة التنفيذ المتوازية، قد تقرأ المعاملة A والمعاملة B الرصيد الأولي 100 في نفس الوقت وتقوم بحساباتها الخاصة:
قرأت المعاملة A الرصيد كـ 100، وبعد الحساب تم تحديث الرصيد إلى 110.
قرأت المعاملة B أيضًا الرصيد كـ 100، وبعد الحساب تم تحديث الرصيد إلى 120.
في هذه الحالة، نظرًا لأن المعاملات تنفذ في نفس الوقت، يؤدي ذلك إلى تحديث الرصيد النهائي ليكون 120 فقط، وليس 130، لأن العمليات من المعاملة A والمعاملة B 'غطت' نتائج بعضها البعض، مما أدى إلى تعارض الحالة.
غالبًا ما تُعرف هذه الأنواع من مشاكل تعارض الحالة باسم 'تغطية البيانات'، أي عندما تحاول المعاملة تعديل نفس البيانات في نفس الوقت، قد تتداخل حسابات بعضها البعض، مما يؤدي إلى حالة نهائية غير صحيحة. وهناك نوع آخر من تعارض الحالة قد يؤدي إلى مشكلة عدم إمكانية ضمان ترتيب التنفيذ. نظرًا لأن عدة معاملات تكمل العمليات في فترات زمنية مختلفة، سيؤدي ذلك إلى ترتيب تنفيذ مختلف. قد يؤدي الترتيب المختلف إلى نتائج حسابية مختلفة، مما يجعل النتائج غير مؤكدة.
لتجنب هذه الحالة غير المؤكدة، عادة ما تقدم أنظمة التنفيذ المتوازية على سلسلة الكتل بعض آليات كشف التعارض وآلية التراجع، أو تقوم مسبقًا بتحليل اعتماد المعاملات، لضمان تنفيذها بالتوازي دون التأثير على تناسق الحالة النهائية.
التوازي المتفائل مقابل التوازي الحتمي
هناك طريقتان للتعامل مع مشاكل تعارض الحالة المحتملة: التوازي الحتمي والتوازي المتفائل. لكل من هذين النموذجين توازن خاص في الكفاءة وتعقيد التصميم.
يتطلب التوازي الحتمي إعلان الوصول إلى الحالة مسبقًا، حيث يحتاج المدقق أو المسلسل إلى فحص الوصول المعلن إلى الحالة عند ترتيب المعاملات. إذا كانت هناك معاملتين تحاولان الكتابة إلى نفس الحالة، يتم وضع علامة على تلك المعاملات على أنها متعارضة، مما يمنع التنفيذ المتوازي. تختلف طرق التنفيذ المسبق لإعلان الوصول إلى الحالة بين سلاسل الكتل المختلفة، ولكنها عمومًا تشمل الطرق التالية:
من خلال فرض قيود على تنظيم العقود: يحدد المطورون نطاق الوصول إلى الحالة مباشرة في العقود الذكية. على سبيل المثال، يتطلب نقل رموز ERC-20 الوصول إلى حقول رصيد المرسل والمستقبل.
من خلال هيكلة بيانات المعاملات: إضافة حقول مخصصة في المعاملة لتحديد الوصول إلى الحالة.
من خلال تحليل المترجم: يمكن لمترجم اللغات العالية التحليل الثابت لشيفرة العقد، وإنشاء مجموعة الوصول إلى الحالة بشكل تلقائي.
من خلال فرض التصريحات من خلال الإطار: تتطلب بعض الإطارات من المطورين تحديد الحالة التي يحتاجون إلى الوصول إليها بوضوح عند استدعاء الوظيفة.
يتم التعامل مع التنفيذ المتوازي بشكل متفائل، حيث تتم معالجة المعاملات أولاً بشكل متفائل، وعند حدوث التعارض، يتم إعادة تنفيذ المعاملات المتأثرة بالترتيب. لتجنب حدوث حالات التعارض قدر الإمكان، يكمن الجوهر في تصميم التنفيذ المتوازي المتفائل في إجراء تقديرات سريعة للحالة عبر البيانات التاريخية والتحليل الثابت. أي أن النظام، دون التحقق الكامل، يفترض أن بعض العمليات أو تحديثات الحالة صحيحة، ويعمل على تجنب انتظار جميع عمليات التحقق، وبالتالي تحسين الأداء والإنتاجية.
على الرغم من أن التنفيذ المتوازي المتفائل يمكن أن يتجنب التعارضات بقدر الإمكان من خلال بعض التقديرات السريعة للحالة، إلا أنه لا يزال هناك تحديات لا مفر منها، خاصة عندما يتعلق الأمر بتنفيذ العقود أو المعاملات عبر السلاسل، إذا تكررت التعارضات بشكل متكرر، فإن إعادة التنفيذ قد تؤدي إلى إبطاء أداء النظام بشكل ملحوظ، وزيادة استهلاك الموارد الحاسوبية.
يتطلب التوازي الحتمي إجراء فحص للاعتماد على الحالة قبل المعاملة لتجنب حالات التعارض التي قد تظهر في التوازي المتفائل، ولكن نظرًا لأنه يتطلب إعلان الاعتماد على الحالة بدقة قبل تقديم المعاملة، يتطلب ذلك من المطورين مستوى أعلى من التحدي، مما يزيد من تعقيد التنفيذ.
معضلة EVM المتوازية
لا يتوقف التعامل مع تعارضات الحالة على التحديد والتفاؤل فحسب، بل يجب أيضًا أخذ هيكل قاعدة بيانات السلسلة في الاعتبار. تعتبر مشاكل تعارض الحالة في EVM تحت هيكل شجرة ميركل تحديًا خاصًا. شجرة ميركل هي بنية هاش هرمية، وعند تعديل أي بيانات حالة، يجب تحديث قيمة الجذر لشجرة ميركل. هذه العملية التحديثية تتطلب حسابات متكررة، من أوراق الشجرة إلى الجذر. نظرًا لأن الهاش غير قابل للعكس، لا يمكن حساب المستوى الأعلى إلا بعد الانتهاء من تغييرات البيانات في المستوى الأدنى، مما يجعل من الصعب تحديثها بالتوازي.
إذا تم تنفيذ معاملتين بالتوازي والوصول إلى نفس الحالة (مثل رصيد الحساب)، فسوف يؤدي ذلك إلى تعارض في عقد شجرة ميركل. عادة ما يتطلب حل هذا التعارض آلية إدارة معاملات إضافية لضمان الحصول على قيمة جذر هايش متسقة عبر الفروع المتعددة. هذا ليس من السهل تحقيقه بالنسبة لـ EVM، لأنه يحتاج إلى الموازنة بين التوازي وتناسق الحالة.
حلول غير EVM المتوازية
سولانا
على عكس شجرة الحالة العالمية في الإيثريوم، تعتمد سولانا نموذج الحساب. كل حساب هو مساحة تخزين مستقلة، مخزنة في دفتر الحسابات، مما يجنبها مشاكل تعارض المسار.
سولانا هي توازي حتمي. في سولانا، يجب على كل معاملة أن تعلن بوضوح عن الحسابات التي ستصل إليها والأذونات المطلوبة عند التقديم (للقراءة فقط أو للقراءة والكتابة). يسمح هذا التصميم لعقد سلسلة الكتل بتحليل موارد الوصول لكل معاملة قبل تنفيذها. نظرًا لأن المعاملات قد أعلنت عن جميع علاقات الاعتماد على الحسابات قبل بدء التنفيذ، يمكن للعقد تحديد المعاملات التي ستصل إلى نفس الحساب، وما هي المعاملات التي يمكن تنفيذها بأمان بالتوازي، مما يحقق جدولة ذكية، ويتجنب التعارض، ويحقق أساس الجدولة المتوازية.
نظرًا لأن كل معاملة قد أعلنت مسبقًا عن الحسابات والأذونات التي تحتاج إلى الوصول إليها قبل التنفيذ، يمكن لسولانا التحقق مما إذا كانت هناك علاقات اعتماد بين الحسابات في المعاملات (نموذج Sealevel). إذا لم يكن هناك حسابات مشتركة للقراءة والكتابة بين المعاملات، يمكن للنظام تخصيصها على معالجات مختلفة لتنفيذها بالتوازي.
أبتوس
تختلف تصميمات التنفيذ المتوازي في Aptos كثيرًا عن الإيثريوم، حيث قدمت بعض الابتكارات الرئيسية في هيكلها وآلياتها، ويركز ذلك بشكل رئيسي على نموذج الحساب وتخزين الحالة.
يتطلب الإيثريوم تحديث شجرة الحالة العالمية (MPT) بشكل متكرر أثناء تنفيذ المعاملات. يتم تخزين حالة جميع الحسابات والعقود في شجرة حالة مشتركة، ويجب أن تصل كل معاملة إلى وتحديث جزء من هذه الشجرة. بينما يتم تقسيم الحسابات في أبتوس إلى وحدات حالة مستقلة، حيث يكون كل كائن زوج مفتاح وقيمة مستقل، يمكن أن توجد الكائنات بشكل مستقل، دون التأثير على بعضها البعض، ولن ترتبط إلا عندما تكون هناك علاقات مرجعية واضحة. لا توجد مسارات شجرية مشتركة بين الكائنات، مما يتجنب منافسة القفل، ويمكن أن يتم التنفيذ بالتوازي بالكامل.
البنية التحتية لبيانات Aptos هي شجرة ميركل جيلليفيش. يتم تخزين حالة كل كائن في النهاية في JMT، كمجموعة مفاتيح وقيم مستقلة. على عكس MPT في الإيثريوم، تتبنى شجرة ميركل جيلليفيش هيكل شجرة ثنائية كاملة، مما يبسط مسار التخزين ومسار الاستعلام للعقد، ويقلل بشكل كبير من وقت التحقق. بالإضافة إلى ذلك، فإن موقع كل حساب في الشجرة ثابت، وتخزن العقد بشكل مستقل، مما يسمح بتحديثات متعددة للحسابات والبحث بشكل متوازي.
أبتوس هو توازي متفائل، ولا يحتاج إلى تقديم جميع علاقات الاعتماد المعلنة مسبقًا. لهذا، تستخدم أبتوس Block-STM، الذي يستخدم ترتيب المعاملات المحدد مسبقًا لتقدير الاعتماد، مما يقلل من عدد الإلغاءات.
EVM المتوازي
بالمقارنة مع EVM غير المتوازية، تواجه EVM المتوازية تحديات تقنية أكبر في معالجة الاعتماد على الحالة، وكشف التعارض، وإدارة الغاز، وآليات التراجع. لفهم هذا بشكل أفضل، يمكننا الرجوع إلى كيفية معالجة بعض مشاريع EVM المتوازية (مثل Sui وMonad وCanto) لهذه المشكلات.
Sui
مثل Aptos، تستخدم Sui أيضًا نموذج الكائنات لمعالجة الحالة، حيث يعتبر كل كائن (مثل الحساب، حالة العقد الذكي) موردًا مستقلًا، يتم تمييز هذه الكائنات من خلال معرفات فريدة. عندما تتعلق المعاملة بكائنات مختلفة، يمكن معالجة هذه المعاملات بالتوازي، لأنها تتعامل مع حالات مختلفة دون أن تتسبب في تعارض مباشر.
على الرغم من أن Sui تستخدم نموذج الكائنات لإدارة الحالة، إلا أنه من أجل التوافق مع EVM، يقوم هيكل Sui بربط نموذج الكائنات ونموذج الحساب في EVM من خلال طبقة تكيف إضافية أو آلية تجريد.
في Sui، تستخدم جدولة المعاملات استراتيجية التوازي المتفائل، حيث تفترض عدم وجود تعارضات بين المعاملات. إذا حدث تعارض، يستخدم النظام آلية التراجع لاستعادة الحالة.
تستخدم Sui نموذج الكائنات وتقنية عزل الحالة، مما يساعد على تجنب مشاكل الاعتماد على الحالة بشكل فعال. كل كائن هو مورد مستقل، ويمكن تنفيذ معاملات مختلفة بالتوازي، مما يزيد من الإنتاجية والكفاءة. لكن هذه الطريقة تأتي مع تكلفة تعقيد نموذج الكائنات ونفقات آلية التراجع. إذا حدث تعارض بين المعاملات، يحتاج النظام إلى التراجع عن جزء من الحالة، مما يزيد من عبء النظام وقد يؤثر على كفاءة المعالجة المتوازية. مقارنة بالأنظمة غير EVM المتوازية (مثل Solana)، تحتاج Sui إلى المزيد من الموارد الحاسوبية والتخزينية للحفاظ على كفاءة المعالجة المتوازية.
Monad
مثل Sui، تستخدم Monad أيضًا التنفيذ المتوازي المتفائل. لكن التنفيذ المتوازي المتفائل لـ Monad يتطلب توقع بعض المعاملات ذات الاعتماد قبل التنفيذ الفعلي، ويتم ذلك بشكل رئيسي من خلال محلل الشيفرة الثابتة لـ Monad. يتطلب التوقع الوصول إلى الحالة، بينما تجعل طريقة تخزين الحالة في قاعدة بيانات الإيثريوم الوصول إلى الحالة أمرًا صعبًا للغاية، من أجل جعل القراءة المتوازية للحالة أكثر كفاءة، أعادت Monad أيضًا بناء قاعدة البيانات.
تشطر شجرة الحالة لـ Monad إلى أقسام، حيث يحتفظ كل قسم بشجرة حالة فرعية خاصة به. عند التحديث، تحتاج فقط إلى تعديل الشظايا ذات الصلة، دون الحاجة إلى إعادة بناء شجرة الحالة بأكملها. من خلال جدول فهرسة الحالة، يمكن تحديد موقع الحالة بسرعة داخل القسم، مما يقلل من التفاعل بين الأقسام.
ملخص
الجوهر في التوازي هو تحسين كفاءة التنفيذ من خلال تنفيذ متعدد المسارات، ومن أجل تحقيق التنفيذ متعدد المسارات، تحتاج السلسلة إلى إجراء سلسلة من الإجراءات مثل كشف التعارض وآلية التراجع لضمان تنفيذها بالتوازي دون التأثير على تناسق الحالة النهائية، وإجراء تحسينات معينة على قاعدة البيانات.
بالطبع، لا يقتصر تحسين كفاءة طبقة التنفيذ على التوازي فقط، بل يمكن أيضًا تحقيق تحسينات في مراحل التنفيذ من خلال تقليل عمليات القراءة والكتابة التي تحتاجها المعاملة الواحدة على قاعدة البيانات. ولكن نطاق تسريع سلسلة الكتل بالكامل أوسع، حيث يتضمن أيضًا تحسينات في كفاءة طبقة الإجماع.
كل تقنية لها قيودها الخاصة. يعد التوازي مجرد وسيلة واحدة لتعزيز الكفاءة، والقرار النهائي بشأن استخدام هذه التقنية يتطلب أيضًا النظر في ما إذا كانت مناسبة للمطورين، وما إذا كانت يمكن أن تكتمل دون التضحية باللامركزية، وما إلى ذلك. لا تعني تراكم التقنيات أنها أفضل، على الأقل بالنسبة للإيثريوم، لم يكن التوازي جذابًا جدًا، إذا نظرنا فقط من منظور تعزيز الكفاءة، فإن إضافة التوازي للإيثريوم ليست الحل الأمثل، سواء من حيث البساطة أو من حيث مخطط الإيثريوم الحالي الذي يركز على Rollup.