원래 제목:Ethereum All Core Developers Consensus Call #107 Writeup

원래 제목:

2023년 4월 20일, 이더리움 개발자들이 107차 ACDC(Core Developers Consensus Conference Call)를 위해 모였습니다. ACDC는 Ethereum Foundation의 연구원인 Danny Ryan이 진행하는 격주 컨퍼런스 시리즈로, Ethereum 개발자들이 Ethereum Consensus Layer(CL)의 변경 사항에 대해 논의하고, Deneb 주변의 진행 상황을 업데이트하고, Ethereum EIP-4844 외에 다른 제안에 대해 논의합니다. 다음 Cancun 업그레이드에 포함됩니다.

Deneb Devnet #5 

첫 번째 레벨 제목

4월 12일 상하이에서 성공적인 활성화 이후 이더리움 개발자들은 처음으로 칸쿤 준비에 관심을 돌렸습니다. Cancun은 Ethereum 실행 계층(EL)의 다음 업그레이드 이름이고 Deneb는 CL에 해당하는 업그레이드 이름입니다. ACDE 통화 중에 개발자는 EIP 4844를 중심으로 하는 Cancun/Deneb 업그레이드의 최종 범위, blob 트랜잭션 유형의 구현 및 devnet #5의 출시를 시작으로 Deneb의 준비 상태에 대해 논의했습니다.
개발자들은 지난 10월부터 EIP 4844에 대한 다중 클라이언트 테스트넷(devnets라고도 함)을 시작했습니다. ACDE 컨퍼런스 콜 의장인 Tim Beiko에 따르면 EIP 4844의 다섯 번째 devnet이 다음 주에 출시될 예정입니다. Ethereum Foundation의 DevOps 엔지니어인 Paritosh Jayanthi는 다음 주 Devnet 출시를 준비하기 위해 Ethereum JS(EL) 및 Lodestar(CL)와 같은 클라이언트를 위한 파일럿을 실행하고 있다고 말했습니다.

무엇보다도 "getPayload V3" 및 "getBlobsBundle V1" 호출을 하나로 병합하는 엔진 API에 대한 작은 변경 사항이 있습니다. Beiko는 이 변경 사항이 아직 GitHub의 EIP 4844 사양에 병합되지 않았지만 devnet #5에서 변경 사항을 테스트할 수 있도록 며칠 내에 완료될 것이라고 강조했습니다. Beiko는 클라이언트 팀이 이 변경 사항을 최대한 빨리 검토할 것을 촉구했습니다. 가능한 한.ETHTokyo그런 다음 개발자는 체인 재구성의 경우 Blob 트랜잭션을 블록에 다시 삽입하는 방법에 대해 논의했습니다. 이 질문은 Geth(EL) 개발자 Péter Szilágyi가 그의PPT위의 프리젠테이션에서 제안됨(Szilágyi's에서 사용 가능)

)에서 자세한 정보를 찾으십시오. Ryan은 blob 트랜잭션이 일반 트랜잭션과 분리되는 특성으로 인해 재구성된 blob은 공용 mempool의 트랜잭션에서만 얻을 수 있다고 말했습니다. mempool을 우회하는 트랜잭션, 즉 MEV 트랜잭션 및 번들이 많다는 점을 감안할 때 모든 blob이 재구성될 수 있음을 보장하는 한 가지 방법(mempool을 우회하는 트랜잭션도 포함)은 CL이 각 블록의 blob 데이터를 EL로 전달한 다음 EL로 전달하는 것입니다. 블록이 완료될 때까지 캐시할 수 있습니다. 또는 네트워크는 mempool을 건너뛰는 트랜잭션을 제출한 사용자가 체인 재구성 이벤트에서 트랜잭션을 다시 제출하도록 요구할 수 있습니다.

