이더리움 개선 제안 및 업그레이드 프로세스 개선 제안

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

, 저자: Tim Beiko, 번역 및 교정: Peter Chen & A Jian, 승인을 받아 Odaily에서 재인쇄함.

요약

이 게시물은 Danno Ferrin과 제가 DevconV(제6회 이더리움 개발자 컨퍼런스)에서 나눈 대화의 대략적인 기록입니다. 이 기사는 지난 해 커뮤니티에서 제안한 몇 가지 EIP 프로세스 개선 제안에 대해 논의하고 이를 통합 프레임워크에 통합하여 이더리움을 보다 원활하게 업그레이드하는 방법을 안내합니다. 우리는 그것을 "기차역 모델"이라고 부릅니다.

• 보조 제목

• 요약

• 지난 1년 동안 커뮤니티의 여러 제안을 기반으로 우리는 이더리움 네트워크에서 업그레이드를 조정하는 새로운 방법을 제안합니다. 특히 우리는 다음과 같이 믿습니다.

• 업그레이드는 커뮤니티에 명확한 예측 가능성을 제공하기 위해 1년에 두 번 수행되어야 합니다.

업그레이드에는 출시 준비가 된 이더리움 개선 제안(EIP)만 포함되어야 하며, 아직 논의 중인 모든 개선 사항은 다음 업그레이드에 포함되어야 하며 현재 업그레이드를 지연시키지 않아야 합니다.

이더리움 개선 제안은 작업 그룹에서 독립적인 방식으로 개발해야 하며 완료 시 업그레이드에 포함하는 것으로만 고려해야 합니다.

Ethereum 개선 제안 및 작업 그룹에는 커뮤니티에 연락하고 관련 EIP에 대한 커뮤니티의 질문에 답변할 챔피언 또는 대표가 있어야 합니다.

이더리움의 업그레이드 이력에 대해 간단히 말씀드리겠습니다. Frontiers, Homeland, Byzantium, Constantinople을 포함한 처음 몇 번의 네트워크 업그레이드는 1950년대의 가족 휴가와 비슷했습니다. 엄마 아빠가 차의 포장을 풀고 우리는 뒷좌석에 올라타 우리가 가장 좋아하는 장난감을 가지고 갔습니다. 그들은 우리를 목적지까지 안전하게 데려다 줄 것입니다.

이것은 과거의 업그레이드에 대한 간단한 비유이지만 이러한 업그레이드의 경우 핵심 개발자가 대부분의 이더리움 개선 제안을 작성했으며 이더리움 커뮤니티는 조직적이고 계획적인 방식으로 커뮤니티와 소통할 수 있을 정도로 작았습니다. 포크와 업그레이드가 순조롭게 진행되었습니다.

.... 하지만 너무 바쁠 때가 있습니다! 우리가 불을 진압하기 위해 서둘러야 했던 몇몇 경우에. 그런 경우에 우리는 기본적으로 모두 군인입니다. 상하이 Devcon 2 동안의 사이버 공격이든, The DAO로 인한 이더리움 포크이든, 콘스탄티노플 업그레이드 전 마지막 순간에 발견된 약점이든, 커뮤니티는 항상 함께 모여 버그를 수정하고 문제를 해결하며 사용자가 적시에 노드를 업그레이드할 수 있도록 합니다. .

이미지 설명

-이더리움 색의 폭포-

지금까지 이스탄불 업그레이드. 업그레이드 계획을 시작했을 때 워크플로를 잘 파악하고 업그레이드 프로세스를 보다 철저하게 계획하기로 결정했습니다. 업그레이드 프로세스의 각 단계에 대한 시간 노드를 설정하고 이더리움 개선 제안부터 최종 메인넷 업그레이드까지 세부 계획을 세웠습니다. 어느새 우리는 일종의 이더리움 폭포 모델에 있었습니다!

그러나 이러한 계획된 시간 노드 중 얼마나 많은 시간이 실제로 정시에 완료됩니까? 단 한 가지가 있으며 그것이 시작 부분에 있습니다.

실행하는 동안 많은 일이 잘못되었습니다. 더 중요한 이유 중 하나는 이더리움 커뮤니티가 마지막 업그레이드 이후 많이 성장했고 이스탄불 업그레이드 제안을 검토할 시간이 되었을 때 핵심 개발자가 30개 이상의 이더리움 개선 제안을 함께 패키징해야 했다는 것입니다. 의견을 제시할 소수의 제안!

