توضیح ارتقای Pectra اتریوم: Account Abstraction در عمل چه تغییری برای توسعه‌دهندگان و کاربران ایجاد می‌کند؟

Pectra که مخفف Prague/Electra است، در اوایل ۲۰۲۵ روی شبکه اصلی اتریوم مستقر شد و تغییرات لایه اجرایی (Prague) را با ارتقاهای لایه اجماع (Electra) ترکیب می‌کند. این ارتقا مهم‌ترین تغییر از زمان Merge برای توسعه‌دهندگان است و بخش اصلی آن EIP-7702 است که یک شکل عملی و تدریجی از Account Abstraction را برای حساب‌های خارجی (EOA) فراهم می‌کند بدون اینکه کاربران مجبور به مهاجرت به کیف‌پول‌های Smart Contract جدید شوند.

سه EIP تعریف‌کننده Pectra

Pectra ده‌ها EIP را بسته‌بندی می‌کند، اما سه مورد بیشترین تأثیر واقعی را دارند:

• EIP-7702 — تنظیم کد برای EOA: به هر EOA اجازه می‌دهد برای مدت یک تراکنش به طور موقت کد Smart Contract را اتخاذ کند. این همان قفل Account Abstraction است که بیشتر توسعه‌دهندگان به آن اهمیت می‌دهند.
• EIP-7251 — افزایش حداکثر بالانس مؤثر اعتبارسنج: حداکثر بالانس مؤثر برای اعتبارسنج‌ها را از ۳۲ ETH به ۲٬۰۴۸ ETH افزایش می‌دهد. عملیات بزرگ استیکینگ می‌توانند به جای راه‌اندازی صدها گره ۳۲-ETH، اعتبارسنج‌ها را ادغام کنند و سربار p2p و پیچیدگی عملیاتی را به شدت کاهش دهند.
• EIP-7549 — انتقال شاخص کمیته به خارج از Attestation: بهبود کارایی در لایه اجماع که تعداد هش‌های مورد نیاز برای پردازش attestation را کاهش می‌دهد، از توان عملیاتی بالاتر پشتیبانی می‌کند و زمینه را برای مقیاس‌پذیری blob آینده از طریق افزایش تعداد blob در Pectra (از ۳/۶ به ۶/۹ هدف/حداکثر در هر بلاک) فراهم می‌کند.

Account Abstraction به چه معناست؟

اصطلاح Account Abstraction از سال ۲۰۱۶ در گفتمان اتریوم مطرح بوده است. به زبان ساده، یعنی دادن قابلیت‌های برنامه‌پذیری که Smart Contractها همیشه داشته‌اند به کیف‌پول‌های معمولی کاربران (EOA). قبل از Pectra، EOAها انعطاف‌ناپذیر بودند: فقط می‌توانستند با کلید خصوصی خود تراکنش امضا کنند، همیشه کارمزد را به ETH پرداخت می‌کردند و هر اقدام نیاز به یک تراکنش امضا شده جداگانه از صاحب کیف‌پول داشت.

EIP-7702 این انعطاف‌ناپذیری را می‌شکند و به EOA اجازه می‌دهد اجرای خود را به یک قطعه کد Smart Contract — یک نشانگر کد (code pointer) — که روی زنجیره وجود دارد، واگذار کند. این واگذاری از طریق یک نوع تراکنش جدید (SET_CODE_TX_TYPE = 0x04) تنظیم می‌شود و تا زمانی که لغو نشود معتبر است. این امر چهار قابلیت را ممکن می‌سازد که قبلاً غیرممکن بودند یا نیاز به راه‌حل‌های پیچیده داشتند:

• پرداخت کارمزد با هر توکن: یک قرارداد paymaster می‌تواند هزینه گس ETH را به نمایندگی از کاربر پوشش دهد و به برنامه‌ها اجازه دهد کارمزد را اسپانسر کنند یا USDC بپذیرند. کاربران دیگر برای تعامل با برنامه‌های اتریوم نیازی به ETH ندارند.
• تراکنش‌های دسته‌ای: چندین عملیات — approve + swap، approve + deposit + stake — در یک تراکنش اتمیک واحد ادغام می‌شوند. یک امضا، یک تأیید، یک بلاک.
• کلیدهای جلسه (Session Keys): یک DApp می‌تواند یک کلید محدود و زمان‌دار دریافت کند که اقدامات خاصی را مجاز می‌کند (مثلاً «تا ۵۰ USDC در این بازی برای ۲۴ ساعت آینده خرج کند») بدون اینکه کلید خصوصی اصلی در معرض دید قرار گیرد.
• بازیابی اجتماعی: کد واگذار شده می‌تواند منطق بازیابی multi-signature را پیاده‌سازی کند و به مخاطبان مورد اعتماد اجازه دهد در صورت گم شدن کلید خصوصی، دسترسی به کیف‌پول را بازیابی کنند.

