پروتکل x402: پرداخت‌های HTTP 402 برای دسترسی درخواستی

پروتکل X402 یک استاندارد پرداخت باز و بومی HTTP است که از پاسخ HTTP 402 "پرداخت مورد نیاز" به همراه هدرهای استاندارد شده استفاده می‌کند تا یک مشتری قبل از اینکه سرور منبعی را برگرداند، پرداخت کند. این پروتکل یک تماس API عادی را به یک جریان تعیین‌شده از نقل قول → پرداخت → تأیید/تسویه → رسید تبدیل می‌کند، با خدمات شخص ثالث اختیاری برای مدیریت تأیید و تسویه در شبکه‌ها.

نکات کلیدی

• x402 از http 402 "پرداخت مورد نیاز" به همراه هدرهای استاندارد شده استفاده می‌کند تا سرور بتواند قبل از ارائه یکپاسخ APIیا منبع وب، پرداخت را درخواست کند.
• دست‌دادن اصلی 402 + PAYMENT-REQUIRED (نقل قول) → تلاش دوباره با PAYMENT-SIGNATURE (بار پرداخت) → تأیید و تسویه → 200 + PAYMENT-RESPONSE (رسید).
• x402 با جفت کردن یک طرح پرداخت با یک پیاده‌سازی شبکه خاص، بی‌طرف به شبکه باقی می‌ماند و می‌تواند تأیید و تسویه را به یک تسهیل‌گر واگذار کند.
• Solanax402 را با آمار خاص زنجیره‌ای، از جمله نهایی‌سازی ~400ms، هزینه‌های تراکنش ~$0.00025، و بیش از 35 میلیون تراکنش x402 و بیش از 10 میلیون دلار حجم از زمان راه‌اندازی در Solana، بازاریابی می‌کند.

X402 به عنوان یک استاندارد پرداخت HTTP

حرکت کلیدی در پروتکل x402 این است که پرداخت به یک الگوی پاسخ HTTP درجه یک تبدیل می‌شود، نه یک سیستم صورتحساب خاص برنامه که بعداً به آن اضافه شده است. یک سرور منبع می‌تواند به یک درخواست پرداخت‌نشده با http 402 و الزامات پرداخت قابل خواندن توسط ماشین پاسخ دهد و کلاینت می‌تواند با یک بارگذاری پرداخت امضا شده در هدرها پاسخ دهد.

به همین دلیل است که "توضیح x402" کمتر شبیه یک پیشنهاد محصول کریپتو به نظر می‌رسد و بیشتر شبیه یک قطعه گمشده از لوله‌کشی وب است که در حال پر شدن است.

این موضوع برای اقتصاد عامل توضیح داده شده اهمیت دارد زیرا عوامل نمی‌خواهند برای هر نقطه پایانی که با آن تماس می‌گیرند "ثبت‌نام" کنند. درآمدزایی سنتی API حساب‌ها را مجبور می‌کند،کلیدهای APIفاکتورها و یک داستان احراز هویت جداگانه. x402 ترتیب را معکوس می‌کند: سرور شرایط پرداخت را در داخل همان جریان HTTP نقل می‌کند و مشتری تأیید پرداخت را به همان روشی که هر ویژگی دیگری از درخواست را تأیید می‌کند، با ارسال یک هدر اثبات می‌کند.

x402 به عنوان یک استاندارد باز برای "پرداخت‌های بومی اینترنتی" مشخص شده است که هدف آن بی‌توجهی به شبکه، توکن و ارز است. مرکز ثقل این مشخصات مخزن بنیاد x402 است که هدف سازندگان برای سازگاری باید به آن توجه کنند. Coinbase x402 نیز وجود دارد، اما README خود آن به عنوان یک انشعاب توسعه‌ای علامت‌گذاری شده است پس از اینکه پروژه تحت بنیاد x402 منتقل شد، که واقعیت حاکمیتی عملی پشت "coinbase x402" است.

چگونه یک درخواست x402 پرداخت می‌شود

