ERC-8004 و هویت عامل‌های هوش مصنوعی روی بلاک‌چین

ERC-8004 و هویت عامل‌های هوش مصنوعی روی بلاک‌چین

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

استاندارد ERC-8004 با عنوان «عامل‌های بدون نیاز به اعتماد قبلی» برای پاسخ به همین مسئله طراحی شده است. این استاندارد تلاش می‌کند یک لایه‌ی عمومی برای شناسایی، کشف، ثبت بازخورد و اعتبارسنجی عامل‌های هوش مصنوعی ایجاد کند؛ لایه‌ای که به یک شرکت، پلتفرم یا ارائه‌دهنده‌ی مدل خاص وابسته نباشد. با این حال، میان «ثبت یک شناسه روی بلاک‌چین» و «وجود یک عامل فعال، مفید و قابل اعتماد» فاصله‌ی مهمی وجود دارد که نباید در هیاهوی بازار نادیده گرفته شود.

بر اساس صفحه‌ی رسمی ERC-8004 در مخزن پیشنهادهای بهبود اتریوم، این استاندارد در تاریخ 13 August 2025 ایجاد شده و همچنان با وضعیت Draft منتشر می‌شود. بنابراین ERC-8004 را باید یک استاندارد نوظهور و در حال تکامل دانست، نه یک زیرساخت کاملاً تثبیت‌شده و نهایی. (eips.ethereum.org)

ERC-8004 دقیقاً چیست؟

ERC-8004 یک قرارداد یا توکن سرمایه‌گذاری نیست؛ بلکه مجموعه‌ای از رابط‌ها و قراردادهای استاندارد برای ایجاد ارتباط میان عامل‌های هوش مصنوعی و زیرساخت‌های بلاک‌چینی است. هدف آن این نیست که مدل هوش مصنوعی را روی اتریوم اجرا کند. در عوض، بلاک‌چین نقش دفتر عمومی هویت، سابقه و شواهد اعتبار را ایفا می‌کند.

نسخه‌ی پیشنهادی ERC-8004 سه رجیستری اصلی را تعریف می‌کند:

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

این طراحی، ERC-8004 را از پروتکل‌هایی مانند MCP و A2A متمایز می‌کند. MCP بیشتر درباره‌ی ارائه‌ی ابزار، منابع و قابلیت‌هاست و A2A بر ارتباط و هماهنگی میان عامل‌ها تمرکز دارد؛ اما ERC-8004 می‌خواهد به پرسش‌های «این عامل کیست؟»، «چه سابقه‌ای دارد؟» و «چه کسی عملکرد آن را بررسی کرده است؟» پاسخ بدهد. این توضیح در مقاله‌ی رسمی تیم هوش مصنوعی بنیاد اتریوم در تاریخ 7 January 2026 نیز به‌صراحت مطرح شده است. (ai.ethereum.foundation)

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

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

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

ERC-8004 تلاش می‌کند این مشکل را با ایجاد یک شناسه‌ی عمومی حل کند. این شناسه به خودی خود تضمین نمی‌کند که عامل خوب یا صادق است، اما امکان می‌دهد اطلاعات مربوط به آن در یک نقطه‌ی قابل بررسی ثبت شود. در چنین مدلی، عامل می‌تواند شناسه‌ی خود، نقاط دسترسی، سرویس‌های قابل ارائه، کیف‌پول‌ها، نام ENS یا شناسه‌های دیگر را در یک فایل ثبت‌نام معرفی کند.

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

رجیستری هویت چگونه کار می‌کند؟

رجیستری هویت ERC-8004 بر پایه‌ی ERC-721 و افزونه‌ی URIStorage طراحی شده است. در نتیجه، هویت عامل از نظر فنی به یک توکن غیرقابل‌تعویض شبیه است؛ با این تفاوت که هدف اصلی آن معامله‌گری یا کلکسیونی نیست، بلکه نمایش هویت یک عامل نرم‌افزاری است.

