L2-3: Social Recovery（ソーシャルリカバリーウォレット） #

1. 問題 #

ソーシャルリカバリーをサポートするスマートコントラクトウォレットを作成します：オーナーが秘密鍵を紛失した場合、事前に指定された「ガーディアン」のグループが全会一致でオーナーを交代できます。

2. 理由 #

従来のEOAウォレットの最大のリスク：秘密鍵の紛失 = 資産の永久喪失。

ソーシャルリカバリーは「ガーディアン」（友人、家族、機関）のグループを信頼することで解決します：

• 通常時：オーナーがすべてを制御
• 秘密鍵紛失時：ガーディアンに連絡してオーナー交代を投票
• 回復条件：すべてのガーディアンの同意

Vitalik はユーザー体験を改善する重要な技術としてソーシャルリカバリーウォレットを繰り返し推奨しています。

3. 解決策 #

アーキテクチャ #

owner ── 通常操作 ──→ call(任意のコントラクト, ETH, calldata)
guardians ── 全会一致投票 ──→ signalNewOwner(newOwner) → 自動的にリカバリーを実行
owner ── ガーディアン管理 ──→ addGuardian / removeGuardian

コアメカニズム #

• signalNewOwner(_proposedOwner)：各ガーディアンは同じ proposedOwner に対して1回のみ投票可能
• signalCount == guardianCount の場合：自動的にオーナーを交代
• 異なる proposedOwner へのシグナルは独立して追跡

4. 遭遇した落とし穴 #

4.1 全会一致 vs 多数決のトレードオフ #

このレベルでは全会一致（すべてのガーディアン）を採用しています。つまり：

• 任意の1人のガーディアンが一方的にリカバリーを阻止できる
• ガーディアンも鍵を紛失した場合 → リカバリー不可能

4.2 ガーディアンセット変更の影響 #

オーナーがリカバリープロセス中にガーディアンを追加/削除した場合、guardianCount の変更により：

• ガーディアン追加：以前の全会一致はもはや全会一致ではない
• ガーディアン削除：一部の投票で早期にリカバリーが発動する可能性

4.3 複数候補のシグナル追跡 #

ガーディアンAが proposedOwner1 に投票し、ガーディアンBが proposedOwner2 に投票する——両者の signalCount は独立して計算され、相互に影響しません。

5. 落とし穴の理由 #

5.1 #

全会一致はセキュリティと活性性のトレードオフです。全会一致はセキュリティを重視し（全員の同意が必要）、多数決は活性性を重視します（1〜2人の連絡不能なガーディアンによってブロックされない）。

5.2 #

これは設計上の選択です：このレベルでは全会一致を要求し、タイムロックを含みません。業界レベルの実装（Argent、Safe など）は通常、多数決（例：3/5）+ タイムロックを使用します。

5.3 #

signalNewOwner では、signalCount は _proposedOwner の次元で独立して追跡されます：

mapping(address => mapping(address => bool)) public hasSignaled; // proposedOwner → guardian → signaled
mapping(address => uint256) public signalCount;                   // proposedOwner → count

6. 落とし穴の解決方法 #

• 本番環境では多数決（例：N-of-M）+ タイムロック + キャンセル機構を使用する
• ガーディアンの選択：信頼性 + 技術サポート能力 + 地理的分散
• オーナー変更後、古いシグナルのクリアを検討（このレベルでは簡略化のため未実装）

7. 技術的ポイント #