«تضمین داده‌های واقعی»؛ هدف جدید پروتکل پرداخت x402 برای عامل‌ها

تصور کنید یک عامل هوش مصنوعی برای انجام یک تراکنش مالی حساس، داده‌ای را از یک API می‌خرد، اما در مسیر بازگشت، یک مهاجم بایت‌های پاسخ را تغییر می‌دهد تا عامل را به اشتباه بیندازد. برای جلوگیری از این فاجعه، پروتکل x402 معرفی شده است تا پرداخت و تأیید اصالت داده را در یک چرخه بسته ادغام کند. این سازوکار یک شکاف امنیتی حیاتی را می‌پوشاند؛ جایی که یک عامل ممکن است هزینه سرویسی را بپردازد، اما پیش از اجرای یک اقدام با ریسک بالا، داده‌های جعلی (Spoofed) دریافت کند.

این پروتکل با بازتعریف وضعیت HTTP 402 (Payment Required)، به کاربر یا عامل اجازه می‌دهد بدون نیاز به کلید API، ایجاد حساب کاربری یا پرداخت اشتراک‌های ماهانه، هزینه هر فراخوانی را به‌صورت تک‌به‌تک با USDC بپردازد. در واقع، این سیستم شبیه به خرید بلیط تک‌سفره برای یک اتوبوس است که در آن هر بار ورود، یک پرداخت کوچک و سریع نیاز دارد و نیازی به عضویت سالانه نیست.

همان‌طور که در تحلیل‌های پیشین ما درباره‌ی امنیت مدل‌های عامل‌محور اشاره کردیم، اعتماد به داده‌های ورودی بزرگ‌ترین نقطه ضعف سیستم‌های خودکار است. ریل‌های پرداخت معمولاً فقط جابه‌جایی پول را ثابت می‌کنند، اما هیچ تضمینی نمی‌دهند که بایت‌های بازگشتی دست‌نخورده باشند. به عبارت ساده‌تر، ریل پرداخت چیزی درباره بایت‌هایی که بازمی‌گردند نمی‌گوید. در دنیایی که عامل‌های خودکار تراکنش‌های مالی را مدیریت می‌کنند، عمل کردن بر اساس حتی یک بایت تغییریافته می‌تواند منجر به شکست‌های فاجعه‌بار شود. یک عامل می‌تواند پرداخت را به‌طور کامل و درست انجام دهد، اما همچنان بر اساس داده‌های دست‌کاری‌شده یا جعلی عمل کند.

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

این سیستم بر پایه دو کتابخانه با مجوز MIT بنا شده است. فروشنده از @foreseal/gate استفاده می‌کند؛ یک میان‌افزار (Middleware) در Express که هر API بالادستی را به یک نقطه اتصال پولی و گواهی‌شده تبدیل می‌کند. خریدار نیز از @payperbyte/sdk برای تأیید پاسخ پیش از پردازش توسط عامل استفاده می‌کند. شما می‌توانید این اجزا را خودتان سیم‌کشی کنید یا برای سرعت بخشیدن به اسمبل کردن پروژه، از این کتابخانه‌ها استفاده کنید.

جریان فنی عملیات

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

• درخواست: کلاینت یک نقطه اتصال را فراخوانی می‌کند (مثلاً GET /price).
• چالش: سرور وضعیت HTTP 402 را همراه با شرایط USDC در قالب x402 (شامل نوع دارایی، مبلغ، شبکه و آدرس پرداخت یا payTo) بازمی‌گرداند.
• تسویه: کلاینت مبلغ USDC را روی شبکه اصلی Base پرداخت می‌کند.
• تحویل: سرور پاسخ ۲۰۰ (OK) را به همراه داده‌ها و یک هدر X-BYTE-Attestation ارسال می‌کند که شامل امضای EIP-712 روی بایت‌های دقیق ارسالی است.
• تأیید: کلاینت هش بایت‌های دقیق دریافتی را مجدداً محاسبه کرده و امضا را باز می‌کند تا اصالت را تأیید کند.

جزئیات ادغام برای فروشنده

ادغام برای فروشنده تنها با یک فراخوانی میان‌افزار در @foreseal/gate انجام می‌شود. پیکربندی trustMiddleware شامل نقطه اتصال بالادستی و قیمت است. برای قیمت‌گذاری می‌توان از گزینه‌هایی مثل perCallUsdc: "0.01" یا جایگزین‌هایی مانند perKBUsdc (به ازای هر کیلوبایت) یا floorUsdc (حداقل هزینه) استفاده کرد. همچنین آدرس پرداخت (payTo) و نوع گواهی تعیین می‌شود؛ نوع گواهی باید روی "delivery" تنظیم شود تا هر پاسخ ۲۰۰ پرداخت شده، مهر اصالت بخورد.

مکانیسم‌های تأیید برای خریدار

اعتبارسنجی مرحله‌ای است که اکثر توسعه‌دهندگان نادیده می‌گیرند، اما حیاتی‌ترین بخش است. با استفاده از @payperbyte/sdk کلاینت باید بررسی verifyFromGatewayResponse را اجرا کند. این فرآیند شامل سه مورد تست خاص برای تضمین امنیت است:

