فهم X402 و MPP في جملة واحدة: مسارين لدفع الوكيل

عنوان النص الأصلي: MPP من Stripe مقابل x402: ماذا حدث فعلاً اليوم مؤلف النص الأصلي: Nick Sawinyh، defiprime.com ترجمة: Peggy، Blockbeats

مؤلف النص الأصلي:律动BlockBeats

المصدر:

إعادة النشر: 火星财经

مقدمة المحرر: حول مسألة كيف يمكن للوكيل (Agent) أن يدفع، قدمت كل من x402 وMPP مسارين يكاد يكونا متعاكسين.

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

أما MPP فهو يهدف إلى تعظيم النظام: من خلال الجلسات (sessions)، والدفع التدفقى، ونظام الامتثال، لحل مشكلات التداول عالي التكرار، وإدارة المخاطر، والوصول إلى العملات القانونية. لا يسعى إلى الكمال، بل يركز على تلبية الاحتياجات التجارية الواقعية، وهو أكثر ملاءمة للمؤسسات والتطبيقات الواسعة النطاق.

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

ولذلك، فهي ليست منافسة مباشرة تمامًا، بل تتوزع على مدى مختلف؛ x402 يغطي احتياجات الشبكة المفتوحة، وMPP يتعامل مع حركة المرور عالية التكرار والتجارية. في اقتصاد الوكيل (Agent) غير المكتمل بعد، قد يكون هذا التخصص ضروريًا.

وفيما يلي النص الأصلي:

منذ أن تم تعريف رمز الحالة HTTP 402 في نهاية تسعينيات القرن الماضي في مواصفة HTTP/1.1، وهو ينتظر فرصة لاستخدامه. معناه هو الدفع المطلوب (Payment Required). كانت الفكرة في البداية: دمج القدرة على الدفع في طبقة بروتوكول الويب، بحيث يمكن للآلات شراء الموارد كما تطلب صفحات الويب.

لكن معظم هذه الفكرة لم تتحقق. على مر السنين، ظهر هذا الرمز في بعض السيناريوهات الحدية فقط، مثل استجابة Shopify للحد من التدفق، أو أخطاء الفوترة في Apple Mobile Me، لكن لم يُبنى أحد مستقبل الدفع المصغر الذي يوحي به. بدلاً من ذلك، ظهرت أنظمة بطاقات الائتمان، والجدران المدفوعة بالاشتراك، وآليات مفاتيح API، وكلها مصممة بشكل أساسي للتعامل مع البشر الذين يديرونها.

واليوم، ظهرت مساران متنافسان لتحقيق هذا المستقبل، وتم إصدارهما في نفس اليوم. فيما يلي، أود أن أستعرض ما هما، وما الفروقات بينهما، ولماذا تراهن Stripe على كلا المسارين.

x402: حل أبسط

أطلقت Coinbase رسميًا x402 في مايو 2025، وهو تقريبًا بسيط جدًا إلى حد التطرف. يطلب العميل موردًا؛ يرد الخادم برمز HTTP 402، ويخبر العميل: كم المبلغ المطلوب، وأي عملة رمزية، وعلى أي سلسلة يتم الدفع. بعد إتمام الدفع على السلسلة، يرفق العميل إثبات الدفع في الطلب الجديد، فيقوم الخادم بتسليم المورد.

الأمر بسيط جدًا. لا يوجد نظام حسابات، ولا مفاتيح API، ولا آلية اشتراك. مجرد طلب HTTP ذهابًا وإيابًا، مع إدراج عملية دفع واحدة بينهما.

حاليًا، تقدم Stripe دعمًا أصليًا لـ x402 في نظام الدفع الخاص بها، ويمكن للتجار استقبال هذا النوع من المدفوعات مباشرة من خلال لوحة التحكم الحالية. ومع ذلك، من حيث الجوهر، لا يزال بروتوكول x402 بقيادة Coinbase، وتتحمل مسؤولية إدارته مؤسسة x402 التي أُنشئت في سبتمبر 2025 بالتعاون مع Cloudflare. هذا البروتوكول مفتوح المصدر بالكامل (رخصة Apache 2.0)، ويوفر SDK بلغات متعددة مثل TypeScript وGo وPython.

