أساسيات المشاركة

لنبدأ بأبسط طريقة للمشاركة. في هذا النهج بدلا من بتشغيل blockchain واحد، سنقوم بتشغيل عدة، ونستدعي كل منها blockchain a "الشظية". سيكون لكل جزء مجموعته الخاصة من validators. هنا وأدناه نستخدم مصطلح عام "validator" للإشارة إلى المشاركين الذين يتحققون من المعاملات و إنتاج الكتل، إما عن طريق التعدين، كما هو الحال في إثبات العمل، أو عن طريق التصويت على أساس 1تم نشر هذا القسم مسبقًا في https://near.ai/shard1. إذا قرأته من قبل، انتقل إلى القسم التالي.

آلية. لنفترض الآن أن القطع لا تتواصل مع بعضها أبدًا أخرى. هذا التصميم، على الرغم من بساطته، يكفي لتوضيح بعض التحديات الرئيسية الأولية في التقسيم. 1.1 تقسيم المدقق وسلاسل المنارة لنفترض أن النظام يتكون من 10 أجزاء. التحدي الأول هو أنه مع كل منهما الجزء الذي يحتوي على validators خاص به، أصبح كل جزء الآن أقل أمانًا بعشر مرات من الجزء السلسلة بأكملها. لذا، إذا قررت سلسلة غير مجزأة تحتوي على X validators إجراء عملية الانقسام الكلي إلى سلسلة مجزأة، وتقسم X validators عبر 10 أجزاء، كل جزء الآن يحتوي فقط على X/10 validators، وإفساد جزء واحد يتطلب إفسادًا فقط 5.1% (51% / 10) من إجمالي عدد validators (انظر الشكل 1)، الشكل 1: تقسيم validators عبر الأجزاء وهو ما يقودنا إلى النقطة الثانية: من يختار validators لكل جزء؟ إن التحكم في 5.1% من validators يكون ضارًا فقط إذا كانت كل تلك الـ 5.1% من validators هم في نفس القشرة. إذا لم يتمكن validators من اختيار الجزء الذي يمكنهم التحقق من صحته في، من غير المرجح أن يحصل المشارك الذي يتحكم في 5.1% من validators على كل شيء validators في نفس القطعة، مما يقلل بشكل كبير من قدرتهم على التسوية النظام. تعتمد جميع تصميمات التجزئة تقريبًا اليوم على بعض مصادر العشوائية قم بتعيين validators إلى الأجزاء. تعتبر العشوائية في blockchain في حد ذاتها موضوعًا صعبًا للغاية وهي خارج نطاق هذه الوثيقة. الآن دعونا نفترض أن هناك بعض مصادر العشوائية التي يمكننا استخدامها. سوف نقوم بتغطية مهمة validators في مزيد من التفاصيل في القسم 2.1. تتطلب كل من العشوائية والتخصيص validator حسابًا ليس كذلك خاص بأي شريحة معينة. لهذا الحساب، عمليا كل الموجود تحتوي التصميمات على blockchain منفصل مكلف بتنفيذ العمليات اللازمة لصيانة الشبكة بأكملها. إلى جانب توليد عشوائيالأرقام وتعيين validators للأجزاء، غالبًا ما تكون هذه العمليات أيضًا تتضمن تلقي التحديثات من الأجزاء والتقاط لقطات منها ومعالجتها الرهانات والتخفيض في أنظمة إثبات الحصة، وإعادة موازنة القطع عند ذلك الميزة مدعومة. تسمى هذه السلسلة بسلسلة المنارة في Ethereum، وهي مرحل السلسلة في PolkaDot، والمركز Cosmos في Cosmos. في جميع أنحاء هذه الوثيقة سوف نشير إلى هذه السلسلة باسم سلسلة المنارة. يقودنا وجود سلسلة Beacon إلى الموضوع التالي المثير للاهتمام، وهو تقسيم تربيعي. 1.2 التقسيم التربيعي غالبًا ما يتم الإعلان عن المشاركة كحل يتسع بشكل لا نهائي مع العدد من العقد المشاركة في تشغيل الشبكة. في حين أنه من الناحية النظرية ممكن تصميم مثل هذا الحل للمشاركة، أي حل يحتوي على مفهوم المنارة السلسلة ليس لديها قابلية التوسع اللانهائية. لفهم السبب، لاحظ أن المنارة يتعين على السلسلة إجراء بعض العمليات الحسابية المحاسبية، مثل تعيين validators إلى القطع، أو قطع سلسلة القطع، التي تتناسب مع العدد من الشظايا في النظام. نظرًا لأن سلسلة Beacon هي نفسها blockchain واحدة، مع الحساب يحده القدرات الحسابية للعقد التي تعمل عليه، عدد القطع محدود بشكل طبيعي. ومع ذلك، فإن بنية الشبكة المجزأة تمنح عملية مضاعفة التأثير على أي تحسينات على العقد الخاصة به. النظر في الحالة التي يكون فيها التعسفي يتم إجراء تحسين على كفاءة العقد في الشبكة مما سيسمح بذلك لهم أوقات معالجة المعاملات أسرع. إذا كانت العقد التي تقوم بتشغيل الشبكة، بما في ذلك العقد الموجودة في سلسلة المنارة، تصبح أسرع بأربع مرات، فستكون كل قطعة قادرة على المعالجة أربع مرات أكثر المعاملات، وستكون سلسلة المنارة قادرة على الحفاظ على شظايا أكثر بأربعة أضعاف. ستزداد الإنتاجية عبر النظام بعامل 4 × 4 = 16 - ومن هنا جاء اسم التقسيم التربيعي. من الصعب توفير قياس دقيق لعدد الشظايا قابلة للحياة اليوم، ولكن من غير المرجح أن في أي المستقبل المنظور الإنتاجية سوف تتجاوز احتياجات مستخدمي blockchain قيود التقسيم التربيعي. العدد الهائل من العقد اللازمة لتشغيل مثل هذا الحجم من القطع بشكل آمن من المحتمل أن يكون حجمها أعلى من عدد العقد التي تعمل جميعها blockchains مجتمعة اليوم. 1.3 تقسيم الدولة حتى الآن لم نحدد بشكل جيد ما هو منفصل وما هو غير منفصل عندما يتم تقسيم الشبكة إلى أجزاء. على وجه التحديد، العقد الموجودة في blockchain أداء ثلاث مهام مهمة: لا يقومون فقط بـ 1) معالجة المعاملات، بل يقومون أيضًا أيضًا 2) ترحيل المعاملات التي تم التحقق منها والكتل المكتملة إلى العقد الأخرى و3) تخزين حالة وتاريخ دفتر أستاذ الشبكة بالكامل. كل واحد من هؤلاء الثلاثة تفرض المهام متطلبات متزايدة على العقد التي تقوم بتشغيل الشبكة:1. تتطلب ضرورة معالجة المعاملات المزيد من القوة الحاسوبية زيادة عدد المعاملات التي تتم معالجتها؛ 2. تتطلب ضرورة ترحيل المعاملات والكتل مزيدًا من النطاق الترددي للشبكة مع زيادة عدد المعاملات التي يتم ترحيلها؛ 3. ضرورة تخزين البيانات تتطلب المزيد من التخزين مع نمو الدولة. الأهم من ذلك، على عكس قوة المعالجة والشبكة، فإن متطلبات التخزين تنمو حتى لو كان معدل المعاملة (عدد المعاملات التي تمت معالجتها). في الثانية) يظل ثابتًا. من القائمة أعلاه قد يبدو أن متطلبات التخزين ستكون كذلك والأكثر إلحاحا، لأنه الوحيد الذي يتزايد مع مرور الوقت حتى لو لم يتغير عدد المعاملات في الثانية، ولكن في الممارسة العملية الشرط الأكثر إلحاحا اليوم هو قوة الحوسبة. الدولة بأكملها Ethereum حتى كتابة هذه السطور تبلغ 100 جيجابايت، ويمكن التحكم فيها بسهولة بواسطة معظم العقد. لكن عدد المعاملات التي يمكن لـ Ethereum معالجتها يبلغ حوالي 20 ألف طلب حجمها أقل مما هو مطلوب في العديد من حالات الاستخدام العملي. Zilliqa هو المشروع الأكثر شهرة الذي يقوم بمعالجة القطع وليس التخزين. تعد عملية تقاسم المعالجة مشكلة أسهل لأن كل عقدة تحتوي على كامل المعالجة State، مما يعني أنه يمكن للعقود استدعاء العقود الأخرى بحرية وقراءة أي بيانات من blockchain. هناك حاجة إلى بعض الهندسة الدقيقة للتأكد من التحديثات من شظايا متعددة تحديث نفس الأجزاء من الدولة لا تتعارض. في فيما يتعلق بهذه الأمور، تتخذ Zilliqa نهجًا مبسطًا نسبيًا. في حين تم اقتراح تقسيم التخزين دون تقسيم المعالجة، فهو كذلك غير شائع للغاية. وبالتالي، في الممارسة العملية، تقاسم التخزين، أو تقاسم الدولة، يعني دائمًا تقريبًا تقسيم المعالجة وتقسيم الشبكة. من الناحية العملية، في ظل تقسيم الحالة، تقوم العقد الموجودة في كل جزء ببناء عقدها الخاصة الخاص blockchain الذي يحتوي على المعاملات التي تؤثر فقط على الجزء المحلي من الحالة العالمية المخصصة لتلك القطعة. ولذلك، فإن validators في تحتاج Shard فقط إلى تخزين الجزء المحلي الخاص بها من الحالة العالمية وتنفيذها فقط، وعلى هذا النحو فقط يقومون بترحيل المعاملات التي تؤثر على الجزء الخاص بهم من الدولة. هذا يعمل التقسيم خطيًا على تقليل المتطلبات على جميع طاقة الحوسبة والتخزين و عرض النطاق الترددي للشبكة، ولكنه يقدم مشاكل جديدة، مثل توفر البيانات و المعاملات المتقاطعة، والتي سنغطيها أدناه. 1.4 المعاملات المتقاطعة نموذج التجزئة الذي وصفناه حتى الآن ليس مفيدًا جدًا، لأنه إذا كان فرديًا لا تستطيع الشظايا التواصل مع بعضها البعض، فهي ليست أفضل من المتعددة مستقل blockchains. حتى اليوم، عندما لا تكون المشاركة متاحة، هناك الطلب الكبير على قابلية التشغيل البيني بين مختلف blockchains. دعونا الآن نفكر فقط في معاملات الدفع البسيطة، حيث يكون لكل مشارك حساب في جزء واحد بالضبط. إذا كان أحد يرغب في تحويل الأموال من 2يمكن العثور على تحليلنا لنهجهم هنا: https://medium.com/nearprotocol/ 8f9efae0ce3bمن حساب إلى آخر ضمن نفس الجزء، يمكن معالجة المعاملة بالكامل بواسطة validators في تلك القطعة. ومع ذلك، إذا كانت أليس تسكن على القشرة يريد رقم 1 إرسال أموال إلى بوب الذي يقيم في الجزء رقم 2، وليس validators في الجزء رقم 1 (لن يتمكنوا من إضافة حساب بوب) ولا validators على يمكن للجزء رقم 2 (لن يتمكنوا من الخصم من حساب أليس) معالجة العملية بالكامل معاملة. هناك مجموعتان من أساليب التعامل مع المعاملات المتقاطعة: • متزامن: عندما يلزم تنفيذ معاملة متقاطعة، الكتل الموجودة في أجزاء متعددة تحتوي على انتقال الحالة المتعلق بـ يتم إنتاج جميع المعاملات في نفس الوقت، وتتعاون validators من الأجزاء المتعددة في تنفيذ مثل هذه المعاملات.3 • غير متزامن: معاملة متقاطعة تؤثر على أجزاء متعددة يتم تنفيذه في تلك الأجزاء بشكل غير متزامن، ويتم تنفيذ جزء "الائتمان". نصفها بمجرد أن يكون لديها أدلة كافية على أن الجزء "المدين" قد نفذ نصيبه. يميل هذا النهج إلى أن يكون أكثر انتشارًا نظرًا لخصائصه البساطة وسهولة التنسيق. يُقترح هذا النظام اليوم في Cosmos، Ethereum Serenity، Near، Kadena، وغيرها. مشكلة في هذا يكمن النهج في أنه إذا تم إنتاج الكتل بشكل مستقل، فهناك فرصة غير صفرية لأن تصبح إحدى الكتل المتعددة معزولة، مما يجعل تم تطبيق المعاملة جزئيًا فقط. خذ بعين الاعتبار الشكل 2 الذي يصور اثنين واجه كلاهما شوكة ومعاملة متقاطعة التي تم تسجيلها في الكتلتين A وX على التوالي. إذا كانت السلاسل A-B وV'-X'-Y'-Z' ينتهي بهما الأمر إلى أن يكونا أساسيين في الأجزاء المقابلة، the تم الانتهاء من الصفقة بالكامل. إذا أصبح A'-B'-C'-D' وV-X أساسيين، ومن ثم يتم التخلي عن المعاملة بالكامل، وهو أمر مقبول. ولكن إذا، ل على سبيل المثال، تصبح A-B وV-X أساسية، ثم يتم الانتهاء من جزء واحد من المعاملة ويتم التخلي عن جزء آخر، مما يؤدي إلى فشل ذري. نحن سوف يغطي كيفية معالجة هذه المشكلة في البروتوكولات المقترحة في الجزء الثاني، عند تغطية التغييرات في قواعد اختيار الشوكة والإجماع الخوارزميات المقترحة للبروتوكولات المجزأة. لاحظ أن الاتصال بين السلاسل مفيد خارج blockchains المقسمة أيضا. تعد إمكانية التشغيل البيني بين السلاسل مشكلة معقدة تواجهها العديد من المشاريع يحاولون حل. في blockchains المشكلة أسهل إلى حد ما منذ ذلك الحين هيكل الكتلة والإجماع متماثلان عبر الأجزاء، وهناك سلسلة إشارات يمكن استخدامها للتنسيق. ومع ذلك، في blockchain مجزأة، جميع سلاسل الأجزاء هي نفسها، بينما في النظام البيئي العالمي blockchains هناك هناك الكثير من blockchains، مع حالات استخدام مستهدفة مختلفة، واللامركزية وضمانات الخصوصية. بناء نظام تكون فيه مجموعة من السلاسل لها خصائص مختلفة ولكن استخدام إجماع وبنية كتلة متماثلين بدرجة كافية والحصول على سلسلة إشارات مشتركة يمكن أن تمكن نظامًا بيئيًا من blockchains غير المتجانسة التي لها 3ال معظم مفصلة اقتراح معروف ل ال المؤلفين من هذا وثيقة هو دمج كتل، الموصوفة هنا: https://ethresear.ch/t/ دمج الكتل والتزامن عبر تنفيذ الحالة / 1240الشكل 2: المعاملات المتقاطعة غير المتزامنة العمل على النظام الفرعي للتشغيل البيني. من غير المحتمل أن يتميز مثل هذا النظام بالتناوب validator، لذا يلزم اتخاذ بعض الإجراءات الإضافية لضمان الأمان. كلاهما Cosmos وPolkaDot هما من هذه الأنظمة بشكل فعال4 1.5 السلوك الضار سنراجع في هذا القسم السلوك العدائي الذي يمكن أن يكون ضارًا لـ validators ممارسة إذا تمكنوا من إفساد شظية. سنراجع الأساليب الكلاسيكية لتجنب إتلاف القطع في القسم 2.1. 1.5.1 شوكات ضارة قد تحاول مجموعة من validators الضارة إنشاء تفرع. لاحظ أنه لا لا يهم إذا كان الإجماع الأساسي هو BFT أم لا، مما يؤدي إلى إفساد العدد الكافي من validators سيجعل من الممكن دائمًا إنشاء شوكة. من المرجح بشكل كبير أن يفسد أكثر من 50% من جزء واحد، أكثر من أن يفسد أكثر من 50% من الشبكة بأكملها (سنقوم بذلك) تعمق أكثر في هذه الاحتمالات في القسم 2.1). كما تمت مناقشته في القسم 1.4، تتضمن المعاملات المتقاطعة تغييرات معينة في الحالة في أجزاء متعددة، و يجب أن تكون الكتل المقابلة في هذه القطع التي تطبق مثل هذه التغييرات في الحالة إما أن يتم الانتهاء منها جميعًا (أي تظهر في السلاسل المحددة في السلاسل المقابلة لها القطع)، أو تكون جميعها يتيمة (أي لا تظهر في السلاسل المحددة على القطع المقابلة لها). منذ عموما احتمال تلف القطع 4 ارجع إلى هذه الكتابة التي كتبها زكي مانيان من Cosmos: https://forum.cosmos.network/ t/polkadot-vs-cosmos/1397/2 وهذه العاصفة من التغريدات التي كتبها المؤلف الأول لهذه الوثيقة: https://twitter.com/AlexSkidanov/status/1129511266660126720 للحصول على مقارنة تفصيلية من الاثنين

