#dusk $DUSK التحذير الأكثر خطورة في خلفية الأوراق المالية: ليس بالضرورة أن يكون "فشلًا"، بل قد يكون "تم قبوله". الفشل على الأقل يجعل الناس يتوقفون، أما تم قبوله فقد يُفهم بسهولة على أنه تم تسوية المال والأوراق بشكل نهائي. وبالنسبة للـسلسلة أيضًا: دخول كتلة إلى سجلّ محلي لا يعني أنها وصلت فعلاً إلى الخطوة الأخيرة غير القابلة للاستبدال.
أعدت قراءة ورقة Dusk البيضاء عن Rolling Finality باستخدام الرقم @Dusk ، ثم اكتشفت أن Dusk لم تخلط كل "التأكيدات" في كلمة واحدة، بل قسمت الحالة إلى accepted وattested وconfirmed وfinal أربع حالات. قد تكون الكتلة في حالة accepted قد حصلت على إثبات نجاح، لكن إذا كانت قادمة من تكرار أعلى، ولم تكن التكرارات الأقل السابقة قد احتوت على إثبات فشل، فقد يُستبدل ذلك لاحقًا عند ظهور كتلة شرعية من تكرار أقل، وسيتراجع بعدها أيضًا ما يليها من كتل.
أما attested فهي أكثر استقرارًا؛ لأنها تكون إما قادمة من التكرار رقم 0، أو أن التكرارات السابقة تركت إثباتات فشل. وتحتاج confirmed إلى أن تستمر الكتل اللاحقة في إضافة الموثوقية إلى السلسلة الحالية. ولا تمثل final إلا عندما تكون الكتلة الأب أيضًا قد وصلت إلى final، فتُغلق كامل مسار الأسلاف ولا يمكن استبداله بعد ذلك.
قدمت الورقة البيضاء مثالًا محددًا: كتلة ما تتولد في التكرار الخامس، لكن قبل ذلك لم تكن توجد سوى جولتين تحملان إثبات فشل. فتم وسمها أولًا accepted، وتحتاج إلى انتظار 4 كتل متتالية في حالتي attested أو confirmed، لكي تنتقل إلى confirmed. أي أنه بين "تم إصدار الكتلة" و"يمكن اعتبار تسليم الأوراق المالية حقيقة لا رجعة فيها" قد توجد عدة خطوات فعلًا.
وأنا أُقرّ بهذه الصراحة. النظام المالي يخشى أكثر من إخفاء الاحتمال داخل علامة اختيار خضراء واحدة. لكن هذا أيضًا يمنح فريق المنتج درسًا: المحفظة، ومنصة التداول، ونظام التسجيل—أي حالة بالضبط يعرضها؟ وهل يسمح للمستخدم حين يظهر له accepted بالاستمرار في تحويل الأصول أو استردادها؟ إذا كانت الواجهة تُوحّد كل شيء وتكتب "تم بنجاح"، حتى مع وجود حالة توافق (consensus) أكثر تدقيقًا، فقد تُطمَس التفاصيل بصياغة نص المنتج.
لذلك عندما أنظر إلى الإنهاء السريع لدى Dusk بالثواني، لا أنظر فقط إلى كم ثانية استغرق متوسط التنفيذ، بل أيضًا إلى توزيع انتقال accepted إلى final تحت الحالات الشاذة للتكرار، وإلى ما إذا كان التطبيق فعلاً ينتظر حتى final ليُقرّ بالأمر. الإنهائية ليست رقمًا تسويقيًا، بل هي انضباط لا يسمح بتشبيه "اكتمل تقريبًا" بـ"اكتمل فعلًا".
أعدت قراءة ورقة Dusk البيضاء عن Rolling Finality باستخدام الرقم @Dusk ، ثم اكتشفت أن Dusk لم تخلط كل "التأكيدات" في كلمة واحدة، بل قسمت الحالة إلى accepted وattested وconfirmed وfinal أربع حالات. قد تكون الكتلة في حالة accepted قد حصلت على إثبات نجاح، لكن إذا كانت قادمة من تكرار أعلى، ولم تكن التكرارات الأقل السابقة قد احتوت على إثبات فشل، فقد يُستبدل ذلك لاحقًا عند ظهور كتلة شرعية من تكرار أقل، وسيتراجع بعدها أيضًا ما يليها من كتل.
أما attested فهي أكثر استقرارًا؛ لأنها تكون إما قادمة من التكرار رقم 0، أو أن التكرارات السابقة تركت إثباتات فشل. وتحتاج confirmed إلى أن تستمر الكتل اللاحقة في إضافة الموثوقية إلى السلسلة الحالية. ولا تمثل final إلا عندما تكون الكتلة الأب أيضًا قد وصلت إلى final، فتُغلق كامل مسار الأسلاف ولا يمكن استبداله بعد ذلك.
قدمت الورقة البيضاء مثالًا محددًا: كتلة ما تتولد في التكرار الخامس، لكن قبل ذلك لم تكن توجد سوى جولتين تحملان إثبات فشل. فتم وسمها أولًا accepted، وتحتاج إلى انتظار 4 كتل متتالية في حالتي attested أو confirmed، لكي تنتقل إلى confirmed. أي أنه بين "تم إصدار الكتلة" و"يمكن اعتبار تسليم الأوراق المالية حقيقة لا رجعة فيها" قد توجد عدة خطوات فعلًا.
وأنا أُقرّ بهذه الصراحة. النظام المالي يخشى أكثر من إخفاء الاحتمال داخل علامة اختيار خضراء واحدة. لكن هذا أيضًا يمنح فريق المنتج درسًا: المحفظة، ومنصة التداول، ونظام التسجيل—أي حالة بالضبط يعرضها؟ وهل يسمح للمستخدم حين يظهر له accepted بالاستمرار في تحويل الأصول أو استردادها؟ إذا كانت الواجهة تُوحّد كل شيء وتكتب "تم بنجاح"، حتى مع وجود حالة توافق (consensus) أكثر تدقيقًا، فقد تُطمَس التفاصيل بصياغة نص المنتج.
لذلك عندما أنظر إلى الإنهاء السريع لدى Dusk بالثواني، لا أنظر فقط إلى كم ثانية استغرق متوسط التنفيذ، بل أيضًا إلى توزيع انتقال accepted إلى final تحت الحالات الشاذة للتكرار، وإلى ما إذا كان التطبيق فعلاً ينتظر حتى final ليُقرّ بالأمر. الإنهائية ليست رقمًا تسويقيًا، بل هي انضباط لا يسمح بتشبيه "اكتمل تقريبًا" بـ"اكتمل فعلًا".
