10월 12일 이더리움 개발자들이 Zoom 컨퍼런스 콜을 위해 모였습니다. Ethereum Foundation의 프로토콜 지원 책임자인 Tim Beiko가 주최한 회의에서는 개발자들이 Ethereum Execution Layer(EL)에 대한 변경 사항을 논의하고 조정했습니다. 최신 회의는 Dencun 테스트 및 EVM 개체 형식 개발을 중심으로 이루어졌습니다.

10월 12일, 이더리움 개발자들은 ACDE(All Core Developers Execution) Call #172 회의를 위해 Zoom에 모였습니다. ACDE 컨퍼런스 콜은 이더리움 재단의 프로토콜 지원 책임자인 Tim Beiko가 주최하는 격주 일련의 회의로, 개발자들은 이더리움 실행 계층(EL)에 대한 변경 사항을 논의하고 조정합니다. 이번 주 개발자들은 다음 주제의 진행 상황에 중점을 두고 있습니다.

칸쿤/데네브(덴쿤) 테스트

EVM(Ethereum Virtual Machine) 개체 형식 개발.

덴쿤 테스트

Ethereum Foundation의 DevOps 엔지니어인 Barnabas Busa는 최근 9월 29일에 출시된 Devnet #9에 대한 일부 업데이트를 공유했습니다.

Devnet #9의 참여율은 현재 93%입니다. 이는 검증인의 93%가 네트워크 합의에 적극적으로 참여하고 있음을 의미합니다.

실행되지 않는 검증인의 7%는 주로 Geth(EL)/Teku(CL) 검증인 노드로 구성됩니다.

Erigon(EL)/Prysm(CL) 클라이언트 조합과 EthereumJS(EL) 클라이언트에도 문제가 있습니다.

Flashbots 팀은 Devnet #9에서 MEV-Boost 릴레이 및 빌더를 테스트하고 있습니다. Busa는 Devnet #9에서 더 많은 MEV 인프라를 테스트할 수 있도록 다른 릴레이 및 빌더 운영자가 자신에게 연락할 것을 권장합니다.

Blob 트랜잭션은 MEV-Boost 빌더로 테스트되지 않았습니다. 이 경우 빌더가 Blob을 삭제했지만 개발자는 이것이 Blob이 실제로 유효하지 않기 때문인지, 최소 기본 요금 요구 사항을 충족하지 않기 때문인지, 아니면 다른 이유로 삭제되었는지 아직 확신하지 못합니다.

Busa와 그의 Ethereum Foundation 동료 Parithosh Jayanthi는 곧 출시될 Devnet #10에 대한 업데이트를 공유했습니다.

Devnet #10은 이번 주에는 준비되지 않았지만 다음 주에는 준비될 것으로 예상됩니다.

Devnet #10의 경우 개발자는 EIP 4844 KZG 시상식에서 신뢰할 수 있는 설정 파일을 테스트할 계획입니다.

Devnet #10은 330,000명의 활성 유효성 검사기를 포함하여 대규모 유효성 검사기 기반을 갖게 됩니다. 개발 네트워크가 막 출시되면 검증인 입출금이 대량으로 유입될 예정이며, 네트워크 출시 후 1~2일 이내에 검증인 입출금 한도가 5회에서 4회로 줄어들 것으로 예상됩니다. 메인넷의 실제 최대 수신 이탈 제한은 8이지만, 개발자는 Devnet #10에서 EIP 7514를 테스트하기 위해 4라는 제한을 채택할 것입니다.

Busa는 개발자들이 Dencun의 테스트 프로세스 중에 몇 가지 주요 문제를 여전히 해결하고 있다고 강조했습니다. 개발팀은 이러한 문제가 제대로 해결될 때까지 Devnet #10을 출시하지 않을 것이며, 이는 Goerli와 같은 공용 Ethereum 테스트넷에서 업그레이드가 활성화되기 전 Dencun의 최종 devnet이 될 가능성이 높습니다. Zoom 채팅에서 Jayanthi는 Devnet #10을 출시하기 전에 개발자가 해결해야 할 주요 문제를 설명했습니다.

EIP 4844 KZG 행사에 대한 신뢰할 수 있는 설정 파일 업데이트

Blob 트랜잭션의 시각화 향상

MEV 파이프라인 개선

네트워크 안정성 향상

EIP 4844 KZG 행사에 대한 신뢰할 수 있는 설정 파일 업데이트

Blob 트랜잭션의 시각화 향상

MEV 파이프라인 개선

네트워크 안정성 향상

통화 중에 Jayanthi는 Blob 트랜잭션의 가시성을 높이기 위해 Beacon API에 대한 지원을 추가하도록 고객 팀에 권장했습니다. Beiko는 개발자들이 Devnet #10 출시 후 Goerli 테스트 네트워크를 업그레이드할 의향이 있는지 물었습니다. Busa는 후속 업그레이드 테스트 단계를 결정하기 전에 Devnet #10의 성능을 관찰할 것을 권장합니다.