لا يمكن إهمالها، فلا يمكننا أن نفترض أن التشعبات لن تحدث حتى لو تم التوصل إلى إجماع بيزنطي بين الكسور validators، أو تم إنشاء العديد من الكتل أنتجت على رأس الكتلة مع تغيير الحالة. لهذه المشكلة حلول متعددة، وأكثرها شيوعًا هو الحلول العرضية الربط المتبادل لأحدث كتلة سلسلة شظية بسلسلة المنارة. الشوكة يتم بعد ذلك تغيير قاعدة الاختيار في سلاسل القطع لتفضل دائمًا السلسلة الموجودة مرتبطة بشكل متقاطع، ولا تطبق إلا قاعدة اختيار الشوكة الخاصة بالكتل التي كانت تم نشره منذ آخر رابط متقاطع. 1.5.2 الموافقة على الكتل غير الصالحة قد تحاول مجموعة من validators إنشاء كتلة تطبق وظيفة انتقال الحالة بشكل غير صحيح. على سبيل المثال، البدء بالحالة التي تكون فيها أليس لديه 10 tokens وBob لديه 0 tokens، قد تحتوي الكتلة على معاملة يرسل 10 tokens من أليس إلى بوب، لكنه ينتهي بحالة تكون فيها أليس 0 tokens وبوب لديه 1000 tokens، كما هو موضح في الشكل 3. الشكل 3: مثال على كتلة غير صالحة في blockchain الكلاسيكية غير المجزأة، مثل هذا الهجوم غير ممكن، لأن كل شيء يقوم المشارك في الشبكة بالتحقق من صحة جميع الكتل، والكتلة بها سيتم رفض انتقال الحالة غير الصالح من قبل منتجي الكتل الآخرين و المشاركون في الشبكة الذين لا يقومون بإنشاء كتل. حتى لو كانت خبيثة يستمر validators في إنشاء الكتل فوق هذه الكتلة غير الصالحة بشكل أسرع من يقوم validators الصادقون ببناء السلسلة الصحيحة، وبالتالي الحصول على السلسلة مع غير الصالح كون الكتلة أطول، لا يهم، لأن كل مشارك يستخدم blockchain لأي غرض من الأغراض يتحقق من صحة كافة الكتل، ويتجاهل كافة الكتل بنيت على رأس كتلة غير صالحة. في الشكل 4 يوجد خمسة validator، ثلاثة منها خبيثة. هم أنشأنا كتلة غير صالحة "أ"، ثم واصلنا بناء كتل جديدة في الأعلى منه. تم تجاهل اثنين من validators الصادقين A' باعتباره غير صالح وكانا يبنيان في الأعلىالشكل 4: محاولة إنشاء كتلة غير صالحة في blockchain غير مقسمة من آخر كتلة صالحة معروفة لهم، مما أدى إلى إنشاء شوكة. نظرًا لوجود عدد أقل validators في الشوكة الصادقة سلسلتهم أقصر. ومع ذلك، في blockchain الكلاسيكي غير المقسم، كل مشارك يستخدم blockchain لأي غرض هو مسؤول عن التحقق من صحة جميع الكتل التي يتلقونها وإعادة حساب الحالة. وبالتالي فإن أي شخص لديه أي مصلحة في blockchain سوف يلاحظ أن "أ" غير صالح، وبالتالي أيضًا تجاهل B' وC' وD' على الفور، على هذا النحو مع أخذ السلسلة A-B هي أطول سلسلة صالحة حاليًا. ومع ذلك، في blockchain المجزأة، لا يستطيع أي مشارك التحقق من صحة جميع المعاملات على جميع الأجزاء، لذلك يحتاجون إلى طريقة ما لتأكيد ذلك نقطة في تاريخ أي جزء من blockchain لم يتم تضمين كتلة غير صالحة. لاحظ أنه على عكس الشوكات، فإن الارتباط المتبادل بسلسلة Beacon ليس حلاً كافيًا، نظرًا لأن سلسلة Beacon لا تتمتع بالقدرة على التحقق من صحة كتل. يمكنها فقط التحقق من وجود عدد كافٍ من validators في تلك القطعة وقع على الكتلة (وبالتالي يشهد على صحتها). سنناقش حلول هذه المشكلة في القسم 2.2 أدناه.

صحة الدولة وتوافر البيانات

الفكرة الأساسية في blockchains المجزأة هي أن معظم المشاركين يعملون أو لا يمكن باستخدام الشبكة التحقق من صحة الكتل في جميع الأجزاء. على هذا النحو، كلما يحتاج أي مشارك إلى التفاعل مع جزء معين لا يستطيع ذلك بشكل عام قم بتنزيل السجل الكامل للجزء والتحقق من صحته. ومع ذلك، فإن جانب التقسيم في التقسيم يثير إمكانات كبيرة المشكلة: دون تنزيل السجل الكامل لملف معين والتحقق من صحته لا يمكن بالضرورة أن يكون المشارك على يقين من أن الحالة التي معه 5تم نشر هذا القسم، باستثناء القسم الفرعي 2.5.3، مسبقًا في https://near.ai/ شارد2. إذا قرأته من قبل، فانتقل إلى القسم التالي.

تفاعلهم هو نتيجة لبعض التسلسل الصحيح للكتل وهذا التسلسل من الكتل هي في الواقع السلسلة الأساسية في القشرة. مشكلة لا موجودة في blockchain غير مجزأة. سنقدم أولاً حلاً بسيطًا لهذه المشكلة التي تم اقتراحها بواسطة العديد من البروتوكولات ثم قم بتحليل كيف يمكن أن ينكسر هذا الحل وماذا وقد بذلت محاولات لمعالجتها. 2.1 تناوب المدققين يظهر الحل الساذج لصلاحية الحالة في الشكل 5: لنفترض أننا نفترض أن النظام بأكمله يحتوي على آلاف validators، منها ما لا يزيد عن 20% منها تكون ضارة أو ستفشل (مثل الفشل في أن تكون عبر الإنترنت لإنتاج كتلة). ثم إذا أخذنا عينة من 200 validators، فإن الاحتمال من أكثر من 1 3 يمكن افتراض أن الفشل للأغراض العملية هو صفر. الشكل 5: أخذ العينات validators 1 3 عتبة مهمة. هناك عائلة من بروتوكولات الإجماع تسمى BFT بروتوكولات الإجماع، التي تضمن ذلك لمدة تقل عن 1 3 من يفشل المشاركون، إما عن طريق الانهيار أو عن طريق التصرف بطريقة تنتهك قواعد اللعبة البروتوكول، سيتم التوصل إلى توافق في الآراء. مع هذا الافتراض بنسبة validator الصادقة، إذا كانت المجموعة الحالية من validators في الجزء يزودنا ببعض الكتل، كما يفترض الحل الساذج أن الكتلة صالحة وأنها مبنية على ما يعتقده validators السلسلة الأساسية لتلك القطعة عندما بدأوا في التحقق من صحتها. validators تعلمت السلسلة الأساسية من المجموعة السابقة من validators، والتي بنفس الطريقة تم بناء الافتراض فوق الكتلة التي كانت رأس السلسلة القانونية قبل ذلك. عن طريق الاستقراء تكون السلسلة بأكملها صالحة، وبما أنه لا توجد مجموعة من validators في أي لحظة أنتجت الشوك، والحل الساذج هو أيضا على يقين من أن التيار السلسلة هي السلسلة الوحيدة في القشرة. انظر الشكل 6 للتصور.