بین یک مشتری که به یک نقطه پایانی ضربه می‌زند و سرور یک 200 OK برمی‌گرداند، x402 تعامل را به یک میکروساختار قابل پیش‌بینی وادار می‌کند: نقل قول، پر کردن، تسویه، رسید. پروتکل این کار را با کدهای وضعیت و هدرها انجام می‌دهد، نه با یک دست دادن SDK سفارشی.

یک جریان معمولی، همان‌طور که در مشخصات بنیاد x402 مستند شده است، به این صورت عمل می‌کند:

1. مشتری از یک سرور منابع درخواست یک منبع را از طریق HTTP می‌کند. 2. سرور منابع یک پاسخ 402 نیاز به پرداخت با هدر PAYMENT-REQUIRED که شامل یک شی PaymentRequired کدگذاری شده به base64 است و الزامات پرداخت قابل قبول را فهرست می‌کند، برمی‌گرداند. 3. مشتری یکی از الزامات پرداخت را انتخاب کرده و یک PaymentPayload که با جفت (طرح، شبکه) انتخاب شده مطابقت دارد، می‌سازد. 4.

مشتری درخواست را با هدر PAYMENT-SIGNATURE که شامل PaymentPayload است، دوباره ارسال می‌کند. 5. سرور منابع Payload را به صورت محلی یا با ارسال POST Payload و الزامات به یک نقطه پایانی تسهیل‌گر /verify تأیید می‌کند. 6. اگر تأیید معتبر باشد، سرور منابع درخواست را انجام می‌دهد و سپس یا به صورت مستقیم در زنجیره تسویه می‌کند یا با ارسال POST به یک نقطه پایانی تسهیل‌گر /settle. 7.

اگر تسویه موفقیت‌آمیز باشد، سرور منابع 200 OK را با منبع در بدنه و یک هدر PAYMENT-RESPONSE که شامل یک پاسخ تسویه کدگذاری شده به base64 است، برمی‌گرداند.

دو جزئیات بیشتر نتایج ادغام را هدایت می‌کنند. اول، مراحل ۱ و ۲ اختیاری هستند اگر مشتری از جزئیات پرداخت برای آن منبع مطلع باشد، که اینگونه تیم‌ها از یک سفر اضافی در مقیاس جلوگیری می‌کنند. دوم، مشخصات به‌طور صریح اجازه می‌دهد که سرعت پاسخ در مقابل تضمین پرداخت معامله شود، که به همین دلیل "http 402 payment" به‌طور خودکار مترادف با "تسویه نهایی فوری" نیست.

شبکه‌ها، طرح‌ها و تسهیل‌کننده‌ها

ادعای زنجیره‌ناشناخته x402 بر یک قید بستگی دارد: مشتریان و تسهیل‌کنندگان باید از جفت‌های صریح (طرح، شبکه) پشتیبانی کنند. یک طرح یک روش منطقی برای انتقال پول است، اما پیاده‌سازی آن طرح بسته به شبکه متفاوت است. "دقیق براتریوم"و "دقیق بر روی سولانا" همان مشکل مهندسی نیستند، حتی اگر سطح HTTP مشابه به نظر برسد.

مخزن بنیاد x402 طرح‌هایی را توصیف می‌کند که شامل تسویه دقیق، حداکثر و تسویه دسته‌ای (EVM) است. این تمایزها انتخاب‌های سبک اجرای مختلف هستند. دقیق یک انتقال ثابت برای یک درخواست است. حداکثر یک مجوز تا یک سقف است، با این حال فروشنده مصرف واقعی را تا آن حداکثر تسویه می‌کند.

تسویه دسته‌ای (EVM) از وثیقه و کوپن‌های خارج از زنجیره استفاده می‌کند تا بسیاری از هزینه‌های کوچک بتوانند به صورت دسته‌ای در زنجیره تسویه شوند به جای اینکه هر درخواست HTTP به طور جداگانه تسویه شود.

