عندما كنت أترجم/أراجع مستند دورة حياة المعاملة لـ @Dusk Dusk، صححت خطأً واحدًا: تُرجع الواجهة 202 Accepted فقط لتوضّح أن العقدة استلمت الطلب. بعد تقديم توقيع Dusk L1، تقوم العقدة أولًا بعملية admission؛ وعند اجتيازها ينتقل الطلب إلى real mempool ويتم بثّه إلى peers. مُنشئ الكتل ينفّذ العمليات وفق ترتيب gasPrice.
لقد اعتبرتها خط معالجة/تصفية. 202 هو سجل الاستلام في الواجهة الأمامية، وincluded هو الدخول إلى منطقة الانتظار، أما executed فيتطلب أيضًا التحقق من أن err ليس null. حتى بعد قبول الكتلة (accepted)، قد تحدث عملية reverted، إلى أن تقوم blocks/statechange بإعلان finalized، عندها فقط يتم إغلاق/تثبيت السجل. Moonlight يعتمد على تضارب الحساب وnonce، وPhoenix ينظر إلى nullifier؛ والمعاملة المُستبدَلة يجب أن ترفع gasPrice.
سلسلة الأحداث هذه تنطبق فقط على Dusk L1، بينما لدى DuskEVM نموذج sequencer ونموذج finality مختلف. كتبت مستمعًا (listener) سيخزن tx hash وإحداثيات الكتلة، ثم يستخدم onlyFinalized:true للتحقق. أنا لا أتابع إلا included؛ لكن عند حدوث استبدال من العقدة، أو انتهاء الصلاحية، أو الإقصاء بسبب السعة، من السهل اعتبار الحالة المحلية أنها وصلت/تمت. إشعار الاستلام (receipt) هو مجرد سجل الاستلام، أما تأكيد الأموال فيجب أن ينتظر الحالة النهائية.
#dusk $DUSK
لقد اعتبرتها خط معالجة/تصفية. 202 هو سجل الاستلام في الواجهة الأمامية، وincluded هو الدخول إلى منطقة الانتظار، أما executed فيتطلب أيضًا التحقق من أن err ليس null. حتى بعد قبول الكتلة (accepted)، قد تحدث عملية reverted، إلى أن تقوم blocks/statechange بإعلان finalized، عندها فقط يتم إغلاق/تثبيت السجل. Moonlight يعتمد على تضارب الحساب وnonce، وPhoenix ينظر إلى nullifier؛ والمعاملة المُستبدَلة يجب أن ترفع gasPrice.
سلسلة الأحداث هذه تنطبق فقط على Dusk L1، بينما لدى DuskEVM نموذج sequencer ونموذج finality مختلف. كتبت مستمعًا (listener) سيخزن tx hash وإحداثيات الكتلة، ثم يستخدم onlyFinalized:true للتحقق. أنا لا أتابع إلا included؛ لكن عند حدوث استبدال من العقدة، أو انتهاء الصلاحية، أو الإقصاء بسبب السعة، من السهل اعتبار الحالة المحلية أنها وصلت/تمت. إشعار الاستلام (receipt) هو مجرد سجل الاستلام، أما تأكيد الأموال فيجب أن ينتظر الحالة النهائية.
#dusk $DUSK