ERPC تطلق Solana RPC المتوافق مع x402 — فاتحةً العصر الذي يدفع فيه وكلاء الذكاء الاصطناعي مقابل واجهات API التي يحتاجونها عند الطلب

ELSOUL LABO B.V. (المقر الرئيسي: أمستردام، هولندا؛ المدير التمثيلي والرئيس التنفيذي: فوميتاكي كاواساكي) وValidators DAO، مشغّلا ERPC، يسعدهما الإعلان عن إطلاق بروكسي JSON-RPC لشبكة Solana الرئيسية متوافق مع x402.

الخدمة المُطلقة حديثًا هي Solana RPC متوافق مع x402 وجاهز للإنتاج متاح على x402.erpc.global. ويمكن للمستخدمين والتطبيقات ووكلاء الذكاء الاصطناعي إرسال طلبات Solana JSON-RPC إلى POST https://x402.erpc.global/v1/solana-mainnet. وعندما يلزم الدفع، تعيد ERPC رمز HTTP 402 Payment Required مع تحدي دفع x402. ويمكن للعميل بعدها إرفاق حمولة دفع بعملة USDC المستقرة على شبكة Solana الرئيسية وإعادة المحاولة بالطلب نفسه لتلقّي نتيجة Solana RPC بعد التحقق من الدفع وتسويته.

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

نقطة نهاية RPC المدفوعة: POST https://x402.erpc.global/v1/solana-mainnet التسعير: https://x402.erpc.global/pricing OpenAPI: https://x402.erpc.global/doc اكتشاف الخدمة: https://x402.erpc.global/.well-known/x402

x402 بروتوكول دفع مفتوح يُدخل رمز الحالة HTTP 402 Payment Required إلى مدفوعات الويب وAPI الحديثة.

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

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

بعبارة أخرى، يحوّل x402 الوصول المدفوع إلى واجهات API على الويب إلى محادثة طلب/استجابة HTTP طبيعية: هذه العملية تكلف هذا المبلغ؛ قُدّم الدفع؛ ويمكن الآن إعادة النتيجة.

بروكسي Solana RPC المتوافق مع x402 من ERPC هو بروكسي JSON-RPC لشبكة Solana الرئيسية يعمل على Cloudflare Workers. ويستخدم التحقق من الدفع وتسويته ميسّر Coinbase CDP x402، مع مدفوعات بعملة USDC المستقرة على شبكة Solana الرئيسية. وينشر /.well-known/x402 الإصدار 2 من x402 وعنوان URL للميسّر وشبكة Solana الرئيسية وUSDC ونقطة نهاية POST على /v1/solana-mainnet.

في الطلب الأول، يرسل العميل جسم Solana JSON-RPC عاديًا. وإذا لم يتضمن الطلب X-Payment، تعيد ERPC 402 Payment Required مع تحدي x402 ووزن أسلوب RPC ومعلومات السعر المقوَّم بالدولار الأمريكي.

ثم يُنشئ العميل حمولة دفع بعملة USDC المستقرة على شبكة Solana الرئيسية ويعيد المحاولة بجسم JSON-RPC نفسه مع ترويسة X-Payment. وتطلب ERPC من الميسّر التحقق من الدفع وتسويته، وتتلقى إيصال تسوية، وتمرّر الطلب إلى خدمة Solana RPC المنبع. ويتلقى العميل نتيجة JSON-RPC مع إيصال X-Payment-Response. وللتوافق، تقبل ERPC أيضًا Payment-Signature كترويسة قديمة.

ولمنع استخدام الدفع المكرر، تُعالج التوقيعات المعاد استخدامها بوصفها 409 duplicate_payment. وتُعاد المدفوعات غير الصالحة أو المبالغ غير الكافية بوصفها 402 payment_invalid أو payment_amount_too_low.