또한 Jayanthi는 Devnet #10 출시 후 일정 기간 동안 개발자가 Dencun 업그레이드를 추가 테스트하기 위해 공개 테스트 네트워크 테스트 작업과 동시에 Ethereum 메인넷의 섀도우 포크를 수행할 수 있음을 확인했습니다. 그러나 Jayanthi는 Dencun 테스트 중에 발견된 대부분의 버그가 P2P 네트워크 수준에 있었기 때문에 섀도우 포크의 유용성이 제한될 수 있다고 지적했습니다.

Geth(EL) 개발자 Marius van der Wijden은 그의 동료 Péter Szilágyi가 Devnet #9에서 자신의 노드를 성공적으로 실행했으며 블롭 스팸과 관련된 심각한 문제를 발견했다고 말했습니다.

노드 충돌을 방지하기 위해 Szilágyi는 개발 네트워크에서 본 blob 수를 제한하는 트랜잭션 핸들러를 구현한 것으로 알려졌습니다. Van der Wijden은 CL 팀이 EIP 4844의 3/6 최대 blob 목표/제한을 다시 검토하고 EL 팀이 노드 대역폭 요구 사항과 blob 스팸을 해결하는 방법을 심층적으로 고려하도록 권장했습니다.

이러한 문제를 더 자세히 논의하기 위해 Beiko는 개발자가 10월 16일 Dencun 상호 운용성 테스트 회의에 참석할 것을 권장합니다.

EVM 객체 형식 개발

그런 다음 개발자들은 EVM 개체 형식(EOF)의 최신 개발 사항에 대해 논의했습니다. EOF는 스마트 계약 코드를 실행하는 데 사용되는 이더리움 기반 가상 머신인 EVM의 변경에 초점을 맞춘 EIP 세트입니다. EOF 옹호자 중 한 명인 Danno Ferrin은 지난 몇 달 동안의 EOF 작업을 요약하고 정리했습니다.

프레젠테이션 시작 부분에서 Ferrin은 EOF가 Cancun/Deneb(Prague/Electra라고 함) 이후의 업그레이드에서 주요 코드 변경이 될 것으로 예상한다고 강조했습니다. Ferrin은 현재 EOF를 작업하는 주요 팀이 4개 있다고 말했습니다.

Team Ipsilon: EVM 개선에 중점을 두고 Ethereum Foundation에서 자금을 지원하는 개발 팀

EL 클라이언트 팀: Geth, Besu 및 Nethermind 등

Solidity 및 Vyper와 같은 고급 언어 컴파일러 팀

스마트 계약 개발자: 예를 들어 SSTORE2 opcode 옹호자.

일반적으로 다양한 팀이 EOF 개발에 기여하고 이더리움 네트워크의 기술 발전을 공동으로 추진하고 있습니다.

EOF의 주요 목표는 EVM 코드에 대한 새로운 컨테이너 형식을 만드는 것입니다. 이 컨테이너 형식은 코드와 데이터를 명확하게 구분하지만 현재 형식에서는 불가능합니다. 또한 새로운 opcode의 도입을 허용하고 스마트 계약 개발자가 애플리케이션을 보다 효율적으로 설계하는 데 도움을 주며 더 나은 코드 보안을 제공합니다. EOF에서는 기존 형식을 유지하면서 EVM 코드에 대한 새로운 컨테이너 형식을 생성해야 합니다.

EVM과 관련된 이러한 변경 사항의 구현 및 테스트를 용이하게 하기 위해 Ferrin은 개발자가 새로운 EOF EVM 코드를 사용하는 스마트 계약과 그렇지 않은 이전 스마트 계약 간의 종속성을 줄일 수 있는 방법을 자세히 설명했습니다. 클라이언트 팀은 두 가지 버전의 EVM을 유지해야 하지만 Ferrin은 새 버전이 현재 EVM보다 업데이트하기가 더 쉬울 것이라고 믿습니다. 그는 또한 시간이 지남에 따라 점점 더 많은 스마트 계약 개발자가 EOF를 채택함에 따라 현재 EVM이 점차 쓸모 없게 될 수 있다고 말했습니다.

Ferrin이 연설에서 언급한 EOF 관련 EIP는 다음과 같습니다.

EIP 3540: EVM 코드를 위한 새로운 컨테이너 형식입니다.

EIP 4200: 정적 점프를 도입하는 세 가지 새로운 EVM 점프 명령어.

EIP 4750: 두 개의 새로운 opcode는 동적 점프의 필요성을 제거하고 비활성화합니다.

EIP 3540: EVM 코드를 위한 새로운 컨테이너 형식입니다.

