이 기사는 Ethereum Core Developers Conference의 최신 업데이트를 정리합니다.

ECN以太坊中国

特邀专栏作者

2023-01-04 12:00

이 기사는 약 6976자로, 전체를 읽는 데 약 10분이 소요됩니다

상하이 업그레이드, 철수 메커니즘, 칸쿤 업그레이드...

원본 소스: AllCoreDevs 업데이트

저자: 팀 베이코

원본 편집: Ethereum.cn

2022년 마지막 업데이트인 새로운 AllCoreDevs(Ethereum Core Developers Conference) 업데이트에 오신 것을 환영합니다.

이러한 업데이트는 월간 시리즈로 시작되었지만 주기는 점차 분기별 업데이트로 이동했습니다. 독자는 이러한 업데이트를 AllCoreDevs를 둘러싼 주요 이벤트의 요약으로 생각할 수 있습니다. 더 자세한 내용을 원하시면 Christine Kim의 녹취록, Ben Edginton의 컨센서스 레이어 회의 녹취록 및 더 자주 업데이트되는 저의 ACD 긴 트윗을 읽어보시기 바랍니다.

요약

상하이/카펠라 업그레이드 내용이 확정되었습니다: 출금, EOF 및 일부 사소한 수정... 출금을 지연시키지 않는 한

Blob 공간이 다가오고 있습니다: EIP-4844는 Ethereum의 다음 업그레이드의 중심이 될 것이며 소환 의식이 곧 시작될 것입니다.

기술적인 측면에서는 Execution Layer와 Consensus Layer의 업그레이드 프로세스를 조율하기 위한 노력이 진행 중입니다. 우리는 또한 커뮤니티 의견을 프로세스에 더 잘 통합하는 것에 대한 활발한 토론을 보고 있습니다.

첫 번째 레벨 제목

상하이/카펠라 업그레이드

최근 AllCoreDevs에서 클라이언트 팀은 Shanghai/Capella 업그레이드의 최종 범위에 대해 합의했습니다. 업그레이드의 이름은 논쟁의 여지가 있지만 팀은 그 범위에 대해 명확합니다. 업그레이드의 주요 기능은 스테이커를 위한 비콘 체인 인출을 도입하는 것입니다. 가능한 한 빨리 이 기능을 제공하는 것은 클라이언트 팀이 타협하고 싶지 않은 것이므로 업그레이드의 다른 기능은 동시에 준비되어야 합니다. 그렇지 않으면 삭제될 수 있습니다.

Shanghai Executive Specification에는 통합된 모든 EIP가 나열되어 있습니다.

EIP-3540: EVM 개체 형식(EOF) v1

EIP-3651: COINBASE 주소에 액세스하기 위한 가스 오버헤드를 줄입니다.

EIP-3670: EOF - 코드 유효성 검사

EIP-3855: 새로운 opcode PUSH 0

EIP-3860: 초기화 코드 크기 제한 및 가스 계량 도입

EIP-4200: EOF - 정적 상대 점프

EIP-4750: EOF - 가져오기 기능

EIP-4895: Beacon Chain 푸시 인출을 시스템 운영으로

EIP-5450: EOF - 스택 검증

보조 제목

사소한 개선

EIP-3651: Warm COINBASE(COINBASE 주소 액세스의 가스 오버헤드 감소)

이 EIP는 특정 데이터 필드 액세스에 대한 가스 비용 수정이 데이터가 이미 클라이언트 메모리에 있는지(WARM) 또는 디스크에서 검색해야 하는지(COLD) 여부에 따라 결정되는 EIP-2929의 감독을 수정합니다.

EIP-2929는 각 트랜잭션 시작 시 클라이언트 메모리에 있는 두 가지 데이터(발신 주소 및 수신 주소)를 WARM으로 설정합니다. EIP-3651은 이 목록에 세 번째 주소인 COINBASE 주소(즉, feeRecipient)를 추가합니다. 이는 블록 트랜잭션을 처리할 때 클라이언트가 메모리에 가지고 있는 주소이기도 하기 때문입니다.

