EIP 프로세스 개선 아이디어: RFC 및 W3C 프로세스에서 차용

편집자 주: 이 기사의 출처는이더리움 애호가(ID: ethfans)편집자 주: 이 기사의 출처는

이더리움 애호가(ID: ethfans)

이더리움 애호가(ID: ethfans)

, 저자: Alex Beregszaszi, 번역 및 교정: Min Min & A Jian, Odaily의 승인을 받아 재인쇄됨.

한 문장 요약: 먼저 2019년 EIP 프로세스 및 조정에 대한 일반적인 소개를 하겠습니다. 그런 다음 RFC 및 W3C 프로세스에서 크게 영감을 받은 새로운 EIP 프로세스를 제안합니다.

• 2016년부터 EIP(Ethereum Improvement Proposals)에 참여했습니다. 기고자로 시작하여 나중에 "AllCoreDev 프로세스"에 참여하고 편집 작업을 맡았습니다.

• 현재 프로세스

현재 EIP 라이브러리에는 두 가지 별개의 프로세스가 있습니다.

사양

• 전체 네트워크 구현(하드포크 계획)

• EIP-1 ​​및 EIP 233은 두 프로세스의 일부를 정의합니다. 나중에 EIP-2378은 이를 기반으로 확장되었습니다.

• 2019년에 몇 가지 변경 사항이 제안되었으며, 그 중 4개는 제안 상태와 관련이 있습니다.

• "검토" 상태 소개

"수락됨"을 "준비됨"으로 이름 바꾸기

"포기" 상태 소개

"연기" 상태 제거

처음 두 변경 사항을 도입한 동기는 비슷하지만 약간 다릅니다. "검토" 상태는 광범위한 검토가 가능한 명확한 제안이 있지만 제안이 긴급하게 구현되지 않는 새로운 단계입니다. "Ready" 상태는 약간의 증분 변화일 뿐이며 톤은 "Accepted"보다 부드럽지만 EIP-1의 하드포크 프로세스는 여전히 유지됩니다.

많은 버려진 초안을 정리하기 위해 "Abandoned" 상태가 도입되었습니다. 분명히 이전에 사용되지 않은 "철회" 상태가 제거되었습니다.

EIP-233 및 EIP-2378의 변경 사항으로 인해 "지연" 상태는 더 이상 사용되지 않으며 제거되었습니다.

"수락됨" 및 "거부됨"과 같은 다른 하드 포크 상태를 제거하자는 제안도 있습니다.

아래 다이어그램에서 각 상태가 의미하는 바를 자세히 설명하지는 않습니다. 각 코너 케이스에 대해 EIP-1을 읽으십시오. 그러나 아래의 'Proposed Process'는 합리적인 설명을 제공합니다. "

2019년 6월에 우리는 EIP 프로세스의 복잡성에 대해 심도 있게 논의했습니다. 각 상태를 고려하면 전체 EIP 흐름("지연" 상태가 제거되기 전)이 다음 다이어그램에 표시됩니다.

그 당시 나는 EIP가 문서에 쓰여 있지는 않았지만 "Last Call(마지막 시간 코멘트)" 상태에서 "Abandoned" 상태로 변경될 수 있다고 가정했습니다.

내가 언급하지 않은 것은 서로 다른 프로세스를 가진 두 개의 EIP가 있으며 위의 모든 조합이 유효한 것은 아니라는 것입니다.

"핵심" EIP의 흐름은 다음과 같습니다.

여기에서 "핵심" EIP는 최근까지 "마지막 호출" 상태를 도입하지 않았다는 점에 유의해야 합니다.

"비핵심" EIP 프로세스는 다음과 같습니다.

2020년 5월에 저는 더 간단한 프로세스를 제안했습니다.

우리는 이미 이 점을 논의했습니다. 그러나 EIP 프로세스를 거치는 많은 제안과 마찬가지로 이 제안도 진행되지 않았습니다.

하드포크

