# [ERC5313] ERC173をシンプルにした提案を理解しよう！

> この提案では、コントラクトを制御するアカウントを特定するために必要な最小限のインターフェースを定義しています。

- URL: https://cardene.dev/articles/6978005a6899259e2d36
- 公開日: 2023-07-26
- 更新日: 2023-07-26
- トピック: Blockchain
- タグ: ethereum, solidity, smartcontract, ブロックチェーン

## はじめに

初めまして。
**CryptoGames**というブロックチェーンゲーム企業でエンジニアをしている **cardene（かるでね）** です！
スマートコントラクトを書いたり、フロントエンド・バックエンド・インフラと幅広く触れています。

https://cryptogames.co.jp/

代表的なゲームは**クリプトスペルズ**というブロックチェーンゲームです。

https://cryptospells.jp/

今回は、コントラクトの所有権を制御できる**ERC173**をよりコンパクトにした**ERC5313**についてまとめていきます！

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

https://eips.ethereum.org/EIPS/eip-5313

:::message
**ERC173**については以下にまとめられています。
:::

[\[ERC173\] コントラクトの所有権を制御できる仕組みを理解しよう！](/articles/0b8cdc156404920a8cbd)

## 要約
この提案では、コントラクトを制御するアカウントを特定するために必要な最小限のインターフェースを定義しています。

:::message
「**そもそもインターフェースって何？**」という方は以下の記事を参考にしてください！
:::

https://chaldene.net/erc721#st-toc-h-5

## 仕様

このEIPに準拠するすべてのコントラクトは、**EIP5313**インターフェースを実装しなければなりません。

```javascript
// SPDX-License-Identifier: CC0-1.0
pragma solidity ^0.8.15;

interface EIP5313 {
    function owner() view external returns(address);
}
```
### owner

コントラクトの所有者のアドレスを取得する関数。

コントラクトに所有権の概念を実装するための最小限のメソッドを定義しています。

![ブログERC & EIP (3).png](/images/qiita-e14761c8-133a-0ec2-4b57-900f4e2bb95b.webp)


## 補足
この標準の提案にあたり、以下を意識しています。

- インターフェース内の関数の数を最小限に抑えること。
- 既存のコントラクトとの後方互換性を保つこと。


この標準は、他の標準によって拡張することができ、コントラクトの所有機能を追加できます。
インターフェース内の関数の数を減らすことで、より簡単な所有権の実装が可能となります。

:::message
詳細は以下の**ERC173**を参照してください。
:::

[\[ERC173\] コントラクトの所有権を制御できる仕組みを理解しよう！](/articles/0b8cdc156404920a8cbd)

## 後方互換性
**ERC173**を実装しているすべてのコントラクトは、すでにこの仕様を実装しています。

## セキュリティ上の考慮事項
この仕様書は**EIP165**を拡張しないため、この提案の`owner`関数を呼び出しても、その結果が本当にコントラクトの所有アドレスであることを完全に保証できません。
例えば、同じ関数シグネチャを持つ別の関数が、コントラクトの所有者アドレスではないアドレスを返す可能性があります。
あるアドレスがコントラクトの所有者どうかを判別するためにのみこの実装を使用する場合、上記のリスクの影響は最小限に抑えられます。
ただし、例えば貴重なNFTをコントラクトの所有者アドレスに送る場合は、リスクが高まります。

![ブログERC & EIP (5).png](/images/qiita-88288a48-a8b3-3979-b263-57df596e0c13.webp)

:::message alert
コントラクトの所有者アドレスだと思って送ったアドレスが、実はコントラクトの所有者アドレスではない可能性がある。
:::

## 考察

この**ERC5313**として、提案されているインターフェースを使用する場面はあまりないのかなと思いました。
つまり、**ERC173**などを参考にして**ERC5313**で提案されている実装が既にされていると思っています。
この提案はざっくりまとめると、「**コントラクトの所有権を持つアドレスの確認**」となり、**ERC173**の確認部分のみを切り出したものになります。

**セキュリティ上の考慮事項**で述べられているような、「**コントラクトの所有者か判定してなんらかの処理を実行する**」は既に以下で実装されています。

https://docs.openzeppelin.com/contracts/4.x/api/access#Ownable

そのため、最初に述べたように**ERC5313**として実装することはないのではないかと思った次第です。
もしかしたら上記実装にあたり**ERC5313**を参考にしているのかもしれないですが...。

また、補足としてコントラクト内での権限管理は以下のような**Access Control**があります。

https://docs.openzeppelin.com/contracts/2.x/access-control

## 最後に

今回は「コントラクトの所有権を制御できる**ERC173**をよりコンパクトにした**ERC5313**」についてまとめてきました！
いかがだったでしょうか？

実装については今後追記していきます。

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

[Twitter @cardene777](https://twitter.com/cardene777)

## 採用強化中！

CryptoGamesでは一緒に働く仲間を大募集中です。

https://www.wantedly.com/companies/cryptogames

この記事で書いた自分の経験からもわかるように、裁量権を持って働くことができて一気に成長できる環境です。
「ブロックチェーンやWeb3、NFTに興味がある」、「スマートコントラクトの開発に携わりたい」など、少しでも興味を持っている方はまずはお話ししましょう！