اليوم 3/5 ~ تأكيدات التفريغ ~ كيف تضع السلاسل نموذجا نهائيا ، ولماذا يحتاج تطبيقك إلى التفكير بشكل احتمالي ~ بالأمس ، استكشفنا كيف يعتمد "التأكيد" على السلسلة. اليوم ، دعنا نفك كيف تصنع هذه السلاسل في الواقع نموذجا نهائيا ، ولماذا يحتاج تطبيقك إلى تجاوز العرض الثنائي ل "مؤكد مقابل لا" لا تقدم معظم السلاسل إجابة واحدة نظيفة. بدلا من ذلك ، أنت تعمل مع الطيف: 1. النهائية الحتمية: تقدم السلاسل التي تستخدم إجماع على غرار BFT (مثل cosms ، وبعض alt-DAs) ، وتسوية L1 (مثل ethereu بعد النهاية) ومعظم PoS ضمانات صارمة - بمجرد الانتهاء منها ، لا يمكن إرجاع المعاملة. 2. النهاية الاحتمالية: تقدم سلاسل أسرى العمل (مثل البيتكوين) و Ethereum "ما قبل النهاية" ضمانات إحصائية. من غير المرجح أن يتم إعادة تنظيم tx المدفون بعمق 12 كتلة - ولكن ليس مستحيلا. كلما كان أعمق ، كان أكثر أمانا. 3. إشارات ناعمة: تأكيدات التسلسل ، وإدراج mempool ، ومرحلات البناء - إنها سريعة ، ولكنها تنطوي على مخاطر. هذه الإشارات مفيدة ، ولكن يجب التعامل معها بعناية. غالبا ما تتعامل التطبيقات مع هذه المصادر على قدم المساواة: → "انتظر X كتل" → "ثق في جهاز التسلسل" → "التحقق من التضمين" لكن هذا التجريد ينكسر بمجرد أن تذهب إلى interop. قد يمتد التطبيق عبر السلاسل إلى: ~ سلسلة BFT سريعة النهاية ~ مجموعة متفائلة مع نوافذ احتيال لمدة 7 أيام ~ L1 مع نهائية احتمالية ~ سلسلة مع ضمانات التسلسل فقط لا يمكن لمنطق التطبيق الخاص بك ترميز قاعدة مقاس واحد يناسب الجميع. عليك أن تسأل: "ما مدى احتمالية عودة هذا التكساس؟ ومن يفرض ذلك؟ ==> النهائية ليست ثنائية والمفاضلة بين السرعة والأمان ليست خطية. (على سبيل المثال ، لا تكتسب Multisigs السرعة أو الثقة.) → ما تحتاجه هو ثقة قابلة للبرمجة ومدركة للسلسلة == طريقة للتعبير عما تعنيه كلمة "مؤكد" في كل سياق