مرحبًا ، أنا واحد من مطوري برنامج Blockchain Near Protocol ، وأريد في هذه المقالة التحدث عن ماهية blockchain المشاركة وكيفية تنفيذها وما هي المشاكل الموجودة في تصميمات مشاركة blockchain.
من المعروف أن Ethereum ، الأكثر استخدامًا في سلسلة المفاتيح للأغراض العامة في وقت كتابة هذا التقرير ، يمكنها فقط معالجة أقل من 20 معاملة في الثانية على السلسلة الرئيسية. يؤدي هذا القيد ، بالإضافة إلى شعبية الشبكة ، إلى ارتفاع أسعار الغاز (تكلفة تنفيذ معاملة على الشبكة) وأوقات تأكيد طويلة ؛ على الرغم من حقيقة أنه في وقت كتابة هذا التقرير ، يتم إنتاج كتلة جديدة كل 10 إلى 20 ثانية تقريبًا ، في حين أن متوسط الوقت المستغرق فعليًا لإضافتها إلى سلسلة blockchain هو 1.2 دقيقة ، وفقًا لمحطة ETH للغاز . انخفاض الإنتاجية ، وارتفاع الأسعار ، والكمون العالي يجعل كل Ethereum غير مناسب لتشغيل الخدمات التي تحتاج إلى التوسع مع التبني.
ما هو السبب الرئيسي لإنتاجية Ethereum المنخفضة؟ السبب هو أن كل عقدة في الشبكة تحتاج إلى معالجة كل معاملة واحدة. اقترح المطورون العديد من الحلول لمعالجة مشكلة الإنتاجية على مستوى البروتوكول. يمكن فصل هذه الحلول في الغالب إلى تلك التي تفوض كافة العمليات الحسابية لمجموعة صغيرة من العقد القوية ، وتلك الحلول التي تحتوي كل عقدة في الشبكة تقوم فقط بمجموعة فرعية من إجمالي حجم العمل. الحالة القصوى للنهج السابق هي Thunder التي لها عقدة واحدة تعالج جميع المعاملات والمطالبات بتحقيق 1200 tx / sec ، أي 100x تحسين على Ethereum (أنا لا أؤيد Thunder ، أو أشهد على صحة مطالباتهم ) تتوافق كل من Algorand و SpaceMesh و Solana مع الفئة السابقة ، مبنية تحسينات مختلفة في الإجماع وهيكل blockchain نفسه لتشغيل معاملات أكثر بكثير ، لكن لا يزال يحده ما يمكن لآلة واحدة (وإن كانت قوية جدًا) معالجتها.
يسمى الأسلوب الأخير ، الذي يتم فيه تقسيم العمل بين جميع العقد المشاركة ، المشاركة. هذه هي الطريقة التي تخطط Ethereum Foundation حاليًا لتوسيع Ethereum. في وقت كتابة هذا التقرير ، لم يتم نشر المواصفات الكاملة. فيما يلي روابط إلى نظرة عامة مفصلة لسلاسل Ethereum shard وسلسلة Beacon .
في هذا المنشور ، ألخص الأفكار الأساسية لمشاركة blockchain ، والتي تستند إليها كل من الغالبية العظمى من البروتوكولات الأخرى المقسمة. سيوضح المنشور التالي الموضوعات الأكثر تقدماً في المشاركة.
أبسط التقسيم ، ويعرف أيضا باسم شجرة الفاصولياء
دعنا نبدأ بأبسط طريقة في المشاركة ، والتي سوف ندعوها خلال هذا الكتاب إلى شجرة الفاصولياء. هذا أيضًا ما يسميه Vitalik "التحجيم من خلال ألف altcoins" في هذا العرض التقديمي.
في هذا النهج ، بدلاً من تشغيل blockchain واحد ، سنقوم بتشغيل عدة مرات ، وسنطلق على كل blockchain مثل "shard". سيكون لكل قشرة مجموعة من أجهزة التحقق من الصحة. هنا وفي الأسفل نستخدم المصطلح العام "المدقق" للإشارة إلى المشاركين الذين يقومون بالتحقق من المعاملات وإنتاج الكتل ، إما عن طريق التعدين ، كما هو الحال في إثبات العمل ، أو عبر آلية قائمة على التصويت. الآن دعنا نفترض أن القطع لا تتواصل مع بعضها البعض.
تصميم شجرة الفاصولياء ، على الرغم من بساطته ، يكفي لتوضيح بعض التحديات الرئيسية في التقسيم.
مصادقة التقسيم وسلاسل منارة
التحدي الأول هو أنه مع وجود كل أداة مصادقة خاصة بها ، أصبح كل سهم الآن أقل أمانًا بمقدار 10 مرات من السلسلة بأكملها. لذلك إذا قررت سلسلة غير مظللة مع X Validators أن تتفرع بقوة إلى سلسلة مظللة ، وتقسيم X مدققات عبر 10 قطع ، فإن كل قشرة لديها الآن X / 10 مدققون فقط ، وإفساد قشرة واحدة يتطلب فقط إتلاف 5.1٪ (51٪) / 10) من إجمالي عدد المدققين.
الأمر الذي يقودنا إلى النقطة الثانية: من يختار أدوات التحقق لكل قشرة؟ السيطرة على 5.1 ٪ من المدققين تكون ضارة فقط إذا كانت كل تلك 5.1 ٪ من المدققين في نفس القشرة. إذا لم يتمكن المدققون من اختيار القشرة التي يجب عليهم التحقق من صحتها ، فمن غير المرجح أن يحصل المشارك الذي يسيطر على 5.1٪ من المصادقين على جميع أدوات المصادقة في نفس القشرة ، مما يقلل بشكل كبير من قدرتهم على اختراق النظام.
تعتمد جميع تصميمات المشاركة تقريبًا على مصدر من العشوائية لتعيين المدققين على القطع. يعد العشوائية على blockchain في حد ذاته موضوعًا صعبًا للغاية ويستحق نشر مدونة منفصلة في وقت لاحق ، ولكن في الوقت الحالي لنفترض أن هناك بعض مصادر العشوائية التي يمكننا استخدامها.
تتطلب كل من التعيين العشوائي والمدقق حسابًا لا يقتصر على أي قشرة معينة. لهذا الحساب ، تحتوي جميع التصميمات الموجودة فعليًا على سلسلة مفاتيح منفصلة مهمتها إجراء العمليات اللازمة لصيانة الشبكة بالكامل. إلى جانب إنشاء أرقام عشوائية وتعيين مدققين على القطع ، غالبًا ما تتضمن هذه العمليات أيضًا تلقي التحديثات من القطع وأخذ لقطات منها ومعالجة الرهانات والقطع في أنظمة إثبات الملكية وإعادة موازنة الأسهم عند دعم هذه الميزة. وتسمى هذه السلسلة سلسلة منارة في Ethereum و Near ، وسلسلة ترحيل في PolkaDot ، و Cosmos Hub في Cosmos.
خلال هذا المنشور ، سنشير إلى سلسلة مثل سلسلة منارة . إن وجود سلسلة Beacon يقودنا إلى الموضوع التالي المثير للاهتمام ، وهو التقسيم التربيعي.
التدرج التربيعي
غالبًا ما يتم الإعلان عن المشاركة كحل يقيس عددًا لا نهائي من عدد العقد المشاركة في تشغيل الشبكة. في حين أنه من الممكن نظريًا تصميم مثل هذا الحل المشترك ، فإن أي حل يحتوي على مفهوم سلسلة Beacon لا يحتوي على قابلية لا نهائية. لفهم السبب ، لاحظ أن سلسلة Beacon يجب أن تقوم ببعض عمليات حساب مسك الدفاتر ، مثل تعيين مصادقين على القطع ، أو لقطة كتل سلسلة shard ، والتي تتناسب مع عدد القطع في النظام. نظرًا لأن سلسلة Beacon هي نفسها كتلة واحدة من سلاسل المفاتيح ، مع حساب يحدها القدرات الحسابية للعقد التي تشغلها ، يكون عدد القطع محدودًا بشكل طبيعي.
ومع ذلك ، فإن بنية الشبكة المظللة تضفي تأثيرًا مضاعفًا على أي تحسينات على العقد الخاصة بها. ضع في اعتبارك الحالة التي تم فيها إجراء تحسين تعسفي على كفاءة العقد في الشبكة مما سيتيح لهم أوقات معالجة المعاملات بشكل أسرع.
إذا أصبحت العقد التي تشغل الشبكة ، بما في ذلك العقد في سلسلة Beacon ، أسرع أربع مرات ، فسيكون بإمكان كل شحنة معالجة أربع مرات أكثر من المعاملات ، وستكون سلسلة Beacon قادرة على الحفاظ على 4 مرات أكثر من القطع. ستزيد الإنتاجية عبر النظام بمعامل 4 × 4 = 16 - وبالتالي اسم التقسيم التربيعي .
من الصعب توفير قياس دقيق لعدد القطع القابلة للحياة اليوم ، ولكن من غير المحتمل أن تتجاوز احتياجات الإنتاجية لمستخدمي blockchain حدود التقادم التربيعي في أي مستقبل متوقع. العدد الهائل من العقد اللازمة لتشغيل مثل هذا الحجم من القطع بشكل آمن هو أوامر من حيث الحجم أعلى من عدد العقد التي تعمل جميع block Blockins مجتمعة اليوم.
ومع ذلك ، إذا أردنا إنشاء بروتوكولات إثبات مستقبلية ، فقد يكون من المفيد البدء في البحث عن حلول لهذه المشكلة اليوم. الاقتراح الأكثر تطوراً من الآن هو التقسيم الأسي ، حيث تقوم الشظايا نفسها بتشكيل شجرة ، وكل شبة أصل تنظّم سلسلة من شظايا الأطفال ، بينما يمكن أن تكون هي نفسها طفلة في بعض القواقع الأخرى.
من المعروف أن فلاد زامفير من Ethereum Foundation يعمل على تصميم التقسيم الذي لا يتضمن سلسلة منارات ؛ لقد عملت معه على أحد النماذج ، نظرة عامة تفصيلية عنها هنا .
تقاسم الدولة
حتى الآن لم نحدد بشكل جيد ما هو بالضبط وليس مفصولًا عند تقسيم الشبكة إلى شظايا. على وجه التحديد ، تؤدي العقد الموجودة في blockchain ثلاث مهام مهمة: لا تقوم فقط بمعالجة المعاملات ، بل أيضًا 2) نقل المعاملات التي تم التحقق منها والكتل المكتملة إلى العقد الأخرى و 3) تخزين حالة سجل دفتر الأستاذ الشبكة بالكامل وتاريخه. تفرض كل واحدة من هذه المهام الثلاث متطلبات متزايدة على العقد التي تعمل الشبكة:
- تتطلب ضرورة معالجة المعاملات قوة حساب أكبر مع زيادة عدد المعاملات التي تتم معالجتها ؛
- تتطلب ضرورة نقل المعاملات والكتل مزيدًا من النطاق الترددي للشبكة مع زيادة عدد المعاملات التي يتم ترحيلها ؛
- تتطلب الحاجة إلى تخزين البيانات مزيدًا من التخزين مع نمو الحالة. الأهم من ذلك ، خلافًا لقوة المعالجة والشبكة ، فإن متطلبات التخزين تنمو حتى إذا ظل معدل المعاملة (عدد المعاملات التي تتم معالجتها في الثانية) ثابتًا.
من القائمة أعلاه ، قد يبدو أن متطلبات التخزين ستكون الأكثر إلحاحًا ، نظرًا لأن هذا هو الشرط الوحيد الذي يتم زيادته بمرور الوقت حتى لو لم يتغير عدد المعاملات في الثانية ، ولكن في الممارسة العملية هو أكثر المتطلبات إلحاحًا اليوم هي القوة الحسابية. تبلغ حالة Ethereum بالكامل حتى كتابة هذا التقرير 100 غيغابايت ، ويمكن التحكم فيها بسهولة بواسطة معظم العقد. لكن عدد المعاملات التي يمكن لـ Ethereum معالجتها يبلغ حوالي 20 صفقة ، وهو حجم أوامر أقل مما هو مطلوب في العديد من حالات الاستخدام العملي.
Zilliqa هو المشروع الأكثر شهرة الذي يعالج القطع ولكنه ليس التخزين. تعد مشاركة المعالجة مشكلة أسهل لأن كل عقدة لها الحالة بالكامل ، مما يعني أن العقود يمكن أن تستدعي بحرية العقود الأخرى وقراءة أي بيانات من blockchain. هناك حاجة إلى بعض هندسة دقيقة للتأكد من عدم تعارض التحديثات من عدة شظايا تحديث الأجزاء نفسها من الدولة. في هذا الصدد ، تتبع Zilliqa أسلوبًا بسيطًا للغاية ، يمكن العثور على النقد في هذا المنشور.
في حين تم اقتراح مشاركة التخزين دون مشاركة المعالجة ، إلا أنني لست على علم بأي مشروع يعمل عليه. وبالتالي في الممارسة العملية ، فإن مشاركة التخزين أو مشاركة الدولة ، تعني دائمًا تقاسم معالجة الشبكة ومشاركتها.
من الناحية العملية ، في إطار "مشاركة الدولة" ، تقوم العقد في كل قشرة ببناء سلسلة المفاتيح الخاصة بها والتي تحتوي على معاملات تؤثر فقط على الجزء المحلي من الحالة العالمية المعينة لذلك القشرة. لذلك ، لا يحتاج المدققون في القشرة إلا إلى تخزين الجزء المحلي من الحالة العالمية وتنفيذ المعاملات التي تؤثر على جزءهم من الدولة فقط ، وبالتالي ، فقط التتابع. يقلل هذا القسم بشكل خطي من المتطلبات على كل حساب الطاقة والتخزين وعرض النطاق الترددي للشبكة ، ولكنه يقدم مشاكل جديدة ، مثل توافر البيانات والمعاملات المشتركة ، والتي سنتناولها أدناه.
المعاملات المشتركة
لا يعد Beanstalk كنموذج طريقة مفيدة للغاية في المشاركة ، لأنه إذا لم تتمكن شظايا فردية من التواصل مع بعضها البعض ، فهي ليست أفضل من عدة مجموعات مستقلة. حتى اليوم ، عند عدم توفر التقسيم ، هناك طلب كبير على قابلية التشغيل البيني بين مختلف المجموعات.
دعونا الآن فقط التفكير في معاملات الدفع البسيطة ، حيث يكون لكل مشارك حساب على قشرة واحدة بالضبط. إذا كان أحد يرغب في تحويل الأموال من حساب إلى آخر داخل نفس الشارد ، يمكن معالجة الصفقة بالكامل من قبل المدققين في تلك القشرة. ومع ذلك ، إذا أرادت Alice الموجودة في shard # 1 إرسال الأموال إلى Bob الذي يقيم في shard # 2 ، فلا المصادقون على Shard # 1 (لن يتمكنوا من اعتماد حساب Bob) أو المدققين على shard # 2 ( لن يتمكنوا من خصم حساب Alice) من معالجة المعاملة بالكامل.
هناك نوعان من أساليب التعامل مع المعاملات المشتركة:
- متزامن : كلما دعت الحاجة إلى تنفيذ صفقة مشتركة ، يتم إنتاج الكتل الموجودة في عدة شرائح تحتوي على انتقال الحالة المتعلقة بالمعاملة في نفس الوقت ، ويتعاون مدققو القطع المتعددة في تنفيذ مثل هذه المعاملات. الاقتراح الأكثر تفصيلا المعروف لي هو دمج القطع ، الموصوفة هنا .
- غير متزامن : يتم تنفيذ معاملة مشتركة للأسهم التي تؤثر على عدة شظايا في تلك القطع بشكل غير متزامن ، ويقوم شظية "الائتمان" بتنفيذ النصف بمجرد أن يكون لديه دليل كاف على أن شحنة "الخصم" قد نفذت جزءها. يميل هذا النهج إلى أن يكون أكثر انتشارًا بسبب بساطته وسهولة التنسيق. يتم اقتراح هذا النظام اليوم في Cosmos و Ethereum Serenity و Near و Kadena وغيرها. تكمن مشكلة هذا النهج في أنه إذا تم إنتاج الكتل بشكل مستقل ، فهناك فرصة غير صفرية أن يتيم أحد الكتل المتعددة ، مما يجعل المعاملة مطبقة جزئيًا فقط. النظر في الشكل أدناه الذي يصور اثنين من شظايا وكلاهما واجه شوكة ، والمعاملة عبر شظايا التي تم تسجيلها في كتل A و X 'المقابلة. إذا كانت السلاسل AB و V'-X'-Y'-Z في نهاية الأمر متعارف عليها في القطع المقابلة ، فسيتم الانتهاء من المعاملة تمامًا. إذا أصبحت A'-B'-C'-D 'و VX متعارف عليها ، فسيتم التخلي عن المعاملة تمامًا ، وهو أمر مقبول. ولكن إذا أصبحت AB و VX ، على سبيل المثال ، متعارف عليها ، فسيتم الانتهاء من جزء واحد من المعاملة ويتم التخلي عن جزء منها ، مما يؤدي إلى فشل ذري. سنغطي كيفية معالجة هذه المشكلة في البروتوكولات المقترحة في الجزء الثاني ، عندما نغطي التغييرات التي تطرأ على قواعد اختيار الشوكة وخوارزميات التوافق المقترحة للبروتوكولات المشتركة.
لاحظ أن التواصل بين السلاسل مفيد خارج السلاسل الحجرية المظللة أيضًا. يمثل التشغيل المتداخل بين السلاسل مشكلة معقدة يحاول العديد من المشروعات حلها. في سلاسل القطع المظللة ، تكون المشكلة أسهل إلى حد ما نظرًا لأن هيكل الكتلة والإجماع متشابهان عبر القطع ، وهناك سلسلة منارات يمكن استخدامها للتنسيق. ومع ذلك ، في جميع سلاسل المفاتيح المظللة ، تكون جميع سلاسل القطع متماثلة ، في حين يوجد في النظام الإيكولوجي للعقود العالمية الكثير من سلاسل القطع المختلفة ، مع حالات استخدام الهدف المختلفة ، واللامركزية وضمانات الخصوصية.
إن بناء نظام يكون لمجموعة من السلاسل فيه خواص مختلفة ولكن يستخدم إجماعًا وبنية كتلة متشابهة بما فيه الكفاية وله سلسلة منارات مشتركة يمكن أن يمكّن نظامًا إيكولوجيًا من سلاسل البلوكات غير المتجانسة التي لها نظام فرعي قابل للتشغيل المتبادل. من غير المرجح أن يتميز هذا النظام بتدوير المدقق ، لذلك يلزم اتخاذ بعض التدابير الإضافية لضمان الأمن. كل من كوزموس و PolkaDot هما بفعالية مثل هذه الأنظمة. تقدم هذه المقالة للكاتب Zaki Manian من Cosmos نظرة عامة ومقارنة تفصيلية للجوانب الرئيسية للمشروعين.
السلوك الضار
لديك الآن فهم جيد لكيفية تنفيذ التقسيم ، بما في ذلك مفاهيم سلسلة المنارات ، وتناوب المدقق والمعاملات المشتركة.
مع كل هذه المعلومات ، هناك شيء مهم أخير يجب مراعاته. على وجه التحديد ، ما السلوك العدواني الذي يمكن أن يقوم به المدققون الضارون.
الشوك الخبيثة
قد تحاول مجموعة من أدوات التحقق من الخبيثة إنشاء شوكة. لاحظ أنه لا يهم ما إذا كان الإجماع الأساسي هو BFT أم لا ، فإن إتلاف عدد كافٍ من المدققين سيجعل من الممكن دائمًا إنشاء مفترق طرق.
من المحتمل بدرجة كبيرة أن يكون أكثر من 50٪ من حشرة واحدة تالفة ، أكثر من 50٪ من الشبكة بالكامل تالفة (سنبحث بشكل أعمق في هذه الاحتمالات في الجزء الثاني). كما نوقش أعلاه ، تنطوي المعاملات المتبادلة على تغيرات في حالة معينة في عدة شرائح ، ويجب إما الانتهاء من الكتل المقابلة في مثل هذه القطع التي تطبق تغييرات الحالة هذه (أي تظهر في السلاسل المحددة على القطع المقابلة لها) ، أو يجب أن تكون جميع الأيتام (أي لا تظهر في السلاسل المحددة على القطع المقابلة لها). نظرًا لأن احتمال تلف القطع غير مهم عمومًا ، لا يمكننا أن نفترض أن الشوك لن يحدث حتى لو تم التوصل إلى توافق بيزنطي بين مصادقين على القشرة ، أو تم إنتاج العديد من القطع على الجزء العلوي من الكتلة مع تغيير الحالة .
تحتوي هذه المشكلة على حلول متعددة ، وأكثرها شيوعًا هو الربط العرضي لأحدث كتلة سلسلة قشرة بسلسلة المنارات. بعد ذلك يتم تغيير قاعدة اختيار الشوكة في سلاسل الحصص لتفضيل دائمًا السلسلة المرتبطة بشكل متقاطع ، ويتم تطبيق قاعدة اختيار الشوكة المحددة فقط للكتل على الكتل التي تم نشرها منذ آخر ارتباط تبادلي.
الموافقة على الكتل غير الصالحة
قد تحاول مجموعة من أجهزة التحقق من الصحة إنشاء كتلة تطبق وظيفة انتقال الحالة بشكل غير صحيح. على سبيل المثال ، بدءًا من حالة تضم فيها Alice 10 رموز ورمز Bob له 0 رمزًا ، قد يحتوي المربع على معاملة ترسل 10 رموز من Alice إلى Bob ، ولكن ينتهي بها الحال مع حالة بها Alice 0 رموز ورمز 1000 الرموز.
في سلسلة بلوكلا الكلاسيكية غير المقسمة ، لا يكون هذا الهجوم ممكنًا ، حيث أن جميع المشاركين في الشبكة يقومون بالتحقق من صحة جميع الكتل ، وسيتم رفض الكتلة ذات الانتقال غير الصحيح من قِبل كلا المنتجين الآخرين للكتلة ، والمشاركون في الشبكة التي لا تخلق كتل. حتى إذا واصل المدققون الضارون إنشاء كتل أعلى كتلة غير صالحة بشكل أسرع من قيام المدققون الصادقون ببناء السلسلة الصحيحة ، وبالتالي جعل السلسلة مع الكتلة غير الصالحة أطول ، فلا يهم ، لأن كل مشارك يستخدم blockchain ل أي غرض بالتحقق من صحة جميع الكتل ، ويتجاهل جميع الكتل المبنية على أعلى كتلة غير صالحة.
في الشكل أعلاه ، يوجد خمسة مصادقين ، ثلاثة منهم ضارون. قاموا بإنشاء كتلة غير صالحة A '، ثم واصلوا بناء كتل جديدة فوقه. تجاهل اثنان من المدققين الصادقين "أ" باعتبارهم غير صالحين وكانوا يبنون أعلى آخر كتلة صالحة معروفة لهم ، مما خلق مفترق طرق. نظرًا لوجود عدد أقل من أدوات التحقق في الشوكة الأمينة ، فإن سلسلتها أقصر. ومع ذلك ، في blockchain الكلاسيكية غير المقسمة ، يكون كل مشارك يستخدم blockchain لأي غرض مسؤولاً عن التحقق من صحة جميع الكتل التي يتلقونها وإعادة حساب الحالة. وبالتالي فإن أي شخص لديه مصلحة في blockchain قد يلاحظ أن A 'غير صالح ، وبالتالي أيضًا تجاهل على الفور B' و C 'و D' ، مثل أخذ السلسلة AB كأطول سلسلة صالحة حاليًا.
ومع ذلك ، لا يمكن لأي مشارك التحقق من صحة جميع المعاملات على جميع القطع في كتلة سلسلة مظللة ، لذلك يجب أن يكون لديهم طريقة لتأكيد أنه لم يتم تضمين أي كتلة غير صالحة في أي وقت من الأوقات في تاريخ أي قطعة من كتلة blockchain.
لاحظ أنه على عكس الشوكة ، فإن الارتباط المتقاطع بسلسلة Beacon ليس حلاً كافيًا ، لأن سلسلة Beacon لا تملك القدرة على التحقق من الكتل. يمكن أن يتحقق فقط من أن عددًا كافيًا من المدققين في هذا القشرة قد وقّع الكتلة (وعلى هذا النحو يشهد على صحتها).
إنني على دراية بحلّين فقط لهذه المشكلة ، أي منهما غير مرضٍ حقًا اليوم:
- لديك بعض الآلية المعقولة التي سوف تنبه النظام إذا تم إجراء محاولة لتطبيق انتقال الحالة بشكل غير صحيح. على افتراض أن كل قشرة تقوم بتشغيل نوع من إجماع BFT ، طالما أن عدد المدققين الضارين في قشرة معينة أقل من ⅔ ، فسوف يحتاج مدقق صادق واحد على الأقل إلى التصديق على كتلة ، والتحقق من أن وظيفة انتقال الحالة هي تطبق بشكل صحيح. إذا كانت أكثر من ⅔ من العقد ضارة ، فيمكنها إنهاء كتلة دون مشاركة عقدة صادقة واحدة. على افتراض أن عقدة واحدة على الأقل في الحشرة ليست ضارة ، هناك حاجة إلى آلية تسمح لهذه العقد بمراقبة الكتل التي يتم إنتاجها ، ولديها الوقت الكافي لتحدي العقد ذات الانتقال غير الصحيح للحالة.
- لديك بعض المعلومات في الكتل الكافية لإثبات أن انتقال الحالة يتم تطبيقه بشكل صحيح ولكن أرخص بشكل كبير للتحقق من التطبيق الفعلي لوظيفة انتقال الحالة. إن أقرب آلية لتحقيق ذلك هي zk-SNARKs (على الرغم من أننا لسنا بحاجة حقًا إلى "zk" ، أو المعرفة الصفرية ، فإن SNARK غير zk سيكون كافيًا) ، لكن zk-SNARK يكون بطيئًا في حسابه على هذه النقطة.
تفترض العديد من البروتوكولات اليوم أنه مع الدوران الصحيح للمصادقة والإجماع البيزنطي المتسامح للخطأ ، لا الشوكات ولا التحولات غير الصحيحة للدولة ممكنة. السبب وراء هذا الافتراض غير المعقول هو موضوع لمقال منفصل.
Outro
أكتب كثيرًا عن البلوكات والمشارب ، ولدينا أيضًا سلسلة من مقاطع الفيديو حيث نتحدث إلى مؤسسي البروتوكولات القابلة للتطوير ، مثل Cosmos و Solana ، من خلال الغوص العميق في التكنولوجيا. يمكنك متابعتي على تويتر هنا .