صحة الدولة وتوافر البيانات
الفكرة الأساسية في 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 على هذا النحو الطريقة التي يكون بها النظام آمنًا حتى لو أصبحت بعض الكتل القديمة في بعض القطع غير متوفر تماما.
状态有效性和数据可用性
分片 blockchain 的核心思想是大多数参与者操作或 使用网络无法验证所有分片中的块。因此，每当 任何参与者都需要与他们通常无法进行的特定分片进行交互 下载并验证分片的整个历史记录。 然而，分片的分区方面带来了巨大的潜力 问题：没有下载和验证特定的整个历史记录 分片参与者不一定能确定分片的状态 5 除第 2.5.3 小节外，本节先前发布于 https://near.ai/ 碎片2。如果您之前阅读过，请跳至下一部分。
它们相互作用是一些有效的块序列的结果，并且这种序列 区块确实是分片中的规范链。一个不存在的问题 存在于非分片 blockchain 中。 我们首先将针对已提出的这个问题提出一个简单的解决方案 通过许多协议，然后分析这个解决方案如何破坏以及什么 已经尝试解决这个问题。 2.1 验证者轮换 状态有效性的朴素解决方案如图 5 所示：假设我们假设 整个系统有数千个 validator 的数量级，其中 不超过 20% 是恶意的或会失败（例如未能 在线生成区块）。那么如果我们采样 200 validators，概率 超过 1 个 3 出于实际目的，失败可以假设为零。 图5： 采样 validators 1 3是一个重要的门槛。有一系列共识协议，称为 BFT 共识协议，保证只要少于 1 3 个 参与者失败了，要么是崩溃了，要么是以某种违反规则的方式行事 协议，达成共识。 假设诚实的 validator 百分比，如果当前集合 分片中的 validators 为我们提供了一些块，天真的解决方案假设 该块是有效的，并且它是建立在 validator 所认为的基础上的 当他们开始验证时该分片的规范链。 validators 从前一组 validator 中学习了规范链，它们由相同的 假设建立在作为规范链头部的区块之上 在那之前。通过归纳，整个链都是有效的，并且因为没有 validator 集合 在任何产生分叉的点，简单的解决方案也可以确定当前 chain 是分片中唯一的链。可视化见图 6。
图6： 每个区块都通过 BFT 共识最终确定的 blockchain 如果我们假设 validators 可以是 自适应地损坏，这不是一个不合理的假设6。适应性地 损坏具有 1000 个分片的系统中的单个分片的成本要低得多 而不是破坏整个系统。因此，协议的安全性随着分片数量的增加而线性下降。确定其有效性 一个区块，我们必须知道，在历史上的任何时刻，系统中都没有分片 大多数 validator 串通一气；有了适应性强的对手，我们不再有 这样的确定性。正如我们在 1.5 节中讨论的，串通 validators 可以行使 两种基本的恶意行为：创建分叉和产生无效区块。 恶意分叉可以通过与信标链交叉链接的区块来解决，信标链通常被设计为具有比信标链更高的安全性 分片链。 然而，产生无效块是一个更严重的问题。 具有挑战性的问题需要解决。 2.2 状态有效性 考虑图 7，其中 Shard #1 已损坏并且恶意行为者产生了 无效区块 B。假设在该区块 B 中，有 1000 个 token 被铸造出来 爱丽丝账户上的空气。然后，恶意行为者会生成有效的区块 C（在 感觉 C 中的交易被正确应用）在 B 之上，混淆 无效块 B，并向分片 #2 发起跨分片交易 将这 1000 个 token 转入 Bob 的帐户。从这一刻起，不当行为 创建的 token 驻留在分片 #2 中完全有效的 blockchain 上。 解决这个问题的一些简单方法是： 6阅读 这个 文章 为了 详情 上 如何 适应性 腐败 可以 是 携带 输出： https://medium.com/nearprotocol/d859adb464c8. 对于 更多 详情 上 适应性 腐败， 读 https://github.com/ethereum/wiki/wiki/Sharding-FAQ# 我们正在使用什么安全模型图7： 来自具有无效块的链的跨分片交易 1. 对于分片 #2 的 validators 来验证交易所在的块 已启动。即使在上面的例子中这也不起作用，因为块 C 似乎是完全有效的。 2. 对于分片 #2 中的 validators，验证发起交易的区块之前的大量区块。自然地，对于 由接收分片验证的任意数量的块 N 恶意 validators 可以在无效块之上创建 N+1 个有效块 产生的。 解决这个问题的一个有前途的想法是将分片排列成 无向图，其中每个分片都连接到其他几个分片，以及 只允许相邻分片之间的跨分片交易（例如，这就是 Vlad Zamfir 的分片本质上是有效的7，Kadena 的分片也使用了类似的想法 Chainweb [1])。如果分片之间需要跨分片交易 不是邻居，此类事务通过多个分片路由。在这个设计中 每个分片中的 validator 预计会验证其分片中的所有块 以及所有相邻分片中的所有块。考虑下图 有 10 个分片，每个分片有 4 个邻居，并且没有两个分片需要更多 跨分片通信的跳数少于图 8 所示。 分片 #2 不仅验证其自己的 blockchain，还验证 blockchain 所有邻居，包括 1 号分片。因此，如果 Shard #1 上有恶意行为者 试图创建一个无效的块 B，然后在其上构建块 C 并发起跨分片交易，这样的跨分片交易不会走 自从分片 #2 将验证分片 #1 的整个历史以来， 会导致它识别无效的块B。 7在此处阅读有关设计的更多信息：https://medium.com/nearprotocol/37e538177ed9
图8： 类链网系统中无效的跨分片交易将 被发现 虽然破坏单个分片不再是一种可行的攻击，但破坏一个分片 碎片很少仍然是一个问题。在图 9 中，对手破坏了两个分片
1 和分片 #2 成功执行到分片 #3 的跨分片交易
来自无效区块 B 的资金： 图9： 类链网系统中无效的跨分片交易将 不被检测到 分片 #3 验证分片 #2 中的所有块，但不验证分片 #1 中的所有块，并且 无法检测恶意块。 妥善解决状态有效性有两个主要方向：
和计算的密码证明。 2.3 渔夫 第一种方法背后的想法如下：每当块头 出于任何目的（例如交叉链接到 信标链，或跨分片交易），有一段时间 任何诚实的 validator 都可以提供该块无效的证据。那里 是各种结构，可以非常简洁地证明这些块是 无效，因此接收节点的通信开销要小得多 比收到一个完整的块。 只要存在至少一个诚实的 validator ，就可以使用这种方法 分片，系统是安全的。 图10： 渔夫 这是当今提议的协议中的主要方法（除了假装问题不存在之外）。 然而，这种方法有两个 主要缺点： 1. 对于诚实的validator来说，挑战期需要足够长 识别一个块已生成，下载它，完全验证它，并准备 如果块无效则提出挑战。 引入这样一个时期将 显着减慢跨分片交易的速度。 2. 挑战协议的存在创造了新的攻击向量 当恶意节点发送带有无效挑战的垃圾邮件时。一个显而易见的解决方案 解决这个问题的方法是让挑战者存入一定数量的 token 如果挑战有效则返回。这只是部分解决方案，因为它 对于对手向系统发送垃圾邮件（并烧毁 存款）进行无效挑战，例如阻止有效的挑战来自诚实的 validator 的挑战。这些攻击是 称为悲伤攻击。 有关解决后一点的方法，请参阅第 3.7.2 节。 2.4 简洁的非交互式知识论证 多分片损坏的第二种解决方案是使用某种加密结构，允许人们证明某种计算（例如 因为从一组交易中计算一个块）被正确执行。 这种结构确实存在，例如zk-SNARKs、zk-STARKs 和其他一些， 有些目前在 blockchain 协议中积极用于私人支付， 最值得注意的是 ZCash。这些原语的主要问题是它们 众所周知，计算速度很慢。例如。 Coda 协议，使用 zk-SNARK 特别是为了证明 blockchain 中的所有块都是有效的，如 的采访表明，每笔交易可能需要 30 秒才能创建证明 （现在这个数字可能更小）。 有趣的是，证明不需要由受信任方计算，因为 该证明不仅证明了其所构建的计算的有效性，而且证明了 证明本身的有效性。因此，此类证明的计算可以分开 一组参与者之间的冗余度明显低于实际情况 执行一些无需信任的计算所必需的。它还允许参与者 他们计算 zk-SNARK 在特殊硬件上运行，而不降低 系统的去中心化。 除了性能之外，zk-SNARK 的挑战还包括： 1. 依赖于研究较少且测试较少的密码原语； 2.“有毒废物”——zk-SNARK 依赖于一个可信的设置，其中一个组 的人执行一些计算，然后丢弃中间结果 该计算的值。如果程序的所有参与者都串通 并保留中间值，可以创建假证明； 3. 系统设计引入额外的复杂性； 4. zk-SNARK 仅适用于可能计算的子集，因此协议 使用图灵完备的 smart contract 语言将无法使用 SNARKs 证明链的有效性。 2.5 数据可用性 我们要讨论的第二个问题是数据可用性。一般节点 操作特定的 blockchain 分为两组：完整节点， 那些下载每个完整区块并验证每笔交易的人，以及 Light 节点，仅下载区块头并使用 Merkle 证明作为部分的节点 他们感兴趣的状态和交易，如图 11 所示。
图11： 默克尔树 现在，如果大多数全节点串通，他们可以生成一个区块，有效或 无效，并将其 hash 发送到轻节点，但绝不泄露完整内容 块的。他们可以通过多种方式从中受益。例如， 考虑图 12： 图 12： 数据可用性问题 共有三个区块：前一个 A，是由诚实的 validators 产生的； 当前 B 有 validator 串通；下一个C也将被生产 由诚实的 validators 提供（blockchain 位于右下角）。 你是一个商人。当前块（B）接收块的validators 来自之前的 validator 的 A，计算出您收到资金的区块，并向您发送了该区块的标头，其中包含状态的 Merkle 证明 你有钱（或者发送这笔钱的有效交易的 Merkle 证明） 给你）。确认交易完成后，您即可提供服务。 然而，validators 永远不会将块 B 的全部内容分发给 任何人。因此，块 C 的诚实 validators 无法检索该块，并且 要么被迫停止系统，要么在 A 之上构建，剥夺你作为 金钱商人。 当我们将相同的场景应用于分片时，完整和分片的定义 轻节点通常适用于每个分片：每个分片中的 validators 每下载一次 阻止该分片并验证该分片中的每笔交易，但其他 系统中的节点，包括那些将分片链状态快照到 信标链，仅下载标头。因此分片中的 validator 是 该分片的有效完整节点，而系统中的其他参与者， 包括信标链，作为轻节点运行。 为了使我们上面讨论的渔夫方法发挥作用，诚实的validators 需要能够下载与信标链交叉链接的块。 如果恶意 validators 交叉链接无效块的标头（或使用它来 发起跨分片交易），但从未分发过区块，诚实的人 validators 无法制定挑战。 我们将介绍解决这个问题的三种方法，这些方法相互补充 彼此。 2.5.1 监护权证明 最迫切需要解决的问题是区块一次是否可用 它被出版了。 一个提议的想法是让所谓的公证人进行轮换 分片之间比 validators 更频繁，其唯一的工作就是下载 阻止并证明他们能够下载它。他们可以是 轮换更频繁，因为他们不需要下载整个状态 分片的，与 validator 不同，后者不能频繁轮换，因为它们 每次旋转时都必须下载分片的状态，如图所示 13. 这种幼稚方法的问题是无法在以后证明 公证人是否能够下载该块，因此公证人 可以选择始终证明他们能够下载该块而无需 甚至试图找回它。解决此问题的一种方法是公证人提供 一些证据或抵押一定数量的 token 来证明该区块是 下载了。这里讨论了一种这样的解决方案：https://ethresear.ch/t/ 1 位聚合友好托管债券/2236。 2.5.2 纠删码 当特定的轻节点收到一个区块的 hash 时，增加该节点的 确信该块可用，它可以尝试下载一些随机的 块的碎片。这不是一个完整的解决方案，因为除非轻节点 共同下载恶意区块生产者可以选择的整个区块
图 13： 验证者需要下载状态，因此无法轮换 经常 保留未由任何轻节点下载的块部分， 从而仍然使该块不可用。 一种解决方案是使用一种称为纠删码的结构来使其成为可能 即使只有部分块可用，也可以恢复整个块，如图所示 如图 14 所示。 图 14： Merkle tree 建立在纠删码数据之上 Polkadot 和 Ethereum Serenity 都围绕这个想法进行设计 为轻节点提供一种合理确信区块可用的方法。 Ethereum Serenity 方法在 [2] 中有详细描述。2.5.3 Polkadot 的数据可用性方法 在 Polkadot 中，与大多数分片解决方案一样，每个分片（称为平行链）将其块快照到信标链（称为中继链）。假设有 2f + 1 中继链上的 validators。平行链区块的区块生产者，称为 整理者，一旦生成了平行链区块，就计算该区块的纠删码版本，该版本由 2f +1 个部分组成，这样任何 f 个部分就足够了 重建块。然后，他们将一份零件分发给 validator 上的每个 validator 中继链。特定中继链 validator 只会在中继链上签名 块，如果它们对每个被快照的平行链块都有自己的部分 这样的中继链区块。因此，如果中继链区块具有来自 2f + 1 的签名 validators，只要不超过 f 个违反协议，每个 平行链区块可以通过从 validators 中获取部分来重建 遵循协议。见图 15。 图 15： Polkadot 的数据可用性 2.5.4 长期数据可用性 请注意，上面讨论的所有方法仅证明了以下事实：块 已全部发布，并且现已可用。块稍后可能会变得不可用 由于多种原因：节点离线、节点故意删除历史记录 数据等。 值得一提的解决此问题的白皮书是 Polyshard [3]， 它使用纠删码来使块可以跨分片使用，即使多个分片 分片完全丢失数据。不幸的是，他们的具体方法需要 所有分片从所有其他分片下载块，这是令人望而却步的 昂贵。 长期可用性并不是一个紧迫的问题：因为没有参与者 系统中预计能够验证所有链中的所有链
分片，分片协议的安全性需要这样设计 即使某些分片中的某些旧块变得如此，系统也是安全的 完全不可用。
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)، ثم المزامنة فقط كتل السلسلة الرئيسية من كتلة اللقطة الأخيرة.
Nightshade
3.1 从分片链到分片块 具有分片链和信标链的分片模型非常强大，但是 具有一定的复杂性。特别需要执行分叉选择规则 分别在每个链中，分片链和信标中的分叉选择规则 链必须以不同的方式构建并单独测试。 在 Nightshade 中，我们将系统建模为单个 blockchain，其中每个 块逻辑上包含所有分片的所有交易，并更改 所有分片的完整状态。然而，实际上，没有参与者下载 完整状态或完整逻辑块。相反，网络的每个参与者仅 维护与验证交易的分片相对应的状态，并且块中所有交易的列表被分为物理部分 块，每个分片一个块。 在理想条件下，每个块每个分片仅包含一个块 块，它大致对应于分片链的模型，其中 分片链产生区块的速度与信标链相同。然而， 由于网络延迟，某些块可能会丢失，因此实际上每个块 每个分片包含一个或零个块。有关如何操作的详细信息，请参阅第 3.3 节 块被生产出来。 图 16： 左侧有分片链且其中一条链具有 块在右侧分成块
3.2 共识 今天 blockchain 达成共识的两种主要方法是 最长（或最重）的链，其中具有最多工作量或权益的链 用于构建它被认为是规范的，并且 BFT，其中每个块都有一些 validator 组达成 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 节），他们可以收集签名 其他区块生产者和 validator 证明前一个区块。参见部分 3.8 了解如何聚合如此大量的签名的详细信息。重量 8另请参阅 Justin Drake 的白板会议，深入了解 Casper FFG，以及它如何与 GHOST 最重链共识集成：https://www. youtube.com/watch?v=S262StTwkmo一个区块的总权益就是所有签名者的累积权益 包含在块中。链的权重是块权重的总和。 在最重链共识之上，我们使用了一个最终性小工具，该小工具使用 完成区块的证明。为了降低系统的复杂度， 我们使用一个最终性小工具，它不会以任何方式影响分叉选择规则， 相反，只引入额外的削减条件，这样一旦一个块被 由最终性小工具最终确定，除非有很大比例，否则分叉是不可能的 总股份被削减。 Casper CBC 就是这样一个最终结果小工具，我们 目前模型考虑的是 Casper CBC。 我们还致力于一个名为 TxFlow 的独立 BFT 协议。当时 撰写本文档时，尚不清楚是否会使用 TxFlow 来代替 Casper 加拿大广播公司。然而，我们注意到，最终性小工具的选择很大程度上与设计的其余部分正交。 3.3 区块生产 在 Nightshade 中有两个角色：区块生产者和 validators。 在任何 点系统包含 w 个区块生产者，在我们的模型中 w = 100，并且 wv validators，在我们的模型中 v = 100, wv = 10, 000。该系统是权益证明系统， 这意味着区块生产者和 validators 都有一定数量的内部 货币（称为“tokens”）锁定时间远远超过 他们花时间履行构建和验证链的职责。 与所有权益证明系统一样，并非所有 w 区块生产者也不是 所有 wv validator 都是不同的实体，因为无法强制执行。每个 然而，w 区块生产者和 wv validators 确实有一个单独的 股份。 系统包含 n 个分片，在我们的模型中 n = 1000。正如中提到的 第 3.1 节，在 Nightshade 中，没有分片链，而是所有区块生产者和 validator 都在构建一个 blockchain，我们将其称为 主链。主链的状态被分成n个分片，每个区块 生产者和 validator 在任何时刻都只在本地下载了一个子集 对应于分片的某个子集的状态，并且仅处理和 验证影响状态这些部分的交易。 要成为区块生产者，网络参与者需要锁定一些大的区块 数量 tokens（股份）。网络的维护是分周期完成的， 其中纪元是一段以天为单位的时间段。 参加者 在特定时期开始时，w 最大的赌注是区块 那个时代的生产者。每个区块生产者都被分配给 sw 分片（比如 sw = 40，这将使 sww/n = 每个分片有 4 个区块生产者）。街区 生产者下载纪元之前分配给他们的分片的状态 开始，并在整个纪元中收集影响该分片的交易， 并将它们应用到国家。 对于主链上的每个区块 b 和每个分片 s，都有一个 将区块生产者分配给 s，s 负责生产与 b 相关的部分 到碎片。 b 中与 shard s 相关的部分称为 chunk，包含 b 中包含的分片交易列表以及 merkle结果状态的根。 b 最终只会包含一个非常小的标头 块，即所有应用交易的 Merkle 根（参见部分 3.7.1 了解具体细节），以及最终状态的 merkle 根。 在文档的其余部分中，我们经常提到区块生产者 负责在特定时间为特定分片生成块 作为块生产者。区块生产者始终是区块生产者之一。 块生产者和块生产者根据以下方式轮换每个块： 到固定的时间表。区块生产者有订单并重复生产 按该顺序块。 例如。 如果有 100 个区块生产者，则第一个区块 生产者负责生产区块 1、101、201 等，第二个是 负责生产2、102、202等）。 由于块生产与块生产不同，需要维护 状态，对于每个分片，只有 sww/n 块生产者维护状态 每个分片，相应地只有那些 sww/n 块生产者轮流创建 大块。例如。上面的常量被分配给四个区块生产者 每个分片，每个块生产者将每四个块创建一次块。 3.4 确保数据可用性 为了确保数据可用性，我们使用类似于 Polkadot 的方法 2.5.3 节中描述。一旦区块生产者产生了一个区块，他们就会创建 它的纠删码版本，具有最佳 (w, ⌊w/6 + 1⌋) 块代码 块。 然后，他们发送一块纠删码块（我们称这些块为 块部分，或只是部分）到每个块生产者。 我们计算一棵默克尔树，其中包含作为叶子的所有部分，并且 每个块的标头包含该树的默克尔根。 这些部件通过 onepart 消息发送到 validators。每一条这样的消息 包含块头、部分序号和部分内容。的 消息还包含产生该区块的区块生产者的签名 chunk 和merkle路径来证明该部分对应于header 并由适当的区块生产者生产。 一旦区块生产者收到主链区块，他们首先检查是否 块中包含的每个块都有 onepart 消息。如果没有，则块 在检索到丢失的 onepart 消息之前不会进行处理。 一旦收到所有 onepart 消息，区块生产者就会获取 来自对等体的剩余部分并重建它们所持有的块 国家。 区块生产者不会处理主链区块，如果至少有一个 块中包含的块没有相应的 onepart 消息，或者如果对于至少一个分片，他们无法维护其状态 重建整个块。 对于可用的特定块，该块的 ⌊w/6⌋+1 就足够了 生产者有自己的部分并为他们服务。因此，只要数量 恶意行为者不超过⌊w/3⌋没有超过一半区块的链 构建它的生产者可能有不可用的块。图 17： 每个块包含每个分片一个或零个块，并且每个块 是擦除编码的。纠删码块的每个部分都被发送到指定的 区块生产者通过特殊的 onepart 消息 3.4.1 对付懒惰的区块生产者 如果区块生产者有一个区块缺少 onepart 消息，那么他们 可能会选择仍然在其上签名，因为如果该块最终在链上 将使区块生产者的奖励最大化。区块没有风险 生产者，因为事后无法证明区块生产者没有 onepart 消息。 为了解决这个问题，我们在创建块时让每个块生成器 为未来编码块的每个部分选择一种颜色（红色或蓝色），并存储 编码之前块中指定颜色的位掩码。每一个部分 然后消息包含分配给该部件的颜色，并且在以下情况下使用该颜色 计算编码部分的默克尔根。如果块生产者偏离 从协议中，可以很容易地证明这一点，因为默克尔根不会 对应于 onepart 消息，或者 onepart 消息中的颜色 对应于merkle根将与块中的掩码不匹配。 当区块生产者签署区块时，它们会包含所有区块的位掩码 他们收到的红色部分是块中包含的块。出版一个 不正确的位掩码是一种可削减的行为。如果区块生产者还没有收到 onepart 消息，他们无法知道消息的颜色，并且 因此，如果他们试图盲目地签署协议，就有 50% 的机会被削减 块。 3.5 状态转换申请 块生产者仅选择要包含在块中的交易，但是 当它们生成块时不应用状态转换。相应地，
块头包含之前默克尔化状态的默克尔根 应用块中的事务。 仅当包含该块的完整块时才应用事务 已处理。参与者仅处理一个块，如果 1. 前一个区块被接收并处理； 2.对于每个块，参与者不维护他们拥有的状态 看到了 onepart 消息； 3. 对于每个块，参与者确实维护状态，因为他们有 完整的块。 一旦块被处理，对于参与者的每个分片 维护状态，他们应用交易并计算新状态 在应用交易后，它们就准备好生产 下一个块的块（如果它们被分配给任何分片），因为它们有 新默克尔化状态的默克尔根。 3.6 跨分片交易和收据 如果一笔交易需要影响多个分片，则需要连续进行 在每个分片中单独执行。完整的交易被发送到第一个分片 受影响，并且一旦交易包含在此类分片的块中，并且 在块包含在块中之后应用，它会生成所谓的收据 交易，即路由到交易需要的下一个分片 被处决。如果需要更多步骤，则执行收据交易 生成新的收据交易等。 3.6.1 收据交易生命周期 理想的是，收据交易应用于紧随其生成的块之后的块中。收据交易仅 区块生产者收到并应用前一个区块后生成 维护原始分片，并且需要在 下一个块的块由目的地的块生产者生成 碎片。因此，收据必须从源分片传送到 这两个事件之间的短时间内的目标分片。 令 A 为最后产生的区块，其中包含生成收据 r 的交易 t。令 B 为下一个生成的块（即具有 A 的块） 它的前一个块）我们想要包含 r。设 t 在分片 a 中，r 为 在碎片 b. 收据的生命周期（也如图 18 所示）如下： 制作并保存收据。分片的块生产者 cpa a 接收区块 A，应用交易 t 并生成收据 r。注册会计师 然后将所有此类生成的收据存储在其索引的内部持久存储中 通过源分片 ID。分发收据。一旦 cpa 准备好生成块 块 B 的分片 a，它们获取通过应用分片 a 的块 A 中的交易而生成的所有收据，并将它们包含到 shrad 的块中 块 B 中的 a。一旦生成这样的块，cpa 就会生成其纠删码 版本和所有相应的 onepart 消息。 cpa 知道哪些区块生产者维护哪些分片的完整状态。对于特定的区块生产者 bp cpa 包括在 A 块中应用交易产生的收据 对于具有 bp 关心的任何分片作为其目的地的分片 a 当他们在块 B 中分发分片 a 的块时，在 onepart 消息中 （见图 17，显示了 onepart 消息中包含的收据）。 收到收据。请记住，参与者（区块生产者和 validators）在收到 onepart 消息之前不会处理区块 对于块中包含的每个块。因此，当任何特定参与者应用块 B 时，他们拥有对应于的所有 onepart 消息 B 中的块，因此它们拥有包含分片的所有传入收据 参与者将状态维持为目的地。 当应用 特定分片的状态转换，参与者应用两个收据 他们在 onepart 消息中为分片收集的信息，以及所有 包含在块本身中的事务。 图 18： 收据交易的生命周期 3.6.2 处理过多的收据 有可能针对某个特定分片的收据数量 特定块太大而无法处理。例如，考虑图 19， 每个分片中的每笔交易都会生成一个针对分片 1 的收据。 到下一个块时，分片 1 需要处理的收据数量为 与处理时所有碎片组合处理的负载相当 前一个块。
图 19： 如果所有收据都针对同一个分片，则该分片可能没有 处理它们的能力 为了解决这个问题，我们使用了类似于 QuarkChain 9 中使用的技术。 具体来说，对于每个分片，最后一个块 B 和该分片中的最后一个分片 s 记录应用收据的块。当新分片出现时 创建后，收据首先从 B 中的剩余分片中应用， 然后在 B 之后的块中，直到新块已满。正常情况下 负载均衡的情况下，一般会导致所有收据 正在应用（因此最后一个块的最后一个分片将被记录为 每个块），但在负载不平衡的时候，以及特定的 分片收到不成比例的大量收据，这种技术使他们能够 进行处理，同时遵守所包含交易数量的限制。 请注意，如果这种不平衡负载持续较长时间，则延迟 收据创建直到应用程序可以无限期地继续增长。一 解决这个问题的方法是删除任何创建收据的交易 处理延迟超过某个常量（例如一个时期）的分片。 考虑图 20。到了区块 B，分片 4 无法处理所有收据， 因此它只处理来自区块 A 中最多分片 3 的收据，并且 记录下来。在区块 C 中，包含区块 B 中最多分片 5 的收据，并且 然后到了块 D，分片赶上了，处理所有剩余的收据 B 块和 C 块的所有收据。 3.7 块验证 为特定分片生成的块（或在具有分片链的模型中为特定分片链生成的分片块）只能由 9查看 QuarkChain 的白板片段：https://www.youtube.com/watch? v=opEtG6NM4x4，其中讨论了跨分片交易的方法等 东西图 20： 延迟收据处理 维持状态的参与者。他们可以是区块生产者，validators， 或者只是下载状态并验证分片的外部见证人 他们存储资产。 在本文档中，我们假设大多数参与者无法存储 大部分分片的状态。不过值得一提的是， 存在分片 blockchain ，其设计假设为 大多数参与者确实有能力存储状态并验证大部分 分片，例如 QuarkChain。 由于只有一小部分参与者拥有验证分片的状态 块，有可能自适应地破坏具有 状态，并应用无效的状态转换。 提出了多重分片设计，每隔几次采样 validators 天，以及一天之内分片链中任何拥有超过 2/3 的区块 立即考虑分配给此类分片的 validator 的签名 最终。通过这种方法，自适应对手只需要破坏 2n/3+1 分片链中的 validators 来应用无效状态转换，其中， 虽然可能很难实现，但对于公众来说安全水平还不够 blockchain。 正如第 2.3 节中所讨论的，常见的方法是在为任何具有状态的参与者（无论是 它是一个区块生产者、validator 或外部观察者）来挑战其有效性。这些参与者被称为渔民。为了让渔民能够 挑战无效区块，必须确保这样的区块可供使用 他们。 Nightshade 中的数据可用性将在第 3.4 节中讨论。 在 Nightshade 中，一旦生成了一个块，这些块就不会被验证 除了实际的块生产者之外的任何人。特别是，区块生产者 建议该块自然不具有大多数分片的状态，并且无法验证这些块。当下一个区块产生时，它包含多个区块生产者和 validator 的证明（参见第 3.2 节）， 但由于大多数区块生产者和 validator 不维护状态 对于大多数分片来说，只有一个无效块的区块将收集超过一半的证明，并且将继续处于最重的状态 链。 为了解决这个问题，我们允许任何维持以下状态的参与者 一个分片，用于针对该分片中产生的任何无效块在链上提交挑战 碎片。 3.7.1 状态有效性挑战 一旦参与者检测到特定块无效，他们需要提供该块无效的证明。由于大多数网络参与者不维护无效块所在分片的状态 产生后，证明需要有足够的信息来确认该块是 无状态无效。 我们设置单个事务的状态量（以字节为单位）的限制 Ls 可以累积读取或写入。任何触及 Ls 以上的交易 状态被认为是无效的。请记住 3.5 节中的块 特定区块B中仅包含要应用的交易，但不包含 新的状态根。块B中的块包含的状态根是状态 在应用此类事务之前，但在应用事务之后 块 B 之前同一分片中的最后一个块。恶意行为者 希望应用无效的状态转换将包括不正确的状态根 在块 B 中，它与应用产生的状态根不对应 前一个块中的交易。 我们扩展块生产者在块中包含的信息。 它不是只包含应用所有事务后的状态，而是 在应用每个连续的交易集之后包括一个状态根 共同读取和写入 Ls 个字节的状态。 有了这些信息对于 渔夫提出了一个挑战，即状态转换应用不正确 足以找到第一个这样的无效状态根，并且只包含 Ls 字节 受最后一个状态根（之前是 valid）和带有默克尔证明的当前状态根。那么任意参与者 可以验证段中的事务并确认该块是 无效。 类似地，如果块生产者尝试包含读取的事务 并写入超过 Ls 个字节的状态，对于挑战来说，包含就足够了 它与默克尔证明接触的第一个 Ls 字节，这足以 应用交易并确认有一个时刻尝试 读取或写入的内容超出 Ls 字节。
3.7.2 渔民和快速跨分片交易 正如 2.3 节中所讨论的，一旦我们假设分片块（或分片 具有分片链的模型中的块）可能无效并带来挑战 期间，它会对最终结果产生负面影响，从而影响跨分片通信。在 特别是，任何跨分片交易的目标分片都无法确定 在挑战期结束之前，原始分片块或块是最终的 （见图 21）。 图 21： 在申请收据之前等待挑战期 以使得跨分片交易的方式来解决这个问题 Instantinious 是指目标分片不等待挑战期 源分片交易发布后，应用收据交易 立即，然后将目标分片与源分片一起回滚 如果后来发现原始块或块无效（见图 22）。这非常自然地适用于 Nightshade 设计，其中碎片 链不是独立的，而是分片块全部发布 一起在同一个主链区块中。如果发现任何块无效， 包含该块的整个块被认为是无效的，并且构建在其上的所有块 其顶部。见图 23。 上述两种方法都提供原子性，假设挑战 周期足够长。我们使用后一种方法，因为在正常情况下提供快速的跨分片交易比 由于其中之一的状态转换无效，目标分片回滚 源碎片，这是极其罕见的事件。 3.7.3 隐藏 validators 挑战的存在已经大大降低了 自适应损坏，因为要使用无效的状态转换后完成一个块图 22： 立即应用收据并回滚目的地 链如果源链有无效块 图 23： 茄属渔夫挑战 适应性对手需要腐蚀所有参与者的挑战期 维护分片的状态，包括所有 validator。 估计此类事件的可能性极其复杂，因为没有 sharded blockchain 已经存在足够长的时间来尝试任何此类攻击。我们认为这种可能性虽然极低，但仍然足够 对于预计执行数百万笔交易的系统来说很大 经营全球金融业务。 这种信念有两个主要原因： 1. 权益证明链的大多数 validator 和矿工
工作量证明链主要受到财务上行的激励。如果 适应性强的对手为他们提供的钱多于预期回报 从诚实经营的角度来看，可以合理地预期许多 validator 将接受该提议。 2. 许多实体对权益证明链进行专业验证，并且 预计任何连锁店的大部分股权都将被 来自此类实体。此类实体的数量对于 适应性强的对手能够亲自了解他们中的大多数人并拥有 很好地理解了他们的本性被腐蚀了。 我们通过隐藏哪些 validator 分配给哪个分片，进一步降低了自适应损坏的概率。这个想法是 与 Algorand [5] 隐藏 validators 的方式非常相似。 值得注意的是，即使 validator 被隐藏，如 Algorand 中所示 或者如下所述，自适应腐败在理论上仍然是可能的。同时 适应性对手不知道将创建或验证的参与者 一个块或一个块，参与者自己确实知道他们将执行 这样的任务并有它的密码证明。 这样，对手就可以 传播他们的腐败意图，并向任何愿意提供的参与者支付费用 这样的密码学证明。然而我们注意到，由于对手不 知道分配给他们想要破坏的分片的 validator，他们 别无选择，只能将他们破坏特定分片的意图传播给 整个社区。到那时，这对任何诚实的人来说都是经济上有利的 参与者启动一个验证该分片的完整节点，因为有一个很高的 该分片中出现无效块的机会，这是一个机会 创建挑战并收集相关奖励。 为了不泄露分配给特定分片的 validator，我们这样做 如下（见图 24）： 使用 VRF 获取任务。在每个纪元的开始 validator 使用 VRF 获取分配给 validator 的分片的位掩码。 每个 validator 的位掩码将具有 Sw 位（请参阅第 3.3 节了解定义 的 Sw）。然后 validator 获取相应分片的状态，并且 在收到的每个块的纪元期间验证对应的块 分配给 validator 的分片。 对块而不是块进行签名。由于分片分配是隐藏的，因此 validator 无法在块上签名。相反，它总是在整个 块，因此不会透露它验证的分片。具体来说，当 validator 接收到一个块并验证所有块时，它要么创建一条消息 证明 validator 分配到的所有分片中的所有块都是 有效（不以任何方式表明这些分片是什么），或者一条消息 如果任何块无效，则包含无效状态转换的证明。请参阅 有关如何聚合此类消息的详细信息，请参阅第 3.8 节，有关如何聚合此类消息的详细信息，请参阅第 3.7.4 节 有关如何防止 validators 捎带消息的详细信息 其他 validators，以及第 3.7.5 节了解如何奖励和惩罚的详细信息 validators 应该成功地发生无效状态转换挑战。图 24： 将 validator 隐藏在茄属植物中 3.7.4 提交-揭示 validators 的常见问题之一是 validator 可以跳过下载状态并实际验证块和块，而是 观察网络，查看其他 validator 提交的内容并重复他们的 消息。遵循这种策略的 validator 不提供任何额外的 网络安全，但收取奖励。 此问题的常见解决方案是为每个 validator 提供一个证明 他们实际上验证了该块，例如通过提供唯一的跟踪 应用状态转换，但这样的证明显着增加了成本 的验证。 图 25： 提交-揭示
相反，我们让 validators 首先提交验证结果（或者 证明块有效性的消息，或无效证明 状态转换），等待一定的时间，然后才显示实际的验证结果，如图25所示。提交时间与 揭示期，因此懒惰的 validator 无法模仿诚实的 validator。 此外，如果不诚实的 validator 提交了一条证明 分配的块的有效性，并且至少有一个块是无效的，一旦 显示该块无效，validator 无法避免削减，因为， 正如我们在第 3.7.5 节中所示，在这种情况下不被削减的唯一方法 是呈现一条消息，其中包含无效状态转换的证明 匹配提交。 3.7.5 应对挑战 如上所述，一旦 validator 接收到带有无效块的块， 他们首先准备无效状态转换的证明（参见第 3.7.1 节），然后 致力于这样的证明（见 3.7.4），并在一段时间后揭示挑战。 一旦揭示的挑战被包含在区块中，就会发生以下情况： 1. 从包含该块的块中发生的所有状态转换 无效块，直到包含所揭示的挑战的块得到 无效。包含已揭示挑战的区块之前的状态 被认为与包含该块的块之前的状态相同 无效块。 2. 在一定的时间内，每个 validator 必须揭示其位掩码 他们验证的分片的数量。由于位掩码是通过 VRF 创建的，如果 他们被分配到具有无效状态转换的分片，他们 无法避免暴露它。任何无法显示位掩码的 validator 假设已分配给分片。 3. 在这段时间内发现分配给分片的每个 validator， 确实提交了包含以下内容的块的某些验证结果 无效块并且没有揭示无效状态转换的证明 与他们的提交相对应的内容被削减。 4. 每个validator得到一个新的分片分配，并安排一个新的epoch 一段时间后开始，足以让所有 validator 下载 状态，如图 26 所示。 请注意，从 validator 显示分配给它们的分片那一刻起 直到新纪元开始，系统的安全性都会降低，因为 分片分配被揭示。网络参与者需要保留它 在此期间使用网络时请谨记。 3.8 签名聚合 为了让拥有数百个分片的系统能够安全运行，我们希望 10、000 或更多 validator 的顺序。正如第 3.7 节中所讨论的，我们希望每个图 26： 应对挑战 validator 发布对特定消息的提交和平均签名 每个块一次。即使提交消息相同，聚合这样的 BLS 签名并对其进行验证的成本将高得令人望而却步。但是 当然，validator 中的提交和显示消息并不相同， 因此我们需要某种方法来聚合这些消息和签名 以便稍后快速验证的方式。 我们使用的具体方法如下： 验证者加入区块生产者。区块生产者是已知的 在纪元开始之前的某个时间，因为他们需要一些时间来下载 纪元开始之前的状态，与 validator 不同，区块生产者是 没有隐藏。每个区块生产者都有 v 个 validator 插槽。验证者提交 向区块生产者提出链下提案，将其纳入其 v 之一 validators。如果区块生产者希望包含 validator，他们会提交 包含来自 validator 的初始链外请求的交易，以及 区块生产者的签名，使 validator 加入区块生产者。 请注意，分配给区块生产者的 validator 不一定是 验证区块生产者为其生成块的相同分片。 如果一个 validator 申请加入多个区块生产者，仅来自 第一个区块生产者将会成功。 区块生产者收集提交。区块生产者不断收集来自 validator 的提交和显示消息。一旦累积了一定数量的此类消息，区块生产者就会计算默克尔 这些消息的树，并向每个 validator 发送 merkle 根和 他们的消息的默克尔路径。 validator 验证路径并登录 默克尔根。然后，区块生产者在区块链上累积 BLS 签名 来自 validators 的 merkle 根，并且仅发布 merkle 根和 累计签名。区块生产者还签署了该区块的有效性 使用廉价的 ECDSA 签名进行多重签名。如果多重签名没有 匹配提交的默克尔根或参与的 validator 的位掩码，这是可削减的行为。同步链时，参与者 可以选择验证来自 validators 的所有 BLS 签名（这非常昂贵，因为它涉及聚合 validators 公钥），或者仅验证来自区块生产者的 ECDMA 签名，并依赖于以下事实： 区块生产者没有受到挑战和削减。 使用链上交易和默克尔证明来应对挑战。它 可以注意到，如果没有，那么泄露来自 validators 的消息是没有价值的。 检测到无效的状态转换。仅包含实际内容的消息 需要揭示无效状态转换的证明，并且仅针对此类消息 需要证明它们与之前的提交相匹配。该消息需要 被披露有两个目的： 1. 真正启动链回滚到之前的那一刻 无效状态转换（参见第 3.7.5 节）。 2. 证明 validator 并未试图证明该信息的有效性 无效块。 无论哪种情况，我们都需要解决两个问题： 1. 实际提交并未包含在链上，仅包含在链上的merkle根 提交与其他消息聚合。 validator 需要使用 区块生产者提供的默克尔路径及其原始承诺 证明他们致力于挑战。 2. 有可能分配给无效分片的所有validator 状态转换恰好被分配给损坏的区块生产者 正在审查他们。为了解决这个问题，我们允许他们提交他们的揭露 作为链上的常规交易并绕过聚合。 后者仅适用于无效状态转换的证明，即 极其罕见，因此不应导致垃圾邮件块。 需要解决的最后一个问题是区块生产者可以 选择不参与消息聚合或故意审查特定的 validator。我们通过制作区块使其在经济上处于不利地位 生产者奖励与分配给他们的 validator 数量成正比。我们 还请注意，由于纪元之间的区块生产者很大程度上相交（因为 它始终是拥有最高赌注的前 w 参与者），validators 可以 很大程度上坚持与相同的区块生产者合作，从而降低风险 被分配给过去审查过他们的区块生产者。 3.9 快照链 由于主链上的区块产生非常频繁，因此下载 完整的历史可能很快就会变得昂贵。而且，由于每 区块包含大量参与者的 BLS 签名，仅聚合公钥来检查签名可能会变得令人望而却步 也很贵。 最后，因为在任何可预见的未来 Ethereum 1.0 可能仍然是一个 最常用的 blockchain 中，有一种有意义的方式来转移资产
要求接近 Ethereum，今天验证 BLS 签名以确保 Ethereum 一侧的近块有效性是不可能的。 Nightshade 主链中的每个区块都可以选择包含 Schnorr 包含此类 Schnorr 的最后一个块的标头上的多重签名 多重签名。我们将此类块称为快照块。第一个块 每个纪元必须是一个快照块。在研究这样的多重签名时， 区块生产者还必须累积 validator 的 BLS 签名 在最后一个快照块上，并按照与中所述相同的方式聚合它们 第 3.8 节。 由于区块生产者集在整个时期内保持不变，因此验证 假设在没有任何情况下，只有每个时期中的第一个快照块就足够了 指出很大一部分区块生产者和 validator 串通并创建 叉子。 纪元的第一个块必须包含足以计算的信息 该纪元的区块生产者和 validators。 我们称主链中只包含快照的子链为 阻止快照链。 创建 Schnorr 多重签名是一个交互式过程，但由于我们 只需要很少执行，任何流程，无论效率如何低下 就足够了。 Schnorr 多重签名可以在 Ethereum 上轻松验证， 从而为执行跨blockchain的安全方式提供关键原语 沟通。 与近链同步只需下载所有快照 块并确认 Schnorr 签名正确（也可以选择验证 validator 的各个 BLS 签名），然后仅同步 主链区块来自最后一个快照区块。
خاتمة
ناقشنا في هذه الوثيقة أساليب بناء blockchains و غطت تحديين رئيسيين مع النهج الحالي، وهما صلاحية الدولة وتوافر البيانات. ثم قدمنا Nightshade، وهو تصميم مقسم صلاحيات NEAR البروتوكول. التصميم قيد التنفيذ، إذا كان لديك تعليقات أو أسئلة أو ملاحظات في هذا المستند، يرجى الانتقال إلى https://near.chat.
结论
在本文档中，我们讨论了构建分片 blockchain 的方法和 克服了现有方法的两个主要挑战，即状态有效性 和数据可用性。然后我们提出了 Nightshade，一种分片设计 赋予 NEAR 协议权力。 设计正在进行中，如果您有意见、问题或反馈 对于本文档，请转至 https://near.chat.