چگونه عامل‌های هوش مصنوعی معاملات را به صورت زنجیره‌ای اجرا می‌کنند: نیت‌ها، ERC-4337 و مجوزهای توکن

چگونه عوامل هوش مصنوعی معاملات را در زنجیره اجرا می‌کنند به لوله‌کشی بستگی دارد، نه "جادوی هوش مصنوعی": عامل نیت‌های امضا شده‌ای تولید می‌کند که سایر بازیگران آن‌ها را به تغییرات وضعیت اتریوم تبدیل می‌کنند. معامله تنها در صورتی تسویه می‌شود که دو ریل به درستی متصل شده باشند، ریل اجرای (معامله EOA یا عملیات کاربر ERC-4337) و ریل مجوز توکن (مجوزها یا مجوزهای سبک Permit2).

نکات کلیدی

• یک عامل هوش مصنوعی به تنهایی در اتریوم "معامله" نمی‌کند. این عامل باید کنترل شود یا مجوز داشته باشد از یک حساب زنجیره‌ای که می‌تواند تماس‌های قرارداد و انتقال توکن‌ها را تحریک کند.
• دو ریل اجرایی وجود دارد: یک معامله منبع‌دار EOA، یا یک عملیات کاربر ERC-4337 که یک بسته‌بندی‌کننده آن را به قرارداد EntryPoint برای تأیید و اجرا ارسال می‌کند.
• تعویض‌ها نیاز به مجوز صریح هزینه توکن قبل از حرکت توکن دارند، و Permit2 انتقال مجوزها زمان انقضا و nonceهای غیر(مالک، توکن، خرج‌کننده) را به آن مجوز اضافه می‌کند تا آن را محدود و از تکرار محافظت کند.
• برای اندازه‌های بزرگتر یا کنترل‌های سختگیرانه‌تر، یک Safe می‌تواند وظایف را با اجازه دادن به عامل برای پیشنهاد یک معامله در حالی که چندین مالک قبل از اجرا تأیید می‌کنند، جدا کند.

چگونه یک عامل هوش مصنوعی می‌تواند در زنجیره معامله کند

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

این واقعیت اصلی پشت معاملات خودکار زنجیره‌ای است: "عامل" یک موتور تصمیم‌گیری خارج از زنجیره است و بخش زنجیره‌ای یک حساب به علاوه یک درخواست امضا شده است که شبکه آن را می‌پذیرد.دو ریل در یک کاوشگر بلاک ظاهر می‌شوند. اولین ریل، ریل اجرایی است، به این معنی که چگونه درخواست به یک معامله اتریوم تبدیل می‌شود. در اتریوم، تنها یک حساب خارجی می‌تواند یک معامله را منبع‌گذاری کند، زیرا یک EOA توسط یک کلید خصوصی

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

تعویض "فقط تماس با یک روتر" نیست. توکن‌های ERC-20 به دلیل اینکه یک تابع تعویض فراخوانی شده است، حرکت نمی‌کنند. آن‌ها حرکت می‌کنند زیرا مالک توکن مجوز هزینه را به یک خرج‌کننده داده است و سپس آن خرج‌کننده از آن مجوز برای انتقال توکن‌ها استفاده می‌کند.

اگر عامل در حال ساخت اجرای عامل زنجیره‌ای باشد که به ERC-20ها مربوط می‌شود، باید هر بار هر دو ریل را حل کند: (1) زنجیره را برای اجرای تماس‌ها و (2) اطمینان حاصل کند که قرارداد صحیح مجوز دارد تا مقدار صحیحی از توکن‌ها را برداشت کند.این جایی است که محصولات دیفای تجمع می‌کنند: اجرای خودکار در UX کیف پول، با محافظت‌هایی در اطراف آنچه امضا می‌شود و آنچه هزینه می‌شود. مدل ذهنی مفید همان چیزی است که پشت اجرای خودکار زنجیره‌ای دیفای به عنوان یک دسته وجود دارد: عامل نیت‌ها را تألیف می‌کند و زیرساخت آن نیت‌ها را به تسویه تبدیل می‌کند.خط لوله اجرایی ERC-4337