من حيث الدعم، تظهر وثائق Coinbase أن الدعم متوفر حاليًا على شبكات Base وPolygon وSolana لدفع ERC-20. كما يتم استكشاف توسيعه ليشمل Avalanche وSui وNear، لكن مستوى النضج يختلف.

أما عن بيانات الاعتماد، فهي معقدة بعض الشيء. تقول Coinbase إن أكثر من 50 مليون معاملة تمت عبر بنية Agentic Wallet الخاصة بها. يبدو رقمًا مبهرًا، لكن وفقًا لتحليل Artemis على السلسلة الذي أوردته CoinDesk في 11 مارس، فإن حجم المعاملات اليومي حوالي 131,000 معاملة، والمبلغ الإجمالي حوالي 28,000 دولار، ومتوسط الدفع لكل معاملة حوالي 0.20 دولار، ونصفها تقريبًا كانت اختبارات أو أنشطة ألعاب، وليست معاملات تجارية حقيقية.

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

على سبيل المثال، بروتوكول Agentic Payments الخاص بـ Google (AP2، ضمن إطار A2A) تم دمجه مع x402؛ كما عرضت Lowe’s Innovation Labs نموذجًا تجريبيًا: يمكن لوكيل AI أن يكمل عملية اكتشاف المنتجات، والبحث، وطلب الشراء في عملية واحدة. وفي الوقت نفسه، أطلقت شركة World (بقيادة سام ألتمان) هذا الأسبوع AgentKit، الذي يضيف قدرات إثبات الهوية البشرية لمحفظة x402.

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

MPP: الحل الشامل

اختارت Stripe وTempo مسارًا مختلفًا. تم إصدار بروتوكول المدفوعات الآلية (MPP) اليوم مع إطلاق شبكة Tempo الرئيسية. على عكس x402، الذي هو طبقة خفيفة على شبكات البلوكشين الحالية، فإن MPP مصمم خصيصًا لسيناريو الوكلاء (agents) الذين يجرون تداولات عالية التكرار.

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

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

عنصر آخر مهم هو: مجموعة أدوات التجارة الآلية (Agentic Commerce Suite) من Stripe تتضمن رموز دفع مشتركة (SPTs). هذه ليست جزءًا من MPP نفسه، لكنها آلية توسعة من Stripe، ويمكن استخدامها معًا. تسمح SPT للوكيل بنقل بيانات اعتماد البطاقة أو المحفظة بشكل آمن إلى التاجر دون الكشف عن البيانات الحقيقية. هذه البيانات تكون صالحة لمعاملة واحدة فقط، ولها مدة زمنية محددة، ويمكن اعتبارها نوعًا من التفويض القابل للبرمجة والمتلف ذاتيًا. في الاستخدام العملي، يعني ذلك أن وكيلًا يدفع عبر MPP يمكنه استخدام USDC على Tempo، أو بطاقة Visa المرتبطة بالمستخدم، أو كليهما معًا.

وفقًا لمقالة إطلاق شبكة Tempo، تشمل شركاؤها شركة Anthropic، وDoorDash، وMastercard، وNubank، وOpenAI، وRamp، وRevolut، وShopify، وStandard Chartered، وVisa. وذكرت مجلة The Block أن أكثر من 100 خدمة كانت مدرجة في قائمة المدفوعات عند إطلاق MPP، بما في ذلك خدمات مثل Alchemy، وDune Analytics، وMerit Systems، وParallel Web Systems. قال مؤسس مشارك في Tempo وParadigm، مات هوانغ، في مقابلة مع Fortune، إن هذا المجال لا يزال في مراحله المبكرة، وأن هدف تصميم MPP هو أن يتوسع ليشمل بيئات شبكية أكثر من شبكة Tempo.

لماذا تدعم Stripe كلاهما في الوقت نفسه

إذا كنت قد استخدمت Stripe، فإن الإجابة الأكثر عملية هي: لست بحاجة إلى الاختيار بينهما.

