أستمر في رؤية @NewtonProtocol مُوصوفة بأنها “أتمتة قابلة للتحقق” أو “عملاء ذكيون”، لكن بصراحة؟ الجزء الخاص بمحرك السياسات، وتحديدًا تكامل Rego، هو ما يجعل هذا المشروع يستحق الاهتمام به. #Newt
المشكلة هي أن معظم مشاريع الأتمتة تمنح المشغّلين تحكّمًا كبيرًا جدًا (أمرٌ محفوف بالمخاطر) أو تُقيّد كل شيء على السلسلة (مكلف جدًا). رهان نيوتن مختلف: إتاحة كتابة قواعد دقيقة التفاصيل بلغة تم استخدامها في التمويل التقليدي لسنوات، ثم فرض تطبيقها عبر أمان EigenLayer.
الجزء الممل (المهم): Rego
Rego هي لغة السياسات التي تشغّل Open Policy Agent (OPA). وقد تم اختبارها في الميدان في جهات مثل Goldman Sachs و Capital One من أجل منطق التفويض (authorization).
لقد نقلها Newton فقط… إلى السلسلة. نفس اللغة، مسارات جديدة (rails).
• لقد قاموا بتفريع Regorus (مفسّر Rego مبني على Rust) وأضافوا ملحقات تشفير للتحقق على السلسلة
• يتم تنفيذ تقييم السياسة خارج السلسلة (off-chain)، لكن يتم التحقق من الإثبات على السلسلة عبر Newton AVS
• هذا يعني أن منطق تفويض معاملةك يمكن أن يكون معقدًا كما تحتاج دون دفع غاز EVM لكل فحص شرط
ما الذي أحبّه حقًا: أنت لا تتعلّم لغة جديدة. إذا كنت قد كتبت سياسات OPA ل Kubernetes أو بوابات API، فيمكنك كتابة سياسات لـ Newton. هذا أكثر عملية من أغلب المقاربات التي تعتمد على التشفير بشكل مباشر.
كيف تعمل تدفّق السياسة (عمليًا)
إليك ما يحدث فعليًا عند استخدام هذا:
1. تكتب Policy في Rego تحدد حدود الصرف، وقوائم السماح (allowlists)، ونوافذ الوقت، أيًا كان ذلك
2. يتم تخزين السياسة على IPFS مع مرجع CID
3. يقوم المستخدمون بإرسال Intents (حقول معاملة EVM القياسية: from, to, value, calldata, chain_id)
4. يقوم مشغلو Newton بتقييم الـ Intent مقابل سياستك
5. يقومون بإنتاج توقيع تجميعي BLS (Attestation) إذا نجحت السياسة
6. يقوم عقدك الذكي بالتحقق من الإثبات قبل تنفيذ العملية
طريقتان للتحقق:
• _validateAttestation، تستخدم بحثًا في السجل، المزيد من الغاز لكن مع حل تلقائي للإعدادات
• _validateAttestation، غاز أقل مباشرةً لكن عليك أنت إدارة مراجع السياسات بنفسك
ماذا يتيح هذا بالفعل
ليس “وكلاء ذكاء اصطناعي” أو أي مصطلح رائج آخر. أشياء حقيقية وعملية:
• سياسات معاملات عبر السلاسل، سياسة واحدة تحكم النشاط عبر عدة سلاسل
• صلاحيات محدودة بالوقت، ومفتاح جلسة (session key) ينتهي بعد 24 ساعة أو X معاملات
• صرف مشروط، وافق على المعاملة فقط إذا كان سعر الرمز > حد معين (عبر أوراكلز PolicyData)
• سياج امتثال، فحوصات قائمة العقوبات قبل أي تحويل
الفصل بين data.params (مجموعة إعدادات يحددها مالك العقد) و data.wasm (بيانات وقت التشغيل القادمة من الأوراكلز) ذكي فعلًا؛ فهو يسمح بتحديث حدود الصرف دون تغيير منطق السياسة الأساسي.
ما الذي يجعلني متشككًا قليلًا
اقتصاديات المشغّلين. يحتاج Newton إلى وجود عدد كافٍ من المشغّلين يعملون على AVS لتحقيق نصاب (quorum) ذي معنى. إذا كان عدد المشغّلين صغيرًا، فإن جزء “اللامركزية” يشعر بأنه رقيق. من المفترض أن نموذج الرهن dPoS مع $NEWT يحل هذه المشكلة، لكن ذلك يعمل فقط إذا كان الرمز يمتلك فائدة حقيقية تتجاوز المضاربة.
اعتماد على بيانات في الوقت الحقيقي. بعض السياسات تعتمد على بيانات خارج السلسلة عبر WASM أوراكلز. إذا كانت هذه الأوراكلز بطيئة أو فشلت، يتوقف تقييم معاملتك. تتعامل معمارية Newton مع ذلك، لكن يبقى نقطة فشل محتملة لا تملكها منطقية السلسلة الخالصة.
منحنى تعلم Rego. نعم، إنها معيارية، لكنها ما زالت لغة متخصصة. سيحتاج معظم المطورين إلى الارتقاء بمستواهم في صيغة Rego وملحقات Newton المحددة.
ما الذي سأتحقق منه قبل استخدامه
• حالة التدقيق: هل تمت مراجعة منطق تقييم السياسة ومسار التحقق من العقد؟
• عدد المشغّلين: كم عدد المشغّلين النشطين؟ وما عتبة النصاب؟
• شروط الـ Slashing، ماذا يحدث إذا أساء المشغّلون السلوك؟ وكيف يتم اكتشاف ذلك؟
• تكاليف الغاز، ما مقدار ما تضيفه فعليًا عملية التحقق من الإثبات على السلسلة إلى كل معاملة؟
• موثوقية PolicyData، من يشغّل الأوراكلز، وما ضمان وقت تشغيلها (الـ uptime)؟
الخلاصة
لا يحاول Newton إعادة اختراع “الأتمتة”. هو يحل مشكلة محددة: كيف تفوّض المعاملات المعقدة دون الوثوق ببوت مركزي أو دفع غاز بمستوى EVM لكل شرط؟ توليفة Rego + AVS إجابة منطقية، حتى لو كانت تفاصيل التنفيذ لا تزال بحاجة لأن تتضح. التقنية موجودة. السؤال المفتوح هو تأثيرات الشبكة (network effects).