منذ الأيام الأولى لسلاسل الكتل العامة التي سعت جميعها إلى كسر عنق زجاجة TPS، وصولًا إلى مختلف شبكات الطبقة الثانية التي تواصل ضغط تكاليف الغاز وتقليص زمن تأكيد الكتل، فإن كل الخطابات التقنية في الصناعة بُنيت على توافق واحد، وهو تقليل العوائق أمام تنفيذ المعاملات قدر الإمكان، بحيث يمكن لكل تحويل أو تفاعل مع عقد يقوم به المستخدم أن يكتمل بسلاسة. وبصفتي شخصيًا قضيت وقتًا طويلًا في مجال تطبيق تقنية البلوك تشين على مستوى الشركات (To B)، فقد شهدت بنفسي حيرة العديد من العملاء المؤسسين عند دخول Web3؛ إذ إن المؤسسات المالية التقليدية راكمت على مدى عقود قواعد إدارة المخاطر وإجراءات القبول، لكنها تجد صعوبة في نقلها إلى الشبكات اللامركزية. في الغالب، لا يستطيع معظم DApp سوى تطبيق بعض إجراءات إدارة المخاطر بشكل متفرق على مستوى التطبيق، ولا يمكنها تحقيق إعادة استخدام القواعد عبر سيناريوهات متعددة، كما أنها لا تلبي المتطلبات الصارمة التي تفرضها الجهات الرقابية فيما يتعلق بالتتبع الكامل عبر السلسلة وإمكانية التدقيق. وهذه هي أيضًا العقدة الأساسية التي تجعل كثيرًا من الأموال التقليدية تتردد طويلًا في احتضان التمويل على السلسلة على نطاق واسع.
عند تعاملي الأول @NewtonProtocol مع مبدأ تصميم Authorization الذي كان يجري التأكيد عليه باستمرار، لم أكن متحمسًا لتطبيق الخبرات الراسخة في إدارة المخاطر لدى الواجهة الأمامية كما هي لتفسير الأمر. بدلًا من ذلك، أعدت التفكير والتخطيط مرارًا وتكرارًا بالاستناد إلى احتياجات الامتثال الواقعية لدى الجانب المؤسسي. فإذا كان هدف المشروع هو فقط اعتراض العناوين عالية الخطورة والتحويلات المالية الكبيرة غير الاعتيادية قبل بدء المعاملة، فإن الحلول الناضجة مثل إضافات المحافظ ومفاتيح التحقق في واجهات الخلفية يمكن تنفيذها بتكلفة منخفضة تمامًا، ولا يتطلب الأمر استثمار موارد تطوير كبيرة لإنشاء طبقة جديدة تمامًا من بنية بروتوكول أساسية. وهذا يعني أن النية الأصلية وراء تصميم آلية التفويض لم تكن أبدًا لحل مشكلة مخاطر المعاملات في سيناريو منفرد، بل كانت محاولة لإعادة تشكيل الحامل الأساسي لحوكمة القواعد داخل النظام اللامركزي بأكمله.
في شبكات الـ DeFi التقليدية، يتم تثبيت حدود تشغيل النظام بواسطة آلة حالة مُضمنة مسبقًا داخل العقود؛ وبمجرد نشر القواعد على السلسلة، يصبح تعديلها بشكل مرن أمرًا صعبًا. لا يمكن لقيود المخاطر كلها أن تحدث إلا أثناء تنفيذ المعاملة. فإذا تمكنت معاملة خبيثة من اجتياز مرحلة التنفيذ داخل العقد، فإن عمليات وقف الخسارة اللاحقة غالبًا ما تتأخر وتكون باهظة التكلفة.#newton قلبت هذه المنطق رأسًا على عقب بالكامل: إذ تم ضبط التحقق من التفويض ليكون إجراءً إلزاميًا مسبقًا لكل تفاعل على السلسلة. تصبح عملية تنفيذ المعاملة مجرد خطوة ختامية لسلسلة العمل بأكملها. لم تعد حدود القيود مُحكمة داخل كود العقد، بل تُعرَّف عبر قواعد قبول يمكن كتابتها بشكل مرن ونشرها بشكل موحد على مستوى الشبكة. ترتيب الخطوات يبدو تغييره بسيطًا في الظاهر، لكن جوهر الأمر هو نقل صلاحيات الحوكمة من مطوري العقود إلى واضعي القواعد. كما يوفر ذلك أدوات حوكمة معيارية للجهات التنظيمية والمؤسسات وأطراف المشاريع.
في الوقت الراهن، يتقدم قطاع التشفير تدريجيًا من عصر المضاربين الأفراد إلى عصر الامتثال المؤسسي. لقد وصلت عوائد التفوق في الأداء عبر المنافسة محليًا بالفعل إلى سقف مرحلي. والفجوة في قدرات معالجة المعاملات بين سلاسل عامة مختلفة تتقلص باستمرار. والمنافسة في المستقبل لن تدور إلا حول مدى قوة منافسة قدرات الحوكمة عبر القواعد. من يستطيع توفير مجموعة من البنية التحتية العامة للدخول في المعاملات، قابلة للتدقيق وعالية المرونة، يمكنه أن يستوعب حجم الطلب الهائل لنقل التحول الرقمي للتمويل التقليدي إلى السلسلة. يقوم Newton بتثبيت آلية التفويض باعتبارها نواة البروتوكول في الأساس؛ وجوهر ذلك هو أنه يحدد مسبقًا مسار البنية التحتية الأكثر ندرة في موجة امتثال Web3. وحتى إذا انتشرت مستقبلاً على نطاق واسع وكلاء الذكاء الاصطناعي والعمليات الآلية للمعاملات على السلسلة، ستظل مختلف أشكال السلوك المالي البرمجي بحاجة إلى معايير موحدة للحكم على القبول لتجنب المخاطر النظامية. كما سيتطور نظام التفويض تدريجيًا من وظيفة وحيدة للرقابة على المخاطر إلى بوابة عامة للتدفق والحوكمة في نظام التمويل اللامركزي الجيل القادم.$NEWT #newt