이미지 설명

이더리움 이스탄불에 대한 최종 개선 제안 목록을 받았을 때는 이미 한여름이었고, 당초 계획대로라면 이때까지 클라이언트 구현을 완료해야 했습니다. 이 일이 발생했을 때 많은 사람들이 개발 프로세스가 예상보다 훨씬 뒤쳐져 있다는 것을 깨달았고 이스탄불 이후 베를린 업그레이드를 보다 원활하게 실행할 수 있는 방법에 대해 많은 제안이 있었습니다. 이제 이러한 제안 중 일부를 논의한 다음 "철도역 모델"이라고 부르는 것에 통합할 것입니다.

이미지 설명

보조 제목

Ethereum 1.X는 EIP 개발 프로세스를 변경하려고 시도합니다.

이스탄불 업그레이드 중에 개발 프로세스 문제를 해결하기 위해 가장 먼저 시도한 사람은 Alexey Akhunov였습니다. 그는 ReTestEth를 사용하여 작업 그룹을 구성하여 이더리움 프로토콜 개선에 기여하는 구성원 수를 늘리는 동시에 기존 핵심 개발자의 부담 부담. "pre-1.x" 개선 프로세스에서 제출된 이더리움 개선 제안은 주로 Geth, Parity 및 Aleth의 클라이언트 개발자가 구현하며, 이 경우 이더리움 개선 제안은 이들 팀이 공동으로 개선합니다. 고객이 Ethereum 개선 제안의 최종 사양에 동의하면 참조 테스트를 생성할 수 있습니다. Aleth는 테스트를 생성할 수 있는 유일한 클라이언트이므로 이러한 테스트를 생성하려면 모든 Ethereum 개선 제안을 Aleth에서 구현해야 합니다. 그런 다음 EF의 테스트 팀은 이러한 테스트를 실행하고 모든 클라이언트가 실행할 적합성 테스트를 작성합니다.

-슬라이드쇼의 사진은 Alexey의 원본 게시물에서 가져왔습니다-

이 프로세스에는 주요 클라이언트 구현 팀, 참조 테스트를 생성하는 Aleth, EF의 테스트 팀이 작성한 적합성 테스트 등 몇 가지 병목 현상이 있습니다. 작업 효율을 높이기 위해 Alexey는 워킹 그룹을 구성하는 아이디어를 제안했습니다. 이 작업 그룹은 이더리움을 개선하려는 욕구를 공유하는 사람들의 하위 집합으로 구성됩니다. 그들은 이더리움 개선 제안의 초기 단계부터 시작하여 최종 버전에 어느 정도 근접하거나 도달할 수 있도록 개선하는 데 도움을 줄 수 있습니다. 이런 식으로 클라이언트 개발자는 성숙한 이더리움 개선 제안, 적어도 초기 구현 및 이미 답변된 대부분의 관련 공개 질문을 볼 수 있습니다.

이 외에도 EF 테스트 팀이 개발한 새로운 테스트 도구인 retesth를 통해 작업 그룹은 모든 클라이언트(현재 Geth, Aleth 및 Hyperledger Besu)에 필요한 EIP 참조 테스트를 생성할 수 있습니다. 따라서 이 작업 그룹 프레임워크는 이더리움 개선 제안의 개선 프로세스를 분산화할 뿐만 아니라 테스트 병목 현상과 압력을 줄일 것입니다.

eEIP 지지자

이스탄불 업그레이드를 준비하는 동안 모든 핵심 개발자가 특정 이더리움 개선 제안에 대해 아무도 이야기하지 않는 전화 회의를 갖는 것은 드문 일이 아닙니다.상호 의존성 또는 경쟁 제안은 전체 업그레이드 프로세스의 진행을 크게 늦출 수 있습니다.

이미지 설명

-이러한 문제를 논의하기 위한 워크숍을 조직하는 데 도움을 준 MP와 Boris에게 감사합니다-

챔피언의 역할은 그들을 EIP의 접점으로 만드는 것입니다. 그들은 EIP의 토론 조정자 역할을 하여 업그레이드 프로세스가 원활하게 진행되고 적절한 사람들이 합리적인 토론에 참여하도록 합니다. 그들은 모든 작업에 대한 책임이 없고 반드시 직접 구현할 필요는 없지만 Ethereum 개선 제안 구현의 핵심 인물이 되어야 하며 커뮤니티 내의 구성원과 업그레이드 프로세스를 완전히 소통하는 데 전념해야 합니다.

보조 제목

EIP 중심 포크

최근 EF 팀의 Martin Holst Swende가 제안한 또 다른 아이디어는 이더리움 네트워크 업그레이드 프로세스를 EIP 중심으로 조정하는 것입니다. 업그레이드에 집중하고 모든 이더리움 개선 제안이 업그레이드의 각 단계에서 잠금 단계에 있는지 확인하는 대신 각 EIP를 성숙하게 만드는 데 집중하고 성숙하고 릴리스 가능한 EIP에 대한 업그레이드만 계획하는 것이 좋습니다.

누구나 이더리움 개선 제안을 초안 단계에서 성공적인 메인넷 활성화로 가져가려는 경우, 이 프레임워크 내에서 수행하는 방법은 다음과 같습니다(원래 제안에서 인용, 가독성을 위해 약간의 편집 포함).

1단계: ACD로부터 확인 받기

이더리움 개선 제안이 존재한다고 가정하면(단계 0), ALCORIEDEV(포럼)는 처음에 이더리움 개선 제안이 "예비 수락"되는지 여부를 결정합니다. "예비 수락"(또는 "긍정적")은 주요 고객 및 생태계 이해 관계자가 Ethereum 개선 제안에 대해 긍정적인 태도를 갖고 EIP를 코드 기반에 통합하고 테스트를 시작하기 위해 (잘 작성된) PR을 수락할 의향이 있음을 의미합니다. 그러나 이 단계는 활성화의 실제 블록 높이를 지정하지 않습니다.

이 "예비 승인" 상태는 EF, ConsenSys 또는 심지어 MolochDAO와 같은 프로토콜 업그레이드에 자금을 지원하는 조직에 유용한 신호 메커니즘이기도 합니다. 자금의 대부분이 메인넷 출시를 촉진하는 이니셔티브에 사용되도록 자금 조달을 여러 단계(즉, "초기 승인" 전 및 후)로 나눌 수 있습니다.

2단계: 실행

ACD가 명확한 방향을 제시하면 개발자 및 기타 이더리움 개선 제안 작성자는 이를 구현하고 클라이언트를 위한 업데이트를 릴리스할 수 있습니다.

구현된 기능이 기본 클라이언트에 병합되면 이 마일스톤이 완료됩니다.

3단계: 테스트 케이스

이 기능은 이제 클라이언트에서 "활성화"될 수 있으므로 이제 이 기능에 대한 클라이언트 간 테스트를 생성할 수 있습니다. 테스트 사례에는 해피 경로 테스트 및 쿼크/엣지 케이스 테스트가 포함되어야 합니다. EVM(Ethereum Virtual Machine)을 이해하고 이해하는 심층적인 사람들이 함께 실행하여 오류 가능성을 최소화합니다.

이 단계에서 보안성 검토도 진행되어야 하며, 검토 프로젝트는 "보안 고려사항"이라는 이름으로 이더리움 개선 제안으로 피드백되어야 합니다. 쉽게 간과. 이 단계의 완료는 테스트 팀의 승인으로 표시됩니다.

4단계: ACD 최종 승인

"그래서 한 달 후 테스트넷에서 이 이더리움 개선 제안(블록 높이 X)을 활성화하고 두 달 후에 메인넷(블록 높이 Y)에서 이 이더리움 개선 제안을 활성화합시다." 모든 클라이언트는 다음 릴리스에 업그레이드를 포함할 것입니다. , 명령줄 플래그를 통해 이더리움 개선 제안을 지금부터 일주일 동안 연기하는 것도 실용적입니다.

여러 이더리움 개선 제안이 동시에 4단계에 도달하면 ACD는 이더리움 개선 제안이 내부 종속성/커플링을 가질 수 있다는 우려가 없는 한 동시에 2개 또는 3개의 이더리움 개선 제안을 시작하기로 결정할 수 있습니다. 불필요한 테스트 간섭).

이미지 설명

-명확한 그림을 그려주신 James Hancock에게 감사드립니다! -