هر عامل یک agentId دریافت می‌کند. این شناسه در کنار آدرس رجیستری و شناسه‌ی شبکه، یک هویت قابل ارجاع ایجاد می‌کند. فایل ثبت‌نام عامل می‌تواند روی IPFS، یک دامنه‌ی وب، یا حتی به‌صورت داده‌ی درون‌زنجیره‌ای قرار گیرد.

این فایل می‌تواند اطلاعاتی مانند نام عامل، توضیح عملکرد، نقاط دسترسی A2A و MCP، کیف‌پول‌ها، دامنه‌های تأییدشده، پشتیبانی از x402 و مدل‌های اعتماد مورد استفاده را شامل شود. استاندارد، ساختار انعطاف‌پذیری برای این فایل پیشنهاد می‌کند و اجازه می‌دهد چندین سرویس و نقطه‌ی دسترسی در آن معرفی شود. (eips.ethereum.org)

با این حال، باید میان اثبات مالکیت شناسه و اثبات توانایی عامل تفاوت گذاشت. مالک یک NFT می‌تواند اطلاعاتی را به آن متصل کند، اما این موضوع به‌تنهایی نشان نمی‌دهد که نقطه‌ی دسترسی معرفی‌شده فعال است، پاسخ‌های درست ارائه می‌کند یا در برابر حمله مقاوم است. خود متن ERC-8004 نیز تأکید می‌کند که ثبت‌نام رمزنگاری‌شده، عملکردی‌بودن قابلیت‌های اعلام‌شده یا غیرمخرب‌بودن عامل را تضمین نمی‌کند. (eips.ethereum.org)

شهرت؛ از امتیاز ساده تا مسئله‌ی سیبیل

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

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

مهاجم می‌تواند تعداد زیادی کیف‌پول ایجاد کند و از آن‌ها برای ثبت امتیاز مثبت برای عامل خود استفاده کند. این حمله که معمولاً با عنوان حمله‌ی سیبیل شناخته می‌شود، باعث می‌شود تعداد بازخوردها با کیفیت واقعی تعاملات اشتباه گرفته شود. ERC-8004 تلاش می‌کند با فیلترکردن بازخورد بر اساس آدرس مشتری و طراحی سازوکارهای پاسخ و لغو بازخورد، این مشکل را کاهش دهد؛ اما پروتکل پایه به‌تنهایی نمی‌تواند تشخیص دهد که آیا یک مشتری واقعاً خدمت دریافت کرده است یا خیر.

یک مطالعه‌ی تجربی منتشرشده در arXiv در سال 2026، داده‌های ERC-8004 را در اتریوم، BNB Smart Chain و Base تا تاریخ 13 May 2026 بررسی کرد. این پژوهش نتیجه گرفت که در وضعیت بررسی‌شده، بسیاری از بازخوردها به تعاملات قابل راستی‌آزمایی متصل نیستند و بخش قابل‌توجهی از فعالیت بررسی‌کنندگان الگوهای هماهنگ یا سیبیلی نشان می‌دهد. این یافته نشان می‌دهد که تعداد بازخوردها، به‌تنهایی معیار قابل اتکایی برای اعتماد نیست. (arxiv.org)

اعتبارسنجی چه تفاوتی با شهرت دارد؟

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

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

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

با این حال، بسیاری از مدل‌های اعتبارسنجی پیشنهادی هنوز در سطح معماری و نمونه‌سازی هستند. ERC-8004 رابط ثبت درخواست و پاسخ را فراهم می‌کند، اما امنیت، مشوق اقتصادی، جریمه‌ی اعتبارسنج و روش حل اختلاف را به پروتکل‌های تخصصی دیگر واگذار می‌کند. بنابراین وجود رجیستری اعتبارسنجی به معنای آن نیست که همه‌ی عامل‌های ثبت‌شده واقعاً اعتبارسنجی شده‌اند.

رابطه‌ی ERC-8004 با x402

x402 یک پروتکل پرداخت مبتنی بر HTTP است که از کد وضعیت 402 یا «Payment Required» استفاده می‌کند. در جریان معمول، سرویس به مشتری اعلام می‌کند که برای دسترسی به یک منبع باید پرداخت انجام شود؛ مشتری مجوز پرداخت را امضا می‌کند؛ پرداخت از طریق یک تسهیل‌گر بررسی و تسویه می‌شود؛ و سپس سرویس منبع درخواستی را ارائه می‌کند.

