تصور کنید یک ربات معامله‌گر هوشمند داشته باشید که هر ثانیه قیمت‌ها را چک می‌کند، اما هر بار که می‌خواهد تراکنشی را امضا کند، کل مرورگر شما را برای ۸ ثانیه منجمد می‌کند. این دقیقاً کابوسی بود که توسعه‌دهندگان پروژه Casper Carbon با آن دست‌وپنجه نرم می‌کردند تا یک بازار دارایی‌های واقعی (RWA) را بر پایه عامل‌های هوش مصنوعی (AI Agents) راه‌اندازی کنند. این پروژه ثابت کرد که عامل‌های AI می‌توانند به‌طور автоном مدیریت بازارهای RWA را بر عهده بگیرند، به شرطی که کیف پول زیرساختی و منطق قیمت‌گذاری از پیچیدگی‌ها و کدهای زائد پاکسازی شوند.
این پروژه در زمان حساسیت به گذار از مدل‌های زبانی ساده به سمت گردش‌های کاری عامل‌محور (Agentic) عرضه شده است؛ جایی که تصمیم یک مدل باید به یک تراکنش واقعی در بلاک‌چین تبدیل شود. چالش اصلی در این مسیر، «آخرین کیلومتر» است؛ یعنی نقطه‌ای که تصمیم هوش مصنوعی باید به یک تراکنش امضا شده روی زنجیره تبدیل شود، بدون اینکه باعث کرش کردن مرورگر کاربر شود یا قیمت دارایی‌ها را مختل کند. همان‌طور که در تحلیل قبلی ما درباره‌ی امنیت مدل‌های بازمتن اشاره کردیم، نقطه شکست این سیستم‌ها معمولاً در همین لبه‌ی برخورد کد فنی با رابط کاربری کاربر اتفاق می‌افتد.
طبق گزارش تحلیل فنی منتشر شده در ۲۶ ژوئیه ۲۰۲۶ در وب‌سایت dev.to، تیم توسعه‌دهنده در ابتدا از ویجت CSPR.click استفاده می‌کرد که یک ابزار رابط کاربری پیش‌ساخته بود. در ظاهر، این ادغام ایده‌آل به نظر می‌رسید: کافی بود یک تگ اسکریپت CDN اضافه کنید، یک div برای کانتینر قرار دهید و تابع showTopBar() را فراخوانی کنید تا یک پاپ‌آپ صیقل‌خورده از کیف پول ظاهر شود. اما در عمل، این انتخاب منجر به ایجاد گلوگاه‌های عملکردی شدید شد:
- حجم ۲ مگابایتی بسته CDN: این باندل شامل یک کتابخانه کامل UI، دارایی‌های SVG و یک Runtime بود که یک Virtual DOM مشابه React را درون صفحه رندر می‌کرد و باعث می‌شد هر بار بارگذاری صفحه متوقف شود.
- نشتی حافظه (Memory Leaks): این SDK ده‌ها شنونده رویداد (Event Listener) ایجاد می‌کرد بدون اینکه آن‌ها را پاکسازی کند. پس از سه بار جابجایی بین صفحات، Node.js هشدار
MaxListenersExceededWarningرا صادر می‌کرد و تب مرورگر به‌شدت کند می‌شد. - کرش‌های مبتنی بر Regex: تحلیل‌گر پیام‌های داخلی از یک عبارت منظم (Regex) استفاده می‌کرد که در مواجهه با پاسخ‌های خاص کیف پول Casper دچار «پس‌گرد catastrophic» (Catastrophic Backtracking) می‌شد. این اتفاق باعث می‌شد صفحه برای ۸ ثانیه کاملاً منجمد شود و سپس خطای "Regex execution time exceeded" ظاهر شود.
- فشار سخت‌افزاری: ترکیب عملیات Polling (نظرسنجی مداوم) و چرخه شدید شنونده‌ها باعث می‌شد فن‌های MacBook M3 حتی در حالت بی‌کار و صرفاً هنگام حضور در صفحه بازار، به ۵۰۰۰ دور در دقیقه (RPM) برسند.
توسعه‌دهندگان پس از سه روز عیب‌یابی برای ایزوله کردن علت کرش Regex، تصمیم گرفتند کل کتابخانه UI را دور بریزند و مستقیماً با window.CasperWalletProvider() ارتباط برقرار کنند (که هنگام نصب افزونه Casper Wallet در دسترس است). آن‌ها با تمرکز بر سه فراخوانی ساده‌ی API — یعنی requestConnection() برای درخواست اتصال، getActivePublicKey() برای دریافت کلید عمومی و امضای Deployها — حجم کد مربوط به اتصال کیف پول را از چندین مگابایت به تنها ۴۰ خط کد TypeScript در فایل wallet.tsx کاهش دادند. آن‌ها یک نکته حیاتی و ظریف را افشا کردند: برخلاف مستندات قدیمی که پیشنهاد می‌کرد از window.location.origin استفاده شود، در نسخه‌های جدید افزونه باید Provider به‌صورت ساده (window.CasperWalletProvider()) فراخوانی شود تا از بروز خطا جلوگیری شود.
بعد از بهینه‌سازی کیف پول، تیم روی جریان خرید (Purchase Flow) تمرکز کرد. این فرآیند توالی مشخصی را دنبال می‌کند: کاربر روی دکمه «خرید» کلیک می‌کند، سرور یک Deploy امضا‌نشده را می‌سازد و آن را به صورت JSON برمی‌گرداند، کاربر آن را از طریق افزونه کیف پول Casper امضا می‌کند و در نهایت Deploy امضا شده به Endpoint مربوط به RPC کیسپر ارسال می‌شود.
در این مرحله، تیم با دو مانع فنی در SDK مواجه شد:
- متدهای استاتیک: آن‌ها کشف کردند که کلاس
Deployدرcasper-js-sdkبه جای استفاده از متد instance، از یک متد استاتیکtoJSON(deploy)استفاده می‌کند. اشتباه در تشخیص این مورد باعث می‌شد پاسخ‌ها بدون هیچ خطایی، اما کاملاً خالی ارسال شوند. - تله‌های مربوط به بزرگی حروف (Casing): SDK در نام‌گذاری‌ها ناسازگار است. در حالی که منطق برنامه‌نویسی کاربر را به سمت
newCLUint256()می‌برد، اما SDK دقیقاًnewCLUInt256()(با حرف I بزرگ) را می‌طلبد. این موضوع نیاز به تکیه بر Typings (نوع‌بندی‌ها) به جای اتکای صرف به Auto-complete محیط IDE را برجسته کرد.
بزرگ‌ترین چالش however در لایه‌ی عامل‌ها بود. این پروژه از سه عامل هوش مصنوعی اصلی استفاده می‌کند: یک عامل تأییدکننده (Verifier)، یک عامل تطبیق (Compliance) و یک عامل بازار (Market Agent). عامل بازار طراحی شده بود تا قیمت‌های اعتبارات روی زنجیره را با قیمت لحظه‌ای (Spot) در Carbonmark مقایسه کند و هر لیستی که بیش از ۵۰ واحد پایه (bps) انحراف داشت را لغو کند.
بعد از دور مقدماتی، عامل سالم به نظر می‌رسید و در هر چرخه پیام «۱۲ لیست را اصلاح کردم» را ثبت می‌کرد. اما در واقعیت، صفحه بازار هیچ لیست فعال را نشان نمی‌داد. تیم متوجه یک باگ «خرابی داده‌های خاموش» در فایل agents/src/market.ts شد که دلیل آن عدم تبدیل صحیح ارزها بود.
به‌طور مشخص، عامل قیمت‌های دلاری (USD) را به اشتباه به عنوان mote (واحد کوچک‌ترین تقسیم CSPR) می‌شناخت. اگر قیمت یک کرِدیت Carbonmark ۱۰ دلار بود، عامل مقدار externalPriceMotes را ۱۰ میلیارد محاسبه می‌کرد. اما اگر یک لیست ۱۵ CSPR برای هر تن بود و قیمت هر CSPR مقدار ۰.۱۰ دلار داشت، قیمت منصفانه باید ۱۰۰ میلیارد mote می‌بود. عامل مقدار ۱۵ میلیارد (روی زنجیره) را با ۱۰ میلیارد (تبدیل غلط دلار به mote) مقایسه می‌کرد، اختلاف ۵۰۰ واحد پایه را محاسبه می‌کرد و چون ۵۰۰ از آستانه ۵۰ واحد بیشتر بود، تک‌تک لیست‌ها را لغو می‌کرد.
برای حل این مشکل، تیم تابع اختصاصی fetchCsprUsdPrice() را پیاده‌سازی کرد که داده‌ها را از CoinGecko (هدف: "casper-network" $
ightarrow$ usd) می‌گیرد. این منطق جدید شامل موارد زیر است:
- تبدیل صحیح: فرمول به
(externalPrice / csprPrice) * 1,000,000,000به‌روزرسانی شد. - تاب‌آوری (Resiliency): یک حافظه موقت (Cache) با زمان انقضای ۶۰ ثانیه‌ای (TTL) و مکانیسم تلاش مجدد سه مرحله‌ای با تأخیر ۲ ثانیه‌ای (backoff) برای تضمین پایداری عامل اضافه شد.
همین رویکرد اصلاحی در عامل تأییدکننده (Verifier) نیز به کار رفت. پیش از این، Verifier مقدار price_per_token: "15000000000" (۱۵ CSPR) را به‌صورت سخت‌افزاری (Hardcode) در کد داشت که با نوسان ۵۰ درصدی بازار در یک هفته، بلافاصله منسوخ شد. اکنون Verifier از Promise.all برای دریافت هم‌زمان داده‌های Carbonmark و CoinGecko استفاده می‌کند تا ارزش منصفانه بازار را تعیین کند و تنها در صورتی که دریافت داده‌ها از API شکست بخورد، به مقدار پیش‌فرض ۱۵ CSPR بازگردد.
هم‌زمان، داشبورد مدیریتی برای مدیریت وضعیت زنده عامل‌ها مورد بازبینی عملکردی قرار گرفت:
- بهینه‌سازی Polling: تیم یک hook سفارشی به نام
usePollرا با استفاده از یک ref به نامinflightپیاده کرد. اگر درخواستی هنوز در جریان بود، hook چرخه بعدی را نادیده می‌گرفت تا فشار روی CSPR.cloud کاهش یابد. بازه‌های زمانی نظرسنجی برای وضعیت زنجیره و فعالیت عامل‌ها از ۱۰ ثانیه به ۳۰ ثانیه افزایش یافت. - اندیکاتورهای وضعیت: نقاط سبز و خاکستری اکنون فعالیت عامل را نشان می‌دهند. نقطه زمانی سبز می‌شود که یک Deploy در ۴۰ ثانیه اخیر از طریق حساب آن عامل ارسال شده باشد.
- مدیریت خطای پیشرفته: هر صفحه اکنون از یک کامپوننت
ErrorCardدر مسیرweb/src/components/shared.tsxاستفاده می‌کند تا از سفید شدن رابط کاربری در اثر Reject شدن‌های مدیریت نشده‌ی Promiseها جلوگیری شود. - تأیید یکپارچگی (Integrity Verification): یک بخش جدید (Hero Section) مدل تعهد SHA-256 را توضیح می‌دهد. هر قضاوت مدل زبانی (LLM) به‌صورت هش روی زنجیره ثبت می‌شود؛ سپس مرورگر هش را دوباره محاسبه می‌کند تا صحت و یکپارچگی تصمیم AI تأیید شود.
در نهایت، لایه‌ی قراردادهای هوشمند بدون تغییر باقی ماند. سیستم همچنان بر چهار قرارداد Odra متکی است که در دور مقدماتی مستقر شده بودند:
AgentRegistry(ثبت عامل‌ها)CarbonProjectRegistry(ثبت پروژه‌های کربن)CarbonCreditToken(توکن اعتبار کربن)CarbonMarketplace(بازار خرید و فروش)
تیم همچنین یک رمزگشای وضعیت (State Decoder) سفارشی را حفظ کرد که از هش blake2b256 برای ایندکس فیلد و کلید مپینگ، در ترکیب با دسریالیزه کردن دستی bytesrepr برای خواندن وضعیت زنجیره استفاده می‌کند.
این معماری ثابت می‌کند که در سیستم‌های RWA عامل‌محور، ناپایداری معمولاً در لایه‌ی تعامل (Interaction Layer) است، نه در منطق روی زنجیره. با ساده‌سازی پل اتصال کیف پول و اصلاح اوراکل قیمت، تیم توانست با موفقیت بازار خود را روی Casper Testnet فعال کند.
گام بعدی شما
- اگر در حال ساخت گردش‌های کاری عامل‌محور هستید، تمام نقاط تماس مقادیر محاسباتی AI با اعداد صحیح (Integers) در بلاک‌چین را بازبینی کنید تا خطاهای تبدیل ارز تکرار نشود.
- وابستگی‌های SDK حجیم را با تماس‌های مستقیم API جایگزین کنید تا از کندی مرورگر (Client-side bloat) جلوگیری کنید.
- برای تأیید تصمیمات AI، از مدل تعهد هش (Hash Commitment) استفاده کنید تا سیستم شما شفاف و قابل حسابرسی باشد.
- می‌توانید پیاده‌سازی کامل را بررسی کرده و دمو را از طریق مخزن متن‌باز پروژه در
github.com/harishkotra/casper-carbonاجرا کنید.
اما داستان سخت‌افزاری این تحول حتی شگفت‌انگیزتر است — به تحلیل ما درباره‌ی تراشه‌های Blackwell مراجعه کنید.
گفتگو