كيف يمكنك اتقان نقاط الساخنة في السوق، والاتجاهات التقنية، والتقدم البيئي، وحالة الحوكمة التي تحدث في صناعة Web3 بسهولة؟ يقدم قسم "تحليل نبض السوق" من Web3Caff Research تحليلاً عميقًا ومنتقى للأحداث الساخنة الجارية، مع تفسيرات قيّمة، وملاحظات، وتحليلات للآليات. انتقل من الظواهر إلى الجوهر، وتابعنا فورًا لاكتساب اتجاهات السوق المباشرة في Web3.
كاتب المقال: هيندريكس، باحث في Web3Caff Research
المصدر: Web3Caff Research
As AI agents continue to enhance their capabilities and take on an increasing number of end-to-end tasks, building payment systems for agents has become a necessary evolution for traditional merchants and service providers. However, existing solutions each have their own limitations: traditional payment systems such as credit cards and third-party payment platforms were originally designed for human users, requiring complex identity verification and risk assessment processes that are unsuitable for agents; meanwhile, emerging agent payment protocols such as x402 (developed and promoted by Coinbase), MPP (Machine Payment Protocol developed by Tempo and Stripe), etc., operate as separate systems entirely built for on-chain payments, processing the entire transaction on-chain with on-chain verification ensuring security. Service providers must therefore build an entirely separate payment infrastructure outside their traditional payment channels, raising the barrier to adoption. Traditional payment solutions and emerging agent payment protocols resemble two parallel lanes that have not been effectively integrated, limiting agents’ ability to autonomously purchase services mostly to Web3-friendly ecosystems, thus preventing large-scale workflow chaining. To address this, Solana Foundation and Google Cloud jointly launched Pay.sh, positioned as a “payment gateway between agents and enterprise-grade service infrastructure,” bridging the final step for agents to access a broader range of services.
ملاحظة قانونية: المحتوى التالي هو تحليل موضوعي لـ Pay.sh ومبادئه التقنية وقواعده التصميمية، ولا يشكل أي اقتراح أو عرض. يرجى عدم اتخاذ أي قرارات بناءً على هذه المعلومات، ويرجى الالتزام الصارم بالقوانين واللوائح السارية في بلدكم ومنطقتك (يُنصح بشدة قراءة "ملخص القوانين واللوائح الصينية المتعلقة بالبلوكشين والعملات الافتراضية" للقراء في البر الرئيسي للصين)، وعدم المشاركة في أي أنشطة مالية محظورة بموجب قوانين بلدكم ومنطقتك.
يسمح Pay.sh للمستخدمين بإيداع أموال بسرعة إلى محفظة Solana عبر بطاقة ائتمان أوالعملات المستقرة، وبعد ذلك يمكن لمحفظة Solana أن تعمل كوكيل هوية وحساب دفع في عالم موارد Web2.عندما يحتاج الوكيل إلى استدعاء خدمة، لن يكون من الضروري تسجيل حساب جديد أو إدخال مفتاح API، فسيقوم بوابة Pay.sh بالإعلان عن هوية الوكيل الموثوقة، تمامًا مثل نظام هوية Google، مما يسمح للوكيل باستخدام هوية حساب موحدة لشراء موارد تطوير كانت صعبة الوصول إليها سابقًا مثل Google Cloud وAliCloud.
الخدمات API الحالية المدعومة من Pay.sh صورة مأخوذة من الموقع الرسمي للمشروع
عملية الدفع في Pay.sh مشابهة لبروتوكول x402 الذي اكتسب شعبية كبيرة مؤخرًا، حيث تستند كلاهما إلى رمز الحالة HTTP 402: عندما يكتشف الوكيل خدمة خارجية تحتاج إلى استدعاء، فإنه يُرسل طلبًا إلى المورد المدفوع، فترد الخادم برمز الحالة 402 (يتطلب الدفع) مع تفاصيل الدفع المرفقة، بما في ذلك المبلغ المدفوع، خطة الدفع، عنوان الاستلام، صلاحية الدفع، وغيرها. تقوم Pay.sh بتحليل المحتوى المقابل وإرسال طلب تفويض إلى المحفظة، وبعد إتمام دفع المحفظة وإنشاء إيصال الدفع، تقوم Pay.sh بإعادة إرسال طلب الخدمة مع الإيصال للحصول على استجابة طبيعية. ولكن من أجل تغطية سيناريوهات استخدام واجهات برمجة التطبيقات المختلفة، تدعم Pay.sh أيضًا منطق الدفع الخاص بـ x402 وMPP: عندما تُرجع الخادم رمز الحالة 402، تقوم Pay.sh بتحديد طريقة الدفع الخاصة بالخدمة المستهدفة. إذا كانت مشاركة بيانات لمرة واحدة (الدفع للحصول على صلاحية وصول واحدة) أو نوع وصول مبني على الاستخدام (الدفع للحصول على كمية ثابتة من الوصول)، تقوم Pay.sh بإنشاء تحويل ثابت لمرة واحدة وإرساله على السلسلة. أما إذا كانت التكلفة مستمرة أو مبنية على الجلسة (الدفع الفردي للفاتورة الموحدة بناءً على الاستخدام)، فتدعم Pay.sh شهادة التفويض بالجلسة التي أطلقتها MPP (Machine Payment Protocol)، حيث تُدخل حد الميزانية في التفويض وترجعه إلى الخادم، مما يسمح للوكيل باستدعاء الخدمة مرارًا وتكرارًا في فترة قصيرة دون الحاجة إلى طلب تفويض متكرر. تقوم Pay.sh بتحديث الرصيد المتبقي في كل استدعاء، وعند نفاد الرصيد أو انتهاء الخدمة، تُعيد تلقائيًا طلب تفويض الجلسة. تعتمد Pay.sh تلقائيًا على مسار الدفع الأنسب بناءً على متطلبات الخدمة المستهدفة، مما يقلل من تكلفة الاستخدام وإدارة التكاليف. كما تضمن Pay.sh تخزين المحفظة بأمان محليًا دائمًا، وتطلب تأكيد المستخدم فقط عند الحاجة للدفع. عندما تستلم معلومات، تقوم Pay.sh بتمييز البيانات عن الأوامر؛ فجميع المحتويات الخارجية التي تُرجعها مزود الخدمة (بما في ذلك العنوان والنص ووصف واجهة برمجة التطبيقات) تُعتبر مدخلات غير موثوقة من قبل Pay.sh، ولا يجوز للوكيل تنفيذ الأوامر التي تُرجعها مزود الخدمة لمنع حقن كلمات التوجيه الضارة أو هجمات أخرى.
الميزة الأكبر لـ Pay.sh هي أنها توفر لمزودي الخدمة أيضًا بوابة سهلة النشر، بحيث لا يحتاج مزودو الخدمة إلى إجراء تعديلات كبيرة على قنوات الدفع أو واجهات برمجة التطبيقات الخاصة بهم لدمج بوابة الدفع في شبكتهم الخدمية. ما على مزودي الخدمة سوى تقديم ملف إعلاني يحدد المعلمات المتعلقة بالدفع لملاءمة سيناريوهات استخدام معقدة، مثل تحديد قواعد التوجيه لتمكين الوكلاء من استخدام الخدمة مجانًا حتى حد معين، ثم بدء فرض الرسوم بعد تجاوز الحد، بل ويمكن تحقيق نظام تسعير تدريجي (أسعار مختلفة حسب كمية الاستخدام)؛ بالإضافة إلى ذلك، توفر Pay.sh ميزة تقسيم الدفع، حيث يمكن إرسال الرسوم التي يستلمها مزود الخدمة تلقائيًا إلى عناوين متعددة، مثل 2% كرسوم حقوق بيانات الدفع، و5% كتكاليف سحابية، والباقي يبقى لتشغيل الخدمة، ويحتاج مزودو الخدمة فقط إلى تحديد نسب أو مبالغ مختلفة عند تعيين عناوين الاستلام لتنفيذ التسوية متعددة الحسابات مرة واحدة. بعد إكمال التسجيل، يمكن لمزودي الخدمة نشر بيانات خدمة API الخاصة بهم في Pay Skill Registry، ويمكن للوكلاء اكتشاف واختيار خدمات API المناسبة من خلال الاستعلام عن السجل.
Pay.sh ليس منافسًا لـ x402 و MPP. بينما تهدف بروتوكولات x402 و MPP إلى جعل مدفوعات الوكلاء على السلسلة أكثر موثوقية قدر الإمكان، فإن Pay.sh تهدف إلى ربط بيئتي الدفع Web2 و Web3، ومنح الوكلاء هوية ملائمة للحصول على الموارد. محفظة الوكيل هي هوية ووسيلة دفع في آن واحد، ولا يحتاج إلى التسجيل يدويًا على مواقع الخدمات (حيث قد تُصنف بعض الخدمات حاليًا محاولة الوكيل التقليد كمستخدم بشري كسلوك غير مسموح به). علاوة على ذلك، من خلال شراكتها مع Google، يمكن لـ Pay.sh تمكين الوكلاء من تنفيذ وكيل API وجدولة الحركة عبر Google Cloud، مما يضمن التحكم في الوصول والامتثال للسجلات، ويضع سلوك الوكلاء ضمن حدود معقولة. توفر Pay.sh دليلاً مختَّرًا للخدمات واكتشاف الأسعار، مما يمنع الوكلاء من اكتشاف الخدمات عشوائيًا في بيئة شبكة غير محمية، كما يمكنها الاستفادة من طرق الدفع المختلفة لـ x402 و MPP، مع إتمام عملية الخدمة وفق متطلبات الامتثال المؤسسي على Google Cloud — وهي ميزات تكمل قدرات الدفع للوكلاء التي لا تستطيع بروتوكولات x402 و MPP كقنوات دفع منفردة تغطيها، كما تفتح بابًا للتجارة الوكيلية للانتقال نحو Web3. بالإضافة إلى ذلك، يمكن لـ Pay.sh تزويد بروتوكولات التجارة الوكيلية التي أطلقتها Google بالحل النهائي للدفع، مثل: A2A (Agent2Agent Protocol) التي تُنجز الاتصال وتوزيع المهام بين الوكلاء، وAP2 (Agent Payments Protocol) التي تُنجز التحقق من الامتثال، وUCP (Universal Commerce Protocol) التي تُنجز اكتشاف الخدمة وتنفيذها، بينما تتحمل Pay.sh مسؤولية التسوية السلسة لقيمة الخدمة. ظهور Pay.sh يكمل أيضًا حلقات التجارة الوكيلية في Web2، ويصبح نقطة تقاطع لتدفق القيمة بين العالمين. هذه الخطوة تمثل أيضًا فرصة لترقية بيئة سولانا نفسها. في بيئة بروتوكول x402، يوجد عدد كبير من واجهات برمجة التطبيقات المُغلفة، حيث ينتهك مقدمو الخدمة شروط الخدمة الأصلية ويقومون بإعادة بيع خدماتها — مثل سرقة بيانات قواعد البيانات وبيعها، أو تغليف واجهات نماذج كبيرة وإعادة بيعها للآخرين. في هذا البيئة، لا يستطيع الوكلاء التمييز بين الخدمات المُصرّح بها والخدمات الضارة أو العشوائية، ولكن من خلال بوابة الدفع Pay.sh وتعاونها مع Google، يمكن للوكلاء عند استخدام الخدمات عبر Pay.sh تقليل المخاطر المحتملة. إطلاق Pay.sh يمثل دعمًا من سولانا للبنية التحتية والضمان لدفعات الوكلاء — مما لا يجلب فقط المزيد من تدفقات الدفع من Web2 إلى سولانا نفسها، بل يعزز أيضًا قدرات محفظة سولانا ويعجل من انتشارها.
لكن Pay.sh لا تزال بعيدة عن كونها حلاً مثاليًا لبوابة الدفع. حاليًا، سجل مزودي خدمة Pay.sh يفتقر إلى آليات القبول والتحقق اللامركزي، مما يجعل من الصعب التمييز بفعالية بين خدمات الطرف الثالث غير المصرح بها والخدمات الضارة، مما يعرض الوكلاء لخطر كبير في الاتصال بخدمات مزيفة تسبب خسائر للمستخدمين. علاوة على ذلك، نظرًا لأن Pay.sh لا تُصمم بروتوكولات الدفع الأساسية نفسها، فإن أمان عملية الدفع يعتمد بشكل أكبر على تصميم البروتوكول الأساسي، مما يُدخل مخاطر خارجية غير قابلة للتحكم في Pay.sh، كما قد يؤدي عدم التوافق الكافي مع بروتوكولات مختلفة إلى فشل محتمل في الدفع. من منظور مزودي الخدمة، على الرغم من دعم منصة Google، قد يتجنب مزودو واجهات برمجة التطبيقات في دول ومناطق مختلفة تقديم خدمات Pay.sh بسبب متطلبات الامتثال الخاصة بحماية خصوصية البيانات ومتطلبات الامتثال للدفع. وهذا ليس فقط سيحد من عدد مزودي الخدمة الذين يستخدمون Pay.sh، بل قد يتطلب في المستقبل جهودًا أكبر من Pay.sh لتحقيق الامتثال. لكن بغض النظر عن ذلك، فإن إطلاق Pay.sh يمثل خطوة أولى نحو تطبيق دمج البنية التحتية للدفع للوكلاء بين Web2 و Web3، حيث ستتاح لمحفظة السلسلة فرصة أن تصبح ضمانًا لمشاركة الوكلاء في مهام متنوعة. لذا يمكننا مواصلة مراقبة التطورات اللاحقة لـ Pay.sh.
مخطط هيكل النقاط:
