[ERC5883] アクセスできなくなったアドレスが保有するトークンを移動させる仕組みを理解しよう！

はじめに

『DApps開発入門』という本や色々記事を書いているかるでねです。

今回は、アクセスできなくなったアドレスが保有しているトークンを、他のアドレスの承認により移動させる仕組みを提案しているERC5883についてまとめていきます！

以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。

他にも様々なEIPについてまとめています。

概要

ERC5883は、ソーシャルリカバリーの仕組みを標準化する提案をしています。
アクセスできなくなったアカウントから新しいアカウントへトークンを移す方法を決める提案です。
この仕組みを実行するには1つ以上のアドレスによる承認が必要になります。

この仕組みでは、承認を行う人々を「ソウル（Souls）」と呼んでいます。
この考え方は、Soul Bound Token（SBT）の提案に基づいています。
ソウルたちは「Yes」か「No」で承認を行い、決められた閾値に達するとトークンが元のアカウントから新しいアカウントに移されます。

動機

秘密鍵を紛失すると、そのアカウントが保有するトークンを取り戻すことができなくなります。
この問題が起きると、トークンの持ち主が損をするだけでなく、トークンのエコシステム全体にも悪影響を及ぼします。
失われたトークンが増えるほど、エコシステムの成長や計画的な進化が妨げられるため、この問題を解決する仕組みが求められています。

ERC5883が導入されると、秘密鍵をなくしても一定の条件を満たせばトークンを取り戻せるようになります。

仕様

ERC5883では、特定の条件を満たせば、トークンやアカウントの権限を新しいアドレスに移行できるようにする仕組みを定めています。
承認は関係のある複数のアドレスによって行われます。

インターフェース

ISocialRecovery というインターフェースを定義して以下の4つの関数を定義する必要があります。

pragma solidity ^0.8.7;

interface ISocialRecovery {
    /// @dev Related but independent identity approves the transfer
    function approveTransfer(address from_, address to_) external;

    /// @dev User wants to move their onchain identity to another wallet which needs to be approved by n-nearest neighbour identities
    function requestTransfer(address from_, address to_) external payable;

    function addNeighbour(address neighbour_) external;

    function removeNeighbour(address neighbour_) external;
}

• approveTransfer(address from_, address to_)
  • 指定されたアドレスから別のアドレスへの移行を承認する関数。
• requestTransfer(address from_, address to_)
  • ユーザーがウォレットの変更を申請して承認プロセスを開始する関数。
• addNeighbour(address neighbour_)
  • 信頼できる関係者のアドレスを追加する関数。
• removeNeighbour(address neighbour_)
  • 以前に登録した信頼できるアドレスを削除する関数。

スコア計算の数式

トークンの移動を承認するためのシステムでは、各ノード（アカウントや個人）の信頼度をスコアで評価します。

スコアは以下の式で計算されます。

score(n) = \tanh \left( \frac{\sum_{i=1}^{|N|} \log \left( n_i^{r} \times \frac{1}{t - n_i^{t} + 1} \right)}{|N| + 1} + n^{r} \right)

この式の意味は以下の通りです。

• t
  • 現在の時間（ブロックタイムやブロック番号など）
• n^r
  • ノード n の報酬回数（どれだけ承認に参加したか）
• N
  • ノード n のneighboursのリスト（承認に関与する人々）
• n_i^r
  • ノード n のneighbours i の報酬回数
• n_i^t
  • ノード n のneighbours i が最後に報酬を受けたタイムスタンプ

この計算では、単なる多数決ではなく、過去の承認履歴や信頼度を考慮するようになっています。

承認プロセスの流れ

ERC5883では、特定のアカウントの移行がリクエストされると、関係者が承認をして一定の条件を満たした場合に移行が実行されます。

承認の流れ

1. リクエストの送信
   • ユーザーがコントラクトに「アドレスを変更したい」とリクエストを送る。
2. 通知の送信
   • コントラクトが登録されたネイバー全員に通知を送る。（WebSocket や EPNS などを利用）
3. 承認の収集
   • 関係者がコントラクトに対して「承認（Yes/No）」を送る。
4. 承認数とスコアのチェック
   • 承認者の数がしきい値を超えているかを確認。
   • 承認者の累積スコアがしきい値を超えているかを確認。
5. トークンの移動
   • 条件を満たしていたら、保有しているトークンが新しいアドレスへ移される。
6. 報酬の付与
   • 承認に参加した関係者に報酬が与えられる。

補足

ERC5883で使われている数式は、耐性が高く公平なインセンティブ構造を持っています。
スコアに時間を考慮した重み付けを加えることで、公平性を向上させています。
つまり、ただ単に多くの承認を集めるだけではなく、長期的な信頼関係が考慮される仕組みになっています。
これにより、オンチェーンのスコア自体に価値が生まれるようになっています。

セキュリティ

報酬を不正に獲得するリスク

現在の仕組みでは、ユーザーが大量の報酬を得るのを防ぐ明確な方法はありません。
多くの報酬を得るにはそれなりの投資が必要ですが、資金力のある人であればその条件を満たすことができてしまいます。
この問題を解決するには、アドレスと実際のユーザーをより確実に結びつける方法が必要です。
例えば、現実世界の情報をハッシュ化し、一意の識別子を生成する仕組みなどが考えられます。
ただし、このハッシュ値はあくまで「曖昧な」データを元にするため、厳密なものにはならない可能性があります。

しきい値（承認数）の問題

ERC5883では、一定の承認数（しきい値）を超えた場合にのみトークンの移動が可能になります。
しかし、どの程度のしきい値が適切なのかについては基準値がありませせん。
そのため、現在は仮の値を設定しており、将来的に実際の運用を通じて調整が必要になります。

ネットワークの非活性化の問題

ERC5883は、承認を行う「関係者」のネットワークが機能し続けることを前提としています。
もし承認者たちが非アクティブになってしまった場合、必要な承認数を満たせないためユーザーがトークンを移動できなくなる可能性があります。
つまり、このコントラクトは「利用され続けること」が前提となっており、もし使われなくなるとシステム自体が機能しなくなってしまいます。

引用

Erhard Dinhobl (@mrqc), Kevin Riedl (@wsdt), "ERC-5883: Token Transfer by Social Recovery [DRAFT]," Ethereum Improvement Proposals, no. 5883, July 2022. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-5883.

最後に

今回は「アクセスできなくなったアドレスが保有しているトークンを、他のアドレスの承認により移動させる仕組みを提案しているERC5883」についてまとめてきました！
いかがだったでしょうか？

質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！

Twitter @cardene777

他の媒体でも情報発信しているのでぜひ他も見ていってください！