اگر یک عامل هوشمند برای دریافت قیمت لحظه‌ای یک دارایی هزینه پرداخت کند، آیا پاسخ ۲۰۰ OK از یک API تجاری واقعاً ثابت می‌کند که داده‌ها واقعی هستند؟ پاسخ منفی است؛ چرا که پرداخت موفق تنها جابجایی پول را تأیید می‌کند، اما نمی‌تواند شکاف اعتماد را برای عامل‌های خودکاری که از پروتکل x402 استفاده می‌کنند، پر کند. برای حل این مشکل، PayPerByte سازوکاری را معرفی کرده است که تضمین می‌کند پیش از آنکه یک عامل وجهی را آزاد کند، پوزیشنی مالی باز کند، گزارشی ثبت نماید یا یک گردش‌کار (Workflow) را فعال کند، پیش‌نیاز اصلی «اثبات یکپارچگی» (Proof of Integrity) باشد، نه صرفاً یک پرداخت موفق.
تصور کنید عاملی در حال خرید یک فید قیمتی است، اما یک پروکسی، یک کش یا یک حمله مرد-در-میان (Man-in-the-Middle) بایت‌های قیمت را بازنویسی می‌کند. بدون وجود یک لایه‌ی تأیید، عامل بر اساس داده‌های جعلی عمل می‌کند، در حالی که پرداخت همچنان با موفقیت انجام شده و تسویه گشته است. این همان مشکلی است که SDK جدید @payperbyte/sdk با جداسازی مسیر تسویه مالی از لنگر اعتماد (Trust Anchor) برطرف می‌کند.
شکاف تأیید: پرداخت به‌معنای صحت نیست
عامل‌های خودکار به‌طور فزاینده‌ای در حال پرداخت هزینهٔ فراخوانی داده‌ها به ازای هر درخواست (Per Call) با استفاده از استیبل‌کوین‌ها هستند. با این حال، پرداخت تنها مسئله صورت‌حساب را حل می‌کند، نه مسئله اعتماد را. یک عامل نمی‌تواند به‌سادگی فرض کند که «چون برای آن پرداخت کرده‌ام، پس داده دقیق است». هدف این است که ثابت شود بایت‌ها دست‌نخورده باقی مانده‌اند و دقیقاً مشخص شود چه کسی پشت این داده‌ها ایستاده است. این ضرورت تأیید داده‌ها در حالی است که ریسک‌های امنیتی در لایه‌های بالاتر همچنان بالاست؛ برای مثال، گزارش‌های OWASP نشان‌دهنده افزایش شدید حملات تزریق پرامپت در عامل‌های AI است که امنیت کل چرخه داده را به چالش می‌کشد.
برای نمایش ملموس این موضوع، یک کیت آموزشی باز (Open MIT kit) از طریق دستور npx @foreseal/demo یک دمو ارائه می‌دهد. این ابزار به‌صورت کاملاً آفلاین اجرا می‌شود و یک عامل را از میان چندین نمونه داده (Payload) عبور می‌دهد: یک داده‌ی امضاشده‌ی واقعی، داده‌ای با بایت‌های دستکاری‌شده، نسخه‌ای با کلید جعلی (Forged-key)، داده‌ای که رسید آن حذف شده و موردی که دامنه در آن بازنویسی شده است. در هر یک از این موارد شکست‌خورده، تأییدکننده عبارت «REFUSE» را چاپ می‌کند تا اطمینان حاصل شود که عامل در صورت بروز خطا، به‌صورت بسته (Fail Closed) متوقف می‌شود.
جزئیات فنی: بررسی دو مرحله‌ای
طبق راهنمای فنی منتشر شده در dev.to، این سامانه بر یک فرآیند تأیید دو مرحله‌ای (Two-leg verification) با استفاده از هدر X-BYTE-Attestation تکیه دارد. هر پاسخ پرداختی که از درگاه PayPerByte ارسال می‌شود، حاوی یک گواهی PayloadAttestation بر اساس استاندارد EIP-712 است. منطق تأیید از یک دستورالعمل سخت‌گیرانه و ماشین‌خوان پیروی می‌کند که در مسیر /.well-known/agent.json منتشر شده است:
- بخش هش (The Hash Leg): سیستم بررسی می‌کند که آیا
keccak256(responseBody) === payloadHashاست یا خیر. این مرحله ثابت می‌کند بایت‌ها در طول مسیر انتقال تغییر نکرده‌اند. - بخش امضاکننده (The Signer Leg): سیستم از تابع
recoverTypedDataAddress(domain, {PayloadAttestation}, message, signature) === attesterاستفاده می‌کند. این کار ثابت می‌کند رسید توسط کلید مورد انتظار صادر شده و توسط فرستنده‌ی پاسخ به‌صورت خوداظهاری (Self-asserted) جعل نشده است.
برای جلوگیری از این احتمال که مهاجمان پاسخ‌های جعلی را خودشان گواهی کنند (Self-certifying)، این SDK توسعه‌دهندگان را ملزم می‌کند آدرس GATEWAY_ATTESTER را تثبیت (Pin) کنند (مثلاً آدرس 0x77c86a5367d941091a31BC97104609F2Db33C472). از آنجایی که فیلد ناشر (Publisher) در داخل هدر تحت کنترل مهاجم است، اعتماد به آن بدون داشتن یک آدرس Pin شده، اجازه می‌دهد تا پاسخ‌های جعلی به‌راحتی خودشان را تأیید کنند. در واقع، تکیه بر مکانیزم‌های ساده‌ی فیلترینگ یا دکودینگ برای توقف حملات پیچیده کافی نیست، همان‌طور که در تحلیل‌های فنی مربوط به محدودیت‌های دکودر در برابر تزریق‌های پرامپت مغزی مشاهده شده است.
تفکیک معماری و پیاده‌سازی
نکته جالب این است که معماری سیستم، نقش‌های بلاک‌چین را به‌طور کامل تفکیک کرده است. در حالی که پرداخت‌ها با USDC روی شبکه Base تسویه می‌شوند، لنگرهای اعتماد برای گواهی‌ها (Attestations) روی شبکه Arbitrum (با شناسه زنجیره ۴۲۱۶۱۴) تثبیت شده‌اند. این جداسازی عمدی است تا اطمینان حاصل شود که ریل تسویه مالی و لنگر اعتماد متمایز باقی می‌مانند.
توسعه‌دهندگان باید این قابلیت را با استفاده از دستور npm i @payperbyte/sdk@^0.1.2 پیاده‌سازی کنند. رعایت نسخه‌بندی در اینجا حیاتی است؛ زیرا نسخه‌ی ۰.۱.۲ و بالاتر شامل بررسی‌های کامل هش و امضا (توابع verify ،verifyAttestation و verifyFromGatewayResponse) می‌باشد. نسخه‌های قدیمی‌تر (۰.۱.۰ و ۰.۱.۱) تنها تابع verifyPayload را که فقط بررسی هش را انجام می‌داد، صادر می‌کردند.
درک حکم نهایی (Verdict)
این SDK یک رابط کاربری به نام Verdict ارائه می‌دهد که به‌طور صریح دلیل پذیرش یا رد یک داده را ثبت می‌کند:
- verified: یک مقدار بولین که نشان می‌دهد آیا هر دو شرط
hashMatchوsignerMatchبرقرار هستند یا خیر. - hashMatch: تأیید می‌کند که آیا بایت‌ها دستکاری شده‌اند یا خیر.
- signerMatch: صحت امضا را بررسی می‌کند؛ اگر مقدار آن null باشد، به این معناست که هیچ گواهی وجود نداشته و سیستم به‌صورت ایمن متوقف می‌شود.
- recovered: آدرسی که امضا در نهایت به آن بازیابی (Recover) شده است.
- expired: یک پرچم توصیه‌ای برای داده‌های قدیمی (مثلاً ضرب‌الاجل ۳۰۰ ثانیه بعد از زمان حال). این مورد وضعیت
verifiedرا به false تغییر نمی‌دهد، زیرا تازگی داده (Freshness) یک تصمیم سیاستی برای کاربر است و نه یک حکم مربوط به دستکاری داده. - reason: یک رشته متنی خوانا برای تحلیل‌های پس از وقوع خطا (Post-mortems).
تأیید طرف مقابل
فراتر از فیدهای داده، همین الگوی EIP-712 برای غربالگری طرف مقابل (Counterparty Screen) به کار گرفته می‌شود. عامل‌ها می‌توانند با پرداخت هزینه اندک ۰.۰۵ دلار، یک حکم امضاشده شامل وضعیت‌های ALLOW، WARN یا BLOCK درباره یک آدرس یا دامنه خاص، پیش از آزاد کردن وجه دریافت کنند. این یک سیستم غربالگری است تا تعیین شود «آیا ارسال وجه به اینجا ایمن است؟» و نباید با یک امتیاز کلی برای اعتبار فروشنده اشتباه گرفته شود. این درخواست از طریق یک POST به اندپوینت /feeds/address-reputation ارسال می‌شود؛ در صورتی که هدر پرداخت ارسال نشود، سیستم یک چالش HTTP 402 را به عنوان دست‌دادن (Handshake) بازمی‌گرداند.
این تغییر، عامل‌های AI را از رویکرد «اعتماد بر اساس پرداخت» به «اعتماد بر اساس رمزنگاری» منتقل می‌کند. با الزام به یک بررسی رمزنگاری محلی پیش از هر اقدام، ریسک فریب عامل‌ها توسط دستکاری‌های داده در سطح پروکسی به‌شدت کاهش می‌یابد. این سیستم در حال حاضر در مراحل اولیه است و تسویه‌های شبکه اصلی (Mainnet) فعلاً محدود به تست‌های داخلی (Dogfooded) است.
برای کسانی که از IDEهای هوشمند AI استفاده می‌کنند، این کتابخانه از طریق byte-mcp-server در دسترس است و به ابزارهایی نظیر Claude یا Cursor اجازه می‌دهد تا مستقیماً با استفاده از دستور npx -y byte-mcp-server این فیدهای تأییدشده را هدایت کنند.
گام بعدی شما
- اگر توسعه‌دهنده عامل‌های خودکار هستید، کتابخانه
@payperbyte/sdkرا جایگزین سیستم‌های پرداخت ساده کنید. - آدرس
GATEWAY_ATTESTERرا در کد خود Pin کنید تا از حملات self-certifying در امان بمانید. - از
byte-mcp-serverبرای اتصال مستقیم Cursor به داده‌های تأییدشده استفاده کنید.
اما اثر این متد روی کاهش هزینه‌های استنتاج در مقیاس کلان شگفت‌انگیزتر است — به تحلیل ما درباره تراشه‌های Blackwell مراجعه کنید.
گفتگو