من الأمور التي أجدها مثيرة للاهتمام بشأن مسابقة TermMax الأمنية لشهر فبراير 2025 هو حجم النطاق الذي تم مراجعته: 5,816 سطرًا من التعليمات البرمجية (LOC).
بالنسبة إلى TermMax، وهو بروتوكول للاقتراض والإقراض بمعدل ثابت لا مركزي، يُعد هذا مقدارًا مهمًا من الكود لإخضاعه للمراجعة. لكن الرقم وحده لا يقول الكثير حول مدى تمركز “الوزن الأمني” فعليًا داخله.
لقد غطت تلك الأسطر الـ 5,816 أنواعًا مختلفة جدًا من منطق التشغيل، بما في ذلك منطق السوق والأوامر والراوتر والـ vault. عدّ الأسطر يعامل كل جزء بالتساوي. ومن الناحية الاقتصادية، لا تحمل بالضرورة هذه الأجزاء أوزانًا متساوية.
قد يتحكم جزء صغير من الكود في حركة الأموال أو الصلاحيات أو التسعير أو المحاسبة. وقد يكون لمكوّن أكبر بكثير تأثير مباشر أقل على الحالة الاقتصادية.
ما لا أعرفه بعد هو مقدار “سطح الأمان” الحقيقي لدى TermMax الذي كان مركزًا في جزء نسبيًا صغير من هذا النطاق الذي تمت مراجعته.
أقوى الدلائل ستكون وجود خريطة واضحة بين نطاق المراجعة وبين أعلى انتقالات الحالة عواقبًا لدى TermMax: المواضع التي قد تؤدي فيها أخطاء تنفيذ صغيرة إلى نتيجة اقتصادية كبيرة.
هذا يغيّر طريقة تفسير النطاق.
السؤال الأكثر فائدة ليس كم عدد الأسطر التي كانت داخل حدود التدقيق، بل مقدار السلطة الاقتصادية التي كانت تلك الأسطر التي تمت مراجعتها تتحكم فيها.
قد تكون مراجعة تضم 5,816 سطرًا واسعة من حيث حجم الكود دون أن تخبرني ما إذا كانت هذه السعة نفسها موجودة عبر الأجزاء من TermMax التي تكون فيها الأعطال أكثر أهمية.
السؤال هو: هل كانت مراجعة TermMax واسعة من حيث عدد الأسطر فقط، أم أيضًا واسعة عبر الأجزاء من النظام القادرة على تغيير الحالة الاقتصادية.
أنا أراقب كيف يربط TermMax تغطية الأمان بحركة الأموال الحرجة، والصلاحيات، والتسعير، والمحاسبة، والثوابت (invariants) التي تحميها.

@TermMax #TermMax
$PIEVERSE