طبق توضیح Cloudflare در تاریخ 23 September 2025، x402 برای پرداخت‌های برنامه‌محور میان مشتری و سرویس طراحی شده و می‌تواند بدون حساب کاربری سنتی، اشتراک ماهانه یا API key مورد استفاده قرار گیرد. این کاربرد برای عامل‌هایی مهم است که باید به‌صورت خودکار برای داده، ابزار یا API هزینه پرداخت کنند. (blog.cloudflare.com)

تقسیم نقش میان دو استاندارد روشن است: ERC-8004 می‌تواند بگوید «این عامل کیست و چه سابقه‌ای دارد»، در حالی که x402 می‌تواند بگوید «پرداخت برای دریافت این منبع چگونه انجام شود». در یک سناریوی ترکیبی، عامل سرویس‌دهنده هویت ERC-8004 خود را در پیام پرداخت معرفی می‌کند و عامل مشتری نیز در صورت تمایل شناسه‌ی خود را ارائه می‌دهد.

اما باید توجه داشت که اتصال ERC-8004 و x402 هنوز به معنای وجود یک استاندارد نهایی و فراگیر نیست. در مخزن رسمی x402، پیشنهاد یا مسئله‌ی مربوط به افزونه‌ی «8004-reputation» در تاریخ 8 January 2026 مطرح شده است. این افزونه می‌تواند پرداخت موفق، تحویل منبع و هویت عامل را به ثبت بازخورد پیوند دهد، اما صفحه‌ی مربوطه نشان می‌دهد که این موضوع در قالب یک کار در حال توسعه مطرح شده است، نه یک قابلیت نهایی و جهان‌شمول. (github.com)

آنچه امروز واقعاً کار می‌کند

تا تاریخ 3 October 2026، بخش‌هایی از ERC-8004 از نظر مفهومی و فنی روشن‌تر از بخش‌های دیگر هستند. ثبت یک شناسه‌ی زنجیره‌ای، اتصال آن به فایل ثبت‌نام، معرفی نقاط دسترسی و ثبت رویدادهای بازخورد، اجزایی هستند که می‌توان آن‌ها را با قراردادهای هوشمند و ابزارهای شاخص‌گذاری پیاده‌سازی کرد.

همچنین شواهد پژوهشی نشان می‌دهد که رجیستری‌ها در شبکه‌های عمومی مستقر شده‌اند و داده‌ی قابل تحلیل تولید کرده‌اند. یک مطالعه‌ی دیگر که در تاریخ 10 June 2026 منتشر شد، نخستین 10,000 عامل ثبت‌شده در اتریوم را بررسی کرد. داده‌های این مطالعه از بازه‌ی 29 January 2026 تا 9 April 2026 گردآوری شده بود. (arxiv.org)

اما کارکرد واقعی باید با احتیاط تفسیر شود. همان مطالعه گزارش کرد که در نمونه‌ی 10,000تایی، فقط 67 عامل رکورد خدمت قابل مشاهده داشتند، 628 عامل بازخورد دریافت کرده بودند و فقط 19 عامل هم‌زمان نشانه‌هایی از فراداده، سرویس، بازخورد و ثبت میان‌زنجیره‌ای داشتند. این ارقام نشان می‌دهند که تعداد شناسه‌های ساخته‌شده با تعداد عامل‌های فعال و قابل استفاده یکسان نیست. (arxiv.org)

چه چیزی هنوز آزمایشی است؟

بخش آزمایشی ERC-8004 فقط به فناوری قرارداد هوشمند محدود نمی‌شود؛ مسئله‌ی اصلی، طراحی اقتصاد اعتماد است. هنوز مشخص نیست چه الگوریتمی باید بازخوردهای مختلف را با هم ترکیب کند، چگونه باید اعتبار بررسی‌کنندگان سنجیده شود و چه سازوکاری می‌تواند مانع خرید یا جعل شهرت شود.

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

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

