# [EIP1] EIPの目的とガイドラインについて理解しよう！

> EIPは、Ethereum Improvement Proposal（Ethereum改善提案）の略です。Ethereumコミュニティに対しての情報提供や、Ethereumの新機能ついての設計文書です。

- URL: https://cardene.dev/articles/24768d24a8d222a07107
- 公開日: 2024-05-13
- 更新日: 2024-05-13
- トピック: Blockchain
- タグ: ethereum, solidity, smartcontract, ブロックチェーン

## はじめに

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

https://cryptogames.co.jp/

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

https://cryptospells.jp/

今回は、EIPの目的とガイドラインである**EIP1**についてまとめていきます！

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

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

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

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4

## EIPとは？

EIPは、Ethereum Improvement Proposal（Ethereum改善提案）の略です。
Ethereumコミュニティに対しての情報提供や、Ethereumの新機能ついての設計文書です。

## EIPの目的

EIPには以下の三つの目的があります。

- **新機能の提案**
    - Ethereumの機能拡張や改良に関する提案を形式化します。
- **コミュニティの技術的意見の収集**
    - 開発者やユーザーからのフィードバックを集めてより良い設計にします。
- **設計決定の文書化**
    - どうしてその設計にしたのか、なぜ必要なのかなどを記録して透明性を高めます。

EIPはテキストファイルとしてGithubでバージョン保管されています。
これにより、EIPの変遷を追跡できるため、開発者にとっては実装の進行状況を把握するのに便利です。
理想的には、各実装の提案者自身が実装したEIPのリストを公開し、エンドユーザーが現在の実装状況やライブラリのステータスを簡単に確認できるようにすることが望まれます。

## EIPの種類

Ethereum Improvement Proposals（EIP）には、主に三つのタイプがあります。

### Standards Track EIP
このEIPは、 ほぼ全てのEthereum実装に影響を与える変更です。
例としては、ネットワークプロトコルの変更、ブロックやトランザクションの有効性ルールの変更、アプリケーション標準や規約の提案などがあります。

#### Core
コンセンサスフォークを必要とする改善や、コア開発者の議論に関連する変更（例：**EIP5**、**EIP101**）。

:::message
**EIP5**については以下の記事を参考にしてください。
:::

[\[EIP5\] 使用したメモリに対してのみガス代を支払う仕組みを理解しよう！](/articles/6c666cba3523af2d7ce5)

#### Networking
devp2p（**EIP8**）やLight Ethereum Subprotocolの改善、whisperやswarmのネットワークプロトコル仕様の提案改善。

:::message
##### devp2p（EIP-8）
devp2pは、Ethereumノード間での通信を管理するための基本的なプロトコルです。
**EIP8**は、この通信プロトコルにおいて、互換性の問題を解決してより堅牢な接続を可能にする改善を提案しています。
具体的には、異なるバージョンのプロトコル間でも通信がスムーズに行えるように設計変更を行う内容です。

##### Light Ethereum Subprotocol
フルノードではなくライトクライアントのためのサブプロトコルです。
ライトクライアントが必要なデータのみを効率的に取得し、Ethereumネットワークと効果的にやり取りできるようにするための改善が含まれます。

##### whisperとswarmのネットワークプロトコル仕様の提案改善
**Whisper**は、Ethereumネットワーク上での非同期かつ匿名のメッセージングプロトコルです。
セキュリティを高め、効率的なメッセージングを実現するための改善が提案されています。

**Swarm**は、分散型ストレージとコンテンツ配布を目的としたプロトコルで、Ethereumアプリケーションがデータを分散して保管し、アクセスするための効率的な方法を提供することを目指しています。
これに関連する改善提案は、より高速かつ信頼性の高いデータアクセスを可能にするためのものです。
:::

#### Interface
メソッド名（**EIP6**）やコントラクトABIなど、言語レベルの標準に関する改善。

:::message
**EIP6**については以下の記事を参考にしてください。
:::

[\[EIP6\] SUICIDEからSELFDESTRUCTへ用語を置き換える提案を理解しよう！](/articles/077e34aa46bf93cee4e8)