EIP 4200: 정적 점프를 도입하는 세 가지 새로운 EVM 점프 명령어.

EIP 4750: 두 개의 새로운 opcode는 동적 점프의 필요성을 제거하고 비활성화합니다.

EIP 663: 두 개의 새로운 명령어를 통해 스택 깊이 256(16 대신)에 액세스할 수 있습니다.

EIP 7480: EOF 컨테이너의 데이터 부분을 읽을 수 있는 4개의 새로운 명령어.

EIP 7069: 가스 사용 및 비용 관련 의미를 단순화하기 위한 세 가지 새로운 호출 지침입니다.

EIP 5450: 계약 실행 중 EOF 형식 스마트 계약 검증을 도입합니다.

EIP 3670: 계약 생성 시 EOF 형식 스마트 계약 검증을 도입합니다.

EOF opcode에 대한 전체 변경 목록을 보려면 Ferrin 프레젠테이션의 다음 차트를 참조하세요.

EOF opcode 변경 사항 요약. 출처: Danno Fehling

EOF 테스트 진행 상황과 관련하여 Ferrin은 EOF 사양이 아직 완성되지 않았기 때문에 클라이언트가 아직 업그레이드를 구현하지 않은 이유라고 설명했습니다. 그러나 그는 EOF의 초점이 EVM에 수행된 변경에만 맞춰져 있기 때문에 EOF 테스트가 매우 "독립형"이고 상대적으로 간단할 것으로 예상합니다. 그는 "우리는 네트워크 상호작용이나 다른 CL/EL 조합과의 페어링에 대해 걱정할 필요가 없다"며 "테스트할 수 있기 때문에 동일한 수준의 개발 네트워크와 테스트 네트워크가 필요하지 않을 것이라고 생각한다"고 말했다. ." Ferrin은 다음과 같이 덧붙였습니다. "우리는 명확한 참조 테스트를 작성할 것입니다. 또한 우리가 가진 가장 큰 장점 중 하나는 지금까지 수행해 온 차동 EVM 테스트입니다."

강연이 끝날 때 Ferrin은 EOF를 프라하/Electra 업그레이드의 주요 코드 변경으로 보고 싶다는 바람을 반복했습니다. 그는 또한 Dencun 업그레이드가 완료된 후 3~6개월 이내에 메인넷에서 EOF에 대한 일련의 코드 변경을 테스트하고 실행하는 것이 가능하다고 말했습니다. EOF의 최신 사양은 여기에서 확인할 수 있습니다 . Ipsilon 팀은 이러한 사양에 대한 공개 질문을 여기에 정리했습니다. EOF 사양의 일부 부분은 여전히 ​​개선이 필요합니다. 통화에 참여하는 개발자는 Ethereum Research and Development Discord의 "#EVM" 채널에서 EOF의 최신 개발 및 사양에 대한 생각을 공유하도록 권장됩니다.

EVM 객체 형식 논쟁

Ferrin의 프레젠테이션은 개발자들 사이에서 광범위한 토론을 촉발시켰습니다. 컨퍼런스 콜 동안 EOF에 대한 개발자들의 주요 관심사는 다음과 같습니다.

일정: Tim Beiko를 포함한 여러 개발자는 Dencun 업그레이드 후 EOF 구현에 3~6개월이 소요되는 일정을 망설였습니다.

긴급성: 개발자들은 또 다른 주요 코드 변경을 통해 Verkle을 Bragg/Electra에 통합하는 것을 고려하고 있습니다. 8월 초, 이더리움 재단 개발자인 Guillaume Ballet은 Verkle의 최신 진행 상황을 공유했습니다. 이번 주 컨퍼런스 콜에서 Ballet은 Verkle이 EOF보다 이더리움에 대한 더 긴급한 업그레이드이므로 우선순위를 두어야 한다고 강조했습니다. Ballet은 또한 구현이 Verkle의 일정에 영향을 미치지 않도록 EOF의 복잡성을 줄이고 코드 변경 횟수를 줄일 수 있다면 업그레이드를 지원할 것이라고 말했습니다.

이점: Van der Wijden과 Nethermind(EL) 개발자 Lukasz Rozmej는 EOF의 즉각적인 이점과 업그레이드 복잡성 간의 균형에 대해 의문을 제기합니다. EVM에 대한 이러한 큰 변화에 대한 강력한 수요가 부족하다는 우려에 대해 Ferrin은 EVM이 Ethereum의 원래 개발 팀에 의해 "주말 동안" 작성되었으며 EVM이 유지되도록 많은 개선이 이루어질 수 있다고 말했습니다. Layer-1 블록체인 Sui의 새로운 대체와 같은 경쟁업체와 경쟁할 수 있습니다. Ferrin은 "이것은 보안 위험이 아닙니다."라고 말했습니다. "이것은 실존적인 거래에 가깝습니다."

