Ethereum 핵심 개발자 회의 노트: 상하이 업그레이드에 대한 최신 업데이트
원래 제목: "원래 제목: "》
#152 이더리움 코어 개발자 회의 노트
원편집자: Stephanie, ECN
편집된 단어
ECN이 매주 업데이트하는 "이더리움 7일 토크"를 본 친구들은 "7일 토크"가 거의 한 달 동안 중단되었음을 알 수 있습니다. ECN은 얼마 전 에디터의 코로나19 감염으로 업데이트 소식을 전해드리지 못하는 점에 더해 '세븐데이토크' 편집을 계속할지 고민하고 있다. ECN은 새해에는 '세븐데이 토크' 등 일부 콘텐츠 운영 조정을 할 예정이다.
이더리움 핵심 개발자 회의의 노트 편집은 항상 "세븐 데이 토크"의 중요한 부분이었으며 이제 우리는 이를 독립적으로 업데이트하기로 결정했습니다.
이전 "7일 회담"의 콘텐츠를 계속 업데이트하기를 원하시면 다양한 소셜 미디어를 통해 비공개 메시지를 보내주세요. 콘텐츠의 품질을 향상시키기 위해 귀하의 피드백을 기꺼이 듣고 있습니다.
다음은 자세한 참고 사항입니다 👇
첫 번째 레벨 제목
상하이 업그레이드 진행
(https://t.co/HBkcidHvMq)
첫 번째 레벨 제목
상하이에서 EOF 관련 EIP 제거 및 업그레이드
상하이에서 EOF 관련 EIP 제거 및 업그레이드
다음으로 회의에서는 주로 EOF 관련 주제를 논의했습니다.
Geth 팀의 개발자 @lightclients가 12월 EOF 그룹 회의에 대한 업데이트를 제공했습니다. (EOF는 EVM Object Format으로 이더리움의 코드 환경에 약간의 변화를 가져올 것입니다. 이와 관련된 EIP는 스마트 계약의 코드와 데이터를 보다 명확하게 구분하고 향후 EVM을 업그레이드하기 쉽게 만듭니다.) , 이 사양은 JUMPF를 제거하고 데이터 섹션을 포함하도록 데이터 EOF 계약을 필수로 만드는 두 가지 사소한 변경으로 마무리되었습니다.
테스트 측면에서 Geth 팀의 @mhswende는 구현 퍼징을 시작하고 버그를 찾아 모든 클라이언트에서 수정했습니다. 현재 퍼지 테스트는 주로 클라이언트에서 EOF 컨테이너/구조의 구현을 목표로 하지만 배포된 EOF 코드는 포함하지 않습니다. 이더리움 재단 테스트 팀의 Mario Vega@elbuenmayini는 EOF의 복잡성으로 인해 오류 사례에 대한 정적 테스트 사례를 작성하기 어려울 수 있다고 덧붙였습니다. 구현 시 정확한 테스트 사례를 만나기 전에 다른 오류가 발생할 수 있기 때문입니다.
클라이언트 측에서 Geth와 Besu는 완전한 구현을 가지고 있으며 대부분의 테스트를 통과했습니다. Nethermind에도 구현이 있지만 어떤 테스트 스위트를 사용하는 것이 가장 좋은지 확실하지 않습니다. 그리고 Erigon은 Geth의 EOF 구현을 사용할 것입니다.
EOF의 구현 및 테스트를 기반으로 Vitalik은 EOF의 성급한 구현에 대한 우려도 표명하고 EOF 제안을 게시했습니다. -eof-계정의 코드 검사/12113
Vitalik은 회의에서 이 제안의 이면에 있는 생각을 설명하고 EVM을 수정하는 것이 일반적으로 다른 프로토콜 수정보다 더 어려운 이유를 설명했습니다. 그는 이더리움에서 작업 증명을 제거하는 것이 opcode를 폐기하는 것보다 쉽다고 언급했습니다. 이는 이더리움 애플리케이션/계약이 EVM의 특정 동작에 의존하기 때문에 수정 사항은 이전 버전과 호환되어야 합니다. 그렇지 않으면 배포된 계약이 중단됩니다. 프로토콜의 다른 측면을 변경하면 모든 사람이 특정 시간에 업데이트하기만 하면 되며 그렇지 않으면 네트워크의 어떤 것도 손상시키지 않습니다.
즉, EVM을 개선하거나 EOF와 같은 새 버전을 도입할 때 이전 버전을 폐기할 수 없기 때문에 영원히 함께 살아야 할 가능성이 높습니다. 이상적으로 우리는 EVM이 더 깨끗하고 단순하기를 원하지만, 우리가 그것에 무언가를 추가할 수만 있고 제거할 수 없다면 그것은 어려울 것입니다. 삭제의 가장 큰 과제 중 하나는 EVM의 코드 검사입니다.
따라서 Vitalik의 제안은 EOF v1에 더 많은 콘텐츠를 추가하여 EOF 계약에서 코드 검사를 크게 제한하여 잠재적으로 향후 업그레이드를 더 쉽게 만드는 것입니다. Ipsilon 팀의 @alexberegszaszi는 EOF 제안 작성자가 실제로 이전에 유사한 기능을 고려했으며 EOF v1을 단순하게 유지하기를 원했기 때문에 포기하기로 결정했다고 언급했습니다. 그는 또한 Vitalik의 제안을 EOF v2에 통합하기 위한 대안을 제안합니다: https://ethereum-magicians.org/t/eof v2-aka-what-evm-2-0-could-look-like/12442
그러나 EOF v1에 콘텐츠를 추가하자는 이 제안으로 클라이언트 팀은 전체 개정이 너무 클 것이라고 우려했습니다. @lightclients는 또한 EOF 테스트의 현재 진행 상황에 따라 상하이 업그레이드에 포함하는 데 약 한 달 정도 지연될 수 있다고 말했습니다. 2월 초에 메인넷 테스트넷 업그레이드를 시작하려면 EOF 부분이 준비되어 있지 않아야 합니다. 또한 EVM에 대한 변경 사항은 일단 배포되면 수정할 수 없기 때문에 이것은 중요한 결정입니다.
상하이 업그레이드는 다른 EIP를 보완해야 합니까? 논의 후 개발자들은 상하이 업그레이드를 지연시키지 않기 위해 다른 EIP를 추가하지 않기로 결정했습니다.
첫 번째 레벨 제목
다른 EIP에 대한 논의
그 후 개발자들은 Nimbus 팀의 Etan Kissling의 제안에 대해서도 논의했습니다. ExecutionPayloadHeader의 트랜잭션 목록에 16진수 루트를 추가하는 것입니다. https://github.com/ethereum/consensus-specs/pull/3078
간단히 말해서 실행 계층의 블록 헤더와 합의 계층의 실행 페이로드 헤더(ExecutionPayloadHeader) 사이에 서로 다른 직렬화 형식으로 인코딩된 필드가 사용됩니다. 이 두 필드의 서로 다른 인코딩 형식은 지갑 및 이더리움 라이트 클라이언트 구성에 추가적인 오버헤드와 복잡성을 가져옵니다. Kissling은 다양한 방식으로 Execution Layer의 RLP 직렬화 형식을 지원하기 위해 CL의 SSZ 직렬화 형식을 실행 계층 또는 합의 계층 클라이언트에 추가할 것을 제안합니다. 이번 제안은 상하이 업그레이드 철수와 관련돼 있어 비교적 시급하다. 이 문제는 이번 주 1월 12일 ACDC(Consensus Layer Conference)에서 다시 논의될 예정입니다.
다음과 같이 소스 컴파일@TimBeiko그리고@christine_dkim그리고