تدعم Stripe كلا المسارين بشكل مستقل، وليس كواجهة موحدة. بالنسبة لـ x402، تركز وثائقها على إنشاء عناوين الإيداع، ومراقبة المعاملات على السلسلة، وتسوية الأموال إلى حساب Stripe الخاص بك — أنت مسؤول عن الرد برمز 402، والبنية التحتية للتشفير والدفع تتولى Stripe. حاليًا، يدعم ذلك USDC على شبكة Base، وسيتم التوسع لاحقًا. أما بالنسبة لـ MPP، فيمكن للتجار استقبال المدفوعات عبر واجهة PaymentIntents، التي تعتمد على الجلسات.

تم إصدار مجموعة أدوات التجارة الآلية (Agentic Commerce Suite) من Stripe في ديسمبر 2025، وتبني على هذين المسارين. يرفع التجار منتجاتهم، ويختارون الوكلاء الذكيين الذين يرغبون في التعامل معهم، وتقوم Stripe بمهمة اكتشاف المنتجات، وإتمام عمليات الدفع، ومكافحة الاحتيال، ومعالجة الضرائب. حاليًا، يستخدمها عملاء مثل URBN وEtsy وCoach وKate Spade وAshley Furniture، كما تم تكاملها مع منصات مثل Wix وWooCommerce وBigCommerce وSquarespace وcommercetools.

استراتيجيتها واضحة جدًا: السيطرة على مستوى التجريد، وترك البروتوكولات الأساسية تتنافس.

مقارنة عامة

على المستوى الكلي، كلا البروتوكولين يهدفان إلى شيء واحد: تمكين الآلات من الدفع مقابل الموارد عبر HTTP. لكن الاختلاف الحقيقي يكمن في التفاصيل.

x402 (بقيادة Coinbase) مقابل MPP (Stripe + Tempo)

التوحيد القياسي: x402 مفتوح المصدر بالكامل (Apache 2.0)، وتديره مؤسسة x402 التي تضم Coinbase وCloudflare وVisa وGoogle. أما MPP، فهو معيار مفتوح وضعته Stripe وTempo، وهو جزء من مجموعة أدوات Stripe Agentic Commerce.

آلية HTTP: x402 يعيد إحياء رمز HTTP 402، ويستخدم رأس PAYMENT-REQUIRED لبدء الطلب، ويستخدم توقيع PAYMENT-SIGNATURE لإعادة المحاولة. أما MPP، فيعتمد على آلية تحدي-رد (challenge-response)، باستخدام بروتوكول مصادقة HTTP للدفع (IETF draft)، مع ربط التحدي عبر HMAC بمعرف التحدي.

الأساس التكنولوجي للدفع (Rails): x402 غير مرتبط بشكل مباشر بالسلسلة، ويدعم حاليًا شبكات Base وPolygon وSolana، مع استكشاف دعم شبكات أخرى. أما MPP، فهو مبني على شبكة Tempo، وهي شبكة Layer 1 محسنة للدفع، تدعم أكثر من 10,000 معاملة في الثانية، وتحقق تأكيدات في أقل من ثانية، ولا تمتلك رموز غاز أصلية؛ وهدفها طويل الأمد هو التوافق عبر السلاسل.

طرق الدفع: x402 تعتمد على العملات المستقرة بشكل كامل وعلى السلسلة. أما MPP، فيدعم USDC على Tempo وSPT (آلية Stripe)، مما يتيح دمج العملات المشفرة مع العملات القانونية (بطاقات الائتمان، المحافظ، BNPL).

طرق التسوية: تسوية على السلسلة (من 200 مللي ثانية إلى عدة ثوانٍ)، مع التحقق والتسوية من قبل Coinbase وغيرها من الوسطاء. أما MPP، فبفضل سرعة تأكيد Tempo، يتم تلقائيًا تسجيل المدفوعات ومعالجتها بشكل متوافق.

دخول التجار: الوسيط المفتوح (مثل Express، Hono، Next.js) يمكن أن يبني أو يستخدم وسيطًا. أما MPP، فيمكن الوصول إليه مباشرة عبر واجهة PaymentIntents من Stripe، مع إدارة كاملة للمخاطر، والضرائب، والردود، والتقارير.