الشكل 6: blockchain مع الانتهاء من كل كتلة من خلال إجماع BFT هذا الحل البسيط لا يعمل إذا افترضنا أن validators يمكن أن يكون كذلك تالف بشكل تكيفي، وهو ليس افتراضًا غير معقول. بشكل تكيفي إن إفساد جزء واحد في نظام يحتوي على 1000 جزء يعد أرخص بكثير بدلاً من إفساد النظام بأكمله. ولذلك، فإن أمان البروتوكول يتناقص خطيًا مع عدد الأجزاء. أن يكون على يقين من صحة كتلة، يجب أن نعرف أنه في أي وقت من التاريخ لم يحدث أي شظية في النظام أغلبية validators تتواطأ؛ مع الخصوم التكيفيين، لم يعد لدينا مثل هذا اليقين. كما ناقشنا في القسم 1.5، يمكن أن يكون التواطؤ validator أمرًا فعالاً هناك سلوكان خبيثان أساسيان: إنشاء تشعبات وإنتاج كتل غير صالحة. يمكن معالجة التشعبات الضارة من خلال ربط الكتل بسلسلة Beacon المصممة بشكل عام لتكون ذات مستوى أمان أعلى بكثير من تلك الموجودة في سلسلة Beacon. سلاسل القشرة. ومع ذلك، فإن إنتاج كتل غير صالحة يعد أمرًا أكثر أهمية مشكلة صعبة لمعالجة. 2.2 صلاحية الدولة خذ بعين الاعتبار الشكل 7 الذي تظهر فيه القطعة رقم 1 تالفة وينتجها ممثل خبيث الكتلة غير الصالحة B. لنفترض في هذه الكتلة B أنه تم سك 1000 tokens من الرقاقة الهواء على حساب أليس. يقوم الممثل الخبيث بعد ذلك بإنتاج كتلة C صالحة (في ملف بمعنى أن المعاملات في C يتم تطبيقها بشكل صحيح) أعلى B، مما يؤدي إلى التشويش الكتلة B غير الصالحة، وتبدأ معاملة مشتركة للجزء رقم 2 ينقل تلك الـ 1000 tokens إلى حساب بوب. من هذه اللحظة بشكل غير صحيح تم إنشاء tokens على blockchain صالح تمامًا بخلاف ذلك في الجزء رقم 2. بعض الطرق البسيطة لمعالجة هذه المشكلة هي: 6اقرأ هذا مقالة ل التفاصيل على كيف التكيف الفساد يمكن يكون نفذت خارج: https://medium.com/nearprotocol/d859adb464c8. ل المزيد التفاصيل على التكيف الفساد, قراءة https://github.com/ethereum/wiki/wiki/Sharding-FAQ# ما هي نماذج الأمان التي نعمل بموجبها؟الشكل 7: معاملة مشتركة من سلسلة تحتوي على كتلة غير صالحة 1. بالنسبة إلى validators من الجزء رقم 2 للتحقق من صحة الكتلة التي يتم منها المعاملة بدأ. لن ينجح هذا حتى في المثال أعلاه، نظرًا لأن الكتلة C يبدو أنه صالح تماما. 2. بالنسبة لـ validators في الجزء رقم 2 للتحقق من صحة عدد كبير من الكتل التي تسبق الكتلة التي تبدأ منها المعاملة. بطبيعة الحال، ل أي عدد من الكتل N التي تم التحقق من صحتها بواسطة الجزء المتلقي الخبيث يمكن لـ validators إنشاء كتل صالحة N+1 أعلى الكتلة غير الصالحة أنتجت. قد تكون الفكرة الواعدة لحل هذه المشكلة هي ترتيب القطع في ملف رسم بياني غير موجه حيث ترتبط كل قطعة بعدة أجزاء أخرى، و السماح فقط بالمعاملات المتقاطعة بين الأجزاء المجاورة (على سبيل المثال، هذه هي الطريقة إن عملية التقسيم التي اقترحها فلاد زامفير تعمل بشكل أساسي7، كما تم استخدام فكرة مماثلة في فكرة كادينا تشينويب [1]). إذا كانت هناك حاجة إلى معاملة متقاطعة بين الأجزاء الموجودة وليس الجيران، يتم توجيه هذه المعاملة من خلال أجزاء متعددة. في هذا التصميم من المتوقع أن يقوم validator في كل جزء بالتحقق من صحة كل الكتل الموجودة في الجزء الخاص بهم وكذلك جميع الكتل في جميع القطع المجاورة. النظر في الشكل أدناه مع 10 شظايا، لكل منها أربعة جيران، ولا تتطلب شظيتين أكثر أكثر من قفزتين للاتصال المتقاطع الموضح في الشكل 8. لا تقوم القطعة رقم 2 بالتحقق من صحة blockchain الخاصة بها فحسب، بل أيضًا blockchains الخاصة بها جميع الجيران، بما في ذلك الشارد رقم 1. فإذا كان فاعل خبيث على الكسرة رقم 1 يحاول إنشاء كتلة B غير صالحة، ثم بناء الكتلة C فوقها وبدء معاملة القطع المتقاطعة، لن تتم مثل هذه المعاملة المتقاطعة من خلال الجزء رقم 2 سيكون قد تم التحقق من صحة تاريخ الجزء رقم 1 بأكمله والذي سيؤدي ذلك إلى تحديد الكتلة غير الصالحة B. 7 اقرأ المزيد عن التصميم هنا: https://medium.com/nearprotocol/37e538177ed9

الشكل 8: معاملة متقاطعة غير صالحة في نظام يشبه شبكة الويب من شأنه أن الحصول على الكشف عنها على الرغم من أن إتلاف جزء واحد لم يعد هجومًا قابلاً للتطبيق، إلا أن إتلاف ملف تبقى شظايا قليلة مشكلة. في الشكل 9، هناك خصم يفسد كلاً من الشارد نجح #1 وShard #2 في تنفيذ معاملة مشتركة إلى Shard #3 بأموال من الكتلة B غير الصالحة: الشكل 9: معاملة متقاطعة غير صالحة في نظام يشبه شبكة الويب من شأنه أن لا يتم الكشف عنها الجزء رقم 3 يتحقق من صحة جميع الكتل في الجزء رقم 2، ولكن ليس في الجزء رقم 1، و ليس لديه طريقة للكشف عن الكتلة الضارة. هناك اتجاهان رئيسيان لحل مشكلة صلاحية الدولة بشكل صحيح: الصيادون

