Account Abstraction
Account Abstractionは、ブロックチェーンアカウントの管理方法において paradigm shift をもたらします。Ethereumのような一般的なブロックチェーンでは、主に Externally Owned Accounts (EOAs) が私有キーで制御され、Contract Accounts (スマートコントラクト) の2つの主要なアカウントタイプを使用しています。Account Abstractionはこれらを統一し、スマートコントラクトがアカウントになり、カスタムトランザクションロジックや多重認証、アカウントの復元など、追加機能を可能にします。 このアプローチにより、デcentralized アpplications (dApps) とのインターフェースが簡素化され、セキュリティも向上します。複数のトランザクションを一度にまとめて実行したり、ガス料金を任意のトークンで支払ったり、私有キー署名よりも複雑な認証スキームを可能にするなど、追加機能が提供されます。目標はブロックチェーンのインタラクションがもっとうまくと安全に、一貫性のあるウェブアプリケーションのようなものになることです。
ブロックチェーン、特にEthereumの文脈におけるアカウント抽象化（AA）は、外部所有アカウント（EOA）の制限を超えてスマートコントラクトの機能を進化させることを目指しています。秘密鍵によって制御されるEOAは、主にトランザクションへの署名という固定された機能セットを持っています。アカウント抽象化は、スマートコントラクト自体をアカウントとして扱い、プログラム可能なロジックと強化された機能を与えることを提案しています。これは、トランザクション検証と実行のための「メンプール」を導入するERC-4337や、オフチェーンで署名を検証するためのERC-1271などの標準によって達成されます。主な利点には、ソーシャルリカバリ（信頼できる連絡先を指定してシードフレーズなしでアカウントを復旧する）、ガススポンサーシップ（第三者がトランザクション手数料を支払うことを許可する）、バッチトランザクション（複数の操作を単一のトランザクションに結合する）などのユーザーエクスペリエンスの向上があります。技術的な観点からは、AAは秘密鍵暗号化を超えた柔軟な認証方法を可能にし、マルチシグネチャウォレット、ハードウェアウォレットの統合、さらにはスマートコントラクトによって管理される生体認証さえも可能にします。また、条件付き支出や複数ステップの承認プロセスなど、より複雑なトランザクション検証ルールも容易にします。トレードオフには、スマートコントラクト開発と監査の複雑さの増加、より洗練されたアカウントロジックのガスコストへの影響の可能性、およびスマートコントラクトアカウント自体の脆弱性を防ぐための堅牢なセキュリティ対策の必要性が含まれます。
graph LR
Center["Account Abstraction"]:::main
Pre_blockchain["blockchain"]:::pre --> Center
click Pre_blockchain "/terms/blockchain"
Pre_smart_contracts["smart-contracts"]:::pre --> Center
click Pre_smart_contracts "/terms/smart-contracts"
Pre_ethereum["ethereum"]:::pre --> Center
click Pre_ethereum "/terms/ethereum"
Rel_wallet["wallet"]:::related -.-> Center
click Rel_wallet "/terms/wallet"
Rel_reflection_token["reflection-token"]:::related -.-> Center
click Rel_reflection_token "/terms/reflection-token"
Rel_distributed_ledger_technology_dlt["distributed-ledger-technology-dlt"]:::related -.-> Center
click Rel_distributed_ledger_technology_dlt "/terms/distributed-ledger-technology-dlt"
classDef main fill:#7c3aed,stroke:#8b5cf6,stroke-width:2px,color:white,font-weight:bold,rx:5,ry:5;
classDef pre fill:#0f172a,stroke:#3b82f6,color:#94a3b8,rx:5,ry:5;
classDef child fill:#0f172a,stroke:#10b981,color:#94a3b8,rx:5,ry:5;
classDef related fill:#0f172a,stroke:#8b5cf6,stroke-dasharray: 5 5,color:#94a3b8,rx:5,ry:5;
linkStyle default stroke:#4b5563,stroke-width:2px;
🧠 理解度チェック
🧒 5歳でもわかるように説明
通常のオンラインアカウントを、前にしか進めないシンプルなオモチャの車だと想像してください。アカウント抽象化は、それを、友達がリモコンを失くしたときに助けてくれたり、ガソリン代を自分で払ってくれたりする、たくさんのクールなトリックができる超強力なロボットカーのようにします！
🤓 Expert Deep Dive
アカウント抽象化（AA）は、主にEthereumのERC-4337および関連標準によって推進されており、スマートコントラクトをトランザクションを開始できる第一級市民として扱うことで、アカウント管理に革命をもたらします。秘密鍵のみによって管理される従来の外部所有アカウント（EOA）とは異なり、「スマートアカウント」または「コントラクトアカウント」として知られるAA対応アカウントは、特定のインターフェース（例：IAccountAbstraction）に準拠したデプロイされたスマートコントラクトです。
AAの鍵となるのは、「ペイマスター」と「バンダー」の概念です。バンダーは、ユーザー操作（スマートアカウントからの署名済みトランザクション）を集約し、それを単一のトランザクションとしてネットワークに送信するオフチェーンエンティティです。このプロセスは、「ユーザーオペレーションメンプール」と呼ばれる新しいメンプールによって促進されます。ペイマスターは別のスマートコントラクトであり、ユーザーのガス料金をスポンサーしたり（ERC-20トークンでのガス支払い、またはユーザーへの無料トランザクションを可能にする）、カスタム検証ロジックを強制したりできます。
スマートアカウントの検証プロセスは通常、スマートアカウントコントラクト内のisValidSignature関数またはカスタムvalidateUserOp関数を呼び出すことを含みます。この関数は、UserOperationハッシュとユーザーによって提供された署名を受け取ります。スマートアカウントはその後、内部ロジックを実行して操作を検証します。これには、多要素認証（例：ハードウェアウォレット署名と時間ロックされたバックアップが必要）、ソーシャルリカバリメカニズム、またはセッションキーが含まれる場合があります。
solidity
// スマートアカウントの検証ロジックの簡略化された例
interface ISmartAccount {
function validateUserOp(UserOperation calldata op, bytes calldata signature) external returns (uint256 validUntil, bytes32 validHash);
}
contract MySmartAccount is ISmartAccount {
address public owner;
address public guardian;
uint256 public recoveryTimeout;
function validateUserOp(UserOperation calldata op, bytes calldata signature) external view override returns (uint256, bytes32) {
// ここに署名検証ロジック、例：ECDSA、マルチシグなど
// 例：require(ecrecover(keccak256(hash(op)), sig) == owner);
// ガーディアンの署名に基づいた時間ロックされたリカバリロジックも実装可能
return (block.timestamp + 3600, keccak256(abi.encode(op))); // 1時間有効
}
}
このアーキテクチャの変更は、トランザクション署名とキー管理を分離し、基盤となるブロックチェーンのセキュリティ原則を損なうことなく、よりリッチで、より安全で、ユーザーフレンドリーなやり取りを可能にします。