ماذا لو كانت معاملة ما تستطيع أن تُثبت أنها استوفت قواعدك قبل أن تلمسها العقود الذكية؟
@NewtonProtocol يواصل طرح فكرة أن التفويض يجب أن يحدث قبل التنفيذ، وليس بعده. يبدو ذلك بسيطًا، لكنه يغيّر مكان وضع المطوّرين للثقة. بدلًا من وضع كل شرط مباشرة داخل عقد، يتيح Newton لسياسة أن تقرر ما إذا كانت المعاملة تستحق أن تمضي قدمًا.
التوتر العملي $UP
معظم العقود الذكية تكون ثابتة بمجرد نشرها.
قواعد العمل ليست كذلك.
حدّ الإنفاق يتغير. يتغير متطلب الامتثال. تتغير حالة المحفظة. إن تحديث Solidity في كل مرة أمر بطيء ومكلف. يتعامل نهج Newton مع ذلك بشكل مختلف عبر فصل قواعد المعاملة عن منطق العقد.
ما الذي يلفت الانتباه
•حقيقة: يقيم نيوتن نوايا المعاملات قبل التنفيذ عبر سير عمل للسياسة بدلًا من التحقق من كل شيء داخل Solidity.
•حقيقة: يمكن للسياسات استخدام معلومات خارجية يتم تزويدها عبر أوراكل بيانات WebAssembly (WASM) قبل اتخاذ القرار.
•حقيقة: يُرجع المشغّلون شهادات تشفيرية، يتم التحقق منها بواسطة PolicyClient على السلسلة قبل التنفيذ.
•رأي: الجزء المثير للاهتمام ليس لغة السياسة. بل تقليل عدد الأسباب التي تستدعي إعادة نشر عقد ما عندما تتطور قواعد العمل.
ملاحظة واحدة أعود إليها باستمرار
#Newt لا يحاول جعل العقود أكثر تعقيدًا.
إنه يحاول جعلها أقل مسؤولية.
يتحقق العقد في الأساس من شهادة. لقد تم تقييم القرار نفسه بالفعل في مكان آخر وفقًا لقواعد محددة مسبقًا.
وهذا يخلق فصلًا أنظف بين التنفيذ والتفويض.
ما إذا كان ذلك يصبح ميزة يعتمد على التطبيق.
الأرقام التي تستحق الانتباه
•حوالي 30 دقيقة لبناء أوراكل بيانات WASM.
•حوالي 20 دقيقة لكتابة سياسة Rego.
•حوالي 15 دقيقة للنشر عبر واجهة CLI.
•حوالي 30 دقيقة لكل من تكامل عقد ذكي وتكامل واجهة SDK للواجهة الأمامية.
هذه تقديرات للتوثيق وليست ضمانات. عادةً ما تستغرق المشاريع الحقيقية وقتًا أطول حسب اختبارات الأمان ومراجعاته.
الاستنتاج/الخلاصة
•يسمح نيوتن للمطورين بنشر السياسات بشكل منفصل عن العقود.
•يدعم نيوتن إدخالات بيانات خارجية أثناء تقييم السياسة.
•يتحقق نيوتن من الشهادات الموقعة بـ BLS على السلسلة قبل التنفيذ.
•نشر سياسة الشبكة الرئيسية (Mainnet) يتطلب السماح المسبق (allowlisting) بدلًا من النشر غير المقيد تمامًا.
تشير هذه التفاصيل إلى أن نيوتن يتوقع اعتبار بنية التفويض بنيةً حرجة للإنتاج وليس ميزة اختيارية.
أين أجد أن نيوتن يصبح مثيرًا للاهتمام
تخيل خزينة بحد تحويل يومي.
غدًا يقرر المجلس أن يتغير الحد.
بدون نيوتن، قد يقوم المطورون بإعادة نشر العقود أو إضافة تعقيد في الحوكمة.
مع نيوتن، تتغير السياسة بينما يبقى عقد التنفيذ نفسه.
هذا لا يزيل الحوكمة.
يغير مكان حدوث الحوكمة.
فرق بسيط.
قد يكون ذا معنى.
ما سأتحقق منه قبل البناء على نيوتن
•من أين تأتي البيانات الخارجية فعليًا؟
•من يشغّل مصدر البيانات؟
•كم مرة يتم تحديث هذه المعلومات؟
•هل يمكن أن تتغير منطق السياسة دون التأثير على الافتراضات الحالية؟
•من يتحكم في ترقيات السياسة؟
•هل من السهل تدقيق الشهادات بشكل مستقل؟
•هل حصلت أداة PolicyClient على تدقيقات أمنية؟
•ماذا يحدث إذا أصبح تقييم السياسة غير متاح مؤقتًا؟
هذه الأسئلة مهمة أكثر من مدى شعور SDK بأنه مريح.
مخاطر تستحق إبقائها في الاعتبار
•خطر العقد الذكي: حتى إذا تحقق نيوتن من الشهادات بشكل صحيح، لا يزال بإمكان عقود التطبيق أن تحتوي على أخطاء تنفيذ/تنفيذ برمجي.
•خطر الاعتماد على طرف خارجي: قرارات السياسة تعتمد على التقييم خارج السلسلة وتوفر البيانات. إذا تعطل دعم البنية التحتية، فقد يتأخر تفويض المعاملة.
•خطر تشغيلي: تصبح الحوكمة المتعلقة بتحديثات السياسة افتراضًا أمنيًا مهمًا.
•تقديرات التوثيق: أزمنة التكامل أرقام مرجعية وليست جداول زمنية للإنتاج.
التصاميم المتوازنة نادرًا ما تلغي المخاطر.
عادةً ينقلها إلى مكان آخر.
خلاصي $ARX
$NEWT يشبه أقل مجموعة أدوات عقد ذكي أخرى، وأكثر محاولة لفصل من يقرر عن من ينفذ. قد يبسّط هذا الفصل بعض التطبيقات بينما يضيف افتراضات تشغيلية جديدة. ما إذا كانت هذه المقايضة مجدية على الأرجح يعتمد أقل على نيوتن نفسه وأكثر على مقدار توقع أن قواعد التفويض في مشروعك ستتغير بعد النشر. هذه هي الجزء الذي سأستمر في مراقبته.