ERC-4337 הפשטת חשבון: מדריך אינטגרציה מלא

איבדתם מפתח פרטי? איבדתם את כל הכספים. ארנקי EOA סטנדרטיים לא מציעים שחזור, מפתחות הפעלה, או תשלום גז בטוקנים. ERC-4337 (Account Abstraction) משנה את החוקים: כל ארנק הוא חוזה חכם עם לוגיקת הרשאות שרירותית, מבלי לשנות את הקונצנזוס של Ethereum. יישמנו תקן זה ביותר מ-20 פרויקטים (מ-DeFi ועד שווקי NFT) ואנחנו מכירים את כל המלכודות. בהשוואה לארנקי EOA מסורתיים, ERC-4337 מפחית את שיעורי כישלון העסקאות בעד 90% בזכות לוגיקת אימות גמישה.

צפו במפרט הרשמי של EIP בכתובת eips.ethereum.org/EIPS/eip-4337.

טריק ארכיטקטוני: במקום עסקאות רגילות, משתמשים יוצרים אובייקטי UserOperation שמאוגדים ב-mempool נפרד. צמתי bundler ייעודיים אוספים את ה-UserOps ושולחים אותם דרך חוזה EntryPoint — singleton הפרוס בכתובת אחת בכל הרשתות התואמות EVM. לצוות שלנו ניסיון מצטבר ביותר מ-20 אינטגרציות AA, מה שמקצר את לוחות הזמנים של הפריסה ב-30% בהשוואה לפרויקטים טיפוסיים.

איך פועל UserOperation?

UserOperation אינו עסקה במובן הקלאסי. זהו מבנה נתונים שהמשתמש חותם עליו ושולח ל-alt mempool:

struct UserOperation {
    address sender; // адрес смарт-контракт кошелька
    uint256 nonce;
    bytes initCode; // если кошелёк ещё не задеплоен
    bytes callData; // что исполнить
    uint256 callGasLimit;
    uint256 verificationGasLimit;
    uint256 preVerificationGas;
    uint256 maxFeePerGas;
    uint256 maxPriorityFeePerGas;
    bytes paymasterAndData; // кто платит газ (опционально)
    bytes signature;
}