مقایسه‌ی ERC-8004 با رویکردهای جایگزین

شواهد استفاده؛ میان رشد ثبت‌نام و استفاده‌ی واقعی

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

مطالعه‌ی منتشرشده در ژوئن 2026، سهم عامل‌هایی را که فایل ثبت‌نام معتبر و دست‌کم یک نقطه‌ی خدمت فعال داشتند، در سه شبکه‌ی بررسی‌شده به‌ترتیب حدود 3 درصد در اتریوم، 4 درصد در BNB Smart Chain و 15 درصد در Base گزارش کرد. این نتایج نشان می‌دهد که آمار خام ثبت‌نام، معیار مناسبی برای سنجش بلوغ اقتصاد عامل‌ها نیست. (arxiv.org)

این یافته‌ها به معنای شکست ERC-8004 نیست. هر استاندارد جدید ابتدا باید هویت و قالب داده‌ی مشترک ایجاد کند و سپس ابزارهای کشف، ارزیابی، بیمه، داوری و پرداخت پیرامون آن شکل بگیرند. اما برای تحلیل‌گران و کاربران، تفاوت میان «تعداد agentIdها»، «تعداد فایل‌های معتبر»، «تعداد سرویس‌های فعال» و «تعداد تعاملات پرداخت‌شده» باید همیشه حفظ شود.

ریسک‌ها و محدودیت‌ها

مهم‌ترین محدودیت ERC-8004 این است که بلاک‌چین فقط چیزی را که ثبت شده، قابل مشاهده و قابل حسابرسی می‌کند؛ نه این‌که واقعیت بیرونی را به‌طور خودکار تضمین کند. اگر فایل ثبت‌نام ادعای نادرستی داشته باشد، ثبت هش آن ادعا را درست نمی‌کند.

• حملات سیبیل: مهاجم می‌تواند با کیف‌پول‌های متعدد بازخورد جعلی ایجاد کند.
• تمرکز مالکیت: تعداد زیادی هویت ممکن است تحت کنترل چند کیف‌پول یا تیم محدود باشد.
• ابهام در کیفیت امتیازها: امتیازهای مختلف ممکن است مقیاس، زمینه و تعریف یکسانی نداشته باشند.
• ریسک فایل‌های خارج از زنجیره: IPFS یا دامنه‌ی معرفی‌شده ممکن است حذف، تغییر یا از دسترس خارج شود.
• ریسک قرارداد هوشمند: نقص در قرارداد رجیستری یا ابزارهای پیرامونی می‌تواند هویت و بازخورد را تحت تأثیر قرار دهد.
• عدم تضمین رفتار آینده: عامل می‌تواند پس از دریافت بازخورد مثبت، نسخه، مدل یا سیاست اجرایی خود را تغییر دهد.
• ریسک حریم خصوصی: پیوند دادن هویت عامل با پرداخت‌ها، مشتریان و سوابق عملکردی می‌تواند اطلاعات حساس تولید کند.

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

این موضوع به چه کسی مربوط است؟

ERC-8004 برای توسعه‌دهندگان عامل‌هایی اهمیت دارد که می‌خواهند سرویسشان در چند پلتفرم و شبکه قابل کشف باشد. این استاندارد می‌تواند به آن‌ها کمک کند هویت، قابلیت‌ها، کیف‌پول‌ها و مدل‌های اعتماد خود را با قالبی مشترک معرفی کنند.

ارائه‌دهندگان API، بازارهای عامل‌ها، سازندگان ابزارهای شاخص‌گذاری، شرکت‌های اعتبارسنج، پروتکل‌های پرداخت و پروژه‌های بیمه‌ی دیجیتال نیز از گروه‌های مهم هستند. این بازیگران می‌توانند روی داده‌های عمومی هویت و بازخورد، خدماتی مانند امتیازدهی تخصصی، غربال‌گری سیبیل، رتبه‌بندی کاربردی و مدیریت ریسک بسازند.