Szilágyi는 blob 데이터를 EL로 전송하여 재편성 시 트랜잭션이 다시 삽입될 수 있도록 하는 전자를 선호한다고 말했습니다. 심지어 mempool을 우회하는 트랜잭션도 마찬가지입니다. Szilágyi의 관점에서 이것은 EL에 대한 추가적인 부하가 아니며 노드가 지원하기에 프로세스가 너무 복잡해지면 개발자는 부하를 줄이기 위해 EL과 CL 사이의 메시지를 조정할 수 있습니다. Szilágyi는 "가장 간단한 솔루션은 합의 클라이언트가 새 페이로드를 보낼 때 실행 클라이언트에 BLOB를 제공하는 것입니다."라고 말했습니다. Ryan은 제안된 솔루션이 간단하지만 EL 및 CL 레이어 간의 추상화를 더욱 깨뜨린다고 응답했습니다. 또한 이 솔루션은 노드가 완전한 데이터를 저장한다는 가정을 시행하며 이는 DAS(Data Availability Sampling)를 구현하는 향후 업그레이드에서 손상될 수 있습니다.

EL 고객 그룹의 참여 부족으로 인해 이 질문은 다음 ACDE 컨퍼런스 콜에서 다시 제기될 것입니다.

Deneb Add-Ons

첫 번째 레벨 제목

Deneb 업그레이드는 EIP-4844 외에도 다른 코드 업그레이드도 고려했습니다.

1. 첫 번째는 EIP-4788로 CL 비콘체인의 상태를 EL에 노출시킬 수 있다. 이를 통해 EL에서 실행되는 스마트 계약은 스테이킹 풀, 재스테이킹 프로토콜, MEV 등과 관련된 CL에 대한 신뢰 최소화 액세스를 가질 수 있습니다. EIP의 저자 중 한 명인 Ethereum Foundation 연구원 Alex Stokes는 이 기능이 CL에 대한 "경량" 변경이라고 말했습니다. 통화에 Deneb에 EIP 4788을 포함시키는 데에는 이의가 없었습니다. 이 EIP에 대한 지원은 다음 ACDE 컨퍼런스 콜에서 EL 고객 팀에게 요청할 것입니다.

2. EIP-6914, 이 제안은 네트워크에서 완전히 철회되고 일정 기간 동안 활성화되지 않은 유효성 검사기 번호를 재사용할 수 있습니다. 이 EIP는 유효성 검사기가 종료되고 새로운 유효성 검사기가 네트워크에 합류함에 따라 유효성 검사기 목록의 무한 성장을 줄이는 데 도움이 됩니다. Stokes는 EIP 6914의 복잡성이 상대적으로 높으며 코드 변경은 Deneb 이후의 다음 하드 포크까지 연기되어야 한다고 말했습니다. EIP-6914의 복잡성에 대해 논의한 후 개발자는 코드 업데이트의 세부 사항에 대해 계속 논의하기로 합의했지만 최종 구현은 Deneb까지 남겨 두었습니다.
4、PR 3175 3. Ryan은 Beacon Chain 제네시스 블록의 데이터를 백필하고 새로운 "역사적 요약" 콘텐츠를 생성하는 것과 관련된 잠재적인 코드 변경을 제안했습니다. 이 코드 변경에 대한 세부 사항은 아직 EIP에 지정되지 않았습니다. Ryan은 이 변경 제안자인 Jacek Sieka(Nimbus(CL) 클라이언트를 구축하고 있는 Status의 연구 개발 책임자)에게 자세한 내용을 문의하기로 동의했습니다.

, 이 제안은 불이익을 받은 검증자가 대기열에서 제거될 때 블록을 제안하는 것을 방지합니다. 검증인의 50% 이상이 악의적인 행동으로 처벌을 받는 경우 해당 검증인은 네트워크에서 강제로 제거되는 동안에도 여전히 블록을 제안할 수 있습니다. 이 논리를 변경하는 것은 "높은 고장 모드"에 대한 보호를 제공하는 상대적으로 작은 CL 레이어 변경이라고 Ryan은 말했습니다.5. EIP-6493, CL에서는 SSZ 형식이지만 EL에서는 다르게 인코딩되는 Blob 트랜잭션 유형을 노드가 처리하는 방법을 설명합니다. 이 EIP는 계층 간 일관성을 달성하기 위해 Ethereum 직렬화 형식을 업데이트하는 일부입니다. Ethereum 직렬화 형식에 대한 자세한 배경 정보는 이전에 읽을 수 있습니다.。

개발자 기록