موازنة القابلية للتوسع: اختيار بولكادوت وويب 3

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

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

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

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

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

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

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

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

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

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

هل Sequencer موثوق؟

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

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

بولكادوت: حل غير متنازل

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

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

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

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

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

الأمان

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

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

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

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

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

التعقيد

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

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

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

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

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

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

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

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

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

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

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

ما هي التنازلات التي قدمتها بروتوكولات أخرى؟

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

سولانا

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

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

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

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

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

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

سولانا sacrificed decentralization and resistance to attacks in pursuit of TPS، حيث أن معامل ناكاموتو الخاص بها يبلغ 20 فقط، وهو أقل بكثير من 172 الخاص بـ Polkadot.

تون

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

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

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

أفالانش

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

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

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

إيثيريوم

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

التحسين المتفائل

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

زك رول أب

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

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

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

الخاتمة

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

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

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