Account Abstraction چیست و چگونه تجربه کاربری کیف پول ها را متحول می کند؟

پاسخ کوتاه: Account Abstraction چیست؟ روشی برای تبدیل «حساب کاربر» به یک قرارداد هوشمند قابل برنامه ریزی است تا قوانین ورود، امضا، محدودیت ها و حتی پرداخت کارمزد را خود حساب تعیین کند. نتیجه مستقیم برای کیف پول ها: ورود بدون سید، بازیابی اجتماعی، پرداخت گس با توکن های دلخواه یا اسپانسر، امضای چندمرحله ای، تراکنش های دسته ای و تجربه ای شبیه اپ های معمولی با امنیت زنجیره.

تفاوت مدل فعلی با Account Abstraction

در اتریوم دو نوع حساب وجود دارد:

• EOA: حسابی که با کلید خصوصی کنترل می شود. ساده و کم هزینه است اما فقط یک قانون دارد: «هر که کلید را دارد، صاحب حساب است».
• Contract Account: کدی روی زنجیره که می تواند قوانین پیچیده داشته باشد ولی به خودی خود تراکنش را شروع نمی کند.

Account Abstraction شکاف بین این دو را پر می کند: حساب کاربر خودش یک قرارداد است و می تواند امضاهای متنوع، چندامضایی، محدودیت مبلغ، سشن کی و پرداخت گس با توکن های غیر از ETH را پشتیبانی کند؛ بدون نیاز به تغییر در قوانین پایه شبکه (در مدل EIP-4337).

Account Abstraction چگونه کار می کند؟

پیاده سازی رایج AA در اتریوم بر اساس EIP-4337 است. ایده اصلی این است که به جای ارسال تراکنش مستقیم از EOA، کاربر «UserOperation» می سازد؛ بسته ای شامل مقصد، داده، امضا و بودجه. این بسته به یک «ورودگاه» مشترک (EntryPoint) می رسد و توسط «باندلر» ها در یک تراکنش جمع آوری و اجرا می شود. قرارداد حساب قوانین اعتبارسنجی خودش را اجرا می کند.

اجزای کلیدی

• Account Contract: همان کیف پول کاربر به صورت قرارداد هوشمند که قوانین امضا و اجرا را پیاده می کند.
• EntryPoint: قرارداد مشترکی که UserOperation ها را اعتبارسنجی و اجرا می کند.
• Bundler: نودی که UserOperation ها را جمع کرده و یک تراکنش به EntryPoint ارسال می کند.
• Paymaster: اختیاری؛ نهادی که می تواند کارمزد را به جای کاربر بپردازد یا اجازه پرداخت گس با توکن های دیگر را بدهد.

جریان یک تراکنش با AA

1. کاربر در dApp یک عملیات (یا چند عملیات) را انتخاب می کند.
2. کیف پول یک UserOperation می سازد و با روش انتخابی کاربر امضا می کند (کلید، Passkey/WebAuthn، چندامضایی و…).
3. باندلر UserOperation را به EntryPoint می فرستد.
4. EntryPoint تابع اعتبارسنجی حساب را صدا می زند؛ اگر معتبر بود، اجرا انجام می شود.
5. کارمزد توسط خود کاربر یا Paymaster پرداخت می شود. اگر از توکن دیگر پرداخت شود، تبدیل داخلی انجام می شود.

تاثیر مستقیم بر تجربه کاربری کیف پول ها

• آن بوردینگ بدون سید: ثبت نام با ایمیل/پسکی/سوشال لاگین و تولید کلید امن در دستگاه یا ماژول سخت افزاری؛ بازیابی از طریق «گاردین» ها یا روش های تعریف شده.
• پرداخت گس با توکن های دلخواه: نیازی نیست کاربر بابت هر زنجیره ETH نگه دارد؛ Paymaster یا تعادل توکن های دیگر هزینه را پوشش می دهد.
• تراکنش های دسته ای (Batch): چند فراخوانی در یک امضا؛ مثلا Approve + Swap + Stake یکجا.
• محدودیت و سیاست: سقف روزانه، فهرست مقصد امن، تاخیر زمانی برای مبالغ بزرگ، تایید والدین برای حساب نوجوان و …
• امضای چندمرحله ای شفاف: امضای مشترک خانواده/تیم بدون وابستگی به رابط های پیچیده.
• کلیدهای جلسه (Session Keys): اجازه محدود موقت به یک بازی یا اپ، بدون درخواست امضای مداوم.

