قادة الفكر

المكدس الوكلي يتألف من أربع طبقات. معظم النشرات تفتقد ثلاثًا

mm
أضف Securities.io إلى مصادرك المفضلة على Google

الهوية، السمعة، التفويض، والدفع تحتاج إلى أن تكون على السلسلة. في العديد من النشرات الإنتاجية، لا يزال الأمر كذلك، وهذا مشكلة معمارية، ليست مجرد فكرة لاحقة للامتثال.

أقضي الكثير من الوقت في دراسة كيفية ربط نشرات الوكلاء الإنتاجية فعليًا، والنمط غالبًا ما يكون نفسه: النموذج قادر، وإطار التنسيق معقول، ومع ذلك لا يزال طبقة المصادقة مفتاح API مشترك لم يتغير منذ أشهر.

لم تواكب بنية الوكيل المستقل السرعة التي تتطور بها النماذج التي تعمل فوقها. يتكون المكدس الوكلي من أربعة مكونات يجب أن تكون أصلية على السلسلة: الهوية، السمعة، التفويض، والدفع. في معظم النشرات الإنتاجية التي أراها، لا يزال يتم إضافة هذه المكونات لاحقًا، إن وجدت أصلاً.

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

لماذا مفاتيح API المشتركة هي العنصر الأساسي الخاطئ

نموذج المصادقة الذي ترثه معظم نشرات الوكلاء من SaaS هو سر مشترك يُمرّر في رأس الطلب. يصدق الخدمة المستدعية لكنه لا يوضح شيئًا عن الوكيل المحدد الذي يجري الاتصال، أو ما يُسمح لهذا الوكيل بفعله، ولا يترك سجلاً يبقى بعد التدقيق بصيغة يمكن للمنظم فحصها. كل إجراء للوكيل يُنسب فقط إلى من يحمل المفتاح، مما يعني عمليًا أن الإسناد ينهار بمجرد وجود أكثر من وكيل أو أكثر من مشغل.

البديل هو التسوية القائمة على التوقيع لكل طلب. يُوقع كل طلب بمحفظة الوكيل الخاصة ويُستقر تشفيرًا عند نقطة الاستدعاء. هذا هو ما صُمم من أجله x402 ، حيث يتم التعامل مع المصادقة والدفع معًا. يمنح ذلك المؤسسات سجلًا يوضح أي محفظة قامت بالإجراء، ومتى قامت به، وما دفعته، وهو دفتر يمكنه الصمود أمام تدقيق المراجعين.

فجوة الهوية

ERC-8004 يحدد هوية على السلسلة للوكلاء غير الموثوقين: سجل يُسجَّل فيه الوكيل بمحفظة تحكم، ونقطة خدمة، وإشارة إلى نموذج. حاليًا، هذا الوكيل هو مجرد عملية غير شفافة تعمل داخل بنية البائع. تجعل إدخال السجل الوكيل فاعلًا من الدرجة الأولى على السلسلة بأصل يمكن التحقق منه — يمكن لعقد ذكي أو لوحة امتثال التحقق منه مباشرةً دون الاعتماد على وسيط.

طبقة السمعة تُبنى على هذا. إشارات التغذية الراجعة المكتوبة في سجل ERC-8004 غير قابلة للتغيير، ومؤرخة، ويمكن إسنادها. أي نظام يرغب في اتخاذ قرارات ثقة بشأن وكيل يمكنه قراءة ذلك السجل مباشرةً. على عكس درجة يديرها البائع أو تقييم على Discord، الثقة هنا هي خاصية للشبكة وليس لمن يتحكم في قاعدة البيانات.

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

مشكلة التفويض هي المكان الذي يختلف فيه التمويل المنظم عن كل شيء آخر

الهوية والسمعة تخبرانك بمن هو الوكيل وكيف تصرف. لا يحددان ما هو التفويض المسموح للوكيل بالقيام به. في العديد من حالات استخدام الوكلاء، يمكن لطبقات التحكم التطبيقية تغطية تلك الفجوة. بالنسبة للوكلاء الذين يعملون على أصول منظمة، يصبح سؤال التفويض سؤالًا قانونيًا. يجب أن يكون الجواب موجودًا بصيغة يمكن أن ترضى المنظم.

ERC-8226، معيار تفويض الوكيل المنظم (RAMS)، صُمم لسد هذه الفجوة. يعرّف RAMS طبقة تفويض الامتثال التي تقع بين هوية الوكيل وأطر الامتثال على مستوى الرموز. يمنح المبدأ المُتحقق من KYC للوكيل تفويضًا بنطاق محدد، واختصاص قضائي، وحدود قيمة، وتاريخ انتهاء. عمليًا، يعمل كوكالة قانونية على السلسلة يمكن التحقق منها قبل التسوية. ثم يتحقق عقد الرمز المنظم من هذا التفويض بشكل ذري داخل ربط الامتثال قبل النقل قبل أي تسوية.