이 프레임워크를 사용하면 각 이더리움 개선 제안이 자체 속도로 진행될 수 있으므로 업그레이드 프로세스 동안 토론의 시간과 범위를 줄이는 동시에 프로세스가 이전보다 더 예측 가능하기 때문에 테스트 팀에 대한 압력을 줄일 수 있습니다. 마감일 전에 테스트에 집중하기 위해 허둥지둥할 필요가 없습니다.

보조 제목

• 이더리움 개선 제안 1872

• Ethereum 네트워크의 업그레이드 프로세스를 원활하게 하기 위한 또 다른 제안은 Danno Ferrin이 제안한 Proposition 1872입니다. 더 많은 회사가 이더리움을 인프라의 핵심 부분으로 사용함에 따라 우리는 네트워크 업그레이드를 보다 예측 가능하게 만들기 위해 노력해야 합니다.

• 이 제안은 이더리움이 마이크로소프트의 화요일 정기 패치 릴리스와 유사하게 네트워크 업그레이드를 위한 기본 일정을 채택할 것을 제안합니다. 그렇게 하면 이더리움 노드를 운영하는 사람들은 잠재적인 업그레이드를 모니터링할 가능성이 높은 시기를 알 수 있습니다. 요컨대, 이 제안은 다음과 같이 제안합니다.

• 대부분의 주요 미국 및 유럽 공휴일을 피하기 위해 기본적으로 매월 세 번째 수요일, 바람직하게는 1월, 4월, 7월 또는 10월에 메인넷 업그레이드가 이루어지도록 합니다.

업그레이드가 예정대로 롤아웃되지 않으면 다음 달 세 번째 수요일까지 연기됩니다(콘스탄티노플 업그레이드 중에 일어난 일).

언제 어디서나 문제가 발생하면 즉시 해결

이 EIP는 예상치 못한 상황에 대처하는 우리의 능력을 제한하지 않고 6개월마다 고정 업그레이드와 같은 기본 주기성을 강조하여 업그레이드 불확실성에 대한 시장의 우려를 줄이고 동시에 핵심 개발자를 줄입니다. 프로세스.

또한 현재 접근 방식과 "하나의 이더리움 개선 제안, 하나의 업그레이드" 접근 방식(예: EIP 중심 포크 접근 방식) 사이의 "중간 지점"을 제공합니다.

보조 제목

기차역 모델

위 권장 사항의 일부를 결합하여 현재의 "공항 운영 방식에 더 가까운" 프로세스보다 기차역 운영 방식에 더 가까운 프로세스에 도달했습니다.

현재 업그레이드는 비행기 티켓 구매 방식과 유사합니다. 날짜와 시간이 고정되어 있고, 지연이 발생하더라도 수하물을 확인하여 모든 사람이 비행기에 탑승하도록 노력합니다.

우리는 사람들이 손에 짐을 들고 기차역에 나타나서 갈 준비를 하고 다음 이용 가능한 기차를 타고 떠나는 모델로 이동하면 네트워크 업그레이드가 현재보다 훨씬 원활해질 것이라고 믿습니다.

구체적으로 기차역 모형은 크게 네 부분으로 나뉜다.

첫째, 각각의 이더리움 개선 제안은 독립적으로 진행되어야 합니다. 작업 그룹은 제안을 추진할 수 있으며 Ethereum 개선 제안이 준비 상태에 있는 경우에만 네트워크 업그레이드 일정을 잡습니다.

둘째, Ethereum 개선 제안 및 작업 그룹에는 챔피언이 필요합니다. 이 챔피언은 이더리움 개선 제안에 대한 대표 및 기본 연락 창구 역할을 해야 합니다. 그들은 AllCoreDevs 또는 기타 포럼에서 커뮤니티에 제안을 전달할 책임이 있으며 EIP의 실제 구현자일 수도 있고 아닐 수도 있습니다.

셋째, 수행한 작업을 게시합니다. 네트워크를 업그레이드할 때 릴리스할 준비가 된 모든 EIP를 업그레이드에 넣습니다. 아직 논의 중인 제안에 대해서는 단계적 확대가 예정되어 있지 않습니다. 마찬가지로 제안서에 마지막 순간에 문제가 있는 경우 전체 업그레이드를 연기하는 대신 다음 업그레이드로 옮깁니다.