• بایت‌های واقعی: بایت‌های دریافتی با هش گواهی‌شده مطابقت دارند و امضاکننده درست است؛ در این حالت عامل می‌تواند با خیال راحت عمل کند.
• بایت‌های دست‌کاری‌شده: تغییر حتی یک بایت باعث عدم تطابق هش (HASH MISMATCH) می‌شود؛ در این حالت عامل باید از انجام هرگونه عملیاتی خودداری کند.
• امضاکننده جعلی: اگر بازگشت امضا با شکست مواجه شود (Recovery Failure)، عامل باید از واکنش نشان دادن به داده‌ها خودداری کند.

یک نکته فنی ظریف در مورد دامنه امضا وجود دارد. در حالی که پرداخت‌ها روی شبکه Base تسویه می‌شوند، دامنه امضای EIP-712 در شناسه زنجیره ۴۲۱۶۱۴ (Arbitrum Sepolia) لنگر انداخته است. این شناسه به عنوان یک فضای نام امضای منجمد (Frozen Namespace) برای بازیابی امضا عمل می‌کند. توسعه‌دهندگان باید مقدار ARBITRUM_SEPOLIA را به تأییدکننده پاس دهند، حتی اگر پول روی Base جابه‌جا شده باشد. مخلوط کردن این دو شبکه منجر به ایجاد امضاهایی می‌شود که بازیابی نخواهند شد.

برای کسانی که می‌خواهند این چرخه را تست کنند، تنظیمات پیش‌فرض از طریق یک تسهیل‌گر عمومی x402 روی base-sepolia است که اجازه می‌دهد کل چرخه با USDC تست‌نت به‌صورت رایگان کار کند. برای انتقال به محیط عملیاتی روی شبکه اصلی Base، کاربران باید تسهیل‌گر Coinbase CDP را ادغام کنند. این کار با تنظیم شبکه روی base و ارائه CDP_API_KEY_ID و CDP_API_KEY_SECRET انجام می‌شود. این اقدام تضمین می‌کند که وضعیت ۴۰۲، دارایی USDC استاندارد در Base و آدرس payTo صحیح را تبلیغ کند.

این ساختار بین «منشأ» (Provenance) و «حقیقت» (Truth) تفکیک قائل می‌شود. رسید ثابت می‌کند بایت‌ها اصیل هستند و توسط فروشنده امضا شده‌اند—که باعث می‌شود داده‌ها قابل شناسایی در برابر دست‌کاری و متصل به امضاکننده باشند—اما ثابت نمی‌کند که داده‌ها از نظر محتوایی «درست» هستند. یک رسید معتبر برای یک عدد اشتباه، باز هم تأیید می‌شود چون بایت‌ها اصیل‌اند، حتی اگر مقدار آن‌ها زباله باشد. ادعای این سیستم محدود است: «این‌ها دقیقاً همان بایت‌هایی هستند که فروشنده امضا کرده است»، نه اینکه «این عدد درست است».

برای توسعه‌دهندگانی که از پروتکل زمینه مدل (MCP) استفاده می‌کنند، byte-mcp-server (با مجوز MIT) ابزاری آماده برای Claude Desktop، Claude Code و Cursor فراهم می‌کند تا منطق «خرید-سپس-تأیید» را مستقیماً و بدون تغییرات دستی پیاده کنند. برای کسانی که شروع سریع‌تری می‌خواهند، کیت‌های استارتر آماده برای استقرار در Express و MCP با قیمت ۳۹ دلار each موجود است تا از فرآیند سیم‌کشی دستی اجتناب شود.

این چرخش، صنعت را از کلیدهای API ایستا و اشتراک‌های ماهانه به سمت یک اقتصاد دانه‌بندی‌شده و مبتنی بر مصرف (Utility-based) می‌برد. فراخوانی API از یک تمرین «اعتماد کور» به یک قرارداد تجاری قابل تأیید تبدیل می‌شود. با ارزان کردن اثبات منشأ داده، ریسک عمل کردن عامل‌ها بر اساس داده‌های دست‌کاری‌شده از بین می‌رود.

گام بعدی شما

• اگر از عامل‌های خودکار برای تراکنش‌های مالی استفاده می‌کنید، کتابخانه @payperbyte/sdk را برای اعتبارسنجی پاسخ‌ها در لایه کلاینت پیاده کنید.
• برای کاهش هزینه‌های زیرساختی، مدل پرداخت «به ازای هر بایت» را جایگزین اشتراک‌های ثابت در APIهای خود کنید.
• سرور byte-mcp-server را روی کلاینت‌های Claude یا Cursor تست کنید تا سرعت اجرای عملیات خرید داده را بسنجید.

اما تأثیر این مدل پرداخت بر توزیع قدرت در میان ارائه‌دهندگان داده‌های کوچک حتی عمیق‌تر است — به تحلیل ما درباره‌ی اقتصاد توکن‌های کاربردی مراجعه کنید.