والبراهين التشفيرية للحساب. 2.3 صياد الفكرة وراء النهج الأول هي ما يلي: كلما كان رأس الكتلة يتم توصيله بين السلاسل لأي غرض (مثل الارتباط المتبادل بـ سلسلة منارات، أو معاملة متقاطعة)، هناك فترة زمنية خلالها والتي يمكن لأي validator صادق أن يقدم دليلاً على أن الكتلة غير صالحة. هناك هي إنشاءات مختلفة توفر أدلة موجزة للغاية على وجود الكتل غير صالح، وبالتالي فإن حمل الاتصالات للعقد المستقبلة يكون أصغر بكثير من الحصول على كتلة كاملة. مع هذا النهج طالما أن هناك على الأقل validator صادقًا واحدًا في شارد، النظام آمن. الشكل 10: صياد وهذا هو النهج السائد (إلى جانب التظاهر بعدم وجود المشكلة) بين البروتوكولات المقترحة اليوم. ومع ذلك، فإن هذا النهج له طريقتان العيوب الرئيسية: 1. يجب أن تكون فترة التحدي طويلة بما فيه الكفاية للصادق validator للتعرف على الكتلة التي تم إنتاجها، قم بتنزيلها والتحقق منها بالكامل والاستعداد التحدي إذا كانت الكتلة غير صالحة. إدخال مثل هذه الفترة سيكون إبطاء المعاملات المتقاطعة بشكل كبير. 2. إن وجود بروتوكول التحدي يخلق ناقلًا جديدًا للهجمات عندما ترسل العقد الضارة رسائل غير مرغوب فيها باختبارات غير صالحة. حل واضح لحل هذه المشكلة هو جعل المنافسين يودعون مبلغًا قدره tokens يتم إرجاعها إذا كان التحدي صالحًا. وهذا ليس سوى حل جزئي، كما هو الحال قد يكون من المفيد للخصم أن يرسل بريدًا عشوائيًا إلى النظام (ويحرق ملفات الودائع) مع الطعون الباطلة، على سبيل المثال لمنع صالحةتحدي من validator صادق من المرور. هذه الهجمات تسمى هجمات الحزن. انظر القسم 3.7.2 لمعرفة طريقة للالتفاف على النقطة الأخيرة. 2.4 حجج المعرفة غير التفاعلية المختصرة الحل الثاني لفساد الأجزاء المتعددة هو استخدام نوع ما من بنيات التشفير التي تسمح للشخص بإثبات أن عملية حسابية معينة (مثل (مثل حساب كتلة من مجموعة من المعاملات) تم تنفيذها بشكل صحيح. مثل هذه الإنشاءات موجودة بالفعل، على سبيل المثال. zk-SNARKs، zk-STARKs وعدد قليل من الآخرين، ويتم استخدام بعضها بشكل نشط في بروتوكولات blockchain اليوم للمدفوعات الخاصة، وأبرزها ZCash. المشكلة الأساسية مع هؤلاء البدائيين هي أنهم من المعروف أنها بطيئة في الحساب. على سبيل المثال. بروتوكول Coda، الذي يستخدم zk-SNARKs على وجه التحديد لإثبات أن جميع الكتل الموجودة في blockchain صالحة، قيل في أحد من المقابلات أن الأمر قد يستغرق 30 ثانية لكل معاملة لإنشاء دليل (ربما يكون هذا الرقم أصغر الآن). ومن المثير للاهتمام أن الدليل لا يحتاج إلى حساب من قبل طرف موثوق به، منذ ذلك الحين لا يشهد الدليل على صحة الحساب الذي بني من أجله فحسب، بل يشهد أيضًا على صحة الدليل نفسه. وبالتالي، يمكن تقسيم حساب هذه البراهين بين مجموعة من المشاركين الذين لديهم تكرار أقل بكثير مما سيكون عليه الحال اللازمة لإجراء بعض الحسابات غير الموثوق بها. كما يسمح للمشاركين الذين يحسبون zk-SNARKs للتشغيل على أجهزة خاصة دون تقليل اللامركزية في النظام. تحديات zk-SNARKs، إلى جانب الأداء، هي: 1. الاعتماد على أساسيات التشفير الأقل بحثًا واختبارها على مر الزمن؛ 2. "النفايات السامة" - تعتمد zk-SNARKs على إعداد موثوق فيه مجموعة من الأشخاص يقومون ببعض العمليات الحسابية ثم يتجاهلون الوسيط قيم هذا الحساب. إذا تواطأ جميع المشاركين في الإجراء والحفاظ على القيم المتوسطة، يمكن إنشاء أدلة وهمية؛ 3. تعقيد إضافي تم إدخاله في تصميم النظام؛ 4. تعمل zk-SNARKs فقط مع مجموعة فرعية من الحسابات المحتملة، وبالتالي البروتوكول مع لغة Turing-Complete smart contract لن يكون من الممكن استخدامها SNARKs لإثبات صحة السلسلة. 2.5 توفر البيانات المشكلة الثانية التي سنتطرق إليها هي توفر البيانات. العقد عموما يتم فصل تشغيل blockchain معين إلى مجموعتين: العقد الكاملة، تلك التي تقوم بتنزيل كل كتلة كاملة والتحقق من صحة كل معاملة، وLight العقد، تلك التي تقوم فقط بتنزيل رؤوس الكتل، وتستخدم إثباتات Merkle للأجزاء للدولة والمعاملات التي يهتمون بها، كما هو مبين في الشكل 11.

الشكل 11: شجرة ميركل الآن، إذا تواطأت غالبية العقد الكاملة، فيمكنها إنتاج كتلة صالحة أو غير صالح، وأرسل hash إلى العقد الخفيفة، ولكن لا تكشف مطلقًا عن المحتوى الكامل من الكتلة. هناك طرق مختلفة يمكنهم الاستفادة منها. على سبيل المثال، النظر في الشكل 12: الشكل 12: مشكلة توفر البيانات هناك ثلاث كتل: السابقة، A، تم إنتاجها بواسطة validators الصادق؛ التيار، B، لديه validators متواطئ؛ وسيتم أيضًا إنتاج المنتج التالي، C بواسطة validators الصادق (تم توضيح blockchain في الزاوية اليمنى السفلية). أنت تاجر. تم استلام الكتلة validators للكتلة الحالية (B). A من validators السابقة، قامت بحساب الكتلة التي تتلقى فيها الأموال،وأرسلت لك رأسًا لتلك الكتلة مع إثبات Merkle للحالة التي فيها لديك أموال (أو إثبات Merkle لمعاملة صالحة ترسل الأموال لك). بعد التأكد من إتمام المعاملة، يمكنك تقديم الخدمة. ومع ذلك، لا يقوم validators أبدًا بتوزيع المحتوى الكامل للكتلة B عليه أي شخص. على هذا النحو، لا يمكن لـ validators الصادقة من الكتلة C استرداد الكتلة، و إما أن تضطر إلى تعطيل النظام أو البناء على الجزء A، مما يحرمك من دورك تاجر المال. عندما نطبق نفس السيناريو على المشاركة، فإن تعريفات كامل و يتم تطبيق العقدة الخفيفة بشكل عام لكل جزء: validators في كل تنزيل جزء كل قم بحظر تلك القطعة والتحقق من صحة كل معاملة في تلك القطعة، ولكن غيرها العقد في النظام، بما في ذلك تلك التي تلتقط سلاسل الأجزاء في سلسلة منارة، فقط تحميل الرؤوس. وبالتالي فإن validators الموجودة في الجزء هي العقد الكاملة لتلك القطعة بشكل فعال، بينما يقوم المشاركون الآخرون في النظام، بما في ذلك سلسلة المنارة، تعمل كعقد ضوئية. لكي ينجح نهج الصياد الذي ناقشناه أعلاه، يجب أن يكون صادقًا validators يجب أن تكون قادرًا على تنزيل الكتل المرتبطة بسلسلة المنارات. إذا قامت validators الضارة بربط رأس كتلة غير صالحة (أو استخدمتها لـ بدء معاملة متقاطعة)، ولكن لم يتم توزيع الكتلة أبدًا، الصادق validators ليس لديهم طريقة لصياغة التحدي. سنغطي ثلاثة طرق لمعالجة هذه المشكلة المكملة بعضها البعض. 2.5.1 إثباتات الحضانة المشكلة الأكثر إلحاحًا التي يجب حلها هي ما إذا كانت الكتلة متاحة مرة واحدة أم لا تم نشره. إحدى الأفكار المقترحة هي أن يكون هناك ما يسمى بكتاب العدل الذين يتناوبون بين الأجزاء في كثير من الأحيان أكثر من validators التي تتمثل مهمتها الوحيدة في تنزيل ملف حظر ويشهد على حقيقة أنهم تمكنوا من تنزيله. يمكن أن يكونوا كذلك يتم تدويرها بشكل متكرر لأنهم لا يحتاجون إلى تنزيل الحالة بأكملها من القطعة، على عكس validators الذين لا يمكن تدويرهم بشكل متكرر منذ ذلك الحين يجب تنزيل حالة الجزء في كل مرة يتم تدويرها، كما هو موضح في الشكل 13. المشكلة في هذا النهج الساذج هو أنه من المستحيل إثباته لاحقًا ما إذا كان كاتب العدل قادرًا على تنزيل الكتلة أم لا، لذلك كاتب العدل يمكنهم اختيار التأكيد دائمًا على أنهم تمكنوا من تنزيل الكتلة بدونها وحتى محاولة استعادته. أحد الحلول لذلك هو أن يقدمه كتاب العدل بعض الأدلة أو حصة مبلغ من tokens يشهد على أن الكتلة كانت تم تنزيله. تتم مناقشة أحد هذه الحلول هنا: https://ethresear.ch/t/ 1-بت-التجميع-ودية-سندات الحضانة/2236. 2.5.2 رموز المحو عندما تتلقى عقدة ضوئية معينة hash من الكتلة، لزيادة عدد العقد الثقة بأن الكتلة متاحة يمكنها محاولة تنزيل عدد قليل عشوائيًا قطع الكتلة. وهذا ليس حلا كاملا، لأنه ما لم تكن العقد الخفيفة قم بتنزيل الكتلة بأكملها بشكل جماعي والتي يمكن لمنتجي الكتل الضارة اختيارها

الشكل 13: تحتاج أدوات التحقق إلى تنزيل الحالة وبالتالي لا يمكن تدويرها في كثير من الأحيان لحجب أجزاء الكتلة التي لم يتم تنزيلها بواسطة أي عقدة خفيفة، وبالتالي لا يزال يجعل الكتلة غير متاحة. أحد الحلول هو استخدام بنية تسمى Erasure Codes لجعل ذلك ممكنًا لاستعادة الكتلة الكاملة حتى في حالة توفر جزء فقط من الكتلة، كما هو موضح في الشكل 14 الشكل 14: Merkle tree مبني على بيانات مشفرة مشفرة لدى كل من Polkadot وEthereum Serenity تصميمات تدور حول هذه الفكرة توفير طريقة للعقد الخفيفة لتكون واثقة بشكل معقول من توفر الكتل. يتضمن أسلوب الصفاء Ethereum وصفًا تفصيليًا في [2].2.5.3 نهج Polkadot فيما يتعلق بتوفر البيانات في Polkadot، كما هو الحال في معظم الحلول المجزأة، تقوم كل جزء (تسمى سلسلة Parachain) بتصوير كتلها إلى سلسلة المنارة (تسمى سلسلة التتابع). لنفترض أن هناك 2f + 1 validators على سلسلة التتابع. يُطلق على منتجي الكتل من كتل المظلات اسم المقارنات، بمجرد إنتاج كتلة المظلة، قم بحساب نسخة مشفرة للمسح من الكتلة التي تتكون من أجزاء 2f +1 بحيث تكون أي أجزاء f كافية لإعادة بناء الكتلة. ثم يقومون بتوزيع جزء واحد على كل validator على سلسلة التتابع. سلسلة ترحيل معينة validator ستوقع فقط على سلسلة ترحيل block إذا كان لديهم الجزء الخاص بهم لكل كتلة من الكتل المظلية التي تم التقاطها إليها مثل كتلة سلسلة التتابع. وبالتالي، إذا كانت كتلة سلسلة التتابع تحتوي على توقيعات من 2f + 1 validators، وطالما لم ينتهك البروتوكول أكثر من f منهم، كل منهم يمكن إعادة بناء كتلة المظلة عن طريق جلب الأجزاء من validators التي تتبع البروتوكول. انظر الشكل 15. الشكل 15: توفر بيانات Polkadot 2.5.4 توافر البيانات على المدى الطويل لاحظ أن جميع الأساليب التي تمت مناقشتها أعلاه تشهد فقط على حقيقة أن الكتلة تم نشره على الإطلاق، وهو متاح الآن. يمكن أن تصبح الكتل غير متاحة لاحقًا لعدة أسباب: العقد غير متصلة بالإنترنت، والعقد تمحو التاريخ عمدًا البيانات، وغيرها. من الجدير بالذكر أن المستند التقني الذي يعالج هذه المشكلة هو Polyshard [3]، والذي يستخدم رموز المسح لإتاحة الكتل عبر الأجزاء حتى لو كانت متعددة تفقد القطع بياناتها تمامًا. لسوء الحظ يتطلب نهجهم المحدد جميع الأجزاء لتنزيل الكتل من جميع الأجزاء الأخرى، وهو أمر محظور باهظة الثمن. إن التوفر على المدى الطويل ليس مشكلة ملحة: حيث لا يوجد مشارك في النظام من المتوقع أن يكون قادرًا على التحقق من صحة جميع السلاسل في جميع

shards، يجب تصميم أمان بروتوكول sharded على هذا النحو الطريقة التي يكون بها النظام آمنًا حتى لو أصبحت بعض الكتل القديمة في بعض القطع غير متوفر تماما.

Nightshade

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

3.2 الإجماع النهجان المهيمنان على الإجماع في blockchains اليوم هما أطول (أو أثقل) سلسلة، وهي السلسلة التي لديها أكبر قدر من العمل أو الحصة المستخدمة في بنائه تعتبر قانونية، و BFT، فيها لكل كتلة بعض مجموعة من validators تصل إلى إجماع BFT. وفي البروتوكولات المقترحة مؤخرا، يعتبر النهج الأخير هو النهج الأكثر هيمنة، لأنها توفر نهائية فورية، بينما في السلسلة الأطول تحتاج إلى المزيد من الكتل ليتم بناؤها على رأس الكتلة لضمان النهاية. في كثير من الأحيان لمعنى الأمن هو الوقت الذي يستغرقه بناء عدد كافٍ من الكتل ترتيب الساعات. استخدام BFT الإجماع على كل كتلة له أيضًا عيوب، مثل: 1. BFT يتضمن الإجماع قدرًا كبيرًا من التواصل. بينما تسمح التطورات الحديثة بالتوصل إلى الإجماع في الوقت الخطي من حيث العدد من المشاركين (راجع على سبيل المثال [4])، لا يزال هناك حمل ملحوظ لكل كتلة؛ 2. من غير الممكن لجميع المشاركين في الشبكة المشاركة في BFT الإجماع لكل كتلة، وبالتالي عادةً ما يصل فقط مجموعة فرعية من المشاركين تم أخذ عينات منها بشكل عشوائي إلى الإجماع. يمكن لمجموعة العينات العشوائية، من حيث المبدأ، أن تكون: تالف بشكل تكيفي، ويمكن إنشاء شوكة من الناحية النظرية. النظام إما أن تكون على غرار ليكون جاهزا لمثل هذا الحدث، وبالتالي لا يزال لديك قاعدة اختيار شوكة إلى جانب إجماع BFT، أو مصممة لإغلاق أسفل في مثل هذا الحدث. ومن الجدير بالذكر أن بعض التصاميم مثل Algorand [5]، يقلل بشكل كبير من احتمالية الفساد التكيفي. 3. والأهم من ذلك، أن النظام يتوقف إذا 1 3 أو أكثر من جميع المشاركين غير متصل. وبالتالي، فإن أي خلل مؤقت في الشبكة أو انقسام في الشبكة يمكن أن يؤدي إلى توقف النظام تمامًا. من الناحية المثالية، يجب أن يكون النظام قادرًا على الاستمرار تعمل طالما أن نصف المشاركين على الأقل متصلون بالإنترنت (أثقل تستمر البروتوكولات القائمة على السلسلة في العمل حتى لو كان أقل من نصف المشاركين متصلين بالإنترنت، ولكن مدى استصواب هذه الخاصية أكثر إثارة للجدل داخل المجتمع). النموذج الهجين الذي يكون فيه الإجماع المستخدم هو الأثقل نوعًا ما سلسلة، ولكن يتم الانتهاء من بعض الكتل بشكل دوري باستخدام أداة BFT النهائية للحفاظ على مزايا كلا النموذجين. مثل هذه الأدوات BFT هي Casper FFG [6] المستخدم في Ethereum 2.0 8، Casper CBC (راجع https://vitalik. ca/general/2018/12/05/cbc_casper.html) و GRANDPA (راجع https:// Medium.com/polkadot-network/d08a24a021b5) المستخدم في Polkadot. يستخدم Nightshade إجماع السلسلة الأثقل. على وجه التحديد عندما كتلة ينتج المنتج كتلة (انظر القسم 3.3)، ويمكنه جمع التوقيعات منها منتجو الكتل الآخرون وvalidators يشهدون على الكتلة السابقة. انظر القسم 3.8 للحصول على تفاصيل حول كيفية تجميع هذا العدد الكبير من التوقيعات. الوزن 8 راجع أيضًا جلسة السبورة البيضاء مع جاستن دريك للحصول على نظرة عامة متعمقة عن Casper FFG، وكيف يتم دمجه مع إجماع سلسلة GHOST الأثقل هنا: https://www. youtube.com/watch?v=S262StTwkmoمن الكتلة هي الحصة التراكمية لجميع الموقعين الذين لديهم توقيعات المدرجة في الكتلة. وزن السلسلة هو مجموع أوزان الكتلة. علاوة على إجماع السلسلة الأثقل، نستخدم أداة نهائية تستخدم الشهادات لإنهاء الكتل. لتقليل تعقيد النظام، نحن نستخدم أداة نهائية لا تؤثر على قاعدة اختيار الشوكة بأي شكل من الأشكال، وبدلاً من ذلك يقدم فقط شروط القطع الإضافية، مثل تلك التي يتم قطعها مرة واحدة في الكتلة تم الانتهاء من الشوكة بواسطة الأداة النهائية، ومن المستحيل الحصول على شوكة ما لم تكن هناك نسبة كبيرة جدًا من إجمالي الحصة تم تخفيضها. إن Casper CBC عبارة عن أداة نهائية، ونحن كذلك النموذج حاليًا مع وضع Casper CBC في الاعتبار. نحن نعمل أيضًا على بروتوكول BFT منفصل يسمى TxFlow. في وقت عند كتابة هذه الوثيقة، من غير الواضح ما إذا كان سيتم استخدام TxFlow بدلاً من Casper سي بي سي. ومع ذلك، نلاحظ أن اختيار الأداة النهائية متعامد إلى حد كبير مع بقية التصميم. 3.3 إنتاج الكتلة يوجد في Nightshade دوران: منتجو الكتل وvalidators. في أي نقطة النظام يحتوي على منتجي الكتلة w، w = 100 في نماذجنا، وwv validators، في نموذجنا v = 100، wv = 10,000. النظام هو إثبات الحصة، مما يعني أن كلا من منتجي الكتل وvalidator لديهم عدد من العناصر الداخلية العملة (المشار إليها باسم "tokens") مقفلة لمدة زمنية تتجاوز بكثير الوقت الذي يقضونه في أداء واجباتهم في بناء السلسلة والتحقق من صحتها. كما هو الحال مع جميع أنظمة إثبات الحصة، ليس كل منتجي الكتلة وليس كذلك جميع wv validators هي كيانات مختلفة، حيث لا يمكن فرض ذلك. كل ومع ذلك، فإن منتجي الكتل w وwv validators لديهم قسم منفصل حصة. يحتوي النظام على n شظايا، n = 1000 في نموذجنا. كما ذكر في القسم 3.1، في Nightshade لا توجد سلاسل شظية، وبدلاً من ذلك يقوم جميع منتجي الكتل وvalidator ببناء blockchain واحد، والذي نشير إليه باسم السلسلة الرئيسية. يتم تقسيم حالة السلسلة الرئيسية إلى أجزاء n وكل كتلة المنتج وvalidator في أي لحظة قاموا فقط بتنزيل مجموعة فرعية من الحالة التي تتوافق مع بعض المجموعات الفرعية من القطع، والمعالجة فقط التحقق من صحة المعاملات التي تؤثر على تلك الأجزاء من الدولة. لكي تصبح منتجًا للكتل، يجب على أحد المشاركين في الشبكة أن يقوم بتأمين بعض الكتل الكبيرة مبلغ tokens (حصة). تتم صيانة الشبكة على فترات، حيث العصر هو فترة من الزمن بترتيب الأيام. المشاركون مع أكبر الرهانات في بداية حقبة معينة هي الكتلة المنتجين لتلك الحقبة. يتم تعيين كل منتج كتلة إلى قطع sw، (على سبيل المثال sw = 40، مما يجعل sww/n = 4 منتجي كتلة لكل قطعة). الكتلة يقوم المنتج بتنزيل حالة الجزء الذي تم تعيينه له قبل العصر يبدأ، وعلى مدار العصر يجمع المعاملات التي تؤثر على تلك القطعة، ويطبقها على الدولة. لكل كتلة b في السلسلة الرئيسية، ولكل قطعة s، هناك واحدة من تم تعيين منتجي الكتل إلى المسؤول عن إنتاج الجزء المتعلق ب إلى القشرة. الجزء من b المرتبط بالشظية يسمى قطعة، ويحتوي على قائمة المعاملات الخاصة بالجزء المراد تضمينه في b، بالإضافة إلى Merkleجذر الحالة الناتجة. b سيحتوي في النهاية على رأس صغير جدًا فقط القطعة، وهي جذر Merkle لجميع المعاملات المطبقة (انظر القسم 3.7.1 للحصول على تفاصيل دقيقة)، وجذر ميركل للحالة النهائية. غالبًا ما نشير في بقية الوثيقة إلى منتج الكتل المسؤولة عن إنتاج قطعة في وقت معين لقطعة معينة كمنتج قطعة. يعد منتج Chunk دائمًا أحد منتجي الكتل. يقوم منتجو الكتل ومنتجو القطع بتدوير كل كتلة وفقًا لذلك لجدول زمني محدد. منتجو الكتل لديهم طلب وينتجون بشكل متكرر كتل في هذا الترتيب. على سبيل المثال. إذا كان هناك 100 منتج كتلة، الكتلة الأولى المنتجون مسؤولون عن إنتاج الكتل 1، 101، 201 إلخ، والثاني هو المسؤول عن إنتاج 2، 102، 202 الخ). نظرًا لأن إنتاج القطع، على عكس إنتاج الكتل، يتطلب الصيانة الدولة، ولكل جزء فقط منتجو كتلة sww/n يحافظون على الدولة لكل قطعة، في المقابل، يتم تدوير منتجي كتل sww/n فقط لإنشاءها قطع. على سبيل المثال. مع الثوابت المذكورة أعلاه مع أربعة منتجين للكتل تم تعيينهم كل قطعة، سيقوم كل منتج كتلة بإنشاء قطع مرة واحدة كل أربع كتل. 3.4 ضمان توافر البيانات لضمان توفر البيانات، نستخدم أسلوبًا مشابهًا لأسلوب Polkadot الموصوفة في القسم 2.5.3. بمجرد أن ينتج منتج الكتلة قطعة، فإنه يقوم بإنشائها نسخة مشفرة للمحو باستخدام رمز الكتلة الأمثل (w, ⌊w/6 + 1⌋) قطعة. ثم يرسلون بعد ذلك قطعة واحدة من قطعة المحو المشفرة (نسميها هذه القطع أجزاء قطعة، أو أجزاء فقط) لكل منتج كتلة. نقوم بحساب شجرة ميركل التي تحتوي على جميع الأجزاء مثل الأوراق، و يحتوي رأس كل قطعة على جذر ميركل لهذه الشجرة. يتم إرسال الأجزاء إلى validators عبر رسائل onepart. كل رسالة من هذا القبيل يحتوي على رأس القطعة والترتيبي للجزء ومحتويات الجزء. ال تحتوي الرسالة أيضًا على توقيع منتج الكتلة الذي أنتج الملف قطعة ومسار ميركل لإثبات أن الجزء يتوافق مع الرأس ويتم إنتاجه بواسطة منتج الكتلة المناسب. بمجرد أن يتلقى منتج الكتلة كتلة السلسلة الرئيسية، فإنه يتحقق أولاً مما إذا كان ذلك صحيحًا أم لا تحتوي على رسائل مكونة من جزء واحد لكل قطعة مضمنة في الكتلة. إذا لم يكن كذلك، الكتلة لا تتم معالجة حتى يتم استرداد الرسائل المفقودة. بمجرد استلام كافة الرسائل المكونة من جزء واحد، يقوم منتج الكتلة بإحضار الملف الأجزاء المتبقية من أقرانه ويعيد بناء القطع التي يحتفظون بها الدولة. لا يقوم منتج الكتلة بمعالجة كتلة السلسلة الرئيسية إذا كانت لواحدة على الأقل القطعة المضمنة في الكتلة لا تحتوي على الرسالة المقابلة من جزء واحد، أو إذا كانت القطعة واحدة على الأقل تحافظ على الحالة التي لا يمكنها ذلك إعادة بناء القطعة بأكملها. لكي تكون قطعة معينة متاحة، يكفي أن يكون ⌊w/6⌋+1 من الكتلة المنتجون لديهم أجزائهم ويخدمونها. وهكذا، طالما أن عدد لا تتجاوز الجهات الفاعلة الضارة ⌊w/3⌋لا توجد سلسلة تحتوي على أكثر من نصف الكتلة يمكن أن يحتوي المنتجون الذين يقومون ببنائه على قطع غير متوفرة.الشكل 17: تحتوي كل كتلة على قطعة واحدة أو صفر قطعة لكل قطعة، وكل قطعة هو محو مشفرة. يتم إرسال كل جزء من قطعة المحو المشفرة إلى جهة معينة منتج الكتلة عبر رسالة خاصة من جزء واحد 3.4.1 التعامل مع منتجي الكتل الكسالى إذا كان لدى منتج الكتلة كتلة تفتقد رسالة مكونة من جزء واحد، فسيقومون بذلك قد يختار الاستمرار في التوقيع عليها، لأنه إذا انتهى الأمر بربط الكتلة بالسلسلة سيزيد من مكافأة منتج الكتلة. لا يوجد خطر على الكتلة المنتج لأنه من المستحيل إثبات لاحقًا أن منتج الكتلة لم يكن لديه الرسالة ذات الجزء الواحد. لمعالجة هذه المشكلة، نجعل كل قطعة منتجة عند إنشاء القطعة اختر لونًا (أحمر أو أزرق) لكل جزء من القطعة المشفرة المستقبلية، وقم بتخزينها القناع البتي للون المخصص في القطعة قبل تشفيرها. كل جزء تحتوي الرسالة بعد ذلك على اللون المخصص للجزء، ويتم استخدام اللون متى حساب جذر ميركل للأجزاء المشفرة. إذا انحرف منتج القطعة من البروتوكول، يمكن إثبات ذلك بسهولة، حيث لن يتم إثبات جذر Merkle تتوافق مع الرسائل ذات الجزء الواحد، أو الألوان الموجودة في الرسائل ذات الجزء الواحد تتوافق مع جذر Merkle ولن تتطابق مع القناع الموجود في القطعة. عندما يقوم منتج الكتلة بالتوقيع على الكتلة، فإنه يتضمن قناعًا نقطيًا لجميع العناصر الأجزاء الحمراء التي تلقوها مقابل القطع الموجودة في الكتلة. نشر ان قناع البت غير الصحيح هو سلوك قابل للقطع. إذا لم يتلق منتج الكتلة أ رسالة مكونة من جزء واحد، ليس لديهم طريقة لمعرفة لون الرسالة، و وبالتالي لديهم فرصة بنسبة 50٪ للتعرض للقطع إذا حاولوا التوقيع بشكل أعمى على كتلة. 3.5 تطبيق انتقال الدولة يختار منتجو القطعة فقط المعاملات التي سيتم تضمينها في القطعة ولكن لا تطبق انتقال الحالة عندما تنتج قطعة. في المقابل،

يحتوي رأس القطعة على جذر Merkle لحالة Merkelized كما كان من قبل يتم تطبيق المعاملات في القطعة. يتم تطبيق المعاملات فقط عندما تكون الكتلة كاملة تتضمن القطعة تتم معالجتها. يقوم المشارك بمعالجة الكتلة فقط إذا 1. تم استلام الكتلة السابقة ومعالجتها؛ 2. بالنسبة لكل قطعة، لا يحتفظ المشارك بالحالة التي يمتلكها رأيت الرسالة المكونة من جزء واحد؛ 3. بالنسبة لكل قطعة، يحافظ المشارك على الحالة لأنه يمتلك قطعة كاملة. بمجرد معالجة الكتلة، لكل قطعة يشارك فيها المشارك يحافظ على الحالة، ويقوم بتطبيق المعاملات وحساب الحالة الجديدة اعتبارًا من بعد تطبيق المعاملات، وبعد ذلك تصبح جاهزة للإنتاج قطع الكتلة التالية، إذا تم تخصيصها لأي قطعة، نظرًا لوجودها جذر ميركل للدولة المركلية الجديدة. 3.6 المعاملات والإيصالات عبر القطع إذا كانت المعاملة تحتاج إلى أن تؤثر على أكثر من جزء واحد، فيجب أن تكون متتالية يتم تنفيذها في كل قطعة على حدة. يتم إرسال المعاملة الكاملة إلى الجزء الأول متأثرة، وبمجرد تضمين المعاملة في قطعة هذه القطعة، و يتم تطبيقه بعد تضمين القطعة في كتلة، فإنه يولد ما يسمى بالإيصال المعاملة، التي يتم توجيهها إلى الجزء التالي الذي تحتاج المعاملة إليه يتم إعدامه. إذا كانت هناك حاجة لمزيد من الخطوات، تنفيذ معاملة الاستلام ينشئ معاملة استلام جديدة وما إلى ذلك. 3.6.1 استلام المعاملة مدى الحياة من المستحسن أن يتم تطبيق معاملة الاستلام في الكتلة التي تتبع الكتلة التي تم إنشاؤها فيها مباشرة. معاملة الاستلام فقط تم إنشاؤها بعد استلام الكتلة السابقة وتطبيقها من قبل منتجي الكتلة التي تحافظ على القطعة الأصلية، ويجب أن تكون معروفة بحلول الوقت الذي يتم إنتاج قطعة الكتلة التالية بواسطة منتجي الكتلة للوجهة شظية. وبالتالي، يجب إرسال الإيصال من الجزء المصدر إلى جزء الوجهة في الإطار الزمني القصير بين هذين الحدثين. دع A يكون آخر كتلة تم إنتاجها والتي تحتوي على معاملة t التي تولد إيصالًا r. دع B يكون الكتلة المنتجة التالية (أي الكتلة التي تحتوي على A كـ كتلته السابقة) التي نريد أن تحتوي على r. دع t يكون في الكسرة a و r يكون في القشرة ب. عمر الإيصال، الموضح أيضًا في الشكل 18، هو كما يلي: إنتاج وتخزين الإيصالات. منتج القطعة CPA للقطعة يتلقى a الكتلة A، ويطبق المعاملة t وينشئ الإيصال r. اتفاق السلام الشامل ثم يقوم بتخزين جميع هذه الإيصالات المنتجة في وحدة التخزين الداخلية الدائمة المفهرسة بواسطة معرف القطعة المصدر.توزيع الإيصالات. بمجرد أن يصبح CPA جاهزًا لإنتاج القطعة الجزء "أ" للكتلة "ب"، يقومون بإحضار جميع الإيصالات التي تم إنشاؤها عن طريق تطبيق المعاملات من الكتلة "أ" للجزء "أ"، وإدراجها في القطعة للجزء "شراد" a في الكتلة B. بمجرد إنشاء هذه القطعة، ينتج cpa تشفيرًا للمسح الخاص بها الإصدار وجميع رسائل onepart المقابلة. يعرف CPA منتجي الكتل الذين يحتفظون بالحالة الكاملة لأي شظايا. لمنتج كتلة معينة تتضمن bp cpa الإيصالات الناتجة عن تطبيق المعاملات في الكتلة A بالنسبة للقطعة a التي تحتوي على أي من القطع التي تهتم بها شركة bp كوجهة لها في الرسالة المكونة من جزء واحد عندما قاموا بتوزيع القطعة الخاصة بالجزء "أ" في الكتلة "ب". (انظر الشكل 17، الذي يوضح الإيصالات المضمنة في الرسالة المكونة من جزء واحد). استلام الإيصالات. تذكر أن المشاركين (منتجي الكتل وvalidators) لا يقومون بمعالجة الكتل حتى يكون لديهم رسائل مكونة من جزء واحد لكل قطعة مدرجة في الكتلة. وبالتالي، بحلول الوقت الذي يقوم فيه أي مشارك معين بتطبيق المجموعة B، يكون لديه جميع الرسائل ذات الجزء الواحد التي تتوافق معها قطع في B، وبالتالي لديهم جميع الإيصالات الواردة التي تحتوي على القطع يحتفظ المشارك بالحالة كوجهة له. عند تطبيق انتقال الحالة لجزء معين، يقوم المشارك بتطبيق كلا الإيصالات التي جمعوها للكسرة في الرسائل الواحدة، فضلا عن الجميع المعاملات المدرجة في القطعة نفسها. الشكل 18: عمر معاملة الاستلام 3.6.2 التعامل مع عدد كبير جدًا من الإيصالات من الممكن أن يكون عدد الإيصالات التي تستهدف جزءًا معينًا في ملف كتلة معينة كبيرة جدًا بحيث لا يمكن معالجتها. على سبيل المثال، تأمل الشكل 19، في حيث تقوم كل معاملة في كل جزء بإنشاء إيصال يستهدف الجزء 1. بحلول الكتلة التالية، يكون عدد الإيصالات التي تحتاج القطعة 1 إلى معالجتها هو يمكن مقارنته بالحمل الذي تمت معالجته لجميع القطع مجتمعة أثناء التعامل معها الكتلة السابقة.

الشكل 19: إذا كانت كافة الإيصالات تستهدف نفس الجزء، فقد لا يكون لدى الجزء نفس الشيء القدرة على معالجتها ولمعالجتها نستخدم تقنية مشابهة لتلك المستخدمة في QuarkChain 9. على وجه التحديد، بالنسبة لكل جزء، توجد الكتلة الأخيرة B وآخر جزء داخل ذلك يتم تسجيل الكتلة التي تم تطبيق الإيصالات منها. عندما تكون القشرة الجديدة تم إنشاؤه، ويتم تطبيق الإيصال بالترتيب أولاً من الأجزاء المتبقية في B، ثم في الكتل التي تتبع B، حتى تمتلئ القطعة الجديدة. تحت العادي الظروف مع حمولة متوازنة ستؤدي بشكل عام إلى جميع الإيصالات يتم تطبيقها (وبالتالي سيتم تسجيل الجزء الأخير من الكتلة الأخيرة كل قطعة)، ولكن في الأوقات التي يكون فيها الحمل غير متوازن، وخاصة تتلقى Shard العديد من الإيصالات بشكل غير متناسب، وهذا الأسلوب يسمح لهم بذلك تتم معالجتها مع احترام الحدود المفروضة على عدد المعاملات المدرجة. لاحظ أنه إذا ظل هذا الحمل غير المتوازن لفترة طويلة، فإن التأخير من إنشاء الإيصال حتى يتمكن التطبيق من الاستمرار في النمو إلى أجل غير مسمى. واحد طريقة معالجتها هي إسقاط أي معاملة تؤدي إلى إنشاء إيصال يستهدف أ جزء يحتوي على تأخير معالجة يتجاوز بعض الثوابت (على سبيل المثال، عصر واحد). خذ بعين الاعتبار الشكل 20. حسب الكتلة B، لا يمكن للجزء 4 معالجة جميع الإيصالات، لذلك فهو يعالج فقط إنشاء الإيصالات من الجزء 3 حتى الجزء A، و يسجل ذلك. في الكتلة C، يتم تضمين الإيصالات حتى الجزء 5 في الكتلة B، و ثم عن طريق الكتلة D، يتم اللحاق بالجزء، ومعالجة جميع الإيصالات المتبقية الكتلة B وجميع الإيصالات من الكتلة C. 3.7 التحقق من صحة القطع لا يمكن التحقق من صحة القطعة التي تم إنتاجها لجزء معين (أو كتلة جزء تم إنتاجها لسلسلة جزء معينة في النموذج الذي يحتوي على سلاسل جزء) فقط من خلال 9شاهد حلقة السبورة البيضاء مع QuarkChain هنا: https://www.youtube.com/watch? v=opEtG6NM4x4، حيث تتم مناقشة أسلوب المعاملات المتقاطعة، من بين أمور أخرى الأشياءالشكل 20: تأخر معالجة الإيصالات المشاركين الذين يحافظون على الدولة. يمكن أن يكونوا منتجي كتل، validators، أو مجرد شهود خارجيين قاموا بتنزيل الحالة والتحقق من صحة الجزء فيها التي يقومون بتخزين الأصول. في هذه الوثيقة نفترض أن غالبية المشاركين لا يستطيعون التخزين الدولة لجزء كبير من القطع. ومن الجدير بالذكر، مع ذلك، أن هناك blockchains مقسمة تم تصميمها مع افتراض ذلك يتمتع معظم المشاركين بالقدرة على تخزين الحالة والتحقق من صحتها الشظايا، مثل QuarkChain. نظرًا لأن جزءًا صغيرًا فقط من المشاركين لديهم الحالة اللازمة للتحقق من صحة القطعة قطع، فمن الممكن أن التكيف الفاسدة فقط المشاركين الذين لديهم الحالة، وتطبيق انتقال حالة غير صالح. تم اقتراح تصميمات تقسيم متعددة لأخذ عينات من validators كل بضعة أيام أيام، وخلال يوم أي كتلة في سلسلة الكسرة تحتوي على أكثر من 2/3 يتم النظر على الفور في توقيعات validators المخصصة لهذه القطعة نهائي. مع مثل هذا النهج، يحتاج الخصم المتكيف فقط إلى إفساد 2n/3+1 من validators في سلسلة الجزء لتطبيق انتقال حالة غير صالح، والذي، ورغم أنه من الصعب تحقيق ذلك على الأرجح، إلا أنه ليس مستوى من الأمان كافيًا للجمهور blockchain. كما تمت مناقشته في القسم 2.3، فإن النهج الشائع هو السماح بفترة زمنية معينة بعد إنشاء الكتلة لأي مشارك لديه حالة (سواء كانت إنه منتج كتلة، validator، أو مراقب خارجي) للطعن في صحته. ويطلق على هؤلاء المشاركين اسم الصيادين. لكي يتمكن الصياد من ذلك تحدي كتلة غير صالحة، يجب التأكد من أن هذه الكتلة متاحة ل لهم. تمت مناقشة توفر البيانات في Nightshade في القسم 3.4. في Nightshade، بمجرد إنتاج كتلة، لا يتم التحقق من صحة القطع من قبل أي شخص باستثناء منتج القطعة الفعلي. على وجه الخصوص، منتج الكتلة ذلك اقترح أن الكتلة بطبيعة الحال لا تحتوي على الحالة لمعظم القطع، ولم يكن قادرا على التحقق من صحة القطع. عندما يتم إنتاج الكتلة التالية، فإنها تحتوي على شهادات (انظر القسم 3.2) من منتجي الكتل المتعددين وvalidators، ولكن بما أن غالبية منتجي الكتل وvalidators لا يحافظون على الحالة بالنسبة لمعظم القطع أيضًا، فإن الكتلة التي تحتوي على قطعة واحدة غير صالحة ستجمع أكثر من نصف الشهادات بشكل ملحوظ وستظل على الأثقل سلسلة. لمعالجة هذه المشكلة، نسمح لأي مشارك يحافظ على حالة قطعة لإرسال تحدي على السلسلة لأي قطعة غير صالحة تم إنتاجها في ذلك شظية. 3.7.1 تحدي صلاحية الدولة بمجرد اكتشاف أحد المشاركين أن مجموعة معينة غير صالحة، فإنه يحتاج إلى تقديم دليل على أن المجموعة غير صالحة. نظرًا لأن غالبية المشاركين في الشبكة لا يحافظون على حالة القطعة التي توجد بها القطعة غير الصالحة يجب أن يحتوي الدليل على معلومات كافية لتأكيد الكتلة باطل دون وجود الدولة. قمنا بتعيين حد Ls لمقدار الحالة (بالبايت) لمعاملة واحدة يمكن القراءة أو الكتابة بشكل تراكمي. أي معاملة تمس أكثر من Ls تعتبر الدولة غير صالحة. تذكر من القسم 3.5 أن القطعة في كتلة معينة B تحتوي فقط على المعاملات التي سيتم تطبيقها، ولكن لا جذر الدولة الجديدة. جذر الحالة المتضمن في القطعة في الكتلة B هو الحالة root قبل تطبيق مثل هذه المعاملات، ولكن بعد تطبيق المعاملات من القطعة الأخيرة في نفس الكسرة قبل الكتلة B. ممثل خبيث قد تتضمن الرغبة في تطبيق انتقال حالة غير صالح جذر حالة غير صحيح في الكتلة B التي لا تتوافق مع جذر الحالة الناتج عن التقديم المعاملات في القطعة السابقة. نقوم بتوسيع المعلومات التي يتضمنها منتج القطعة في القطعة. بدلاً من مجرد تضمين الحالة بعد تطبيق كافة المعاملات، يتم بدلاً من ذلك يتضمن جذر الحالة بعد تطبيق كل مجموعة متجاورة من المعاملات قراءة وكتابة بايتات Ls من الحالة بشكل جماعي. بهذه المعلومات ل صياد لخلق التحدي المتمثل في تطبيق انتقال الدولة بشكل غير صحيح عليه يكفي العثور على أول جذر حالة غير صالح، ويتضمن فقط Ls بايت من الحالة التي تتأثر بالمعاملات بين جذر الحالة الأخير (والذي كان صالح) وجذر الحالة الحالية مع أدلة ميركل. ثم أي مشارك يمكن التحقق من صحة المعاملات في المقطع والتأكد من أن القطعة موجودة غير صالح. وبالمثل، إذا حاول منتج القطعة تضمين المعاملات التي تقرأ واكتب أكثر من Ls بايت من الحالة، فالتحدي يكفي أن تشمله البايتات الأولى التي يلامسها باستخدام أدلة ميركل، والتي ستكون كافية للقيام بذلك قم بتطبيق المعاملات والتأكد من أن هناك لحظة يتم فيها المحاولة قراءة أو كتابة محتوى يتجاوز بايت Ls.

3.7.2 الصيادون والمعاملات السريعة المتقاطعة كما تمت مناقشته في القسم 2.3، بمجرد أن نفترض أن قطع الكسر (أو الكسر يمكن أن تكون الكتل الموجودة في النموذج ذات سلاسل الأجزاء) غير صالحة وتشكل تحديًا خلال هذه الفترة، فإنه يؤثر سلبًا على النهاية، وبالتالي على التواصل عبر الأجزاء. في على وجه الخصوص، لا يمكن التأكد من جزء الوجهة لأي عملية نقل متقاطعة تعتبر قطعة أو كتلة القطعة الأصلية نهائية حتى تنتهي فترة التحدي (انظر الشكل 21). الشكل 21: انتظار فترة التحدي قبل تقديم الإيصال وطريقة معالجتها بطريقة تجعل المعاملات متقاطعة اللحظية هي أن لا تنتظر قطعة الوجهة فترة التحدي بعد نشر معاملة الجزء المصدر، وتطبيق معاملة الاستلام على الفور، ولكن بعد ذلك قم باستعادة جزء الوجهة مع المصدر shard إذا تبين لاحقًا أن القطعة أو الكتلة الأصلية غير صالحة (انظر الشكل 1). 22). وهذا ينطبق بشكل طبيعي جدًا على تصميم Nightshade الذي توجد فيه القشرة السلاسل ليست مستقلة، ولكن بدلًا من ذلك يتم نشر جميع أجزاء الكسر معًا في نفس كتلة السلسلة الرئيسية. إذا تم العثور على أي قطعة غير صالحة، تعتبر الكتلة بأكملها التي تحتوي على تلك القطعة غير صالحة، وجميع الكتل المبنية عليها أعلى منه. انظر الشكل 23. يوفر كلا النهجين المذكورين أعلاه الذرية على افتراض أن التحدي الفترة طويلة بما فيه الكفاية. نحن نستخدم النهج الأخير نظرًا لأن توفير معاملات متقاطعة سريعة في ظل الظروف العادية يفوق الإزعاج تم التراجع عن جزء الوجهة بسبب انتقال حالة غير صالح في أحد شظايا المصدر، وهو حدث نادر للغاية. 3.7.3 إخفاء validators إن وجود التحديات يقلل بالفعل بشكل كبير من احتمالية حدوث ذلك الفساد التكيفي، منذ الانتهاء من قطعة مع منشور انتقال حالة غير صالحالشكل 22: تطبيق الإيصالات على الفور وإرجاع الوجهة chain إذا كانت السلسلة المصدر تحتوي على كتلة غير صالحة الشكل 23: تحدي الصياد في الباذنجان فترة التحدي التي يحتاجها الخصم المتكيف لإفساد جميع المشاركين التي تحافظ على حالة الجزء، بما في ذلك كافة validators. إن تقدير احتمالية حدوث مثل هذا الحدث أمر معقد للغاية، حيث لا تم نشر blockchain لفترة كافية لمحاولة أي هجوم من هذا القبيل. ونحن نرى أن الاحتمال، على الرغم من كونه منخفضا للغاية، لا يزال كافيا كبير بالنسبة لنظام من المتوقع أن ينفذ عدة ملايين من المعاملات و إدارة العمليات المالية في جميع أنحاء العالم. هناك سببان رئيسيان لهذا الاعتقاد: 1. معظم validators من سلاسل إثبات الملكية والقائمين بالتعدين في

يتم تحفيز سلاسل إثبات العمل في المقام الأول من خلال الاتجاه الصعودي المالي. إذا فالخصم المتكيف يقدم لهم أموالاً أكثر من العائد المتوقع من العمل بأمانة، فمن المعقول أن نتوقع أن العديد من validators سوف يقبل العرض. 2. تقوم العديد من الكيانات بالتحقق من صحة سلاسل إثبات الملكية بشكل احترافي ومن المتوقع أن تكون هناك نسبة كبيرة من الحصة في أي سلسلة من مثل هذه الجهات. عدد هذه الكيانات صغير بما يكفي ل الخصم المتكيف للتعرف على معظمهم شخصيًا والحصول على وحسن فهم ميلهم إلى الفساد. نحن نخطو خطوة أخرى نحو تقليل احتمالية الفساد التكيفي عن طريق إخفاء validators المخصصة لأي جزء. الفكرة هي تشبه عن بعد طريقة Algorand [5] لإخفاء validators. من المهم ملاحظة أنه حتى لو تم إخفاء validator، كما في Algorand أو كما هو موضح أدناه، لا يزال الفساد التكيفي ممكنًا من الناحية النظرية. بينما الخصم المتكيف لا يعرف المشاركين الذين سيقومون بالإنشاء أو التحقق من صحتهم كتلة أو قطعة، يعرف المشاركون أنفسهم أنهم سيؤدونها مثل هذه المهمة ويكون لديك دليل التشفير على ذلك. وهكذا يستطيع العدو يبثون نيتهم في الفساد، ويدفعون لأي مشارك سيقدم ذلك مثل هذا الدليل التشفير. ومع ذلك، نلاحظ أنه بما أن الخصم لا يفعل ذلك تعرف على validators المخصصة للجزء الذي يريدون إفساده، فهم ليس لديهم خيار آخر سوى الإعلان عن نيتهم في إفساد جزء معين المجتمع بأكمله. عند هذه النقطة يكون الأمر مفيدًا اقتصاديًا لأي شخص صادق يقوم المشارك بتدوير عقدة كاملة تتحقق من صحة تلك القطعة، نظرًا لوجود ارتفاع فرصة ظهور كتلة غير صالحة في تلك القطعة، وهي فرصة لذلك قم بإنشاء تحدي وجمع المكافأة المرتبطة به. لكي لا نكشف عن validators المخصصة لجزء معين، فإننا نفعل ذلك ما يلي (انظر الشكل 24): استخدام VRF للحصول على المهمة. في بداية كل عصر لكل منهما يستخدم validator VRF للحصول على قناع نقطي للأجزاء التي تم تعيين validator لها. سيحتوي قناع البت لكل validator على بتات Sw (راجع القسم 3.3 للتعرف على من سو). يقوم validator بعد ذلك بجلب حالة الأجزاء المقابلة، و خلال فترة كل كتلة مستلمة، يتم التحقق من صحة القطع المقابلة إلى الأجزاء التي تم تعيين validator لها. قم بالتسجيل على الكتل بدلاً من القطع. نظرًا لأن تعيين الأجزاء مخفي، لا يمكن لـ validator تسجيل الدخول على القطع. بدلا من ذلك فإنه يوقع دائما على كامل block، وبالتالي لا يكشف عن الأجزاء التي يتحقق من صحتها. على وجه التحديد، عندما يتلقى validator كتلة ويتحقق من صحة جميع المقاطع، فإنه إما يقوم بإنشاء رسالة يشهد أن جميع القطع الموجودة في جميع الأجزاء التي تم تعيين validator لها هي صالحة (دون الإشارة بأي شكل من الأشكال إلى ماهية تلك الأجزاء)، أو رسالة مفادها يحتوي على دليل على انتقال حالة غير صالح إذا كان أي جزء غير صالح. انظر القسم 3.8 للحصول على تفاصيل حول كيفية تجميع هذه الرسائل، القسم 3.7.4 لـ التفاصيل حول كيفية منع validators من النسخ الاحتياطي على الرسائل الواردة من validators الأخرى، والقسم 3.7.5 للحصول على تفاصيل حول كيفية المكافأة والمعاقبة validators في حالة حدوث اختبار ناجح لنقل الحالة غير الصالحة بالفعل.الشكل 24: إخفاء validators في الباذنجان 3.7.4 الالتزام وكشف إحدى المشكلات الشائعة في validators هي أن validator يمكنه تخطي تنزيل الحالة والتحقق فعليًا من صحة المقاطع والكتل، وبدلاً من ذلك راقب الشبكة، وشاهد ما يرسله validators الآخرون ويكررونه الرسائل. validator الذي يتبع مثل هذه الإستراتيجية لا يوفر أي شيء إضافي الأمن للشبكة، ولكن يجمع المكافآت. الحل الشائع لهذه المشكلة هو أن يقدم كل validator دليلاً أنهم قاموا بالفعل بالتحقق من صحة الكتلة، على سبيل المثال من خلال توفير تتبع فريد من تطبيق انتقال الدولة، ولكن مثل هذه البراهين تزيد التكلفة بشكل كبير من التحقق من الصحة. الشكل 25: كشف الالتزام

وبدلاً من ذلك، نجعل validators يلتزم أولاً بنتيجة التحقق (إما الرسالة التي تشهد بصحة القطع، أو إثبات بطلانها انتقال الحالة)، انتظر فترة معينة، وعندها فقط تكشف عن نتيجة التحقق الفعلية، كما هو موضح في الشكل 25. لا تتقاطع فترة الالتزام مع فترة الكشف، وبالتالي لا يستطيع validator الكسول تقليد validators الصادق. علاوة على ذلك، إذا كان validator غير أمين ملتزمًا برسالة تشهد على ذلك صلاحية القطع المخصصة، وكانت قطعة واحدة على الأقل غير صالحة، بمجرد أن تكون كذلك تبين أن القطعة غير صالحة ولا يمكن لـ validator تجنب التقطيع، نظرًا لأن، كما نبين في القسم 3.7.5، الطريقة الوحيدة لعدم التعرض للخسارة في مثل هذه الحالة هو تقديم رسالة تحتوي على دليل على أن الحالة الانتقالية غير صالحة يطابق الالتزام. 3.7.5 التعامل مع التحديات كما تمت مناقشته أعلاه، بمجرد أن يتلقى validator كتلة تحتوي على مقطع غير صالح، يقومون أولاً بإعداد دليل على انتقال الحالة غير الصالح (انظر القسم 3.7.1)، ثم التزم بمثل هذا الدليل (انظر 3.7.4)، وبعد فترة اكشف عن التحدي. بمجرد تضمين التحدي الذي تم الكشف عنه في الكتلة، يحدث ما يلي: 1. جميع انتقالات الحالة التي حدثت من الكتلة التي تحتوي على قطعة غير صالحة حتى يتم الحصول على الكتلة التي تم تضمين التحدي المكشوف فيها باطل. الحالة قبل الكتلة التي تتضمن التحدي المكشوف تعتبر نفس الحالة قبل الكتلة التي تحتوي عليها القطعة غير الصالحة 2. خلال فترة زمنية معينة، يجب على كل validator أن يكشف عن قناعه النقطي من القطع التي التحقق من صحتها. نظرًا لأنه يتم إنشاء قناع البت عبر VRF، إذا تم تعيينهم إلى الجزء الذي كان به انتقال حالة غير صالح، هم لا يمكن تجنب الكشف عنها. أي validator يفشل في الكشف عن قناع البت من المفترض أن يتم تعيينها للقطعة. 3. كل validator يتم العثور عليه بعد هذه الفترة مخصصًا للكسر، التي التزمت ببعض نتائج التحقق من الصحة للكتلة التي تحتوي على ملف قطعة غير صالحة والتي لم تكشف عن دليل على انتقال الحالة غير الصالحة الذي يتوافق مع التزامهم مقطوع. 4. يحصل كل validator على مهمة أجزاء جديدة، ويتم جدولة حقبة جديدة للبدء بعد مرور بعض الوقت الكافي لجميع validators لتنزيل الملف الحالة، كما هو موضح في الشكل 26. لاحظ أنه منذ اللحظة التي تكشف فيها validators عن الأجزاء المخصصة لها حتى يبدأ العصر الجديد، يتم تقليل أمان النظام منذ ذلك الحين تم الكشف عن مهمة القطع. يحتاج المشاركون في الشبكة إلى الاحتفاظ بها في الاعتبار أثناء استخدام الشبكة خلال هذه الفترة. 3.8 تجميع التوقيع لكي يعمل نظام يحتوي على مئات القطع بشكل آمن، نريد أن يكون لدينا طلب 10000 أو أكثر validators. كما تمت مناقشته في القسم 3.7، نريد كلًا منهماالشكل 26: التعامل مع التحدي validator لنشر التزام برسالة معينة وتوقيع في المتوسط مرة واحدة لكل كتلة. حتى لو كانت رسائل الالتزام هي نفسها، فإن تجميع مثل هذا كان من الممكن أن يكون توقيع BLS والتحقق من صحته مكلفًا للغاية. لكن من الطبيعي أن رسائل الالتزام والكشف ليست هي نفسها عبر validators، وبالتالي نحتاج إلى طريقة ما لتجميع هذه الرسائل والتوقيعات في ملف واحد الطريقة التي تسمح للتحقق السريع في وقت لاحق. النهج المحدد الذي نستخدمه هو ما يلي: ينضم المدققون إلى منتجي الكتل. منتجو الكتلة معروفون بعض الوقت قبل بدء العصر، حيث أنهم يحتاجون إلى بعض الوقت لتنزيل الملف الحالة قبل بدء العصر، وعلى عكس validators فإن منتجي الكتل هم غير مخفي. كل منتج كتلة لديه فتحات v validator. يقدم المصادقون يتم إدراج المقترحات خارج السلسلة لمنتجي الكتل كواحدة من مشاريعهم v validators. إذا رغب منتج الكتلة في تضمين validator، فعليه إرسال أ المعاملة التي تحتوي على الطلب الأولي خارج السلسلة من validator، و توقيع منتج الكتلة الذي يجعل validator ينضم إلى منتج الكتلة. لاحظ أن validators المخصصة لمنتجي الكتل ليس بالضرورة التحقق من صحة نفس القطع التي ينتجها منتج الكتلة. إذا أ تم تقديم validator للانضمام إلى العديد من منتجي الكتل، فقط المعاملة من سوف ينجح منتج الكتلة الأول. يقوم منتجو الكتل بجمع الالتزامات. يقوم منتج الكتلة باستمرار بجمع رسائل الالتزام والكشف من validators. بمجرد تجميع عدد معين من هذه الرسائل، يقوم منتج الكتلة بحساب Merkle شجرة هذه الرسائل، ويرسل إلى كل validator جذر Merkle و مسار ميركل إلى رسالتهم. يقوم validator بالتحقق من صحة المسار وتسجيل الدخول جذر ميركل. يقوم منتج الكتلة بعد ذلك بتجميع توقيع BLS على ملف جذر Merkle من validators، وينشر فقط جذر Merkle و التوقيع المتراكم يوقع منتج الكتلة أيضًا على صلاحية التوقيع المتعدد باستخدام توقيع ECDSA الرخيص. إذا لم يكن التوقيع المتعدد كذلك مطابقة جذر Merkle الذي تم إرساله أو قناع البت الخاص بـ validators المشاركة، فهو سلوك قابل للتقطيع. عند مزامنة السلسلة، أحد المشاركين يمكن اختيار التحقق من صحة جميع توقيعات BLS من validators (وهو أمر مكلف للغاية لأنه يتضمن تجميع مفاتيح validators العامة)، أو فقطتوقيعات ECDMA من منتجي الكتل وتعتمد على حقيقة أن لم يتم تحدي منتج الكتلة أو قطعه. استخدام المعاملات عبر السلسلة وإثباتات ميركل للتحديات. ذلك يمكن ملاحظة أنه لا قيمة لكشف الرسائل من validators إذا كان الجواب لا تم اكتشاف انتقال حالة غير صالح. فقط الرسائل التي تحتوي على الفعلي يجب الكشف عن إثباتات انتقال الحالة غير الصالحة، وذلك بالنسبة لمثل هذه الرسائل فقط يجب أن يُظهر أنها تتطابق مع الالتزام السابق. الرسالة تحتاج إلى يتم الكشف عنها لغرضين: 1. للبدء فعليًا في التراجع عن السلسلة إلى اللحظة التي سبقت انتقال الحالة غير صالح (انظر القسم 3.7.5). 2. لإثبات أن validator لم يحاول إثبات صحة قطعة غير صالحة وفي كلتا الحالتين لا بد من معالجة مسألتين: 1. لم يتم تضمين الالتزام الفعلي في السلسلة، بل تم تضمين جذر Merkle فقط الالتزام مجمعة مع رسائل أخرى. يحتاج validator إلى استخدام مسار Merkle المقدم من منتج الكتلة والتزامه الأصلي به إثبات أنهم ملتزمون بالتحدي. 2. من الممكن أن تكون جميع validators المخصصة للجزء غير صالحة يحدث أن يتم تعيين انتقال الحالة إلى منتجي الكتل الفاسدين يقومون بمراقبةهم. للتغلب على ذلك، نسمح لهم بتقديم كشفهم كمعاملة منتظمة على السلسلة وتجاوز التجميع. هذا الأخير مسموح به فقط لإثباتات انتقال الحالة غير الصالحة، وهي نادر للغاية، وبالتالي لا ينبغي أن يؤدي إلى إرسال بريد عشوائي إلى الكتل. والمسألة الأخيرة التي تحتاج إلى معالجة هي أن منتجي الكتل قادرون على ذلك اختر عدم المشاركة في تجميع الرسائل أو فرض رقابة متعمدة على validators. نحن نجعلها غير مواتية اقتصاديًا، من خلال صنع الكتلة مكافأة المنتج تتناسب مع عدد validators المخصص لهم. نحن لاحظ أيضًا أنه نظرًا لأن منتجي الكتل بين العصور يتقاطعون إلى حد كبير (منذ ذلك الحين إنه دائمًا أعلى المشاركين ذوي أعلى حصة)، يمكن لـ validators التمسك إلى حد كبير بالعمل مع نفس منتجي الكتل، وبالتالي تقليل المخاطر من التعيين إلى منتج الكتل الذي فرض رقابة عليهم في الماضي. 3.9 سلسلة اللقطات نظرًا لأنه يتم إنتاج الكتل الموجودة على السلسلة الرئيسية بشكل متكرر جدًا، فقد تم تنزيلها قد يصبح التاريخ الكامل باهظ الثمن بسرعة كبيرة. علاوة على ذلك، منذ كل تحتوي الكتلة على توقيع BLS لعدد كبير من المشاركين، وقد يصبح مجرد تجميع المفاتيح العامة للتحقق من التوقيع أمرًا محظورًا مكلفة كذلك. أخيرًا، نظرًا لأنه في المستقبل المنظور، من المحتمل أن يظل Ethereum 1.0 واحدًا من أكثر blockchains استخدامًا، والتي تتمتع بطريقة مفيدة لنقل الأصول منها

يعد القرب من Ethereum أحد المتطلبات، واليوم يتم التحقق من توقيعات BLS لضمان ذلك صلاحية الكتل القريبة من جانب Ethereum غير ممكنة. يمكن أن تحتوي كل كتلة في سلسلة Nightshade الرئيسية بشكل اختياري على Schnorr التوقيع المتعدد على رأس الكتلة الأخيرة التي تضمنت مثل شنور التوقيع المتعدد. نحن نسمي هذه الكتل كتل لقطة. الكتلة الأولى من يجب أن يكون كل عصر عبارة عن كتلة لقطة. أثناء العمل على مثل هذا التوقيع المتعدد، يجب على منتجي الكتل أيضًا تجميع توقيعات BLS الخاصة بـ validators في كتلة اللقطة الأخيرة، وقم بتجميعها بنفس الطريقة الموضحة في القسم 3.8. نظرًا لأن مجموعة منتجي الكتل ثابتة طوال العصر، يتم التحقق من صحتها تكفي فقط مجموعات اللقطات الأولى في كل عصر على افتراض عدم وجود ذلك تشير نسبة كبيرة من منتجي الكتل وvalidator إلى تواطؤهم وإنشاءهم شوكة. يجب أن تحتوي الكتلة الأولى من العصر على معلومات كافية للحساب منتجو الكتل و validators لهذا العصر. نطلق على السلسلة الفرعية للسلسلة الرئيسية التي تحتوي على اللقطة فقط كتل سلسلة لقطة. يعد إنشاء توقيع متعدد لشنور عملية تفاعلية، ولكن بما أننا تحتاج فقط إلى تنفيذها بشكل غير متكرر، بغض النظر عن مدى عدم فعاليتها سوف يكفي. يمكن التحقق من صحة التوقيعات المتعددة لشنور بسهولة على Ethereum، وبالتالي توفير الأساسيات الحاسمة لطريقة آمنة لأداء cross-blockchain الاتصالات. للمزامنة مع السلسلة القريبة، يحتاج المرء فقط إلى تنزيل جميع اللقطات الكتل والتأكد من صحة توقيعات شنور (اختياريًا أيضًا التحقق من توقيعات BLS الفردية الخاصة بـ validators)، ثم المزامنة فقط كتل السلسلة الرئيسية من كتلة اللقطة الأخيرة.

خاتمة

ناقشنا في هذه الوثيقة أساليب بناء blockchains و غطت تحديين رئيسيين مع النهج الحالي، وهما صلاحية الدولة وتوافر البيانات. ثم قدمنا ​​Nightshade، وهو تصميم مقسم صلاحيات NEAR البروتوكول. التصميم قيد التنفيذ، إذا كان لديك تعليقات أو أسئلة أو ملاحظات في هذا المستند، يرجى الانتقال إلى https://near.chat.