#dusk $DUSK
تابعت مؤخرًا المستند الخاص بدورة حياة المعاملات لـ @Dusk ، واكتشفت أنني كنت أتبسط في فهم هذه المسألة سابقًا إلى حدٍ كبير:
نجاح تنفيذ المعاملة لا يعني بالضرورة أن النظام المالي يمكنه اعتبار هذه الحالة “حقيقة” بالفعل.
في DuskDS، تمر المعاملة أولًا بمرحلة الاستلام والانتشار والتنفيذ، ثم يتعين عليها أن تمر أيضًا بمرحلة التأكيد النهائي.
حتى إن الوثائق الرسمية تنبّه صراحةً إلى أن:
included وaccepted وconfirmed لا يمكن اعتبارها مباشرةً payment finality.
والسبب ليس معقدًا.
إذا دخلت المعاملة إلى accepted block، فقد يتم إرجاع هذا الـ block (أي التراجع عنه).
أما عندما تصل إلى finalized، فهنا فقط تعني أن الحالة دخلت finality حتمية.
في Succinct Attestation لدى Dusk، ستستمر العملية عبر المراحل التالية:
Proposal
→ Validation
→ Ratification
وعند اكتمال Ratification، يصبح الـ block نهائيًا فعلًا.
أعتقد أن هذه التفاصيل أهم من مجرد “كم TPS”.
لأن البورصات أو الأنظمة المالية لا تخاف من مجرد تأخر بضعة ثوانٍ في مشاهدة معاملة.
بل تخاف من:
أنني قد تكون قد قمت بالفعل بإدخال المبلغ في حساب المستخدم اعتمادًا على هذه الحالة، ثم تتغير الحالة الأساسية لاحقًا.
لذلك تضع Dusk أيضًا في وثائق التكامل الخاصة بالبورصات متطلبات واضحة: لا يجوز تسجيل العمليات مسبقًا بسبب mempool أو event المسمى included أو حتى accepted-but-unfinalized block.
هذه في الحقيقة طريقة واقعية لشرح مفهوم finality.
إنه ليس مجرد مصطلح يتعلق بالأداء.
بل هو إجابة عن سؤال:
من أي لحظة بالضبط يبدأ النظام بحيث يمكن ألا نقلق بعد الآن من أن هذه الحالة قد تُسحب؟
حالياً تعرض صفحة موقع Dusk الرسمية مؤشر finality بحوالي 10 ثوانٍ.
ما يهمني أكثر ليس ما إذا كان هذا الرقم يبدو جميلًا.
بل ما إذا كان الحد الفاصل بين accepted وfinalized يمكن أن يظل واضحًا ومستقرًا طوال الوقت بعد أن يصبح الحمل الحقيقي على الشبكة الرئيسية على أرض الواقع.
فالاعتماد الحقيقي في النهاية هو على هذا.
تابعت مؤخرًا المستند الخاص بدورة حياة المعاملات لـ @Dusk ، واكتشفت أنني كنت أتبسط في فهم هذه المسألة سابقًا إلى حدٍ كبير:
نجاح تنفيذ المعاملة لا يعني بالضرورة أن النظام المالي يمكنه اعتبار هذه الحالة “حقيقة” بالفعل.
في DuskDS، تمر المعاملة أولًا بمرحلة الاستلام والانتشار والتنفيذ، ثم يتعين عليها أن تمر أيضًا بمرحلة التأكيد النهائي.
حتى إن الوثائق الرسمية تنبّه صراحةً إلى أن:
included وaccepted وconfirmed لا يمكن اعتبارها مباشرةً payment finality.
والسبب ليس معقدًا.
إذا دخلت المعاملة إلى accepted block، فقد يتم إرجاع هذا الـ block (أي التراجع عنه).
أما عندما تصل إلى finalized، فهنا فقط تعني أن الحالة دخلت finality حتمية.
في Succinct Attestation لدى Dusk، ستستمر العملية عبر المراحل التالية:
Proposal
→ Validation
→ Ratification
وعند اكتمال Ratification، يصبح الـ block نهائيًا فعلًا.
أعتقد أن هذه التفاصيل أهم من مجرد “كم TPS”.
لأن البورصات أو الأنظمة المالية لا تخاف من مجرد تأخر بضعة ثوانٍ في مشاهدة معاملة.
بل تخاف من:
أنني قد تكون قد قمت بالفعل بإدخال المبلغ في حساب المستخدم اعتمادًا على هذه الحالة، ثم تتغير الحالة الأساسية لاحقًا.
لذلك تضع Dusk أيضًا في وثائق التكامل الخاصة بالبورصات متطلبات واضحة: لا يجوز تسجيل العمليات مسبقًا بسبب mempool أو event المسمى included أو حتى accepted-but-unfinalized block.
هذه في الحقيقة طريقة واقعية لشرح مفهوم finality.
إنه ليس مجرد مصطلح يتعلق بالأداء.
بل هو إجابة عن سؤال:
من أي لحظة بالضبط يبدأ النظام بحيث يمكن ألا نقلق بعد الآن من أن هذه الحالة قد تُسحب؟
حالياً تعرض صفحة موقع Dusk الرسمية مؤشر finality بحوالي 10 ثوانٍ.
ما يهمني أكثر ليس ما إذا كان هذا الرقم يبدو جميلًا.
بل ما إذا كان الحد الفاصل بين accepted وfinalized يمكن أن يظل واضحًا ومستقرًا طوال الوقت بعد أن يصبح الحمل الحقيقي على الشبكة الرئيسية على أرض الواقع.
فالاعتماد الحقيقي في النهاية هو على هذا.