مع استمرار صناديق التمويل اللامركزي (DeFi) في إدارة كميات متزايدة من رأس المال، لم يعد من الممكن أن تعتمد الأمان وحده على القائمين الموثوقين أو على أذونات العقود الذكية الثابتة. يجب التحقق من كل إجراء حساس داخل الصندوق مقابل المخاطر الديناميكية والسياسات التنظيمية والتشغيلية قبل التنفيذ. يقدّم Newton VaultKit هذه القدرة بالضبط من خلال إضافة طبقة إنفاذ سياسات لا مركزية إلى سير العمل الحالي للصناديق.
على عكس عمليات التكامل التقليدية التي تتطلب من المطورين إعادة تصميم البنية التحتية لديهم، يعمل VaultKit جنبًا إلى جنب مع مجموعات تطوير الصناديق (SDKs) التي يستخدمونها بالفعل. تواصل التطبيقات إعداد إجراءات الصندوق بالطريقة المعتادة، لكن بدلًا من إرسالها مباشرةً إلى الصندوق، يتم توجيه التنفيذ عبر عقد Shield الذي يتطلب شهادة Newton صالحة قبل أن يمكن لأي إجراء أن يمضي قدمًا.
تبدأ عملية البدء مع VaultKit بتثبيت حزمة SDK الأساسية، ومكتبات حزم السياسات، وأي SDKs خاصة بالبروتوكول من جهات مزوّدة مثل Morpho. بعد ذلك يقوم المطورون بإنشاء عملاء Viem العامة وعملاء المحافظ (wallet clients)، والتي تُمكّن VaultKit من قراءة حالة البلوكشين وإرسال المعاملات بشكل آمن.
الخطوة التالية هي بناء حزمة سياسات. تحدد حزم السياسات القواعد التي سيقوم مُشغلو Newton بتقييمها أثناء عملية التفويض. يمكن لمحفظة (Vault) دمج عدة وحدات، بما في ذلك Vaults.fyi لمراقبة صحة الـvault، وChainalysis لفحص العقوبات، وRedStone للتحقق من الـoracle، وWebacy للحماية من فقدان الارتباط (depeg). يتيح هذا التصميم المعياري للمشاريع صياغة سياسات أمنية وفقًا لاحتياجاتها الخاصة بدلًا من الاعتماد على نهج واحد يناسب الجميع.
بعد تحديد حزمة السياسات، يقوم المطورون بإنشاء Shield باستخدام createShield(). يعمل الـShield كطبقة تنفيذ آمنة بين المُشرف (curator) والـvault. وبما أن نشر Shield حتمي، يقوم VaultKit تلقائيًا بإرفاقه بـ Shield متوافق موجود مسبقًا إن كان موجودًا بالفعل، أو ينشر Shield جديدًا فقط عند الحاجة. وهذا يبسط عملية النشر مع منع تكرار البنية التحتية.
بمجرد جاهزية الـShield، يمكن تهيئة معلمات السياسات على السلسلة باستخدام قيم مُعنونة مثل درجات المخاطر الدنيا، وحدود انحراف APY، وحدود سحب TVL، واكتشاف تغييرات التخصيص، وفحوصات التحذير الحرجة. تُشفّر بيانات اعتماد واجهات البرمجة الحساسة (API)، بما في ذلك مفاتيح Vaults.fyi، قبل رفعها عبر Newton Gateway. يمكن للمشغّلين الوصول إلى هذه الأسرار بشكل آمن أثناء تقييم السياسات دون كشفها على السلسلة أبدًا.
قبل تنفيذ إجراءات الـvault، يجب أن يستلم الـShield الصلاحيات المطلوبة. يتم تفويض المندوبين المعتمدين صراحةً لإرسال المعاملات، بينما تُسند أدوار المدير الخاصة بالبروتوكول—مثل أذونات مُخصّص MetaMorpho—إلى الـShield نفسه. يضمن ذلك أن كل إجراء ذي صلاحيات يمر عبر عملية التحقق من السياسات الخاصة بـ Newton.
إن تنفيذ عملية على الـvault يتم بقصد تبسيطه. على سبيل المثال، تستخدم تكاملات Morpho الدالة typed shield.morpho.reallocate(). خلف الكواليس، يقوم VaultKit ببناء نية المعاملة، واستخراج مدخلات السياسات، وطلب تقييم لامركزي من مُشغلي Newton، واستلام إثبات تحقق تشفيري، ثم أخيرًا إرسال المعاملة عبر الـShield. إذا فشلت أي قاعدة من قواعد السياسات، يتوقف التنفيذ قبل أن تصل المعاملة أبدًا إلى الـvault.
يوفر VaultKit أيضًا معالجة شاملة للأخطاء. يمكن للمطورين التمييز بين حالات رفض السياسات، ومشكلات بوابة مؤقتة، وانتهاءات مهلة التحقق. يتيح ذلك للتطبيقات إعادة المحاولة بأمان عند الاقتضاء، مع رفض الإجراءات التي تنتهك سياسات مُعدة فورًا.
يعزز هذا التصميم بشكل كبير أمن DeFi. بدلًا من الاعتماد فقط على مُشرفين موثوقين، يُدخل VaultKit إنفاذ سياسات لا مركزي يقوم بتقييم مستمر لصحة الـvault، ومتطلبات الامتثال، وسلامة الـoracle، والمخاطر التشغيلية قبل حدوث أي إجراءات حساسة. تحمل كل معاملة معتمدة دليلًا تشفيريًا يثبت أنها استوفت السياسات المُعدة، مما يحسن الشفافية لكل من المودعين والمؤسسات ومشغلي البروتوكول.
من خلال الجمع بين حزم سياسات قابلة لإعادة الاستخدام، ونشر Shield حتمي، وإدارة أسرار مشفّرة، والتحقق اللامركزي، يحوّل Newton VaultKit إدارة الـvault إلى عملية قابلة للتحقق والبرمجة وموجهة للأمن—دون الحاجة إلى إعادة تصميم بروتوكولات الـvault الحالية.
