لقد تعطل مساءً من كتلةِ نهائية حالاتها هذا الأسبوع لأن كلمة "final" تُستخدم على نحوٍ فضفاض في وثائق البلوك تشين، وأردتُ معرفة ما الذي يعنيه كلُّ وضع فعليًا في الورقة البيضاء، التي تستخدم أربع مصطلحات مميزة.
تتبع أربعة أشياء.
لقد قُبلت كتلةٌ مع إقرارٍ بالنجاح (success attestation)، لكن التكرار I > 0 وليست كل التكرارات السابقة لديها إقرارات بالفشل (fail attestations). تم قبولها في السلسلة. ولا تزال يمكن استبدالها ببلوكٍ منافس من رقم تكرارٍ أقل. ليست مُسَوّاة بشكل دائم.
مُقَرّ به (Attested): إما أن يكون التكرار I = 0 (الأدنى الممكن، ولا يوجد تكرار أقل لاستبداله)، أو أن جميع التكرارات السابقة لديها إقرارات بالفشل. لا يمكن استبدال الكتلة ببلوك من تكرار أقل. هذه هي أقوى حالة يمكن لبلوكٍ منفرد أن يصل إليها اعتمادًا على خصائص إقراره وحدها.
مُؤكّد (Confirmed): الكتلة إما مُقبولة أو مُقرّ بها، وقد تم استيفاء قواعد النهائية (finality) بما يأتي بعدها. تصبح البلوكات المقبولة مؤكدّة بعد 2n من الخلفيات المتتالية المُقرّ بها أو المُؤكدّة، حيث n هو عدد التكرارات السابقة غير المُقرّ بها. وتصبح البلوكات المُقرّ بها مؤكدّة عندما يكون لها خلف واحد مُقرّ به أو مُؤكد.
نهائي (Final): مؤكد، وأن والدها (parent) أيضًا نهائي. لا يمكن استبدالها تحت أي ظرف. هذه هي الضمانة الحقيقية الوحيدة.
في الواقع، أعتقد أن هذا يهمّ أكثر التطبيقات التي تحتاج إلى معرفة متى يتم تسوية معاملة فعليًا — وليس فقط إدراجها. إن استخدام "accepted" كبديل لـ "settled" يترك احتمال الاستبدال واردًا. إن الزناد الصحيح هو "confirmed" على الأقل، و"final" لأي شيء عالي المخاطر.
السؤال هو ما إذا كان مطوّرو التطبيقات المبنون على Dusk يحصلون على إشارة API واضحة لكل حالة — أم أنهم يتعين عليهم الاستعلام عن حالة البلوك وتنفيذ آلة حالاتهم الخاصة لتتبع اللحظة التي تعبر فيها كتلة محددة إلى حالة "final". @Dusk
$DUSK #dusk
تتبع أربعة أشياء.
لقد قُبلت كتلةٌ مع إقرارٍ بالنجاح (success attestation)، لكن التكرار I > 0 وليست كل التكرارات السابقة لديها إقرارات بالفشل (fail attestations). تم قبولها في السلسلة. ولا تزال يمكن استبدالها ببلوكٍ منافس من رقم تكرارٍ أقل. ليست مُسَوّاة بشكل دائم.
مُقَرّ به (Attested): إما أن يكون التكرار I = 0 (الأدنى الممكن، ولا يوجد تكرار أقل لاستبداله)، أو أن جميع التكرارات السابقة لديها إقرارات بالفشل. لا يمكن استبدال الكتلة ببلوك من تكرار أقل. هذه هي أقوى حالة يمكن لبلوكٍ منفرد أن يصل إليها اعتمادًا على خصائص إقراره وحدها.
مُؤكّد (Confirmed): الكتلة إما مُقبولة أو مُقرّ بها، وقد تم استيفاء قواعد النهائية (finality) بما يأتي بعدها. تصبح البلوكات المقبولة مؤكدّة بعد 2n من الخلفيات المتتالية المُقرّ بها أو المُؤكدّة، حيث n هو عدد التكرارات السابقة غير المُقرّ بها. وتصبح البلوكات المُقرّ بها مؤكدّة عندما يكون لها خلف واحد مُقرّ به أو مُؤكد.
نهائي (Final): مؤكد، وأن والدها (parent) أيضًا نهائي. لا يمكن استبدالها تحت أي ظرف. هذه هي الضمانة الحقيقية الوحيدة.
في الواقع، أعتقد أن هذا يهمّ أكثر التطبيقات التي تحتاج إلى معرفة متى يتم تسوية معاملة فعليًا — وليس فقط إدراجها. إن استخدام "accepted" كبديل لـ "settled" يترك احتمال الاستبدال واردًا. إن الزناد الصحيح هو "confirmed" على الأقل، و"final" لأي شيء عالي المخاطر.
السؤال هو ما إذا كان مطوّرو التطبيقات المبنون على Dusk يحصلون على إشارة API واضحة لكل حالة — أم أنهم يتعين عليهم الاستعلام عن حالة البلوك وتنفيذ آلة حالاتهم الخاصة لتتبع اللحظة التي تعبر فيها كتلة محددة إلى حالة "final". @Dusk
$DUSK #dusk
