كان لدي ثلاث حزم مفتوحة في محرر سياسة نيوتن، vaults.fyi وRedStone وChainalysis، للتحقق مما إذا كان يجب السماح بتنفيذ إجراء على أحد الفوّلات.
أرجعت vaults.fyi قيمة risk_score تساوي 0.72. وأرجعت RedStone قيمة divergence_bps تساوي 38. وأرجعت Chainalysis قيمة risk_score الخاصة بها، "low"، بالإضافة إلى علامة مُسَنَّدة مضبوطَة على false.
تستخدم اثنتان من تلك الردود الثلاثة الاسم الحقل نفسه تمامًا، risk_score، لشيئين مختلفين تمامًا. أحدهما تقييم رقمي لصحة الفوّلات. والآخر هو تصنيف فئوي للجزاءات. لا يوجد في أيٍّ من JSON الخاص بأي مزوّد ما يحذرك مسبقًا، لأن أيًّا من الفريقين لم يبنِ مخططه وهو على علم بوجود الفريق الآخر.
إذا قام دمجٌ ساذج فقط بكتابة الاستجابتين في كائن واحد، فإن الكتابة الثانية تفوز. تحصل Vaults.fyi على 0.72 ثم تُستبدل بصمت بـ "low". تستمر السياسة في العمل. لا خطأ، ولا تحذير، ولا نص أحمر في أي مكان. تبدأ بمقارنة حدٍّ مع قيمة لم تعد موجودة.
بحثت عن المكان الذي يتوقف عنده نيوتن فعلًا، لأن الأمر لا يبدو أنه متروكًا لمن يكتب ملف Rego كي ينتبه.
كل حزمة تُنشئ مساحة أسماء ناتجها تحت مُعرّف الحزمة الخاص بها قبل أن يحدث أي دمج. درجة المخاطر لدى Vaults.fyi موجودة في data.wasm.vaultsfyi.risk_score. أما لدى Chainalysis فهي في data.wasm.chainalysis.risk_score، وهو عنوان مختلف تمامًا، حتى مع أن اسم الحقل متطابق. قيمة التباعد لدى RedStone موجودة في data.wasm.redstone.divergence_bps. عند تشغيل Simulate على الثلاثة معًا مرة واحدة، أظهر لوح البيانات المدمجة بالضبط ذلك: ثلاث مسارات منفصلة، لا يلامس أيٌّ منها الآخر.
هذا ليس قاعدة تقول لمطوري البرمجيات أن يكونوا حذرين في التسمية. بل إن عملية الدمج نفسها ترفض السماح بحدوث التصادم، قبل أن يكتب مؤلف السياسة أي مقارنة على الإطلاق.
الذي ظلّ معي لم يكن الخلل الذي لم أصِبه. بل كان مدى عدم بريق الإصلاح فعليًا. لا أحد يروّج لأسماء مفاتيح JSON المُسماة. لكن هذا التفصيل المحدد هو ما يقف بين سياسة خزنة تمنع إجراءً خطِرًا بشكل صحيح، وبين سياسة توافق عليه بهدوء لأن مزوّرين غير مرتبطين بالصدفة اتفقا على كلمة واحدة.