هل ما نقص من DUSK في المحفظة بعد فشل العملية يُعتبر كأنك صرفت أموالًا بلا فائدة؟👻؟
عندما فتحت صفحة Tokenomics الخاصة بـ Dusk، رأيت قاعدة سهلة جدًا أن تُفوّت: إذا استُهلك الغاز بالكامل في عملية ما، فسيتم التراجع (Rollback)، لكن الغاز الذي تم استهلاكه بالفعل لن يُعفى منه—يتم تحصيل رسومه مع ذلك. كلمة “فشل” التي يتكلم بها المستخدمون قد تعني على السلسلة واحدًا من نتيجتين على الأقل.
حد الغاز (Gas limit) يحدد أقصى قدر من العمل يمكن لهذه الاستدعاء القيام به، وسعر الغاز (Gas price) هو ثمن كل وحدة من العمل. تُحسب التكلفة بناءً على الاستهلاك الفعلي؛ وما لم يُستخدم لا يُخصم. هذه القواعد بحد ذاتها ليست مشكلة. المشكلة أن المحفظة غالبًا ما تعطيك فقط عبارة واحدة بخلفية حمراء ونص أبيض: “Failed”.
سابقًا كنت بالتأكيد ألوم المستخدمين لأنهم لم يتركوا رسومًا كافية. الآن وقد عدت أنظر من جديد، هل المنتج يشرح سبب الفشل بوضوح؟ هذا هو ما يحدد مباشرة ما إذا كان المستخدم سيتحمّس لمحاولة ثانية أم لا. هل السبب أن حجم العمل غير كافٍ؟ أم مشكلة صلاحيات؟ أم معطيات (Parameters) خاطئة؟ أم حالة الشبكة؟ طريقة التعامل تختلف تمامًا.
لنضرب مثالًا على ذلك. شخص استخدم كمية صغيرة من DUSK لتشغيل عقد (Contract)، لكنه وضع Gas limit منخفضًا جدًا. فشلت المعاملة: نقص الرصيد حصل، لكن حالة السلسلة لم تتغير. ثم حاول مرة أخرى ودفع رسومًا إضافية. إذا كانت الجذور في كتابة المعلمات بشكل خاطئ، فستستمر الرسوم في الاحتراق في كل مرة.
لذلك لا أرى أن آلية غاز Dusk يمكن اختزالها ببساطة إلى “حتى الفشل يجب أن يُحسب عليه رسوم”. البروتوكول أوضح بالفعل حدود ما يتم إرجاعه عند عدم استخدام الغاز وما يتم تحصيله عند استهلاكه. ما يحتاجه المنتج هو ترجمة هذه الحدود إلى لغة يفهمها الناس. @Dusk إذا كان بإمكانها عرض كلًا من gas limit والإنفاق الفعلي وسبب الفشل معًا داخل سجل الفشل، فستقل طبقة واحدة من سوء الفهم حول شرط الاستخدام الخاص بـ $DUSK . #dusk
عندما فتحت صفحة Tokenomics الخاصة بـ Dusk، رأيت قاعدة سهلة جدًا أن تُفوّت: إذا استُهلك الغاز بالكامل في عملية ما، فسيتم التراجع (Rollback)، لكن الغاز الذي تم استهلاكه بالفعل لن يُعفى منه—يتم تحصيل رسومه مع ذلك. كلمة “فشل” التي يتكلم بها المستخدمون قد تعني على السلسلة واحدًا من نتيجتين على الأقل.
حد الغاز (Gas limit) يحدد أقصى قدر من العمل يمكن لهذه الاستدعاء القيام به، وسعر الغاز (Gas price) هو ثمن كل وحدة من العمل. تُحسب التكلفة بناءً على الاستهلاك الفعلي؛ وما لم يُستخدم لا يُخصم. هذه القواعد بحد ذاتها ليست مشكلة. المشكلة أن المحفظة غالبًا ما تعطيك فقط عبارة واحدة بخلفية حمراء ونص أبيض: “Failed”.
سابقًا كنت بالتأكيد ألوم المستخدمين لأنهم لم يتركوا رسومًا كافية. الآن وقد عدت أنظر من جديد، هل المنتج يشرح سبب الفشل بوضوح؟ هذا هو ما يحدد مباشرة ما إذا كان المستخدم سيتحمّس لمحاولة ثانية أم لا. هل السبب أن حجم العمل غير كافٍ؟ أم مشكلة صلاحيات؟ أم معطيات (Parameters) خاطئة؟ أم حالة الشبكة؟ طريقة التعامل تختلف تمامًا.
لنضرب مثالًا على ذلك. شخص استخدم كمية صغيرة من DUSK لتشغيل عقد (Contract)، لكنه وضع Gas limit منخفضًا جدًا. فشلت المعاملة: نقص الرصيد حصل، لكن حالة السلسلة لم تتغير. ثم حاول مرة أخرى ودفع رسومًا إضافية. إذا كانت الجذور في كتابة المعلمات بشكل خاطئ، فستستمر الرسوم في الاحتراق في كل مرة.
لذلك لا أرى أن آلية غاز Dusk يمكن اختزالها ببساطة إلى “حتى الفشل يجب أن يُحسب عليه رسوم”. البروتوكول أوضح بالفعل حدود ما يتم إرجاعه عند عدم استخدام الغاز وما يتم تحصيله عند استهلاكه. ما يحتاجه المنتج هو ترجمة هذه الحدود إلى لغة يفهمها الناس. @Dusk إذا كان بإمكانها عرض كلًا من gas limit والإنفاق الفعلي وسبب الفشل معًا داخل سجل الفشل، فستقل طبقة واحدة من سوء الفهم حول شرط الاستخدام الخاص بـ $DUSK . #dusk
