في مرة من المرات غيّرتُ رقم هاتفي، طلبت مني إحدى البنوك التحقق عبر سؤال أمني. أجبتُ بشكل صحيح تمامًا لكنهم مع ذلك رفضوني، لأن النظام يطابق مع البيانات المُدخلة قبل عشر سنوات؛ في ذلك الوقت أخطأتُ في تهجئة حرف واحد دون أن أتذكر. صحيح من حيث المضمون، لكن خاطئ من حيث التنسيق، والنظام لا يميّز بين نوعي الخطأ هذين.
وكذلك الحال في الـDeFi؛ توجد أخطاء من نفس النوع تمامًا — اختلاف عنوان محفظة مكتوب بالأحرف الكبيرة والصغيرة، أو رقم تم التقريب يختلف عن رقم عشري غير مُقرب، قد يجعل الشرط صحيحًا من حيث الجوهر لكنه يُعتبر غير مطابق فقط لأن المطابقة تتم على سلسلة الأحرف حرفيًا، بدل فهم المعنى.
@NewtonProtocol إذا بُنيت سياسة (policy engine) تفهم معنى الشرط بدل الاقتصار على المطابقة الجامدة، فستُقلَّل كثير من حالات الرفض الظالم من هذا النوع.
مراجعة ذاتية: لكن كلما جعلنا النظام “أكثر مرونة في فهم المعنى”، احتجنا إلى طبقات أكثر من تعقيم/توحيد البيانات المعقدة، وكل طبقة إضافية تصبح أيضًا موضعًا قد يولد أخطاء جديدة. التوحيد الزائد قد يجعل قيمتين مختلفتين فعليًا تُعامل على أنهما متشابهتان، مُنتجًا مخاطرة عكسية بل وخطيرة: قبول الخطأ لأننا ظنناه صوابًا.
الجزء الصعب في @NewtonProtocol ليس هو جعل النظام أكثر ذكاءً، بل إيجاد حد المرونة المناسب: أن يكون كافيًا لعدم رفض حالات الاختلافات غير المؤذية في التنسيق، دون أن يُطمِس أيضًا الفروق الحقيقية المهمة.
$NEWT ينبغي تقييمه عبر معرفة أين يقع ذلك الحد، وليس فقط عبر ما إذا كان يتم تطبيق تقنية لفهم اللغة/المعنى أم لا.

#newt $LAB $SAROS