#dusk $DUSK @Dusk وأثناء قراءة ملاحظات إصدار Boreas، توقفت عند تعديل صغير واحد: لم تعد DUSK تُسعِّر SHA-256 وKeccak والهاشات العامة كما لو أن كل مُدخل له نفس التكلفة.

تتشارك دالة طلب الاستعلام الخاصة بالهاش ذي 32 بايت والهاش متعدد الكيلوبايت في نفس المُضيف، لكنهما لا تفرضان عملاً متساوياً. يضيف Boreas تسعيراً قائماً على الحجم لتلك الثلاثة، بينما تتدرّج عملية التحقق من BLS متعدد التوقيعات حسب عدد المفاتيح. ولا تُوصف عملية التحقق من KZG ولا الاسترداد في secp256k1 على أنهما مُسعّران بحسب طول الإدخال. إن سؤال أي استعلام هو “الأغلى” دون تثبيت طول الإدخال وعدد المفاتيح هو سؤال شبه خاطئ.

المقارنة هنا بين تسعير ثابت لنداء الـ API وبين كلفة الحوسبة المفروضة على المُصدّقين. تحرّكت DUSK نحو الخيار الثاني.

لكن هناك تعقيداً. Boreas يدرك الفَرْق بين الإصدارات (fork-aware): يستمر التنفيذ التاريخي محافظاً على دلالات ما قبل الفَرْك، بينما تستقبل العقود الحالية الجدول الجديد. قد تحمل نفس قيمة الحوسبة غازات مختلفة بحسب سياق التنفيذ اللازم لإعادة التشغيل (replay)، وهذا أمر مزعج بالنسبة للمطوّرين الذين يتوقعون التكاليف.

بالنسبة لـ DUSK، ينبغي أن تؤدي دقة أفضل في حساب الغاز إلى تقليل أحمال العمل التشفيري المُسعّرة بأقل من قيمتها، وجعل التنفيذ أكثر اتساقاً عبر العقد. ولا يثبت أن انتقالات الحالة الناجحة أصبحت أرخص. ربما أصبحت مُسعّرة بشكل أكثر صدقاً، حتى عندما يرتفع الرقم.

ما زلت أنتظر بيانات القياس حسب فئة الإدخال (input bucket). لا تكون المحاسبة الحتمية مقنعة إلا عندما يرتبط الغاز المُحمّل فعلياً بعمل الـ CPU الحقيقي.
@Dusk #dusk #Dusk