لماذا يحتاج محرك السياسات إلى خمس خطوات منفصلة فقط ليقول "نعم" أو "لا" للمعاملة؟
هذا هو السؤال الحقيقي وراء دورة تقييم نيوتن.

كيف يتم إنشاء السياسة أصلًا؟

يقوم أحد المطورين بكتابة المنطق بلغة Rego، ثم ينشره في سجل نيوتن، ويتم تخزينه على IPFS، مع الإشارة إليه عبر CID. وهذا يعني أن كل سياسة قابلة للتحقق وإعادة الاستخدام، وليست صندوقًا أسود مدفونًا داخل عقد.

من يقرر أي سياسة تنطبق على معاملة؟

المستخدم يفعل ذلك. فهو ينشر عقد PolicyClient، ويختار سياسة، ويحدد بنفسه حدودًا (thresholds) وقواعد انتهاء الصلاحية. ومن وجهة نظري، فإن هذه هي الجزء الأقل تقديرًا: إذ تعيد التحكم إلى المستخدم بدلًا من جعله بيد بوابة مركزية.

ماذا يحدث عند إرسال مهمة؟

يُقترن Intent بـ PolicyClient ويصل إلى بوابة #Newt عبر SDK أو RPC. يبدو الأمر بسيطًا على السطح، لكنه نقطة التشغيل التي يبدأ عندها كل ما يأتي لاحقًا.

من الذي يتحقق فعليًا مما إذا كانت المعاملة صالحة؟

يقوم مشغلو AVS بتقييم السياسة بشكل مستقل وإصدار توقيعات BLS. وعندما يتم الوصول إلى النصاب (quorum)، يقوم Aggregator بتجميعها في إقرار/إثبات واحد (attestation). ومن وجهة نظري، فهذا هو أقوى اختيار تصميمي في كامل سير العمل: لا يستطيع أي مشغل واحد الموافقة أو الحظر بشكل منفرد. $NEWT

إذًا ما الخلاصة؟

@NewtonProtocol ليس مجرد إضافة خطوة موافقة أخرى للمعاملات، بل هو لا مركزية الحكم نفسه. هذه هي النقلة الحقيقية التي يستحق الانتباه إليها.
$ARX $LAB #NewtonProtocol #NEWTtoken #NEWTUSDT
📊 ما الأهم قبل أن تمر المعاملة عبر ذلك؟