يتبع التسعير نموذج الرموز القياسي لـ ERPC: يُضرب الوزن الخام لكل أسلوب في 0.000001 USD. فأساليب JSON-RPC القياسية تساوي 42 رمزًا، وgetProgramAccounts يساوي 4200 رمز، وgetTokenLargestAccounts يساوي 2400 رمزًا، ويضيف getMultipleAccounts عددًا قدره 420 رمزًا لكل pubkey. ولمطابقة الحد الأدنى لمبلغ التسوية لدى الميسّر، يُطبق حد أدنى للرسوم قدره 0.001 USD على الطلب كله. فمثلًا، يبلغ الوزن الخام لـ getSlot عدد 42 رمزًا، لكن الوزن المفوتر يصبح 1000 رمز، أي 0.001 USD، بعد تطبيق الحد الأدنى للرسوم.

تتوفر أيضًا نقاط نهاية فحص مجانية: GET /health وGET /pricing وGET /.well-known/x402. ويعرض /pricing الوزن الخام لكل أسلوب Solana RPC والوزن بعد الحد الأدنى للرسوم والسعر المقوَّم بالدولار الأمريكي.

من الدلالات المهمة لدعم x402 أن التعامل مع واجهات API وRPC يمكن أن يتم بدقة تقترب من مستوى المدفوعات الصغيرة.

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

مع آليات مثل x402، يمكن للخدمة أن تعرض سعرًا لكل طلب API أو استرجاع بيانات أو عملية، ويدفع العميل فقط مقابل ما يحتاجه. ونموذج تسعير ERPC مصمم أيضًا حول ضرب الوزن الخام لكل أسلوب في 0.000001 USD. وتطبق نقطة النهاية الحالية حدًا أدنى قدره 0.001 USD على الطلب كله لمطابقة الحد الأدنى لتسوية الميسّر، لكن الوحدة الأساسية مصممة بدقة 1 رمز = 0.000001 USD.

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

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

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

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

بالنسبة للبشر، من الطبيعي توقيع عقد SaaS ومراجعة فاتورة وإصدار مفتاح API قبل استخدام خدمة. لكن إذا كان وكيل ذكاء اصطناعي يتخذ آلاف أو عشرات آلاف القرارات الصغيرة أثناء العمل، فإن اشتراط موافقة بشرية على كل عقد أو دفعة يوقف سير العمل.

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

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

تقدّر McKinsey أن التجارة الوكيلة قد تنسّق ما بين 3 تريليونات و5 تريليونات دولار أمريكي عالميًا بحلول 2030. والذكاء الاصطناعي يصبح بالفعل نقطة دخول للبحث والمقارنة والتوصيات ودعم القرار. ومع نضج الهوية والتفويض والمدفوعات، يُتوقع أن يتعمق وكلاء الذكاء الاصطناعي أكثر في الشراء وتنفيذ الخدمات.

وفي الوقت نفسه، تُظهر بروتوكولات الدفع الأصيلة للإنترنت مثل x402 بالفعل نشاط معاملات واسع النطاق وحالات استخدام تجريبية. وينشر الموقع الرسمي لـ x402 مقاييس حية للمعاملات والحجم والمشترين والبائعين على مدى الأيام الثلاثين الماضية. وقد أشارت Circle إلى أن x402 عالج أكثر من 100 مليون دولار أمريكي من المدفوعات في أشهره الأولى. كما خلص تحليل Chainalysis إلى أن مدفوعات x402 الوكيلة على Base تجاوزت 100 مليون معاملة بحلول الربع الأول من 2026.

تُظهر هذه الأرقام أن x402 ليس مجرد مفهوم، بل دخل بالفعل مرحلة تجريب واستخدام للمدفوعات الآلية عالية التكرار. ولا يزال السوق في مرحلة مبكرة، لكن البنية التحتية تتشكل بسرعة لعالم يمكن فيه الدفع مقابل واجهات API والبيانات والحوسبة والخدمات الرقمية بدقة الطلب الواحد.