또한 "철회"와 "포기"의 두 상태를 병합해야 하는지 여부도 논란의 여지가 있습니다. 이것은 최근 문제에서 명확하게 설명되었습니다.

컨퍼런스콜에서는 '액티브' 대신 '리빙'이라는 단어를 사용할 것을 제안하기도 했다. 전자가 최선의 선택은 아닐 수 있지만 후자보다는 나은 것 같습니다.

하드포크

저는 하드 포크 관리와 표준 관리의 두 프로세스를 분리하는 것을 선호합니다. 이제 많은 사람들이 그렇게 생각하는 것 같습니다. 이렇게 하면 프로세스가 훨씬 쉽고 원활해집니다.

모든 핵심 개발자 회의의 새로운 소식에 따르면 이제 제안을 추적 및 관리하고 소위 "YOLO" 임시 테스트넷에서 테스트하는 전용 ETH 1.0 사양 저장소가 있는 것으로 보입니다.

마지막 남은 하드포크 과정을 EIP 라이브러리에서 제거하더라도 EIP-233의 원래 아이디어는 여전히 합리적이라고 생각합니다. 사양 변경을 기술하는 EIP 함께)

그러나 사람들은 EIP-233의 원래 아이디어에서 한 걸음 더 나아가 하드 포크의 이름을 명확히하기 위해 가능한 한 빨리 메타 문서를 만드는 규칙이되었습니다. 클라이언트마다 다른 이름을 사용하기 때문입니다. 그러나 이름 지정 메커니즘이 합의된 후에는 이 문제가 더 이상 문제가 되지 않습니다.

마지막으로 EIP-233의 아이디어가 다시 확장되어 계획 및 조정 프로세스에서 하드 포크를 추적하는 프로세스를 확장합니다. 다행스럽게도 앞으로 이것은 ETH 1.0 사양에 의해 처리될 것입니다.

하드 포크가 발생한 후 모든 데이터는 "하드 포크 메타"에 기록됩니다. 하드 포드 메타는 매우 유용한 자원임이 입증되었습니다.

내 제안 프로세스

거인의 어깨 위에 서기 위해 우리가 찾은 최고의 리소스는 RFC 프로세스와 W3C 프로세스입니다. 이 두 프로세스에 포함된 사양은 일반적으로 EIP보다 훨씬 크지만 여기서 배울 수 있다고 생각합니다.

여기서는 W3C 프로세스에서 개인적으로 좋아하는 용어를 차용했습니다. 그러나 위의 그림에는 기존 용어 또는 제안된 용어 모두 다른 옵션이 있습니다. 저는 개인적으로 "후보자"라는 용어를 선호합니다.

아이디어

제안서를 제출하기 전에 초안을 작성하는 풀 요청(풀 요청)을 제출하기 전에 신중한 단계가 있어야 합니다. Ethereum Magicians, ethressearch.ch 및 Gitter 또는 Discord의 채널에서 아이디어를 토론하고 비평할 수 있습니다.

초안

아이디어가 관심을 끈다고 가정하면 EIP 템플릿을 기반으로 초안을 작성해야 합니다. 이 초안이 기본 문법 요구 사항을 충족하는 한 병합해야 합니다.

질문: 편집자가 제안서를 검토해야 하는 정도에 대한 의견이 다양하며 명확한 답이 없습니다. 실패한 EIP를 제거하기 위한 좋은 프로세스가 있다면 초안을 더 일찍 병합하는 것이 확실히 옳은 일입니다.

이 단계에서 초안은 관심있는 참가자의 소규모 그룹에 의해 논의될 것으로 예상됩니다.

"초안" 상태에 대한 시간 제한은 없지만 합리적인 기간(몇 개월)을 초과하지 않는 것이 좋습니다.

후보(후보)/검토(검토)

이 단계는 초안이 더 이상의 주요 수정이 없을 정도로 충분히 안정되면 시작되어야 합니다.

이 단계에서 더 많은 참가자가 피드백을 제공합니다. 이 시점에서 참가자는 사양이 갑자기 크게 변경되지 않을 것이라고 믿을 만한 이유가 있으므로 이를 검토하고 논의하는 데 시간을 투자할 가능성이 더 큽니다.