نقش تسهیل‌گر یکی دیگر از اهرم‌های طراحی بزرگ است. تسهیل‌گر یک سرور است که تأیید و اجرای پرداخت‌ها را برای یک یا چند شبکه تسهیل می‌کند. به طور مشخص، این سرور به سرور منبع یک سطح /verify و /settle می‌دهد تا سرور نیازی به پیاده‌سازی هر یک از ادغام‌های زنجیره‌ای به تنهایی نداشته باشد.

این راحتی با یک وابستگی جدید همراه است: تسهیل‌گر بخشی از مرز قابلیت اطمینان و اعتماد می‌شود، حتی اگر هدف اعلام شده استاندارد، حداقل کردن اعتماد و جلوگیری از انتقال وجوه توسط تسهیل‌گران خارج از قصد مشتری باشد.

این جایی است که ارزیابی‌های "پروتکل x402 کریپتو" اغلب اشتباه می‌شود. سوال درست این نیست که "آیا x402 سریع یا ارزان است"، زیرا x402 یک لایه مذاکره و اثبات است. تأخیر، پروفایل هزینه و تضمین‌های تسویه از جفت (طرح، شبکه) ناشی می‌شود و اینکه آیا تأیید و تسویه به صورت محلی انجام می‌شود یا به یک تسهیل‌گر واگذار می‌شود.

چرا x402 برای عامل‌های هوش مصنوعی اهمیت دارد

عامل‌های هوش مصنوعیشکل تقاضا را تغییر می‌دهند زیرا درخواست‌های کوچک و مکرر زیادی تولید می‌کنند که سخت است با اشتراک‌ها درآمدزایی کرد و با ورود به حساب کاربری دشوار است. x402 به گونه‌ای طراحی شده است که پرداخت‌های عامل‌محور را شبیه HTTP عادی احساس کند: عامل یک نقطه پایانی را فراخوانی می‌کند، یک نقل قول 402 دریافت می‌کند و می‌تواند بر اساس قوانین خود تصمیم بگیرد که آیا پرداخت کند یا نه.

صفحه x402 سولانا این موضوع را به عنوان "پرداخت‌های بومی اینترنت" برای ابزارهای خودمختار معرفی می‌کند و به آن تکیه می‌کنداستیبل کوینتسویه‌حساب به عنوان ریل اقتصادی که قیمت‌گذاری بر اساس درخواست را منطقی می‌سازد. آن صفحه ادعا می‌کند که پرداخت‌های استیبل‌کوین در سولانا بیش از ۱۱ میلیارد دلار در گردش است و بیش از ۲۰۰ میلیون تراکنش در ماه را شامل می‌شود، که شبکه را به عنوان یک لایه تسویه‌حساب با توان بالا برای خدمات پرداخت بر اساس درخواست قرار می‌دهد.

مکانیسم به‌خوبی با جریان‌های کاری عامل‌ها هم‌راستا می‌شود زیرا نیاز به یک هویت و کانال صورتحساب جداگانه را حذف می‌کند. یک مشتری که می‌تواند به HTTP صحبت کند می‌تواند با خواندن هدرهای استاندارد شده یاد بگیرد که چگونه پرداخت کند، به جای اینکه برای هر API یک SDK صورتحساب متفاوت را ادغام کند. این ویژگی اصلی برای پرداخت ماشین به ماشین است: مذاکره پرداخت برای مشتریان عمومی قابل درک است، نه فقط برای انسان‌ها که در یک صفحه پرداخت کلیک می‌کنند.

معامله این است که "پرداخت، احراز هویت است" تنها به اندازه‌ای که طرح و انتخاب‌های تسهیل‌کننده اجازه می‌دهند به طور روان عمل می‌کند. اگر یک عامل هزاران تماس برقرار کند، تفاوت بین "هر بار دقیقاً تسویه شده" و "تسویه دسته‌ای که بعداً بازخرید می‌شود" تفاوت بین یک حلقه تنگ و سیستمی است که زمان خود را صرف انتظار برای تأییدها می‌کند.

سیگنال‌های پذیرش و تعادل‌های عملی