مقایسه ملموس: قبل و بعد

تعویض توکن در یک DEX

قبل از Pectra: کاربر MetaMask را باز می‌کند، توکن را approve می‌کند (تراکنش ۱، گس به ETH، حدود ۱۵ ثانیه)، منتظر تأیید می‌ماند، سپس swap را اجرا می‌کند (تراکنش ۲، گس بیشتر به ETH، ۱۵ ثانیه دیگر). دو تأیید جداگانه، دو پرداخت گس، دو نقطه شکست احتمالی.

بعد از Pectra: کاربر روی «Swap» کلیک می‌کند. کیف‌پول به یک قرارداد بسته‌بندی واگذار می‌کند، یک تراکنش ارسال می‌کند که به طور اتمیک approve و swap را انجام می‌دهد و paymaster برنامه گس را به USDC می‌پردازد اگر کاربر ETH نداشته باشد. یک کلیک، یک تأیید.

راه‌اندازی کاربر جدید

قبل از Pectra: کاربر جدید ETH را از صرافی می‌خرد، به کیف‌پول برداشت می‌کند، منتظر می‌ماند تا ETH برسد، سپس می‌تواند با DAppها تعامل کند. نیاز به گس یک مانع ورودی بود که نرخ تبدیل را می‌کشت.

بعد از Pectra: DApp تراکنش‌های اولیه را از طریق یک paymaster اسپانسر می‌کند. کاربر می‌تواند فقط با یک استیبل‌کوین یا حتی یک تراکنش بدون گس شروع به کار کند. کیف‌پول یک EOA استاندارد تولید می‌کند — بدون مهاجرت به کیف‌پول Smart Contract، بدون پیچیدگی عبارت بازیابی فراتر از حالت معمول.

پیامدها برای پروتکل‌های DeFi

پروتکل‌های DeFi بدون نیاز به بازنویسی قراردادها، بهبود قابل توجهی در UX دریافت می‌کنند. پروتکل‌هایی که فرانت‌اند آگاه از EIP-7702 را پیاده‌سازی می‌کنند می‌توانند:

• جریان‌های «zap» یک‌کلیکی ارائه دهند که چندین عملیات DeFi را بسته‌بندی می‌کنند (مثلاً ETH به توکن استیکینگ مایع و سپس واریز به خزانه بازده) بدون جریان‌های تأیید چندمرحله‌ای.
• اسپانسری گس برای کاربران واجد شرایط پیاده‌سازی کنند (مثلاً کاربرانی با بیش از ۱٬۰۰۰ دلار TVL در پروتکل تراکنش‌های بدون گس دریافت کنند).
• از کلیدهای جلسه برای ربات‌های سفارش محدود و استراتژی‌های خودکار استفاده کنند — کاربران یک قرارداد خاص را برای اقدام از طرف خود در پارامترهای مشخص مجاز می‌کنند، بدون واگذاری حضانتی.

نکته حیاتی برای توسعه‌دهندگان پروتکل: نیازی به استقرار مجدد قراردادهای خود ندارید. EIP-7702 در سطح حساب عمل می‌کند. قراردادهای Solidity موجود شما تماس‌هایی را از چیزی دریافت می‌کنند که شبیه یک EOA است که مانند Smart Contract رفتار می‌کند — رابط بدون تغییر است.

توسعه‌دهندگان چه چیزی را باید تغییر دهند

برای توسعه‌دهندگان کیف‌پول، EIP-7702 یک نوع تراکنش جدید معرفی می‌کند که باید در جریان‌های امضا پشتیبانی شود. فیلد authorization_list در تراکنش‌های نوع ۰x04 شامل تاپل‌های امضا شده (chain_id, address, nonce) است که واگذاری کد را تنظیم می‌کند. کیف‌پول‌ها باید این موارد را به وضوح به کاربران نمایش دهند — واگذاری به یک قرارداد مخرب از نظر عملکردی معادل دادن کنترل کامل EOA برای آن تراکنش است.

برای توسعه‌دهندگان DApp، اولیه اصلی جدید رابط paymaster است (که در ERC-4337 استاندارد شده و اکنون از طریق EIP-7702 با EOAها قابل استفاده است). ادغام یک paymaster نیازمند انتخاب یک ارائه‌دهنده bundler (Pimlico، Alchemy، Biconomy و Stackup همگی از این پشتیبانی می‌کنند)، پیاده‌سازی منطق validatePaymasterUserOp و به‌روزرسانی فرانت‌اند برای ساخت نوع تراکنش جدید به جای یک تراکنش ساده EOA است.

