التوازن بين القابلية للتوسع والأمان واللامركزية: خيارات Polkadot التكنولوجية

في زمن تسعى فيه تقنية البلوكتشين لتحقيق كفاءة أعلى، بدأت تظهر مسألة رئيسية: هل من الضروري التضحية بالأمان ومرونة النظام أثناء تحسين الأداء؟

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

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

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

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

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

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

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

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

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

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

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

هل Sequencer موثوق به؟

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

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

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

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

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

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

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

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

الأمان

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

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

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

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

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

تعقيد

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

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

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

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

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

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

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

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

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

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

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

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

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

سولانا

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

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

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

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

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

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

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

طن

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

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

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

أفالانش

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

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

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

إيثيريوم

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

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

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

زك رولاب

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

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

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

الخاتمة

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

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

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