افترضت أنه إذا أردت تنفيذ ثلاث عمليات على السلسلة—الموافقة، ثم التبديل، ثم الإيداع—فستتعامل السلسلة مع ذلك كعملية واحدة تحدث أو لا تحدث على الإطلاق. وتقول مسألة مفتوحة في مستودع Rusk التابع لـ Dusk إنه ليس هذا ما يحدث اليوم.
تحمل معاملة Dusk اليوم عملية اختيارية واحدة فقط: استدعاء عقد واحد، أو نشر عقد واحد، أو مذكّرة واحدة، مع قيمة واحدة، ومستلم واحد، ورقم تسلسلي (nonce) واحد، وتوقيع واحد. لذلك تصبح الموافقة والتبديل والإيداع ثلاث معاملات منفصلة، يُدرج كلٌّ منها أو يُسقَط بشكل مستقل. تنص مسألة Dusk على ذلك صراحةً: لا توجد ضمانات للذرّية (atomicity) عبر هذه العمليات.
ادخل الموافقة والتبديل ولكن ليس الإيداع، وستبقى في منتصف التدفق دون إمكانية تراجع على مستوى البروتوكول.
المشكلة ليست فقط أن التدفقات متعددة الخطوات قد تتوقف في منتصفها. إصلاح ذلك يغيّر من يتحمل تكلفة التوافق.
يسمح عقد الباتشر (batcher) بجعل التسلسل ذريًّا بالكامل، لأن استدعاء فرعي فاشل يُرجِع (reverts) المعاملة الخارجية. لكن عقدًا مستهدفًا يتحقق من الأشخاص الذين يستدعونه مباشرةً سيرى الباتشر بدلًا منك، ما لم يكن ذلك العقد مكتوبًا مسبقًا ليتجاوز الاستدعاء المباشر. أما معاملة الباتش على مستوى البروتوكول فتجعلك أنت المكلّف (caller) في كل خطوة، لكنها لا تُطرح دون صيغة معاملة جديدة، وتغييرات في الإجماع، وتحديث هارد فورك، وتحديث كل حزمة تطوير SDK للأجهزة المحمولة (wallet SDKs).
إضافة الباتش لا تُزيل المقايضة. إنها تحدد ما إذا كانت مسؤولية التوافق تقع في تفويض التطبيق (application authorization) أم في طبقة البروتوكول.
"إن إصلاح الذرّية لا يُزيل المقايضة؛ بل يحدد إلى أين تنتقل مسؤولية التوافق وحدود الثقة."
ما أود أن أراقبه فعليًا: هل تختار Dusk الباتشر على مستوى التطبيق أم المعاملة على مستوى البروتوكول؟ وما الافتراضات الحالية المتعلقة بالتفويض التي يفرضها هذا الاختيار على المطورين كي يغيّروها.
#dusk $DUSK @Dusk
تحمل معاملة Dusk اليوم عملية اختيارية واحدة فقط: استدعاء عقد واحد، أو نشر عقد واحد، أو مذكّرة واحدة، مع قيمة واحدة، ومستلم واحد، ورقم تسلسلي (nonce) واحد، وتوقيع واحد. لذلك تصبح الموافقة والتبديل والإيداع ثلاث معاملات منفصلة، يُدرج كلٌّ منها أو يُسقَط بشكل مستقل. تنص مسألة Dusk على ذلك صراحةً: لا توجد ضمانات للذرّية (atomicity) عبر هذه العمليات.
ادخل الموافقة والتبديل ولكن ليس الإيداع، وستبقى في منتصف التدفق دون إمكانية تراجع على مستوى البروتوكول.
المشكلة ليست فقط أن التدفقات متعددة الخطوات قد تتوقف في منتصفها. إصلاح ذلك يغيّر من يتحمل تكلفة التوافق.
يسمح عقد الباتشر (batcher) بجعل التسلسل ذريًّا بالكامل، لأن استدعاء فرعي فاشل يُرجِع (reverts) المعاملة الخارجية. لكن عقدًا مستهدفًا يتحقق من الأشخاص الذين يستدعونه مباشرةً سيرى الباتشر بدلًا منك، ما لم يكن ذلك العقد مكتوبًا مسبقًا ليتجاوز الاستدعاء المباشر. أما معاملة الباتش على مستوى البروتوكول فتجعلك أنت المكلّف (caller) في كل خطوة، لكنها لا تُطرح دون صيغة معاملة جديدة، وتغييرات في الإجماع، وتحديث هارد فورك، وتحديث كل حزمة تطوير SDK للأجهزة المحمولة (wallet SDKs).
إضافة الباتش لا تُزيل المقايضة. إنها تحدد ما إذا كانت مسؤولية التوافق تقع في تفويض التطبيق (application authorization) أم في طبقة البروتوكول.
"إن إصلاح الذرّية لا يُزيل المقايضة؛ بل يحدد إلى أين تنتقل مسؤولية التوافق وحدود الثقة."
ما أود أن أراقبه فعليًا: هل تختار Dusk الباتشر على مستوى التطبيق أم المعاملة على مستوى البروتوكول؟ وما الافتراضات الحالية المتعلقة بالتفويض التي يفرضها هذا الاختيار على المطورين كي يغيّروها.
#dusk $DUSK @Dusk