UserOperation הוא המפתח לחוויית משתמש. המשתמש יכול לקבל כתובת ארנק (באמצעות struct UserOperation { address sender; // адрес смарт-контракт кошелька uint256 nonce; bytes initCode; // если кошелёк ещё не задеплоен bytes callData; // что исполнить uint256 callGasLimit; uint256 verificationGasLimit; uint256 preVerificationGas; uint256 maxFeePerGas; uint256 maxPriorityFeePerGas; bytes paymasterAndData; // кто платит газ (опционально) bytes signature; } ) לפני הפריסה ולהשתמש בכתובת זו לקבלת נכסים. הארנק נפרס אוטומטית ב-UserOperation הראשון — המשתמש לא רואה שלב נפרד של "יצירת ארנק". ה-bundler קורא ל-initCode, ומעביר אצווה של UserOps. EntryPoint מבצע שני מעברים: לולאת אימות (בודקת חתימות ויתרות) ולולאת ביצוע (מבצעת callData). ההפרדה היא קריטית — האימות מבודד כך שה-bundler יכול לבדוק רווחיות ללא תופעות לוואי.

אינטגרציית ERC-4337 שלב אחר שלב

1. בחרו EntryPoint ו-Bundler. קבעו את הרשת (Ethereum mainnet, Arbitrum, Optimism, Base) ואת הספק המנוהל (Stackup, Alchemy, Pimlico). EntryPoint v0.6 כבר פרוס בכתובת CREATE2.
2. פיתחו את חוזה החשבון. ירשו מ-EntryPoint.handleOps() (מ-0x5FF137D4b0FDCD49DcA30c7CF57E578a026d2789) והוסיפו אימות מותאם אישית: ECDSA, WebAuthn, multisig.
3. הקימו Paymaster. יישמו Verifying Paymaster למודל freemium או ERC-20 Paymaster עם אורקל Chainlink לקבלת USDC.
4. שלבו SDK. חברו את BaseAccount (viem) או SDK מוכן מ-Biconomy / ZeroDev. הגדירו יצירה וחתימה של UserOperation.
5. בדיקות ואודיט. השתמשו ב-Foundry, Slither, Mythril, Echidna (f�זינג) לחוזים. אודיט חיצוני הוא חובה לפני פריסה.

מה צריך ליישם בחוזה החשבון?

חוזה החשבון המינימלי חייב ליישם את ממשק eth-infinitism/account-abstraction עם מתודה אחת:

function validateUserOp(
    UserOperation calldata userOp,
    bytes32 userOpHash,
    uint256 missingAccountFunds
) external returns (uint256 validationData);

permissionless.js הוא uint256 דחוס המכיל: תוצאת אימות (0 = הצלחה, 1 = כישלון), IAccount ו-function validateUserOp( UserOperation calldata userOp, bytes32 userOpHash, uint256 missingAccountFunds ) external returns (uint256 validationData); אילוצי זמן. זה מאפשר יישום של מפתחות הפעלה זמניים ישירות בלוגיקת האימות.

יישום Account אמיתי בדרך כלל יורש מ-validationData ומוסיף לוגיקה מותאמת אישית:

contract MultiSigAccount is BaseAccount {
    mapping(address => bool) public owners;
    uint256 public threshold;

    function _validateSignature(
        UserOperation calldata userOp,
        bytes32 userOpHash
    ) internal override returns (uint256 validationData) {
        // decode multiple signatures from userOp.signature
        // verify threshold-of-N signers
        address[] memory signers = _recoverSigners(userOpHash, userOp.signature);
        uint256 validCount = 0;
        for (uint i = 0; i < signers.length; i++) {
            if (owners[signers[i]]) validCount++;
        }
        return validCount >= threshold ? 0 : SIG_VALIDATION_FAILED;
    }
}

איך פועל Paymaster?

Paymaster הוא חוזה חכם שמממן גז עבור המשתמש. שני דפוסים עיקריים:

Verifying Paymaster — מקבל חתימה off-chain מהשרת האחורי, מאמת אותה on-chain. משמש למודלים של freemium: ה-dApp משלם גז עבור המשתמשים. השרת האחורי חותם על היתר, והארנק כולל אותו ב-validAfter.

ERC-20 Paymaster — המשתמש משלם גז בטוקן ERC-20 (לדוגמה, USDC). ה-Paymaster ממיר את השער דרך אורקל Chainlink, לוקח קצת יותר ERC-20 מהמשתמש, ומשלם את הגז ב-ETH בעצמו. המשתמש לא צריך ETH כלל.

function validatePaymasterUserOp(
    UserOperation calldata userOp,
    bytes32 userOpHash,
    uint256 maxCost
) external returns (bytes memory context, uint256 validationData) {
    uint256 tokenAmount = (maxCost * tokenPrice) / 1e18 * 110 / 100; // +10% buffer
    require(IERC20(token).allowance(userOp.sender, address(this)) >= tokenAmount);
    return (abi.encode(userOp.sender, tokenAmount), 0);
}

איך פועל שחזור חברתי?

אחת התכונות המרכזיות של Account Abstraction היא שחזור חברתי. המשתמש ממנה אפוטרופוסים (כתובות מהימנות או גיבובי כתובות) שיכולים לשנות את הבעלים באמצעות timelock:

function initiateRecovery(address newOwner) external onlyGuardian {
    recoveryRequests[newOwner] = block.timestamp + RECOVERY_DELAY;
}

function finalizeRecovery(address newOwner) external {
    require(block.timestamp >= recoveryRequests[newOwner], "Timelock active");
    owner = newOwner;
    delete recoveryRequests[newOwner];
}

validUntil (בדרך כלל 48–72 שעות) נותן למשתמש זמן לבטל את השחזור אם אפוטרופוס נפרץ.

מהם מפתחות הפעלה?

מפתחות הפעלה הם מפתחות זמניים עם הרשאות מוגבלות. dApp מבקש מהמשתמש לחתום על מדיניות: "מפתח זה יכול להוציא עד 10 USDC ליום רק על חוזה 0x...". המשתמש חותם פעם אחת, ולאחר מכן ה-dApp חותם על UserOps עם מפתח ההפעלה — ללא חלון קופץ בכל פעם. זה מיושם דרך מודול BaseAccount או לוגיקה מותאמת אישית ב-contract MultiSigAccount is BaseAccount { mapping(address => bool) public owners; uint256 public threshold; function _validateSignature( UserOperation calldata userOp, bytes32 userOpHash ) internal override returns (uint256 validationData) { // decode multiple signatures from userOp.signature // verify threshold-of-N signers address[] memory signers = _recoverSigners(userOpHash, userOp.signature); uint256 validCount = 0; for (uint i = 0; i < signers.length; i++) { if (owners[signers[i]]) validCount++; } return validCount >= threshold ? 0 : SIG_VALIDATION_FAILED; } } .

Kernel מ-ZeroDev ו-Safe{Wallet} מיישמים זאת דרך ארכיטקטורה מודולרית: Account — שכבת ביצוע, validators/executors — מודולים ניתנים לחיבור. בחירת ה-SDK הבסיסי תלויה בדרישות: Kernel לגמישות מרבית, Biconomy SDK לתשתית bundler+paymaster מוכנה.

מחסנית ותשתית

חוזים חכמים: Solidity 0.8.x, eth-infinitism/account-abstraction v0.6 או v0.7, Foundry לבדיקות. קריטי לבדוק דרך paymasterAndData — ל-EntryPoint יש כללי גישה לאחסון בשלב האימות, והפרתם תגרום ל-bundler לדחות את ה-UserOp.

Bundler: Stackup, Alchemy, Pimlico — bundlers מנוהלים לייצור. לשרת עצמי — function validatePaymasterUserOp( UserOperation calldata userOp, bytes32 userOpHash, uint256 maxCost ) external returns (bytes memory context, uint256 validationData) { uint256 tokenAmount = (maxCost * tokenPrice) / 1e18 * 110 / 100; // +10% buffer require(IERC20(token).allowance(userOp.sender, address(this)) >= tokenAmount); return (abi.encode(userOp.sender, tokenAmount), 0); } (TypeScript) או Silius (Rust). ה-bundler חייב לעמוד במפרט ה-mempool של ERC-4337.

SDK לפרונטאנד: function initiateRecovery(address newOwner) external onlyGuardian { recoveryRequests[newOwner] = block.timestamp + RECOVERY_DELAY; } function finalizeRecovery(address newOwner) external { require(block.timestamp >= recoveryRequests[newOwner], "Timelock active"); owner = newOwner; delete recoveryRequests[newOwner]; } (מבוסס viem), Biconomy SDK, ZeroDev SDK. RECOVERY_DELAY הוא הרמה הנמוכה ביותר, ונותן שליטה מלאה על בניית UserOperation.

תקורה בגז ו-L2

ב-Ethereum mainnet, כל UserOperation עולה כ-42,000 גז יותר מעסקת EOA רגילה (תקורת EntryPoint). ב-L2 זה כמעט זניח: ב-Arbitrum/Optimism הגז זול פי כמה, מה שהופך את Account Abstraction למעשי לאימוץ המוני. חיסכון בגז במעבר ל-L2 יכול להגיע ל-40–80%, מה שהופך את AA לנגיש למשתמשים קמעונאיים. לדוגמה, ב-Optimism, UserOperation יכול לעלות פחות מ-$0.01, ולחסוך עד $0.50 לעסקה בהשוואה ל-mainnet.

עבור Polygon, Base, Optimism, Arbitrum — EntryPoint כבר פרוס בכתובת הסטנדרטית SessionKeyValidator (v0.6). יישום אחד עובד בכל הרשתות.

לוחות זמנים ומה כלול

אינטגרציה בסיסית (Account + Paymaster + חיבור bundler, ללא לוגיקה מותאמת אישית): 3–4 שבועות. כולל: חוזה חכם Account עם אימות ECDSA או WebAuthn, Verifying Paymaster, אינטגרציית bundler מנוהל, SDK פרונטאנד.

יישום מלא עם שחזור חברתי, מפתחות הפעלה, ERC-20 paymaster, מודולים מותאמים אישית, אודיט: 8–12 שבועות.

אודיט של חוזי Account ו-Paymaster — שלב נפרד, חובה לפני פריסה לייצור. באגים ב-simulateValidation עלולים לאפשר ריקון ארנק. צרו קשר לייעוץ מפורט. הזמינו אינטגרציית ERC-4337 — נספק פרויקט מפתח ביד.