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

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

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

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

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

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

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

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

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

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

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

هل Sequencer موثوق؟

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

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

Polkadot: حل غير مقبول

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

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

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

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

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

الأمان

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

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

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

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

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

تعقيد

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

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

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

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

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

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

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

التفاعل بين الأنظمة

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

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

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

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

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

سولانا

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

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

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

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

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

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

تخلت سولانا عن اللامركزية والقدرة على مقاومة الهجمات في سعيها لتحقيق 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 النظري لكل شبكة فرعية إلى حوالي 5000، مشابهة لفكرة Polkadot: تقليل الحمل على shard واحد لتحقيق التوسع. لكن Avalanche يسمح للمتحققين باختيار المشاركة في الشبكة الفرعية بحرية، ويمكن أن تتضمن الشبكة الفرعية متطلبات إضافية مثل الجغرافيا وKYC، مما يضحي باللامركزية والأمان.

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

إيثيريوم

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

الطبقة المتفائلة

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

(# زك رول أب

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

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

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

الخاتمة

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

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

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