صحة الدولة وتوافر البيانات
الفكرة الأساسية في 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 على هذا النحو الطريقة التي يكون بها النظام آمنًا حتى لو أصبحت بعض الكتل القديمة في بعض القطع غير متوفر تماما.
Durum Geçerliliği ve Veri Kullanılabilirliği
Parçalanmış blockchain'lerdeki temel fikir, çoğu katılımcının işletim veya ağı kullanmak tüm parçalardaki blokları doğrulayamaz. Bu nedenle, ne zaman olursa olsun herhangi bir katılımcının genellikle yapamadığı belirli bir parçayla etkileşime girmesi gerekir Parçanın tüm geçmişini indirin ve doğrulayın. Bununla birlikte, parçalamanın bölümleme yönü önemli bir potansiyel ortaya çıkarmaktadır. sorun: belirli bir uygulamanın tüm geçmişini indirmeden ve doğrulamadan katılımcının parçanın bulunduğu durumdan mutlaka emin olması mümkün değildir. 5Bu bölüm, alt bölüm 2.5.3 hariç, daha önce https://near.ai/ adresinde yayınlanmıştır. parça2. Daha önce okuduysanız bir sonraki bölüme geçin.
etkileşime girmeleri bazı geçerli blok dizilerinin sonucudur ve bu dizi Blok sayısı gerçekten de parçadaki kanonik zincirdir. Çözülmeyen bir sorun parçalanmamış bir blockchain içinde mevcut. Öncelikle bu soruna önerilen basit bir çözüm sunacağız. birçok protokole göre analiz edin ve ardından bu çözümün nasıl bozulabileceğini ve ne olacağını analiz edin. giderilmesine yönelik girişimlerde bulunuldu. 2.1 Doğrulayıcıların rotasyonu Durum geçerliliğine yönelik saf çözüm şekil 5'te gösterilmektedir: diyelim ki tüm sistemde binlerce validators var, bunlardan %20'den fazlası kötü niyetli değildir veya başka şekilde başarısız olacaktır (örneğin, Bir blok oluşturmak için çevrimiçi). O zaman 200 validators örnek alırsak olasılık 1'den fazla 3 pratik amaçlar açısından başarısızlığın sıfır olduğu varsayılabilir. Şekil 5: Örnekleme validators 1 3 önemli bir eşik. Bir mutabakat protokolü ailesi var. BFT fikir birliği protokolleri; bu, 1'den az olduğu sürece bunu garanti eder 3'ü Katılımcılar ya kaza yaparak ya da kuralları ihlal eden bir şekilde hareket ederek başarısız olurlar. Protokolde fikir birliğine varılacak. Bu dürüst validator yüzdelik varsayımla, eğer mevcut Saf çözüm, bir parçadaki validators'nin bize bir miktar blok sağladığını varsayar bloğun geçerli olduğunu ve validators olduğuna inanılanlar üzerine inşa edildiğini doğrulamaya başladıklarında söz konusu parçanın standart zinciri. validator'lar kanonik zinciri önceki validators kümesinden öğrendi; Kanonik zincirin başı olan bloğun üzerine inşa edilen varsayım ondan önce. Tümevarımla zincirin tamamı geçerlidir ve validators kümesi olmadığından Çatal üretilen herhangi bir noktada, naif çözüm aynı zamanda mevcut olanın da kesin olduğudur. zincir, parçadaki tek zincirdir. Görselleştirme için şekil 6'ya bakın.
Şekil 6: Her bloğun BFT fikir birliğiyle sonlandırıldığı bir blockchain validators'nin olabileceğini varsayarsak bu basit çözüm işe yaramaz. uyumsal olarak bozulmuştur ki bu mantıksız bir varsayım değildir6. Uyarlanabilir 1000 parçadan oluşan bir sistemde tek bir parçayı bozmak çok daha ucuzdur tüm sistemi bozmak yerine. Bu nedenle protokolün güvenliği, parça sayısı arttıkça doğrusal olarak azalır. Geçerliliğinden emin olmak için bir blok, tarihin herhangi bir noktasında sistemdeki hiçbir parçanın olmadığını bilmeliyiz. validator'ların çoğunluğu gizli anlaşma yapıyor; uyarlanabilir düşmanlarla artık elimizde değil öyle bir kesinlik ki. Bölüm 1.5'te tartıştığımız gibi, validators ile gizli anlaşma yapmak işe yarayabilir iki temel kötü niyetli davranış: çatallar oluşturmak ve geçersiz bloklar üretmek. Kötü niyetli çatallanmalar, blokların genel olarak diğerlerine göre önemli ölçüde daha yüksek güvenliğe sahip olacak şekilde tasarlanan Beacon zincirine çapraz bağlanmasıyla ele alınabilir. kırık zincirler. Geçersiz bloklar üretmek ise önemli ölçüde daha fazla bir sorundur. üstesinden gelinmesi zor bir sorun. 2.2 Durum Geçerliliği 1. Parçanın bozulduğu ve kötü niyetli bir aktörün ürettiği Şekil 7'yi düşünün. geçersiz blok B. Diyelim ki bu B bloğunda 1000 tokens yoktan basıldı Alice'in hesabında yayın. Kötü niyetli aktör daha sonra geçerli C bloğunu üretir (bir C'deki işlemlerin doğru bir şekilde uygulandığını hissetmek) B'nin yanı sıra kafa karıştırıcı geçersiz B bloğunu kullanır ve Parça #2'ye bir çapraz parça işlemi başlatır. bu 1000 tokens'yi Bob'un hesabına aktarır. Bu andan itibaren uygunsuz bir şekilde oluşturulan token'ler, Parça #2'deki tamamen geçerli bir blockchain üzerinde bulunuyor. Bu sorunu çözmeye yönelik bazı basit yaklaşımlar şunlardır: 6Oku bu makale için ayrıntılar üzerinde nasıl uyarlanabilir yolsuzluk yapabilir olmak taşınan dışarı: https://medium.com/nearprotocol/d859adb464c8. için daha fazla ayrıntılar üzerinde uyarlanabilir yolsuzluk, okumak https://github.com/ethereum/wiki/wiki/Sharding-FAQ# altında-çalıştığımız-güvenlik modelleri nelerdirŞekil 7: Geçersiz bloğu olan bir zincirden gelen parçalar arası işlem 1. İşlemin yapıldığı bloğu doğrulamak amacıyla validators Parça #2 için başlatılır. Bu yukarıdaki örnekte bile işe yaramayacaktır çünkü C bloğu tamamen geçerli olduğu görülmektedir. 2. İşlemin başlatıldığı bloktan önceki çok sayıda bloğu doğrulamak için Parça #2'deki validators için. Doğal olarak, kötü niyetli alıcı parça tarafından doğrulanan herhangi bir sayıda blok N validators, geçersiz bloğun üstünde N+1 geçerli blok oluşturabilir üretildi. Bu sorunu çözmek için umut verici bir fikir, parçaları bir düzende düzenlemek olacaktır. her bir parçanın diğer birkaç parçaya bağlandığı yönlendirilmemiş grafik ve yalnızca komşu parçalar arasında çapraz parça işlemlerine izin ver (ör. Vlad Zamfir'in parçalaması esasen işe yarıyor7 ve benzer fikir Kadena'nınkinde de kullanılıyor Chainweb [1]). Parçalar arasında parçalar arası bir işlem gerekiyorsa komşular değil, bu tür işlemler birden fazla parça aracılığıyla yönlendirilir. Bu tasarımda Her bir parçadaki bir validator'nin, kendi parçalarındaki tüm blokları doğrulaması bekleniyor ve ayrıca tüm komşu parçalardaki tüm bloklar. Aşağıdaki şekli düşünün 10 parçadan oluşan, her birinin dört komşusu olan ve daha fazlasını gerektiren iki parçanın olmadığı Şekil 8'de gösterilen çapraz parça iletişimi için ikiden fazla atlama. Parça #2 yalnızca kendi blockchain parçasını değil aynı zamanda blockchain parçasını da doğruluyor 1 numaralı Parça dahil tüm komşular. Yani Parça #1'de kötü niyetli bir aktör varsa geçersiz bir B bloğu oluşturmaya çalışıyor, ardından bunun üzerine C bloğunu inşa ediyor ve parçalar arası bir işlem başlatın, bu tür parçalar arası işlem gerçekleşmeyecek Parça #2'den beri Parça #1'in tüm geçmişi doğrulanmış olacak. geçersiz B bloğunu tanımlamasına neden olacaktır. 7Tasarım hakkında daha fazla bilgiyi burada bulabilirsiniz: https://medium.com/nearprotocol/37e538177ed9
Şekil 8: Chainweb benzeri sistemde geçersiz bir çapraz parça işlemi tespit edilmek Tek bir parçayı bozmak artık geçerli bir saldırı olmasa da, bir parçayı bozmak artık geçerli bir saldırı değildir. birkaç parça sorun olmaya devam ediyor. Şekil 9'da bir düşman her iki Shard'ı da bozuyor
1 ve Parça #2, Parça #3'e yönelik bir çapraz parça işlemini başarıyla yürütür
geçersiz bir B bloğundan gelen fonlarla: Şekil 9: Chainweb benzeri sistemde geçersiz bir çapraz parça işlemi tespit edilmemek Parça #3, Parça #2'deki tüm blokları doğrular ancak Parça #1'deki tüm blokları doğrular ve kötü amaçlı bloğu tespit etmenin bir yolu yoktur. Durum geçerliliğini doğru şekilde çözmenin iki ana yönü vardır: balıkçılar
ve hesaplamanın kriptografik kanıtları. 2.3 Balıkçı İlk yaklaşımın arkasındaki fikir şudur: ne zaman bir blok başlığı Herhangi bir amaç için zincirler arasında iletilir (örneğin çapraz bağlanma gibi). işaret zinciri veya parçalar arası bir işlem), bu sırada belirli bir süre vardır dürüst herhangi bir validator bloğun geçersiz olduğuna dair kanıt sağlayabilir. Orada blokların çok kısa ve öz kanıtlarını sağlayan çeşitli yapılardır. geçersiz olduğundan alıcı düğümlerin iletişim yükü çok daha küçüktür tam bir blok almaktan daha fazla. En az bir dürüst validator olduğu sürece bu yaklaşımla Shard, sistem güvenlidir. Şekil 10: Balıkçı Bu, bugün önerilen protokoller arasında (sorun yokmuş gibi davranmanın yanı sıra) baskın yaklaşımdır. Ancak bu yaklaşımın iki önemli dezavantajlar: 1. Dürüst validator için meydan okuma süresinin yeterince uzun olması gerekir Bir bloğun üretildiğini tanımak, onu indirmek, tamamen doğrulamak ve hazırlamak blok geçersizse meydan okuma. Böyle bir dönemin getirilmesi Parçalar arası işlemleri önemli ölçüde yavaşlatır. 2. Challenge protokolünün varlığı yeni bir saldırı vektörü yaratıyor Kötü niyetli düğümler geçersiz sorgulamalarla spam yaptığında. Açık bir çözüm Bu sorunun çözümü, meydan okuyanların bir miktar tokens yatırmasını sağlamaktır. meydan okuma geçerliyse iade edilir. Bu yalnızca kısmi bir çözümdür, çünkü saldırganın sisteme spam göndermesi (ve yakması) yine de faydalı olabilir. örneğin geçerli işlemleri engellemek için geçersiz sorgulamalarla yapılan para yatırma işlemleri)dürüst bir validator'dan gelen meydan okuma. Bu saldırılar Kederli Saldırılar denir. İkinci noktayı aşmanın bir yolu için bölüm 3.7.2'ye bakın. 2.4 Kısa ve Etkileşimli Olmayan Bilgi Argümanları Çoklu parça bozulmasına karşı ikinci çözüm, belirli bir hesaplamanın (örneğin, bir dizi işlemden bir bloğun hesaplanması gibi) doğru bir şekilde gerçekleştirildi. Bu tür yapılar mevcuttur; zk-SNARK'lar, zk-STARK'lar ve birkaç kişi daha, ve bazıları bugün blockchain protokollerinde özel ödemeler için aktif olarak kullanılıyor, en önemlisi ZCash. Bu tür ilkellerle ilgili temel sorun, onların hesaplamanın oldukça yavaş olduğu biliniyor. Örn. zk-SNARK'ları kullanan Coda Protokolü özellikle blockchain içindeki tüm blokların geçerli olduğunu kanıtlamak için, birinde söylendi Kanıt oluşturmanın işlem başına 30 saniye sürebileceği görüşmelerden (bu sayı muhtemelen şimdiye kadar daha küçüktür). İlginç bir şekilde, bir kanıtın güvenilir bir tarafça hesaplanmasına gerek yoktur, çünkü Kanıt yalnızca oluşturulduğu hesaplamanın geçerliliğini kanıtlamakla kalmaz, aynı zamanda kanıtın kendisinin geçerliliği. Dolayısıyla bu tür kanıtların hesaplanması bölünebilir önemli ölçüde daha az yedekliliğe sahip bir grup katılımcı arasında bazı güvenilir hesaplamalar yapmak için gereklidir. Aynı zamanda katılımcıların zk-SNARK'ları özel donanım üzerinde çalışacak şekilde hesaplayanlar sistemin ademi merkeziyetçiliği. zk-SNARK'ların performansın yanı sıra karşılaştığı zorluklar şunlardır: 1. Daha az araştırılmış ve daha az zaman içinde test edilmiş kriptografik temellere bağımlılık; 2. “Zehirli atık” — zk-SNARK'lar, bir grubun içinde bulunduğu güvenilir bir kuruluma bağlıdır İnsanların oranı bir miktar hesaplama yapıyor ve ardından ara hesaplamayı atıyor bu hesaplamanın değerleri. Prosedürün tüm katılımcıları gizli anlaşma yaparsa ve ara değerleri koruyarak sahte deliller oluşturulabilir; 3. Sistem tasarımına eklenen ekstra karmaşıklık; 4. zk-SNARK'lar yalnızca olası hesaplamaların bir alt kümesi için çalışır, dolayısıyla bir protokol Turing-complete smart contract dilini kullanamazsınız Zincirin geçerliliğini kanıtlamak için SNARK'lar. 2.5 Veri Kullanılabilirliği Değineceğimiz ikinci sorun veri kullanılabilirliğidir. Genellikle düğümler belirli bir blockchain çalıştıran iki gruba ayrılır: Tam Düğümler, her tam bloğu indiren ve her işlemi doğrulayanlar ve Light Yalnızca blok başlıklarını indiren ve parçalar için Merkle kanıtlarını kullanan düğümler Şekil 11'de gösterildiği gibi ilgilendikleri durum ve işlemler.
Şekil 11: Merkle Ağacı Artık tam düğümlerin çoğunluğu gizli anlaşma yaparsa geçerli veya geçerli bir blok üretebilirler. geçersizdir ve hash dosyasını hafif düğümlere gönderin, ancak içeriğin tamamını hiçbir zaman açıklamayın bloğun. Bundan faydalanabilecekleri çeşitli yollar vardır. Örneğin, Şekil 12'yi düşünün: Şekil 12: Veri Kullanılabilirliği sorunu Üç blok vardır: önceki A, dürüst validators tarafından üretilmiştir; mevcut B'nin validators gizli anlaşması var; ve bir sonraki C de üretilecek dürüst validators tarafından (blockchain sağ alt köşede gösterilmektedir). Sen bir tüccarsın. Geçerli bloğun (B) validator'leri alınan blok Önceki validator'lerden A, içinde para aldığınız bir blok hesapladı,ve size o bloğun başlığını, içinde bulunulan durumun Merkle kanıtıyla birlikte gönderdim. paranız var (veya parayı gönderen geçerli bir işlemin Merkle kanıtı) sana). İşlemin tamamlandığından emin olduğunuzda hizmeti sağlarsınız. Ancak validator'ler hiçbir zaman B bloğunun tam içeriğini dağıtmaz. herhangi biri. Bu nedenle, C bloğunun dürüst validator'leri bloğu geri alamaz ve ya sistemi durdurmaya zorlanırlar ya da A'nın üzerine inşa ederek sizi bir sistem olarak mahrum bırakırlar. para tüccarı. Aynı senaryoyu parçalamaya uyguladığımızda tam ve hafif düğüm genellikle parça başına uygulanır: her parça indirmesinde validators o parçada bloke edin ve o parçadaki her işlemi doğrulayın, ancak diğer parça zincirlerinin anlık görüntüsünü alan düğümler de dahil olmak üzere sistemdeki düğümler işaret zinciri, yalnızca başlıkları indirin. Böylece parçadaki validator'ler sistemdeki diğer katılımcılar bu parça için etkili bir şekilde tam düğümler oluştururken, işaret zinciri de dahil olmak üzere ışık düğümleri olarak çalışır. Yukarıda tartıştığımız balıkçı yaklaşımının işe yaraması için dürüst validators işaret zincirine çapraz bağlı blokları indirebilmeniz gerekir. Kötü niyetli validator'ler geçersiz bir bloğun başlığını çapraz bağladıysa (veya bunu kullandıysa) parçalar arası bir işlem başlatır), ancak bloğu asla dağıtmaz, dürüst validator'lerin bir meydan okuma oluşturmanın hiçbir yolu yok. Bu sorunu çözmek için birbirini tamamlayan üç yaklaşımı ele alacağız. Birbirimiz. 2.5.1 Velayet Kanıtları Çözülmesi gereken en acil sorun, bir bloğun bir kez kullanılabilir olup olmadığıdır. yayınlandı. Önerilen fikirlerden biri dönüşümlü Noterlere sahip olmaktır. tek işi bir dosya indirmek olan validator'lerden daha sık parçalar arasında engelleyin ve indirebildiklerini doğrulayın. Onlar olabilir tüm durumu indirmeleri gerekmediği için daha sık dönüşümlü olarak kullanılıyor parçanın aksine, sık sık döndürülemeyen validator'lerin aksine şekilde gösterildiği gibi her döndüklerinde parçanın durumunu indirmeleri gerekir 13. Bu naif yaklaşımın sorunu daha sonra kanıtlamanın imkansız olmasıdır. Noterin bloğu indirip indiremediğine bağlı olarak Noter bloğu indirebildiklerini her zaman onaylamayı seçebilirler. hatta onu geri almaya çalışıyorum. Bunun bir çözümü Noterlerin sağlamasıdır. bloğun olduğunu kanıtlayan bazı kanıtlar veya bir miktar tokens stake etmek indirildi. Böyle bir çözüm burada tartışılmaktadır: https://ethresear.ch/t/ 1 bitlik toplama dostu saklama tahvilleri/2236. 2.5.2 Silme Kodları Belirli bir ışık düğümü bir bloğun hash değerini aldığında, düğümün Bloğun mevcut olduğundan emin olmak için rastgele birkaç tane indirmeyi deneyebilir bloğun parçaları. Bu tam bir çözüm değil çünkü ışık düğümleri Kötü niyetli blok üreticilerinin seçebileceği bloğun tamamını toplu olarak indirin
Şekil 13: Doğrulayıcıların durumu indirmesi gerekir ve bu nedenle döndürülemez sık sık bloğun herhangi bir ışık düğümü tarafından indirilmeyen kısımlarını alıkoymak, böylece bloğu hala kullanılamaz hale getiriyoruz. Çözümlerden biri, bunu mümkün kılmak için Silme Kodları adı verilen bir yapıyı kullanmaktır. gösterildiği gibi bloğun yalnızca bir kısmı mevcut olsa bile tüm bloğu kurtarmak için Şekil 14'te. Şekil 14: Merkle tree silme kodlu veriler üzerine inşa edilmiştir Hem Polkadot hem de Ethereum Serenity'nin tasarımları bu fikir etrafında şekilleniyor: Hafif düğümlerin blokların mevcut olduğundan makul ölçüde emin olmaları için bir yol sağlar. Ethereum Serenity yaklaşımının ayrıntılı açıklaması [2]'da bulunmaktadır.2.5.3 Polkadot'nin veri kullanılabilirliğine yaklaşımı Polkadot'de, çoğu parçalı çözümde olduğu gibi, her parça (parachain olarak adlandırılır) bloklarının anlık görüntüsünü işaret zincirine (aktarma zinciri olarak adlandırılır) alır. Diyelim ki 2f + 1 var Aktarma zincirinde validators. Parachain bloklarının blok üreticileri, harmanlayıcılar, parachain bloğu üretildiğinde, herhangi bir f parçası yeterli olacak şekilde 2f +1 parçadan oluşan bloğun silme kodlu versiyonunu hesaplarlar. bloğu yeniden inşa etmek için. Daha sonra her validator'e bir parça dağıtırlar. röle zinciri. Belirli bir geçiş zinciri validator yalnızca bir geçiş zincirinde imza atar anlık görüntüsü alınan her parachain bloğu için kendi paylarına sahiplerse bloklayın böyle bir röle zinciri bloğu. Dolayısıyla, eğer bir aktarma zinciri bloğu 2f + 1'den imzalara sahipse validators ve bunlardan en fazla f tanesi protokolü ihlal etmediği sürece, her biri parachain bloğu validators'den parçalar alınarak yeniden oluşturulabilir protokolü takip edenler. Bkz. şekil 15. Şekil 15: Polkadot'nin veri kullanılabilirliği 2.5.4 Uzun vadeli veri kullanılabilirliği Yukarıda tartışılan tüm yaklaşımların yalnızca bir bloğun olduğu gerçeğini doğruladığını unutmayın. yayınlandı ve şu anda mevcut. Bloklar daha sonra kullanılamayabilir çeşitli nedenlerden dolayı: düğümlerin devre dışı kalması, düğümlerin kasıtlı olarak geçmişi silmesi veriler ve diğerleri. Bu sorunu ele alan bahsetmeye değer bir teknik inceleme Polyshard [3]'dir, birden fazla parça olsa bile blokların parçalar arasında kullanılabilir olmasını sağlamak için silme kodlarını kullanan Parçalar verilerini tamamen kaybeder. Ne yazık ki onların özel yaklaşımı şunu gerektirir: diğer tüm parçalardan blok indirmek için tüm parçalar, bu da yasaklayıcı bir şekilde pahalı. Uzun vadeli kullanılabilirlik o kadar acil bir sorun değil: hiçbir katılımcı olmadığı için Sistemin tüm zincirlerdeki tüm zincirleri doğrulayabilmesi bekleniyor.
Parçalanmış protokollerin güvenliğinin böyle bir şekilde tasarlanması gerekir. bazı parçalardaki bazı eski bloklar bozulsa bile sistemin güvenli kalmasının bir yolu tamamen kullanılamaz.
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 Parça zincirlerinden parça parçalara Parça zincirleri ve işaret zinciri içeren parçalama modeli çok güçlüdür ancak belirli karmaşıklıklara sahiptir. Özellikle çatal seçim kuralının uygulanması gerekiyor her zincirde ayrı ayrı, parça zincirlerinde ve işaretçide çatal seçim kuralı Zincir farklı şekilde oluşturulmalı ve ayrı olarak test edilmelidir. Nightshade'de sistemi tek bir blockchain olarak modelliyoruz; her biri blok mantıksal olarak tüm parçalar için tüm işlemleri içerir ve tüm parçaların tüm durumu. Ancak fiziksel olarak hiçbir katılımcı dosyayı indirmez. tam durum veya tam mantıksal blok. Bunun yerine, ağın her katılımcısı yalnızca İşlemleri doğruladıkları parçalara karşılık gelen durumu korur ve bloktaki tüm işlemlerin listesi fiziksel olarak bölünmüştür parçalar, parça başına bir parça. İdeal koşullar altında her blok, parça başına tam olarak bir parça içerir. kabaca parça zincirli modele karşılık gelen blok parça zincirleri işaret zinciriyle aynı hızda bloklar üretir. Ancak, ağ gecikmeleri nedeniyle bazı parçalar eksik olabilir; bu nedenle pratikte her blok parça başına bir veya sıfır parça içerir. Nasıl yapılacağına ilişkin ayrıntılar için bölüm 3.3'e bakın. bloklar üretilir. Şekil 16: Solda parça zincirleri ve tek zinciri olan bir model bloklar sağ tarafta parçalara bölünmüş
3.2 Konsensüs Bugün blockchain'lerde fikir birliğine yönelik iki baskın yaklaşım şunlardır: En fazla işe veya hisseye sahip olan zincirin en uzun (veya en ağır) zincir oluşturmak için kullanılan kurallı kabul edilir ve BFT, burada her blok için bazı validator kümesi BFT fikir birliğine ulaştı. Son zamanlarda önerilen protokollerde ikincisi daha baskın bir yaklaşımdır, anında kesinlik sağladığından, en uzun zincirde daha fazla bloğa ihtiyaç duyulurken Kesinliği sağlamak için bloğun üzerine inşa edilecek. Çoğu zaman anlamlı Yeterli sayıda bloğun inşa edilmesi için gereken süre güvenlik gerektirir. saat sırası. Her blokta BFT fikir birliğini kullanmanın aşağıdaki gibi dezavantajları da vardır: 1. BFT fikir birliği önemli miktarda iletişim gerektirir. iken Son gelişmeler sayıca doğrusal zamanda fikir birliğine varılmasına olanak tanıyor katılımcıların sayısı (bkz. örneğin [4]), blok başına hala fark edilebilir bir yüktür; 2. Tüm ağ katılımcılarının BFT'ya katılması mümkün değildir. Blok başına fikir birliğine varılır, dolayısıyla genellikle yalnızca rastgele örneklenmiş bir katılımcı alt kümesi fikir birliğine varır. Rastgele örneklenmiş bir küme prensip olarak şu şekilde olabilir: uyarlanabilir bir şekilde bozulur ve teoride bir çatal oluşturulabilir. sistem her ikisinin de böyle bir olaya hazır olmak için modellenmesi gerekiyor ve bu nedenle hala BFT fikir birliğinin yanı sıra bir çatal seçeneği kuralına sahip olmak veya kapanacak şekilde tasarlanmış olmak böyle bir olayda aşağı. Bazı tasarımların olduğunu belirtmekte fayda var. Algorand [5], uyarlamalı yolsuzluk olasılığını önemli ölçüde azaltır. 3. En önemlisi şu durumlarda sistem durur: Tüm katılımcıların 3 veya daha fazlası çevrimdışı. Bu nedenle, herhangi bir geçici ağ arızası veya ağ bölünmesi, sistemi tamamen durdurabilir. İdeal olarak sistem devam edebilmelidir katılımcıların en az yarısı çevrimiçi olduğu sürece faaliyet göstermektedir (en yoğun Zincir tabanlı protokoller, katılımcıların yarısından azı çevrimiçi olsa bile çalışmaya devam eder, ancak bu özelliğin arzu edilirliği daha tartışmalıdır topluluk içinde). Kullanılan fikir birliğinin bir tür en ağır olduğu hibrit bir model zincir, ancak bazı bloklar BFT sonlandırma aracı kullanılarak periyodik olarak sonlandırılır ve her iki modelin de avantajları korunur. Bu tür BFT nihai gadget'lar Ethereum 2.0 8'de kullanılan Casper FFG [6], Casper CBC (bkz. https://vitalik.) ca/general/2018/12/05/cbc_casper.html) ve GRANDPA (bkz. https:// Medium.com/polkadot-network/d08a24a021b5) Polkadot'de kullanıldı. Nightshade en ağır zincir konsensüsünü kullanır. Özellikle bir blok Üretici bir blok ürettiğinde (bkz. Bölüm 3.3), imza toplayabilirler. diğer blok üreticileri ve önceki bloğu doğrulayan validator'lar. Bölüme bakın Bu kadar çok sayıda imzanın nasıl toplandığıyla ilgili ayrıntılar için 3.8'e bakınız. Ağırlık 8Ayrıca Casper'a derinlemesine bir genel bakış için Justin Drake ile yapılan beyaz tahta oturumuna bakın FFG ve GHOST en ağır zincir konsensüsüne nasıl entegre edildiği burada: https://www. youtube.com/watch?v=S262StTwkmobir bloğun payı, imzaları imzalanan tüm imzalayanların kümülatif hissesidir. bloğa dahil edilmiştir. Bir zincirin ağırlığı blok ağırlıklarının toplamıdır. En ağır zincir mutabakatının yanı sıra, aşağıdakileri kullanan bir nihai gadget kullanıyoruz: blokları sonlandırmak için onaylar. Sistemin karmaşıklığını azaltmak için, Çatal seçim kuralını hiçbir şekilde etkilemeyen bir sonlandırma aracı kullanıyoruz, ve bunun yerine yalnızca ekstra eğik çizgi koşulları getirir, öyle ki bir blok bir kez Nihai gadget tarafından sonlandırıldığında, çok büyük bir yüzde olmadıkça çatallanma imkansızdır. toplam bahis miktarı kesildi. Casper CBC son derece kaliteli bir cihazdır ve biz şu anda Casper CBC'yi göz önünde bulundurarak model oluşturuyorum. Ayrıca TxFlow adı verilen ayrı bir BFT protokolü üzerinde de çalışıyoruz. O sırada Bu belgeyi yazarken Casper yerine TxFlow'un kullanılıp kullanılmayacağı belli değil CBC. Ancak son cihaz seçiminin büyük ölçüde tasarımın geri kalanına dik olduğunu belirtmeliyiz. 3.3 Blok üretimi Nightshade'de iki rol vardır: blok yapımcıları ve validator'ler. herhangi bir zamanda sistemin w blok üreticilerini içerdiği nokta, modellerimizde w = 100 ve wv validators, modelimizde v = 100, wv = 10, 000. Sistem Proof-of-Stake'tir, bu, hem blok üreticilerinin hem de validator'lerin bir takım dahili bağlantılara sahip olduğu anlamına gelir para birimi ("tokens" olarak anılır) belirtilen süreyi aşan bir süre boyunca kilitlendi zinciri oluşturma ve doğrulama görevlerini yerine getirmek için harcadıkları zaman. Tüm Proof of Stake sistemlerinde olduğu gibi, tüm w blok üreticileri ve tüm wv validator'ler farklı varlıklardır, çünkü bu uygulanamaz. Her biri Bununla birlikte, w blok üreticilerinin ve wv validator'lerin ayrı bir hisse. Sistem n parça içeriyor, modelimizde n = 1000. Bahsedildiği gibi bölüm 3.1, Nightshade'de hiçbir parça zinciri yoktur, bunun yerine tüm blok üreticileri ve validator'ler tek bir blockchain inşa ediyor, biz bunu ana zincir. Ana zincirin durumu n parçaya bölünmüştür ve her blok yapımcı ve validator her an yerel olarak yalnızca bir alt kümesini indirdi bazı parçaların alt kümesine karşılık gelen ve yalnızca işlem ve Eyaletin bu kısımlarını etkileyen işlemleri doğrulamak. Bir blok üreticisi olmak için ağın bir katılımcısı bazı büyükleri kilitler tokens miktarı (bir hisse). Ağın bakımı dönemler halinde yapılır, burada bir dönem gün sırasına göre bir zaman dilimidir. Katılımcılar Belirli bir çağın başında en büyük riske sahip olan bloklar O dönemin yapımcıları. Her blok üreticisi yazılım parçalarına atanır (örneğin sw = 40, bu da sww/n = parça başına 4 blok üreticisi anlamına gelir). Blok yapımcı, atandığı parçanın çağdan önceki durumunu indirir başlar ve dönem boyunca söz konusu parçayı etkileyen işlemleri toplar, ve bunları devlete uygular. Ana zincirdeki her b bloğu ve her parça s için aşağıdakilerden biri vardır: blok üreticilerini b ile ilgili kısmı üretmekten sorumlu olanlara atadık parçaya. b'nin parçayla ilgili kısmına yığın denir ve şunları içerir: merkle'nin yanı sıra b'ye dahil edilecek parçaya ilişkin işlemlerin listesiortaya çıkan durumun kökü. b sonuçta yalnızca çok küçük bir başlık içerecektir parça, yani uygulanan tüm işlemlerin merkle kökü (bkz. bölüm Kesin ayrıntılar için 3.7.1) ve son durumun merkle kökü. Belgenin geri kalanında sıklıkla blok üreticisinden bahsediyoruz belirli bir parça için belirli bir zamanda bir parça üretmekten sorumlu olan bir parça üreticisi olarak. Parça üreticisi her zaman blok üreticilerinden biridir. Blok üreticileri ve parça üreticileri her bloğu ona göre döndürür. sabit bir programa göre. Blok üreticilerinin siparişi var ve tekrar tekrar üretim yapıyorlar. bu sırayla bloklar. Örn. 100 blok üreticisi varsa ilk blok üreticiler 1, 101, 201 vb. blokların üretiminden sorumludur, ikincisi ise 2, 102, 202 vb. üretmekten sorumludur. Parça üretimi, blok üretiminden farklı olarak bakım gerektirdiğinden durum ve her parça için yalnızca sww/n blok üreticileri durumu korur parça başına, buna uygun olarak yalnızca sww/n blok üreticileri, oluşturmak için dönüşümlü olarak çalışır. parçalar. Örn. dört blok üreticisinin atandığı yukarıdaki sabitlerle Her parça, her blok üreticisi her dört blokta bir parça oluşturacak. 3.4 Veri kullanılabilirliğinin sağlanması Veri kullanılabilirliğini sağlamak için Polkadot yaklaşımına benzer bir yaklaşım kullanıyoruz bölüm 2.5.3'te açıklanmıştır. Bir blok üreticisi bir parça ürettiğinde, optimal (w, ⌊w/6 + 1⌋) blok koduna sahip silme kodlu versiyonu yığın. Daha sonra silme kodlu parçanın bir parçasını gönderirler (bu tür parçalar diyoruz) her blok üreticisine parça parçaları veya sadece parçalar). Yapraklar gibi tüm parçaları içeren bir merkle ağacı hesaplıyoruz ve Her parçanın başlığı bu ağacın merkle kökünü içerir. Parçalar tek parça mesajları aracılığıyla validators'ye gönderilir. Bu tür mesajların her biri öbek başlığını, parçanın sırasını ve parça içeriğini içerir. mesaj aynı zamanda blok üreticisinin imzasını da içermektedir. parçanın başlığa karşılık geldiğini kanıtlamak için parça ve merkle yolu ve uygun blok üreticisi tarafından üretilmektedir. Bir blok üreticisi bir ana zincir bloğunu aldığında ilk olarak bu bloğun olup olmadığını kontrol eder. blokta yer alan her parça için tek parçalı mesajlar bulunur. Aksi takdirde blok eksik tek parçalı mesajlar alınana kadar işlenmez. Tüm tek parçalı mesajlar alındıktan sonra blok üreticisi, akranlarından kalan parçaları alır ve tuttukları parçaları yeniden yapılandırır devlet. Blok üreticisi en az bir ana zincir bloğunu işlemez. bloğa dahil edilen parçalarda karşılık gelen tek parçalı mesaj yoktur veya durumu korudukları en az bir parça için bunu yapamazlar tüm parçayı yeniden yapılandırın. Belirli bir parçanın mevcut olması için bloğun ⌊w/6⌋+1 olması yeterlidir Üreticiler kendi paylarına sahipler ve onlara hizmet ediyorlar. Böylece sayı kadar Kötü niyetli aktörler, yarım bloktan fazla bloğu olan hiçbir zincirin ⌊w/3⌋ değerini aşmaz bunu inşa eden üreticiler kullanılamayan parçalara sahip olabilir.Şekil 17: Her blok, parça başına bir veya sıfır parça içerir ve her parça silme kodludur. Silme kodlu yığının her bir parçası belirlenmiş bir yere gönderilir. özel bir tek bölümlü mesaj aracılığıyla yapımcıyı bloke etme 3.4.1 Tembel blok üreticileriyle uğraşmak Bir blok üreticisinin tek parçalı mesajın eksik olduğu bir bloğu varsa, yine de imzalamayı seçebilir, çünkü eğer blok zincire bağlanırsa blok üreticisinin ödülünü maksimuma çıkaracak. Blok için risk yok Daha sonra blok üreticisinin sahip olmadığını kanıtlamak imkansız olduğundan üretici tek parça mesajı. Bunu ele almak için, her bir parça üreticisini, parçayı oluştururken yapıyoruz. gelecekteki kodlanmış parçanın her bir parçası için bir renk (kırmızı veya mavi) seçin ve saklayın kodlanmadan önce yığındaki atanan rengin bit maskesi. Her bir parça mesaj parçaya atanan rengi içerir ve renk şu durumlarda kullanılır: kodlanmış parçaların merkle kökünün hesaplanması. Parça üreticisi saparsa protokole göre kolayca kanıtlanabilir, çünkü merkle kökü tek parça mesajlarına veya tek parça mesajlarındaki renklere karşılık gelir merkle köküne karşılık gelen, yığındaki maskeyle eşleşmeyecektir. Bir blok üreticisi bir bloğa imza attığında, tüm blokların bit maskesini ekler. bloğa dahil edilen parçalar için aldıkları kırmızı parçalar. Bir yayınlama yanlış bit maskesi kesilebilir bir davranıştır. Bir blok üreticisi bir sertifika almamışsa tek parçalı mesaj, mesajın rengini bilmelerinin hiçbir yolu yoktur ve dolayısıyla körü körüne imza atmaya kalkışmaları halinde %50 oranında kesintiye uğrama şansları vardır. Blok. 3.5 Durum geçiş başvurusu Parça üreticileri yalnızca parçaya hangi işlemlerin dahil edileceğini seçerler ancak bir yığın ürettiklerinde durum geçişini uygulamayın. Buna bağlı olarak,
yığın başlığı, daha önce olduğu gibi merkelize durumun merkle kökünü içerir yığındaki işlemler uygulanır. İşlemler yalnızca parçayı içeren tam bir blok olduğunda uygulanır işlenir. Bir katılımcı yalnızca şu durumlarda bir bloğu işler: 1. Önceki blok alındı ve işlendi; 2. Her parça için katılımcı sahip olduğu durumu korumaz tek parça mesajını gördüm; 3. Her parça için katılımcı, sahip oldukları durumu korur. tam yığın. Blok işlendikten sonra, katılımcının her bir parça için durumu korur, işlemleri uygular ve yeni durumu hesaplarlar işlemler uygulandıktan sonra üretime hazır hale gelirler herhangi bir parçaya atanmışlarsa bir sonraki bloğun parçaları yeni merkelleşmiş durumun merkle kökü. 3.6 Parçalar arası işlemler ve makbuzlar Bir işlemin birden fazla parçayı etkilemesi gerekiyorsa bunun ardışık olarak yapılması gerekir her parçada ayrı ayrı yürütülür. İşlemin tamamı ilk parçaya gönderilir etkilendiğinde ve işlem söz konusu parçanın öbeğine dahil edildiğinde ve öbek bir bloğa dahil edildikten sonra uygulanır, sözde bir makbuz üretir işlemin yapılması gereken bir sonraki parçaya yönlendirilen işlem idam edilecek. Daha fazla adımın gerekli olması halinde, alındı işleminin yürütülmesi yeni bir giriş hareketi oluşturur ve bu şekilde devam eder. 3.6.1 Makbuz işleminin ömrü Alış işleminin oluşturulduğu bloğun hemen ardından gelen blokta uygulanması arzu edilir. Makbuz işlemi yalnızca Önceki bloğun blok üreticileri tarafından alınıp uygulanmasından sonra oluşturulan kaynak parçayı koruyan ve o zamana kadar bilinmesi gereken Bir sonraki blok için parça, hedefin blok üreticileri tarafından üretilir kırık. Bu nedenle, makbuzun kaynak parçadan alıcıya iletilmesi gerekir. Bu iki olay arasındaki kısa zaman dilimindeki hedef parça. A, r girişini üreten bir t işlemini içeren son üretilen blok olsun. B bir sonraki üretilen blok olsun (yani A'yı içeren bir blok) r'yi içermek istediğimiz önceki bloğu). a ve r parçasında olsun kırıkta b. Şekil 18'de de gösterilen faturanın kullanım ömrü aşağıdaki gibidir: Makbuzların üretilmesi ve saklanması. Parça için parça üreticisi EBM'si a, A bloğunu alır, t işlemini uygular ve r makbuzunu oluşturur. EBM daha sonra üretilen tüm makbuzları dahili kalıcı depolama biriminde indekslenmiş olarak saklar kaynak parça kimliğine göre.Makbuzların dağıtılması. EBM, parçayı üretmeye hazır olduğunda B bloğu için a parçasını, a bloğu için A bloğundaki işlemlerin uygulanmasıyla oluşturulan tüm makbuzları getirir ve bunları parça için parçaya dahil ederler. B bloğunda a. Böyle bir yığın oluşturulduktan sonra, cpa onun silme kodunu üretir sürümü ve karşılık gelen tüm onepart mesajları. EBM, hangi blok üreticilerinin hangi parçalar için tam durumu koruduğunu bilir. Belirli bir blok üreticisi için bp cpa, A bloğundaki işlemlerin uygulanmasından kaynaklanan makbuzları içerir bp'nin hedef olarak önemsediği parçalardan herhangi birine sahip olan parça a için B bloğundaki a parçası için yığını dağıttıklarında tek parçalı mesajda (tek parçalı mesaja dahil edilen makbuzları gösteren şekil 17'ye bakın). Makbuzların alınması. Katılımcıların (hem blok üreticileri hem de validator'ler) tek parçalı mesajları alana kadar blokları işlemediklerini unutmayın. blokta yer alan her parça için. Böylece, herhangi bir katılımcı B bloğunu uyguladığında, B bloğuna karşılık gelen tüm tek parçalı mesajlara sahip olur. B'deki parçalar ve dolayısıyla parçaların bulunduğu tüm gelen makbuzlara sahipler katılımcı, varış yeri olarak durumunu korur. Uygularken belirli bir parça için durum geçişi, katılımcı hem makbuzları uygular tek parçalı mesajlarda parça için topladıklarının yanı sıra tüm yığının kendisinde yer alan işlemler. Şekil 18: Bir makbuz işleminin ömrü 3.6.2 Çok fazla makbuz işlemek Belirli bir parçayı hedefleyen faturaların sayısının belirli blok işlenemeyecek kadar büyük. Örneğin, şekil 19'u düşünün, her bir parçadaki her işlem, parça 1'i hedefleyen bir makbuz oluşturur. Bir sonraki blokta, parça 1'in işlemesi gereken faturaların sayısı şu şekilde olur: taşıma sırasında tüm parçaların bir araya getirdiği yükle karşılaştırılabilir önceki blok.
Şekil 19: Tüm faturalar aynı parçayı hedefliyorsa parçanın bunları işleme kapasitesi Bu sorunu çözmek için QuarkChain 9'da kullanılana benzer bir teknik kullanıyoruz. Spesifik olarak, her bir parça için son B bloğu ve onun içindeki son parça Fişlerin uygulandığı blok kaydedilir. Yeni parça ne zaman Oluşturulduğunda, fiş ilk önce B'de kalan parçalardan başlayarak uygulanır, ve sonra yeni yığın dolana kadar B'yi takip eden bloklar halinde. Normalin altında Dengeli bir yüke sahip koşullar altında, genellikle tüm tahsilatlar sonuçlanacaktır. uygulanıyor (ve böylece son bloğun son parçası kaydedilecek) her parça), ancak yükün dengeli olmadığı zamanlarda ve belirli bir Shard orantısız bir şekilde çok sayıda makbuz alıyor, bu teknik onların dahil edilen işlem sayısındaki sınırlara uyularak işlenecektir. Böyle dengesiz bir yükün uzun süre kalması durumunda gecikmenin Başvuruya kadar fiş oluşturma süresiz olarak büyümeye devam edebilir. Bir Bunu çözmenin yolu, bir hedefi hedefleyen bir makbuz oluşturan herhangi bir işlemi iptal etmektir. Belirli bir sabiti (ör. bir dönem) aşan bir işlem gecikmesine sahip olan parça. Şekil 20'yi düşünün. B bloğuna göre 4 numaralı parça tüm girişleri işleyemez, bu nedenle yalnızca A bloğundaki 3. parçaya kadar olan makbuzları işler ve onu kaydeder. C bloğunda B bloğundaki 5. parçaya kadar olan makbuzlar dahil edilir ve daha sonra D blokta parça yakalanır ve kalan tüm faturalar işlenir. B bloğu ve C bloğundaki tüm faturalar. 3.7 Parça doğrulama Belirli bir parça için üretilen bir parça (veya parça zincirli modelde belirli bir parça zinciri için üretilen bir parça bloğu) yalnızca şu şekilde doğrulanabilir: 9QuarkChain ile beyaz tahta bölümünü buradan izleyin: https://www.youtube.com/watch? v=opEtG6NM4x4, diğerlerinin yanı sıra parçalar arası işlemlere yaklaşımın tartışıldığı şeylerŞekil 20: Gecikmeli makbuz işleme Devleti koruyan katılımcılar. Blok üreticileri olabilirler, validators, veya yalnızca durumu indiren ve parçayı doğrulayan harici tanıklar varlıkları depoluyorlar. Bu belgede katılımcıların çoğunluğunun depolama yapamadığını varsayıyoruz. parçaların büyük bir kısmı için devlet. Ancak şunu belirtmekte yarar var varsayımıyla tasarlanmış parçalanmış blockchain'lerin bulunduğunu çoğu katılımcının durumunu saklama ve çoğu şeyi doğrulama kapasitesi vardır. QuarkChain gibi parçalar. Katılımcıların yalnızca bir kısmı parçayı doğrulama durumuna sahip olduğundan Parçalar halinde, yalnızca aşağıdaki özelliklere sahip olan katılımcıları uyarlanabilir şekilde yozlaştırmak mümkündür. durumu seçin ve geçersiz bir durum geçişi uygulayın. Her birkaç örnekte validators içeren birden fazla parçalama tasarımı önerildi gün ve bir gün içinde parça zincirinde 2/3'ten fazla olan herhangi bir blok söz konusu parçaya atanan validator'lerin imzalarının sayısı hemen dikkate alınır son. Böyle bir yaklaşımla, uyum sağlayabilen bir düşmanın yalnızca 2n/3+1'i yozlaştırması yeterlidir Geçersiz bir durum geçişi uygulamak için bir parça zincirindeki validator'lerin sayısı; Bunu başarmak muhtemelen zor olsa da, kamuya açık bir güvenlik düzeyi yeterli değil blockchain. Bölüm 2.3'te tartışıldığı gibi, ortak yaklaşım, durumu olan herhangi bir katılımcı için bir blok oluşturulduktan sonra belirli bir zaman aralığına izin vermektir (ister geçerliliğine meydan okuyan bir blok üreticisi, bir validator veya harici bir gözlemci). Bu tür katılımcılara Balıkçı denir. Bir balıkçının bunu yapabilmesi için Geçersiz bir bloğa itiraz edilmesi durumunda, böyle bir bloğun erişime açık olduğundan emin olunmalıdır. onlar. Nightshade'deki veri kullanılabilirliği bölüm 3.4'te tartışılmaktadır. Nightshade'de bir blok üretildiğinde parçalar gerçek parça üreticisi dışında herkes. Özellikle blok üreticisi bloğun doğal olarak çoğu parça için duruma sahip olmadığını öne sürdü veparçaları doğrulayamadı. Bir sonraki blok üretildiğinde, birden fazla blok üreticisinin ve validator'lerin onaylarını (bkz. bölüm 3.2) içerir, ancak blok üreticilerinin ve validator'lerin çoğunluğu durumu korumadığından çoğu kırık için de yalnızca bir geçersiz parçaya sahip bir blok, doğrulamaların yarısından önemli ölçüde fazlasını toplayacak ve en ağır blokta yer almaya devam edecek zincir. Bu sorunu çözmek için, durumunu koruyan herhangi bir katılımcıya izin veriyoruz. bu şekilde üretilen herhangi bir geçersiz parça için zincir üzerinde bir meydan okuma gönderecek bir parça kırık. 3.7.1 Devlet geçerliliği sorunu Bir katılımcı belirli bir parçanın geçersiz olduğunu tespit ettiğinde parçanın geçersiz olduğuna dair bir kanıt sunması gerekir. Ağ katılımcılarının çoğunluğu geçersiz parçanın bulunduğu parçanın durumunu korumadığından üretildiğinde, kanıtın bloğun doğrulandığını doğrulamak için yeterli bilgiye sahip olması gerekir. devlet olmadan geçersiz. Tek bir işlemin gerçekleştirebileceği durum miktarının (bayt cinsinden) Ls sınırını belirliyoruz. toplu olarak okuyabilir veya yazabilir. L'den daha fazlasına dokunan herhangi bir işlem durum geçersiz kabul edilir. Bölüm 3.5'ten hatırlayın ki yığın belirli bir B bloğunda yalnızca uygulanacak işlemleri içerir, ancak yeni durum kökü. B bloğundaki yığının içerdiği durum kökü durumdur root, bu tür işlemleri uygulamadan önce, ancak işlemleri uyguladıktan sonra B bloğundan önceki aynı parçadaki son parça. Kötü niyetli bir aktör geçersiz bir durum geçişi uygulamak istemeniz, yanlış bir durum kökü içerecektir uygulamadan kaynaklanan durum köküne karşılık gelmeyen B bloğunda önceki parçadaki işlemler. Bir parça üreticisinin parçaya dahil ettiği bilgiyi genişletiyoruz. Tüm işlemleri uyguladıktan sonra sadece durumu dahil etmek yerine, her bir bitişik işlem kümesi uygulandıktan sonra bir durum kökü içerir. toplu olarak Ls durum baytını okur ve yazar. Bu bilgilerle birlikte balıkçının devlet geçişinin yanlış uygulandığına dair bir zorluk yaratması Bu türden ilk geçersiz durum kökünü bulmak yeterlidir ve yalnızca Ls baytını içerir. son durum kökü arasındaki işlemlerden etkilenen durum (ki bu geçerli) ve merkle kanıtlarıyla birlikte mevcut durum kökü. Daha sonra herhangi bir katılımcı segmentteki işlemleri doğrulayabilir ve parçanın olduğunu doğrulayabilir geçersiz. Benzer şekilde, yığın üreticisi şunu okuyan işlemleri dahil etmeye çalışırsa: ve Ls bayttan daha fazla durum yazın, zorluk için dahil etmek yeterlidir Merkle kanıtlarıyla dokunduğu ilk Ls baytı, bu da yeterli olacaktır. işlemleri uygulayın ve bir girişimde bulunulacağı bir anın olduğunu onaylayın Ls bayt ötesinde içerik okuma veya yazma işlemi yapılır.
3.7.2 Balıkçılar ve hızlı çapraz parça işlemleri Bölüm 2.3'te tartışıldığı gibi, parça parçalarının (veya parçanın) modeldeki parça zincirli bloklar) geçersiz olabilir ve zorluk yaratabilir Bu durum nihailiği ve dolayısıyla parçalar arası iletişimi olumsuz etkiler. içinde özellikle herhangi bir çapraz parça işleminin hedef parçası kesin olamaz kaynak parça parçası veya blok, meydan okuma süresi bitene kadar nihaidir (bkz. şekil 21). Şekil 21: Makbuz uygulamadan önce sorgulama süresinin beklenmesi Bunu, parçalar arası işlemleri gerçekleştirecek şekilde ele almanın yolu hedef parçanın meydan okuma süresini beklememesi anlıktır kaynak parça işlemi yayınlandıktan sonra ve alındı işlemini uygulayın hemen, ancak daha sonra hedef parçayı kaynakla birlikte geri alın daha sonra kaynak parçanın veya bloğun geçersiz olduğu tespit edilirse parça (bkz. şekil 22). Bu, parçanın bulunduğu Nightshade tasarımı için çok doğal olarak geçerlidir. zincirler bağımsız değildir ancak bunun yerine parça parçalarının tümü yayınlanır birlikte aynı ana zincir bloğunda. Herhangi bir parçanın geçersiz olduğu tespit edilirse, bu parçaya sahip bloğun tamamı geçersiz kabul edilir ve üzerine inşa edilen tüm bloklar üstüne. Bkz. şekil 23. Yukarıdaki yaklaşımların her ikisi de, sorunun şu şekilde olduğu varsayılarak atomiklik sağlar: süre yeterince uzundur. Normal koşullar altında hızlı çapraz parça işlemlerinin sağlanması, hedef parça, aşağıdakilerden birinde geçersiz bir durum geçişi nedeniyle geri alınıyor son derece nadir bir olay olan kaynak parçaları. 3.7.3 validators gizleniyor Zorlukların varlığı, halihazırda bu olasılığı önemli ölçüde azaltıyor. uyarlanabilir yolsuzluk, çünkü bir yığını geçersiz bir durum geçiş gönderisiyle sonuçlandırmak içinŞekil 22: Makbuzların anında uygulanması ve varış noktasına geri alınması kaynak zincirinde geçersiz bir blok varsa zincir Şekil 23: Nightshade'de balıkçı mücadelesi Adaptif düşmanın tüm katılımcıları yozlaştırması gereken meydan okuma dönemi tüm validator'ler dahil olmak üzere parçanın durumunu koruyan. Böyle bir olayın olasılığını tahmin etmek son derece karmaşıktır, çünkü hiçbir Sharded blockchain bu tür bir saldırının denenmesine yetecek kadar uzun süredir yayında. Olasılığın son derece düşük olmasına rağmen hala yeterince yüksek olduğunu savunuyoruz. Milyonlarca işlemi yürütmesi beklenen bir sistem için büyük ve dünya çapında finansal operasyonlar yürütmek. Bu inancın iki temel nedeni vardır: 1. Proof-of-Stake zincirlerinin ve madencilerin validator'lerinin çoğu
İş Kanıtı zincirleri öncelikle finansal yükselişle teşvik ediliyor. Eğer Adaptif bir düşman onlara beklenen getiriden daha fazla para teklif eder dürüst bir şekilde faaliyet göstermekten dolayı, birçok validators'nin olmasını beklemek makul olacaktır. teklifi kabul edecek. 2. Birçok kuruluş Proof-of-Stake zincirlerinin doğrulamasını profesyonelce yapar ve Herhangi bir zincirdeki hisselerin büyük bir yüzdesinin bu tür kuruluşlardan. Bu tür varlıkların sayısı bir dönem için yeterince azdır. çoğunu kişisel olarak tanımak ve bozulmaya olan eğilimlerini iyi anlıyorlar. Hangi validator'lerin hangi parçaya atandığını gizleyerek uyarlamalı bozulma olasılığını azaltma konusunda bir adım daha ileri gidiyoruz. Fikir şu Algorand [5]'nin validators'yi gizlemesine uzaktan benzer. validator'ler, Algorand'da olduğu gibi gizlenmiş olsa bile, şunu unutmamak önemlidir: veya aşağıda açıklandığı gibi, uyarlanabilir bozulma teoride hala mümkündür. iken uyarlanabilir rakip, oluşturacak veya doğrulayacak katılımcıları tanımıyor Bir blok ya da yığın halinde, katılımcılar performans sergileyeceklerini kendileri biliyorlar. böyle bir görev ve bunun kriptografik bir kanıtı var. Böylece düşman yolsuzluk yapma niyetlerini yayınlayacak ve bunu sağlayacak herhangi bir katılımcıya ödeme yapacaktır. böyle bir kriptografik kanıt. Ancak şunu da belirtmeliyiz ki, rakip bunu yapmadığından bozmak istedikleri parçaya atanan validator'leri biliyorlarsa, belirli bir parçayı bozma niyetlerini yayınlamaktan başka seçeneği yok tüm topluluk. Bu noktada herhangi bir dürüst için ekonomik olarak faydalıdır. katılımcının bu parçayı doğrulayan tam bir düğümü döndürmesi için yüksek bir söz konusu parçada geçersiz bir bloğun görünme olasılığı; bir meydan okuma yaratın ve ilgili ödülü toplayın. Belirli bir parçaya atanan validator'leri açığa çıkarmamak için şunu yaparız: aşağıdakiler (bkz. şekil 24): Ödevi almak için VRF'yi kullanma. Her çağın başında her validator, validator'nin atandığı parçaların bit maskesini almak için bir VRF kullanır. Her validator'nin bit maskesi Sw bitlerine sahip olacaktır (tanım için bölüm 3.3'e bakın) Sw). validator daha sonra karşılık gelen parçaların durumunu getirir ve Alınan her blok için dönem boyunca karşılık gelen parçaları doğrular validator öğesinin atandığı parçalara. Parçalar yerine bloklar üzerinde oturum açın. Parça ataması gizlendiğinden validator parçalar üzerinde oturum açamaz. Bunun yerine her zaman bütünü imzalar böylece hangi parçaları doğruladığını açığa çıkarmıyor. Özellikle, validator bir blok alıp tüm parçaları doğruladığında ya bir mesaj oluşturur bu, validator öğesinin atandığı tüm parçalardaki tüm parçaların geçerli (bu parçaların ne olduğunu hiçbir şekilde belirtmeden) veya herhangi bir parçanın geçersiz olması durumunda geçersiz durum geçişinin kanıtını içerir. Bkz. Bu tür mesajların nasıl bir araya getirildiğine ilişkin ayrıntılar için bölüm 3.8, aşağıdakiler için bölüm 3.7.4: validators adlı kişinin gelen iletileri arka arkaya almasının nasıl önleneceğine ilişkin ayrıntılar nasıl ödüllendirileceği ve cezalandırılacağıyla ilgili ayrıntılar için diğer validators ve bölüm 3.7.5'e bakın validators başarılı bir geçersiz durum geçiş sorunu gerçekten meydana gelirse.Şekil 24: Nightshade'de validator'leri gizlemek 3.7.4 Taahhüt-Açıklama validators ile ilgili yaygın sorunlardan biri, validator'nin durumu indirmeyi ve aslında parçaları ve blokları doğrulamayı atlayabilmesi ve bunun yerine Ağı gözlemleyin, diğer validator'ların neler gönderdiğini görün ve yaptıklarını tekrarlayın. mesajlar. Böyle bir stratejiyi izleyen bir validator fazladan bir şey sağlamaz ağ için güvenlik sağlar, ancak ödüller toplar. Bu soruna yönelik yaygın bir çözüm, her validator için bir kanıt sağlamaktır örneğin benzersiz bir izleme sağlayarak bloğu gerçekten doğruladıklarını devlet geçişini uygulamak, ancak bu tür kanıtlar maliyeti önemli ölçüde artırıyor doğrulama. Şekil 25: Taahhüt-açıklama
Bunun yerine validators'nin doğrulama sonucuna ilişkin ilk taahhüdünü yaparız (veya parçaların geçerliliğini doğrulayan mesaj veya geçersiz olduğunun kanıtı durum geçişi), belirli bir süre bekleyin ve ancak bundan sonra şekil 25'te gösterildiği gibi gerçek doğrulama sonucunu ortaya çıkarın. ortaya çıkma dönemidir ve bu nedenle tembel bir validator dürüst validator'leri taklit edemez. Ayrıca, dürüst olmayan bir validator şunu doğrulayan bir mesaj gönderirse: atanan parçaların geçerliliği ve en az bir parçanın geçersiz olması durumunda öbeğin geçersiz olduğu gösterildiğinde validator eğik çizgiden kaçınamaz, çünkü, Bölüm 3.7.5'te gösterdiğimiz gibi böyle bir durumda kesilmemenin tek yolu geçersiz durum geçişinin kanıtını içeren bir mesaj sunmaktır. taahhütle eşleşir. 3.7.5 Zorluklarla baş etme Yukarıda tartışıldığı gibi, validator geçersiz parçaya sahip bir blok aldığında, önce geçersiz durum geçişinin kanıtını hazırlarlar (bkz. bölüm 3.7.1), ardından böyle bir kanıtı taahhüt edin (bkz. 3.7.4) ve bir süre sonra zorluğu ortaya çıkarın. Ortaya çıkan zorluk bir bloğa dahil edildiğinde aşağıdakiler gerçekleşir: 1. Bloktan gerçekleşen tüm durum geçişleri Ortaya çıkan zorluğun dahil edildiği bloğa kadar geçersiz parça hükümsüz kılındı. Ortaya çıkan mücadeleyi içeren bloktan önceki durum içeren bloktan önceki durumla aynı olduğu kabul edilir geçersiz yığın. 2. Belirli bir süre içinde her validator kendi bit maskesini göstermelidir doğruladıkları parçalar. Bit maskesi bir VRF aracılığıyla oluşturulduğundan, geçersiz durum geçişine sahip olan parçaya atandılar, ifşa etmekten kaçınamaz. Bit maskesini ortaya çıkaramayan herhangi bir validator parçaya atandığı varsayılmaktadır. 3. Bu süre sonunda parçaya atandığı tespit edilen her validator, içeren blok için bazı doğrulama sonuçları taahhüt etti geçersiz yığın ve bu geçersiz durum geçişinin kanıtını ortaya çıkarmadı bu onların taahhütlerine karşılık gelir. 4. Her validator yeni bir parça ataması alır ve yeni bir dönem planlanır tüm validator'ların indirmesi için yeterli bir süre sonra başlamak üzere Şekil 26'da gösterildiği gibi. validator'lerin kendilerine atanan parçaları ortaya çıkardığı andan itibaren unutmayın yeni dönem başlayana kadar sistemin güvenliği azaltılmıştır. Shard'ın ataması ortaya çıktı. Ağın katılımcılarının bunu saklaması gerekir Bu dönemde ağı kullanırken aklınızda bulundurun. 3.8 İmza Toplama Yüzlerce parçaya sahip bir sistemin güvenli bir şekilde çalışabilmesi için, 10.000 veya daha fazla validators sırası. Bölüm 3.7'de tartışıldığı gibi, her birini istiyoruz.Şekil 26: Mücadeleyi ele almak validator ortalama olarak belirli bir mesaja ve imzaya yönelik bir taahhüt yayınlamak için blok başına bir kez. Taahhüt mesajları aynı olsa bile, böyle bir şeyin toplanması BLS imzası ve bunun doğrulanması son derece pahalı olurdu. Ama doğal olarak taahhüt ve açıklama mesajları validators genelinde aynı değildir, dolayısıyla bu tür mesajları ve imzaları bir araya getirmenin bir yoluna ihtiyacımız var. Daha sonra hızlı doğrulamaya izin veren bir yol. Kullandığımız özel yaklaşım şudur: Doğrulayıcılar blok üreticilerine katılıyor. Blok üreticileri biliniyor çağın başlamasından bir süre önce, çünkü indirmeleri için biraz zamana ihtiyaçları var. çağ başlamadan önceki durum ve validator'lerden farklı olarak blok üreticileri gizlenmedi. Her blok üreticisinin v validator yuvası vardır. Doğrulayıcılar gönderir Blok üreticilerine v'lerinden biri olarak dahil edilmeleri için zincir dışı teklifler validators. Bir blok üreticisi validator eklemek isterse, validator'den gelen ilk zincir dışı talebi içeren işlem ve validator öğesinin blok üreticisine katılmasını sağlayan blok üreticisinin imzası. Blok üreticilerine atanan validator'lerin zorunlu olarak atanmadığını unutmayın. Blok üreticisinin parçalar ürettiği aynı parçaları doğrulayın. eğer bir Birden fazla blok üreticisini birleştirmek için validator uygulandı, yalnızca işlem ilk blok üreticisi başarılı olacaktır. Blok üreticileri taahhütleri toplar. Blok üreticisi sürekli olarak validators'den taahhüt ve açıklama mesajlarını toplar. Bu tür mesajların belirli bir sayısı toplandığında, blok üreticisi bir merkle hesaplar. bu mesajların ağacını oluşturur ve her validator'e merkle kökünü ve mesajlarına giden merkle yolu. validator yolu doğrular ve imzalar merkle kökü. Blok üreticisi daha sonra blok üzerinde bir BLS imzası biriktirir. validators'den merkle kökü ve yalnızca merkle kökü ve birikmiş imza Blok üreticisi aynı zamanda sözleşmenin geçerliliğini de imzalar. Ucuz bir ECDSA imzası kullanarak çoklu imza. Çoklu imza çalışmıyorsa gönderilen merkle köküyle veya katılan validator'ların bit maskesiyle eşleşirse, bu eğik çizgi çizilebilir bir davranıştır. Zinciri senkronize ederken bir katılımcı validator'lerden gelen tüm BLS imzalarını doğrulamayı seçebilir (bu, validator'nin ortak anahtarlarının toplanmasını gerektirdiğinden son derece pahalıdır) veya yalnızcaBlok üreticilerinin ECDMA imzalarına güveniyoruz ve blok üreticisine meydan okunmadı ve kesildi. Zorluklar için zincir içi işlemleri ve merkle kanıtlarını kullanma. o eğer hayırsa validators'den gelen mesajları açığa çıkarmanın hiçbir değeri olmadığı belirtilebilir. geçersiz durum geçişi algılandı. Yalnızca gerçek bilgiyi içeren mesajlar Geçersiz durum geçişinin kanıtlarının açıklanması gerekir ve yalnızca bu tür mesajlar için önceki taahhütle eşleştiklerinin gösterilmesi gerekir. Mesajın ihtiyacı var iki amaçla ortaya çıkar: 1. Zincirin geri dönüşünü fiilen başlatmak için geçersiz durum geçişi (bkz. bölüm 3.7.5). 2. validator belgesinin geçerliliğini kanıtlamaya çalışmadığını kanıtlamak için geçersiz yığın. Her iki durumda da iki konuyu ele almamız gerekiyor: 1. Gerçek taahhüt zincire dahil edilmedi, yalnızca merkle kökü diğer mesajlarla birleştirilmiş taahhüt. validator öğesinin şunu kullanması gerekiyor: Blok üreticisi tarafından sağlanan merkle yolu ve orijinal taahhütleri bu mücadeleye kararlı olduklarını kanıtla. 2. Tüm validator'lerin geçersiz parçaya atanması mümkündür. durum geçişi bozuk blok üreticilerine atanacak bunları sansürlüyorlar. Bunu aşmak için onların açıklamalarını göndermelerine izin veriyoruz Zincir üzerinde düzenli bir işlem olarak ve toplamayı atlayarak. İkincisine yalnızca geçersiz durum geçişinin kanıtları için izin verilir; son derece nadirdir ve bu nedenle blokların spam gönderilmesiyle sonuçlanmamalıdır. Ele alınması gereken son konu, blok üreticilerinin iletilerin toplanmasına katılmamayı veya belirli validators'leri kasıtlı olarak sansürlememeyi tercih edin. Blok haline getirerek ekonomik açıdan dezavantajlı hale getiriyoruz üretici ödülü, kendilerine atanan validators sayısıyla orantılıdır. Biz ayrıca dönemler arasındaki blok üreticilerinin büyük ölçüde kesiştiğinden (çünkü her zaman en yüksek hisseye sahip olan en üstteki katılımcılardır), validator'ler yapabilir Büyük ölçüde aynı blok üreticileriyle çalışmaya devam edin ve böylece riski azaltın Geçmişte onları sansürleyen bir blok üreticisine atanmak. 3.9 Anlık Görüntü Zinciri Ana zincirdeki bloklar çok sık üretildiğinden indirme tarihin tamamı çok hızlı bir şekilde pahalı hale gelebilir. Üstelik her zamandan beri blok çok sayıda katılımcının BLS imzasını içeriyorsa, yalnızca imzayı kontrol etmek için ortak anahtarların toplanması engelleyici hale gelebilir aynı zamanda pahalı. Son olarak, öngörülebilir bir gelecekte Ethereum 1.0 muhtemelen bir tane olarak kalacak en çok kullanılan blockchain'lerden biridir ve varlıkları aktarmanın anlamlı bir yolunu sunar
Ethereum'ye yakın olması bir gerekliliktir ve bugün BLS imzalarının doğrulanması Ethereum tarafında yakın blokların geçerliliği mümkün değildir. Nightshade ana zincirindeki her blok isteğe bağlı olarak bir Schnorr içerebilir böyle bir Schnorr içeren son bloğun başlığındaki çoklu imza çoklu imza. Bu tür bloklara anlık görüntü blokları diyoruz. İlk blok her çağ bir anlık görüntü bloğu olmalıdır. Böyle bir çoklu imza üzerinde çalışırken, blok üreticileri ayrıca validators'nin BLS imzalarını da biriktirmelidir son anlık görüntü bloğuna yerleştirin ve bunları bölümünde açıklandığı şekilde toplayın. bölüm 3.8. Blok üreticilerinin belirlediği dönem boyunca sabit olduğundan doğrulama hiçbir çağda yalnızca ilk anlık görüntü blokları yeterlidir. blok üreticilerinin ve validator'lerin büyük bir yüzdesinin gizli anlaşma yapıp yarattığını gösteriyor bir çatal. Çağın ilk bloğu hesaplamaya yetecek bilgiyi içermelidir dönemin blok üreticileri ve validator'ler. Ana zincirin yalnızca anlık görüntüsünü içeren alt zincirine diyoruz. anlık görüntü zincirini engeller. Schnorr çoklu imzası oluşturmak etkileşimli bir süreçtir, ancak ne kadar verimsiz olursa olsun bunu nadiren gerçekleştirmeniz gerekir; yeterli olacaktır. Schnorr çoklu imzaları Ethereum üzerinde kolayca doğrulanabilir, böylece çapraz-blockchain gerçekleştirmenin güvenli bir yolu için önemli temel öğeler sağlanır iletişim. Yakın zincirle senkronizasyon için yalnızca tüm anlık görüntülerin indirilmesi gerekir bloklar ve Schnorr imzalarının doğru olduğunu onaylar (isteğe bağlı olarak validators'nin bireysel BLS imzalarını da doğrular) ve ardından yalnızca senkronizasyon son anlık görüntü bloğundan ana zincir blokları.
خاتمة
ناقشنا في هذه الوثيقة أساليب بناء blockchains و غطت تحديين رئيسيين مع النهج الحالي، وهما صلاحية الدولة وتوافر البيانات. ثم قدمنا Nightshade، وهو تصميم مقسم صلاحيات NEAR البروتوكول. التصميم قيد التنفيذ، إذا كان لديك تعليقات أو أسئلة أو ملاحظات في هذا المستند، يرجى الانتقال إلى https://near.chat.
Çözüm
Bu belgede parçalı blockchains oluşturmaya yönelik yaklaşımları tartıştık ve mevcut yaklaşımlarla iki büyük zorluğu, yani durum geçerliliğini ele aldı ve veri kullanılabilirliği. Daha sonra bir parçalama tasarımı olan Nightshade'i sunduk. NEAR Protokolüne güç verir. Yorumlarınız, sorularınız veya geri bildirimleriniz varsa tasarım üzerinde çalışma devam etmektedir bu belgede lütfen https://near.chat. adresine gidin