アカウント抽象化
ユーザーは、を使用してイーサリアムとやりとりします。 EOAは、トランザクションを開始したり、スマートコントラクトを実行したりするための唯一の方法です。 ユーザーとイーサリアムのやり取りは、EOAにより制限されています。 例えば、EOAでは、トランザクションのバッチ処理が困難になり、ユーザーはガス代を支払うためのETH残高を常に保持する必要があります。
アカウント抽象化は、ユーザーがアカウントに対してセキュリティを強化したり、ユーザーエクスペリエンスを柔軟にプログラムできるようにすることで、これらの問題を解決する方法です。 EOAをアップグレード(opens in a new tab)してスマートコントラクトから制御できるようにするか、スマートコントラクトをアップグレード(opens in a new tab)してトランザクションを開始できるようにすることで実現します。 上記のオプションのいずれにおいても、イーサリアムプロトコルを変更する必要があります。 さらに、既存のプロトコルと並行して実行する第二の独立したトランザクションシステム(opens in a new tab)追加する方法もあります。 どの方法であっても、結果としてスマートコントラクトウォレットを介してイーサリアムにアクセスします。これは、既存のプロトコルの一部を利用しても、アドオンのトランザクションネットワークを介しても、ネイティブにサポートされます。
スマートコントラクトウォレットは、ユーザーにさまざまな利点をもたらします。
- 独自の柔軟なセキュリティルールを定義できる
- 鍵を失くしても、アカウントを復元できる
- 信頼しているデバイスや個人間でアカウントのセキュリティを共有できる
- 他のアカウントのガスを支払う、または他のアカウントに自分のガス代を支払ってもらうことができる
- トランザクションをまとめて処理できる (例: 一括でスワップを承認して実行する)
- dAppとウォレットのデベロッパーがユーザーエクスペリエンスでイノベーションを起こす機会が増える
現在、外部所有アカウント () のみがトランザクションを開始できるため、これらの利点はネイティブにサポートされていません。 EOAは、シンプルに公開鍵と秘密鍵のペアで構成されており、 仕組みは以下のとおりです。
- 秘密鍵を持っていれば、イーサリアム仮想マシン(EVM)のルールの範囲内で何でもできます。
- 秘密鍵を持っていなければ、何もできません。
鍵を紛失すると、復元できません。また、鍵が盗まれると、アカウント内のすべての資金に即座にアクセスされてしまいます。
スマートコントラクトウォレットは、これらの問題の解決策ですが、実装するロジックはイーサリアムで処理する前に一連のEOAトランザクションに変換する必要があるため、現在ではプログラムすることが難しくなっています。 アカウント抽象化により、スマートコントラクト自体がトランザクションを開始できるようになり、ユーザーが実装したいロジックをスマートコントラクトウォレット自体にコード化し、イーサリアム上で実行できるようになります。
最終的に、アカウント抽象化によってスマートコントラクトウォレットのサポートが向上するため、構築が簡素化し、安全に使用できるようになり、 イーサリアムの基盤となる技術を知らずとも、イーサリアムのすべてのメリットを享受できるようになります。
シードフレーズを超えて
現在のアカウントは、シードフレーズから計算された秘密鍵を使用して保護されています。 シードフレーズにアクセスできる人は、アカウントを保護する秘密鍵を簡単に発見し、保護されているすべての資産にアクセスできます。 秘密鍵とシードフレーズを紛失してしまうと、復元することはできず、ウォレットが管理する資産は永久に凍結されます。 シードフレーズの保護は、熟練ユーザーであっても簡単ではありません。また、ユーザーが詐欺に遭う最も一般的な手法の1つとしてシードフレーズフィッシングがあります。
アカウント抽象化では、スマートコントラクトを使用して資産を保持し、トランザクションを承認することで、この問題を解決します。 これらのスマートコントラクトにカスタムロジックを施すことができ、可能な限り安全に、そしてユーザーごとにカスタマイズすることができます。 最終的には、アカウントへのアクセスを制御するために秘密鍵を使用しますが、より簡単で安全に秘密鍵を管理するための安全策が施してあります。
例えば、バックアップキーをウォレットに追加できます。そのため、メインキーを紛失したり誤って公開したりしてしまった場合でも、バックアップキーで許可することで新しい安全なキーに置き換えられます。 各バックアップキーを別の方法で保護したり、信頼できるガーディアン間で分割したりすることもでき、 結果として、泥棒が資金を完全に制御するのがはるかに難しくなります。 同様に、ウォレットにルールを追加して、メインキーが侵害された場合の影響を軽減できます。例えば、低額のトランザクションを単一の署名で検証できるようにし、一方で高額のトランザクションでは複数の認証された署名者の承認が必要になるよう設定します。 スマートコントラクトウォレットの使用方法で窃盗を阻止するのに役立つものは他にもあります。例えば、許可リストを使用して、信頼できるアドレスへのトランザクションか、事前に承認された複数のキーで検証されない限り、すべてのトランザクションをブロックすることができます。
スマートコントラクトウォレットに組み込めるセキュリティロジックの例:
- マルチシグ認証: 複数の信頼できるユーザーまたはデバイス間で認証資格情報を共有できます。 これにより、事前設定された金額を超えるトランザクションには、信頼できる当事者の特定の割合 (例: 5人中の3人) からの承認が必要となるようにコントラクトを設定できます。 例えば、高額のトランザクションでは、モバイルデバイスとハードウェアウォレットの両方からの承認、または信頼できる家族に配布されたアカウントからの署名を必須にすることができます。
- アカウントの凍結: デバイスが紛失したり侵害された場合、認証された別のデバイスからアカウントをロックすることができ、ユーザーの資産を保護します。
- アカウントの復元: デバイスを紛失したり、パスワードを忘れたりすることがあります。 現在の仕組みでは、あなたの資産が永久に凍結される可能性があります。 そこで、スマートコントラクトウォレットを使用することで、新しいデバイスを承認してアクセスをリセットできるアカウントの許可リストを設定します。
- トランザクションリミットの設定: 1日、1週間、1か月などの期間でアカウントから転送できる金額の1日当たりのしきい値を指定できます。 つまり、攻撃者がアカウントにアクセスできたとしても、一度にすべての金額を流出させることはできなくなり、攻撃者からのアクセスを凍結してリセットすることができます。
- 許可リストの作成: 安全であるとわかっている特定のアドレスへのトランザクションのみを許可します。 つまり、秘密鍵が盗まれたとしても、攻撃者はリストに登録されている宛先アカウントにしか資金を送金することはできません。 これらの許可リストを変更するには複数の署名が必要になるため、攻撃者は、あなたの複数のバックアップキーにアクセスできない限り、リストに自分のアドレスを追加できません。
ユーザーエクスペリエンスの向上
アカウント抽象化によって、スマートコントラクトウォレットがプロトコルレベルでサポートされるようになります。これにより、ユーザーエクスペリエンスが全体的に改善され、セキュリティも向上します。 アカウント抽象化を行う最も重要な理由は、スマートコントラクト、ウォレット、アプリケーションのデベロッパーが、これまでにない方法でユーザーエクスペリエンスをより自由に革新できるようになるからです。 アカウント抽象化によって明らかに改善する点として、トランザクションのバンドル化による速度と効率の向上が挙げられます。 例えば、シンプルなスワップならワンクリックで完了できるはずです。しかし現在のところ、スワップを実行する前に、個々のトークンの支出を承認するために複数のトランザクションに署名する必要があります。 アカウント抽象化は、トランザクションをバンドル化することで、こうした摩擦を取り除きます。 さらに、バンドル化されたトランザクションは、各トランザクションに必要なトークンの正確な値を承認し、トランザクションが完了した後に承認を取り消すことができます。そのため、より安全性が高まります。
ガス代の管理もアカウント抽象化によって大幅に改善されます。 アプリケーションは、ユーザーのガス代を支払うことができるだけでなく、ガス代をETH以外のトークンで支払うこともできます。このため、ユーザーは資金のトランザクションでETH残高を維持する必要がなくなります。 その仕組みを説明すると、コントラクト内でユーザーのトークンをETHに交換し、そのETHをガス代の支払いに使用しています。
また、信頼できるセッションは、ユーザーエクスペリエンスに変革をもたらす可能性秘めています。特に、ゲームなどの短時間で多数の小規模なトランザクション承認が必要となるアプリケーションでは、その効果が顕著です。 ゲーム内のトランザクションを個別に承認すると、ゲームエクスペリエンスが損なわれることがありますが、永続的に承認しておくと安全性に欠けてしまいます。 スマートコントラクトウォレットを使用すれば、特定のトランザクションを一定期間、特定の値まで、または特定のアドレスに対してのみ承認できます。
アカウント抽象化によって、購買がどのように変化するのか考えてみるのも面白いでしょう。 現在、各トランザクションは、正確かつ十分な量のトークンを事前に資金提供されたウォレットから承認、実行される必要があります。 アカウント抽象化では、オンライン ショッピングに近いエクスペリエンスが得られます。例えば、ユーザーは「バスケット」にアイテムを追加し、一度クリックするだけですべてを一括購入でき、必要なロジックはすべて、ユーザーではなくコントラクトで処理できます。
アカウント抽象化は、ユーザーエクスペリエンスを向上させるための強力なツールです。これらの例は、その可能性のほんの一端に過ぎませんが、まだまだ想像もできないようなことを実現できるはずです。 アカウント抽象化によって、デベロッパーは現在のEOAの制約に縛られることなく、Web2の優れた側面をWeb3に取り入れることで、セルフカストディを維持しながら、創造的に新しいユーザーエクスペリエンスをハックできるようになります。
アカウント抽象化の実装方法
スマートコントラクトウォレットはすでに存在していますが、EVM自体がサポートしていないため、実装が難しい状況です。 代わりに、標準的なイーサリアムトランザクション周りを比較的複雑なコードでラップすることに依存しています。 イーサリアムでは、スマートコントラクトがトランザクションを開始できるようにし、オフチェーンではなくイーサリアムスマートコントラクトで必要なロジックを処理することで、スマートコントラクトウォレットに変えることができます。 スマートコントラクトにロジックを組み込むことで、ユーザーが署名したメッセージを通常のイーサリアムトランザクションに変換するためにウォレットデベロッパーが実行する「リレイヤー」が不要となるため、イーサリアムの分散化を高めることができます。
現在の進行状況
スマートコントラクトウォレットはすでに利用可能ですが、それらをできるだけ分散化してパーミッションレスにするには、さらなるアップグレードが必要です。 EIP-4337は、イーサリアムのプロトコルに変更を加えずに実装できる成熟した提案です。そのため、すぐに実装される可能性があります。 ただし、イーサリアムのプロトコルを変更するアップグレードは、現在積極的に開発されておらず、プロトコルの変更を伴うリリースは、さらに時間がかかると予想されます。 EIP-4337によってアカウント抽象化が十分に達成される可能性もあるため、プロトコルの変更がまったく必要なくなるかもしれません。
参考文献
- erc4337.io(opens in a new tab)
- Devcon Bogotaでのアカウント抽象化のパネルディスカッション(opens in a new tab)
- Devcon Bogota「アカウント抽象化がdAppのゲームチェンジャーになる理由」(opens in a new tab)
- Devcon Bogota「アカウント抽象化ELI5」(opens in a new tab)
- ヴィタリックの「アカウント抽象化への道」メモ(opens in a new tab)
- ヴィタリックのソーシャルリカバリウォレットに関するブログ投稿(opens in a new tab)
- EIP-2938のメモ(opens in a new tab)
- EIP-2938のドキュメント(opens in a new tab)
- EIP-4337のメモ(opens in a new tab)
- EIP-4337のドキュメント(opens in a new tab)
- EIP-2771のドキュメント(opens in a new tab)
- 「アカウント抽象化の基礎」 -- アカウント抽象化とは パート1(opens in a new tab)