はじめに
初めまして。
CryptoGamesというブロックチェーンゲーム企業でエンジニアをしている cardene（かるでね） です！
スマートコントラクトを書いたり、フロントエンド・バックエンド・インフラと幅広く触れています。
代表的なゲームはクリプトスペルズというブロックチェーンゲームです。
今回は、コントラクトの所有権を制御できるERC173をよりコンパクトにしたERC5313についてまとめていきます！
以下にまとめられているものを翻訳・要約・補足しながらまとめていきます。
ERC173については以下にまとめられています。
要約
この提案では、コントラクトを制御するアカウントを特定するために必要な最小限のインターフェースを定義しています。
「そもそもインターフェースって何？」という方は以下の記事を参考にしてください！
仕様
このEIPに準拠するすべてのコントラクトは、EIP5313インターフェースを実装しなければなりません。
// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.15;
interface EIP5313 {
function owner() view external returns(address);
}
owner
コントラクトの所有者のアドレスを取得する関数。
コントラクトに所有権の概念を実装するための最小限のメソッドを定義しています。
補足
この標準の提案にあたり、以下を意識しています。
- インターフェース内の関数の数を最小限に抑えること。
- 既存のコントラクトとの後方互換性を保つこと。
この標準は、他の標準によって拡張することができ、コントラクトの所有機能を追加できます。
インターフェース内の関数の数を減らすことで、より簡単な所有権の実装が可能となります。
詳細は以下のERC173を参照してください。
後方互換性
ERC173を実装しているすべてのコントラクトは、すでにこの仕様を実装しています。
セキュリティ上の考慮事項
この仕様書はEIP165を拡張しないため、この提案のowner関数を呼び出しても、その結果が本当にコントラクトの所有アドレスであることを完全に保証できません。
例えば、同じ関数シグネチャを持つ別の関数が、コントラクトの所有者アドレスではないアドレスを返す可能性があります。
あるアドレスがコントラクトの所有者どうかを判別するためにのみこの実装を使用する場合、上記のリスクの影響は最小限に抑えられます。
ただし、例えば貴重なNFTをコントラクトの所有者アドレスに送る場合は、リスクが高まります。
コントラクトの所有者アドレスだと思って送ったアドレスが、実はコントラクトの所有者アドレスではない可能性がある。
考察
このERC5313として、提案されているインターフェースを使用する場面はあまりないのかなと思いました。
つまり、ERC173などを参考にしてERC5313で提案されている実装が既にされていると思っています。
この提案はざっくりまとめると、「コントラクトの所有権を持つアドレスの確認」となり、ERC173の確認部分のみを切り出したものになります。
セキュリティ上の考慮事項で述べられているような、「コントラクトの所有者か判定してなんらかの処理を実行する」は既に以下で実装されています。
そのため、最初に述べたようにERC5313として実装することはないのではないかと思った次第です。
もしかしたら上記実装にあたりERC5313を参考にしているのかもしれないですが...。
また、補足としてコントラクト内での権限管理は以下のようなAccess Controlがあります。
最後に
今回は「コントラクトの所有権を制御できるERC173をよりコンパクトにしたERC5313」についてまとめてきました！
いかがだったでしょうか？
実装については今後追記していきます。
質問などがある方は以下のTwitterのDMなどからお気軽に質問してください！
採用強化中！
CryptoGamesでは一緒に働く仲間を大募集中です。
この記事で書いた自分の経験からもわかるように、裁量権を持って働くことができて一気に成長できる環境です。
「ブロックチェーンやWeb3、NFTに興味がある」、「スマートコントラクトの開発に携わりたい」など、少しでも興味を持っている方はまずはお話ししましょう！