توازن قابلية توسيع البلوكتشين: اختيار Polkadot وWeb3
في الوقت الذي تسعى فيه البلوكتشين باستمرار لتحسين الكفاءة، تبرز مسألة رئيسية: كيف يمكن تحقيق أداء متزايد دون التضحية بالأمان ومرونة النظام؟
ليس هذا مجرد تحدٍ على المستوى التكنولوجي، بل هو خيار عميق في تصميم الهيكل. بالنسبة لنظام Web3، فإن السعي فقط نحو أنظمة أسرع مع تجاهل الثقة والأمان، يجعل من الصعب دعم الابتكار المستدام حقًا.
كجهة فاعلة مهمة في توسيع Web3، هل قامت Polkadot بتقديم بعض التضحيات في سعيها لتحقيق معدل عالٍ من المعالجة ووقت استجابة منخفض؟ هل نموذج rollup الخاص بها قد تخلّى عن اللامركزية أو الأمان أو التفاعل الشبكي؟
ستتناول هذه المقالة هذه القضايا، حيث ستقوم بتحليل عميق للموازنة في تصميم قابلية التوسع في Polkadot، ومقارنتها مع الحلول الأخرى في سلاسل الكتل الرئيسية، واستكشاف الاختلافات في الخيارات بين الأداء والأمان واللامركزية.
التحديات التي تواجه تصميم توسيع بولكادوت
التوازن بين المرونة واللامركزية
هل يعتمد هيكل بولكادوت على شبكة المدققين وسلسلة الإعادة، هل من الممكن أن يقدم ذلك مخاطر مركزية في بعض الجوانب؟ هل من الممكن أن يتشكل نقطة فشل واحدة أو سيطرة، مما يؤثر على خصائصه اللامركزية؟
يعتمد تشغيل Rollup على مُرتب سلسلة الوسيط المتصل، حيث تستخدم اتصالاتها آلية بروتوكول الـ collator. هذا البروتوكول لا يتطلب إذنًا أو ثقة على الإطلاق، يمكن لأي شخص لديه اتصال بالشبكة استخدامه، وتوصيل عدد قليل من عقد سلسلة الوسيط، وتقديم طلبات تحويل حالة الـ rollup. ستتم معالجة هذه الطلبات من خلال أحد نوى سلسلة الوسيط، بشرط واحد فقط: يجب أن تكون تحويلات الحالة صالحة، وإلا فلن يتم دفع حالة الـ rollup.
موازنة التوسع العمودي
يمكن أن تحقق Rollup التوسع العمودي من خلال الاستفادة من بنية Polkadot متعددة النوى. تم تقديم هذه القدرة الجديدة من خلال ميزة "التوسع المرن". خلال عملية التصميم، تم اكتشاف أنه نظرًا لأن التحقق من كتلة rollup لا يتم تنفيذه بشكل ثابت على نواة واحدة، فقد يؤثر ذلك على مرونته.
نظرًا لأن بروتوكول تقديم الكتل إلى سلسلة الوسيط هو غير مصرح به وغير موثوق، يمكن لأي شخص تقديم الكتل إلى أي نواة تم تخصيصها للـrollup للتحقق. قد يستغل المهاجمون ذلك، من خلال إعادة تقديم كتل شرعية تم التحقق منها مسبقًا إلى نوى مختلفة، مما يستهلك الموارد بشكل ضار، وبالتالي يقلل من إجمالي قدرة الـrollup وكفاءته.
يهدف Polkadot إلى الحفاظ على مرونة rollup والاستخدام الفعال لموارد سلسلة الترحيل دون التأثير على الخصائص الأساسية للنظام.
هل Sequencer موثوق؟
طريقة بسيطة للحل هي تعيين البروتوكول على أنه "مرخص": على سبيل المثال باستخدام آلية القائمة البيضاء، أو الثقة افتراضياً أن المنظمين لن يتصرفوا بشكل خبيث، مما يضمن نشاط rollup.
ومع ذلك، في مفهوم تصميم Polkadot، لا يمكننا إجراء أي افتراضات موثوقة حول sequencer، لأننا يجب أن نحافظ على خصائص النظام «غير موثوق» و«غير مصرح به». يجب أن يتمكن أي شخص من استخدام بروتوكول collator لتقديم طلبات تحويل حالة rollup.
بولكادوت: حل لا يتنازل
الخيار النهائي لPolkadot هو: ترك المشكلة بالكامل لوظيفة تحويل حالة rollup (Runtime) لحلها. Runtime هو المصدر الوحيد الموثوق لجميع معلومات الإجماع، لذلك يجب التصريح بوضوح في المخرجات عن المكان الذي يجب تنفيذ التحقق فيه على أي نواة من Nucleus.
يضمن هذا التصميم ازدواجية المرونة والأمان. ستقوم Polkadot بإعادة تنفيذ تحويل حالة rollup في عملية التوفر، وستضمن بروتوكول الاقتصاد المشفر ELVES صحة توزيع core.
قبل كتابة أي كتلة rollup إلى طبقة قابلية البيانات في Polkadot، ستقوم مجموعة مكونة من حوالي 5 مدققين أولاً بالتحقق من شرعيتها. يتلقون الإيصالات المرشحة وشهادات الصلاحية المقدمة من المُرتب، والتي تتضمن كتلة rollup وأدلة التخزين المقابلة. سيتم تمرير هذه المعلومات لمعالجة وظيفة التحقق في السلاسل المتوازية، ليقوم المدققون على سلسلة الإرسال بإعادة تنفيذها.
نتيجة التحقق تتضمن محدد core، يُستخدم لتحديد أي core يجب أن يتم التحقق من الكتلة عليه. سيقوم المُحقق بمقارنة هذا الفهرس مع core الذي يتحمل مسؤوليته؛ إذا لم يكن متطابقًا، ستُ discarded الكتلة.
تضمن هذه الآلية أن تظل النظام دائمًا بلا ثقة وبدون إذن، مما يمنع الجهات الخبيثة مثل المنظمين من التلاعب بمواقع التحقق، ويضمن أنه حتى عند استخدام rollup لعدة core، يمكن الحفاظ على المرونة.
الأمان
في سعيها لتحقيق التوسع، لم تتنازل Polkadot عن الأمان. يتم ضمان أمان الـ rollup بواسطة سلسلة الوسيط، حيث يكفي وجود مرتّب أمين للحفاظ على الاستمرارية.
بمساعدة بروتوكول ELVES، ستقوم Polkadot بتوسيع أمنها بالكامل إلى جميع rollup، والتحقق من جميع العمليات على الcore، دون الحاجة إلى فرض أي قيود أو افتراضات على عدد النوى المستخدمة.
لذا، يمكن أن تحقق rollup الخاصة بـ Polkadot توسيعًا حقيقيًا دون التضحية بالأمان.
قابلية الاستخدام
لن يحد التوسع المرن من قابلية برمجة rollup. يدعم نموذج rollup في Polkadot تنفيذ حسابات كاملة تورينغ في بيئة WebAssembly، طالما أن التنفيذ الواحد يتم في أقل من ثانيتين. بفضل التوسع المرن، يمكن زيادة إجمالي كمية الحسابات القابلة للتنفيذ في كل دورة مدتها 6 ثوانٍ، لكن نوع الحسابات لا يتأثر.
تعقيد
إن زيادة معدل نقل البيانات وانخفاض الكمون لا مفر منهما في إدخال التعقيد، وهو الطريقة الوحيدة المقبولة في تصميم الأنظمة.
يمكن لـ Rollup ضبط الموارد ديناميكيًا من خلال واجهة Agile Coretime للحفاظ على مستوى أمان متسق. كما يجب عليها تحقيق بعض متطلبات RFC103 لتناسب سيناريوهات الاستخدام المختلفة.
تعتمد التعقيد المحدد على استراتيجية إدارة موارد rollup، والتي قد تعتمد على متغيرات على السلسلة أو خارج السلسلة. على سبيل المثال:
استراتيجية بسيطة: استخدام عدد ثابت من core دائمًا، أو التعديل يدويًا خارج السلسلة؛
استراتيجية خفيفة: مراقبة أحمال المعاملات المحددة في ميمبول العقدة؛
استراتيجيات مؤتمتة: من خلال البيانات التاريخية وواجهة XCM لاستدعاء خدمة coretime مسبقًا لتكوين الموارد.
على الرغم من أن الطريقة الآلية أكثر كفاءة، إلا أن تكاليف التنفيذ والاختبار ترتفع بشكل ملحوظ.
التفاعل المتبادل
يدعم Polkadot التفاعل بين مختلف rollups، ولن تؤثر القابلية للتوسع المرن على معدل نقل الرسائل.
تتم عملية التواصل بين الرسائل عبر الrollup بواسطة طبقة النقل الأساسية، حيث أن مساحة كتلة التواصل لكل rollup ثابتة ولا تتعلق بعدد النوى المخصصة له.
في المستقبل، ستدعم Polkadot أيضًا تبادل الرسائل خارج السلسلة، حيث ستكون سلسلة الترحيل هي الواجهة التحكمية، وليس الواجهة البيانية. ستعزز هذه الترقية من قدرة الاتصال بين عمليات التكديس مع زيادة المرونة، مما يعزز قدرة النظام على التوسع العمودي.
تقييمات البروتوكولات الأخرى
من المعروف أن تحسين الأداء غالبًا ما يأتي على حساب اللامركزية والأمان. ولكن من حيث معامل ناكاموتو، حتى لو كانت درجة اللامركزية لدى بعض المنافسين لـ Polkadot منخفضة، فإن أدائهم لا يرضي.
سولانا
لا تعتمد Solana على هيكل تقسيم Polkadot أو Ethereum، بل تحقق قابلية التوسع من خلال هيكل أحادي الطبقة عالي الإنتاجية، تعتمد على إثبات التاريخ (PoH)، المعالجة المتوازية لوحدة المعالجة المركزية، وآلية توافق الآراء المستندة إلى القائد، حيث يمكن أن تصل TPS النظرية إلى 65,000.
تصميم رئيسي هو آلية جدولة القادة التي تم الكشف عنها مسبقًا ويمكن التحقق منها:
في بداية كل فترة (حوالي يومين أو 432,000 فتحة)، يتم تخصيص الفتحات بناءً على كمية الرهان؛
كلما كانت المراهنة أكثر، كانت التوزيعات أكثر. على سبيل المثال، سيحصل المدقق الذي يراهن بنسبة 1% على حوالي 1% من فرص الكتلة؛
تم الإعلان عن جميع صانعي الكتل مسبقًا، مما زاد من خطر تعرض الشبكة لهجمات DDoS موجهة، والانقطاع المتكرر.
تتطلب PoH والمعالجة المتوازية متطلبات عالية جدًا من الأجهزة، مما يؤدي إلى مركزية عقد التحقق. كلما زادت كمية الرهانات، زادت فرص عقد إنشاء الكتل، بينما تعاني العقد الصغيرة من عدم وجود أي مكان، مما يزيد من المركزية، ويزيد أيضًا من خطر تعطل النظام بعد الهجوم.
سولانا ضحت باللامركزية وقدرتها على مقاومة الهجمات في سعيها لتحقيق TPS، حيث أن معامل ناكاموتو الخاص بها هو 20، وهو أقل بكثير من 172 الخاص بـ بولكادوت.
طن
تدعي TON أن عدد TPS يمكن أن يصل إلى 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 إضافية، مما يضحي باللامركزية والأمان.
في بولكادوت، تشترك جميع التراكبات في ضمان أمان موحد؛ بينما لا تحتوي الشبكات الفرعية في أفالانش على ضمان أمان افتراضي، وبعضها قد يكون مركزيًا تمامًا. إذا كنت ترغب في زيادة الأمان، فلا بد من تقديم تنازلات في الأداء، ومن الصعب تقديم التزامات أمان مؤكدة.
إيثيريوم
استراتيجية التوسع لإيثريوم هي الرهان على قابلية التوسع في طبقة الـ rollup، بدلاً من حل المشكلة مباشرة في الطبقة الأساسية. هذه الطريقة في جوهرها لم تحل المشكلة، بل نقلت المشكلة إلى الطبقة العليا من المكدس.
التفاؤل رول أب
حالياً، تعتبر معظم حلول الـOptimistic rollup مركزية (بعضها يحتوي على sequencer واحد فقط)، مما يؤدي إلى مشاكل مثل نقص الأمان، والعزلة عن بعضها البعض، والوقت المستغرق (يجب انتظار فترة إثبات الغش، والتي عادة ما تستغرق عدة أيام).
ZK Rollup
تتأثر عملية تنفيذ ZK rollup بحدود كمية البيانات التي يمكن معالجتها في معاملة واحدة. إن متطلبات الحساب لإنتاج إثباتات المعرفة الصفرية مرتفعة جداً، وآلية "الفائز يأخذ كل شيء" تسهل المركزية في النظام. لضمان TPS، غالباً ما يحدد ZK rollup كمية المعاملات في كل دفعة، مما قد يؤدي إلى ازدحام الشبكة وزيادة رسوم الغاز في أوقات الطلب المرتفع، مما يؤثر على تجربة المستخدم.
بالمقارنة، فإن تكلفة ZK rollup القادر على تيرلنغ تقدر بحوالي 2×10^6 مرة من بروتوكول أمان الاقتصاد المشفر الأساسي في بولكادوت.
علاوة على ذلك، ستؤدي مشكلة قابلية البيانات في ZK rollup إلى تفاقم عيوبها. لضمان إمكانية التحقق من المعاملات من قبل أي شخص، لا يزال يتعين تقديم بيانات المعاملات كاملة. وهذا غالبًا ما يعتمد على حلول إضافية لقابلية البيانات، مما يزيد من التكاليف ورسوم المستخدم.
الخاتمة
نهاية القابلية للتوسع يجب ألا تكون تنازلاً.
بالمقارنة مع سلاسل الكتل العامة الأخرى، لم تسلك Polkadot طريق تحويل المركزية إلى أداء، أو استبدال الثقة المسبقة بالكفاءة، بل حققت توازنًا متعدد الأبعاد بين الأمان، واللامركزية والأداء العالي من خلال التوسع المرن، وتصميم بروتوكول غير مصرح به، وطبقة أمان موحدة وآلية إدارة موارد مرنة.
في سعيها لتحقيق تطبيقات أكبر حجمًا اليوم، قد تكون "قابلية التوسع بدون ثقة" التي تتمسك بها Polkadot هي الحل الحقيقي الذي يمكن أن يدعم التطور المستدام لـ Web3.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 16
أعجبني
16
6
إعادة النشر
مشاركة
تعليق
0/400
Fren_Not_Food
· 07-23 13:22
المشروع يبدو جيداً، دعنا نرى الأداء الفعلي.
شاهد النسخة الأصليةرد0
BlockchainDecoder
· 07-23 11:10
استنادًا إلى بيانات مجموعة أبحاث Cho الحديثة، فإن معدل المعاملات في الثانية (tps) لسلاسل الكتل الفردية عمومًا أقل من 3 آلاف، وتحتاج مشكلة الموازنة إلى突破 عاجل.
بولكادوت: خيار جديد في نظام Web3 البيئي مع قابلية التوسع بدون تنازلات
توازن قابلية توسيع البلوكتشين: اختيار Polkadot وWeb3
في الوقت الذي تسعى فيه البلوكتشين باستمرار لتحسين الكفاءة، تبرز مسألة رئيسية: كيف يمكن تحقيق أداء متزايد دون التضحية بالأمان ومرونة النظام؟
ليس هذا مجرد تحدٍ على المستوى التكنولوجي، بل هو خيار عميق في تصميم الهيكل. بالنسبة لنظام Web3، فإن السعي فقط نحو أنظمة أسرع مع تجاهل الثقة والأمان، يجعل من الصعب دعم الابتكار المستدام حقًا.
كجهة فاعلة مهمة في توسيع Web3، هل قامت Polkadot بتقديم بعض التضحيات في سعيها لتحقيق معدل عالٍ من المعالجة ووقت استجابة منخفض؟ هل نموذج rollup الخاص بها قد تخلّى عن اللامركزية أو الأمان أو التفاعل الشبكي؟
ستتناول هذه المقالة هذه القضايا، حيث ستقوم بتحليل عميق للموازنة في تصميم قابلية التوسع في Polkadot، ومقارنتها مع الحلول الأخرى في سلاسل الكتل الرئيسية، واستكشاف الاختلافات في الخيارات بين الأداء والأمان واللامركزية.
التحديات التي تواجه تصميم توسيع بولكادوت
التوازن بين المرونة واللامركزية
هل يعتمد هيكل بولكادوت على شبكة المدققين وسلسلة الإعادة، هل من الممكن أن يقدم ذلك مخاطر مركزية في بعض الجوانب؟ هل من الممكن أن يتشكل نقطة فشل واحدة أو سيطرة، مما يؤثر على خصائصه اللامركزية؟
يعتمد تشغيل Rollup على مُرتب سلسلة الوسيط المتصل، حيث تستخدم اتصالاتها آلية بروتوكول الـ collator. هذا البروتوكول لا يتطلب إذنًا أو ثقة على الإطلاق، يمكن لأي شخص لديه اتصال بالشبكة استخدامه، وتوصيل عدد قليل من عقد سلسلة الوسيط، وتقديم طلبات تحويل حالة الـ rollup. ستتم معالجة هذه الطلبات من خلال أحد نوى سلسلة الوسيط، بشرط واحد فقط: يجب أن تكون تحويلات الحالة صالحة، وإلا فلن يتم دفع حالة الـ rollup.
موازنة التوسع العمودي
يمكن أن تحقق Rollup التوسع العمودي من خلال الاستفادة من بنية Polkadot متعددة النوى. تم تقديم هذه القدرة الجديدة من خلال ميزة "التوسع المرن". خلال عملية التصميم، تم اكتشاف أنه نظرًا لأن التحقق من كتلة rollup لا يتم تنفيذه بشكل ثابت على نواة واحدة، فقد يؤثر ذلك على مرونته.
نظرًا لأن بروتوكول تقديم الكتل إلى سلسلة الوسيط هو غير مصرح به وغير موثوق، يمكن لأي شخص تقديم الكتل إلى أي نواة تم تخصيصها للـrollup للتحقق. قد يستغل المهاجمون ذلك، من خلال إعادة تقديم كتل شرعية تم التحقق منها مسبقًا إلى نوى مختلفة، مما يستهلك الموارد بشكل ضار، وبالتالي يقلل من إجمالي قدرة الـrollup وكفاءته.
يهدف Polkadot إلى الحفاظ على مرونة rollup والاستخدام الفعال لموارد سلسلة الترحيل دون التأثير على الخصائص الأساسية للنظام.
هل Sequencer موثوق؟
طريقة بسيطة للحل هي تعيين البروتوكول على أنه "مرخص": على سبيل المثال باستخدام آلية القائمة البيضاء، أو الثقة افتراضياً أن المنظمين لن يتصرفوا بشكل خبيث، مما يضمن نشاط rollup.
ومع ذلك، في مفهوم تصميم Polkadot، لا يمكننا إجراء أي افتراضات موثوقة حول sequencer، لأننا يجب أن نحافظ على خصائص النظام «غير موثوق» و«غير مصرح به». يجب أن يتمكن أي شخص من استخدام بروتوكول collator لتقديم طلبات تحويل حالة rollup.
بولكادوت: حل لا يتنازل
الخيار النهائي لPolkadot هو: ترك المشكلة بالكامل لوظيفة تحويل حالة rollup (Runtime) لحلها. Runtime هو المصدر الوحيد الموثوق لجميع معلومات الإجماع، لذلك يجب التصريح بوضوح في المخرجات عن المكان الذي يجب تنفيذ التحقق فيه على أي نواة من Nucleus.
يضمن هذا التصميم ازدواجية المرونة والأمان. ستقوم Polkadot بإعادة تنفيذ تحويل حالة rollup في عملية التوفر، وستضمن بروتوكول الاقتصاد المشفر ELVES صحة توزيع core.
قبل كتابة أي كتلة rollup إلى طبقة قابلية البيانات في Polkadot، ستقوم مجموعة مكونة من حوالي 5 مدققين أولاً بالتحقق من شرعيتها. يتلقون الإيصالات المرشحة وشهادات الصلاحية المقدمة من المُرتب، والتي تتضمن كتلة rollup وأدلة التخزين المقابلة. سيتم تمرير هذه المعلومات لمعالجة وظيفة التحقق في السلاسل المتوازية، ليقوم المدققون على سلسلة الإرسال بإعادة تنفيذها.
نتيجة التحقق تتضمن محدد core، يُستخدم لتحديد أي core يجب أن يتم التحقق من الكتلة عليه. سيقوم المُحقق بمقارنة هذا الفهرس مع core الذي يتحمل مسؤوليته؛ إذا لم يكن متطابقًا، ستُ discarded الكتلة.
تضمن هذه الآلية أن تظل النظام دائمًا بلا ثقة وبدون إذن، مما يمنع الجهات الخبيثة مثل المنظمين من التلاعب بمواقع التحقق، ويضمن أنه حتى عند استخدام rollup لعدة core، يمكن الحفاظ على المرونة.
الأمان
في سعيها لتحقيق التوسع، لم تتنازل Polkadot عن الأمان. يتم ضمان أمان الـ rollup بواسطة سلسلة الوسيط، حيث يكفي وجود مرتّب أمين للحفاظ على الاستمرارية.
بمساعدة بروتوكول ELVES، ستقوم Polkadot بتوسيع أمنها بالكامل إلى جميع rollup، والتحقق من جميع العمليات على الcore، دون الحاجة إلى فرض أي قيود أو افتراضات على عدد النوى المستخدمة.
لذا، يمكن أن تحقق rollup الخاصة بـ Polkadot توسيعًا حقيقيًا دون التضحية بالأمان.
قابلية الاستخدام
لن يحد التوسع المرن من قابلية برمجة rollup. يدعم نموذج rollup في Polkadot تنفيذ حسابات كاملة تورينغ في بيئة WebAssembly، طالما أن التنفيذ الواحد يتم في أقل من ثانيتين. بفضل التوسع المرن، يمكن زيادة إجمالي كمية الحسابات القابلة للتنفيذ في كل دورة مدتها 6 ثوانٍ، لكن نوع الحسابات لا يتأثر.
تعقيد
إن زيادة معدل نقل البيانات وانخفاض الكمون لا مفر منهما في إدخال التعقيد، وهو الطريقة الوحيدة المقبولة في تصميم الأنظمة.
يمكن لـ Rollup ضبط الموارد ديناميكيًا من خلال واجهة Agile Coretime للحفاظ على مستوى أمان متسق. كما يجب عليها تحقيق بعض متطلبات RFC103 لتناسب سيناريوهات الاستخدام المختلفة.
تعتمد التعقيد المحدد على استراتيجية إدارة موارد rollup، والتي قد تعتمد على متغيرات على السلسلة أو خارج السلسلة. على سبيل المثال:
على الرغم من أن الطريقة الآلية أكثر كفاءة، إلا أن تكاليف التنفيذ والاختبار ترتفع بشكل ملحوظ.
التفاعل المتبادل
يدعم Polkadot التفاعل بين مختلف rollups، ولن تؤثر القابلية للتوسع المرن على معدل نقل الرسائل.
تتم عملية التواصل بين الرسائل عبر الrollup بواسطة طبقة النقل الأساسية، حيث أن مساحة كتلة التواصل لكل rollup ثابتة ولا تتعلق بعدد النوى المخصصة له.
في المستقبل، ستدعم Polkadot أيضًا تبادل الرسائل خارج السلسلة، حيث ستكون سلسلة الترحيل هي الواجهة التحكمية، وليس الواجهة البيانية. ستعزز هذه الترقية من قدرة الاتصال بين عمليات التكديس مع زيادة المرونة، مما يعزز قدرة النظام على التوسع العمودي.
تقييمات البروتوكولات الأخرى
من المعروف أن تحسين الأداء غالبًا ما يأتي على حساب اللامركزية والأمان. ولكن من حيث معامل ناكاموتو، حتى لو كانت درجة اللامركزية لدى بعض المنافسين لـ Polkadot منخفضة، فإن أدائهم لا يرضي.
سولانا
لا تعتمد Solana على هيكل تقسيم Polkadot أو Ethereum، بل تحقق قابلية التوسع من خلال هيكل أحادي الطبقة عالي الإنتاجية، تعتمد على إثبات التاريخ (PoH)، المعالجة المتوازية لوحدة المعالجة المركزية، وآلية توافق الآراء المستندة إلى القائد، حيث يمكن أن تصل TPS النظرية إلى 65,000.
تصميم رئيسي هو آلية جدولة القادة التي تم الكشف عنها مسبقًا ويمكن التحقق منها:
تتطلب PoH والمعالجة المتوازية متطلبات عالية جدًا من الأجهزة، مما يؤدي إلى مركزية عقد التحقق. كلما زادت كمية الرهانات، زادت فرص عقد إنشاء الكتل، بينما تعاني العقد الصغيرة من عدم وجود أي مكان، مما يزيد من المركزية، ويزيد أيضًا من خطر تعطل النظام بعد الهجوم.
سولانا ضحت باللامركزية وقدرتها على مقاومة الهجمات في سعيها لتحقيق TPS، حيث أن معامل ناكاموتو الخاص بها هو 20، وهو أقل بكثير من 172 الخاص بـ بولكادوت.
طن
تدعي TON أن عدد TPS يمكن أن يصل إلى 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 إضافية، مما يضحي باللامركزية والأمان.
في بولكادوت، تشترك جميع التراكبات في ضمان أمان موحد؛ بينما لا تحتوي الشبكات الفرعية في أفالانش على ضمان أمان افتراضي، وبعضها قد يكون مركزيًا تمامًا. إذا كنت ترغب في زيادة الأمان، فلا بد من تقديم تنازلات في الأداء، ومن الصعب تقديم التزامات أمان مؤكدة.
إيثيريوم
استراتيجية التوسع لإيثريوم هي الرهان على قابلية التوسع في طبقة الـ rollup، بدلاً من حل المشكلة مباشرة في الطبقة الأساسية. هذه الطريقة في جوهرها لم تحل المشكلة، بل نقلت المشكلة إلى الطبقة العليا من المكدس.
التفاؤل رول أب
حالياً، تعتبر معظم حلول الـOptimistic rollup مركزية (بعضها يحتوي على sequencer واحد فقط)، مما يؤدي إلى مشاكل مثل نقص الأمان، والعزلة عن بعضها البعض، والوقت المستغرق (يجب انتظار فترة إثبات الغش، والتي عادة ما تستغرق عدة أيام).
ZK Rollup
تتأثر عملية تنفيذ ZK rollup بحدود كمية البيانات التي يمكن معالجتها في معاملة واحدة. إن متطلبات الحساب لإنتاج إثباتات المعرفة الصفرية مرتفعة جداً، وآلية "الفائز يأخذ كل شيء" تسهل المركزية في النظام. لضمان TPS، غالباً ما يحدد ZK rollup كمية المعاملات في كل دفعة، مما قد يؤدي إلى ازدحام الشبكة وزيادة رسوم الغاز في أوقات الطلب المرتفع، مما يؤثر على تجربة المستخدم.
بالمقارنة، فإن تكلفة ZK rollup القادر على تيرلنغ تقدر بحوالي 2×10^6 مرة من بروتوكول أمان الاقتصاد المشفر الأساسي في بولكادوت.
علاوة على ذلك، ستؤدي مشكلة قابلية البيانات في ZK rollup إلى تفاقم عيوبها. لضمان إمكانية التحقق من المعاملات من قبل أي شخص، لا يزال يتعين تقديم بيانات المعاملات كاملة. وهذا غالبًا ما يعتمد على حلول إضافية لقابلية البيانات، مما يزيد من التكاليف ورسوم المستخدم.
الخاتمة
نهاية القابلية للتوسع يجب ألا تكون تنازلاً.
بالمقارنة مع سلاسل الكتل العامة الأخرى، لم تسلك Polkadot طريق تحويل المركزية إلى أداء، أو استبدال الثقة المسبقة بالكفاءة، بل حققت توازنًا متعدد الأبعاد بين الأمان، واللامركزية والأداء العالي من خلال التوسع المرن، وتصميم بروتوكول غير مصرح به، وطبقة أمان موحدة وآلية إدارة موارد مرنة.
في سعيها لتحقيق تطبيقات أكبر حجمًا اليوم، قد تكون "قابلية التوسع بدون ثقة" التي تتمسك بها Polkadot هي الحل الحقيقي الذي يمكن أن يدعم التطور المستدام لـ Web3.