صحة الدولة وتوافر البيانات
الفكرة الأساسية في 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 على هذا النحو الطريقة التي يكون بها النظام آمنًا حتى لو أصبحت بعض الكتل القديمة في بعض القطع غير متوفر تماما.
Hiệu lực của trạng thái và tính sẵn có của dữ liệu
Ý tưởng cốt lõi trong sharded blockchains là hầu hết người tham gia đều vận hành hoặc việc sử dụng mạng không thể xác thực các khối trong tất cả các phân đoạn. Như vậy, bất cứ khi nào bất kỳ người tham gia nào cũng cần tương tác với một phân đoạn cụ thể mà họ thường không thể tải xuống và xác thực toàn bộ lịch sử của phân đoạn. Tuy nhiên, khía cạnh phân vùng của sharding làm tăng tiềm năng đáng kể vấn đề: không tải xuống và xác thực toàn bộ lịch sử của một ứng dụng cụ thể phân đoạn, người tham gia không nhất thiết phải chắc chắn rằng trạng thái của nó 5Phần này, ngoại trừ tiểu mục 2.5.3, đã được xuất bản trước đây tại https://near.ai/ mảnh vỡ2. Nếu bạn đã đọc nó trước đó, hãy chuyển sang phần tiếp theo.
chúng tương tác với nhau là kết quả của một chuỗi khối hợp lệ nào đó và chuỗi đó của các khối thực sự là chuỗi chuẩn trong phân đoạn. Một vấn đề không tồn tại trong blockchain không được phân chia. Đầu tiên chúng tôi sẽ trình bày một giải pháp đơn giản cho vấn đề này đã được đề xuất bằng nhiều giao thức và sau đó phân tích xem giải pháp này có thể bị hỏng như thế nào và điều gì đã có những nỗ lực để giải quyết nó. 2.1 Xoay vòng xác thực Giải pháp đơn giản cho tính hợp lệ của trạng thái được thể hiện trên hình 5: giả sử chúng ta giả sử mà toàn bộ hệ thống có khoảng hàng nghìn validator, trong đó không quá 20% là độc hại hoặc sẽ thất bại (chẳng hạn như không thể trực tuyến để tạo ra một khối). Sau đó, nếu chúng ta lấy mẫu 200 validators thì xác suất nhiều hơn 1 3 không đạt trong mục đích thực tế có thể được coi là bằng không. Hình 5: Đang lấy mẫu validators 1 3 là một ngưỡng quan trọng. Có một nhóm các giao thức đồng thuận, được gọi là BFT giao thức đồng thuận, đảm bảo rằng chỉ cần ít hơn 1 3 trong số người tham gia thất bại, do vi phạm hoặc do hành động theo cách nào đó vi phạm giao thức thì sẽ đạt được sự đồng thuận. Với giả định về tỷ lệ phần trăm validator trung thực này, nếu tập hợp hiện tại validator trong một phân đoạn cung cấp cho chúng ta một số khối, giải pháp ngây thơ giả định rằng khối đó hợp lệ và nó được xây dựng dựa trên những gì validator được cho là chuỗi chuẩn cho phân đoạn đó khi họ bắt đầu xác thực. validators đã học chuỗi chuẩn từ tập hợp validator trước đó, cũng bằng cách đó giả định được xây dựng trên khối đứng đầu chuỗi kinh điển trước đó. Bằng quy nạp, toàn bộ chuỗi là hợp lệ và vì không có tập hợp validator nào tại bất kỳ thời điểm nào sản xuất nĩa, giải pháp ngây thơ cũng chắc chắn rằng hiện tại chuỗi là chuỗi duy nhất trong phân đoạn. Xem hình 6 để hình dung.
Hình 6: blockchain với mỗi khối được hoàn tất thông qua sự đồng thuận BFT Giải pháp đơn giản này sẽ không hiệu quả nếu chúng ta giả sử rằng validator có thể bị hỏng một cách thích ứng, đây không phải là một giả định vô lý6. Thích ứng làm hỏng một phân đoạn trong hệ thống có 1000 phân đoạn sẽ rẻ hơn đáng kể hơn là làm hỏng toàn bộ hệ thống. Do đó, tính bảo mật của giao thức giảm tuyến tính theo số lượng phân đoạn. Để có sự chắc chắn về tính hợp lệ của một khối, chúng ta phải biết rằng tại bất kỳ thời điểm nào trong lịch sử không có phân đoạn nào trong hệ thống có phần lớn validator thông đồng; với những đối thủ có khả năng thích ứng, chúng ta không còn có sự chắc chắn như vậy. Như chúng ta đã thảo luận trong phần 1.5, việc thông đồng với validator có thể gây ảnh hưởng hai hành vi độc hại cơ bản: tạo nhánh và tạo các khối không hợp lệ. Các nhánh độc hại có thể được xử lý bằng các khối được liên kết chéo với chuỗi Beacon thường được thiết kế để có độ bảo mật cao hơn đáng kể so với các chuỗi khác. những chuỗi mảnh vỡ. Tuy nhiên, việc tạo ra các khối không hợp lệ là một vấn đề đáng kể hơn. vấn đề đầy thách thức cần giải quyết. 2.2 Hiệu lực của tiểu bang Hãy xem hình 7 trong đó Shard #1 bị hỏng và một tác nhân độc hại tạo ra khối B không hợp lệ. Giả sử trong khối B này 1000 token được đúc từ mỏng phát sóng trên tài khoản của Alice. Sau đó, tác nhân độc hại tạo ra khối C hợp lệ (trong một cảm thấy rằng các giao dịch trong C được áp dụng chính xác) trên B, làm xáo trộn khối B không hợp lệ và bắt đầu giao dịch chéo tới Phân đoạn số 2 chuyển 1000 tokens đó vào tài khoản của Bob. Từ lúc này trở đi không đúng cách đã tạo token nằm trên blockchain hoàn toàn hợp lệ trong Phân đoạn #2. Một số cách tiếp cận đơn giản để giải quyết vấn đề này là: 6Đọc cái này bài viết cho chi tiết trên làm thế nào thích nghi tham nhũng có thể được mang theo ra: https://medium.com/nearprotocol/d859adb464c8. cho hơn thế nữa chi tiết trên thích nghi tham nhũng, đọc https://github.com/ethereum/wiki/wiki/Sharding-FAQ# mô hình bảo mật mà chúng tôi đang vận hành là gìHình 7: Giao dịch chéo từ chuỗi có khối không hợp lệ 1. Dành cho validator của Phân đoạn số 2 để xác thực khối nơi giao dịch được thực hiện được khởi xướng. Điều này sẽ không hoạt động ngay cả trong ví dụ trên, vì khối C dường như hoàn toàn hợp lệ. 2. Dành cho validator trong Phân đoạn số 2 để xác thực một số lượng lớn khối trước khối mà giao dịch được bắt đầu. Đương nhiên, đối với bất kỳ số lượng khối N nào được xác nhận bởi phân đoạn nhận độc hại validators có thể tạo N+1 khối hợp lệ lên trên khối không hợp lệ mà họ được sản xuất. Một ý tưởng đầy hứa hẹn để giải quyết vấn đề này là sắp xếp các mảnh thành một đồ thị vô hướng trong đó mỗi phân đoạn được kết nối với một số phân đoạn khác và chỉ cho phép giao dịch chéo giữa các phân đoạn lân cận (ví dụ: đây là cách Về cơ bản, sharding của Vlad Zamfir hoạt động7 và ý tưởng tương tự được sử dụng trong Kadena Chuỗi mạng [1]). Nếu cần một giao dịch chéo giữa các phân đoạn không phải hàng xóm, giao dịch đó được định tuyến qua nhiều phân đoạn. Trong thiết kế này validator trong mỗi phân đoạn phải xác thực cả hai khối trong phân đoạn của chúng cũng như tất cả các khối trong tất cả các mảnh lân cận. Hãy xem xét một hình dưới đây với 10 phân đoạn, mỗi phân đoạn có bốn phân đoạn lân cận và không có phân đoạn nào yêu cầu nhiều hơn hơn hai bước nhảy cho giao tiếp chéo được hiển thị trên hình 8. Phân đoạn số 2 không chỉ xác thực blockchain của chính nó mà còn blockchain của tất cả những người hàng xóm, bao gồm cả Shard #1. Vì vậy, nếu một tác nhân độc hại trên Shard #1 đang cố gắng tạo khối B không hợp lệ, sau đó xây dựng khối C lên trên khối đó và bắt đầu một giao dịch chéo, giao dịch chéo đó sẽ không diễn ra kể từ khi Phân đoạn số 2 sẽ xác thực toàn bộ lịch sử của Phân đoạn số 1 sẽ khiến nó xác định khối B không hợp lệ. 7Đọc thêm về thiết kế tại đây: https://medium.com/nearprotocol/37e538177ed9
Hình 8: Một giao dịch chéo không hợp lệ trong hệ thống giống như chainweb sẽ bị phát hiện Mặc dù việc làm hỏng một phân đoạn không còn là một cuộc tấn công khả thi nữa, việc làm hỏng một vài mảnh vẫn còn là một vấn đề. Trên hình 9, một đối thủ đang làm hỏng cả Shard
1 và Shard #2 thực hiện thành công giao dịch chéo tới Shard #3
với số tiền từ khối B không hợp lệ: Hình 9: Một giao dịch chéo không hợp lệ trong hệ thống giống như chainweb sẽ không bị phát hiện Phân đoạn số 3 xác thực tất cả các khối trong Phân đoạn số 2, nhưng không có trong Phân đoạn số 1 và không có cách nào để phát hiện khối độc hại. Có hai hướng chính để giải quyết đúng đắn tính hợp lệ của trạng thái:
và bằng chứng mật mã của tính toán. 2.3 ngư dân Ý tưởng đằng sau cách tiếp cận đầu tiên là như sau: bất cứ khi nào một tiêu đề khối được truyền đạt giữa các chuỗi vì bất kỳ mục đích nào (chẳng hạn như liên kết chéo với chuỗi đèn hiệu hoặc giao dịch chéo), có một khoảng thời gian trong mà bất kỳ validator trung thực nào cũng có thể cung cấp bằng chứng cho thấy khối không hợp lệ. Ở đó là những công trình khác nhau cho phép chứng minh rất ngắn gọn rằng các khối không hợp lệ, do đó chi phí liên lạc cho các nút nhận sẽ nhỏ hơn nhiều hơn là nhận được một khối đầy đủ. Với cách tiếp cận này miễn là có ít nhất một validator trung thực trong mảnh vỡ, hệ thống được an toàn. Hình 10: ngư dân Đây là cách tiếp cận chủ đạo (ngoài việc giả vờ như vấn đề không tồn tại) trong số các giao thức được đề xuất hiện nay. Tuy nhiên, cách tiếp cận này có hai nhược điểm lớn: 1. Thời gian thử thách cần phải đủ dài đối với người trung thực validator để nhận biết một khối đã được tạo, tải xuống, xác minh đầy đủ và chuẩn bị thử thách nếu khối không hợp lệ. Giới thiệu một thời kỳ như vậy sẽ làm chậm đáng kể các giao dịch chéo. 2. Sự tồn tại của giao thức thử thách tạo ra một hướng tấn công mới khi các nút độc hại spam với các thách thức không hợp lệ. Một giải pháp rõ ràng của vấn đề này là bắt những người thách đấu gửi một số tiền tokens được trả lại nếu thử thách hợp lệ. Đây chỉ là giải pháp một phần vì nó vẫn có thể có lợi cho kẻ thù gửi thư rác vào hệ thống (và đốt cháy tiền gửi) với những thách thức không hợp lệ, ví dụ để ngăn chặn hợp lệthách thức từ validator trung thực khi vượt qua. Những cuộc tấn công này là được gọi là Cuộc tấn công đau buồn. Xem phần 3.7.2 để biết cách giải quyết điểm sau. 2.4 Lập luận ngắn gọn về kiến thức không tương tác Giải pháp thứ hai cho vấn đề hỏng nhiều phân đoạn là sử dụng một số loại cấu trúc mật mã cho phép người ta chứng minh rằng một tính toán nhất định (chẳng hạn như như việc tính toán một khối từ một tập hợp các giao dịch) đã được thực hiện chính xác. Những công trình như vậy tồn tại, ví dụ: zk-SNARK, zk-STARK và một số loại khác, và một số được sử dụng tích cực trong các giao thức blockchain ngày nay để thanh toán riêng tư, đáng chú ý nhất là ZCash. Vấn đề chính với những thứ nguyên thủy như vậy là chúng nổi tiếng là tính toán chậm. Ví dụ. Giao thức Coda, sử dụng zk-SNARK cụ thể là để chứng minh rằng tất cả các khối trong blockchain đều hợp lệ, được nói trong một trong số các cuộc phỏng vấn rằng có thể mất 30 giây cho mỗi giao dịch để tạo bằng chứng (con số này có lẽ bây giờ đã nhỏ hơn). Điều thú vị là, bằng chứng không cần phải được tính toán bởi một bên đáng tin cậy, vì bằng chứng không chỉ chứng thực tính hợp lệ của tính toán mà nó được xây dựng mà còn giá trị pháp lý của chính bằng chứng. Vì vậy, việc tính toán các chứng minh đó có thể được chia giữa một nhóm người tham gia với mức độ dư thừa ít hơn đáng kể so với cần thiết để thực hiện một số tính toán không tin cậy. Nó cũng cho phép người tham gia những người tính toán zk-SNARK để chạy trên phần cứng đặc biệt mà không làm giảm phi tập trung hóa hệ thống. Những thách thức của zk-SNARK, ngoài hiệu suất, là: 1. Sự phụ thuộc vào các mật mã nguyên thủy ít được nghiên cứu và thử nghiệm ít thời gian hơn; 2. ”Chất thải độc hại” — zk-SNARK phụ thuộc vào thiết lập đáng tin cậy trong đó một nhóm mọi người thực hiện một số tính toán và sau đó loại bỏ kết quả trung gian các giá trị của phép tính đó. Nếu tất cả những người tham gia thủ tục thông đồng và giữ nguyên các giá trị trung gian, có thể tạo ra bằng chứng giả; 3. Độ phức tạp cao hơn được đưa vào thiết kế hệ thống; 4. zk-SNARK chỉ hoạt động đối với một tập hợp con các phép tính có thể, do đó, một giao thức với ngôn ngữ Turing-complete smart contract sẽ không thể sử dụng SNARK để chứng minh tính hợp lệ của chuỗi. 2,5 Tính sẵn có của dữ liệu Vấn đề thứ hai chúng ta sẽ đề cập đến là tính sẵn có của dữ liệu. Nói chung các nút việc vận hành một blockchain cụ thể được tách thành hai nhóm: Nút đầy đủ, những thứ tải xuống mọi khối đầy đủ và xác thực mọi giao dịch và Light Các nút chỉ tải xuống tiêu đề khối và sử dụng bằng chứng Merkle cho các bộ phận của nhà nước và các giao dịch mà họ quan tâm, như thể hiện trên hình 11.
Hình 11: Cây Merkle Bây giờ nếu phần lớn các nút đầy đủ thông đồng với nhau, chúng có thể tạo ra một khối, hợp lệ hoặc không hợp lệ và gửi hash của nó tới các nút ánh sáng nhưng không bao giờ tiết lộ toàn bộ nội dung của khối. Có nhiều cách khác nhau để họ có thể hưởng lợi từ nó. Ví dụ, xét hình 12: Hình 12: Vấn đề về tính sẵn có của dữ liệu Có ba khối: khối trước, A, được tạo bởi validators trung thực; hiện tại, B, có validator thông đồng; và loại tiếp theo, C, cũng sẽ được sản xuất bởi validators trung thực (blockchain được mô tả ở góc dưới cùng bên phải). Bạn là một thương gia. validators của khối hiện tại (B) đã nhận được khối A từ validator trước đó, đã tính toán một khối trong đó bạn nhận được tiền,và gửi cho bạn tiêu đề của khối đó cùng với bằng chứng Merkle về trạng thái bạn có tiền (hoặc bằng chứng Merkle về giao dịch hợp lệ gửi tiền cho bạn). Tin chắc rằng giao dịch đã hoàn tất, bạn cung cấp dịch vụ. Tuy nhiên, validator không bao giờ phân phối toàn bộ nội dung của khối B cho bất cứ ai. Do đó, validator trung thực của khối C không thể truy xuất khối và hoặc bị buộc phải đình trệ hệ thống hoặc xây dựng trên đỉnh A, tước bỏ tư cách của bạn người buôn tiền. Khi chúng tôi áp dụng kịch bản tương tự cho sharding, các định nghĩa về đầy đủ và nút nhẹ thường áp dụng cho mỗi phân đoạn: validators trong mỗi lần tải xuống phân đoạn chặn trong phân đoạn đó và xác thực mọi giao dịch trong phân đoạn đó, nhưng các giao dịch khác các nút trong hệ thống, bao gồm cả các nút có trạng thái chuỗi phân đoạn nhanh vào chuỗi đèn hiệu, chỉ tải xuống các tiêu đề. Do đó, validator trong phân đoạn là các nút đầy đủ hiệu quả cho phân đoạn đó, trong khi những người tham gia khác trong hệ thống, bao gồm chuỗi đèn hiệu, hoạt động như các nút ánh sáng. Để cách tiếp cận của ngư dân mà chúng ta đã thảo luận ở trên có hiệu quả, validators trung thực cần có khả năng tải xuống các khối được liên kết chéo với chuỗi đèn hiệu. Nếu validator độc hại liên kết chéo tiêu đề của một khối không hợp lệ (hoặc sử dụng nó để bắt đầu một giao dịch chéo), nhưng không bao giờ phân phối khối, thì giao dịch trung thực validator không có cách nào để tạo ra thử thách. Chúng tôi sẽ đề cập đến ba cách tiếp cận để giải quyết vấn đề này, bổ sung cho lẫn nhau. 2.5.1 Bằng chứng về quyền nuôi con Vấn đề trước mắt nhất cần giải quyết là liệu một khối có sẵn một lần hay không nó được xuất bản. Một ý tưởng được đề xuất là có cái gọi là Công chứng viên luân phiên giữa các phân đoạn thường xuyên hơn validator có công việc duy nhất là tải xuống chặn và chứng thực rằng họ có thể tải xuống nó. Họ có thể được luân chuyển thường xuyên hơn vì họ không cần tải xuống toàn bộ trạng thái của phân đoạn, không giống như validator không thể xoay thường xuyên vì chúng phải tải xuống trạng thái của phân đoạn mỗi lần chúng xoay, như thể hiện trên hình 13. Vấn đề với cách tiếp cận ngây thơ này là không thể chứng minh sau này cho dù Công chứng viên có thể tải xuống khối hay không, vì vậy Công chứng viên có thể chọn luôn chứng thực rằng họ có thể tải xuống khối mà không cần thậm chí còn cố gắng lấy lại nó. Một giải pháp cho vấn đề này là Công chứng viên cung cấp một số bằng chứng hoặc đặt cược số lượng token chứng thực rằng khối đã được đã tải xuống. Một giải pháp như vậy được thảo luận ở đây: https://ethresear.ch/t/ Trái phiếu lưu ký thân thiện với tập hợp 1 bit/2236. 2.5.2 Mã xóa Khi một nút nhẹ cụ thể nhận được hash của một khối, để tăng sức mạnh của nút đó tin rằng khối đó có sẵn, nó có thể thử tải xuống một vài thông tin ngẫu nhiên các mảnh của khối. Đây không phải là một giải pháp hoàn chỉnh, vì trừ khi các nút ánh sáng tải xuống chung toàn bộ khối mà nhà sản xuất khối độc hại có thể chọn
Hình 13: Trình xác thực cần phải tải xuống trạng thái và do đó không thể xoay được thường xuyên để giữ lại các phần của khối không được tải xuống bởi bất kỳ nút ánh sáng nào, do đó vẫn làm cho khối không có sẵn. Một giải pháp là sử dụng một cấu trúc có tên là Erasure Codes để thực hiện điều đó. để khôi phục toàn bộ khối ngay cả khi chỉ có một phần của khối, như được hiển thị trên hình 14. Hình 14: Merkle tree được xây dựng dựa trên dữ liệu đã mã hóa bị xóa Cả Polkadot và Ethereum Serenity đều có thiết kế xoay quanh ý tưởng này cung cấp một cách để các nút nhẹ có thể tin cậy một cách hợp lý rằng các khối có sẵn. Phương pháp Ethereum Serenity có mô tả chi tiết trong [2].2.5.3 Cách tiếp cận của Polkadot đối với tính khả dụng của dữ liệu Trong Polkadot, giống như trong hầu hết các giải pháp phân đoạn, mỗi phân đoạn (được gọi là parachain) chụp nhanh các khối của nó vào chuỗi báo hiệu (được gọi là chuỗi chuyển tiếp). Giả sử có 2f + 1 validator trên chuỗi chuyển tiếp. Các nhà sản xuất khối của khối parachain, được gọi là đối chiếu, sau khi khối parachain được tạo ra, hãy tính toán một phiên bản mã hóa xóa của khối bao gồm 2f +1 phần sao cho bất kỳ phần f nào cũng đủ để xây dựng lại khối. Sau đó, họ phân phối một phần cho mỗi validator trên chuỗi rơle. Chuỗi chuyển tiếp cụ thể validator sẽ chỉ đăng nhập vào chuỗi chuyển tiếp khối nếu họ có phần của mình cho mỗi khối parachain được chụp nhanh vào khối chuỗi chuyển tiếp như vậy. Do đó, nếu khối chuỗi chuyển tiếp có chữ ký từ 2f + 1 validators và miễn là không quá f trong số chúng vi phạm giao thức, mỗi khối parachain có thể được xây dựng lại bằng cách tìm nạp các phần từ validators tuân theo giao thức. Xem hình 15. Hình 15: Tính khả dụng của dữ liệu Polkadot 2.5.4 Tính sẵn có của dữ liệu dài hạn Lưu ý rằng tất cả các phương pháp được thảo luận ở trên chỉ chứng thực thực tế là một khối đã được xuất bản và hiện có sẵn. Các khối sau này có thể không còn khả dụng vì nhiều lý do: các nút ngoại tuyến, các nút cố tình xóa lịch sử dữ liệu và những thứ khác. Sách trắng đáng được đề cập giải quyết vấn đề này là Polyshard [3], sử dụng mã xóa để cung cấp các khối trên các phân đoạn ngay cả khi một số mảnh vỡ hoàn toàn mất dữ liệu của họ. Thật không may, cách tiếp cận cụ thể của họ đòi hỏi tất cả các phân đoạn để tải xuống các khối từ tất cả các phân đoạn khác, điều này bị cấm đắt tiền. Tính khả dụng lâu dài không phải là vấn đề cấp bách: vì không có người tham gia trong hệ thống dự kiến sẽ có khả năng xác nhận tất cả các chuỗi trong tất cả
phân đoạn, tính bảo mật của giao thức phân đoạn cần phải được thiết kế theo cách cách mà hệ thống được an toàn ngay cả khi một số khối cũ trong một số phân đoạn trở thành hoàn toàn không có sẵn.
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 Từ chuỗi mảnh đến mảnh vỡ Mô hình sharding với chuỗi phân đoạn và chuỗi đèn hiệu rất mạnh mẽ nhưng có những phức tạp nhất định. Đặc biệt, quy tắc lựa chọn ngã ba cần được thực thi trong mỗi chuỗi riêng biệt, quy tắc lựa chọn ngã ba trong chuỗi phân đoạn và đèn hiệu chuỗi phải được xây dựng khác nhau và được thử nghiệm riêng biệt. Trong Nightshade, chúng tôi lập mô hình hệ thống dưới dạng một blockchain duy nhất, trong đó mỗi khối chứa tất cả các giao dịch cho tất cả các phân đoạn một cách hợp lý và thay đổi toàn bộ trạng thái của tất cả các mảnh vỡ. Tuy nhiên, về mặt vật lý, không có người tham gia nào tải xuống trạng thái đầy đủ hoặc khối logic đầy đủ. Thay vào đó, mỗi người tham gia mạng chỉ duy trì trạng thái tương ứng với các phân đoạn mà họ xác thực giao dịch và danh sách tất cả các giao dịch trong khối được chia thành các phần vật lý khối, một khối cho mỗi mảnh. Trong điều kiện lý tưởng, mỗi khối chứa chính xác một đoạn trên mỗi phân đoạn. khối, gần tương ứng với mô hình với các chuỗi phân đoạn trong đó chuỗi phân đoạn tạo ra các khối có cùng tốc độ với chuỗi đèn hiệu. Tuy nhiên, do sự chậm trễ của mạng, một số khối có thể bị thiếu, vì vậy trong thực tế mỗi khối chứa một hoặc không khối trên mỗi phân đoạn. Xem phần 3.3 để biết chi tiết về cách khối được sản xuất. Hình 16: Một mô hình có các chuỗi mảnh ở bên trái và có một chuỗi có các khối được chia thành các khối bên phải
3.2 Sự đồng thuận Hai cách tiếp cận chủ yếu để đạt được sự đồng thuận trong blockchain ngày nay là chuỗi dài nhất (hoặc nặng nhất), trong đó chuỗi có nhiều công việc hoặc cổ phần nhất được sử dụng để xây dựng nó được coi là chuẩn và BFT, trong đó đối với mỗi khối một số tập hợp validator đạt được sự đồng thuận BFT. Trong các giao thức được đề xuất gần đây thì cách thứ hai là cách tiếp cận ưu việt hơn, vì nó cung cấp tính hữu hạn ngay lập tức, trong khi ở chuỗi dài nhất cần nhiều khối hơn được xây dựng trên đỉnh của khối để đảm bảo tính cuối cùng. Thường vì một ý nghĩa bảo mật mất thời gian để xây dựng đủ số khối thứ tự giờ. Việc sử dụng sự đồng thuận BFT trên mỗi khối cũng có những nhược điểm, chẳng hạn như: 1. BFT sự đồng thuận đòi hỏi lượng trao đổi đáng kể. Trong khi những tiến bộ gần đây cho phép đạt được sự đồng thuận trong thời gian tuyến tính về số lượng của người tham gia (xem ví dụ: [4]), chi phí này vẫn đáng chú ý trên mỗi khối; 2. Tất cả những người tham gia mạng lưới đều không thể tham gia BFT sự đồng thuận trên mỗi khối, do đó thường chỉ có một tập hợp con người tham gia được lấy mẫu ngẫu nhiên đạt được sự đồng thuận. Về nguyên tắc, một tập hợp được lấy mẫu ngẫu nhiên có thể là về mặt lý thuyết có thể bị hỏng một cách thích ứng và một nhánh phân nhánh có thể được tạo ra. hệ thống hoặc cần phải được lập mô hình để sẵn sàng cho một sự kiện như vậy, và do đó vẫn có quy tắc lựa chọn nhánh bên cạnh sự đồng thuận BFT hoặc được thiết kế để đóng xuống trong một sự kiện như vậy. Điều đáng nói là một số thiết kế như Algorand [5], giảm đáng kể khả năng tham nhũng thích ứng. 3. Quan trọng nhất là hệ thống sẽ ngừng hoạt động nếu 1 3 hoặc nhiều hơn trong số tất cả những người tham gia là ngoại tuyến. Do đó, bất kỳ trục trặc mạng tạm thời hoặc sự chia tách mạng nào cũng có thể khiến hệ thống bị đình trệ hoàn toàn. Lý tưởng nhất là hệ thống phải có khả năng tiếp tục hoạt động miễn là có ít nhất một nửa số người tham gia trực tuyến (nặng nhất các giao thức dựa trên chuỗi tiếp tục hoạt động ngay cả khi có ít hơn một nửa số người tham gia trực tuyến, nhưng mức độ mong muốn của đặc tính này còn gây tranh cãi hơn trong cộng đồng). Một mô hình kết hợp trong đó sự đồng thuận được sử dụng là một trong những mô hình nặng nề nhất chuỗi, nhưng một số khối được hoàn thiện định kỳ bằng cách sử dụng tiện ích cuối cùng BFT duy trì những ưu điểm của cả hai mô hình. BFT tiện ích cuối cùng như vậy là Casper FFG [6] được sử dụng trong Ethereum 2.0 8, Casper CBC (xem https://vitalik. ca/general/2018/12/05/cbc_casper.html) và GRANDPA (xem https:// Medium.com/polkadot-network/d08a24a021b5) được sử dụng trong Polkadot. Nightshade sử dụng sự đồng thuận chuỗi cao nhất. Cụ thể khi một khối nhà sản xuất tạo ra một khối (xem phần 3.3), họ có thể thu thập chữ ký từ các nhà sản xuất khối khác và validator chứng thực khối trước đó. Xem phần 3.8 để biết chi tiết về cách tổng hợp số lượng chữ ký lớn như vậy. trọng lượng 8Ngoài ra, hãy xem phiên bảng trắng với Justin Drake để có cái nhìn tổng quan sâu sắc hơn về Casper FFG và cách nó được tích hợp với sự đồng thuận chuỗi nặng nhất GHOST tại đây: https://www. youtube.com/watch?v=S262StTwkmocủa một khối khi đó là cổ phần tích lũy của tất cả những người ký có chữ ký được đưa vào khối. Trọng lượng của chuỗi là tổng trọng lượng của khối. Để đạt được sự đồng thuận cao nhất trong chuỗi, chúng tôi sử dụng tiện ích cuối cùng sử dụng các chứng thực để hoàn thiện các khối. Để giảm độ phức tạp của hệ thống, chúng tôi sử dụng một tiện ích cuối cùng không ảnh hưởng đến quy tắc lựa chọn ngã ba dưới bất kỳ hình thức nào, và thay vào đó chỉ đưa ra các điều kiện cắt bổ sung, sao cho khi một khối được được hoàn thiện bởi tiện ích cuối cùng, việc phân nhánh là không thể trừ khi có một tỷ lệ phần trăm rất lớn tổng số cổ phần bị cắt giảm. Casper CBC là một tiện ích cuối cùng và chúng tôi hiện đang lưu ý đến mô hình Casper CBC. Chúng tôi cũng làm việc trên một giao thức BFT riêng biệt có tên là TxFlow. Vào thời điểm viết tài liệu này, không rõ liệu TxFlow có được sử dụng thay vì Casper hay không CBC. Tuy nhiên, chúng tôi lưu ý rằng việc lựa chọn tiện ích cuối cùng phần lớn là trực giao với phần còn lại của thiết kế. 3.3 Sản xuất khối Trong Nightshade có hai vai trò: nhà sản xuất khối và validators. Tại bất kỳ điểm hệ thống chứa w nhà sản xuất khối, w = 100 trong mô hình của chúng tôi và wv validators, trong mô hình của chúng tôi v = 100, wv = 10.000. Hệ thống là Bằng chứng cổ phần, có nghĩa là cả nhà sản xuất khối và validator đều có một số quyền nội bộ loại tiền tệ (được gọi là ”tokens”) bị khóa trong một khoảng thời gian vượt xa thời gian họ dành để thực hiện nhiệm vụ xây dựng và xác nhận chuỗi. Giống như tất cả các hệ thống Proof of Stake, không phải tất cả các nhà sản xuất khối w và không tất cả wv validator đều là các thực thể khác nhau vì điều đó không thể thực thi được. Mỗi Tuy nhiên, trong số các nhà sản xuất khối w và wv validators có một sự tách biệt cổ phần. Hệ thống chứa n phân đoạn, n = 1000 trong mô hình của chúng tôi. Như đã đề cập ở phần 3.1, trong Nightshade không có chuỗi phân đoạn, thay vào đó tất cả các nhà sản xuất khối và validator đang xây dựng một blockchain duy nhất mà chúng tôi gọi là chuỗi chính. Trạng thái của chuỗi chính được chia thành n phân đoạn và mỗi khối nhà sản xuất và validator bất kỳ lúc nào cũng chỉ tải xuống cục bộ một tập hợp con của trạng thái tương ứng với một số tập hợp con của phân đoạn và chỉ xử lý và xác thực các giao dịch ảnh hưởng đến các phần đó của trạng thái. Để trở thành nhà sản xuất khối, một người tham gia mạng sẽ khóa một số lượng lớn số lượng tokens (tiền đặt cọc). Việc bảo trì mạng được thực hiện theo thời gian, trong đó một kỷ nguyên là một khoảng thời gian theo thứ tự ngày. Những người tham gia với w cổ phần lớn nhất vào đầu một kỷ nguyên cụ thể là khối nhà sản xuất của thời đại đó. Mỗi nhà sản xuất khối được gán cho các phân đoạn sw, (giả sử sw = 40, điều này sẽ tạo ra sww/n = 4 nhà sản xuất khối trên mỗi phân đoạn). khối nhà sản xuất tải xuống trạng thái của phân đoạn mà họ được chỉ định trước kỷ nguyên bắt đầu và trong suốt thời kỳ đó sẽ thu thập các giao dịch ảnh hưởng đến phân đoạn đó, và áp dụng chúng cho nhà nước. Đối với mỗi khối b trên chuỗi chính và với mỗi phân đoạn, có một trong giao các nhà sản xuất khối cho s, người chịu trách nhiệm sản xuất phần liên quan của b đến mảnh vỡ. Phần của b liên quan đến phân đoạn s được gọi là đoạn và chứa danh sách các giao dịch cho phân đoạn được bao gồm trong b, cũng như merklegốc của trạng thái kết quả. b cuối cùng sẽ chỉ chứa một tiêu đề rất nhỏ của đoạn, cụ thể là gốc merkle của tất cả các giao dịch được áp dụng (xem phần 3.7.1 để biết chi tiết chính xác) và nghiệm merkle của trạng thái cuối cùng. Trong suốt phần còn lại của tài liệu, chúng tôi thường đề cập đến nhà sản xuất khối có trách nhiệm tạo ra một đoạn tại một thời điểm cụ thể cho một phân đoạn cụ thể với tư cách là một nhà sản xuất chunk. Nhà sản xuất chunk luôn là một trong những nhà sản xuất khối. Các nhà sản xuất khối và các nhà sản xuất khối xoay vòng từng khối theo theo một lịch trình cố định. Các nhà sản xuất khối có đơn đặt hàng và liên tục sản xuất khối theo thứ tự đó. Ví dụ. nếu có 100 nhà sản xuất khối thì khối đầu tiên nhà sản xuất chịu trách nhiệm sản xuất khối 1, 101, 201, v.v., khối thứ hai là chịu trách nhiệm sản xuất 2, 102, 202, v.v.). Vì sản xuất theo khối, không giống như sản xuất theo khối, đòi hỏi phải duy trì trạng thái và đối với mỗi phân đoạn, chỉ có nhà sản xuất khối sww/n mới duy trì trạng thái trên mỗi phân đoạn, tương ứng chỉ những nhà sản xuất khối sww/n mới xoay vòng để tạo khối. Ví dụ. với các hằng số ở trên với bốn nhà sản xuất khối được gán cho mỗi phân đoạn, mỗi nhà sản xuất khối sẽ tạo ra các khối cứ bốn khối một lần. 3,4 Đảm bảo tính sẵn có của dữ liệu Để đảm bảo tính khả dụng của dữ liệu, chúng tôi sử dụng phương pháp tương tự như phương pháp của Polkadot được mô tả ở phần 2.5.3. Khi nhà sản xuất khối tạo ra một đoạn, họ sẽ tạo một phiên bản được mã hóa xóa của nó với mã khối tối ưu (w, ⌊w/6 + 1⌋) của khúc. Sau đó, họ gửi một phần của đoạn mã bị xóa (chúng tôi gọi những phần đó là từng phần hoặc chỉ các phần) cho mỗi nhà sản xuất khối. Chúng tôi tính toán một cây merkle chứa tất cả các phần là lá và tiêu đề của mỗi đoạn chứa gốc merkle của cây đó. Các bộ phận được gửi tới validator thông qua tin nhắn một phần. Mỗi tin nhắn như vậy chứa tiêu đề chunk, thứ tự của phần và nội dung phần. các tin nhắn cũng chứa chữ ký của nhà sản xuất khối đã tạo ra chunk và đường dẫn merkle để chứng minh rằng phần đó tương ứng với tiêu đề và được sản xuất bởi nhà sản xuất khối thích hợp. Khi nhà sản xuất khối nhận được khối chuỗi chính, trước tiên họ sẽ kiểm tra xem chúng có có các thông điệp một phần cho mỗi đoạn được bao gồm trong khối. Nếu không, khối không được xử lý cho đến khi các tin nhắn onepart bị thiếu được lấy ra. Sau khi nhận được tất cả các tin nhắn một phần, nhà sản xuất khối sẽ tìm nạp các phần còn lại từ các đồng nghiệp và xây dựng lại các khối mà chúng nắm giữ nhà nước. Nhà sản xuất khối không xử lý khối chuỗi chính nếu có ít nhất một khối đoạn được bao gồm trong khối thì chúng không có thông báo một phần tương ứng hoặc nếu đối với ít nhất một phân đoạn mà chúng duy trì trạng thái thì chúng không thể xây dựng lại toàn bộ đoạn. Để có sẵn một đoạn cụ thể, chỉ cần ⌊w/6⌋+1 của khối là đủ nhà sản xuất có bộ phận của họ và phục vụ họ. Vì vậy, miễn là số lượng tác nhân độc hại không vượt quá ⌊w/3⌋không có chuỗi nào có hơn nửa khối các nhà sản xuất xây dựng nó có thể có những phần không có sẵn.Hình 17: Mỗi khối chứa một hoặc không có khối trên mỗi phân đoạn và mỗi khối được mã hóa xóa. Mỗi phần của đoạn mã xóa được gửi đến một địa chỉ được chỉ định nhà sản xuất khối thông qua tin nhắn onepart đặc biệt 3.4.1 Đối phó với các nhà sản xuất khối lười biếng Nếu nhà sản xuất khối có một khối bị thiếu thông báo một phần, họ sẽ có thể chọn vẫn đăng nhập vào nó, bởi vì nếu khối đó cuối cùng vẫn nằm trong chuỗi sẽ tối đa hóa phần thưởng cho nhà sản xuất khối. Không có rủi ro cho việc chặn nhà sản xuất vì sau này không thể chứng minh rằng nhà sản xuất khối không có tin nhắn một phần. Để giải quyết vấn đề này, chúng tôi tạo ra mỗi nhà sản xuất đoạn khi tạo đoạn để chọn một màu (đỏ hoặc xanh) cho từng phần của đoạn được mã hóa trong tương lai và lưu trữ bitmask của màu được gán trong đoạn trước khi nó được mã hóa. Mỗi phần một sau đó thông báo chứa màu được gán cho phần đó và màu này được sử dụng khi tính toán gốc merkle của các phần được mã hóa. Nếu nhà sản xuất chunk đi chệch hướng từ giao thức, điều đó có thể được chứng minh dễ dàng vì gốc merkle sẽ không tương ứng với tin nhắn một phần hoặc màu sắc trong tin nhắn một phần tương ứng với gốc merkle sẽ không khớp với mặt nạ trong đoạn. Khi nhà sản xuất khối ký vào một khối, họ sẽ bao gồm một bitmask của tất cả phần màu đỏ mà họ nhận được cho các khối có trong khối. Xuất bản một bitmask không chính xác là một hành vi có thể gạch chéo. Nếu nhà sản xuất khối chưa nhận được một tin nhắn, họ không có cách nào biết được màu sắc của tin nhắn, và do đó có 50% khả năng bị chém nếu họ cố gắng mù quáng ký vào bản hợp đồng. khối. 3,5 Ứng dụng chuyển trạng thái Nhà sản xuất khối chỉ chọn những giao dịch nào sẽ được đưa vào khối nhưng không áp dụng chuyển đổi trạng thái khi chúng tạo ra một đoạn. Tương ứng,
tiêu đề chunk chứa gốc merkle của trạng thái merkelized như trước các giao dịch trong chunk được áp dụng. Các giao dịch chỉ được áp dụng khi một khối đầy đủ bao gồm đoạn được xử lý. Một người tham gia chỉ xử lý một khối nếu 1. Khối trước đó đã được nhận và xử lý; 2. Đối với mỗi đoạn, người tham gia không duy trì trạng thái vì họ có đã xem tin nhắn onepart; 3. Đối với mỗi đoạn, người tham gia duy trì trạng thái vì họ có đoạn đầy đủ. Sau khi khối được xử lý, đối với mỗi phân đoạn mà người tham gia duy trì trạng thái, áp dụng các giao dịch và tính toán trạng thái mới kể từ sau khi các giao dịch được áp dụng, sau đó họ đã sẵn sàng sản xuất các khối cho khối tiếp theo, nếu chúng được gán cho bất kỳ phân đoạn nào, vì chúng có gốc merkle của trạng thái merkelized mới. 3.6 Giao dịch và biên lai chéo Nếu một giao dịch cần ảnh hưởng đến nhiều phân đoạn, thì nó cần phải được thực hiện liên tục được thực hiện trong từng phân đoạn riêng biệt. Giao dịch đầy đủ được gửi đến phân đoạn đầu tiên bị ảnh hưởng và khi giao dịch được bao gồm trong khối cho phân đoạn đó và được áp dụng sau khi đoạn được đưa vào một khối, nó tạo ra cái gọi là biên nhận giao dịch, được chuyển đến phân đoạn tiếp theo mà giao dịch cần thực hiện được thực thi. Nếu cần nhiều bước hơn, việc thực hiện giao dịch nhận tạo ra một giao dịch biên nhận mới, v.v. 3.6.1 Thời gian nhận giao dịch Điều mong muốn là giao dịch nhận được áp dụng trong khối ngay sau khối mà nó được tạo. Giao dịch nhận tiền chỉ được tạo sau khi khối trước đó được các nhà sản xuất khối nhận và áp dụng duy trì phân đoạn ban đầu và cần được biết vào thời điểm chunk cho khối tiếp theo được tạo ra bởi nhà sản xuất khối của đích mảnh vỡ. Do đó, biên nhận phải được truyền từ phân đoạn nguồn đến phân đoạn đích trong khung thời gian ngắn giữa hai sự kiện đó. Đặt A là khối được tạo cuối cùng chứa giao dịch t tạo ra biên nhận r. Đặt B là khối được tạo tiếp theo (tức là khối có A là khối trước đó của nó) mà chúng ta muốn chứa r. Đặt t ở trong mảnh a và r là trong mảnh vỡ b. Thời hạn sử dụng của biên nhận, cũng được mô tả trên hình 18, như sau: Lập và lưu trữ hóa đơn. Cpa của nhà sản xuất chunk cho phân đoạn a nhận khối A, áp dụng giao dịch t và tạo biên nhận r. cpa sau đó lưu trữ tất cả các biên lai được tạo ra như vậy trong bộ lưu trữ liên tục nội bộ được lập chỉ mục theo id phân đoạn nguồn.Phân phối các khoản thu. Khi cpa đã sẵn sàng để tạo đoạn cho phân đoạn a cho khối B, họ tìm nạp tất cả các biên lai được tạo bằng cách áp dụng các giao dịch từ khối A cho phân đoạn a và đưa chúng vào đoạn cho phân đoạn a trong khối B. Một khi đoạn như vậy được tạo ra, cpa sẽ tạo ra mã xóa của nó phiên bản và tất cả các thông báo onepart tương ứng. cpa biết nhà sản xuất khối nào duy trì trạng thái đầy đủ cho phân đoạn nào. Đối với một nhà sản xuất khối cụ thể bp cpa bao gồm các khoản thu được từ việc áp dụng các giao dịch trong khối A đối với phân đoạn a có bất kỳ phân đoạn nào mà bp quan tâm làm đích đến của họ trong tin nhắn onepart khi họ phân phối đoạn cho phân đoạn a trong khối B (xem hình 17, hiển thị các biên nhận có trong thông báo một phần). Nhận biên lai. Hãy nhớ rằng những người tham gia (cả nhà sản xuất khối và validator) không xử lý các khối cho đến khi họ có thông báo một phần cho mỗi đoạn có trong khối. Do đó, vào thời điểm bất kỳ người tham gia cụ thể nào áp dụng khối B, họ có tất cả các thông báo một phần tương ứng với các khối trong B và do đó họ có tất cả các biên nhận đến có các phân đoạn người tham gia duy trì trạng thái làm điểm đến của họ. Khi áp dụng các chuyển trạng thái cho một phân đoạn cụ thể, người tham gia sẽ áp dụng cả biên lai mà họ đã thu thập cho phân đoạn trong tin nhắn một phần, cũng như tất cả các giao dịch được bao gồm trong chính đoạn đó. Hình 18: Thời gian tồn tại của một giao dịch biên nhận 3.6.2 Xử lý quá nhiều biên lai Có thể số lượng biên lai nhắm mục tiêu vào một phân đoạn cụ thể trong một khối cụ thể quá lớn để được xử lý. Ví dụ, hãy xem xét hình 19, trong mỗi giao dịch trong mỗi phân đoạn sẽ tạo ra một biên nhận nhắm mục tiêu phân đoạn 1. Ở khối tiếp theo, số biên nhận mà phân đoạn 1 cần xử lý là có thể so sánh với tải mà tất cả các phân đoạn kết hợp được xử lý trong khi xử lý khối trước đó.
Hình 19: Nếu tất cả các khoản thu đều nhắm mục tiêu vào cùng một phân đoạn thì phân đoạn đó có thể không có khả năng xử lý chúng Để giải quyết vấn đề này, chúng tôi sử dụng một kỹ thuật tương tự như kỹ thuật được sử dụng trong QuarkChain 9. Cụ thể, đối với mỗi phân đoạn, khối B cuối cùng và phân đoạn cuối cùng trong đó khối mà biên lai được áp dụng được ghi lại. Khi có phân đoạn mới được tạo, biên nhận được áp dụng theo thứ tự đầu tiên từ các phân đoạn còn lại trong B, và sau đó theo các khối theo B, cho đến khi khối mới đầy. Dưới mức bình thường trường hợp có tải trọng cân bằng nhìn chung sẽ dẫn đến tất cả các khoản thu đang được áp dụng (và do đó phân đoạn cuối cùng của khối cuối cùng sẽ được ghi lại cho từng đoạn), nhưng trong những thời điểm tải không cân bằng và một phần cụ thể phân đoạn nhận được nhiều biên lai không tương xứng, kỹ thuật này cho phép họ được xử lý đồng thời tôn trọng các giới hạn về số lượng giao dịch được đưa vào. Lưu ý rằng nếu tải không cân bằng như vậy tồn tại trong một thời gian dài thì độ trễ từ việc tạo biên lai cho đến khi ứng dụng có thể tiếp tục phát triển vô thời hạn. một cách để giải quyết vấn đề này là loại bỏ bất kỳ giao dịch nào tạo ra biên nhận nhắm mục tiêu phân đoạn có độ trễ xử lý vượt quá một số hằng số (ví dụ: một kỷ nguyên). Hãy xem xét hình 20. Theo khối B, phân đoạn 4 không thể xử lý tất cả các biên nhận, vì vậy nó chỉ xử lý nguồn gốc biên lai từ tối đa phân đoạn 3 trong khối A và ghi lại nó. Trong khối C, bao gồm các khoản thu lên tới phân đoạn 5 trong khối B và sau đó đến khối D, phân đoạn sẽ bắt kịp, xử lý tất cả các khoản thu còn lại trong khối B và tất cả các khoản thu từ khối C. 3,7 Xác thực khối Một đoạn được tạo cho một phân đoạn cụ thể (hoặc một khối phân đoạn được tạo cho một chuỗi phân đoạn cụ thể trong mô hình có chuỗi phân đoạn) chỉ có thể được xác thực bởi 9Xem tập bảng trắng với QuarkChain tại đây: https://www.youtube.com/watch? v=opEtG6NM4x4, trong đó cách tiếp cận các giao dịch chéo được thảo luận, cùng với các vấn đề khác nhiều thứHình 20: Xử lý biên lai bị trì hoãn những người tham gia duy trì trạng thái. Họ có thể là nhà sản xuất khối, validators, hoặc chỉ những nhân chứng bên ngoài đã tải xuống trạng thái và xác thực phân đoạn trong mà họ lưu trữ tài sản. Trong tài liệu này chúng tôi giả định rằng phần lớn những người tham gia không thể lưu trữ trạng thái cho một phần lớn các phân đoạn. Tuy nhiên, điều đáng nói là rằng có blockchain được phân chia được thiết kế với giả định rằng hầu hết người tham gia đều có khả năng lưu trữ trạng thái và xác thực hầu hết các phân đoạn, chẳng hạn như QuarkChain. Vì chỉ một phần nhỏ người tham gia có trạng thái xác thực phân đoạn các khối, có thể thích ứng với tham nhũng chỉ những người tham gia có trạng thái và áp dụng chuyển đổi trạng thái không hợp lệ. Nhiều thiết kế phân đoạn đã được đề xuất lấy mẫu validator cứ sau vài lần ngày và trong vòng một ngày, bất kỳ khối nào trong chuỗi phân đoạn có hơn 2/3 chữ ký của validator được gán cho phân đoạn đó sẽ được xem xét ngay lập tức cuối cùng. Với cách tiếp cận như vậy, đối thủ thích ứng chỉ cần làm hỏng 2n/3+1 của validator trong chuỗi phân đoạn để áp dụng chuyển đổi trạng thái không hợp lệ, trong đó, mặc dù có thể khó thực hiện nhưng mức độ bảo mật không đủ cho công chúng blockchain. Như đã thảo luận trong phần 2.3, cách tiếp cận phổ biến là cho phép một khoảng thời gian nhất định sau khi khối được tạo cho bất kỳ người tham gia nào có trạng thái (cho dù đó là nhà sản xuất khối, validator hoặc người quan sát bên ngoài) để thách thức tính hợp lệ của nó. Những người tham gia như vậy được gọi là Ngư dân. Để một ngư dân có thể thách thức một khối không hợp lệ, phải đảm bảo rằng khối đó có sẵn để họ. Tính khả dụng của dữ liệu trong Nightshade được thảo luận trong phần 3.4. Trong Nightshade khi một khối được tạo ra, các khối không được xác thực bởi bất cứ ai ngoại trừ nhà sản xuất chunk thực sự. Đặc biệt, nhà sản xuất khối đó đề xuất khối tự nhiên không có trạng thái cho hầu hết các phân đoạn vàđã không thể xác nhận các khối. Khi khối tiếp theo được tạo ra, nó chứa các chứng thực (xem phần 3.2) của nhiều nhà sản xuất khối và validators, nhưng vì phần lớn các nhà sản xuất khối và validator không duy trì trạng thái đối với hầu hết các phân đoạn, một khối chỉ có một đoạn không hợp lệ sẽ thu thập được hơn một nửa số chứng thực và sẽ tiếp tục ở trạng thái nặng nhất. chuỗi. Để giải quyết vấn đề này, chúng tôi cho phép bất kỳ người tham gia nào duy trì trạng thái một phân đoạn để gửi thử thách trên chuỗi cho bất kỳ đoạn không hợp lệ nào được tạo ra trong đó mảnh vỡ. 3.7.1 Thử thách tính hợp lệ của trạng thái Khi người tham gia phát hiện thấy một đoạn cụ thể không hợp lệ, họ cần cung cấp bằng chứng cho thấy đoạn đó không hợp lệ. Vì phần lớn những người tham gia mạng không duy trì trạng thái cho phân đoạn có đoạn không hợp lệ được tạo ra, bằng chứng cần phải có đủ thông tin để xác nhận khối đó là không hợp lệ nếu không có trạng thái. Chúng tôi đặt giới hạn Ls về số lượng trạng thái (tính bằng byte) mà một giao dịch đơn lẻ có thể đọc hoặc viết tích lũy. Bất kỳ giao dịch nào chạm nhiều hơn Ls trạng thái được coi là không hợp lệ. Hãy nhớ từ phần 3.5 rằng đoạn trong khối B cụ thể chỉ chứa các giao dịch được áp dụng chứ không chứa gốc trạng thái mới. Gốc trạng thái có trong đoạn trong khối B là trạng thái root trước khi áp dụng các giao dịch đó, nhưng sau khi áp dụng các giao dịch từ đoạn cuối cùng trong cùng phân đoạn trước khối B. Một tác nhân độc hại mong muốn áp dụng chuyển đổi trạng thái không hợp lệ sẽ bao gồm gốc trạng thái không chính xác trong khối B không tương ứng với gốc trạng thái do áp dụng các giao dịch ở đoạn trước. Chúng tôi mở rộng thông tin mà nhà sản xuất chunk đưa vào chunk. Thay vì chỉ thêm trạng thái sau khi áp dụng tất cả các giao dịch, nó thay vào đó bao gồm một gốc trạng thái sau khi áp dụng từng bộ giao dịch liền kề đọc và ghi chung Ls byte trạng thái. Với thông tin này cho Fisherman tạo ra một thách thức rằng việc chuyển đổi trạng thái được áp dụng không chính xác là đủ để tìm ra gốc trạng thái không hợp lệ đầu tiên và chỉ bao gồm Ls byte của trạng thái bị ảnh hưởng bởi các giao dịch giữa trạng thái gốc cuối cùng (được hợp lệ) và trạng thái gốc hiện tại với bằng chứng merkle. Sau đó bất kỳ người tham gia nào có thể xác thực các giao dịch trong phân đoạn và xác nhận rằng đoạn đó là không hợp lệ. Tương tự, nếu nhà sản xuất chunk cố gắng đưa vào các giao dịch đọc và ghi nhiều hơn L byte trạng thái, đối với thử thách này, chỉ cần bao gồm Ls byte đầu tiên mà nó chạm tới với bằng chứng merkle, điều này sẽ đủ để áp dụng các giao dịch và xác nhận rằng sẽ có lúc cố gắng thực hiện đọc hoặc ghi nội dung vượt quá Ls byte được thực hiện.
3.7.2 Ngư dân và giao dịch xuyên mảnh nhanh chóng Như đã thảo luận trong phần 2.3, khi chúng ta giả định rằng các đoạn phân đoạn (hoặc phân đoạn các khối trong mô hình có chuỗi phân đoạn) có thể không hợp lệ và gây ra thách thức theo thời gian, nó ảnh hưởng tiêu cực đến tính cuối cùng và do đó giao tiếp giữa các phân đoạn. trong cụ thể, phân đoạn đích của bất kỳ chuyển đổi chéo nào đều không thể chắc chắn đoạn hoặc khối phân đoạn ban đầu là cuối cùng cho đến khi giai đoạn thử thách kết thúc (xem hình 21). Hình 21: Chờ đợi thời gian thử thách trước khi áp dụng biên nhận Cách giải quyết vấn đề theo cách thực hiện các giao dịch chéo tức thời là để mảnh đích không phải đợi đến giai đoạn thử thách sau khi giao dịch phân đoạn nguồn được xuất bản và áp dụng giao dịch biên nhận ngay lập tức, nhưng sau đó khôi phục phân đoạn đích cùng với phân đoạn nguồn phân đoạn nếu sau đó đoạn hoặc khối ban đầu được phát hiện là không hợp lệ (xem hình 22). Điều này áp dụng rất tự nhiên cho thiết kế Nightshade trong đó mảnh vỡ các chuỗi không độc lập mà thay vào đó, các đoạn phân đoạn đều được xuất bản cùng nhau trong cùng một khối chuỗi chính. Nếu bất kỳ đoạn nào được phát hiện là không hợp lệ, toàn bộ khối có đoạn đó được coi là không hợp lệ và tất cả các khối được xây dựng trên trên hết. Xem hình 23. Cả hai cách tiếp cận trên đều cung cấp tính nguyên tử giả định rằng thách thức thời gian đủ dài. Chúng tôi sử dụng phương pháp thứ hai vì việc cung cấp các giao dịch chéo nhanh trong các trường hợp thông thường sẽ vượt qua sự bất tiện của phân đoạn đích quay trở lại do chuyển đổi trạng thái không hợp lệ ở một trong các các mảnh nguồn, đây là một sự kiện cực kỳ hiếm. 3.7.3 Đang ẩn validators Sự tồn tại của những thách thức đã làm giảm đáng kể khả năng xảy ra tham nhũng thích ứng, vì để hoàn thiện một đoạn có bài chuyển đổi trạng thái không hợp lệHình 22: Áp dụng biên lai ngay lập tức và quay trở lại điểm đến chuỗi nếu chuỗi nguồn có khối không hợp lệ Hình 23: Thử thách làm ngư dân trong Nightshade giai đoạn thử thách mà đối thủ thích ứng cần để làm hỏng tất cả những người tham gia duy trì trạng thái của phân đoạn, bao gồm tất cả validator. Việc ước tính khả năng xảy ra một sự kiện như vậy là vô cùng phức tạp, vì không có sharded blockchain đã tồn tại đủ lâu để thực hiện bất kỳ cuộc tấn công nào như vậy. Chúng tôi lập luận rằng xác suất, mặc dù cực kỳ thấp, nhưng vẫn đủ lớn đối với một hệ thống dự kiến sẽ thực hiện hàng triệu giao dịch và điều hành các hoạt động tài chính trên toàn thế giới. Có hai lý do chính cho niềm tin này: 1. Hầu hết validator của chuỗi Bằng chứng cổ phần và công cụ khai thác của
Chuỗi Proof-of-Work chủ yếu được khuyến khích bởi lợi ích tài chính. Nếu một đối thủ có khả năng thích ứng mang lại cho họ nhiều tiền hơn lợi nhuận kỳ vọng từ việc vận hành một cách trung thực, thật hợp lý khi mong đợi rằng nhiều validators sẽ chấp nhận lời đề nghị. 2. Nhiều tổ chức thực hiện xác thực chuỗi Proof-of-Stake một cách chuyên nghiệp và người ta dự kiến rằng một tỷ lệ lớn cổ phần trong bất kỳ chuỗi nào sẽ được từ các thực thể đó. Số lượng các thực thể như vậy đủ nhỏ để đối thủ thích nghi để tìm hiểu cá nhân hầu hết họ và có một hiểu rõ khuynh hướng của họ là bị tha hóa. Chúng tôi tiến thêm một bước nữa trong việc giảm khả năng xảy ra lỗi thích ứng bằng cách ẩn validator được gán cho phân đoạn nào. Ý tưởng là tương tự như cách Algorand [5] che giấu validators. Điều quan trọng cần lưu ý là ngay cả khi validator bị ẩn, như trong Algorand hoặc như được mô tả dưới đây, về mặt lý thuyết, tham nhũng thích ứng vẫn có thể xảy ra. Trong khi đối thủ thích ứng không biết những người tham gia sẽ tạo hoặc xác thực một khối hay một đoạn, bản thân những người tham gia đều biết rằng họ sẽ thực hiện một nhiệm vụ như vậy và có bằng chứng mật mã về nó. Vì vậy, đối thủ có thể truyền bá ý định tham nhũng của họ và trả tiền cho bất kỳ người tham gia nào sẽ cung cấp một bằng chứng mật mã như vậy. Tuy nhiên, chúng tôi lưu ý rằng vì đối thủ không biết validator được gán cho phân đoạn mà chúng muốn làm hỏng, chúng không có lựa chọn nào khác ngoài việc truyền bá ý định làm hỏng một phân đoạn cụ thể tới toàn bộ cộng đồng. Vào thời điểm đó, nó mang lại lợi ích kinh tế cho bất kỳ người trung thực nào. người tham gia tạo ra một nút đầy đủ để xác thực phân đoạn đó vì có mức cao khả năng một khối không hợp lệ xuất hiện trong phân đoạn đó, đây là cơ hội để tạo ra một thử thách và thu thập phần thưởng liên quan. Để không tiết lộ validator được gán cho một phân đoạn cụ thể, chúng tôi thực hiện sau đây (xem hình 24): Sử dụng VRF để nhận nhiệm vụ. Vào đầu mỗi thời đại, mỗi validator sử dụng VRF để lấy mặt nạ bit của các phân đoạn mà validator được gán cho. Mặt nạ bit của mỗi validator sẽ có các bit Sw (xem phần 3.3 để biết định nghĩa của Sw). validator sau đó tìm nạp trạng thái của các phân đoạn tương ứng và trong kỷ nguyên cho mỗi khối nhận được sẽ xác thực các khối tương ứng vào các phân đoạn mà validator được gán cho. Đăng nhập vào khối thay vì khối. Vì việc gán phân đoạn bị ẩn nên validator không thể đăng nhập vào các phân đoạn. Thay vào đó nó luôn ký trên toàn bộ chặn, do đó không tiết lộ những phân đoạn mà nó xác nhận. Cụ thể, khi validator nhận được một khối và xác thực tất cả các khối, nó sẽ tạo ra một thông báo chứng thực rằng tất cả các đoạn trong tất cả các phân đoạn mà validator được chỉ định là hợp lệ (không cho biết những phân đoạn đó là gì) hoặc một thông báo rằng chứa bằng chứng về việc chuyển đổi trạng thái không hợp lệ nếu bất kỳ đoạn nào không hợp lệ. Xem phần 3.8 để biết chi tiết về cách tổng hợp các thông báo đó, phần 3.7.4 để biết chi tiết về cách ngăn chặn validator lợi dụng tin nhắn từ validators khác và phần 3.7.5 để biết chi tiết về cách khen thưởng và trừng phạt validators nếu thử thách chuyển đổi trạng thái không hợp lệ thành công thực sự xảy ra.Hình 24: Che giấu validator trong Nightshade 3.7.4 Cam kết-Tiết lộ Một trong những vấn đề phổ biến với validator là validator có thể bỏ qua việc tải xuống trạng thái và thực sự xác thực các khối và khối, thay vào đó quan sát mạng, xem những gì validator khác gửi và lặp lại tin nhắn. validator tuân theo chiến lược như vậy sẽ không cung cấp thêm bất kỳ bảo mật cho mạng nhưng thu thập phần thưởng. Một giải pháp phổ biến cho vấn đề này là mỗi validator cung cấp bằng chứng rằng họ thực sự đã xác thực khối đó, chẳng hạn như bằng cách cung cấp dấu vết duy nhất áp dụng chuyển đổi trạng thái, nhưng những bằng chứng như vậy làm tăng đáng kể chi phí xác nhận. Hình 25: Cam kết tiết lộ
Thay vào đó, chúng tôi thực hiện cam kết đầu tiên của validator với kết quả xác thực (hoặc thông báo chứng thực tính hợp lệ của các khối hoặc bằng chứng về tính hợp lệ của chuyển trạng thái), đợi một khoảng thời gian nhất định và chỉ sau đó mới tiết lộ kết quả xác thực thực tế, như được hiển thị trên hình 25. Khoảng thời gian cam kết không giao nhau với khoảng thời gian tiết lộ và do đó một validator lười biếng không thể bắt chước những validator trung thực. Hơn nữa, nếu một validator không trung thực cam kết thực hiện một thông báo chứng thực tính hợp lệ của các đoạn được gán và ít nhất một đoạn không hợp lệ một khi nó được đã chỉ ra rằng đoạn đó không hợp lệ nên validator không thể tránh được việc gạch chéo, vì, như chúng tôi trình bày trong phần 3.7.5, cách duy nhất để không bị chém trong tình huống như vậy là đưa ra một thông báo chứa bằng chứng về việc chuyển đổi trạng thái không hợp lệ phù hợp với cam kết. 3.7.5 Xử lý thử thách Như đã thảo luận ở trên, khi validator nhận được một khối có đoạn không hợp lệ, đầu tiên họ chuẩn bị bằng chứng về sự chuyển đổi trạng thái không hợp lệ (xem phần 3.7.1), sau đó cam kết với một bằng chứng như vậy (xem 3.7.4), và sau một thời gian hãy tiết lộ thách thức. Khi thử thách được tiết lộ được đưa vào một khối, điều sau đây sẽ xảy ra: 1. Tất cả các chuyển đổi trạng thái xảy ra từ khối chứa đoạn không hợp lệ cho đến khi khối chứa thử thách được tiết lộ bị vô hiệu hóa. Trạng thái trước khối bao gồm thử thách được tiết lộ được coi là giống với trạng thái trước khối chứa đoạn không hợp lệ. 2. Trong một khoảng thời gian nhất định, mỗi validator phải tiết lộ mặt nạ bit của mình của các phân đoạn mà họ xác nhận. Vì mặt nạ bit được tạo thông qua VRF, nếu họ được gán cho phân đoạn có quá trình chuyển đổi trạng thái không hợp lệ, họ không thể tránh khỏi việc tiết lộ nó. Bất kỳ validator nào không tiết lộ được mặt nạ bit được cho là được gán cho phân đoạn. 3. Mỗi validator sau khoảng thời gian đó được phát hiện sẽ được gán cho phân đoạn, đã cam kết với một số kết quả xác thực cho khối chứa đoạn không hợp lệ và điều đó không tiết lộ bằng chứng về việc chuyển đổi trạng thái không hợp lệ tương ứng với cam kết của họ bị cắt giảm. 4. Mỗi validator nhận được một phân đoạn mới và một kỷ nguyên mới được lên lịch bắt đầu sau một khoảng thời gian đủ để tất cả validator tải xuống trạng thái, như thể hiện trên hình 26. Lưu ý rằng kể từ thời điểm validator tiết lộ các phân đoạn mà chúng được chỉ định cho đến khi kỷ nguyên mới bắt đầu, tính bảo mật của hệ thống sẽ bị giảm do phân công mảnh vỡ được tiết lộ. Những người tham gia mạng cần phải giữ nó lưu ý khi sử dụng mạng trong thời gian đó. 3,8 Tổng hợp chữ ký Để một hệ thống có hàng trăm phân đoạn hoạt động an toàn, chúng tôi muốn có trên đơn hàng từ 10.000 trở lên validators. Như đã thảo luận trong phần 3.7, chúng tôi muốn mỗiHình 26: Xử lý thử thách validator để xuất bản một cam kết cho một tin nhắn nhất định và một chữ ký ở mức trung bình một lần cho mỗi khối. Ngay cả khi các thông điệp cam kết giống nhau, việc tổng hợp như vậy Chữ ký BLS và việc xác nhận nó sẽ rất tốn kém. Nhưng đương nhiên các thông báo cam kết và tiết lộ không giống nhau trên validators, và do đó chúng ta cần một số cách để tổng hợp các thông điệp và chữ ký đó trong một cách cho phép xác nhận nhanh chóng sau này. Cách tiếp cận cụ thể mà chúng tôi sử dụng như sau: Người xác nhận tham gia các nhà sản xuất khối. Các nhà sản xuất khối được biết đến một thời gian trước khi kỷ nguyên bắt đầu, vì họ cần một chút thời gian để tải xuống trạng thái trước khi kỷ nguyên bắt đầu và không giống như validator, các nhà sản xuất khối không che giấu. Mỗi nhà sản xuất khối có v validator vị trí. Trình xác nhận gửi đề xuất ngoài chuỗi cho các nhà sản xuất khối để được đưa vào như một trong những v validators. Nếu nhà sản xuất khối muốn bao gồm validator, họ sẽ gửi giao dịch chứa yêu cầu ngoài chuỗi ban đầu từ validator và chữ ký của nhà sản xuất khối khiến validator tham gia nhà sản xuất khối. Lưu ý rằng validator được gán cho nhà sản xuất khối không nhất thiết xác thực các phân đoạn tương tự mà nhà sản xuất khối tạo ra các khối. Nếu một validator áp dụng để tham gia nhiều nhà sản xuất khối, chỉ giao dịch từ nhà sản xuất khối đầu tiên sẽ thành công. Các nhà sản xuất khối thu thập các cam kết. Nhà sản xuất khối liên tục thu thập các thông báo cam kết và tiết lộ từ validator. Khi một số lượng tin nhắn như vậy nhất định được tích lũy, nhà sản xuất khối sẽ tính toán một merkle cây của những tin nhắn này và gửi tới mỗi validator gốc merkle và đường dẫn merkle đến tin nhắn của họ. validator xác thực đường dẫn và đăng nhập rễ merkle. Sau đó, nhà sản xuất khối sẽ tích lũy chữ ký BLS trên gốc merkle từ validators và chỉ xuất bản gốc merkle và chữ ký tích lũy Nhà sản xuất khối cũng ký vào tính hợp lệ của đa chữ ký bằng cách sử dụng chữ ký ECDSA giá rẻ. Nếu đa chữ ký không khớp với gốc merkle được gửi hoặc bitmask của validator tham gia, đó là hành vi có thể cắt được. Khi đồng bộ hóa chuỗi, người tham gia có thể chọn xác thực tất cả chữ ký BLS từ các validator (việc này cực kỳ tốn kém vì nó liên quan đến việc tổng hợp các khóa công khai của validator) hoặc chỉchữ ký ECDMA từ các nhà sản xuất khối và dựa vào thực tế là nhà sản xuất khối không bị thách thức và bị chém. Sử dụng các giao dịch trên chuỗi và bằng chứng merkle để giải quyết các thách thức. Nó có thể lưu ý rằng việc tiết lộ tin nhắn từ validator sẽ không có giá trị gì nếu không chuyển đổi trạng thái không hợp lệ đã được phát hiện. Chỉ những tin nhắn có chứa thông tin thực tế bằng chứng về việc chuyển đổi trạng thái không hợp lệ cần phải được tiết lộ và chỉ dành cho những tin nhắn như vậy nó cần phải được chứng minh rằng chúng phù hợp với cam kết trước đó. Thông điệp cần phải được tiết lộ nhằm hai mục đích: 1. Để thực sự bắt đầu quá trình khôi phục chuỗi về thời điểm trước khi thực hiện chuyển trạng thái không hợp lệ (xem phần 3.7.5). 2. Để chứng minh rằng validator không cố gắng chứng thực tính hợp lệ của đoạn không hợp lệ. Trong cả hai trường hợp, chúng ta cần giải quyết hai vấn đề: 1. Cam kết thực tế không được đưa vào chuỗi, chỉ có gốc merkle của cam kết tổng hợp với các tin nhắn khác. validator cần sử dụng đường dẫn merkle do nhà sản xuất khối cung cấp và cam kết ban đầu của họ đối với chứng minh rằng họ đã cam kết với thử thách. 2. Có thể tất cả validator được gán cho phân đoạn có giá trị không hợp lệ quá trình chuyển đổi trạng thái xảy ra được gán cho các nhà sản xuất khối bị hỏng đang kiểm duyệt chúng. Để giải quyết vấn đề này, chúng tôi cho phép họ gửi tiết lộ của mình như một giao dịch thông thường trên chuỗi và bỏ qua việc tổng hợp. Cái sau chỉ được phép đối với các bằng chứng về sự chuyển đổi trạng thái không hợp lệ, đó là cực kỳ hiếm và do đó sẽ không dẫn đến việc gửi thư rác vào các khối. Vấn đề cuối cùng cần được giải quyết là các nhà sản xuất khối có thể chọn không tham gia vào việc tổng hợp tin nhắn hoặc cố tình kiểm duyệt validators cụ thể. Chúng tôi làm cho nó trở nên bất lợi về mặt kinh tế bằng cách tạo ra khối phần thưởng của nhà sản xuất tỷ lệ thuận với số validator được chỉ định cho họ. Chúng tôi cũng lưu ý rằng vì các nhà sản xuất khối giữa các kỷ nguyên phần lớn giao nhau (vì luôn là những người tham gia có số tiền đặt cược cao nhất), validator có thể phần lớn tập trung vào làm việc với cùng một nhà sản xuất khối và do đó giảm thiểu rủi ro về việc được giao cho một nhà sản xuất khối đã kiểm duyệt chúng trong quá khứ. 3,9 Chuỗi ảnh chụp nhanh Vì các khối trên chuỗi chính được sản xuất rất thường xuyên nên việc tải xuống toàn bộ lịch sử có thể trở nên đắt đỏ rất nhanh. Hơn nữa, vì mỗi khối chứa chữ ký BLS của một số lượng lớn người tham gia, chỉ cần tổng hợp các khóa công khai để kiểm tra chữ ký có thể trở nên quá khó khăn. đắt tiền là tốt. Cuối cùng, vì trong bất kỳ tương lai gần nào Ethereum 1.0 có thể sẽ vẫn là một trong số blockchain được sử dụng nhiều nhất, có một cách hiệu quả để chuyển nội dung từ
Gần Ethereum là một yêu cầu và hôm nay việc xác minh chữ ký BLS để đảm bảo Không thể có hiệu lực ở các khối gần về phía Ethereum. Mỗi khối trong chuỗi chính Nightshade có thể tùy ý chứa Schnorr đa chữ ký trên tiêu đề của khối cuối cùng bao gồm Schnorr đa chữ ký. Chúng tôi gọi những khối như vậy là khối chụp nhanh. Khối đầu tiên của mỗi kỷ nguyên phải là một khối ảnh chụp nhanh. Trong khi làm việc trên một hệ thống đa chữ ký như vậy, nhà sản xuất khối cũng phải tích lũy chữ ký BLS của validators trên khối ảnh chụp nhanh cuối cùng và tổng hợp chúng theo cách tương tự như được mô tả trong phần 3.8. Vì bộ sản xuất khối không đổi trong suốt kỷ nguyên, nên việc xác thực chỉ các khối ảnh chụp nhanh đầu tiên trong mỗi kỷ nguyên là đủ với giả định rằng không có chỉ ra một tỷ lệ lớn các nhà sản xuất khối và validator đã thông đồng và tạo ra một cái nĩa. Khối đầu tiên của kỷ nguyên phải chứa thông tin đủ để tính toán nhà sản xuất khối và validator cho kỷ nguyên. Chúng tôi gọi chuỗi con của chuỗi chính chỉ chứa ảnh chụp nhanh chặn một chuỗi ảnh chụp nhanh. Tạo đa chữ ký Schnorr là một quá trình tương tác, nhưng vì chúng ta chỉ cần thực hiện nó không thường xuyên, bất kỳ quy trình nào, dù kém hiệu quả đến đâu sẽ đủ. Có thể dễ dàng xác thực đa chữ ký Schnorr trên Ethereum, do đó cung cấp các nguyên hàm quan trọng để thực hiện một cách an toàn chéo-blockchain giao tiếp. Để đồng bộ với chuỗi Gần, người ta chỉ cần tải xuống tất cả ảnh chụp nhanh chặn và xác nhận rằng chữ ký Schnorr là chính xác (tùy chọn cũng xác minh chữ ký BLS riêng lẻ của validators), sau đó chỉ đồng bộ hóa khối chuỗi chính từ khối ảnh chụp nhanh cuối cùng.
خاتمة
ناقشنا في هذه الوثيقة أساليب بناء blockchains و غطت تحديين رئيسيين مع النهج الحالي، وهما صلاحية الدولة وتوافر البيانات. ثم قدمنا Nightshade، وهو تصميم مقسم صلاحيات NEAR البروتوكول. التصميم قيد التنفيذ، إذا كان لديك تعليقات أو أسئلة أو ملاحظات في هذا المستند، يرجى الانتقال إلى https://near.chat.
Phần kết luận
Trong tài liệu này, chúng tôi đã thảo luận các phương pháp tiếp cận để xây dựng blockchain phân đoạn và đã giải quyết được hai thách thức lớn với các phương pháp tiếp cận hiện có, đó là tính hợp lệ của trạng thái và tính sẵn có của dữ liệu. Sau đó chúng tôi đã giới thiệu Nightshade, một thiết kế sharding quyền hạn NEAR Giao thức. Thiết kế đang được tiến hành, nếu bạn có ý kiến, câu hỏi hoặc phản hồi trên tài liệu này, vui lòng truy cập https://near.chat.