هناك واجهتان تحملان التصميم. `ComplianceProvider` تُنفّذ من قبل أي مشغل KYC أو توثيق وتضمن أهلية المبدأ للنطاق المحدد. `IAgentMandate` هو السجل الذي يسجل المنح، والتمديدات، والإلغاءات، والتنفيذات، وتجميد المستويات حسب المنظم. يتم التنفيذ عبر `recordExecution`، الذي يتحقق من حدود التفويض النشط وقت النقل ويعيد العملية إذا كان المعاملة ستخترقها.

تقع هذه البنية بين هوية ERC-8004 وأطر امتثال الرموز مثل ERC-7943 بدلاً من استبدال أي منهما. الهوية تقول إن الوكيل موجود ويمكن التحقق منه؛ امتثال الرموز، أن المبدأ مؤهل لحيازة هذا الأصل المحدد. يضيف RAMS الجزء الذي لا يغطيه أي منهما: السلطة من هذا المبدأ، لهذا النطاق، ضمن هذه الحدود، حتى هذا التاريخ. طبقة التفويض القابلة للتنفيذ قانونيًا التي تعيش حاليًا فقط في ملفات PDF وجداول البيانات الخلفية تنتقل إلى السلسلة، حيث يمكن تنفيذها فعليًا وقت النقل.

الفصل بين التحضير والتنفيذ ليس احتكاكًا

قرار تصميم واحد يستحق دفاعًا مباشرًا: فصل تحضير المعاملة عن التوقيع والبث. يتم إهماله في العديد من الأنظمة التي تحاول جعل الوكلاء يشعرون بسلاسة أكبر.

الحدس هو دمج هذه الخطوات في خطوة واحدة لأنها تبدو أكثر كفاءة. لكن الفجوة بين التحضير والبث هي بالضبط المكان الذي ينتمي إليه الإشراف المؤسسي. هو المكان الذي يراجع فيه مسؤول الامتثال ما سيقوم به الوكيل قبل أن تتعرف السلسلة عليه، حيث يتحقق فحص تفويض RAMS من صحة الحمولة المُحضرة مقابل النطاق النشط، والحدود القيمية، والاختصاص القضائي قبل إنتاج أي توقيع، وحيث يوافق المدير المالي على إجراء خزانة قام الوكيل بإعداده لكنه لم يلتزم به بعد.

العديد من المؤسسات التي تنشر وكلاء مستقلين على نطاق كبير يعيدون بناء هذا الفصل في النهاية عندما يكتشفون أنه مفقود. بناءه كعنصر معماري متعمد بدلاً من تعديل لاحق يحمل النظام عبر مراجعته الأولى للامتثال.

ما يبدو عليه المكدس عندما يكون مكتملًا

عندما تكون جميع الطبقات الأربع موجودة، فإنها تتكامل بسلاسة. يثبت ERC-8004 هوية الوكيل وسمعته على السلسلة، ويضيف ERC-8226 طبقة التفويض التي تحدد ما يمكن لكل وكيل القيام به وعلى من behalf. x402 يتعامل مع التسوية، موقّعًا كل طلب بحيث يكون كل إجراء قابلًا للإسناد والتدقيق. تحت ذلك، تُطبق أطر الأصول المنظمة مثل ERC-7943 الامتثال وقت النقل ضد كل من أهلية المبدأ وتفويض الوكيل النشط.

هذه المكونات في مستويات نضج مختلفة، لكن لا أحد منها نظري بحت. ERC-8004 هو مسار معيار مسودة ERC مع هوية وسمعة قابلة للنشر. ERC-7943 هو معيار إيثيريوم نهائي. ERC-8226 على مسار المعايير، والواجهات الأساسية مستقرة بما يكفي للعمل على تنفيذ مبكر. x402 مباشر ومصمم بالفعل حول دفعات HTTP برمجية للبشر والوكلاء.

الفرق التي تنجح في ذلك يمكنها بناء هذا المكدس الآن أو الانتظار حتى يجبر ضغط التدقيق والامتثال على التعديل. المؤسسات التي تنجح في ذلك ستكون هي التي تعالج طبقات التفويض والهوية كمتطلبات بنية تحتية من اليوم الأول، بنفس الطريقة التي تعالج بها KYC والحفظ. قد لا يكون المنظمون قد طلبوا صراحة كل جزء منه بعد. الفرق التي تبني أنظمة إنتاجية في هذا المجال تعرف بالفعل كم هي تكلفة إضافة هذه الضوابط لاحقًا.

دافيدي بيتزو هو مهندس خلفية وذكاء اصطناعي في Brickken، مزود بنية تحتية لتوكنية المؤسسات يعمل في أكثر من 30 دولة. وهو مساهم في ERC-8226 (RAMS)، معيار تفويض الوكيل المنظم الموجود حالياً على مسار معايير إيثيريوم.