الابتكار الرئيسي: x402 بسيط جدًا، وبدون ارتباط بمصنع معين، وهو يشبه فلسفة يونكس في الدفع. أما MPP، فهو يركز على الأداء العالي ودمج العملات القانونية، مع استخدام الجلسات لتحقيق المدفوعات التدفقية، والمدفوعات الصغيرة، والتحكم البرمجي في الإنفاق عبر SPT.

الشركاء الرئيسيون: x402: Coinbase، Cloudflare، Google (A2A/AP2)، Visa، World، Anthropic. أما MPP: Stripe، Visa، Lightspark، Anthropic، DoorDash، Mastercard، OpenAI، Shopify، Revolut، Standard Chartered.

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

أما MPP، فهي نمط مختلف تمامًا. إذا كان وكيلك يحتاج إلى إجراء مئات أو آلاف المعاملات في جلسة واحدة، ولا تريد أن ترفع على السلسلة في كل مرة، فهي الخيار الأنسب. آلية الجلسات تسمح بمعظم التفاعلات أن تبقى خارج السلسلة، حتى يتم التسوية النهائية؛ ونظام Stripe للامتثال يدير المخاطر والضرائب؛ ودمج SPT يتيح للوكيل استخدام كل من العملات المستقرة وبطاقات Visa وغيرها.

وهذا ليس أنيقًا جدًا، لكنه أكثر توافقًا مع الواقع.

المثير للاهتمام هو أن هذين المسارين ليسا بالضرورة منافسين تمامًا. x402 يغطي السيناريوهات المفتوحة والطويلة، وMPP يغطي حركة المرور التجارية عالية التكرار. واستراتيجية Stripe واضحة: لا تراهن على بروتوكول واحد، بل تضمن أن الأموال تصل في النهاية إلى حساباتها.

الحقيقة الآن: إلى أين وصل الأمر؟

بصراحة، لا توجد معاملات واسعة النطاق بعد.

وفقًا لمعلومات Coinbase عن إطلاق x402، فإن الشركاء الأوائل يشملون Hyperbolic (مدفوعات استنتاج GPU) وAnthropic (تكامل بروتوكول MCP). وذكر مدونة Stripe أن سيناريوهات الدفع عبر API (مثل CoinGecko) بدأت تظهر. على شبكة Tempo، يوجد أكثر من 100 خدمة في القائمة. SDK الخاص بـ Cloudflare لدعم الوكلاء يدعم x402 بشكل أصلي، وبعض المشاريع الصغيرة على شبكات Layer 2 مثل Base تحاول استخدام x402 كبوابة دفع.

لكن بشكل عام، حجم المعاملات محدود، وعدد التجار قليل، ومعظم النشاطات لا تزال في مرحلة التجريب.

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

الأهم هو أن اللاعبين الكبار في البنية التحتية بدأوا يتدخلون. فقد أنفقت Coinbase وStripe وCloudflare وVisa وGoogle، بالإضافة إلى شبكة Tempo، مليارات الدولارات على المدفوعات، وارتفعت الأحجام بشكل كبير.

وبالتالي، فإن الطريق واضح. السؤال هو: هل ستحتاج وكالات الذكاء الاصطناعي في 2026 إلى إجراء معاملات واسعة على هذا المسار، أم أن الأمر يشبه تركيب الألياف البصرية في 1998 — البنية التحتية موجودة قبل أن تتطلب الحاجة الفعلية؟

فماذا تختار؟

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

أما إذا كنت ضمن نظام Stripe وترغب في دمج حركة وكيلك — فإن MPP هو الخيار الأنسب. الجلسات، والمدفوعات التدفقية، والدمج بين العملات المشفرة والعملة القانونية، والنظام الكامل للامتثال، كلها ترقية في التكوين، وليست إعادة بناء كاملة للنظام.

وإذا كانت مهمتك الوحيدة هي: أن أتمكن من استلام الأموال بغض النظر عن البروتوكول الذي يستخدمه الوكيل، فالجواب هو: استخدم Stripe. فهي تدعم كلا المسارين.

وأخيرًا، رمز HTTP 402 أخيرًا وجد مكانه، بعد أن انتظر حوالي 27 عامًا.