복잡성 및 위험 증가: Van der Wijden은 EOF가 프로토콜 복잡성과 위험을 증가시킬 수 있는 방식을 강조했습니다. 두 버전의 EVM을 유지 관리하고 향후 하드 포크 중에 상호 종속성을 고려해야 하는 고객 팀의 부담이 커질 것입니다. Wijden은 Layer-2 팀이 EVM 및 EOF 유지 관리 작업을 클라이언트 팀에 동시에 "푸시"하려고 시도해서는 안 되며 자체 프로토콜에서 EVM 개선 사항을 구현하는 데 집중해야 한다고 믿습니다.

하위 호환성: EOF의 또 다른 주요 문제는 레거시 스마트 계약에 하위 호환성 문제가 발생할 수 있다는 것입니다. EOF는 EOF 컨테이너를 사용하지 않는 레거시 스마트 계약에 대한 지속적인 지원을 보장하는 방식으로 설계되었습니다. 그러나 Ferrin과 Ethereum Foundation 연구원인 Ansgar Dietrichs와 같은 개발자는 시간이 지남에 따라 오래된 스마트 계약 기능이 단계적으로 폐지되고 EOF를 위해 특별히 업그레이드될 수 있다고 제안했습니다.

EVM 거버넌스: Dietrichs는 또한 EOF가 EVM 거버넌스에 미치는 영향에 대해 우려를 표명했습니다. Ethereum은 Layer-2라는 대체 네트워크에서 스마트 계약 실행을 지원하기 위해 끊임없이 발전하고 있습니다. 미래에 대부분의 사용자 활동과 스마트 계약 실행이 오프체인에서 발생하고 이더리움이 주로 데이터 가용성 계층으로 사용된다고 가정하면 EVM의 변경은 이더리움 메인넷보다는 레이어 2 프로토콜에 가장 중요해야 합니다. Dietrichs는 개발자가 확장되는 레이어 2 생태계에서 EVM을 변경하기로 결정하는 방법을 신중하게 고려하고 논의할 것을 권장합니다.

Ferrin 등은 이르면 2021년부터 EOF 연구 작업을 시작했습니다. 올해 초 EOF는 다단계 로드맵으로 인해 상하이 하드 포크에 의해 거부되었습니다. EOF 지지자들은 하나의 대규모 업그레이드로 모든 EOF 관련 변경 사항을 도입하는 업데이트된 업그레이드 디자인을 만들어 이 문제를 해결했습니다. 그러나 이번 업그레이드의 복잡성은 이번 주 컨퍼런스 콜에서 제기된 EOF에 대한 주요 우려 사항 중 하나였습니다. Van der Wijden은 이번에는 개발자가 EOF에 대한 결정을 계속 지연시키기보다는 Ethereum에서 EOF를 구현해야 하는지 여부를 신중하게 고려해야 한다고 강조했습니다.

"Ipsilon 팀과 Danno가 이 문제를 해결하기 위해 많은 시간을 보냈다는 것을 알고 있으며, 아마도 오랜 시간이 지나도 이를 제공하지 못할 것이라고 말하는 것은 꽤 가혹한 일이지만, '어디 보자'라고 말하는 것이 더 나쁠 것이라고 생각합니다. ' 그리고 나서 우리는 2년 동안 지연되었고 '아, 우리는 결국 배송하지 않을 것입니다'라고 말했습니다. 그래서 Devconnect에 대한 결정을 내려야 한다고 생각합니다."라고 van der Wijden은 덧붙였습니다. 그것이 우리가 하고 싶은 일이라면 그렇게 할 것입니다. 비슷한 기술적인 문제가 없다면 그렇게 할 것입니다. 우리가 하지 않을 일이라고 말하면 우리는 그렇게 할 것입니다. 그런 일은 없을 것 같아요. 그 동안의 노력에 비해 모두가 명확한 결정을 내리는 것은 팀에게 있어서 공정한 일이죠.”

Rozmej는 개발자가 EOF 및 Verkle 외에도 증가하는 역사적 체인 데이터 증가 문제를 해결하기 위해 EIP 4444와 같은 코드 변경을 재고해야 한다고 덧붙였습니다. Rozmej에 따르면 과거 체인 데이터 증가율은 월 20GB입니다. Beiko는 개발자가 Devconnect에서 EOF, Verkle 및 Praha/Electra에 대해 계속 논의해야 한다는 데 동의했습니다. Beiko는 또한 10월 18일 수요일에 이러한 팀 간의 협업을 장려하기 위해 EVM과 유사한 레이어 2 프로토콜을 소집하는 데 전념할 것이라고 강조했습니다. 같은 날 EOF 구현자 컨퍼런스 콜도 있을 예정입니다. 마지막으로 Beiko는 Devconnect에서 L2Beat가 주최한 전용 Layer2 Day 이벤트에 대해 언급했습니다.