فخ الثقة في البروتوكولات المفتوحة: لماذا يحتاج x402 إلى طبقة مسؤولية مركزية؟

كشف بروتوكول الدفع x402 عن 31 ثغرة جديدة، مما يعرض 99% من المعاملات لخطر سرقة الأصول.

كتابة: @Jun__Yoo

ترجمة: AididiaoJP، Foresight News

نشر أكيبا (@akibablade) من CryptoSlate مؤخرًا مقالًا بعنوان "31 ثغرة جديدة تعرض 99% من مدفوعات x402 المشفرة لخطر سرقة الأصول والتسوق المجاني".

يعتمد هذا المقال على ورقة بحثية بعنوان "عندما يلتقي HTTP 402 مع البلوكشين: مخاطر الدفع الناشئة x402". تم قبول هذه الورقة وستُنشر في مؤتمر USENIX Security 2026.

تدرس الورقة كيف يقوم x402 بتفويض التحقق من إثبات الدفع والتسوية على السلسلة إلى طرف ثالث يسمى facilitator (مساعد الدفع). هذه التصميم يركز الثقة ومنطق التحقق في بنية تحتية للدفع مشتركة بين عدة تجار مستقلين. بمجرد ظهور ثغرة في أي مساعد، قد يؤثر ذلك على العديد من الخدمات.

كما عرّف الباحثون ثماني قواعد أمان يجب على المساعدين الالتزام بها. انتهاك هذه القواعد يمكن أن يؤدي إلى أربعة أنواع من الهجمات: التسوق المجاني، سرقة الأصول، رفض الخدمة، وإساءة استخدام الغاز. قاموا بتقييم 15 مساعدًا رئيسيًا، واكتشفوا 49 انتهاكًا للقواعد و31 ثغرة غير معروفة سابقًا. تم الكشف عن النتائج للجهات المعنية بشكل خاص. تم إصلاح بعض المشكلات، بينما لا تزال أعمال الإصلاح الأخرى جارية.

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

لا يمكن أن تلغي المصادر المفتوحة الثغرات، لكنها توفر مسارًا لتحويل العيوب المكتشفة خارجيًا إلى معايير أمان مشتركة. تم تسليم بروتوكول x402 إلى مؤسسة Linux في 2 أبريل، وبدأت مؤسسة x402 عملياتها رسميًا في 14 يوليو، مع 40 عضوًا. وهذا يوفر منتدى رسمي لمناقشة النتائج المكتشفة على مستوى المواصفات والتنفيذ المرجعي، بدلاً من الاقتصار على تصحيحات مورد واحد.

كما نشر الباحثون إصدارًا علنيًا من x402scope، تمت إزالة كود الاستغلال الحساس منه. وهم يتناقشون مع Coinbase وغيرها من المشاركين الرئيسيين في النظام البيئي حول كيفية دمج فحص القواعد في عملية التحقق قبل التطوير والنشر.

تتوقف مناقشة نضج البروتوكول هنا. أود أن أطرح سؤالًا أساسيًا آخر من هذه الاكتشافات.

بدلاً من مركزية x402 نفسها، هل يحتاج البروتوكول المفتوح إلى طبقة مسؤولية مركزية لفرض معايير التحقق وتحمل تكاليف التسوية والخسائر الناتجة عن الحوادث الأمنية؟

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

لنلقِ نظرة على كيفية عمل x402 فعليًا. يمكن لأي شخص تشغيل خادم أو أن يصبح مساعدًا. لكن النظام ليس خاليًا تمامًا من الثقة. كما عرفت الورقة المساعد بأنه "وسيط يتحمل الثقة". بمجرد تفويض التحقق والتسوية، يجب على المستخدمين وضع قدر كبير من الثقة في المساعد.

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

