يُعدّ إيداع DUSK المُعتمَد نهائيًا آمنًا تلقائيًا للإضافة إلى الرصيد.
لم يكتمل عمل «النهائية» بعد
افترضت أنه بمجرد وصول إيداع Moonlight إلى الحالة النهائية، يمكن لمنصة التداول أن تسجل رصيد العميل بأمان وتمضي قدمًا.
وثائق Dusk تُفصّل بين أمرين.
يقوم الماسح بقراءة سجل Moonlight الذي أصبح نهائيًا، لكن يجب على جهة الحضانة أن تُنشئ الرصيد وأن تُحرّك نقطة التحقق (checkpoint) للكتلة معًا. كل رصيد يستخدم معرّف معاملة Dusk كُمفتاح فريد، ولا يتقدم `next_block` إلا بعد أن يصبح الرصيد قابلاً للاعتماد (متينًا).
الآن خذ مثالًا مُنشأ: ينهي الماسح نطاقًا نهائيًا عبر الكتلة 12000. يكتب إيداعًا قدره 5 DUSK لصالح Alice، ثم يتعطل قبل أن يتقدم `next_block`.
عند إعادة تشغيله، يقوم بمسح النطاق مرة أخرى.
الإيداع ما زال نهائيًا. فالمسح الثاني ما زال آمنًا. يمنع معرّف المعاملة الإيداع نفسه من أن يتحول إلى رصيد ائتماني ثانٍ.
لكن اقلب الترتيب.
إذا تقدّم `next_block` قبل أن يصبح الرصيد قابلاً للاعتماد، فقد يترك التعطل الماسح يعتقد أن النطاق قد اكتمل دون تسجيل إيداع العميل أصلًا. تحذّر وثائق Dusk صراحةً من ترتيب العمليات هذا.
إذًا، تُجيب النهائية عن سؤال واحد: "هل حركة DUSK هذه مستقرة؟"
وتُجيب جهة الحضانة عن سؤال آخر: "هل سجّلنا تلك الحركة المستقرة مرة واحدة بالضبط؟"
لا بد أن يكون كلاهما صحيحًا كي يكون رصيد التبادل صحيحًا.
كم مقدار ما يُسمّى «إيداعًا آمنًا» يأتي من نهائية Dusk، وكم مقدار ما يأتي من آلية المحاسبة التي تجعل الحدث النهائي يبقى قائمًا رغم الأعطال دون أن يُفقد أو يُضاف إليه رصيد مرتين؟
@Dusk #dusk $DUSK
لم يكتمل عمل «النهائية» بعد
افترضت أنه بمجرد وصول إيداع Moonlight إلى الحالة النهائية، يمكن لمنصة التداول أن تسجل رصيد العميل بأمان وتمضي قدمًا.
وثائق Dusk تُفصّل بين أمرين.
يقوم الماسح بقراءة سجل Moonlight الذي أصبح نهائيًا، لكن يجب على جهة الحضانة أن تُنشئ الرصيد وأن تُحرّك نقطة التحقق (checkpoint) للكتلة معًا. كل رصيد يستخدم معرّف معاملة Dusk كُمفتاح فريد، ولا يتقدم `next_block` إلا بعد أن يصبح الرصيد قابلاً للاعتماد (متينًا).
الآن خذ مثالًا مُنشأ: ينهي الماسح نطاقًا نهائيًا عبر الكتلة 12000. يكتب إيداعًا قدره 5 DUSK لصالح Alice، ثم يتعطل قبل أن يتقدم `next_block`.
عند إعادة تشغيله، يقوم بمسح النطاق مرة أخرى.
الإيداع ما زال نهائيًا. فالمسح الثاني ما زال آمنًا. يمنع معرّف المعاملة الإيداع نفسه من أن يتحول إلى رصيد ائتماني ثانٍ.
لكن اقلب الترتيب.
إذا تقدّم `next_block` قبل أن يصبح الرصيد قابلاً للاعتماد، فقد يترك التعطل الماسح يعتقد أن النطاق قد اكتمل دون تسجيل إيداع العميل أصلًا. تحذّر وثائق Dusk صراحةً من ترتيب العمليات هذا.
إذًا، تُجيب النهائية عن سؤال واحد: "هل حركة DUSK هذه مستقرة؟"
وتُجيب جهة الحضانة عن سؤال آخر: "هل سجّلنا تلك الحركة المستقرة مرة واحدة بالضبط؟"
لا بد أن يكون كلاهما صحيحًا كي يكون رصيد التبادل صحيحًا.
كم مقدار ما يُسمّى «إيداعًا آمنًا» يأتي من نهائية Dusk، وكم مقدار ما يأتي من آلية المحاسبة التي تجعل الحدث النهائي يبقى قائمًا رغم الأعطال دون أن يُفقد أو يُضاف إليه رصيد مرتين؟
@Dusk #dusk $DUSK
