اگر قصد دارید برای عامل‌های هوش مصنوعی سرویسی بسازید که به‌ازای هر عملیات مبلغی پرداخت کنند، باید بدانید که ساده‌ترین روش‌های تأیید پرداخت در بلاک‌چین می‌تواند باعث ورشکستگی شما شود. یک اشتباه کوچک در منطق تسویه حساب، به عامل‌های بدخواه اجازه می‌دهد تا خدمات پولی شما را به‌صورت رایگان و در مقیاس انبوه مصرف کنند.
طبق گزارش تیم DeskCrew، شرکتی که ابزارهای پشتیبانی را از طریق پرداخت‌های USDC در اختیار عامل‌ها قرار می‌دهد، این واقعیت تلخ را در مسیر میزبانی شخصی (Self-hosting) زیرساخت‌های پرداخت تجربه کرد. آن‌ها متوجه شدند که راهکارهای ابری معمولاً پیچیدگی‌های تأیید پرداخت را می‌پوشانند، اما وقتی خودتان میزبان هستید، هر شکافی در پروتکل به یک فرصت برای «کلاهبرداری از مدل» تبدیل می‌شود. این چالش‌های میزبانی شخصی در واقع بخشی از روند گسترده‌تر جایگزینی زیرساخت‌های متمرکز است، مشابه آنچه در بررسی جایگزین‌های متن‌باز برای Intercom جهت میزبانی شخصی مشاهده می‌کنیم. طبق گزارش آن‌ها، تیم مجبور شد منطق تسویه حساب خود را به‌طور کامل بازنگری کند تا از جعل پرداخت‌ها توسط کاربران جلوگیری کند. همان‌طور که در تحلیل‌های قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، لایه‌ی اتصال مدل به دنیای واقعی (مانند سیستم‌های پرداخت) اغلب ضعیف‌ترین حلقهٔ زنجیره است.
برای درک این موضوع باید با استاندارد x402 آشنا شوید. این استاندارد مدلی را می‌سازد که در آن عامل (Agent) — همان برنامه‌های هوشمند که به‌جای انسان تصمیم می‌گیرند و عمل می‌کنند — بدون نیاز به ساخت حساب کاربری یا داشتن کلید API، به‌ازای هر اقدام مبلغی می‌پردازد. این رویکرد برای حل مشکل هزینه‌های عملیاتی در مقیاس بالا است، مشابه استراتژی پروژه CleverCrow در انتقال هزینه‌های محاسباتی به کاربر نهایی برای مدیریت حجم بالای درخواست‌ها. این فرآیند از یک توالی مشخص پیروی می‌کند:
۱. کلاینت یک درخواست به نقطهٔ پایانی (Endpoint) پولی می‌فرستد، بدون اینکه پرداختی انجام داده باشد.
۲. سرور پاسخ ۴۰۲ (Payment Required) می‌دهد و یک پیش‌فاکتور (Quote) شامل مبلغ دقیق به USDC اتمیک، آدرس گیرنده، شبکه مورد نیاز و زمان انقضا (Timeout) ارسال می‌کند.
۳. عامل یک امضای EIP-3009 تحت عنوان transferWithAuthorization می‌سازد؛ این امضا یک امضای خارج‌زنجیره‌ای و بدون هزینه گاز (gasless) است که اجازه می‌دهد USDC از کیف پول کاربر به فروشنده منتقل شود و به یک نانس (nonce) یا همان شمارهٔ شناسایی یکتا متصل است تا از تکرار تراکنش جلوگیری شود.
۴. کلاینت درخواست را دوباره با این امضا در یک هدر به نام X-PAYMENT ارسال می‌کند.
این سازوکار نیاز به ثبت‌نام در حساب‌های کاربری را حذف می‌کند و به یک عامل اجازه می‌دهد تنها با پرداخت ۰.۰۵ دلار برای یک تسک واحد، عملیات را انجام داده و سپس سیستم را ترک کند. در حالی که اکثر سرویس‌های x402 از یک تسهیل‌گر (Facilitator) میزبانی‌شده برای تأیید و تسویه پرداخت‌ها استفاده می‌کنند، DeskCrew برای به دست آوردن کنترل کامل و پشتیبانی از ۵ زنجیره مختلف، کل استک — شامل تسهیل‌گر، ریلایر (Relayer) و سیستم تأیید تسویه — را به‌صورت شخصی میزبانی کرد.
با این حال، تیم در حین پیاده‌سازی با چهار «تله» یا نکته حیاتی روبرو شد:
تلهٔ نانس (The Nonce Trap)
بر اساس مستندات فنی این تیم، بررسی وضعیت authorizationState(from, nonce) روی قرارداد USDC کافی نیست. دلیل آن این است که استاندارد EIP-3009 به شخص مجاز اجازه می‌دهد تابع cancelAuthorization را فراخوانی کند یا نانس را در یک انتقال داخلی به خودش مصرف کند. در این حالت، نانس ممکن است «استفاده‌شده» به نظر برسد، در حالی که هیچ پولی به فروشنده نرسیده است. این نقص به یک عامل بدخواه اجازه می‌دهد تا در مقیاس انبوه، خروجی ابزارها را به‌صورت رایگان دریافت کند.
برای حل این مشکل، DeskCrew یک مسیر بازیابی تسویه سخت‌گیرانه‌تر را پیاده کرد:
- یافتن رویداد
AuthorizationUsed(authorizer, nonce)روی زنجیره. - تأیید لاگ انتقال USDC (Transfer log) که دقیقاً در کنار آن رویداد در همان تراکنش قرار دارد.
- بررسی اینکه انتقال واقعاً از کیف پول پرداخت‌کننده به کیف پول گیرنده صورت گرفته و مبلغ آن مساوی یا بیشتر از مبلغ اعلام شده در پیش‌فاکتور باشد.
از آنجا که توکن‌های FiatToken این لاگ‌ها را پشت‌سرهم منتشر می‌کنند، مجاورت ایندکس لاگ‌ها (log-index adjacency) آن‌ها را به یک مجوز (Authorization) واحد متصل می‌کند. اگر لاگی گم شود یا مبلغ کمتر باشد، آن ردیف در وضعیت «تسویه نشده» باقی می‌ماند و هرگز به عنوان درآمد ثبت نمی‌شود.
ناورهای اجرایی (Execution Invariants)
تیم با دو تضاد یا ناور (Invariant) روبروست: اول اینکه نباید بابت کاری که با شکست مواجه شده پول بگیرد، و دوم اینکه نباید یک ابزار اثرگذار (side-effecting tool) را دو بار برای یک پرداخت واحد اجرا کند. برای مدیریت این تضاد، DeskCrew از یک جدول ادعایی (Claim Table) استفاده می‌کند که کلید آن نانس EIP-3009 است و دارای محدودیت یکتایی (UNIQUE) می‌باشد.
- اولین درخواستی که ردیف پرداختِ در انتظار را درج کند، در این رقابت برنده شده و ابزار را اجرا می‌کند.
- تلاش‌های هم‌زمان برای ارسال درخواست با همان نانس ردされる.
- اگر ابزار با موفقیت اجرا شود اما تسویه به دلیل جهش ناگهانی هزینه گاز یا اختلال در RPC شکست بخورد، ردیف با برچسب «مصرف‌شده اما تسویه نشده» (consumed-but-unsettled) علامت‌گذاری می‌شود.
- یک Job بازبینی (Reconcile job) بعداً تسویه را مجدداً تلاش می‌کند و پیش از تبدیل ردیف به درآمد، مجدداً لاگ انتقال (Transfer log) را چک می‌کند.
ترتیب عملیاتی به این صورت است: ادعای نانس $\rightarrow$ تأیید ورودی $\rightarrow$ اجرای ابزار $\rightarrow$ تسویه $\rightarrow$ ثبت. تأیید ورودی پیش از پرداخت بسیار حیاتی است؛ زیرا دریافت ۵ سنت از کاربر و سپس بازگرداندن خطای «ورودی نامعتبر»، اصطکاک شدیدی برای توسعه‌دهندگان عامل‌ها ایجاد می‌کند.
پیچیدگی‌های چندزنجیره‌ای
استقرار روی ۵ زنجیره نشان داد USDC یک دارایی یکسان در همه جا نیست. زنجیره‌های مختلف دارای آدرس‌های قرارداد متفاوت هستند و نسخه‌های متنوعی از توکن‌های «پل‌زده» (Bridged) در مقابل «بومی» (Native) دارند. اعلام دارایی اشتباه در پیش‌فاکتور منجر به امضاهایی می‌شود که در برابر توکن‌هایی تأیید می‌شوند که فروشنده نمی‌تواند آن‌ها را پذیرفت.
چالش‌های خاص شامل موارد زیر است:
- سولانا (Solana): این زنجیره هیچ استاندارد EIP-3009 ندارد. بنابراین مدل باید به یک جریان تراکنش-محور تغییر کند که در آن پرداخت‌کننده هزینه (fee-payer) هم‌امضا می‌شود؛ این یعنی نیاز به یک پیاده‌سازی کامل ثانویه به‌جای یک پورت ساده.
- گاز ریلایر: تبلیغ شبکه‌هایی مانند Sei در پیش‌فاکتورها، در حالی که ریلایر در آن زنجیره گاز ندارد، باعث تخریب حسن‌نیت کاربر می‌شود.
توصیه تیم به توسعه‌دهندگان این است که ابتدا فقط روی شبکه Base استقرار یابند و زنجیره‌های دیگر را تنها در صورت درخواست کاربران اضافه کنند.
معیارهای شناسایی
برای اینکه عامل‌ها بتوانند سرویس را پیدا کنند، DeskCrew مانیفست‌های /.well-known/x402 و مانیفست‌های مربوط به هر Workspace را ارائه می‌دهد و یک ورودی در رجیستری MCP دارد. با این حال، آن‌ها یک قیف چهار مرحله‌ای (four-stage funnel) را برای اندازه‌گیری تقاضای واقعی ردیابی می‌کنند:
۱. دریافت مانیفست‌ها (نشان‌دهنده کنجکاوی).
۲. صدور پیش‌فاکتورهای ۴۰۲ (جایی که اصطکاک خرید آغاز می‌شود).
۳. تلاش برای پرداخت.
۴. تسویه‌های نهایی از کیف پول‌هایی که خودشان کنترل نمی‌کنند.
برای توسعه‌دهندگان، انتقال از تسهیل‌گرهای ابری به میزبانی شخصی، ریسک اصلی را از «وابستگی به فروشنده» به «بهره‌برداری از پروتکل» تغییر می‌دهد. تجربهٔ DeskCrew ثابت کرد که در پرداخت‌های غیرمتمرکز، هر وضعیتی که پرداخت‌کننده بتواند بر آن اثر بگذارد، دلیل بر پرداخت نیست؛ تنها انتقال واقعی به آدرس گیرنده ضمانت می‌دهد.
شما می‌توانید این جریان‌ها را از طریق بخش quickstart در سایت deskcrew.io تست کنید. ارزان‌ترین فراخوانی‌های آن‌ها از ۰.۰۲ دلار شروع می‌شود، در حالی که ابزار draft_support_reply که بدون نیاز به حساب است، ۰.۰۵ دلار هزینه دارد.
گام بعدی شما
- اگر از USDC برای پرداخت‌های میکروسرویس استفاده می‌کنید، منطق تأیید خود را از بررسی State به بررسی Log-index تغییر دهید.
- در ابتدای مسیر، فقط روی شبکهٔ Base استقرار یابید و زنجیره‌های دیگر را طبق درخواست کاربران اضافه کنید.
- برای تست جریان‌های پرداخت، به بخش quickstart در سایت deskcrew.io مراجعه کنید تا با هزینه‌های ۰.۰۲ تا ۰.۰۵ دلاری آشنا شوید.
اما تأثیر این سیستم پرداخت‌ها بر آیندهٔ اقتصاد عامل‌محور بسیار عمیق‌تر است — به تحلیل ما درباره‌ی استانداردهای MCP مراجعه کنید.
گفتگو