اختيار قابلية التوسع في البلوكتشين: الطريق الابتكاري لـ Polkadot

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

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

التحديات التي تواجه تصميم توسيع البلوكتشين Polkadot

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

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

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

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

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

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

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

مشكلة الثقة في Sequencer

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

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

Polkadot: حل غير قابل للتسوية

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

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

قبل كتابة بيانات البلوكتشين في طبقة توفر البيانات الخاصة بـ Polkadot (DA)، ستقوم مجموعة مكونة من حوالي 5 مُحقِّقين بالتحقق من شرعيتها. يستقبلون إيصالات المرشحين المقدمة من المُرتب (candidate receipt) وإثباتات الصلاحية (PoV)، والتي تحتوي على كتلة rollup وإثبات التخزين المقابل. سيتم معالجة هذه المعلومات بواسطة دالة التحقق من السلاسل المتوازية، وسيقوم المُحقِّقون على سلسلة النقل بإعادة تنفيذها.

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

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

الأمان

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

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

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

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

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

تعقيد

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

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

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

• استراتيجية بسيطة: استخدم دائمًا عدد ثابت من core، أو قم بتعديله يدويًا خارج السلسلة؛
• استراتيجية خفيفة: مراقبة حمل معاملات محددة في mempool العقدة;
• استراتيجيات مؤتمتة: من خلال البيانات التاريخية وواجهة XCM لاستدعاء خدمات coretime مسبقًا لتكوين الموارد.

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

التفاعل

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

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

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

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

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

سولانا

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

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

• كل إبوك ( يستمر حوالي يومين أو 432,000 فتحة ) تبدأ بتوزيع الفتحات بناءً على كمية الرهانات؛
• كلما زادت نسبة الرهن، زادت نسبة التوزيع. على سبيل المثال، سيحصل المدقق الذي يرهن 1% على حوالي 1% من فرصة إنشاء الكتل؛
• تم الإعلان عن جميع مُصدري الكتل مسبقًا، مما زاد من خطر تعرض الشبكة لهجمات DDoS موجهة، وتكرار الانقطاع.

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

سولانا sacrificed اللامركزية ومقاومة الهجمات في سعيها لتحقيق TPS، حيث أن معامل ناكاموتو الخاص بها هو 20 فقط، وهو أقل بكثير من 172 الخاص بـ Polkadot.

طن

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

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

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

أفالانش

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

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

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

) إيثريوم

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

التجميع المتفائل

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

ZK Rollup

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

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

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

الخاتمة

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

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

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