توضیح کلیدهای جلسه و مجوزهای عامل: واگذاری بر اساس قرارداد
کلیدهای جلسه و مجوزهای عامل راهی هستند برای اینکه یک حساب هوشمند بتواند یک مأموریت محدود را به یک برنامه یا عامل هوش مصنوعی واگذار کند که توسط منطق اعتبارسنجی کیف پول به صورت زنجیرهای اجرا میشود. هدف، اجرای خودکار زنجیرهای بدون تبدیل یک عامل به یک امضاکننده با قدرت کامل است، با استفاده از محدودیتهایی مانند بازههای زمانی، فهرستهای مجاز و سقف هزینهای که قرارداد میتواند از تجاوز به آن خودداری کند.
نکات کلیدی
- یک کلید جلسه یک گواهی امضای موقتی با اختیارات محدود است که به گونهای طراحی شده است که یک تأیید بتواند مجموعهای محدود از اقدامات را در یک دامنه تعریف شده پوشش دهد.
- بهروزرسانی ایمنی ناشی از حسابهای هوشمند است که سیاست را بهصورت زنجیرهای اجرا میکنند، نه از این که کلید "موقت" باشد.
- ERC-4337 اجرای واگذاری شده را از طریق UserOperations، bundlers و یک قرارداد EntryPoint استاندارد عملی میکند، با paymasterهای اختیاری که میتوانند حمایت کنند.گاز.
- ERC-8196 مرحله بعدی طراحی کیف پول عامل را پیشنهاد میکند: اثبات رمزنگاری شده انطباق با سیاست به علاوه یک زنجیره هش شدهحسابرسیردیابی فعالیت جلسه.
مبانی کلیدهای جلسه و مجوزهای عامل
واگذاری با یک تقسیم ساده آغاز میشود: یک اعتبارنامه کنترل کامل را حفظ میکند و اعتبارنامه دیگر یک وظیفه محدود را دریافت میکند. در یک تنظیم حساب هوشمند، کلید اصلی مالک به عنوان "ریشه" باقی میماند، در حالی که یک کلید جلسه برای یک بازه و دامنه خاص تولید یا مجاز میشود. آن دامنه همان چیزی است که مردم به آن مجوزهای عامل یا دسترسی محدود عامل میگویند. اپلیکیشن یا عامل میتواند امضا کند، اما فقط در داخل جعبهای که قرارداد کیف پول شناسایی میکند.
این چارچوب برای اجرای خودکار بر روی زنجیره اهمیت دارد زیرا عوامل قبلاً میدانند چگونه تراکنشها را امضا کنند. حالت شکست این است که به آنها یک کلید دسترسی کامل بدهید و امیدوار باشید که میزبان، درخواست، درخت وابستگی و رابط کاربری هرگز به شما خیانت نکنند. کلیدهای جلسه وضعیت معکوس هستند. آنها یک بودجه ریسک هستند که میتوانید قیمتگذاری کنید: زمان + اهداف + محدودیتهای ارزش، با قرارداد کیف پول که به عنوان نگهبان عمل میکند.
یک مدل ذهنی مفید "مدرک، نه کلید اصلی" است. مدرک میتواند چند در را در چند ساعت برای یک کار خاص باز کند. اگر مدرک نشت کند، شعاع انفجار بهطور طراحی شده محدود است. به همین دلیل است که عبارت کلیدهای جلسه در رمزنگاری اغلب در کنار حسابهای هوشمند و کیف پولهای جاسازی شده ظاهر میشود. کل هدف این است که تأییدهای تکراری کمتری بدون دادن کنترل دائمی و نامحدود به یک برنامه داشته باشیم.
دو جزئیات وجود دارد که به راحتی ممکن است نادیده گرفته شوند. اول، "موقت" خاصیت امنیتی نیست. دامنه است. دوم، کلیدهای جلسه در حال حاضر در همه جا استاندارد نیستند. پیادهسازیها هنوز به صورت کیف پول به کیف پول است، به این معنی که معانی دقیق ابطال، فهرستهای مجاز و موارد خاص در میان ارائهدهندگان متفاوت است.
چگونه حسابهای هوشمند مجوزها را اجرا میکنند
ERC-4337 تغییراتی در محل انجام مجوزها ایجاد میکند. به جای اینکه یک EOA یک تراکنش عادی را به ممپول عمومی ارسال کند، یک حساب هوشمند انتظار یک UserOperation را دارد که میتواند آن را بر اساس قوانین خود تأیید کند قبل از اینکه چیزی اجرا شود. عامل، UserOperation را با یک کلید مجاز امضا میکند، یک bundler UserOperationها را تجمیع میکند و bundler یک قرارداد EntryPoint استاندارد را فراخوانی میکند که آنها را پردازش میکند. سیستم مجوز در لایه تأیید حساب هوشمند قرار دارد، نه در رابط کاربری.
این معماری است که چرا "به اپ اعتماد کن" میتواند با "قرارداد رد میکند" جایگزین شود. RebelFi این تغییر را با دو خط که ارزش حفظ کردن به صورت کلمه به کلمه را دارند، به تصویر میکشد: "به کد اپلیکیشن عامل اعتماد کن که بیش از حد خرج نکند" در مقابل "قرارداد سیاست خرج کردن را بدون توجه به اینکه اپلیکیشن چه کاری انجام میدهد، اجرا میکند." جمله دوم مکانیزم واقعی است. اگر سیاست بگوید نه، عملیات تأیید نمیشود و EntryPoint آن را اجرا نمیکند.
پرداختکنندگان بخش دیگری هستند که احساس همیشه فعال بودن را برای نمایندگان ایجاد میکنند. در ERC-4337، یک پرداختکننده میتواند هزینه گاز را تأمین کند، به این معنی که یک نماینده که USDC دارد و هیچاتریومهنوز هم میتوان تراکنش انجام داد اگر یک پرداختکننده برای پذیرش USDC به منظور پوشش هزینههای گاز ETH پیکربندی شده باشد. این یک ترفند ظاهری UX نیست. این نیاز عملی به نگهداشتن یک موجودی جداگانه ETH را حذف میکند تا عامل بتواند به کار خود ادامه دهد.
این همچنین جایی است کهeip 7702به گفتگو وارد میشود. ZeroDev استک خود را به عنوان پشتیبانی از هر دو ERC-4337 و eip 7702 قرار میدهد، با کلیدهای جلسه به عنوان یک عنصر UX درجه یک برای اتوماسیون. موضوع مشترک همان است: انتقال واگذاری به یک کیف پول که میتواند سیاست را اجرا کند، به جای اینکه آن را به عنوان یک وعده خارج از زنجیره رها کند.
دامنهها و محدودیتهای مجوز مشترک
یک سیاست جلسه به اندازه دکمههایی که ارائه میدهد و اجرا میکند خوب است. مثال مشخص RebelFi یک الگوی تمیز برای اینکه مجوزهای عامل چگونه باید به نظر برسند زمانی که کسی واقعاً سرمایهای در خطر دارد: حداکثر هزینه به ازای هر تراکنش (مثال: ۵۰ دلار)، یک لیست دریافتکنندگان تأیید شده، یک پنجره انقضا (مثال: ۲۴ ساعت) و یک بودجه کل جلسه (مثال: ۵۰۰ دلار) قبل از تأیید مجدد. آن آخرین مورد مهم است زیرا "ضربات کوچک زیاد" میتواند جمع شود حتی زمانی که هر انتقال فردی محدود شده باشد.
این دکمهها به این شکل نقشهبرداری میشوند که چگونه حسابهای هوشمند نیت را تأیید میکنند:
۱. محدودیتهای زمانی. یک پنجره validAfter و validUntil کلید را در خارج از جلسه بیفایده میکند، که ارزش دزدیدن آن را کاهش میدهد. ۲. محدودیتهای هدف. لیستهای مجاز دریافتکنندگان یا قراردادهای مجاز مانع از استفاده مجدد از کلید برای انتقالهای دلخواه میشود. ۳. محدودیتهای ارزش. یک سقف هزینه به ازای هر تراکنش آسیب یکباره را محدود میکند، در حالی که یک بودجه کل آسیب قطرهای را محدود میکند.
لغو، پشتیبانی عملی است. در معماری RebelFi، کلید امضای ریشه کنترل کامل حساب را حفظ میکند و میتواند کلیدهای جلسه را در هر زمان لغو کند. این تفاوت بین واگذاری و تسلیم است. کلید مالک "شناسایی را به اشتراک نمیگذارد." این یک مأموریت صادر میکند که میتواند لغو شود.
یک نکته دیگر: کلیدهای جلسه اغلب به عنوان "موقت" توصیف میشوند.کلیدهای خصوصی، اما این توصیف ناقص است. کلید فقط یک امضا کننده است. ایمنی از این ناشی میشود که حساب هوشمند از تأیید عملیاتهایی که سیاست را نقض میکنند، خودداری میکند. بدون این اجرای زنجیرهای، "موقت" هنوز هم میتواند درون پنجره فاجعهبار باشد.
جریانهای کاری نماینده فعال شده توسط واگذاری
واگذاری فقط به خاطر راحتی نیست. این تغییر میدهد که چه جریانهای کاری بدون تبدیل هر مرحله به یک مراسم امضای جدید ممکن است. مورد استفاده واضح پرداختهای نماینده است. یک کیف پول نماینده میتواند مجاز باشد که به مجموعهای از ارائهدهندگان خدمات تأیید شده پرداخت کند در حالی که از انتقال وجوه به آدرسهای دلخواه مسدود شده است.
بستهبندی اتمی قفل دوم است. حسابهای هوشمند ERC-4337 میتوانند تراکنشهای بستهبندی اتمی را اجرا کنند، بنابراین توالیهایی مانند برداشت از-بازده + پرداخت برای خدمات به طور همزمان موفق یا ناموفق میشوند. این مهم است زیرا از وضعیت نیمهکامل جلوگیری میکند. اگر بخش پرداخت ناموفق باشد، بخش برداشت به حالت قبلی برمیگردد و وجوه در یک وضعیت میانی ناخواسته باقی نمیمانند.
بستهبندی همچنین به عنوان یک اهرم هزینه قابل اندازهگیری ظاهر میشود. RebelFi دوانتقال ERC-20را به طور جداگانه حدود 2 × 65,000 گاز در مقابل حدود 1 × 110,000 گاز بستهبندی شده تخمین میزند که حدود 15% صرفهجویی است. بر روی صفحه، این تفاوت بین یک جریان کاری نماینده است که از نظر اقتصادی در مقیاس قابل اجرا است و یکی که هزینهها را هدر میدهد.
حمایت از گاز حلقه را برای عوامل "بدون ETH" به هم متصل میکند. با یک پرداختکننده، عامل میتواند در حالی که فقط USDC را در اختیار دارد، عمل کند، به شرطی که پرداختکننده USDC را برای گاز بپذیرد. این پاسخ عملی به این تصور غلط است که عوامل باید ETH را برای عملکرد در اختیار داشته باشند.
موضعگیری ZeroDev با این دیدگاه جریان کار سازگار است. مستندات آن کلیدهای جلسه را به عنوان بخشی از یک ابزار UX حساب هوشمند گستردهتر که شامل دستهبندی و انتزاع گاز است، چارچوببندی میکند و ادعا میکند که بیش از 6 میلیون حساب هوشمند را در بیش از 50 شبکه برای بیش از 200 تیم تأمین میکند. این ادعای مقیاس یک تضمین امنیتی نیست، اما نشانهای است که این الگوها در حال حاضر در استکهای تولیدی استفاده میشوند.
اجرای مبتنی بر سیاست و مسیرهای حسابرسی
ERC-8196 واضحترین بیان از جایی است که مجوزهای عامل در حال حرکت هستند: کیفپولهایی که فقط زمانی اقداماتی را انجام میدهند که با اثبات رمزنگاری شدهای همراه باشند که نشان دهد اقدام با سیاست تعریفشده توسط مالک مطابقت دارد. این فقط "تنظیم محدودیتها در یک UI" نیست. این "اثبات انطباق در زمان اجرا" است، با کیفپول به عنوان نقطه اجرایی.
این پیشنهاد زمینههای سیاست مورد نیاز را مشخص میکند که به نظر میرسد نسخهای رسمی از سیاستهای جلسه امروز باشد: اقدامات مجاز، قراردادهای مجاز و مسدود شده، حداکثر ارزش هر تراکنش، یک پنجره اعتبار و یک دروازه حداقل امتیاز تأیید. همچنین یک مفهوم مسیر حسابرسی غیرقابل تغییر و زنجیرهای از هش برای فعالیت جلسه معرفی میکند، جایی که هر ورودی حسابرسی شامل یک هش قبلی برای یکپارچگی است.
ERC-8196 به پیادهسازیها اجازه میدهد تا ورودیها را خارج از زنجیره ذخیره کنند و بهطور دورهای ریشهها را در زنجیره منتشر کنند، که یک معامله عملی بین هزینه و قابلیت تأیید است.
این پایان بازی است که توسط پایاننامه اشاره شده است: کلیدهای جلسه تنها زمانی به طور معناداری ایمن میشوند که کیفپول بتواند سیاست را در زنجیره اجرا کند و خندق بعدی انطباق قابل تأیید به علاوه قابلیت حسابرسی است. اگر میزبان یک عامل به خطر بیفتد، "گزارشها میگویند که رفتار کرده است" کافی نیست. یک مسیر قابل شناسایی از دستکاری به همراه اجرای مبتنی بر سیاست نزدیکتر به موضعی است که پلتفرمهای تنظیمشده و اپراتورهای جدی میخواهند.
دو نکته احتیاطی باید در یک نفس بیان شوند. ERC-8196 بهطور صریح در حال بررسی همتا است، بنابراین رابط و الزامات ممکن است تغییر کنند. بهطور جداگانه، حتی یک استاندارد کامل خطر پیادهسازی را از بین نمیبرد. منطق اعتبارسنجی کیفپول، بررسیهای تأیید و لولهکشی حسابرسی هنوز باید به درستی ساخته شوند.
ریسکها، نکات احتیاطی و بهترین شیوهها
تصور غلط پرهزینه این است که فکر کنیم یک کلید جلسه به دلیل موقتی بودن ایمن است. محدودیتهای زمانی کمک میکنند، اما یک دامنه کاملاً باز در داخل پنجره هنوز هم یک دامنه کاملاً باز است. یک کلید 24 ساعته که میتواند به هرآدرس منتقل شودیک دکمه تخلیه ۲۴ ساعته است.
دومین تصور نادرست قابلیت حمل است. کلیدهای جلسه در حال حاضر در همه جا استاندارد نیستند و پیادهسازیها از کیف پولی به کیف پول دیگر متفاوت است. این بدان معناست که "مجوزهای عامل" میتوانند در محصولات مشابه به نظر برسند در حالی که در لبهها رفتار متفاوتی دارند، از جمله رفتار ابطال و اینکه چگونه فهرستهای مجاز به طور دقیق اجرا میشوند.
سومین تصور نادرست عملیاتی است: عوامل برای کار کردن به ETH نیاز دارند. پرداختکنندگان ERC-4337 میتوانند هزینه گاز را تأمین کنند و به یک عامل که USDC دارد و هیچ ETH ندارد اجازه میدهند تا معامله کند اگر پرداختکننده برای پذیرش USDC پیکربندی شده باشد.
بهترین شیوه این است که سیاستهایی مانند محدودیتهای ریسک بنویسید، نه مانند سوئیچهای ویژگی:
۱. با یک سقف هزینه کوچک برای هر معامله شروع کنید. این سریعترین راه برای محدود کردن آسیب یکباره است. ۲. از یک فهرست مجاز سخت برای دریافتکنندگان یا قراردادها استفاده کنید. اگر عامل نتواند هدف را در سیاست نام ببرد، نباید بتواند به آن دست بزند. ۳. پنجره اعتبار را کوتاه نگه دارید. انقضا ارزش یک کلید نشت شده را کاهش میدهد. ۴. یک بودجه کل جلسه اضافه کنید. این از "ضربات کوچک متعدد" جلوگیری میکند که حساب را خالی میکند.
بستهبندی همچنین یک ابزار ایمنی است، نه فقط یک ترفند گاز. بستههای اتمی احتمال پایان یافتن با وضعیت نیمهکامل را زمانی که یک جریان کاری عامل شامل مراحل متعدد است، کاهش میدهند.
ابطال باید به عنوان یک کنترل درجه یک در نظر گرفته شود. منابع به وضوح بیان میکنند که کلید ریشه مالک میتواند کلیدهای جلسه را ابطال کند. از نظر عملیاتی، این به معنای طراحی برای کلیدهای خاموش سریع و در نظر گرفتن nonceها و انقضا به عنوان کنترلهای اصلی برای کاهش مسائل تکرار و زمانبندی است.
این جایی است که داستان گستردهتر اجرای خودکار قرار میگیرد: طراحیهای برنده، واگذاری را از وعدههای برنامه خارج کرده و به محدودیتهای تحمیلی قرارداد منتقل میکنند، سپس انطباق قابل تأیید و یک مسیر حسابرسی به آن اضافه میکنند.
نتیجهگیری
من دیدهام که تیمها "کلید موقت" را به عنوان یک استدلال امنیتی در نظر میگیرند و سپس به آرامی یک جلسه را منتشر میکنند که در اهداف یا بودجه کاملاً باز بود. کلید منقضی شد، مطمئناً. اما وجوه هنوز در داخل پنجره ناپدید شدند. تنها نسخهای که معتبر است زمانی است که لایه اعتبارسنجی حساب هوشمند است که میگوید نه، نه یک میزبان عامل یا یک کادر تأیید در رابط کاربری.
پوزیشن تمیز این است که به یک کلید جلسه به عنوان یک مأموریت با قیمت فکر کنیم: زمان کوتاه، فهرست مجاز محدود، سقف هزینه کوچک برای هر تراکنش و یک بودجه کل سخت. اگر سیستم همچنین از دستهبندی اتمی و پرداختکنندگان پشتیبانی کند، عامل میتواند احساس کند که همیشه فعال است بدون اینکه همیشه خطرناک باشد.
این همان جهتی است که اجرای خودکار در زنجیره به آن نزدیک میشود و ERC-8196 اولین تلاش جدی برای گنجاندن انطباق و قابلیت حسابرسی به عنوان بخشی از وظیفه کیف پول است، نه یک فکر بعدی.
منابع
پرسشهای متداول
کلید جلسه در کیف پولهای رمزنگاری چیست؟
کلید جلسه یک کلید امضای موقت با اختیارات محدود برای عمل کردن به نمایندگی از یک کیف پول یا حساب هوشمند است. این کلید برای پوشش مجموعهای محدود از اقدامات پس از یک تأیید یکباره طراحی شده است که با محدودیتهایی مانند زمان، اهداف مجاز و محدودیتهای ارزش محدود شده است. کلید اصلی مالک کنترل کامل را حفظ میکند و میتواند جلسه را لغو کند.
چگونه مجوزهای عامل در زنجیره با ERC-4337 اجرا میشوند؟
در ERC-4337، عامل یک UserOperation را امضا کرده و آن را به یک bundler ارسال میکند که قرارداد canonical EntryPoint را فراخوانی میکند. EntryPoint منطق اعتبارسنجی حساب هوشمند را فعال میکند که در آن سیاستهای جلسه و مجوزهای عامل بررسی میشوند. اگر عملیات سیاست را نقض کند، اعتبارسنجی ناموفق است و اجرا نمیشود.
آیا عوامل هوش مصنوعی برای پرداخت هزینههای گاز به ETH نیاز دارند؟
ضروری نیست. پرداختکنندگان ERC-4337 میتوانند هزینههای گاز را تأمین کنند، بنابراین یک عامل که USDC دارد و هیچ ETH ندارد میتواند معامله کند اگر یک پرداختکننده برای پذیرش USDC در ازای پوشش هزینههای گاز ETH پیکربندی شده باشد. این نیاز به مدیریت یک موجودی جداگانه ETH فقط برای عملیاتی ماندن را از بین میبرد.
محدودیتهای دسترسی عامل با دامنه باید شامل چه مواردی باشد؟
یک سیاست معمول ترکیبی از محدودیتهای زمانی، لیستهای مجاز هدف و محدودیتهای ارزش است. مثال RebelFi شامل حداکثر هزینه برای هر معامله، یک لیست دریافتکنندگان تأیید شده، یک پنجره انقضای ۲۴ ساعته و یک بودجه کل جلسه قبل از تأیید مجدد است. بودجه کل مهم است زیرا بسیاری از معاملات کوچک میتوانند جمع شوند حتی زمانی که هر انتقال محدود شده است.
ERC-8196 چیست و چگونه به کیف پولهای عامل مربوط میشود؟
ERC-8196 یک پیشنهاد بررسی شده همتا برای کیف پولهای تأیید شده توسط عامل هوش مصنوعی است که فقط با اثبات رمزنگاری که اقدام با سیاست تعریف شده توسط مالک مطابقت دارد، اقداماتی را انجام میدهد. این پیشنهاد فیلدهای سیاست مورد نیاز مانند اقدامات مجاز، قراردادهای مجاز و مسدود شده، حداکثر ارزش برای هر معامله، یک پنجره اعتبار و یک دروازه حداقل نمره تأیید را مشخص میکند. همچنین یک مفهوم زنجیرهای از مسیر حسابرسی را مشخص میکند که شامل ذخیرهسازی اختیاری خارج از زنجیره و ریشههای دورهای در زنجیره است.