یک سناریوی واقعی قابل تصور

فرض کنید کاربر تازه وارد می خواهد NFT بخرد، اما ETH ندارد و با مفهوم سید هم آشنا نیست. کیف پول مبتنی بر AA به او اجازه می دهد با Passkey ثبت نام کند. dApp یک Batch شامل Approve و Purchase می سازد. Paymaster کارمزد را از استیبل کوین کاربر برمی دارد. قرارداد حساب با سیاست «سقف خرید روزانه 100 دلار» این عملیات را تایید می کند. نتیجه: خرید تمام می شود بدون اینکه کاربر ETH داشته باشد یا با چند پیام پیچیده مواجه شود.

نمونه کد آموزشی: یک حساب ساده مبتنی بر EIP-4337

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

// SPDX-License-Identifier: MIT
pragma solidity ^0.8.19;

/// ساده سازی شده برای آموزش. برای تولید، از استانداردها و کتابخانه های بررسی شده استفاده کنید.
interface IEntryPoint {
    function depositTo(address account) external payable;
}

interface IAccount {
    // امضای استاندارد EIP-4337 ساده سازی شده؛ نسخه های متفاوتی در گردش است.
    function validateUserOp(
        bytes32 userOpHash,
        bytes calldata signature,
        uint256 missingFunds
    ) external returns (uint256 validationData);
}

library ECDSA {
    function recover(bytes32 hash, bytes memory sig) internal pure returns (address) {
        // پیاده سازی کامل حذف شده؛ در عمل از کتابخانه های معتبر استفاده کنید.
        return address(0);
    }
}

contract SimpleAAAccount is IAccount {
    address public owner;
    IEntryPoint public immutable entryPoint;
    uint256 public nonce;

    event Executed(address target, uint256 value, bytes data);

    modifier onlyEntryPoint() {
        require(msg.sender == address(entryPoint), "not entryPoint");
        _;
    }

    constructor(address _owner, IEntryPoint _entryPoint) {
        owner = _owner;
        entryPoint = _entryPoint;
    }

    // نمونه بسیار ساده از اعتبارسنجی:
    // - بررسی نانس
    // - تایید امضا بر روی userOpHash
    // - در صورت نیاز، تامین موجودی حساب در EntryPoint برای کارمزد
    function validateUserOp(
        bytes32 userOpHash,
        bytes calldata signature,
        uint256 missingFunds
    ) external onlyEntryPoint returns (uint256 validationData) {
        // بررسی امضا
        address signer = ECDSA.recover(userOpHash, signature);
        require(signer == owner, "invalid signature");

        // مدیریت نانس ساده
        nonce++;

        // اگر EntryPoint نیاز به وجه دارد، آن را تامین کن
        if (missingFunds > 0) {
            (bool ok, ) = address(entryPoint).call{value: missingFunds}("");
            require(ok, "funding failed");
        }

        // 0 یعنی معتبر است؛ در نسخه های استاندارد، فیلدهای بیشتر (مانند مهلت) وجود دارد
        return 0;
    }

    // اجرا توسط EntryPoint پس از اعتبارسنجی
    function execute(address target, uint256 value, bytes calldata data) external onlyEntryPoint {
        (bool ok, ) = target.call{value: value}(data);
        require(ok, "call failed");
        emit Executed(target, value, data);
    }

    receive() external payable {}
}

چگونه بررسی کنیم؟ قرارداد را روی یک شبکه آزمایشی مستقر کنید، EntryPoint سازگار را مشخص کنید و یک باندلر/کیف پول توسعه ای که UserOperation می سازد به کار بگیرید. اگر امضا و nonce درست باشد، EntryPoint باید validateUserOp را با موفقیت اجرا و سپس execute را فراخوانی کند. برای یادگیری عمیق تر پیاده سازی قراردادهای AA، شرکت در یک دوره آموزش سالیدیتی می تواند مسیر شما را کوتاه کند.

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

