Sign in Subscribe
ethereum

Ethereum Improvement Proposals

Subin An

• 10 min read
Ethereum Improvement Proposals
Photo by Michael Förtsch / Unsplash
해당 자료는 EIP-1 : EIP Purpose and Guide을 기반으로 번역 및 추가한 내용입니다.

이더리움은 오픈소스이며 많은 이들의 지식을 통해 점진적으로 개선되고 있습니다. EIP는 Ethereum Improvement Proposals의 약어로 말 그대로 "이더리움 개선 제안"입니다. EIP는 이더리움의 핵심 프로토콜 등 기술적인 부분을 포함하여 커뮤니티에 도움이 되는 정보 등을 제안하는 설계 문서입니다.

EIP 작성자는 간결한 설명과 기능에 대한 근거를 제공해야 하며, 이를 커뮤니티 구성원이 합의도록 노력해야 합니다. 또한 해당 제안에 대한 반대 의견도 문서화할 책임을 지니고 있습니다.

대다수 메인넷 기능은 이더리움 커뮤니티에서 논의되었을 가능성이 큽니다. 다른 메인넷을 이해하기 앞서 근본이 되는 이더리움을 이해하는 것이 중요하고, 그 과정에서 사전에 논의된 EIP들을 통해 이더리움에 대한 이해도를 높일 수 있습니다.

현재 포스팅은 EIP에서 첫 번째로 작성된 EIP-1 : 작성 가이드와 지침 에 적힌 내용입니다. 더 많은 내용은 아래 사이트에서 확인 가능합니다.

Home | Ethereum Improvement Proposals
Ethereum Improvement Proposals (EIPs) describe standards for the Ethereum platform, including core protocol specifications, client APIs, and contract standards.
Ethereum Improvement ProposalsEthereum Improvement Proposals

EIP의 종류

EIP는 크게 3가지 종류가 있습니다.

  • Standard EIP
  • Meta EIP
  • Information EIP

Standard EIP

이더리움을 사용하는 어플리케이션 의 상호 운용성에 영향을 미치는 모든 변경 사항을 의미합니다. 일반적으로 구현과 관련된 모든 것이 해당 섹션에 해당합니다. 내부에서는 다음과 같이 나눠집니다.

  • Core : 합의 포크가 필요한 사항 또는 핵심 개발과 관련된 내용
  • Networking : devp2p 또는 라이트 이더리움 서브프로토콜 등의 네트워크 프로토콜 개선
  • Interface : API/RPC 등에서 이름 변경 등을 다룹니다. 예시로 EIP-6는 기존 opcode(기본연산) 중 SUICIDE 를 SELFDESTRUCT 로 개선하는 EIP였습니다. 이런 인터페이스 관련 EIP는 사전에 EIP를 합의하는 과정에서 충분한 논의가 이뤄졌어야 합니다.
  • ERC : Ethereum Request Comments의 약어입니다. 개발자가 새로운 기능을 구현하기 위해 따라야 하는 일련의 규칙 및 권장 사항을 설명합니다. 일반적으로 가장 많이 논의되는 EIP입니다. ERC-20 토큰 표준, ERC-721 NFT 등이 대표적입니다.

Information EIP

이더리움 설계 문제를 설명하거나 새로운 정보를 제공하지만 새로운 기능을 제안하지는 않습니다. 강제성이 있는 것은 아니므로 참고하면 좋을 정보 정도로 여길 수 있습니다.

Meta EIP

이더리움과 관련된 프로세스를 설명하거나, 관련 프로세스의 변경을 제안합니다. 코드를 제안하기보다는 전체 프로세스를 제안합니다. 그래서 Process EIP라고 불리기도 합니다. Information EIP와 유사하지만 Meta EIP는 강제성을 지닙니다.

EIP 절차

이더리움은 다음과 같은 절차를 거칩니다.

EIP Process Diagram
  • 아이디어(Idea) : 초안 이전의 상태입니다. EIP 레포에서 추적하지 않는 상태입니다. Ethereum Research나 Ethereum Magicians에서 논의가 이뤄집니다.
  • 초안(Draft) : EIP의 형식이 갖춰지면, 해당 시점에 레포지토리에 올라가며 추적을 시작합니다. 형식은 아래를 참고해주세요.
  • 검토(Review) : 작성자가 피어 리뷰(동료 평가)를 받을 수 있게 상태를 변경합니다.
  • 최종 확인(Last Call) : 최종 확정 이전의 마지막 검토입니다. EIP 에디터를 통해 결정되며, 최종 데드라인이 정해집니다. 일반적으로 14일 이후가 됩니다.
  • 최종(Final) : 최종 확정 상태를 의미합니다. 최종으로 등록된 내용은 정오표와 비규범적 내용에 대해서만 수정할 수 있습니다.
  • 정체(Stagnant) : 6개월 이상의 초안, 검토, 최종 확인 상태에서 변경 사항이 없는 경우, 정체 상태로 변경합니다. 이후 다시 작성을 재개하면 상태가 변경됩니다.
  • 철회(Withdrawn) : 작성자가 제안한 EIP를 철회한 상태입니다. 철회된 내용은 다시 복구할 수 없으며 새롭게 EIP를 초안부터 시작해야 합니다.
  • 지속(Living) : 지속적으로 업데이트 되는 특별한 상태입니다. 대표적으로는 해당 EIP-1(EIP 작성 가이드라인)이 포함됩니다. (정확히는 EIP-1만 Living 상태입니다.)

EIP 형식