ERC-4337 "ارسال یک معامله" را به یک زنجیره تأمین با بازیگران اضافی تبدیل می‌کند و این فرضیات قابلیت اطمینان را تغییر می‌دهد. به جای اینکه یک EOA یک معامله را به استخر عمومی ارسال کند، یک کیف پول ERC-4337 یک شیء عملیات کاربر را می‌سازد و آن را به یک بسته‌بندی‌کننده می‌دهد که بعداً یک معامله زنجیره‌ای را به یک قرارداد EntryPoint منفرد ارسال می‌کند.

جریان انتها به انتها به راحتی به عنوان یک توالی قابل پیگیری است:

1. عامل یک بارگذاری آماده می‌کند. برای یک کیف پول عامل که یک حساب هوشمند ERC-4337 است، بارگذاری یک عملیات کاربر با زمینه‌هایی مانند فرستنده، nonce، callData،

محدودیت‌های گاز

، پارامترهای هزینه و یک امضا است. 2. عامل عملیات کاربر را به یک استخر مبدل جایگزین ارسال می‌کند. کیف پول‌ها معمولاً آن را به یک نقطه انتهایی RPC بسته‌بندی‌کننده ارسال می‌کنند نه به استخر معاملات استاندارد اتریوم. 3. یک بسته‌بندی‌کننده جمع‌آوری و شبیه‌سازی می‌کند. بسته‌بندی‌کننده‌ها استخر جایگزین را زیر نظر دارند، عملیات کاربر کاندید را شبیه‌سازی می‌کنند و تصمیم می‌گیرند کدام یک را در یک بسته قرار دهند. 4.

بسته‌بندی‌کننده معامله زنجیره‌ای را منبع‌گذاری می‌کند. بسته‌بندی‌کننده با یک آرایه از عملیات کاربر، EntryPoint.handleOps را فراخوانی می‌کند و آن تماس معامله واقعی اتریوم است که در یک بلاک قرار می‌گیرد. 5. EntryPoint تأیید می‌کند، سپس اجرا می‌کند. EntryPoint یک الگوی دو مرحله‌ای را دنبال می‌کند: آن بر روی حساب validateUserOp را فراخوانی می‌کند (و validatePaymasterUserOp اگر یک paymaster متصل باشد) و تنها سپس مرحله اجرا را اجرا می‌کند. 6.

هزینه از طریق پیش‌پرداخت‌ها یا یک paymaster تسویه می‌شود. ERC-4337 اجازه می‌دهد یک قرارداد Paymaster هزینه را با بازپرداخت به بسته‌بندی‌کننده تحت قوانین تعریف شده تأمین کند.برای مکانیک‌های عامل تجاری هوش مصنوعی

، نکته کلیدی فرمت امضا نیست. این است که چه کسی مسئول گنجاندن است. با ERC-4337، "اجرا شده توسط عامل" زمانی نیست که عامل امضا می‌کند. این زمانی است که EntryPoint اجرا می‌کند و این به رفتار بسته‌بندی‌کننده و قوانین paymaster بستگی دارد اگر هزینه تأمین شود.چگونه عوامل مجوز هزینه توکن را دریافت می‌کنندحرکت توکن جایی است که بیشتر طراحی‌های عامل ریسک را نشت می‌دهند، زیرا مجوزها تمایل دارند که از معامله فراتر بروند.

مدل تمیز این است که ابتدا مجوز، سپس اجرا. ERC-4337 می‌تواند آن‌ها را به یک تسویه فشرده کند با بسته‌بندی چندین عمل در یک عملیات کاربر واحد، اما مجوزدهی هنوز باید صریح و محدود باشد.

Permit2

انتقال مجوز Uniswap یک مجموعه مشخص از اصول برای این لایه است. این سه نقطه ورودی اصلی را پشتیبانی می‌کند: تأیید (تنظیم مجوزها در زنجیره)، مجوز (تنظیم مجوزها از طریق یک امضا) و transferFrom (هزینه زمانی که مجوزهای معتبر قبلاً وجود دارند). تفاوت مهم در مقابل عادت قدیمی "تأیید حداکثر برای همیشه" این است که مجوزهای Permit2 می‌توانند با استفاده از یک زمان انقضا محدود شوند.