پیاده‌سازی کلیدهای جلسه معمولاً از الگویی پیروی می‌کند که: (۱) کاربر یک واگذاری به قرارداد کلید جلسه امضا می‌کند، (۲) بک‌اند DApp کلید محدود و پارامترها را ذخیره می‌کند، (۳) اقدامات بعدی به عنوان تراکنش‌هایی ارسال می‌شوند که با کلید جلسه امضا می‌شوند نه EOA اصلی. کتابخانه‌هایی مانند permissionless.js و ماژول Account Abstraction کتابخانه Viem از قبل پشتیبانی EIP-7702 را ارائه داده‌اند.

شکاف‌های باقی‌مانده

EIP-7702 یک بهبود تدریجی است، نه چشم‌انداز کامل Account Abstraction. چندین محدودیت باقی می‌ماند:

• واگذاری به ازای هر حساب است، نه جهانی: هر EOA باید به طور جداگانه به یک واگذاری کد انتخاب کند. هیچ ارتقای کیف‌پول در سطح شبکه وجود ندارد — پذیرش به پشتیبانی کیف‌پول‌ها و حداقل یک تراکنش کاربر برای تنظیم واگذاری بستگی دارد.
• کد با تراکنش‌های ساده EOA بازنشانی می‌شود: اگر EOA یک تراکنش ساده (غیرواگذار) ارسال کند، نشانگر کد می‌تواند پاک شود. کیف‌پول‌ها باید این را با دقت مدیریت کنند تا از وضعیت گیج‌کننده برای کاربرانی که انواع تراکنش قدیم و جدید را مخلوط می‌کنند جلوگیری شود.
• بدون جلسات زنجیره‌ای بومی: کلیدهای جلسه و واگذاری‌ها مختص یک زنجیره هستند. واگذاری در شبکه اصلی اتریوم به Arbitrum یا Base منتقل نمی‌شود. Account Abstraction بین زنجیره‌ای همچنان یک مسئله باز است.
• EOA یک کیف‌پول کامل Smart Contract نیست: EOAهای دارای واگذاری EIP-7702 نمی‌توانند از طریق selfdestruct ETH دریافت کنند، نمی‌توانند به همان روش هدف استقرار CREATE2 باشند و مفروضات امنیتی متفاوتی نسبت به یک کیف‌پول Smart Contract بومی مانند Safe دارند.

نقشه راه اتریوم این شکاف‌ها را در ارتقاهای آینده برطرف می‌کند. EIP-7701 (Account Abstraction بومی از طریق یک نوع تراکنش جدید) و بلوغ زیرساخت ERC-4337 گام‌های بعدی هستند. Pectra را بهتر است به عنوان راهی برای عملی‌سازی Account Abstraction برای پایگاه کاربر فعلی — بیش از ۵۰۰ میلیون EOA — بدون اجبار به مهاجرت درک کنید.

نکات کلیدی برای توسعه‌دهندگان

• اگر کیف‌پول می‌سازید: پشتیبانی از نوع تراکنش EIP-7702 را ارائه دهید، اهداف واگذاری را به وضوح نمایش دهید و ادغام paymaster را با حداقل یک ارائه‌دهنده bundler پیاده‌سازی کنید.
• اگر DApp می‌سازید: می‌توانید بدون استقرار مجدد قراردادها، اسپانسری گس و دسته‌بندی تراکنش‌ها را اضافه کنید. بازگشت سرمایه در کاهش مراحل تأیید در نرخ‌های تبدیل قابل اندازه‌گیری است.
• اگر عملیات استیکینگ دارید: EIP-7251 به شما اجازه می‌دهد ۶۴ اعتبارسنج ۳۲ ETH را در یک اعتبارسنج ۲٬۰۴۸ ETH ادغام کنید و سربار p2p و عملیاتی خود را تقریباً ۹۸٪ کاهش دهید.
• اگر روی زنجیره‌های متعدد کار می‌کنید: فرض نکنید واگذاری‌های EOA در زنجیره‌ها منتقل می‌شوند. معماری کلید جلسه خود را طوری طراحی کنید که مجوز به ازای هر زنجیره را به صراحت مدیریت کند.

Pectra اتریوم را دوباره اختراع نمی‌کند — اصطکاکی را که اتریوم را برای یک دهه استفاده از آن سخت کرده بود از بین می‌برد. تأیید دو مرحله‌ای توکن، نیاز به ETH برای گس، عدم توانایی در خودکارسازی اقدامات کیف‌پول به صورت ایمن: اینها محدودیت‌های بنیادی بلاک‌چین نبودند، محدودیت‌های مدل EOA بودند. EIP-7702 بیشتر آن‌ها را برطرف می‌کند. آنچه باقی می‌ماند یک مسئله اجرایی برای تیم‌های کیف‌پول و توسعه‌دهندگان DApp است، نه یک شکاف پروتکلی.