• پیچیدگی امنیتی: به جای یک قانون ثابت EOA، حالا با منطق قرارداد سروکار دارید. هر باگ می تواند دارایی را در معرض خطر قرار دهد. ممیزی و استفاده از الگوهای استاندارد حیاتی است.
• نیاز به زیرساخت: برای تجربه مناسب به باندلر و گاهی Paymaster نیاز دارید. سرویس های شخص ثالث ممکن است سیاست یا محدودیت داشته باشند.
• هزینه استقرار: اولین استفاده معمولا نیازمند استقرار قرارداد حساب (initCode) است که هزینه گس دارد. برخی کیف پول ها این هزینه را اسپانسر می کنند.
• سازگاری شبکه: مفهوم AA عمومی است، اما جزئیات و بلوغ در زنجیره ها متفاوت است. قبل از انتشار عمومی، در مستندات رسمی شبکه هدف وضعیت پشتیبانی را بررسی کنید.
• بازیابی اجتماعی و حاکمیت کلید: اگر بازیابی اجتماعی را فعال می کنید، انتخاب گاردین ها، آستانه امضا و فرآیند بازیابی باید روشن و مقاوم در برابر حمله باشد.

چه زمانی از AA استفاده کنیم؟ معیار تصمیم گیری

• کیف پول مصرف کننده یا dApp عمومی: تقریبا همیشه ارزشمند؛ آن بوردینگ بی دردسر و پرداخت کارمزد با توکن های دلخواه نرخ تبدیل را بالا می برد.
• سازمان ها و تیم ها: سیاست های چندامضایی، سقف و تایید تاخیری ارزش افزوده جدی دارد.
• کاربران حرفه ای DeFi: اگر به کنترل دستی کامل و ابزارهای فعلی عادت دارند، مهاجرت فوری ضروری نیست؛ اما Batch و سشن کی ها تجربه را بهتر می کند.
• بازی ها و اپلیکیشن های تکرارشونده: سشن کی و تراکنش های بی اصطکاک مزیت کلیدی است.

نکات پیاده سازی برای توسعه دهندگان

• استاندارد مرجع را بخوانید و نسخه EntryPoint شبکه هدف را هماهنگ کنید.
• برای امضا، از ERC-1271 در حساب های قراردادی پشتیبانی کنید تا با اکوسیستم سازگار شوید.
• سیاست nonce را به گونه ای طراحی کنید که اجرای موازی و Batch به مشکل نخورد.
• در Paymaster، قوانین ضد سوءاستفاده (بودجه، فهرست مقصد، محدودیت نرخ) تعریف کنید.
• مسیرهای شکست کاربرپسند طراحی کنید: اگر باندلر در دسترس نبود، گزینه جایگزین یا پیام شفاف بدهید.
• در شبکه آزمایشی با سناریوهای واقعی (ازدحام، گس متغیر، امضاهای نامعتبر) تست جامع انجام دهید.

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

آیا Account Abstraction فقط مخصوص اتریوم است؟

خیر، ایده AA عمومی است. اما پیاده سازی EIP-4337 مخصوص اکوسیستم سازگار با EVM است. سایر زنجیره ها ممکن است رویکردهای متفاوتی داشته باشند.

برای استفاده از AA به کیف پول جدید نیاز دارم؟

بستگی به کیف پول دارد. برخی کیف پول ها از حساب های قراردادی پشتیبانی می کنند. پیش از استفاده، مستندات کیف پول یا dApp را بررسی کنید.

آیا AA با اپ های DeFi و NFT موجود سازگار است؟

بله، چون در نهایت همان فراخوانی های قرارداد انجام می شود. تفاوت در نحوه امضا و ارسال است که توسط EntryPoint و باندلر مدیریت می شود.

گام بعدی چیست؟

اگر توسعه دهنده کیف پول یا dApp هستید، با یک شبکه آزمایشی شروع کنید: یک حساب قراردادی نمونه بسازید، ساخت UserOperation را در کلاینت خود پیاده کنید، و یک Paymaster ساده برای سناریوهای کلیدی اپلیکیشن تعریف کنید. پس از اطمینان از تجربه و امنیت، تدریجا آن را برای کاربران واقعی فعال کنید.