#### ERC
トークン標準（**ERC20**）、Nameレジストリ（**ERC137**）など、アプリケーションレベルの標準や規約。

:::message
**ERC20**については以下の記事を参考にしてください。
:::

https://chaldene.net/erc20

:::message
**ERC137**については以下の記事を参考にしてください。
:::

[\[ERC137\] アドレスに任意の名前を紐付けるENSの仕組みを理解しよう！](/articles/17e6e1a452006f08a197)

### Meta EIP
Ethereumの運用や決定プロセス、開発環境の変更など、Ethereumコミュニティの運営やプロジェクト管理の方法についての提案です。

### Informational EIP
Ethereumの設計問題について説明したり、Ethereumコミュニティに一般的なガイドラインや情報を提供します。
新しい機能を提案するものではなく、ガイドラインに従うかも任意です。

## EIPワークフロー

![EIP-process-update.jpg](/images/qiita-bc213515-bb39-8e14-fb97-583ba474dd84.webp)
引用: https://eips.ethereum.org/EIPS/eip-1

EIP（Ethereum Improvement Proposal）は、新しいアイディアがどのように検討され、採用されるまで以下のステージを踏みます。

1. **Idea (アイデア)**
    - 正式なドラフト前のアイデア段階で、EIPリポジトリでは追跡されません。
    - フォーラムなどでやり取りされています。
2. **Draft (ドラフト)**
    - アイデアが形式化され、EIPリポジトリに正式にマージされる最初のステージです。
3. **Review (レビュー)**
    - EIP著者によって、ピアレビューの準備が整ったとマークされます。
4. **Last Call (ラストコール)**
    - EIPが最終的に採用される前の最終レビュー期間です。
    - 通常14日間設定され、この期間中に重要な変更が必要とされた場合、EIPはレビューステージに戻されます。
5. **Final (ファイナル)**
    - EIPが最終的な標準として確定します。
    - このステータスのEIPは原則として更新されるべきではなく、誤りの修正や非規範的な明確化の追加のみが許可されます。
6. **Stagnant (停滞)**
    - ドラフト、レビュー、ラストコールのいずれかのステータスで6ヶ月以上活動がない場合、EIPは停滞ステータスに移行されます。
    - この状態からの復活は、著者またはEIPエディターによって、ドラフトまたは以前のステータスに戻すことで可能です。
7. **Withdrawn (撤回)**
    - EIP著者が提案を撤回した場合、このステータスが適用されます。
    - この状態は最終的であり、同じEIP番号を使って再活性化することはできません。
8. **Living (生存)**
    - 継続的に更新されることが意図されており、最終的な状態に達することがないEIPに適用されます。代表的な例として**EIP1**があります。

プロセスの初期段階では、アイデアの元々性や実現可能性をコミュニティで議論し、Ethereum Magiciansフォーラムで意見を求めることが推奨されます。
アイデアが承認された後、EIPを通じて提案を進め、コミュニティからのフィードバックを受け入れる責任が著者にあります。
特にCore EIPの場合、実装をクライアントに提供するか、クライアントに実装を説明する必要があります。

## 成功するEIPに含まれれるもの

成功するEIPには、以下の各セクションが含まれています。

#### Preamble (序文)
**RFC 822**形式のヘッダーで、EIPのメタデータ（EIP番号、最大44文字のタイトル、最大140文字の説明、作者の詳細）を含みます。
カテゴリーに関わらず、タイトルや説明にはEIP番号を含めてはいけません。

:::message
**RFC 822**は、インターネット上で電子メールメッセージのフォーマットを定義する標準
:::

#### Abstract (要約)
技術仕様を要約して、このセクションだけ読んでもそのEIPが何をするものかの要点を理解できる必要があります。

#### Motivation (動機): 任意
Ethereumプロトコルを変更することを目指すEIPにとって重要です。
既存のプロトコル仕様が問題を解決するのに不十分である理由を明確に説明する必要があります。

#### Specification (仕様): 任意
新機能の仕様について詳細に説明する必要があります。