EIP-3855: PUSH 0 명령어(opcode `PUSH 0 추가)

이름에서 알 수 있듯이 EIP-3855는 값 0을 스택에 푸시하는 opcode를 도입합니다. 0을 누르는 것은 종종 EVM의 값을 채우는 데 사용되며, 이 opcode는 이를 수행하는 더 효율적이고 저렴한 방법을 제공합니다.

EIP-3860: 제한 및 미터 초기화 코드(초기 코드 크기 제한 설정 및 가스 계량 도입)

이 EIP는 initcode의 크기에 한도를 추가하고 길이에 따라 가스 계량을 도입합니다. 크기 제한은 EVM에 불변성을 추가하여 변경 사항을 더 쉽게 이해하고 제안할 수 있도록 합니다.

보조 제목

개체 형식

상하이 업그레이드에 포함된 대부분의 EIP는 실제로 EVM 개체 형식(EOF)이라는 단일 기능의 일부입니다. 이 작업은 클라이언트 개발자가 각각의 개별 수정 사항을 이해하는 데 도움이 되도록 5개의 서로 다른 EIP로 분류되었지만 더 높은 수준의 개요를 제공하기 위해 개발자는 통합 사양을 게시했습니다. 다섯 가지 EOF의 EIP는 다음과 같습니다.

EIP-3540: EVM 개체 형식 버전 1

EIP-3670: EOF - 코드 유효성 검사

EIP-4200: EOF - 정적 상대 점프

EIP-4750: EOF - 가져오기 기능

EIP-5450: EOF - 스택 검증

EOF의 첫 번째 단계는 EOF 계약을 위해 0xEF 00 접두사를 예약한 런던 업그레이드 EIP-3541에서 발생했다는 점은 주목할 가치가 있습니다. 상하이 업그레이드의 EOF 범위도 지난 몇 달 동안 변경되었습니다.

2월에 고객 팀은 상하이에서 가장 작은 EOF EIP인 EIP 3540 및 3670을 통합하기 위해 업그레이드하는 것을 고려하기로 합의했습니다. 이들은 모두 빌딩 블록 역할을 하겠지만 EIP 4200, 4750 및 5450을 도입하지 않으면 완전한 기능을 제공하지 못할 것입니다. EOF를 확장할 수 있지만 이전 버전과의 비호환성으로 인해 새 버전이 필요할 수 있습니다. EOF 이전의 계약 또는 특정 버전의 EOF가 포함된 계약은 항상 실행 가능해야 하므로 각각의 새로운 EOF 버전은 클라이언트 개발자가 이전 규칙과 병렬로 새로운 EVM 실행 규칙 세트를 유지해야 함을 의미합니다.

EOF 전에 클라이언트는 한 번에 하나의 EVM 규칙 세트만 유지합니다. 코드 베이스는 이전 EVM 규칙도 지원하는데, 이는 각 네트워크 업그레이드에서 수정되지만 일단 블록체인의 헤드에 도달하면 최신 규칙만 적용해야 합니다. EOF를 배포한 후 클라이언트는 두 개의 병렬 EVM 규칙 집합을 유지하므로 EOF 및 비 EOF 계약에서 코드를 실행할 수 있습니다. 즉, EOF의 버전 증가는 유지해야 하는 순차적인 EVM 규칙 세트가 아닌 병렬의 수를 증가시킵니다.

이러한 이유로 지난 몇 개월 동안 클라이언트 팀은 "큰 EOF"를 선호하기 시작했습니다."행동 양식. 이렇게 하면 더 큰 개정 세트를 구현해야 하지만 EOF 버전이 더 오래 지속되고 유지 관리해야 하는 "병렬 EVM"이 줄어듭니다."숫자. 따라서 개발자는 "큰 EOF"를 고려하고 최종적으로 상하이 업그레이드에 통합했습니다.

즉, 더 큰 기능은 분명히 구현 및 테스트하기가 더 어렵고 팀은 EOF가 비콘 체인 철수를 크게 지연시키는 것을 보고 싶지 않습니다. 따라서 EOF 구현이 1월까지 완료되지 않고 서로 신속하게 상호 운용할 수 없는 경우 클라이언트 팀은 업그레이드를 위해 EOF를 상하이 밖으로 옮기는 데 동의합니다.

EIP-3540: EVM 개체 형식(EOF) v1(EVM 개체 형식 버전 1)

EIP-3540: EVM 개체 형식(EOF) v1(EVM 개체 형식 버전 1)

이 EIP는 EOF 계약을 위한 "컨테이너"를 도입합니다. 계약의 코드와 데이터 부분을 구분하기 위해 마커를 추가하고 형식을 준수하지 않는 EOF 계약이 배포되는 것을 방지합니다. 이것은 온체인상의 모든 EOF 계약이 유효한 형식을 따르도록 보장하여 이러한 계약과의 상호 작용 및 정적 분석을 단순화합니다.

EIP-3670: EOF - 코드 유효성 검사(EOF - 코드 유효성 검사)

3540에 의해 도입된 컨테이너를 기반으로 하는 EIP-3670은 EOF 계약의 코드가 유효하거나 배포되지 않도록 합니다.

즉, 정의되지 않은 opcode는 EOF 계약에 배포할 수 없으며 추가해야 하는 EOF 버전의 수를 줄이는 추가 이점이 있습니다. 새 opcode가 추가되면 유효성 검사 규칙을 간단히 변경하여 활성화하고 배포된 EOF 계약이 해당 코드 섹션에서 참조하지 않도록 할 수 있습니다.

EIP-4200: EOF - 정적 상대 점프(EOF - 정적 상대 점프)

EIP-4200은 대상을 서명된 즉치값으로 인코딩하는 RJUMP, RJUMPI 및 RJUMPV와 같은 최초의 EOF 관련 opcode를 도입했습니다. 이러한 새로운 JUMP opcode는 기존 JUMP 및 JUMPI opcode에 필요한 런타임 jumpdest 분석의 필요성을 제거하므로 컴파일러에서 가스 오버헤드를 최적화하는 데 사용할 수 있습니다.

EIP-4750: EOF - 기능(EOF에서 가져온 기능)

EIP-4750은 4200에서 한 단계 더 발전하여 JUMP 및 JUMPI opcode를 허용하지 않고 복제할 수 없는 RJUMP, RJUMPI 및 RJUMPV 기능에 대한 대안을 추가합니다. 새로운 JUMPF, CALLF 및 RETF opcode를 각각 사용하여 점프, 호출 및 반환될 수 있는 EOF 바이트 코드의 특정 함수 섹션을 도입하여 이를 수행합니다.

EIP-5450: EOF - 스택 검증(EOF-Stack Validation)

마지막으로 EIP-5450은 이번에는 스택 주변에서 EOF 계약에 대한 또 다른 유효성 검사를 추가합니다. 이 EIP는 EOF 계약 배포로 인해 잠재적으로 스택 언더플로가 발생하고 경우에 따라 코드가 오버플로되는 것을 방지합니다. 이 EIP를 통해 클라이언트는 스택 관련 예외에 대해 더 나은 보증을 제공하므로 EOF 계약을 실행할 때 유효성 검사 횟수를 줄일 수 있습니다.

보조 제목

비콘체인 출금

마지막으로 "Shapella"(번역자 주: 상하이/Capella의 총칭)의 주요 부분은 비콘 체인 철수입니다. 변경의 이 부분은 컨센서스 레이어 사양 및 EIP-4895에 설명되어 있습니다. 이제 이러한 변경 사항을 함께 묶는 약간 오래된 메타 사양이 있습니다.

높은 수준에서 인출 메커니즘은 다음과 같습니다.

블록을 제안할 때 유효성 검사기는 유효성 검사기 인덱스를 선형적으로 스캔하여 다음 조건 중 하나를 충족해야 하는 0x01 인증서가 있는 처음 16개의 유효성 검사기를 찾습니다.

Have a balance above 32 ETH (i.e. have accrued validator rewards)

Are withdrawable (i.e. have fully exited the validator set)

잔액이 32 ETH보다 큽니다(즉, 유효성 검사기 보상을 획득했습니다).

인출 가능(인출 가능, 즉 유효성 검사기 세트에서 완전히 인출됨)

From these, the validator will create a list of withdrawals to be included in their ExecutionPayload. Each item in that list contains the following:

유효성 검사기는 이러한 유효성 검사기에서 인출 목록을 생성하여 ExecutionPayload에 패키징합니다. 목록의 각 항목에는 다음이 포함됩니다.

WithdrawalIndex: 이루어진 모든 출금 거래의 인덱스 - 동일한 주소, 동일한 유효성 검사기에서 동일한 금액의 출금을 구별하는 데 도움이 됩니다.

ValidatorIndex: 잔액이 발생한 유효성 검사기 인덱스

ExecutionAddress: 출금을 보내야 하는 실행 계층의 ETH 주소

금액: ExecutionAddress로 전송된 금액, 이 금액은 wei가 아닌 gwei로 측정됩니다.

블록을 구축하거나 처리할 때 실행 계층 클라이언트는 트랜잭션이 실행된 후 이러한 인출 작업을 수행합니다. 즉, 인출은 작업 증명 보상이 적립되는 방식과 유사하게 처리되며 블록 공간을 놓고 사용자 트랜잭션과 경쟁하지 않습니다.

몇 가지 주목할만한 세부 사항도 있습니다.

인출을 처리할 때 "전체 자금" 제출과 "부분 자금" 제출 사이의 우선 순위/순위에는 차이가 없습니다. 전체 인출은 검증인이 대기열을 떠날 때 이루어지며, 부분 인출은 주기적으로 검증인 세트의 선형 스캔이 수행되고 검증인의 인덱스 번호에 도달할 때 발생합니다.

인출을 처리하려면 유효성 검사기가 ETH 주소로 표시되는 0x01 토큰을 사용해야 합니다. 비콘 체인이 활성화되면 BLS 키 쌍 0x00 자격 증명만 허용됩니다. 인출을 시작하려면 자격 증명이 0x00인 검증인이 BLSToExecutionChange 메시지에 서명해야 합니다. 이들은 Capella 업그레이드에서 활성화됩니다. 이 메시지에 서명하는 데 사용되는 다양한 도구가 있으며 유효성 검사기는 이러한 도구에 대한 지원 및 자습서를 기대할 수 있습니다.

유효성 검사기는 블록별로 스캔됩니다. 유효성 검사기 세트의 하위 집합을 스캔한 후 처리할 인출이 16개 이하인 경우 유효성 검사기는 스캔을 중지하고 다음 유효성 검사기는 마지막으로 스캔한 유효성 검사기 인덱스에서 시작합니다.

늘 그렇듯이 메인넷이 가동되기 전에 유효성 검사기가 문제를 해결하고 해결할 수 있도록 여러 개발자 테스트넷과 테스트넷(새로운 테스트넷일 수도 있습니다!)이 있을 것입니다.

첫 번째 레벨 제목

칸쿤 업그레이드

상하이 업그레이드 내용이 이미 꽉 찼기 때문에 업그레이드를 고려했던 많은 EIP(CFI)가 상하이 업그레이드에 들어가지 못했습니다. 클라이언트 팀은 다음 업그레이드를 위해 어떤 EIP를 고려해야 하는지에 대해 논의하기 시작했습니다: Cancun 업그레이드(합의 레이어 이름 결정 예정)

합의 계층 측면에서 EIP-4844는 Capella 업그레이드 이후 사양에 기록된 첫 번째 EIP가 되었습니다. 실행 계층에는 (아직) 이 레이아웃을 구현하는 사양이 없지만 실행 계층 팀은 다음 업그레이드의 중심에 EIP-4844를 두고 유사한 경로를 따르기로 동의했습니다.

Devcon을 주최한 도시의 이름을 사용하기 위한 업그레이드 규칙에 따라 cancun.md가 생성되었으며 EIP-4844가 업그레이드에 공식적으로 포함되었습니다.

보조 제목

KZG 행사

칸쿤 업그레이드와 관련하여 기대할 수 있는 또 다른 사항은 EIP-4844의 요구 사항인 KZG 의식입니다.

이 의식은 BLOB 데이터의 유효성을 확인하는 데 필요한 임의성을 생성합니다. 안전한 것으로 간주되려면 한 명의 참가자만 정직해야 합니다. 즉, 한 사람을 제외한 모든 사람이 결탁하면 전체 프로세스가 암호학적으로 안전합니다.

첫 번째 레벨 제목

합병 후 업그레이드 프로세스

이전 업데이트에서 언급했듯이 합병 후 실행 및 합의 계층에서 이더리움의 업그레이드 프로세스를 조정하는 것은 중요한 백로그입니다. 높은 수준에서 실행 계층은 Yellow Paper & EIP를 사용하여 수정 사항을 지정하는 반면 합의 계층은 실행 가능한 Python 사양을 사용합니다.

경영진 수준 프로세스의 이점은 EIP가 커뮤니티에 잘 알려져 있고 제안의 이유를 명확하게 보여주는 방식으로 형식화된다는 것입니다. EIP와 쌍을 이룬 수학이 많은 노란색 종이와 각 EIP의 컨텍스트에 사양을 다시 넣어야 하는 필요성으로 인해 구현 수준 사양을 이해하고 확장하기가 어려웠습니다.

합의 계층의 문제는 정반대입니다. 단일 리포지토리에 명확하고 이해하기 쉬운 사양이 있지만 변경 사항을 구체적으로 식별할 수 없으며 제안이 리포지토리의 다른 공개 PR에 묻혀 있습니다.

Ethereum Execution Layer 사양의 도입으로 실행 계층 관점에서 이 격차를 좁힐 수 있기를 바랍니다. 그리고 약간의 프로세스 랭글링을 통해 EIP를 합의 레이어 프로세스로 가져올 수 있습니다!

즉, 상하이의 업그레이드 범위가 논의되고 확정됨에 따라 프로세스의 또 다른 부분이 부족할 수 있음이 분명해졌습니다. 즉, 커뮤니티가 변경 사항에 대한 상대적 선호도를 표현하고 전체 업그레이드 범위에 대한 토론에 참여하도록 하는 것입니다. (개별 EIP가 아닌) AllCoreDevs 및 Consensus Layer 회의에서 그것이 어디에 있는지 논의하고 결정의 일부로 만드십시오.

그것이 어떤 것인지는 확실하지 않습니다. 제안을 받고 싶습니다! — 그러나 프로토콜 변경에 적극적으로 참여하는 이해관계자의 수와 계층 변경의 영향을 받는 도메인의 수가 증가함에 따라 분명히 무언가가 필요합니다.

다행히 처음부터 시작할 필요는 없습니다. Ethereum Magicians는 수년 동안 사용되어 왔으며 모임, 전용 그룹 모임 또는 커뮤니티 모임은 확장을 위한 좋은 출발점이 될 수 있습니다.

첫 번째 레벨 제목

프로토콜 길드 업데이트

PG(Protocol Guild) 파일럿이 중간에 진행되면서 상황이 어떻게 진행되고 있는지 살펴보고 프로젝트의 다음 단계에 대해 생각하는 보고서를 발표했습니다.

PG는 Ethereum Layer 1 클라이언트 개발자, 프로토콜 연구원 및 귀하와 같은 지원 기여자를 위한 무허가 자금 조달 메커니즘입니다.

이 메커니즘은 조직이 아닌 개인을 중심으로 합니다. 요컨대, 각 구성원은 이더리움에 기여한 기간에 따라 가중치가 부여된 길드의 토큰 지분을 받을 자격이 있습니다. 구성원 추가 및 삭제는 이더리움의 진정한 방식으로 수행됩니다. 일련의 표준을 기반으로 PG 내에서 일반적인 합의에 도달합니다. 그런 다음 이 목록은 0xSplit의 분할 계약을 사용하여 온체인에 배치됩니다. 그런 다음 기부자는 수령인의 주소로 직접 자금을 보내거나 수령인의 주소로 자금을 발행하는 베스팅 계약으로 자금을 보낼 수 있습니다.

파일럿 중간 보고서는 이 트윗에 요약되어 있습니다. 다음은 몇 가지 하이라이트입니다.

파일럿은 Lido, Uniswap, ENS, NounsDAO 및 MolochDAO와 같은 조직과 정기적으로 기부하는 일부 개인(Tetranode에 감사드립니다!)으로부터 970만 달러를 모금했습니다. 이 일을 가능하게 해주신 모든 분들께 감사드립니다!

PG는 출시 당시 90명의 회원이 있었지만 현재는 128명으로 500만 달러가 그들 사이에 분배되었습니다.

평균적으로 각 회원은 $39,000를 받았으며 최저 $13,000, 최고 $79,000를 받았습니다.

PG의 아키텍처가 변경되고 있으며 L2를 지원하고 가중치를 업데이트하기 위해 다중 서명이 필요하지 않습니다.

이러한 초기 결과는 PG가 계획대로 작동하고 있음을 보여줍니다. 토큰 바구니를 자체 배양하고 성장하는 프로토콜 기여자 집합에 배포하는 메커니즘입니다. 파일럿 기부자의 아낌없는 지원이 없었다면 이 프로젝트는 오늘날의 위치에 있지 않았을 것입니다.

앞을 내다보면 지금이 PG의 도달 범위를 확장하고 잠재력을 최대한 실현할 때입니다. 이더리움 관리자를 위한 경쟁적이고 위험 조정된 보상입니다. 여기서 가장 쉬운 것은 PG를 시작한 트윗에서 Danny Ryan이 말했듯이 프로젝트 시작부터 PG에 기부하는 것입니다.

파일럿에서 대부분의 기부금은 상당한 자금을 지원하는 더 큰 프로젝트에서 나왔습니다. 프로토콜 길드가 이러한 프로젝트가 토큰이 여전히 진정으로 "가치가 없는" 첫날부터 PG에 기부하도록 설득할 수 있다면, 이더리움 관리자는 이러한 성공적인 프로젝트의 전체 상승 궤도에서 이익을 얻을 수 있습니다.

충분한 프로젝트가 관련되어 있으면 인센티브를 통해 유지 관리 계약에서 최고의 인재를 끌어내지 않고 유지할 수 있습니다.

이를 지원하고 다른 많은 기부 유형을 지원하기 위해 PG는 기술 점검이 필요합니다. 다음 버전은 L1 및 L2를 지원하고 온체인 거버넌스 공간을 더욱 줄일 것입니다.

첫 번째 레벨 제목