Permit2 همچنین یک دسته محافظت از تکرار عملی را ارائه می‌دهد که عوامل می‌توانند واقعاً از آن استفاده کنند. طرح nonce آن nonceها را برای هر مالک، هر توکن و هر خرج‌کننده افزایش می‌دهد و در یک نقشه مجوز بسته‌بندی می‌شود. این بدان معناست که یک مجوز فقط "آیا مالک یک بار امضا کرده است" نیست، بلکه "آیا مالک این پنجره هزینه خاص را برای این خرج‌کننده امضا کرده است و آیا آن nonce قبلاً مصرف شده است." مجوز Permit2 از امضاهای EOA، امضاهای فشرده EIP-2098 و امضاهای قرارداد EIP-1271 پشتیبانی می‌کند، که وقتی مالک یک حساب هوشمند به جای یک EOA است، مهم است.برای اینکه عوامل چگونه در دیفای معامله می‌کنند، این الگوی عملیاتی است که زمانی که چیزها به دقت ساخته می‌شوند، ظاهر می‌شود:

1. عامل یک پنجره هزینه باریک درخواست می‌کند. مقدار محدود است، انقضا کوتاه است، خرج‌کننده خاص است. 2. عامل مجوزدهی را با اجرا بسته‌بندی می‌کند. یک مجوز یا تأیید می‌تواند با تماس تعویض ترکیب شود تا مجوز بی‌استفاده نماند. 3. عامل تنها تحت آن پنجره از طریق transferFrom هزینه می‌کند. اگر پنجره منقضی شود، مجوز در زنجیره مرده است.

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

کنترل‌های چندامضایی و سیاست با Safe

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

جریان مستند Safe درباره انتقال‌ها صریح است. یک معامله ایجاد می‌شود، به سرویس معامله Safe پیشنهاد می‌شود، توسط سایر مالکان تأیید می‌شود و تنها سپس اجرا می‌شود. در راهنمای کیت پروتکل Safe، توالی به این صورت است: ایجاد یک شیء معامله، محاسبه هش معامله Safe، پیشنهاد آن به طوری که سایر مالکان بتوانند آن را ببینند، جمع‌آوری تأییدات (امضاها) از مالکان، سپس اجرا با executeTransaction.

این برای اجرای خودکار مهم است زیرا معنای "عمل عامل" را تغییر می‌دهد. عامل می‌تواند دقیقاً داده‌های تماس را برای یک تماس روتر DEX تولید کند، یا برای اجرای دسته‌ای یک حساب ERC-4337، اما Safe میز خطر است که تصمیم می‌گیرد آیا آن بارگذاری مجاز است که به زنجیره برسد. این مکان تمیزی برای اجرای سیاست‌هایی است که منابع برای عوامل استاندارد نمی‌کنند، مانند محدود کردن خرج‌کنندگان جدید، نیاز به تأییدات اضافی برای توکن‌های جدید، یا محدود کردن اندازه.

Safe همچنین با الگوهای کلید جلسه در لایه حساب به خوبی کار می‌کند. حساب‌های ERC-4337 می‌توانند طرح‌های امضا مختلف را در validateUserOp تأیید کنند و یک کلید جلسه می‌تواند یکی از آن طرح‌ها باشد. نکته این نیست که کلمه کلیدی است. نکته این است که یک کلید کوتاه‌مدت می‌تواند برای اقدامات باریک مجاز باشد در حالی که مالکان بلندمدت کنترل نهایی را حفظ می‌کنند.

برای تیم‌هایی که سیستم‌های دیفای می‌سازند، این تفاوت بین "عامل می‌تواند معامله کند" و "عامل می‌تواند معاملات را پیش‌نویس کند" است. پیش‌نویس کردن ارزان است. اجرا جایی است که تغییرات وضعیت غیرقابل برگشت اتفاق می‌افتد.

تجارت‌های طراحی و حالت‌های شکست

اولین حالت شکست، سردرگمی در نوع پیام‌ها است. یک UserOperation یک تراکنش اتریوم نیست. این داده‌ای در یک ممپول جایگزین است تا زمانی که یک bundler آن را در یک فراخوان EntryPoint.handleOps بسته‌بندی کند. به همین دلیل است که حساب‌های قرارداد هوشمند نمی‌توانند "فقط تراکنش‌ها را مانند EOAها ارسال کنند." تنها EOAها تراکنش‌ها را ایجاد می‌کنند و حساب‌های هوشمند زمانی عمل می‌کنند که فراخوانی شوند.