أولاً، التحقق (verify) يبدو أكثر كأنه يتنبأ "بأن التسوية لا تزال ممكنة في هذه اللحظة"، بدلاً من كونه مثل تفويض بطاقة الائتمان. إنه يتحقق من التوقيع، الرصيد، nonce ووقت انتهاء الصلاحية، لكنه لا يقفل الأموال ولا يستهلك nonce.

ثانيًا، فصل verify → منطق الأعمال → settle (التسوية) كان الهدف منه حماية المستهلكين والتجار. البروتوكول لا يحتوي على آلية لربط التحقق والتسوية من خلال حالة مشتركة. إذا اتخذ التاجر إجراءً بناءً على نتيجة تحقق المساعد، وفشلت التسوية اللاحقة، سيتعين على التاجر تحمل جميع الخسائر.

ثالثًا، العديد من المساعدين سيتكفلون بتكاليف التسوية على السلسلة. يمكن للمهاجمين التلاعب بمسار التنفيذ، مما يجعل المساعد يدفع تكاليف الغاز الناتجة. على Solana، قد يتمكن المهاجم حتى من إغراء المساعد لدفع الإيجار لحساب يسيطر عليه المهاجم.

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

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

تتحمل الشبكات من خلال رأس المال وإدارة المخاطر للجهة المصدرة للبطاقة هذه التكلفة الثقة، ثم تستردها من خلال الرسوم. أزال x402 تلك الدور، لكنه لم يزل التكلفة.

لذا، هل تحتاج المسار الفعلي إلى إنشاء طبقة مسؤولية فوق البروتوكول المفتوح؟

المركزية هنا لا تعني تسليم البروتوكول x402 بالكامل إلى جهة تشغيل واحدة. يجب أن يكون لكل مسار دفع جهة مسؤولة واضحة. لا يزال بإمكان عدة مشغلين التنافس تحت نفس المعايير المفتوحة، ويمكن للمستخدمين أيضًا تبديل المساعدين. هذه الهيكلية تركز المسؤولية التشغيلية، بينما تحتفظ بفتح البروتوكول وتنافس الموردين.

بوابة Monetization من Cloudflare هي مثال محتمل. إنها تحتفظ بتنسيق الدفع القابل للبرمجة لـ x402، بينما تتعامل في طبقة تحكم واحدة مع استراتيجيات الدفع، والتحقق، والتحكم في الوصول. مسار آخر هو استخدام مساعدين متخصصين، يقدمون اتفاقيات مستوى الخدمة، وحدود الغاز، والتحقق قبل التسوية واستجابة الأحداث.

يبدو أن ERC-8004 ونظام السمعة يوفران بدائل. لكن السمعة هي مجرد إشارة إضافية لتقييم المخاطر، فهي لا تحتفظ بالأموال ولا توفر ضمانات الدفع. أعتقد أن السمعة وحدها لا يمكن أن تسد فجوة المسؤولية.

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

استراتيجية التكامل لـ CDP (@CoinbaseDev) تجمع بين Agentic Wallet وCDP Facilitator وBazaar، وتوفر في كومة تقنية واحدة ميزات المحفظة والدفع والامتثال والاكتشاف.

استراتيجية التكامل لـ Orthogonal (@orthogonal_sh) تجمع بين اكتشاف الخدمات، ومجموعة مفاتيح API، ومعايير الاستجابة، والفوترة تحت حساب واحد، ورصيد واحد، وفاتورة واحدة. تدعم هذه الاستراتيجية credits وx402 وMPP. هذا يضع تعقيد إدارة عدة موردين وطرق دفع تحت بوابة مركزية.

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

إذا أصبحت طبقة المسؤولية المركزية شائعة، فقد يتغير هيكل الدفع نفسه. نموذج محتمل هو استبدال verify → منطق الأعمال → settle بـ verify → settle → منطق الأعمال.

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

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

قد يتساءل البعض:

ألا يعتبر هذا استخدام البلوكشين كقاعدة بيانات دفع مشتركة؟

نعم.

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

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