EIP是以太坊生態中相當重要的一個組成部分，它推動了以太坊的發展，豐富了以太坊的生態，起著導向作用並扮演著風向標的角色。
在以太坊生態中，我們經常聽到一個詞“EIP”，比如典型的EIP-1559、EIP-20、EIP-721等。這個耳熟能詳的詞經常出現在以太坊發展的關鍵節點以及各種以太坊應用中。
那什麼是EIP呢？
我們將在這篇文章中給大家作一個簡單的介紹。
一什麼是EIP？
EIP全稱是Ethereum Improvement Proposal。它是一系列以太坊平台上推薦使用的標準和協議的統稱。它所包含的具體標準和協議涉及以太坊的核心協議、客戶端API、智能合約標準等。每一個EIP包含對某個標准或協議的定義。
我們所熟知的眾多知名通證標準如同質通證（EIP-20）、非同質通證（EIP-721、EIP-1155）等都出自EIP提案庫；我們所見證的眾多以太坊發展史上具有里程碑意義的事件如對Gas機制的改革（EIP-1559）、以太坊的合併（EIP-3675）等也都基於EIP提案庫中的提案標准進行。
二EIP的種類
EIP根據其涉及的領域不同大體可以分為三大類：Standards Track EIP、Meta EIP和Informational EIP。
1 Standards Track EIP
它描述的是任何改變以太坊所有或大多數實現細節的EIP，比如對網絡協議的改變、對區塊或交易有效性判別的改變、新的應用規範、對應用互操作性的改變等。
一個Standards Track EIP包含三部分：設計文檔、實現代碼以及規範定義。更進一步，Standards Track EIP又可以被分為四個子類：Core、Networking、Interface、ERC。
Core：這類EIP指可能導致分叉的對以太坊共識的修改（如EIP-5、EIP-101等）或者對以太坊核心開發相關部分的修改（如EIP-90等）。
Networking：這類EIP指對以太坊網絡通信devp2p （EIP-8）和Light Ethereum Subprotocol的修改或對whisper和swarm網絡協議的修改。
Interface：這類EIP指對以太坊客戶端API/RPC定義和標準的修改以及對調用方法名稱（如EIP-6）和合約ABI等的修改。在EIP庫中有一個[interfaces repo]庫，此類EIP在被提交到EIP庫以前盡量在[interfaces repo]庫裡進行提交討論。
ERC：ERC的全稱是Ethereum Request for Comments。這類EIP主要涉及應用層，包括通證標準（如EIP-20），命名註冊（如EIP-137）、URI格式、代碼庫及代碼包格式、錢包格式等。
在以太坊的應用開發中，很多開發者經常提到或聽到的ERC就是此類EIP。比如EIP-20也被很多開發者成為ERC-20。可以說，ERC是EIP的一個子集。
2 Meta EIP
Meta EIP通常指對以太坊周邊相關事物或者對以太坊本身某個流程（或事件）的改進。這類EIP也有可能提出對某個以太坊實現方式的改進，但這種改進不涉及以太坊的代碼庫。這類EIP通常需要社區達到共識。它不僅僅是建議，而是社區用戶不得不遵循的規則。典型的Meta EIP包括對流程的修改，對用戶指南的修改，對決策過程的修改、對以太坊開發工具及開發環境的修改等等。這類EIP也被稱為Process EIP。
3 Informational EIP
Informational EIP主要針對以太坊的設計、以太坊社區的通用指南或信息給出改進意見。這類EIP通常不會提出新的功能或特性，它也不一定代表以太坊社區的共識或建議。因此用戶或開發者可以僅將其作為參考而不必強制遵循。
三EIP的評審流程及狀態
一般來說，一個EIP從構思到被正式認可，要經歷下列流程：構思（Idea）、草案（Draft）、審核（Review）、最後審稿（Last Call）、定稿（Final）、停滯（Stagnant）、撤回（Withdrawn）和動態（Living）。
構思（Idea）：這主要指作者在擬草案前對EIP的構想、組織和整理。這一狀態並不會在EIP庫中顯示。
草案（Draft）：這是一份EIP被提交後，第一個顯示在EIP庫中的狀態。一份符合撰寫格式的EIP被提交後會被EIP編輯整理合併到EIP庫中。
審核（Review）：這個狀態表明EIP作者認為該EIP已經初步完善，要求相關人員對其進行審核。
最後審稿（Last Call）：這是一個EIP的最後階段的審核。 EIP編輯會為EIP設定一個最後的截止審核時間，通常是14天。這一階段的審查如果發現EIP仍然有需要進行嚴肅修改的地方，則該EIP的狀態會被修改為“審核（Review）”。
定稿（Final）：這是一個EIP的最後狀態。一個被“定稿”的EIP即便還需要修改也無需大改，僅僅只進行一些細節方面的完善。
停滯（Stagnant）：如果EIP的狀態為“Draft”、“Review”或“Last Call”並維持此狀態超過6個月，則狀態會變為“Stagnant”。此時，EIP的作者或編輯可以主動將其狀態改為“Draft”或其先前的狀態，否則該EIP會永遠處於“Stagnant”狀態。
撤回（Withdrawn）：EIP作者撤回其提交的EIP後，其EIP狀態就會變為“Withdrawn”。一旦EIP狀態變為這個狀態，就無法再改變了。如果作者撤回EIP後，重新整理或修改了其想法，並再次提交，則EIP會被提交為一個新的EIP。
動態（Living）：這是一種特殊的狀態。處於這種狀態的EIP會被持續更新，而不會有一個最終狀態。最典型的此類EIP就是EIP-1。
上面的狀態可以用下圖表示：
四EIP的格式及內容
一份標準的EIP一般包含下列內容：
前言（Preamble）：前言的格式需遵循RFC 822標準，包含EIP的元數據（metadata）、EIP編號、標題（44個字符以內）、描述（140個字符以內）和作者信息。注意：標題和描述中無需註明本EIP的編號。
概述（Abstract）：概述通常用一小段話描述EIP的技術要點，讓讀者快速理解此EIP的要點、了解它要解決的問題。
動機（Motivation）：動機為可選寫部分。雖然是非必要，但對某些EIP（比如要改進以太坊協議）而言，對動機的描述非常重要。它需要清晰地表述為什麼現有的協議、標準等不足以或無法解決此EIP所要解決的問題。當然，如果一個EIP的動機顯而易見，作者也可以忽略不寫。
定義（Specification）：此部分需要從技術角度對EIP中各個特性、方法的語法、語義等進行詳細描述。它需要細化到以太坊的各個客戶端平台（比如cpp-ethereum、go-ethereum、parity、ethereumJ、ethereumjs-lib等）都能實現，並做到兼容和互操作。
原理（Rationale）：此部分詳述“定義”的緣由和推理過程。作者最好在此部分也列舉一下在構思EIP的過程中設想的其它方案以及進行的其它相關工作，比如某個定義的特性、方法用其它編程語言該如何實現等。此部分尤其要列舉構思及討論EIP過程中出現的反對意見及擔憂。
後向兼容（Backwards Compatibility）：此部分亦為可選寫。但對所有可能存在後向兼容問題的EIP，則此部分為必須。作者須盡量在此部分詳細羅列此EIP可能引發的種種不兼容問題和可能導致的後果。此外，作者還需盡量給出解決這些問題的建議和方法。對不會引入後向兼容問題的EIP，此部分可忽略。
測試用例（Test Cases）：此部分可選寫。但對要改進共識協議代碼的EIP（比如Core類別），則此部分必須。測試用例可以在EIP中寫成輸入/輸出形式比如“input/expected output”或以文件形式寫為“../assets/eip-###/”。對於非Core類別的EIP，此部分可忽略。
參考實現（Reference Implementation）：此部分可選寫。此部分包含了作者給出的具體的參考實現方式（比如參考代碼）。它能幫助讀者更好地理解一個EIP。
安全考慮（Security Considerations）：所有的EIP都必須包含此部分。作者在這部分主要應提及此EIP帶來的改動可能引發什麼潛在的安全問題或註意事項，並對這些潛在問題或事項盡可能給出可行的建議及措施。一個沒有包含這部分內容的EIP將被拒絕，且不可能進入到“Final”狀態。
版權放棄聲明（Copyright Waiver）：所有的EIP都屬於知識產權法規中的公有領域（public domain）。版權放棄聲明必須指明相關的授權文件，使用“Copyright and related rights waived via [CC0](/LICENSE).”的表述。
上述內容為EIP作者在撰寫EIP標準時需要包含的內容，是每個作者在撰寫時都必須了解和熟知的。遵循這些標準寫出的EIP不僅能讓讀者和編輯更清晰的了解一個EIP，並能夠加快EIP的審核進度和提高審核效率。
五EIP的撰寫及審核涉及的相關方
EIP的撰寫及審核主要會涉及兩方：EIP作者和EIP編輯。
EIP作者的主要職責就是構思和撰寫EIP。
以太坊是一個開源的社區，它面向全世界愛好者和開發者，因此全世界所有關注以太坊發展和開發的人士都可以向EIP庫提交自己撰寫的EIP。
我們建議作者在撰寫EIP之前最好先梳理一下自己的想法，並在以太坊社區的論壇（比如Ethereum Magicians forum）中發帖和大家討論自己的想法。這可以避免因提交重複的EIP而被拒絕，浪費作者的時間和精力。
當作者的想法在社區被證明大概率還未被列為EIP之後，就可以開始撰寫EIP了。不過在撰寫的過程中，作者一定要注意所寫EIP的類別與其所需要的工作量是要匹配的。比如寫一個類別為Core的EIP其工作量就比寫一個類別為ERC的EIP要大得多，並且前者需要有足夠多的以太坊客戶端團隊願意採納才行。 EIP作者要注意社區對EIP的負面意見，有時這些負面意見很可能導致EIP僅僅停留在“Draft”階段。
EIP編輯的主要職責是審核EIP。
他們通常要進行以下事項：
1 審閱提交的EIP。編輯會根據EIP標準中定義的各項內容檢查其是否符合要求，判斷該EIP是否合理及完備。如果編輯認為該EIP仍有待完善，則會告知作者進行進一步完善和修改。
如果編輯認為該EIP基本完善，則進行下一步：
2 給提交的EIP分配一個EIP編號，將其納入EIP庫，通知作者進入下一步工作。
六小結
EIP是以太坊生態中相當重要的一個組成部分，它推動了以太坊的發展，豐富了以太坊的生態。
一方面，它在技術方面匯聚了以太坊社區對加密技術最前沿的探討和智慧，另一方面也在社區建設方面成為凝聚和發展以太坊核心社區的支柱之一。
毫無疑問，EIP在以太坊及其生態的發展和壯大中起著導向作用並扮演著風向標的角色。
放眼未來，隨著以太坊在智能合約公鏈生態中所扮演的先鋒角色越來越突出，EIP將不僅是以太坊社區和開發者關注的焦點，也將成為整個加密生態愛好者探索和研究的焦點。
我們鼓勵所有關心以太坊發展，深度參與以太坊發展的用戶及愛好者都能參與到以太坊EIP的構思和撰寫中來，為EIP也為以太坊的發展作出自己的貢獻。