دومین حالت شکست، رفتار با bundler به عنوان زیرساخت نامرئی است. ERC-4337 فرضیات را از "کیف من پخش می‌کند" به "آیا یک bundler من را شامل می‌شود" تغییر می‌دهد. توصیف Eco به وضوح بیان می‌کند که bundlerها ممپول جایگزین را زیر نظر دارند، شبیه‌سازی می‌کنند و بسته‌ها را ارسال می‌کنند، هزینه L1 را پرداخت کرده و از پیش‌پرداخت‌ها یا پرداخت‌کنندگان بازپرداخت می‌گیرند. اگر یک نقطه پایانی bundler خراب باشد، محدودیت نرخ داشته باشد یا از انجام عملیات خاصی امتناع کند، عامل می‌تواند به امضا ادامه دهد و هیچ چیزی تسویه نخواهد شد.

سومین حالت شکست، گسترش مجوزها است. تأییدهای نامحدود یک ویژگی تجاری نیستند. آن‌ها یک سطح ضرر دائمی هستند. زمان‌های انقضای Permit2 و nonceهای غیر(مالک، توکن، خرج‌کننده) کنترل‌های زنجیره‌ای هستند که می‌توانند آن سطح را محدود کنند، اما تنها در صورتی که ادغام از آن‌ها استفاده کند.

یک اشتباه رایج در ادغام، مجوز دادن به خرج‌کننده نادرست یا عبور دادن آدرس نادرست به یک فراخوان انتقال است، که Uniswap به عنوان یک ملاحظه امنیتی برای ادغام قراردادها به آن اشاره می‌کند.

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

خلاصه تجارت‌ها ساده است. EOAها ساده و مستقیم هستند اما کل سیستم را پشت یک کلید قرار می‌دهند. ERC-4337 به دسته‌بندی، اعتبارسنجی سفارشی و گاز حمایت‌شده اضافه می‌کند، اما یک زنجیره تأمین تراکنش با bundlerها، EntryPoint و پرداخت‌کنندگان اختیاری معرفی می‌کند. Safe به طور عمدی اصطکاک ایجاد می‌کند و آن اصطکاک زمانی مهم است که اندازه اهمیت دارد.

در نزدیکی پایین هر سند معماری جدی، موضوع گسترده‌تر هنوز اجرای خودکار زنجیره‌ای است و سوال این است که کدام ریل و کدام لایه سیاست سیستم می‌تواند در شرایط فشار واقعاً پشتیبانی کند.نکتهمن شاهد بوده‌ام که تیم‌ها بر روی بخش "AI" وسواس دارند و سپس اشتباه پرهزینه‌ای را ارسال می‌کنند: یک تأیید توکن وسیع و بلندمدت که با زیرساخت شکننده جفت شده است. وقتی چیزی اشتباه می‌شود، به ندرت به این دلیل است که مدل یک معامله را توهم کرده است.

این به این دلیل است که لایه مجوز اجازه داده است که یک خرج‌کننده بیشتر از آنچه که قصد شده بود، برداشت کند، یا به این دلیل که زنجیره تأمین ERC-4337 در bundler متوقف شده و هیچ‌کس نظارت بر گنجاندن نداشته است.

وضعیت تمیز این است که هر بار این را مانند یک نمودار دو کلیدی در نظر بگیریم: اختیار اجرا و اختیار خرج. اگر طراحی نتواند در یک جمله پاسخ دهد که چه کسی تراکنش را ایجاد می‌کند (EOA در مقابل bundler از طریق EntryPoint) و دقیقاً چه چیزی خرج‌کننده می‌تواند برداشت کند (مقدار، انقضا، دامنه nonce)، پس سیستم "خودکار" نیست. این فقط بدون نظارت است.

منابع

QuickNode

Eco

Uniswap

Safe

• [@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop
• [@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop
• [@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop
• [@portabletext/react] Unknown block type "span", specify a component for it in the `components.types` prop