توازن قابلية التوسع في Web3: الحل من Polkadot

في عصر تسعى فيه blockchain لتحقيق كفاءة أعلى، تبرز مسألة رئيسية تدريجياً: كيف يمكن التوازن بين الأداء القابل للتوسع والأمان ومرونة النظام؟

هذا ليس مجرد تحدٍ على المستوى التقني، بل هو اختيار عميق في تصميم الهيكل. بالنسبة لبيئة Web3، فإن نظامًا أسرع إذا تم بناؤه على حساب الثقة والأمان، غالبًا ما يكون من الصعب دعم الابتكار المستدام الحقيقي.

تعتبر Polkadot من الداعمين الرئيسيين لقابلية التوسع في Web3، فهل نموذج rollup الخاص بها قد قدم تنازلات في اللامركزية أو الأمان أو التداخل الشبكي؟ سيتناول هذا المقال التضحيات والتوازنات التي قامت بها Polkadot في تصميم قابلية التوسع، ويقارنها مع حلول سلاسل الكتل الرئيسية الأخرى، مستكشفًا الاختيارات المختلفة فيما يتعلق بالأداء والأمان واللامركزية.

التحديات التي تواجه تصميم التوسع في Polkadot

توازن المرونة واللامركزية

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

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

موازنة التوسع العمودي

يمكن أن تحقق Rollup التوسع الرأسي من خلال الاستفادة من بنية Polkadot متعددة النوى. تم تقديم هذه القدرة الجديدة من خلال ميزة "التوسع المرن". خلال عملية التصميم، اكتشفنا أنه نظرًا لأن التحقق من كتلة rollup لا يتم تنفيذه على نواة معينة، فقد يؤثر ذلك على مرونتها.

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

الهدف من Polkadot هو الحفاظ على مرونة rollup والاستخدام الفعال لموارد سلسلة الترحيل دون التأثير على الخصائص الأساسية للنظام.

هل يمكن الوثوق بـ Sequencer؟

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

ومع ذلك، في فلسفة تصميم Polkadot، لا يمكننا إجراء أي افتراضات ثقة حول sequencer، لأنه يجب الحفاظ على خصائص النظام "بدون ثقة" و "بدون إذن". يجب أن يكون بإمكان أي شخص استخدام بروتوكول collator لتقديم طلبات تحويل حالة rollup.

Polkadot: حل لا يتسامح

الخيار النهائي لبولكادوت هو: ترك المشكلة بالكامل لحل دالة تحويل حالة rollup (Runtime). Runtime هو المصدر الوحيد الموثوق به لجميع معلومات الإجماع، لذا يجب أن يتم التصريح بوضوح في المخرجات عن أي نواة بولكادوت يجب أن يتم فيها تنفيذ التحقق.

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

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

تتضمن نتيجة التحقق محدد core، الذي يُستخدم لتحديد أي core يجب التحقق من الكتلة عليه. سيقوم المدقق بمقارنة هذا الفهرس مع core الذي يتحمل مسؤوليته؛ إذا لم يكن متطابقًا، فسيتم التخلص من هذه الكتلة.

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

الأمان

في سعيها لتحقيق القابلية للتوسع، لم تتنازل Polkadot عن الأمان. يتم تأمين rollup بواسطة سلسلة الترحيل، ويتطلب الأمر فقط مُرتب صادق للحفاظ على البقاء.

بفضل بروتوكول ELVES ، تقوم Polkadot بتوسيع أمانها بالكامل إلى جميع rollup ، وتحقق من جميع الحسابات على core ، دون الحاجة إلى فرض أي قيود أو افتراضات حول عدد النوى المستخدمة.

لذلك، يمكن أن تحقق rollup الخاص بـ Polkadot توسعًا حقيقيًا دون التضحية بالأمان.

قابلية الاستخدام

لن يحد التوسع المرن من قابلية برمجة rollup. يدعم نموذج rollup في Polkadot تنفيذ حسابات كاملة تورين في بيئة WebAssembly، طالما أن التنفيذ الفردي يتم في غضون 2 ثانية. بفضل التوسع المرن، يمكن زيادة إجمالي كمية الحسابات التي يمكن تنفيذها في كل دورة مدتها 6 ثوانٍ، ولكن نوع الحسابات لا يتأثر.

تعقيد

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

يمكن لـ Rollup ضبط الموارد ديناميكيًا من خلال واجهة Agile Coretime للحفاظ على مستوى أمان متسق. كما يجب أن تحقق متطلبات RFC103 جزئيًا لتناسب سيناريوهات الاستخدام المختلفة.