#### Rationale (根拠)
なぜこの設計にしたいのかについて説明する必要があります。
代替設計や関連作業について説明し、議論で提起された懸念について取り上げたりしています。

#### Backwards Compatibility (下位互換性): 任意
後方互換性を損なう変更を導入するすべてのEIPはその詳細を説明する必要があります。

#### Test Cases (テストケース): 任意
合意形成に影響を与えるEIPには、実装のテストケースが必須です。
テストはEIP文書内にインラインで、または外部ファイルとして含めることができます。

#### Reference Implementation (参照実装): 任意
この仕様を理解または実装するのに役立つ参考実装などを含む必要があります。

#### Security Considerations (セキュリティ考慮事項)
提案された変更に関連するセキュリティの影響/考慮事項を議論するセクションを含む必要があります。

#### Copyright Waiver (著作権放棄)
すべてのEIPはパブリックドメインである必要があります。

## EIPのフォーマットとテンプレート

EIPはマークダウンで記述して、以下のテンプレートに従う必要があります。

https://github.com/ethereum/EIPs/blob/master/eip-template.md

## EIPヘッダー序文

EIPの最初には、**RFC 822**形式のヘッダーを含みます。
このヘッダーは、以下のEIPのメタデータを整理して提案の追跡と識別を容易にします。

- **eip**
    - EIPの番号。
- **title**
    - EIPのタイトル。
- **description**
    - 簡潔な一文での説明。
- **author**
    - 著者の名前、ユーザーネームかメールアドレス。
    - 最低一人の著者はGitHubユーザーネームを使用し、変更リクエストの通知を受け取り、それに対して承認または拒否ができるようにする。
- **discussions-to**
    - EIPの公式ディスカッションスレッドへのURL。
- **status**
    - EIPの現在のステータス。
    - **Draft**、**Review**、**Last Call**、**Final**、**Stagnant**、**Withdrawn**、**Living**の中から選ぶ。
- **last-call-deadline**
    - ラストコール期間が終了する日付。
    - ステータスが**Last Call**のときにのみ必要。
- **type**
    - EIPのタイプ。
    - **Standards Track**, **Meta**, **Informational**の中から選ぶ。
- **category**
    - EIPのカテゴリ。
    - **Core**, **Networking**, **Interface**, **ERC**の中から選ぶ
    - Standards Track EIPにのみ必要。
- **created**
    - EIPが番号を割り当てられた日付。
- **requires**
    - このEIPが依存する他のEIP番号。
- **withdrawal-reason**
    - EIPが撤回された理由を説明する文。
    - ステータスが**Withdrawn**のときにのみ必要。

## 外部リソースへのリンク

EIP文書において外部リソースへのリンクを含める時には、特定の基準と規則に従う必要があります。
外部リソースが削除されたり移動する可能性があるため、今後も参照可能であることを保証するためです。

#### Ethereum Execution Client Specifications
Ethereumの実行クライアントの仕様に関するリンクは許可されており、具体的なコミットを指す必要があります。
使用されるURLは正確なコミットハッシュにアンカーされるべきです。

```
[Ethereum Execution Client Specifications](https://github.com/ethereum/execution-specs/blob/9a1f22311f517401fed6c939a159b55600c454af/README.md)
```

#### Ethereum Consensus Layer Specifications
Ethereumのコンセンサス層の仕様に関するリンクも許可されており、こちらも具体的なコミットを指す必要があります。

```
[Beacon Chain](https://github.com/ethereum/consensus-specs/blob/26695a9fdb747ecbe4f0bb9812fedbc402e5e18c/specs/sharding/beacon-chain.md)
```

#### Ethereum Networking Specifications**
ネットワーキング仕様に関するリンクには、特定のコミットにアンカーするURLが必要です。

```
[Ethereum Wire Protocol](https://github.com/ethereum/devp2p/blob/40ab248bf7e017e83cc9812a4e048446709623e8/caps/eth.md)
```

