以太坊改良提案 Ethereum Improvement Proposals (EIP)

由於「在 2022 年我們該如何寫智能合約」影片系列即將進入與 ERC20 代幣等相關的主題，因此我們接下來幾天會依序來聊聊什麼是 EIP 與 ERC，以及目前主流的幾個 ERC 的標準。

什麼是以太坊改良提案

以太坊改良提案的標準被定義在 EIP 提案編號 1。本文將以 EIP-1 為主，進行修改與翻譯所寫成。

以太坊改良提案 Ethereum Improvement Proposals，簡稱 EIPs ，它是一份設計文件用來描述提案內容、定義以太坊的新功能或新特性、或定義新流程。
在這份文件中，應該提供清晰簡潔的功能技術規格、需要這個改良的理由。且提案者須負責跟社群進行溝通，並記錄下各種不同的意見與建議。在取得共識之後，才會正式被承認。

以太坊改良提案的種類

一般來說，EIP 可分為三大類：

1. Standards Track EIP：
   任何大幅對以太坊實作相關的改變都應屬於此種類，包含但不限於：對網路協議的修改、對區塊或交易的驗證機制的修改、對應用標準的修訂等等。
   Standards Track EIP 須包含以下幾個部分：
   A. 設計文件（design document）
   B. 實作（implementation）
   C. 對正式規格的更新（updated formal specification）
   且他通常會再被細分成以下四個子種類：
   1.1. 核心（Core）：這類的修改可能需要仰賴共識分叉，如 EIP-5: Gas Usage for RETURN and CALL*, EIP-101: Serenity Currency and Crypto Abstraction；或者不一定需要共識分叉但對核心開發（Core Dev）息息相關，如：EIP-86: Abstraction of transaction origin and signature
   1.2. 網路（Networking）：這類的修改著重在 devp2p，如 EIP-8: devp2p Forward Compatibility Requirements for Homestead ；輕量以太坊子協議（Light Ethereum Subprotocol）；或針對 whisper 與 swarm 的網路協議規格的改進。
   1.3. 介面（Interface）：包含對客戶端的 API 或 RPC 的規格與標準的改進；對語言層級標準的改進，像是 EVM 指令的改進，如：EIP-6: Renaming SUICIDE opcode；與合約的 ABIs 定義。
   1.4. ERC：應用層級的標準與公約，包含合約的標準，如：代幣標準 EIP-20，以太坊域名系統 EIP-137，函式庫或套件的格式，與錢包的格式等。

2. Meta EIP (或 Process EIP)

流程型 EIP ，描述了對以太坊的流程，或對現存流程的修正。流程型 EIP 定義了除在 Standards Track EIPs 裡面所提的以太坊協議本體外的其他領域。如：提出一個無關以太坊程式碼庫(Ethereum's codebase)的實作。這類型的 EIP 通常需要得到社群的共識，因此開發者與使用者都必須重視以待。例如：程序、指南、對決定流程的改變、對開發工具或開發環境的修改等。

3. 資訊型 EIP（Informational EIP）

資訊型的 EIP 描述了對以太坊的設計主題、提供給以太坊社群通用的指南或資訊，但不包含提出新的特性或功能。
且資訊型 EIP 不需要取得以太坊社群的共識或者推薦，因此使用者與開發者不需要特別在意資訊型 EIP，也不一定要遵守裡頭的建議。

EIP 的核心概念

一個 EIP 應著重在擔一個關鍵提案或者想法，越專注在單點，則越容易讓 EIP 被接受。反之，一個包山包海且過分複雜的 EIP 很難被社群接受。
此外，有共通性的修改才需要發起 EIP，若只針對特定的客戶端的修改，那不需要 EIP，只需要去該客戶端那發問即可；反之，當這個修改需要仰賴多個客戶端、或定義會影響到眾多應用的新標準就需要發起 EIP。

EIP 的限制

每一個 EIP 都需達到最低的標準。它必須有一份清晰且對於提案的改良有著完善描述。且提出的實作必須是穩固且不會過份複雜化協議。

關於核心 EIPs 的特殊要求

若 Core EIP 需要修改以太坊虛擬機，在文件中應參照到該指令或以以下格式定義指令：

REVERT (0xfe)