تعتمد التعقيدات المحددة على استراتيجيات إدارة الموارد الخاصة بـ rollup ، والتي قد تعتمد على متغيرات على السلسلة أو خارج السلسلة. على سبيل المثال:

• استراتيجية بسيطة: استخدم دائمًا عددًا ثابتًا من core، أو قم بالتعديل يدويًا خارج السلسلة؛

• استراتيجية خفيفة: مراقبة الحمولة التجارية المحددة في ميمبولو العقد؛

• استراتيجيات الأتمتة: من خلال البيانات التاريخية وواجهة XCM لاستدعاء خدمات coretime مسبقًا لتكوين الموارد.

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

التشغيل المتداخل

تدعم Polkadot التشغيل البيني بين مختلف rollups، بينما لا تؤثر المرونة في التوسع على سعة نقل الرسائل.

تتم عملية التواصل بين الرسائل عبر rollup من خلال طبقة النقل الأساسية، حيث تكون مساحة كتلة التواصل لكل rollup ثابتة، ولا تتعلق بعدد النوى المخصصة لها.

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

ما هي التسويات التي قامت بها البروتوكولات الأخرى؟

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

سلسلة الكتل A

لا تعتمد سلسلة الكتل العامة A على هيكل تقسيم Polkadot أو Ethereum، بل تستخدم هيكلية أحادية ذات قدرة عالية على المعالجة لتحقيق قابلية التوسع، معتمدة على إثبات التاريخ، المعالجة المتوازية لوحدة المعالجة المركزية، وآلية توافق القيادات، حيث يمكن أن تصل TPS النظرية إلى 65,000.

تصميم رئيسي هو آلية جدولة القادة التي تم الكشف عنها مسبقًا ويمكن التحقق منها:

• في بداية كل فترة (حوالي يومين أو 432,000 فتحة)، يتم تخصيص الفتحات بناءً على كمية الرهان؛

• كلما زادت نسبة الرهن، زادت نسبة التوزيع. على سبيل المثال، سيحصل المدقق الذي يراهن بنسبة 1% على حوالي 1% من فرص الكتلة؛

• تم الإعلان عن جميع معدني الكتل مسبقًا، مما زاد من خطر تعرض الشبكة لهجمات DDoS موجهة وتعطل متكرر.

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

تضحي شبكة بلوكشين A من أجل تحقيق TPS بقدر كبير من اللامركزية وقدرتها على مقاومة الهجمات، حيث أن معامل ناكاموتو الخاص بها لا يتجاوز 20، وهو أقل بكثير من 172 الخاص بـ Polkadot.

سلسلة بلوكشين معينة B

يدعي أحد سلاسل الكتل العامة B أن معدل المعاملات في الثانية يمكن أن يصل إلى 104,715، ولكن هذا الرقم تم تحقيقه في شبكة اختبار خاصة، مع 256 عقدة، وفي ظروف مثالية من الشبكة والأجهزة. بينما وصلت Polkadot إلى 128K TPS على شبكة عامة لامركزية.

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

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

سلسلة عامة معينة C

تستخدم سلسلة الكتل العامة C هيكل شبكة رئيسية + شبكة فرعية للتوسع، تتكون الشبكة الرئيسية من X-Chain (التحويلات، ~4,500 TPS)، C-Chain (العقود الذكية، ~100--200 TPS)، P-Chain (إدارة المدققين والشبكات الفرعية).

يمكن أن تصل TPS النظرية لكل شبكة فرعية إلى حوالي 5000، مشابهة لفكرة Polkadot: تقليل الحمل على الشارد الواحد لتحقيق التوسع. لكن إحدى سلاسل الكتل العامة C تسمح للمتحققين باختيار المشاركة في الشبكة الفرعية بحرية، ويمكن أن تحدد الشبكة الفرعية متطلبات إضافية مثل الجغرافيا وKYC، مما يضحي باللامركزية والأمان.

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

إيثيريوم

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

التكديس المتفائل

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

زك رولاب

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

بالمقارنة، فإن تكلفة ZK rollup القابلة للتعميم تبلغ حوالي 2x10^6 مرة تكلفة بروتوكول الأمان الاقتصادي المشفر الأساسي لـ Polkadot.

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

الخاتمة

نهاية القابلية للتوسع لا ينبغي أن تكون تسوية.

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

في سعيها لتحقيق تطبيقات أكبر حجمًا في الوقت الحاضر، قد تكون "قابلية التوسع بدون ثقة" التي تتمسك بها Polkadot هي الحل الحقيقي الذي يمكن أن يدعم التطور طويل الأمد لـ Web3.