#### World Wide Web Consortium (W3C)
W3Cの「**Recommendation**」ステータスの仕様へのリンクが許可されており、技術報告書名前空間内の日付付きURLにアンカーされるべきです。

```
[Secure Contexts](https://www.w3.org/TR/2021/CRD-secure-contexts-20210918/)
```

#### Web Hypertext Application Technology Working Group (WHATWG)
WHATWGの仕様へのリンクは、特定のコミットスナップショットを指す形で許可されています。

```
[HTML](https://html.spec.whatwg.org/commit-snapshots/578def68a9735a1e36610a6789245ddfc13d24e0/)
```

#### Internet Engineering Task Force (IETF)
IETFのRFC（Request For Comment）仕様へのリンクは許可されており、割り当てられたRFC番号があるもののみを参照する必要があります。

```
[RFC 8446](https://www.rfc-editor.org/rfc/rfc8446)
```

#### Bitcoin Improvement Proposal
Bitcoinの改善提案へのリンクは、特定のコミットを指すURLが必要です。

```
[BIP 38](https://github.com/bitcoin/bips/blob/3db736243cd01389a4dfd98738204df1856dc5b9/bip-0038.mediawiki)
```

#### National Vulnerability Database (NVD)
CVE（Common Vulnerabilities and Exposures）システムへのリンクは、最新の変更日付を含む形で許可されています。

```
[CVE-2023-29638 (2023-10-17T10:14:15)](https://nvd.nist.gov/vuln/detail/CVE-2023-29638)
```

#### Digital Object Identifier System (DOI)
DOIを含むリファレンスは、関連するドキュメントへのリンクを含む必要があり、そのトップレベルURLは無料で閲覧可能なドキュメントのコピーを指し示す必要があります。

```
This is a sentence with a footnote.[^1]

[^1]:
```csl-json
{
  "type": "article",
  "id": 1,
  "author": [
    {
      "family": "Jameson",
      "given": "Hudson"
    }
  ],
  "DOI": "00.0000/a00000-000-0000-y",
  "title": "An Interesting Article",
  "original-date": {
    "date-parts": [
      [2022, 12, 31]
    ]
  },
  "URL": "https://sly-hub.invalid/00.0000/a00000-000-0000-y",
  "custom": {
    "additional-urls": [
      "https://example.com/an-interesting-article.pdf"
    ]
  }
}
```
```

# 他EIPの参照

EI内で他のEIPを参照する際は以下のルールに従う必要があります。

- **参照形式**
    - 他のEIPを参照する時は、「**EIP-N**」という形式を使用します。
    - 「**N**」は参照しているEIPの番号です。
- **リンクのパス**
    - リンクは常にGithubの相対パスを使用して設定する必要があります。
- **例**
    - このEIP（**EIP-1**）へのリンクは `./eip-1.md` になります。

# ファイル

EIP内で使用する画像、図表については以下のルールに従う必要があります。

- **ファイルの格納場所**
    - 該当EIP専用のサブディレクトリ（`assets/eip-N`）に格納します。
- **ファイルへのリンク方法**
    - EIP文書内でこれらのファイルにリンクする時は、相対リンクを使用します。
    - 例えば、**EIP-1**の画像にリンクする場合は、「`../assets/eip-1/image.png`」となります。

# EIPの所有権譲渡

EIPの更新にさける時間がなかったり、連絡が取れなくなった場合に所有権を新しいユーザーに移譲する必要あります。

EIPの所有権を引き継ぎたい場合は、元の著者とEIPエディターの両方に宛てて引き継ぎを希望するメッセージを送信します。
元の著者が返信しない場合、EIP編集者が一方的な決定を下します。

# EIP編集者の責任

EIP編集者の役割には、以下のように新たに提出されたEIPの初期評価と管理です。

- **EIPの評価**
    - 新しいEIPを読み、技術的に意味があるか、完全であるかを確認します。
    - 提案が最終的に承認される可能性が低い場合でも、技術的には理解できる必要があります。
- **タイトルのチェック**
    - EIPのタイトルが内容を正確に表しているかを確認します。
