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

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

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

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

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

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

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

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

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

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

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

) هل Sequencer موثوق؟

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

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

Polkadot: حل غير متنازل

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

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

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

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

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

) الأمان

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

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

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

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

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

التعقيد

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

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

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

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

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

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

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

قابلية التشغيل المتداخل

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

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

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

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

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

) سولانا

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

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

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

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

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

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

تضحي سولانا باللامركزية وقدرة مقاومة الهجمات في سعيها لتحقيق 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، تشترك جميع الـrollups في ضمان أمان موحد؛ بينما لا تحتوي الشبكات الفرعية في Avalanche على ضمان أمان افتراضي، وبعضها يمكن أن يكون مركزيًا بالكامل. إذا كنت ترغب في تعزيز الأمان، فلا بد من التنازل عن الأداء، ومن الصعب تقديم التزام بالأمان المؤكد.

( إيثريوم

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

)# التراكب المتفائل

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

ZK Rollup

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

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

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

الخاتمة

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

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

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