مقایسه X402، MPP و AP2: ریسک تسویه و اعتبار جلسه
مقایسه X402 با MPP و AP2 به دو انتخاب میرسد: نحوه انجام تسویه (اتمی بر اساس درخواست در مقابل تسویه جلسهای) و نحوه اثبات مجوز (دستورها). x402 و MPP ریلهای پرداخت برای پرداختهای ماشین به ماشین هستند، در حالی که AP2 لایه حاکمیتی است که پرداختهای عاملی را قابل حسابرسی و ایمن برای شرکتها میسازد.
نکات کلیدی
- x402 یک ریل تسویه stablecoin بومی HTTP است که بر اساس HTTP 402 ساخته شده است: سرور شرایط را اعلام میکند، مشتری پرداخت میکند، سپس درخواست را با مدرک پرداخت دوباره تلاش میکند.
- MPP یک پروتکل پرداخت ماشین مبتنی بر جلسات است: یک عامل یک محدودیت را پیشمجوز میدهد، در طول جلسه میکروپرداختها را پخش میکند و در پایان جلسه تسویه دستهای انجام میدهد.
- AP2 یک ریل نیست. این یک چارچوب مجوز و audit است که از دستورهای امضا شده رمزنگاری شده بر اساس اعتبارنامههای قابل تأیید W3C استفاده میکند.
- الگوی تولید لایهای است: AP2 برای "چه کسی مجاز به خرج کردن چه مقدار است"، سپس x402 یا MPP در زیر برای تسویه، بسته به هزینه و تحمل ریسک.
چگونه این پروتکلها از نظر لایه متفاوت هستند
سریعترین راه برای مقایسه صحیح x402 با mpp و ap2 این است که دیگر آنها را به عنوان سه جایگزین در نظر نگیریم. دو تا از آنها پول را جابهجا میکنند و یکی از آنها مجوز را اثبات میکند. xpay’s “پرداختهای عاملینقشه این را به عنوان یک پشته قاببندی میکند: ریلهای تسویه در پایین (جایی که وجوه واقعاً جابهجا میشوند)، یک لایه کنترل در وسط (سیاستها و حسابرسی) و پروتکلهای کشف یا تجارت در بالای آن.
این قاببندی پشته اهمیت دارد زیرا سوال مهندسی را از "کدام پروتکل پیروز میشود" به "کدام حالت شکست در هر لایه قابل قبول است" تغییر میدهد.
در سمت تسویه، x402 و MPP هر دو از HTTP 402 Payment Required به عنوان دست دادن استفاده میکنند که یکAPIبه یک رویداد قابل صورتحساب تبدیل شود. تفاوت در سطح حسابداری است. x402 به گونهای طراحی شده است که تسویه اتمی را به ازای هر درخواست انجام میدهد، که ریسک اعتباری را محدود و تسویه را دقیق نگه میدارد. MPP یک جلسه را معرفی میکند که هزینههای تسویه در هر تعامل را کاهش میدهد اما یک دورهی در معرض خطر ایجاد میکند تا زمانی که جلسه بسته و تسویه شود.
AP2 بالاتر از هر دو قرار دارد. این یک مشخصه حکمرانی و مجوز است که به سوال متفاوتی پاسخ میدهد: "آیا این عامل مجاز به خرج کردن بود؟" این کار را با دستورات امضا شده به صورت رمزنگاری شده انجام میدهد که میتوان بعداً آنها را تأیید کرد، که این بخش گمشده زمانی است که یک عامل به نمایندگی از یک انسان یا یک سازمان خرج میکند.
مدل ذهنی تمیز به صورت همزمان عبارت است از:
۱. x402: تسویه بدون حالت بر اساس درخواست با استیبلکوینها. ۲. mpp: صورتحساب با حالت برای جلسات با میکروپرداختهای استریمینگ و تسویه دستهای. ۳. ap2: مجوزدهی و حسابرسی امضا شده که میتواند هر یک از مدلهای تسویه را در بر بگیرد.
این هسته اقتصاد عامل توضیح داده شده است: عوامل به روشی برای پرداخت نیاز دارند و اپراتورها به روشی برای اثبات اینکه عامل مجاز به پرداخت بوده است نیاز دارند.
جریان پرداخت x402 و تعادلها
جریان x402 یک حلقه تنگ است که شبیه به چیزی است که در یک ردیابی شبکه ظاهر میشود، نه یک صفحه پرداخت. یک مشتری یک منبع پرداخت شده را درخواست میکند. سرور با HTTP 402 پرداخت مورد نیاز و شرایط پرداخت ساختاری پاسخ میدهد. مشتری یک پرداخت استیبلکوین را امضا میکند و آن را به درخواست بعدی پیوست میکند و سرور منبع را پس از تأیید و تسویه پرداخت باز میگرداند.
منابع متعدد نقش "تسهیلگر" را در این حلقه توصیف میکنند که وجود دارد تا سرور نیازی به تبدیل شدن به یک پردازشگر پرداخت زنجیرهای کامل فقط برای فروش یک پاسخ API نداشته باشد.
این اتمی بودن نکته است. هر درخواست رسید خود را دارد که اندازهگیری و حل اختلاف را ساده میکند. اگر یک عامل 500 بار به یک نقطه پایانی تماس بگیرد، 500 رویداد پرداخت شده مجزا وجود دارد. این همچنین هزینه است. هزینه تسویه به ازای هر درخواست زمانی که حجم تماس بالا است، گلوگاه میشود، حتی اگر هزینههای زنجیرهای زیرین پایین باشد.
منابع x402 را به عنوان اولویت استیبلکوین معرفی میکنند که اغلب با USDC در Base توصیف میشود و به عنوان یک شیء اولیه بدون نیاز به مجوز که در آن خریدار نیازی به باز کردن حساب با فروشنده ندارد.
مدل ریسک ساده است: قرار گرفتن فروشنده اساساً زمان بین دریافت مدرک پرداخت و تحویل منبع است. هیچ "حسابی" باز نمیماند. به همین دلیل x402 برای پرداختهای ماشین به ماشین مانند APIهای پرداخت شده، جریانهای داده و تماسهای خدماتی عامل به عامل مناسب است.
از نظر زمانی، منابع راهاندازی x402 کوین بیس را در مه 2025 قرار میدهند، با یک بهروزرسانی V2 در 11 دسامبر 2025 که ویژگیهای مبتنی بر کیف پول یا سبک هویت و پشتیبانی چند زنجیرهای را اضافه کرد، اگرچه فهرست دقیق ویژگیهای V2 در خلاصهها متفاوت است. منابع همچنین اشاره میکنند که استرایپ x402 را برای پرداختهای USDC در Base در فوریه 2026 ادغام کرده است.
مدل جلسات MPP و پوشش ریلی
MPP واحد حساب را از "درخواست" به "جلسه" تغییر میدهد. به جای پرداخت برای هر تماس، یک عامل یک حد هزینه را پیشمجوز میدهد، سپس میکروپرداختها را به محض جمع شدن استفاده، پخش میکند و جلسه در پایان به صورت دستهای تسویه میشود. این تفاوت مکانیکی کلیدی پشت بیشتر بحثهای "x402 در مقابل mpp" است. این فقط سرعت نیست. این یک پروفایل قرار گرفتن متفاوت و یک شیء تسویه متفاوت است.
MPP در 18 مارس 2026 همزمان با شبکه اصلی Tempo راهاندازی شد و منابع 100+ خدمات یکپارچه را در زمان راهاندازی توصیف میکنند. پروتکل به عنوان چند ریلی معرفی میشود: استیبلکوینها به علاوهفیاتکارتها از طریق مکانیزمهای توکن استرایپ، با افزونههایی که برای لایتنینگ از طریق لایتاسپارک و پشتیبانی از شبکه کارت از طریق ویزا توصیف شدهاند.
این پوشش ریلی دلیل عملی است که تیمها به MPP روی میآورند زمانی که به "یک نقطه پایانی نیاز دارند که هم کریپتو و هم کارتها را بپذیرد."
تجارت وابستگی است. منابع به طور مداوم MPP را به استرایپ به علاوه تمپو مرتبط میکنند، که به این معنی است که ادغام ابزارها و سطح تجاری استرایپ را به ارث میبرد، اما همچنین به وابستگی پلتفرم نیز دچار میشود. این وابستگی انتزاعی نیست. به عنوان فرضیات عملیاتی ظاهر میشود: مدیریت چرخه حیات جلسه، زمانهای انقضا و اینکه چه اتفاقی میافتد وقتی که یک مشتری در میانه جلسه قبل از پایان خراب میشود.
از منظر ریسک، MPP یک خط اعتباری جلسهای با تسویه در پایان جلسه است. فروشنده در معرض خطر بیشتری نسبت به x402 قرار دارد زیرا ارزش میتواند در طول جلسه قبل از تکمیل تسویه نهایی ارائه شود. بازده، هزینههای کمتری در هر تعامل و یک مدل صورتحساب است که برای استفادههای با فرکانس بالا مانند استنتاج، محاسبات، یا هر منبع اندازهگیری شدهای که تسویه در هر تماس بر جریان کار غالب باشد، مناسب است.
AP2 الزامات مجوز و حسابرسی را تعیین میکند.
AP2 در دستهای متفاوت از x402 و MPP قرار دارد. این تسویه را اجرا نمیکند. این تعریف میکند که چگونه یک عامل ثابت میکند که مجوز خرج کردن را داشته است، با استفاده از مجوزهای امضا شده رمزنگاری شده بر اساس اعتبارنامههای قابل تأیید W3C که طراحی شدهاند تا قابل تأیید و غیرقابل انکار باشند.
AP2 سه نوع مجوز را تعریف میکند که به طور واضح با حالتهای خرید رایج عاملها مطابقت دارد:
1. مجوز قصد: خودمختاری واگذار شده، جایی که یک انسان یا سازمان قوانین را از قبل امضا میکند و عامل بعداً در چارچوب آنها خرج میکند. 2. مجوز سبد خرید: سبدهای تأیید شده توسط کاربر، جایی که یک انسان بر روی مجموعه خاصی از اقلام و مجموعها قبل از پرداخت امضا میکند. 3. مجوز پرداخت: سیگنالی به شبکههای پرداخت و صادرکنندگان که یک عامل درگیر بوده است، بنابراین سیستمهای ریسک و انطباق میتوانند تراکنش را به طور مناسب ارزیابی کنند.
به همین دلیل است که مقایسههای "پروتکل AP2" اغلب از ریل خارج میشود. AP2 با x402 یا MPP در زمینه توان عملیاتی یا هزینهها رقابت نمیکند زیرا یک ریل نیست. این پوشش مجوزدهی و حسابرسی است که "عامل پول خرج کرده" را به "عامل پول را تحت یک مجوز امضا شده خرج کرده" تبدیل میکند.
AP2 همچنین به وضوح به عنوان قابل ترکیب با ریلهای تسویه چارچوببندی شده است. منابع پیادهسازیهای AP2 را با استفاده از x402 در زیر از طریق یک افزونه A2A x402 توصیف میکنند، که مثال عینی معماری لایهای است که اکوسیستم به سمت آن همگرا میشود. در آن پشته، AP2 سطح کنترل است و x402 یا MPP ریل تسویهای است که بر اساس هر جریان کاری انتخاب میشود.
برای سازندگان، پیامد عملی این است که تصمیمات AP2 تصمیمات حکومتی هستند: چه محدودیتهایی وجود دارد، چه کسی آنها را امضا میکند و چه شواهدی برای بررسیهای بعدی حفظ میشود. این سطح طراحی متفاوتی از "چگونه USDC را جابجا کنیم" است.
انتخاب x402، MPP، AP2 برای موارد استفاده
چارچوب تصمیمگیری به این شکل نیست که "یک پروتکل را انتخاب کنید." بلکه به این شکل است که "یک ارگونومی تسویه را انتخاب کنید، سپس یک موضع مجوز را انتخاب کنید." نقشه لایهای xpay این را به وضوح بیان میکند و چشمانداز پرداخت عاملی در حال حاضر اینها را به عنوان اجزای قابل ترکیب در نظر میگیرد.
یک روش مفید برای انتخاب این است که تصمیم بگیرید چه چیزی باید تطبیق داده شود و کجا اجازه انباشت ریسک وجود دارد.
1. x402 را زمانی انتخاب کنید که محصول به رسیدهای اتمی در هر تماس و وضعیت حداقلی نیاز دارد. این برای APIهای پرداختی و خدمات عامل به عامل مناسب است که در آن قرارداد تمیزترین حالت "پرداخت، سپس دریافت پاسخ" است. مسیر شکست برای طراحی، حلقه 402 → پرداخت → تلاش مجدد است، از جمله ایپموتنتی و اینکه چه اتفاقی میافتد وقتی مشتری بعد از پرداخت تلاش مجدد میکند. 2.
MPP را انتخاب کنید زمانی که هزینه تسویه در هر درخواست به گلوگاه تبدیل میشود و حسابداری در سطح جلسه قابل قبول است. این برای استفادههای با فرکانس بالا که در آن یک شیء جلسه از قبل طبیعی است مناسب است. مسیر شکست برای طراحی، انقضای جلسه، استفاده جزئی و بازیابی از خرابی قبل از بسته شدن جلسه است. 3. AP2 را اضافه کنید زمانی که سیستم به محدودیتهای قابل اثبات و مسیرهای حسابرسی برای هزینههای عامل نیاز دارد.
این در تأمین مالی شرکتی، محیطهای تنظیمشده و هر جریان کاری که "چه کسی این را مجاز کرده است" باید با یک اثر امضا شده پاسخ داده شود، نه یک ردیف پایگاه داده، رایج است.
معماریهای ترکیبی رایج به طور مستقیم از آن انتخابها پیروی میکنند:
1. AP2 + x402: الزامات محدودیتها و دریافتکنندگان را تعریف میکنند، سپس هر تماس API به صورت اتمی بر روی استیبلکوینها تسویه میشود. 2. AP2 + MPP: الزامات بودجه جلسه و محدودیتها را تعریف میکنند، سپس جریانهای استفاده در یک جلسه پیشمجوز داده شده و به صورت گروهی تسویه میشوند. 3.
x402 + MPP در کنار هم: یک عامل هر دو ریل را صحبت میکند، با استفاده از x402 برای نقاط پایانی با فرکانس پایین یا بدون مجوز و MPP برای بارهای کاری با فرکانس بالا یا جایی که پذیرش کارت لازم است.
نزدیک به پایین پشته، اینها فقط راههای مختلفی برای پیادهسازی رفتار پروتکل پرداخت ماشین هستند. نزدیک به بالا، آنها لولهکشی هستند که اقتصاد عامل را توضیح میدهد و بدون تبدیل هر عامل به یک ریسک هزینه نامحدود، قابل اجرا میکند.
جمعبندی
من شاهد بودهام که تیمها هفتهها وقت خود را صرف بحث درباره "x402 در مقابل MPP" میکنند گویی که این یک جنگ استاندارد برنده-همه است، سپس از قسمت خستهکننده شگفتزده میشوند: تطبیق و مسیرهای شکست. باگ پرهزینه، پرداخت در مسیر خوشحال نیست. این خرابی میانجلسه، تلاش مجدد پس از 402، یا درخواست حسابرسی شش ماه بعد است که وقتی کسی میپرسد چرا به یک عامل اجازه داده شده است که اصلاً هزینه کند.
اگر سیستم به ریسک اعتباری محکم و رسیدهای تمیز در هر تماس نیاز دارد، مدل اتمی x402 سخت است که شکست بخورد. اگر حجم تماس هزینه تسویه در هر درخواست را به محدودیت تبدیل کند، تسویه جلسهای MPP تغییر ارگونومیک واضحی است، با معاملهای که ریسک در داخل جلسه تا بسته شدن زندگی میکند. AP2 بخشی است که اکثر مردم آن را اشتباه طبقهبندی میکنند.
این لایه الزامات است که هر ریل را در یک بررسی شرکتی قابل دفاع میکند زیرا هزینه را به مجوز امضا شده و قابل بررسی تبدیل میکند.
منابع
پرسشهای متداول
آیا AP2 یک پروتکل پرداخت مانند x402 یا MPP است؟
خیر. AP2 یک چارچوب مجوز و حکمرانی است که اثبات میکند یک عامل اجازه داشته است تا تحت شرایط تعریفشده هزینه کند. این پروتکل پول جابجا نمیکند و باید با یک ریل تسویه مانند x402 یا MPP جفت شود.
x402 چگونه بر روی HTTP 402 Payment Required کار میکند؟
یک سرور به درخواست با HTTP 402 و شرایط پرداخت برای منبع پاسخ میدهد. مشتری یک پرداخت استیبلکوین را امضا کرده و مدرک پرداخت را به درخواست بازیابیشده پیوست میکند. یک تسهیلگر میتواند پرداخت را تأیید و تسویه کند تا سرور بتواند پاسخ پرداختشده را بهطور ایمن ارسال کند.
MPP چگونه از x402 برای پرداختهای ماشین به ماشین متفاوت است؟
x402 هر درخواست را بهطور مستقل تسویه میکند که این امر حسابداری را جزئی و ریسک را محدود نگه میدارد. MPP یک جلسه پیشمجوز دادهشده را باز میکند، در طول استفاده میکروپرداختها را استریم میکند و در پایان جلسه بهصورت دستهای تسویه میکند. این امر هزینههای هر تعامل را کاهش میدهد اما آشتی و ریسک را در لایه جلسه متمرکز میکند.
سه نوع مجوز AP2 چیست و چه مواردی را پوشش میدهد؟
AP2 مجوزهای نیت را برای خودمختاری واگذار شده تحت قوانین از پیش تعیین شده، مجوزهای سبد خرید برای سبدهای تأیید شده توسط کاربر با اقلام و مجموعهای صریح، و مجوزهای پرداخت برای علامتگذاری مشارکت عامل به شبکههای پرداخت و صادرکنندگان تعریف میکند. این مجوزها بهطور مشترک هزینههای خودمختار، تسویه تأیید شده توسط انسان و علامتگذاری ریسک در سطح شبکه را پوشش میدهند.
آیا AP2 میتواند با x402 یا MPP در همان معماری استفاده شود؟
بله. منابع پیادهسازیهای AP2 را توصیف میکنند که از x402 در زیرساخت از طریق یک گسترش A2A x402 استفاده میکنند، که الگوی لایهای است که بسیاری از تیمها به آن نزدیک میشوند. همان مفهوم مجوز همچنین میتواند یک ریل مبتنی بر جلسه مانند MPP را با محدود کردن بودجهها و شرایط برای جلسه احاطه کند.