- **言語とマークアップのチェック**
    - スペリング、文法、文の構造、GitHub形式のMarkdownでのマークアップやコードスタイルをチェックします。

- **修正が必要な場合**
    - EIPが準備不足の場合、編集者は具体的な指示とともに著者に修正を依頼します。

- **EIPの準備ができたら**
    - EIPがリポジトリに適した状態になると、編集者は以下の手順を踏みます。
    - **EIP番号の割り当て**
        - 通常は連番で割り当てられますが、番号のスナイピングが疑われる場合は再割り当てが行われることもあります。
    - **プルリクエストのマージ**
        - 対応するプルリクエストをマージします。
    - **次のステップについて著者に通知**
        - EIP著者に対して次のステップについてメッセージを送ります。

EIPエディターは、EIPに対して技術的な判断を下すわけではなく、主に管理的および編集的な役割を果たします。
多くのEIPは、Ethereumコードベースへの書き込みアクセスを持つ開発者によって書かれており、EIPエディターは変更を監視し、構造、文法、スペリング、マークアップの間違いを訂正します。

# スタイルガイド

EIPのスタイルガイドには、タイトル、説明、EIP番号、および用語の使用に関する明確なガイドラインが含まれています。

### タイトル
タイトルフィールドには「**standard**」またはその派生語を含めてはいけません。
EIPの番号をタイトルに含めてはいけません。

### 説明
説明フィールドには「**standard**」またはその派生語を含めてはいけません。
EIPの番号を説明に含めてはいけません。

### EIP番号
ERCカテゴリのEIPを参照する場合は、「**ERC-X**」という形式で記述し、XはそのEIPに割り当てられた番号です。
ERC以外のカテゴリのEIPを参照する場合は、「**EIP-X**」という形式で記述し、XはそのEIPに割り当てられた番号です。

### RFC 2119とRFC 8174
EIPは、用語に関して**RFC 2119**および**RFC 8174**に従うことが推奨されます。
「MUST」、「MUST NOT」、「REQUIRED」、「SHALL」、「SHALL NOT」、「SHOULD」、「SHOULD NOT」、「RECOMMENDED」、「NOT RECOMMENDED」、「MAY」、「OPTIONAL」といったキーワードは、RFC 2119およびRFC 8174に記載されている通りに解釈されるべきです。
これらのキーワードは仕様セクションの冒頭に挿入することが推奨されます。

# 履歴

このEIPは、Bitcoinの**BIP-0001**（Bitcoin Improvement Proposal）から大きく影響を受けており、**BIP-0001**自体もPythonの**PEP-0001**（Python Enhancement Proposal）から派生しています。
**BIP-0001**はAmir Taakiによって書かれましたが、その多くのテキストは**PEP-0001**から直接コピーされ、変更されたものです。
**PEP-0001**のテキストはBarry Warsaw、Jeremy Hylton、David Goodgerによって書かれましたが、これらの著者はEthereum改善プロセスには一切関係がなく、EthereumやEIPに関するすべてのコメントは、EIPの編集者へ向けられるべきです。

# 引用

Martin Becze <mb@ethereum.org>, Hudson Jameson <hudson@ethereum.org>, et al., "EIP-1: EIP Purpose and Guidelines," Ethereum Improvement Proposals, no. 1, October 2015. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-1.

# 引用

Martin Becze <mb@ethereum.org>, Hudson Jameson <hudson@ethereum.org>, et al., "EIP-1: EIP Purpose and Guidelines," Ethereum Improvement Proposals, no. 1, October 2015. [Online serial]. Available: https://eips.ethereum.org/EIPS/eip-1.

# 最後に

今回は「EIPの目的とガイドラインである**EIP1**」についてまとめてきました！
いかがだったでしょうか？

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

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

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

https://chaldene.net/

https://zenn.dev/heku

https://cardene.substack.com/

https://mirror.xyz/0xcE77b9fCd390847627c84359fC1Bc02fC78f0e58

https://cardene.notion.site/ERC-EIP-2a03fa3ea33d43baa9ed82288f98d4a9?pvs=4