이 단계는 피드백을 수집할 수 있도록 최소 45일 동안 지속되어야 합니다.

Proposed (제안) / Last Call (댓글 마지막 요청)

이 단계는 참가자가 사양이 충분히 안정적이어서 더 이상 변경하지 않을 것이라고 느끼면 시작해야 합니다.

이 단계에서 사양은 더 많은 참여자에게 전달되어 의견을 수렴할 것입니다. 그 이후에는 사양이 확정되며 변경할 수 없습니다. ["errata(칸)"를 제외하고, 자세한 내용은 아래 참조]

이 단계는 최소 14일 동안 지속되어야 합니다.

약간의 조정이 필요한 경우 현재 상태를 변경하지 않고 수행할 수 있습니다. 그렇지 않으면 "후보" 상태로 대체해야 합니다.

특별 요구 사항: 검토 종료일 필드는 서론에 포함되어야 합니다.

결정적인

"제안됨" 상태의 사양이 성공적으로 통과되면 완료됩니다.

• 빼는

• "Final"과 "Living"을 제외하고 다른 모든 상태가 이 상태가 될 수 있습니다.

특별 요구 사항: 다음 상황은 "철회" 상태로 이어질 수 있지만 이유 필드가 있어야 합니다.

저자 철회: 저자는 어느 단계에서든 철회 결정을 내렸습니다.

비활성으로 인해 철회됨: 저자가 특정 기간(180일) 동안 활동이 없었습니다.

생활/활동

이러한 EIP-1 ​​레지스트리 및 기타 특수 EIP는 완료되지 않기 때문에 이 상태로 표시됩니다.

모든 신규 등록 문서는 "생활" 상태가 되기 전에 전체 EIP 프로세스를 거쳐야 합니다.

보관됨

• 이것이 상태는 아니지만 이런 식으로 오랫동안 취소된 EIP를 제거하여 EIP 라이브러리를 채우지 않도록 할 수 있습니다. 자세한 내용을 보려면 여기를 클릭하십시오.

• 구식

이것은 상태가 아니라 RFC에서 차용한 단계적 제거 프로세스입니다. 이 프로세스는 두 개의 필드를 도입합니다.

obsoleted-by: 현재 EIP를 폐기하는 EIP 번호를 포함합니다.

obsoletes: 현재 EIP에 의해 폐기된 일련의 EIP 번호를 포함합니다.

현재 EIP는 Final 또는 Withdrawn 상태일 때만 obsoleted-by 필드를 사용할 수 있습니다.

현재 EIP는 참조된 EIP의 "obsoleted-by" 필드가 현재 EIP를 가리키는 경우에만 obsoletes 필드를 가질 수 있습니다.

이는 탈락 당사자인 EIP 작성자와 탈락 당사자가 합의에 도달해야 함을 의미합니다. 이것은 더 나은 제거 프로세스에 대한 제안에 따라 향후 변경될 수 있습니다.

Remark

정오표(errata)

• 사소한 인쇄상의 오류는 관례에 따라 편집자가 수정할 수 있습니다.

• 약간의 수정은 정오표 섹션에서 설명할 수 있으므로 원래 제안을 인식할 수 없을 정도로 변경하지 않는 한 사양을 명확히 하는 데 도움이 되는 모든 수정은 허용됩니다. 주요 수정이 필요한 경우 해당 EIP를 폐기하고 새 EIP를 생성해야 합니다.

• resolution

다음 frontmatter 필드는 지정 및/또는 사용되지 않았기 때문에 제거되었습니다.

교체(제거 프로세스로 교체)

• 대체됨(제거 프로세스로 대체됨)

• Rejected

• Accepted

• 다음 상태가 제거됩니다.

도구

포기("철회"로 명칭 변경)

대체됨(제거 프로세스로 대체됨)

도구

그러나 EIP가 직면한 가장 큰 문제는 인력의 필요성이다.