موازنة وتحديات قابلية التوسع في البلوكتشين: حلول Polkadot
في ظل السعي المستمر لتقنية البلوكتشين لتحقيق كفاءة أعلى اليوم، تبرز مسألة رئيسية تدريجيًا: كيف يمكن تحسين الأداء دون التضحية بالأمان ومرونة النظام؟ هذه ليست مجرد تحديات على المستوى التقني، بل هي أيضًا خيارات عميقة في تصميم الهيكل. بالنسبة لبيئة Web3، فإن نظامًا أسرع إذا تم إنشاؤه على أساس التضحية بالثقة والأمان، غالبًا ما يكون من الصعب دعم الابتكار القابل للاستدامة حقًا.
بصفته أحد المحفزين الرئيسيين للتوسع في Web3، هل قدم نموذج rollup الخاص بـ Polkadot تنازلات في اللامركزية أو الأمان أو التداخل الشبكي؟ ستتناول هذه المقالة تحليلًا عميقًا للتوازنات والتسويات التي قامت بها Polkadot في تصميم التوسع، مقارنةً مع حلول سلاسل الكتل الرئيسية الأخرى، واستكشاف المسارات المختلفة التي تم اختيارها فيما يتعلق بالأداء والأمان واللامركزية.
التحديات التي تواجه تصميم توسيع Polkadot
التوازن بين المرونة واللامركزية
تعتمد بنية Polkadot على شبكة المصدقين وكتلة الترحيل (Relay Chain)، مما قد يقدم مخاطر مركزية في بعض الجوانب. يعتمد تشغيل Rollup على الترتيب (sequencer) المتصل بكتلة الترحيل، حيث تستخدم اتصالاتها آلية بروتوكول collator. لا يتطلب هذا البروتوكول أي إذن أو ثقة، حيث يمكن لأي شخص لديه اتصال بالإنترنت استخدامه، للاتصال بعدد قليل من عقد كتلة الترحيل وتقديم طلبات تحويل حالة rollup.
التوازن في التوسع العمودي
يمكن أن تحقق Rollup التوسع العمودي من خلال الاستفادة من الهيكل متعدد النواة في Polkadot. تم إدخال هذه القدرة الجديدة من خلال ميزة "التوسع المرن" (Elastic Scaling). ومع ذلك، نظرًا لأن التحقق من كتلة rollup لا يتم تنفيذه بشكل ثابت على نواة معينة، فقد يؤثر ذلك على مرونتها. قد يستغل المهاجمون هذه النقطة من خلال تقديم كتل قانونية تم التحقق منها مسبقًا بشكل متكرر إلى نوى مختلفة، مما يستهلك الموارد بشكل ضار، وبالتالي يقلل من إجمالي إنتاجية وكفاءة rollup.
مشكلة الثقة في Sequencer
إحدى الحلول البسيطة هي تعيين البروتوكول ليكون "ذو ترخيص"، مثل استخدام آلية القائمة البيضاء، أو الثقة افتراضياً أن المنظمين لن يتصرفوا بشكل ضار. ومع ذلك، في مفهوم تصميم Polkadot، لا يمكن افتراض أي ثقة في المنظمين، لأنه يجب الحفاظ على خصائص "عدم الثقة" و"عدم الحاجة إلى ترخيص" للنظام.
حلول بولكادوت
الخيار النهائي لـ Polkadot هو: تسليم المشكلة بالكامل إلى دالة تحويل حالة rollup (Runtime) لحلها. Runtime هو المصدر الوحيد الموثوق لجميع معلومات التوافق، ويجب أن يتم الإعلان بوضوح في المخرجات عن أي نواة Polkadot يجب تنفيذ التحقق عليها.
يحقق هذا التصميم ضمانًا مزدوجًا للمرونة والأمان. ستقوم Polkadot بإعادة تنفيذ تحويل حالة rollup في عملية التوافر، وتضمن صحة التوزيع الأساسي من خلال بروتوكول الاقتصاد المشفر ELVES.
قبل كتابة البيانات إلى طبقة قابلية الاستخدام (DA) لبلوكتشين Polkadot في أي كتلة rollup، ستقوم مجموعة مكونة من حوالي 5 من المدققين بالتحقق من مشروعيتها أولاً. يتلقون الإيصالات المرشحة وأدلة الصلاحية المقدمة من المُرتب، والتي تحتوي على كتلة rollup وشهادات التخزين المقابلة. ستتم معالجة هذه المعلومات بواسطة دالة التحقق في السلسلة المتوازية، وسيقوم المدققون على السلسلة الوسيطة بإعادة تنفيذها.
نتيجة التحقق تحتوي على محدد core، يُستخدم لتحديد أي core يجب التحقق من الكتلة عليه. سيقارن المدقق بين هذا الفهرس وما إذا كان يتوافق مع core المسؤول عنه؛ إذا لم يكن متوافقًا، سيتم التخلص من هذه الكتلة.
تضمن هذه الآلية بقاء النظام دائمًا بدون ثقة وبدون إذن، مما يمنع الجهات الخبيثة مثل الترتيب من التلاعب بمواقع التحقق، ويضمن الحفاظ على المرونة حتى عند استخدام rollup لعدة core.
الأمان
في سعيها لتحقيق التوسع، لم تتنازل Polkadot عن الأمان. يتم تأمين rollup بواسطة سلسلة الترحيل، ويكفي وجود مرتب نزيه للحفاظ على البقاء. بفضل بروتوكول ELVES، قامت Polkadot بتوسيع أمانها بالكامل إلى جميع rollup، والتحقق من جميع الحسابات على النواة، دون الحاجة إلى فرض أي قيود أو افتراضات على عدد النوى المستخدمة.
قابلية الاستخدام
لن يحد التوسع المرن من قابلية البرمجة للـrollup. يدعم نموذج الـrollup في Polkadot تنفيذ حسابات كاملة في بيئة WebAssembly، طالما أن التنفيذ الفردي يتم في أقل من ثانيتين. بفضل التوسع المرن، يمكن زيادة إجمالي كمية الحسابات التي يمكن تنفيذها في كل دورة مدتها 6 ثوانٍ، لكن نوع الحسابات لا يتأثر.
تعقيد
لا مفر من أن يؤدي زيادة السعة وتقليل التأخير إلى إدخال التعقيد، وهو الطريقة الوحيدة المقبولة للتوازن في تصميم النظام. يمكن لـ Rollup ضبط الموارد ديناميكيًا من خلال واجهة Agile Coretime للحفاظ على مستوى أمان متسق. كما يجب عليها تحقيق بعض متطلبات RFC103 لتناسب سيناريوهات الاستخدام المختلفة.
تعتمد التعقيدات المحددة على استراتيجيات إدارة الموارد في rollup، والتي قد تعتمد على المتغيرات الموجودة على السلسلة أو خارجها. على سبيل المثال:
استراتيجية بسيطة: استخدم دائمًا عدد ثابت من core، أو قم بالتعديل يدويًا خارج السلسلة؛
استراتيجية خفيفة: مراقبة حمولة معاملات محددة في ميمبول العقد.
استراتيجيات مؤتمتة: من خلال البيانات التاريخية وواجهة XCM لاستدعاء خدمات coretime مسبقًا لتكوين الموارد.
على الرغم من أن الطريقة الآلية أكثر كفاءة، إلا أن تكاليف التنفيذ والاختبار ترتفع بشكل ملحوظ.
التفاعل المتبادل
يدعم Polkadot التفاعل بين rollups المختلفة، بينما لا يؤثر التوسع المرن على سعة نقل الرسائل. يتم تنفيذ الاتصال بين rollups من خلال طبقة النقل الأساسية، حيث تكون مساحة كتلة الاتصال لكل rollup ثابتة، ولا تتعلق بعدد النوى المخصصة له.
في المستقبل، ستدعم Polkadot أيضًا نقل الرسائل خارج السلسلة، مع وجود سلسلة النقل كواجهة تحكم، وليس كواجهة بيانات. ستعمل هذه الترقية على تحسين قدرة الاتصال بين rollup مع توسيع المرونة، مما يعزز بشكل أكبر القدرة العمودية للنظام.
التوازنات في البروتوكولات الأخرى
من المعروف أن تعزيز الأداء غالباً ما يأتي على حساب اللامركزية والأمان. لكن من حيث معامل ناكاموتو، حتى لو كانت درجة اللامركزية لبعض المنافسين لـ Polkadot منخفضة، فإن أدائها لا يزال غير مرضٍ.
سولانا
تعتمد سولانا على هيكل أحادي الطبقة عالي الإنتاجية لتحقيق القابلية للتوسع، وتعتمد على إثبات التاريخ (PoH) ومعالجة وحدة المعالجة المركزية المتوازية وآلية توافق قائمة على القيادة، حيث يمكن أن تصل TPS النظرية إلى 65,000. التصميم الرئيسي لها هو آلية جدولة القادة التي يتم الكشف عنها مسبقًا ويمكن التحقق منها.
ومع ذلك، فإن PoH والمعالجة المتوازية تتطلبان متطلبات عالية جدًا من الأجهزة، مما يؤدي إلى تركيز عقد التحقق. كلما زاد عدد العقد التي يتم رهنها، زادت فرصتها في إنتاج الكتل، بينما يكون لدى العقد الصغيرة تقريبًا عدم وجود slots، مما يزيد من المركزية ويزيد من خطر تعطل النظام بعد تعرضه لهجوم. تسعى Solana لتحقيق TPS، على حساب اللامركزية وقدرة مقاومة الهجمات، حيث أن معامل نكاموتو الخاص بها لا يتجاوز 20، وهو أقل بكثير من 172 الخاص بPolkadot.
طن
تدعي 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 النظرية لكل شبكة فرعية إلى ~5,000، مماثلة لفكرة Polkadot: تقليل الحمل على الشريحة الفردية لتحقيق التوسع.
لكن Avalanche يسمح للمحققين باختيار المشاركة في الشبكات الفرعية بحرية، ويمكن أن تضع الشبكات الفرعية متطلبات إضافية مثل الجغرافيا وKYC، مما يضحي باللامركزية والأمان. في Polkadot، تشترك جميع rollup في ضمان أمان موحد؛ بينما الشبكات الفرعية في Avalanche لا تملك ضمان أمان افتراضي، وبعضها يمكن أن يكون مركزيًا تمامًا. إذا كنت ترغب في زيادة الأمان، فستحتاج إلى التنازل عن الأداء، ومن الصعب تقديم وعود أمان حاسمة.
إيثريوم
استراتيجية التوسع في الإيثيريوم تركز على قابلية التوسع في طبقة الـrollup بدلاً من حل المشكلة مباشرة في الطبقة الأساسية. هذه الطريقة في جوهرها لم تحل المشكلة، بل نقلت المشكلة إلى الطبقة العليا من المكدس.
تعتبر تقنيات Optimistic Rollup في الوقت الحالي مركزية إلى حد كبير، مما يسبب مشاكل مثل نقص الأمان، والعزلة بين بعضها البعض، وزيادة التأخير (حيث يتعين الانتظار لفترة إثبات الاحتيال، والتي عادة ما تستغرق عدة أيام).
تأثرت تنفيذات ZK Rollup بحدود كمية البيانات التي يمكن معالجتها في كل معاملة واحدة. تتطلب حسابات إثبات المعرفة الصفرية موارد حسابية عالية جداً، وآلية "الفائز يأخذ كل شيء" قد تؤدي بسهولة إلى مركزية النظام. لضمان TPS، غالباً ما تحد ZK Rollup من حجم كل دفعة من المعاملات، مما قد يؤدي إلى ازدحام الشبكة وارتفاع تكاليف الغاز في أوقات الطلب المرتفع، مما يؤثر على تجربة المستخدم.
بالمقارنة، فإن تكلفة ZK rollup المكتمل من حيث Turing هي حوالي 2x10^6 مرة من بروتوكول الأمان الاقتصادي الأساسي لـ Polkadot. بالإضافة إلى ذلك، فإن مشكلة توفر البيانات في ZK rollup ستزيد من عيوبها. لضمان قدرة أي شخص على التحقق من المعاملات، يجب تقديم بيانات المعاملات الكاملة. يعتمد هذا عادةً على حلول إضافية لتوفر البيانات، مما يزيد من التكاليف ورسوم المستخدمين.
الخاتمة
نهاية القابلية للتوسع لا ينبغي أن تكون تنازلاً. مقارنةً بسلاسل الكتل العامة الأخرى، لم يسلك Polkadot طريقًا يتم فيه استبدال الأداء بالتركيز أو الكفاءة بالثقة المسبقة، بل حقق توازنًا متعدد الأبعاد بين الأمان واللامركزية والأداء العالي من خلال تصميم بروتوكولات مرنة وقابلة للتوسع، وطبقة أمان موحدة وآلية إدارة موارد مرنة.
في سعيها لتحقيق تطبيقات أكبر على الأرض اليوم، قد تكون "قابلية التوسع بدون ثقة" التي تتمسك بها Polkadot هي الحل الحقيقي الذي يمكن أن يدعم التطور بعيد المدى للويب 3.
قد تحتوي هذه الصفحة على محتوى من جهات خارجية، يتم تقديمه لأغراض إعلامية فقط (وليس كإقرارات/ضمانات)، ولا ينبغي اعتباره موافقة على آرائه من قبل Gate، ولا بمثابة نصيحة مالية أو مهنية. انظر إلى إخلاء المسؤولية للحصول على التفاصيل.
تسجيلات الإعجاب 22
أعجبني
22
6
مشاركة
تعليق
0/400
DuskSurfer
· 07-09 17:45
إن عدم موت DOT هو أمر جيد
شاهد النسخة الأصليةرد0
StakeOrRegret
· 07-09 03:46
老盖被dot خداع الناس لتحقيق الربح 麻了
شاهد النسخة الأصليةرد0
CryptoPunster
· 07-09 03:45
حان وقت مناقشة مثلث التضحية مرة أخرى، من يقف ومن يجلس واضح للجميع
شاهد النسخة الأصليةرد0
Token_Sherpa
· 07-09 03:43
meh... مستوى آخر يعد بالثالوث المقدس للتوسع. كنت هناك، فعلت ذلك، خسرت أموالا في ICOs smh
شاهد النسخة الأصليةرد0
OnchainSniper
· 07-09 03:42
لماذا لا نتحدث مباشرة عن بيانات الأداء؟
شاهد النسخة الأصليةرد0
SelfCustodyBro
· 07-09 03:31
لا تتحدث عن التوسع، دعنا نتحدث عن انخفاض DOT اليوم.
كيف تحقق Polkadot توسيع الأداء العالي دون التضحية بالأمان واللامركزية
موازنة وتحديات قابلية التوسع في البلوكتشين: حلول Polkadot
في ظل السعي المستمر لتقنية البلوكتشين لتحقيق كفاءة أعلى اليوم، تبرز مسألة رئيسية تدريجيًا: كيف يمكن تحسين الأداء دون التضحية بالأمان ومرونة النظام؟ هذه ليست مجرد تحديات على المستوى التقني، بل هي أيضًا خيارات عميقة في تصميم الهيكل. بالنسبة لبيئة Web3، فإن نظامًا أسرع إذا تم إنشاؤه على أساس التضحية بالثقة والأمان، غالبًا ما يكون من الصعب دعم الابتكار القابل للاستدامة حقًا.
بصفته أحد المحفزين الرئيسيين للتوسع في Web3، هل قدم نموذج rollup الخاص بـ Polkadot تنازلات في اللامركزية أو الأمان أو التداخل الشبكي؟ ستتناول هذه المقالة تحليلًا عميقًا للتوازنات والتسويات التي قامت بها Polkadot في تصميم التوسع، مقارنةً مع حلول سلاسل الكتل الرئيسية الأخرى، واستكشاف المسارات المختلفة التي تم اختيارها فيما يتعلق بالأداء والأمان واللامركزية.
التحديات التي تواجه تصميم توسيع Polkadot
التوازن بين المرونة واللامركزية
تعتمد بنية Polkadot على شبكة المصدقين وكتلة الترحيل (Relay Chain)، مما قد يقدم مخاطر مركزية في بعض الجوانب. يعتمد تشغيل Rollup على الترتيب (sequencer) المتصل بكتلة الترحيل، حيث تستخدم اتصالاتها آلية بروتوكول collator. لا يتطلب هذا البروتوكول أي إذن أو ثقة، حيث يمكن لأي شخص لديه اتصال بالإنترنت استخدامه، للاتصال بعدد قليل من عقد كتلة الترحيل وتقديم طلبات تحويل حالة rollup.
التوازن في التوسع العمودي
يمكن أن تحقق Rollup التوسع العمودي من خلال الاستفادة من الهيكل متعدد النواة في Polkadot. تم إدخال هذه القدرة الجديدة من خلال ميزة "التوسع المرن" (Elastic Scaling). ومع ذلك، نظرًا لأن التحقق من كتلة rollup لا يتم تنفيذه بشكل ثابت على نواة معينة، فقد يؤثر ذلك على مرونتها. قد يستغل المهاجمون هذه النقطة من خلال تقديم كتل قانونية تم التحقق منها مسبقًا بشكل متكرر إلى نوى مختلفة، مما يستهلك الموارد بشكل ضار، وبالتالي يقلل من إجمالي إنتاجية وكفاءة rollup.
مشكلة الثقة في Sequencer
إحدى الحلول البسيطة هي تعيين البروتوكول ليكون "ذو ترخيص"، مثل استخدام آلية القائمة البيضاء، أو الثقة افتراضياً أن المنظمين لن يتصرفوا بشكل ضار. ومع ذلك، في مفهوم تصميم Polkadot، لا يمكن افتراض أي ثقة في المنظمين، لأنه يجب الحفاظ على خصائص "عدم الثقة" و"عدم الحاجة إلى ترخيص" للنظام.
حلول بولكادوت
الخيار النهائي لـ Polkadot هو: تسليم المشكلة بالكامل إلى دالة تحويل حالة rollup (Runtime) لحلها. Runtime هو المصدر الوحيد الموثوق لجميع معلومات التوافق، ويجب أن يتم الإعلان بوضوح في المخرجات عن أي نواة Polkadot يجب تنفيذ التحقق عليها.
يحقق هذا التصميم ضمانًا مزدوجًا للمرونة والأمان. ستقوم Polkadot بإعادة تنفيذ تحويل حالة rollup في عملية التوافر، وتضمن صحة التوزيع الأساسي من خلال بروتوكول الاقتصاد المشفر ELVES.
قبل كتابة البيانات إلى طبقة قابلية الاستخدام (DA) لبلوكتشين Polkadot في أي كتلة rollup، ستقوم مجموعة مكونة من حوالي 5 من المدققين بالتحقق من مشروعيتها أولاً. يتلقون الإيصالات المرشحة وأدلة الصلاحية المقدمة من المُرتب، والتي تحتوي على كتلة rollup وشهادات التخزين المقابلة. ستتم معالجة هذه المعلومات بواسطة دالة التحقق في السلسلة المتوازية، وسيقوم المدققون على السلسلة الوسيطة بإعادة تنفيذها.
نتيجة التحقق تحتوي على محدد core، يُستخدم لتحديد أي core يجب التحقق من الكتلة عليه. سيقارن المدقق بين هذا الفهرس وما إذا كان يتوافق مع core المسؤول عنه؛ إذا لم يكن متوافقًا، سيتم التخلص من هذه الكتلة.
تضمن هذه الآلية بقاء النظام دائمًا بدون ثقة وبدون إذن، مما يمنع الجهات الخبيثة مثل الترتيب من التلاعب بمواقع التحقق، ويضمن الحفاظ على المرونة حتى عند استخدام rollup لعدة core.
الأمان
في سعيها لتحقيق التوسع، لم تتنازل Polkadot عن الأمان. يتم تأمين rollup بواسطة سلسلة الترحيل، ويكفي وجود مرتب نزيه للحفاظ على البقاء. بفضل بروتوكول ELVES، قامت Polkadot بتوسيع أمانها بالكامل إلى جميع rollup، والتحقق من جميع الحسابات على النواة، دون الحاجة إلى فرض أي قيود أو افتراضات على عدد النوى المستخدمة.
قابلية الاستخدام
لن يحد التوسع المرن من قابلية البرمجة للـrollup. يدعم نموذج الـrollup في Polkadot تنفيذ حسابات كاملة في بيئة WebAssembly، طالما أن التنفيذ الفردي يتم في أقل من ثانيتين. بفضل التوسع المرن، يمكن زيادة إجمالي كمية الحسابات التي يمكن تنفيذها في كل دورة مدتها 6 ثوانٍ، لكن نوع الحسابات لا يتأثر.
تعقيد
لا مفر من أن يؤدي زيادة السعة وتقليل التأخير إلى إدخال التعقيد، وهو الطريقة الوحيدة المقبولة للتوازن في تصميم النظام. يمكن لـ Rollup ضبط الموارد ديناميكيًا من خلال واجهة Agile Coretime للحفاظ على مستوى أمان متسق. كما يجب عليها تحقيق بعض متطلبات RFC103 لتناسب سيناريوهات الاستخدام المختلفة.
تعتمد التعقيدات المحددة على استراتيجيات إدارة الموارد في rollup، والتي قد تعتمد على المتغيرات الموجودة على السلسلة أو خارجها. على سبيل المثال:
على الرغم من أن الطريقة الآلية أكثر كفاءة، إلا أن تكاليف التنفيذ والاختبار ترتفع بشكل ملحوظ.
التفاعل المتبادل
يدعم Polkadot التفاعل بين rollups المختلفة، بينما لا يؤثر التوسع المرن على سعة نقل الرسائل. يتم تنفيذ الاتصال بين rollups من خلال طبقة النقل الأساسية، حيث تكون مساحة كتلة الاتصال لكل rollup ثابتة، ولا تتعلق بعدد النوى المخصصة له.
في المستقبل، ستدعم Polkadot أيضًا نقل الرسائل خارج السلسلة، مع وجود سلسلة النقل كواجهة تحكم، وليس كواجهة بيانات. ستعمل هذه الترقية على تحسين قدرة الاتصال بين rollup مع توسيع المرونة، مما يعزز بشكل أكبر القدرة العمودية للنظام.
التوازنات في البروتوكولات الأخرى
من المعروف أن تعزيز الأداء غالباً ما يأتي على حساب اللامركزية والأمان. لكن من حيث معامل ناكاموتو، حتى لو كانت درجة اللامركزية لبعض المنافسين لـ Polkadot منخفضة، فإن أدائها لا يزال غير مرضٍ.
سولانا
تعتمد سولانا على هيكل أحادي الطبقة عالي الإنتاجية لتحقيق القابلية للتوسع، وتعتمد على إثبات التاريخ (PoH) ومعالجة وحدة المعالجة المركزية المتوازية وآلية توافق قائمة على القيادة، حيث يمكن أن تصل TPS النظرية إلى 65,000. التصميم الرئيسي لها هو آلية جدولة القادة التي يتم الكشف عنها مسبقًا ويمكن التحقق منها.
ومع ذلك، فإن PoH والمعالجة المتوازية تتطلبان متطلبات عالية جدًا من الأجهزة، مما يؤدي إلى تركيز عقد التحقق. كلما زاد عدد العقد التي يتم رهنها، زادت فرصتها في إنتاج الكتل، بينما يكون لدى العقد الصغيرة تقريبًا عدم وجود slots، مما يزيد من المركزية ويزيد من خطر تعطل النظام بعد تعرضه لهجوم. تسعى Solana لتحقيق TPS، على حساب اللامركزية وقدرة مقاومة الهجمات، حيث أن معامل نكاموتو الخاص بها لا يتجاوز 20، وهو أقل بكثير من 172 الخاص بPolkadot.
طن
تدعي 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 النظرية لكل شبكة فرعية إلى ~5,000، مماثلة لفكرة Polkadot: تقليل الحمل على الشريحة الفردية لتحقيق التوسع.
لكن Avalanche يسمح للمحققين باختيار المشاركة في الشبكات الفرعية بحرية، ويمكن أن تضع الشبكات الفرعية متطلبات إضافية مثل الجغرافيا وKYC، مما يضحي باللامركزية والأمان. في Polkadot، تشترك جميع rollup في ضمان أمان موحد؛ بينما الشبكات الفرعية في Avalanche لا تملك ضمان أمان افتراضي، وبعضها يمكن أن يكون مركزيًا تمامًا. إذا كنت ترغب في زيادة الأمان، فستحتاج إلى التنازل عن الأداء، ومن الصعب تقديم وعود أمان حاسمة.
إيثريوم
استراتيجية التوسع في الإيثيريوم تركز على قابلية التوسع في طبقة الـrollup بدلاً من حل المشكلة مباشرة في الطبقة الأساسية. هذه الطريقة في جوهرها لم تحل المشكلة، بل نقلت المشكلة إلى الطبقة العليا من المكدس.
تعتبر تقنيات Optimistic Rollup في الوقت الحالي مركزية إلى حد كبير، مما يسبب مشاكل مثل نقص الأمان، والعزلة بين بعضها البعض، وزيادة التأخير (حيث يتعين الانتظار لفترة إثبات الاحتيال، والتي عادة ما تستغرق عدة أيام).
تأثرت تنفيذات ZK Rollup بحدود كمية البيانات التي يمكن معالجتها في كل معاملة واحدة. تتطلب حسابات إثبات المعرفة الصفرية موارد حسابية عالية جداً، وآلية "الفائز يأخذ كل شيء" قد تؤدي بسهولة إلى مركزية النظام. لضمان TPS، غالباً ما تحد ZK Rollup من حجم كل دفعة من المعاملات، مما قد يؤدي إلى ازدحام الشبكة وارتفاع تكاليف الغاز في أوقات الطلب المرتفع، مما يؤثر على تجربة المستخدم.
بالمقارنة، فإن تكلفة ZK rollup المكتمل من حيث Turing هي حوالي 2x10^6 مرة من بروتوكول الأمان الاقتصادي الأساسي لـ Polkadot. بالإضافة إلى ذلك، فإن مشكلة توفر البيانات في ZK rollup ستزيد من عيوبها. لضمان قدرة أي شخص على التحقق من المعاملات، يجب تقديم بيانات المعاملات الكاملة. يعتمد هذا عادةً على حلول إضافية لتوفر البيانات، مما يزيد من التكاليف ورسوم المستخدمين.
الخاتمة
نهاية القابلية للتوسع لا ينبغي أن تكون تنازلاً. مقارنةً بسلاسل الكتل العامة الأخرى، لم يسلك Polkadot طريقًا يتم فيه استبدال الأداء بالتركيز أو الكفاءة بالثقة المسبقة، بل حقق توازنًا متعدد الأبعاد بين الأمان واللامركزية والأداء العالي من خلال تصميم بروتوكولات مرنة وقابلة للتوسع، وطبقة أمان موحدة وآلية إدارة موارد مرنة.
في سعيها لتحقيق تطبيقات أكبر على الأرض اليوم، قد تكون "قابلية التوسع بدون ثقة" التي تتمسك بها Polkadot هي الحل الحقيقي الذي يمكن أن يدعم التطور بعيد المدى للويب 3.