كنت أراجع @Dusk مرةً أخرى، وانتهى بي الأمر إلى التعمق أكثر في كيفية عمل تأكيد الكتل فعليًا. ما بدا وكأنه حالة بسيطة «تم تأكيدها» اتضح أنه عملية أكثر طبقات.
تستخدم Dusk نموذج Rolling Finality مع عدة مراحل: accepted وattested وconfirmed وأخيرًا finalized. كل مرحلة تمنح مستوى مختلفًا من الثقة، بدلًا من التعامل مع الحسم بوصفه نتيجة نعم/لا بسيطة.
ما لفت انتباهي حقًا هو أن وقت التأكيد يمكن أن يعتمد على عدد التكرارات الفاشلة التي حدثت قبل قبول الكتلة. كلما زاد هذا العدد، احتاجت الكتلة إلى مزيد من الكتل اللاحقة للوصول إلى حسم نهائي أقوى.
أعجبني منطق الأمان وراء ذلك، لكن توجد أيضًا مسألة تتعلق بسهولة الاستخدام: فمعظم المحافظ تخفي كل هذا التعقيد وتعرض ببساطة «confirmed».
لذلك أنا فضولي—هل تنظر فعلًا إلى حالة الحسم الأساسية، أم أن رسالة التأكيد التي تعرضها المحفظة تكفي لك؟
#dusk $DUSK @Dusk
تستخدم Dusk نموذج Rolling Finality مع عدة مراحل: accepted وattested وconfirmed وأخيرًا finalized. كل مرحلة تمنح مستوى مختلفًا من الثقة، بدلًا من التعامل مع الحسم بوصفه نتيجة نعم/لا بسيطة.
ما لفت انتباهي حقًا هو أن وقت التأكيد يمكن أن يعتمد على عدد التكرارات الفاشلة التي حدثت قبل قبول الكتلة. كلما زاد هذا العدد، احتاجت الكتلة إلى مزيد من الكتل اللاحقة للوصول إلى حسم نهائي أقوى.
أعجبني منطق الأمان وراء ذلك، لكن توجد أيضًا مسألة تتعلق بسهولة الاستخدام: فمعظم المحافظ تخفي كل هذا التعقيد وتعرض ببساطة «confirmed».
لذلك أنا فضولي—هل تنظر فعلًا إلى حالة الحسم الأساسية، أم أن رسالة التأكيد التي تعرضها المحفظة تكفي لك؟
#dusk $DUSK @Dusk
