التفصيل الذي جعلني أعود للنظر مرتين: في Dusk، «accepted» ليست الشيء نفسه كونه نهائيًا.
كنت أتوقع أن تتعامل سلسلة بلوكشين مصممة للتسوية المالية مع التنفيذ الناجح بوصفه نقطة النهاية. وثائق تكامل L1 الخاصة بـ Dusk أكثر صرامة. يمكن إرسال معاملة والحصول على HTTP 202 Accepted، ثم دخول mempool أحد العقد، ثم تنفيذها داخل كتلة «accepted» دون أي خطأ في التنفيذ — ومع ذلك قد لا تكون مدفوعاتها نهائية.
تنص الوثائق صراحةً على أنه يمكن حتى إعادة التراجع عن الكتل المقبولة. ولا تتحقق النهائية إلا عندما تُعلِّم أحداث "blocks/statechange" الكتلة بأنها «finalized». بل إن Dusk تحذّر حتى المُدمِجين من استخدام «included» أو «accepted» أو «confirmed» كمؤشر نهائية مدفوعات.
يبدو هذا الأمر كأنه تفاصيل تنفيذية إلى أن تتذكر ما الذي تستهدفه DUSK: التطبيقات المالية الخاضعة للتنظيم. بالنسبة للبورصات أو معالِجات المدفوعات أو أنظمة الأصول الممثلة عبر التوكنات، فإن الخلط بين التنفيذ والتسوية قد يتحول إلى مشكلة محاسبية، وليس مجرد مشكلة في تجربة المستخدم.
ما شدّ انتباهي هو التوتر القائم: Dusk تصف نهائية حتمية بعد التصديق، لكن التطبيقات لا تزال بحاجة إلى احترام حدّ «finalization» الصريح. هذا يبدو أقل كونه تناقضًا وأكثر كونه هندسة ناضجة للتسوية.
ما أتابعه الآن: مدى الاتساق الذي تعرض به المحافظ وتطبيقات المال هذا الفرق بدلًا من دمجه كله في حالة واحدة «confirmed».
@Dusk $DUSK #dusk
كنت أتوقع أن تتعامل سلسلة بلوكشين مصممة للتسوية المالية مع التنفيذ الناجح بوصفه نقطة النهاية. وثائق تكامل L1 الخاصة بـ Dusk أكثر صرامة. يمكن إرسال معاملة والحصول على HTTP 202 Accepted، ثم دخول mempool أحد العقد، ثم تنفيذها داخل كتلة «accepted» دون أي خطأ في التنفيذ — ومع ذلك قد لا تكون مدفوعاتها نهائية.
تنص الوثائق صراحةً على أنه يمكن حتى إعادة التراجع عن الكتل المقبولة. ولا تتحقق النهائية إلا عندما تُعلِّم أحداث "blocks/statechange" الكتلة بأنها «finalized». بل إن Dusk تحذّر حتى المُدمِجين من استخدام «included» أو «accepted» أو «confirmed» كمؤشر نهائية مدفوعات.
يبدو هذا الأمر كأنه تفاصيل تنفيذية إلى أن تتذكر ما الذي تستهدفه DUSK: التطبيقات المالية الخاضعة للتنظيم. بالنسبة للبورصات أو معالِجات المدفوعات أو أنظمة الأصول الممثلة عبر التوكنات، فإن الخلط بين التنفيذ والتسوية قد يتحول إلى مشكلة محاسبية، وليس مجرد مشكلة في تجربة المستخدم.
ما شدّ انتباهي هو التوتر القائم: Dusk تصف نهائية حتمية بعد التصديق، لكن التطبيقات لا تزال بحاجة إلى احترام حدّ «finalization» الصريح. هذا يبدو أقل كونه تناقضًا وأكثر كونه هندسة ناضجة للتسوية.
ما أتابعه الآن: مدى الاتساق الذي تعرض به المحافظ وتطبيقات المال هذا الفرق بدلًا من دمجه كله في حالة واحدة «confirmed».
@Dusk $DUSK #dusk