برای کاربران عادی و سرمایه‌گذاران حوزه‌ی کریپتو، ERC-8004 بیشتر به‌عنوان زیرساختی برای درک روندهای آینده اهمیت دارد، نه یک سیگنال خرید یا فروش. وجود تعداد زیادی هویت ثبت‌شده نباید به‌تنهایی به‌عنوان نشانه‌ی موفقیت اقتصادی یا پذیرش گسترده تفسیر شود.

جمع‌بندی

ERC-8004 یکی از تلاش‌های مهم برای حل مسئله‌ی اعتماد میان عامل‌های هوش مصنوعی است. ارزش اصلی آن در ایجاد هویت قابل حمل، قالب مشترک برای معرفی سرویس و امکان ثبت بازخورد و اعتبارسنجی در یک محیط عمومی است.

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

رابطه‌ی ERC-8004 با x402 نیز از نظر معماری قابل توجه است: اولی می‌تواند هویت و سابقه را فراهم کند و دومی مسیر پرداخت ماشین‌به‌ماشین را. اما اتصال این دو هنوز در حال توسعه است و نباید نمونه‌های آزمایشی یا پیشنهادهای فنی را با استانداردی کاملاً نهایی و پذیرفته‌شده اشتباه گرفت.

سوالات متداول

ERC-8004 چه مشکلی را حل می‌کند؟

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

آیا ERC-8004 قابل اعتماد بودن یک عامل را تضمین می‌کند؟

خیر. ERC-8004 هویت، بازخورد و چارچوب اعتبارسنجی ارائه می‌کند، اما مالکیت شناسه یا ثبت اطلاعات روی زنجیره به‌تنهایی عملکرد، امنیت یا صداقت عامل را تضمین نمی‌کند.

آیا ERC-8004 همان x402 است؟

خیر. ERC-8004 بر هویت، شهرت و اعتبارسنجی عامل تمرکز دارد، در حالی که x402 یک پروتکل پرداخت مبتنی بر HTTP برای پرداخت برنامه‌محور میان مشتری و سرویس است. این دو می‌توانند در یک سامانه کنار یکدیگر استفاده شوند.

آیا تعداد ثبت‌نام‌های ERC-8004 نشان‌دهنده‌ی تعداد عامل‌های فعال است؟

خیر. پژوهش‌های منتشرشده در سال 2026 نشان داده‌اند که بخشی از شناسه‌های ثبت‌شده فاقد فایل معتبر، سرویس فعال یا سابقه‌ی تعامل هستند. بنابراین باید ثبت‌نام، سرویس فعال و استفاده‌ی واقعی را جداگانه سنجید.

وضعیت استاندارد ERC-8004 چیست؟

بر اساس صفحه‌ی رسمی پیشنهاد ERC-8004، این استاندارد در وضعیت Draft قرار دارد. قراردادها، ابزارها و افزونه‌های پیرامونی ممکن است در طول زمان تغییر کنند؛ بنابراین توسعه‌دهندگان باید همیشه آخرین مستندات رسمی را بررسی کنند.

منابع

• Ethereum Improvement Proposals؛ ERC-8004: Trustless Agents
• Ethereum Foundation؛ dAI Team
• x402 Foundation؛ مخزن رسمی x402
• Cloudflare Blog؛ معرفی x402 Foundation و پرداخت‌های عامل‌محور
• arXiv؛ Can Trustless Agents Be Trusted? An Empirical Study of the ERC-8004 Decentralized AI Agent Ecosystem
• arXiv؛ From Agent Identity to Agent Economy: Measuring the Operational Readiness of ERC-8004 AI Agents

سلب مسئولیت

این مطلب صرفاً با هدف آموزشی و خبری تهیه شده است و توصیه‌ی مالی، سرمایه‌گذاری، خرید، فروش یا استفاده از هیچ دارایی یا پروژه‌ای محسوب نمی‌شود. استانداردهای مرتبط با عامل‌های هوش مصنوعی و بلاک‌چین هنوز در حال توسعه هستند و استفاده از آن‌ها می‌تواند با ریسک‌های فنی، امنیتی، اقتصادی و حقوقی همراه باشد.