McKinsey: https://www.mckinsey.com/capabilities/quantumblack/our-insights/europes-agentic-commerce-moment-decision-influence-is-here-execution-is-coming x402: https://x402.org/ Circle: https://www.circle.com/blog/nanopayments-powered-by-circle-gateway-is-now-live-on-mainnet Chainalysis: https://www.chainalysis.com/blog/x402-agentic-payments-adoption/

بالنسبة لتطبيقات Solana، ليست RPC ميزة جانبية. ففحوص الأرصدة واستعلامات السلوتات وقراءات الحسابات وعمليات بحث حسابات البرامج وفحوص حالة المعاملات واسترجاع الكتل والمراقبة الفورية كلها تعتمد على RPC.

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

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

دعم ERPC لـ x402 خطوة أولى جاهزة للإنتاج نحو ذلك العالم. فيمكن لوكلاء الذكاء الاصطناعي والبرامج التعامل مع Solana RPC لا كخدمة ثابتة متعاقد عليها مسبقًا فحسب، بل أيضًا كمكوّن خدمة أساسي يمكنهم الدفع مقابله واستخدامه عند الطلب.

بالنسبة للمطورين، توفر ERPC المتوافقة مع x402 بيئة حقيقية لاختبار مسارات عمل الوكلاء وتصاميم API القائمة على الدفع حسب الاستخدام.

فعلى سبيل المثال، يمكن لوكيل بحث يحتاج إلى فحص حالة حساب Solana أن يرسل أولًا طلب RPC إلى ERPC. وإذا لزم الدفع، يقرأ الوكيل المبلغ المطلوب من استجابة 402، ويؤكد أنه ضمن الميزانية، ويُنشئ حمولة الدفع بعملة USDC المستقرة، ويعيد محاولة الطلب. وتتحقق ERPC من الدفع وتعيد نتيجة RPC. ويمكن للوكيل حفظ النتيجة والإيصال معًا في سجل مهامه.

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

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

حسّنت ELSOUL LABO وValidators DAO باستمرار البنية التحتية المطلوبة لتطبيقات Solana وعمليات المدققين عبر Solana RPC وGeyser gRPC وShredstream وSLV وSLV AI وValidators Solutions ومركز بيانات AS200261 المتخصص في Solana.

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

وبتبنّي بروتوكولات الدفع الأصيلة للإنترنت مثل x402 مبكرًا وعرضها عبر حالة استخدام ملموسة لـ Solana RPC، فإننا ندفع التنفيذ الواقعي لمدفوعات وكلاء الذكاء الاصطناعي قدمًا.

هذه ليست قصة عن المستقبل فحسب. فنقطة النهاية تعيد بالفعل HTTP 402، وتقبل الدفع بعملة USDC المستقرة، وتشغّل Solana RPC، وتعيد إيصالًا.

ستواصل ERPC تحسين أدائها كبنية تحتية متخصصة في Solana، كما ستواصل البحث والتطوير في طبقات الدفع والتفويض والتنفيذ التي يسهل على وكلاء الذكاء الاصطناعي والأنظمة المستقلة استخدامها.

نقطة النهاية هذه مخصصة لدفع رسوم استخدام Solana RPC من ERPC عبر x402. وهي لا تقدم خدمات تبادل الأصول المشفرة أو الوساطة أو الحفظ أو المحافظ.

نقطة نهاية RPC المدفوعة: POST https://x402.erpc.global/v1/solana-mainnet تسعير ERPC: https://x402.erpc.global/pricing واجهة ERPC OpenAPI: https://x402.erpc.global/doc اكتشاف خدمة ERPC x402: https://x402.erpc.global/.well-known/x402 موقع ERPC: https://erpc.global/ar لوحة تحكم ERPC: https://dashboard.erpc.global/ar

للاستفسار عن ERPC وSolana RPC المتوافق مع x402 وSolana RPC وGeyser gRPC وShredstream والبنية التحتية لوكلاء الذكاء الاصطناعي، يرجى التواصل معنا عبر لوحة تحكم ERPC.

لوحة تحكم ERPC: https://dashboard.erpc.global/ar