تمیزترین نقطه داده‌های جذب در منابع ارائه شده خاص زنجیره است: صفحه x402 سولانا ادعا می‌کند که از زمان راه‌اندازی x402 در سولانا "این تابستان"، بیش از 35 میلیون تراکنش و بیش از 10 میلیون دلار حجم بر روی x402 پردازش کرده است. همان صفحه ادعا می‌کند که سولانا حدود 400 میلی‌ثانیه نهایی‌سازی و هزینه‌های تراکنش حدود 0.00025 دلار دارد.

این اطلاعات به عنوان سیگنال‌های پذیرش و عملکرد برای آن پیاده‌سازی مفید هستند، اما اثبات نمی‌کنند که هر ادغام x402 این اعداد را به ارث می‌برد.

خود مشخصات چارچوبی منطقی‌تر را ارائه می‌دهد: x402 انعطاف‌پذیر است و پیاده‌سازی‌ها می‌توانند سرعت پاسخ را در مقابل تضمین‌های پرداخت تعادل دهند. به همین دلیل است که ادعاهای گسترده‌ای مانند "در حدود ۲ ثانیه تسویه می‌شود" از توضیحات اکوسیستم باید به عنوان وابسته به شبکه و طراحی خوانده شوند، نه به عنوان ویژگی‌ای از دست دادن HTTP.

سازندگان همچنین باید "استاندارد" را از "بازاریابی اکوسیستم" جدا کنند. صفحه سولانا ادعا می‌کند که پلتفرم‌های بزرگی مانند Cloudflare، Google و Vercel از x402 پشتیبانی می‌کنند، اما منابع ارائه شده تعریف نمی‌کنند که "پشتیبانی" در سطح محصول به چه معناست. بدون یک سطح ادغام مشخص، آن خط قابل اقدام نیست.

وضعیت عملی این است که از یک نقطه باریک شروع کرده و اندازه‌گیری کنیم. یک جفت (طرح، شبکه) در تولید یک مسیر خوشایند واحد برای اندازه‌گیری از ابتدا تا انتها فراهم می‌کند. از آنجا، تیم‌ها می‌توانند طرح‌ها یا شبکه‌های بیشتری اضافه کنند و تصمیم بگیرند که آیا تأیید و تسویه را محلی نگه دارند یا به یک تسهیل‌کننده تکیه کنند.

این تفاوت بین یک دمو که کار می‌کند و یک لایه پرداخت است که در برابر تلاش‌های مجدد، زمان‌های انقضا و شکست‌های جزئی در اقتصاد عامل زنده می‌ماند.

تحلیل

من دیده‌ام که تیم‌ها x402 را مانند "یک دیوار پرداخت کریپتو" در نظر می‌گیرند و سپس از بخشی که واقعاً تجربه کاربری را تعیین می‌کند، شگفت‌زده می‌شوند: جفت (طرح، شبکه) و جایی که تأیید و تسویه انجام می‌شود. دست دادن HTTP قطعی است. لایه تسویه این‌طور نیست. اگر /verify یک تسهیل‌گر سریع باشد اما /settle متوقف شود، مشتری آن را به عنوان یک API می‌بیند که به‌طور تصادفی متوقف می‌شود، حتی اگر هدرها به‌طور کامل استاندارد شده باشند.

مدل ذهنی که باقی می‌ماند، میکروساختار است. 402 + PAYMENT-REQUIRED نقل قول است، PAYMENT-SIGNATURE سفارش است، تأیید و تسویه تسویه است، و 200 + PAYMENT-RESPONSE رسید است. وقتی این موضوع روشن می‌شود، ارزیابی دیگر "آیا x402 ارزان است" نیست و به "این نقطه پایانی چه سبک اجرایی را انتخاب کرده و چه وابستگی‌هایی را معرفی کرده است" تبدیل می‌شود، که دقیقاً لنز درستی برای اقتصاد عامل توضیح داده شده است.

منابع

• بنیاد سولانا
• بنیاد x402 (گیت‌هاب)
• کوین‌بیس (گیت‌هاب)
• thirdweb