كنت أظن سابقًا أن التحقق من البلوكشين بسيط جدًا: تُدخل المعاملة إلى البلوك، ثم تُعدّ بضعة بلوكات بعدها، وبشكل أساسي يصبح الأمر كافيًا للاعتبار “آمنًا”. لكن الليلة وأنا أراجع وثيقة دورة حياة المعاملة للمعرّف @Dusk ، توقفت عند جملة واحدة: accepted blocks can still be reverted. إذا كانت قد تم قبولها، فلماذا يمكن إلغاءها؟
ثم فهمت بعد قراءة ورقة 2024 Whitepaper. في إجماع Dusk تمرّ دورة الإجماع بعدة iteration. وقد تظهر كتل متنافسة ضمن نفس الـ round. فحتى إن كانت الكتلة ذات iteration أعلى قد تم قبولها (accepted)، يمكن أن تُفعَّل آلية fallback إذا استوفت كتلة منافِسة ذات iteration أقل الشروط المطلوبة.
“رؤية ما تم نشره على السلسلة” لا تعني بالضرورة أنه لا يمكن استبداله.
Rolling Finality أكثر لا بديهيّة. تستخدم الورقة مصطلح n للدلالة على عدد الـ iterations غير المكتملة لتحديد attestation. يجب على الكتل المقبولة أن تنتظر حتى تدخل إلى حالة confirmed بعد أن يتبعها 2×n من البلوكات اللاحقة المتتابعة التي تم attesting لها أو تأكيدها (attested أو confirmed). لنفترض n=3، إذن يلزم مراقبة 6 بلوكات لاحقة تستوفي الشروط.
عندها اكتشفت أن “عدد التأكيدات” ليس مقياسًا موحّدًا. فحتى مع كون المعاملة قد تم نشرها على السلسلة (on-chain)، يختلف تاريخ الإجماع، وبالتالي تختلف درجة الاستقرار.
التوصية في الوثائق الحالية أكثر مباشرة: لا تفترض أن included أو accepted أو حتى confirmed تعني “وصلت/تم تسليمها”؛ عليك الانتظار حتى تصبح finalized فعلًا.
قد تكون الفروقات في التحويلات الصغيرة مجرد ثوانٍ؛ لكن عند إدراجها في تسوية DvP لصفقات OTC كبيرة أو RWA، فإن “رؤية المعاملة” و“التسوية غير القابلة للعكس” هما أمران مختلفان تمامًا. في المرة القادمة عندما تنظر إلى معاملات Dusk الكبيرة، اسأل فقط: هل أصبحت finalized؟
#dusk $DUSK @Dusk
ثم فهمت بعد قراءة ورقة 2024 Whitepaper. في إجماع Dusk تمرّ دورة الإجماع بعدة iteration. وقد تظهر كتل متنافسة ضمن نفس الـ round. فحتى إن كانت الكتلة ذات iteration أعلى قد تم قبولها (accepted)، يمكن أن تُفعَّل آلية fallback إذا استوفت كتلة منافِسة ذات iteration أقل الشروط المطلوبة.
“رؤية ما تم نشره على السلسلة” لا تعني بالضرورة أنه لا يمكن استبداله.
Rolling Finality أكثر لا بديهيّة. تستخدم الورقة مصطلح n للدلالة على عدد الـ iterations غير المكتملة لتحديد attestation. يجب على الكتل المقبولة أن تنتظر حتى تدخل إلى حالة confirmed بعد أن يتبعها 2×n من البلوكات اللاحقة المتتابعة التي تم attesting لها أو تأكيدها (attested أو confirmed). لنفترض n=3، إذن يلزم مراقبة 6 بلوكات لاحقة تستوفي الشروط.
عندها اكتشفت أن “عدد التأكيدات” ليس مقياسًا موحّدًا. فحتى مع كون المعاملة قد تم نشرها على السلسلة (on-chain)، يختلف تاريخ الإجماع، وبالتالي تختلف درجة الاستقرار.
التوصية في الوثائق الحالية أكثر مباشرة: لا تفترض أن included أو accepted أو حتى confirmed تعني “وصلت/تم تسليمها”؛ عليك الانتظار حتى تصبح finalized فعلًا.
قد تكون الفروقات في التحويلات الصغيرة مجرد ثوانٍ؛ لكن عند إدراجها في تسوية DvP لصفقات OTC كبيرة أو RWA، فإن “رؤية المعاملة” و“التسوية غير القابلة للعكس” هما أمران مختلفان تمامًا. في المرة القادمة عندما تنظر إلى معاملات Dusk الكبيرة، اسأل فقط: هل أصبحت finalized؟
#dusk $DUSK @Dusk