각 EIP에는 다음과 같은 항목이 포함되어야 합니다. 해당 내용에 대한 템플릿은 다음 페이지에서 확인 가능합니다.

  • 서문(Preamble) : 메타 데이터를 담는 포맷으로 아래에 예시가 있습니다.
  • 초록(Abstract) : 요지를 담은 짧은 기술 요약입니다.
  • 동기(Motivation) : 결국 EIP는 새로운 제안이며, 커뮤니티의 합의를 얻어야 하기 때문에 가장 중요한 부분입니다. 기존 프로토콜이 해결할 수 없는 문제에 대해서 제안하는 것이 중요합니다.
  • 사양(Specification) : 새로운 기능과 이에 대한 문법 등을 서술하는 기술적 내용입니다. 기존 이더리움 플랫폼(cpp, go, parity, js)에 대해 상호운용이 가능하도록 상세하게 작성해야 합니다.
  • 근거(Rationale) : 동기와 해당 구현이 연결되는 부분입니다. 해당 코드 디자인에 대한 설명을 해주는 것이 중요합니다.
  • 이전 버전과 호환성(Backwards Compatibility) : 이전 코드와 비호환되는 부분이 있다면 이에 대한 문제점과 해결책에 대해 충분히 논의되어야 합니다.
  • 테스트 케이스(Test Cases) : 사례입니다.
  • 구현 사례(Reference Implementation) : 선택적으로 사람들이 해당 사양 및 구현을 이해하는 데 도움이 될 참조 및 예제를 추가할 수 있습니다.
  • 보안 고려(Security Consideration) : 보안 관련 설계, 우려 사항, 위험성 등에 대한 논의가 필수적입니다. 해당 내용이 없을 경우 제출은 거부됩니다.
  • 저작권 포기(Copyright Waiver) : 모든 EIP는 공개적이어야 합니다. 저작권 포기는 라이선스 파일에 연결되어야 하고 다음 문구를 함께 작성해야 합니다. Copyright and related rights waived via [CC0](/LICENSE).

서문 포맷

각 EIP에는 다음과 같은 RPC 822 스타일의 헤더가 포함됩니다. Jekyll 블로그를 작성하신 분들을 블로그 글에 옵션 처럼 쓰는 것을 아실 예정입니다. 특정 글에 대한 메타 데이터 작성 가이드입니다.

---
eip: <to be assigned>
title: <The EIP title is a few words, not a complete sentence>
description: <Description is one full (short) sentence>
author: <a comma separated list of the author's or authors' name + GitHub username (in parenthesis), or name and email (in angle brackets).  Example, FirstName LastName (@GitHubUsername), FirstName LastName <foo@bar.com>, FirstName (@GitHubUsername) and GitHubUsername (@GitHubUsername)>
discussions-to: <URL>
status: Draft
type: <Standards Track, Meta, or Informational>
category (*only required for Standards Track): <Core, Networking, Interface, or ERC>
created: <date created on, in ISO 8601 (yyyy-mm-dd) format>
requires (*optional): <EIP number(s)>
---

제목, 내용, 번호, 날짜, 저자 등을 포함해 현재 진행 상태, EIP 종류 등에 대한 정보가 들어갑니다.

이런 메타데이터 덕분에 사이트에서는 각 EIP 종류 별 개수, 상태 별 개수 등에 대한 정보를 쉽게 확인할 수 있습니다.

EIP 에디터

EIP를 관리하는 사람들을 에디터라고 합니다. EIP 에디터의 역할은 다음과 같습니다.

  • EIP가 준비되었는지 점검합니다. 최종 상태까지 도달하지 못할 것 같더라도 기술적으로 가능해야 합니다.
  • 제목이 내용을 정확하게 설명해야 합니다.
  • 언어(철자, 문법, 비문), 마크업(마크다운), 코드 스타일 등 앞서 언급한 EIP 형식을 점검합니다.

해당 점검에 통과하지 못하는 경우 작성자에게 수정 지침을 전달하고, 준비된 EIP는 다음과 같은 과정을 거칩니다.

  • EIP 번호 할당(통상적으로 PR 번호)
  • PR 머지 진행
  • EIP 저자에게 연락

EIP 번호 할당이 에디터의 역량이긴 하나 일반적으로는 이더리움 깃헙 레포의 PR 번호를 따릅니다.

ERC-20 표준 토큰, ERC-721 NFT 등 왼쪽 아래의 숫자가 PR 번호입니다.

에디터 목록

현재 EIP 편집자는 다음과 같습니다.

  • Alex Beregszaszi (@axic)
  • Matt Garnett (@lightclient)
  • Micah Zoltu (@MicahZoltu)
  • Greg Colvin (@gcolvin)
  • Sam Wilson (@SamWilsn)

명예 EIP 편집자는 다음과 같습니다.

  • Casey Detrio (@cdetrio)
  • Nick Johnson (@arachnid)
  • ⭐Vitalik Buterin (@vbuterin)
  • Hudson Jameson (@Souptacular)
  • Nick Savers (@nicksavers)
  • Martin Becze (@wanderer)

ETC

  • 외부 리소스에 대한 링크는 포함되면 안됩니다. 참조 리소스는 다른 EIP만 사용할 수 있습니다. 보조 이미지 등은 assets/eip-N 디렉토리에 포함되어 PR을 보내야 합니다.
  • 에디터가 EIP를 판단하는 것은 아니고, EIP 등 개발 관련 내용은 주기적으로 회의를 통해 결정됩니다.
  • EIP를 나타낼 때는 EIP-XXX 형식으로 작성해야 합니다.
  • 문서 내부에서 사용하는 "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", "OPTIONAL" 키워드는 RFC 2119에 설명된 대로 해석됩니다.
  • EIP는 비트코인 제안 BIP와 파이썬 제안 PEP에서 파생되었습니다.
  • EIP 포맷 등에 대한 체크는 봇이 하며 auto merge합니다.

Reference

Sign up for more like this.

Enter your email
Subscribe