한 기사에서 이더 이더리움 Shapella 업그레이드 의 잠재적인 업데이트에 대해 알아보세요.
원제: 《 이더리움 올 코어 개발자 콜 #149 작성 》
크리스틴 킴 지음
편집: 밤새 죽
2022년 11월 10일, 이더 개발자들이 149번째 All Core Developers(ACD) 콜에 모였습니다. ACD 콜은 이더 재단의 팀 베이코가 진행했습니다. 이번 주에 개발자들은 병합된 이더 네트워크(상하이라고 함)의 첫 번째 주요 업그레이드를 달성하기 위한 EVM 객체 형식(EOF) 및 프로토-댄크샤딩과 관련된 코드 변경의 진행 상황에 대해 논의했습니다. 통화 중에 개발자들은 이더리움 Shapella 업그레이드 에 포함될 수 있는 다른 네 가지 EIP에 대해서도 논의했습니다. 각 제안은 이더 에 고유한 장점과 이점을 가져다주지만, 어떤 EIP를 우선적으로 포함할지에 대해서는 개발자들 사이에서 여전히 많은 논란이 있습니다. 이더리움 Shapella 업그레이드 논의 외에도 개발자들은 검열 저항성과 네트워크 확장성을 위해 이더 의 검열 저항 기능이 감수해야 할 잠재적인 타협에 대한 주제도 간략히 다루었습니다.
이더리움 Shapella 업그레이드 계획
이전 ACD 통화에서 이더 개발자들은 이더리움 Shapella 업그레이드 에 핵심 EIP 목록을 포함하기로 합의했습니다. ACD 콜 #148의 전체 통화 내용은 여기에서 확인할 수 있습니다. 이 핵심 EIP 목록에서 주목할 점은 개발자들이 이더리움 Shapella 업그레이드 에 스테이킹 ETH 인출 제안을 포함시키기로 동의했지만, 나머지 두 제안의 코드 변경 사항이 더욱 구체화될 때까지는 동일한 업그레이드에 EOF나 프로토-댄크샤딩을 포함시키기로 약속하지 않았다는 것입니다. 특히 EOF 주제에 대해 개발자들은 이더리움 Shapella 업그레이드 에서 소규모 EIP 세트를 통해 EOF를 부분적으로 구현할지, 아니면 상하이 이후 이더 업그레이드에 EOF 전체 비전을 묶을지에 대해 주저해 왔습니다.
EOF 구현
Hedera 최고 소프트웨어 엔지니어인 Danno Ferrin은 상하이 EOF 구현 진행 상황에 대한 이번 주 통화에 대한 업데이트를 제공했습니다. 그는 개발자들이 가능한 한 일찍 EOF 구현과 관련된 대부분의 EIP를 하나의 대규모 업그레이드로 묶는 경향이 있다고 설명했습니다. 개발자들이 이더리움 Shapella 업그레이드 에 포함을 고려하고 있는 EOF 구현과 관련된 EIP는 EIP 3540, EIP 3670, EIP 4200 및 EIP 4750입니다. 개발자들 사이에서는 EIP 5450을 EOF와 관련된 코드 변경 목록에 포함해야 하는지에 대한 의견이 여전히 분분합니다.
Erigon Execution Layer(EL) 클라이언트 팀의 Andrew Ashikhmin도 Solidity 스마트 계약 언어 팀이 4개(혹은 5개)의 EIP를 모두 완벽하게 지원하고 구현할 수 있을지에 대한 우려를 표명했습니다. 아시크민은 이더리움 Shapella 업그레이드 에서 이러한 EIP를 활성화하기로 약속하기 전에 먼저 Solidity 팀이 이러한 EIP를 구현할 준비가 되었는지 확인해야 한다고 강조했습니다. 아시크민은 전화 통화에서 이것이 "필요한 정신 건강 점검"이라고 말했고, Geth EL 클라이언트 팀의 마리우스 반 더 바이덴도 이에 동의했습니다.
프로토-댄크샤딩
그런 다음 개발자들은 프로토-댄크샤딩의 최신 개발 사항에 대해 논의했습니다. EOF 구현과 달리 프로토-댄크샤딩 코드 변경과 연관된 EIP는 EIP 4844 뿐입니다. OP Labs의 연구원인 Diederik Loerakker(종종 "Protolambda"로 불림)에 따르면 EIP 4844와 관련하여 아직 논의 중인 사항이 있습니다. 이더 Foundation의 Ansgar Dietrichs는 이러한 항목 중 일부가 블롭 트랜잭션의 최소 가격을 설정하고 이더리움 Shapella 업그레이드 의 블롭 트랜잭션 처리량을 줄이는 것과 관련이 있다고 덧붙였습니다. 이러한 TODO는 Github 에 요약되어 있습니다.
Self-Destruct 명령어 및 잠재적으로 다른 EIP를 비활성화합니다.
개발자들이 이더리움 Shapella 업그레이드 위한 EOF와 프로토-댄크샤딩 작업을 준비하는 동안, 개발자들은 이더 의 다음 업그레이드에 포함될 다른 4개의 EIP 작업을 계속 진행하기로 잠정적으로 합의했습니다.
1. EIP 4758 , 이더 에서 "자체 파괴" 명령어 비활성화: 개발자들은 명령어 비활성화에 대한 마지막 ACD 콜에서 논의된 내용을 다시 살펴보았습니다. 이 명령어 비활성화는 개발자들 사이에서 스마트 계약 및 탈중앙화 애플리케이션(dapp)에서 사용하기에 좋지 않은 관행으로 널리 알려져 있습니다. 이 명령어는 배포 시 고정된 가스 비용을 갖지만 잠재적으로 네트워크에 대한 무제한 저장 비용을 갖는 몇 안 되는 레거시 명령어 중 하나입니다. 독립 개발자 마이카 졸투(Micah Zoltu)는 이더 의 일부 활성 스마트 계약이 여전히 자체 파괴(selfdestruct) 명령어를 사용하고 있으며 이를 비활성화하면 기능이 손상될 것이라고 반복해서 말했습니다. 팀 베이코는 이러한 특별한 예외 사례에 대한 몇 가지 해결책이 있을 수 있으며, 이더 재단의 커뮤니티 지원이 더 필요할 것이라고 말했습니다.
2. EIP 1153 , 임시 저장소 명령어 추가: Uniswap 및 Optimism 팀의 대표는 이더 의 일반 저장소 명령어와 동일하게 동작하는 임시 저장소 명령어 도입에 대해 설득력 있는 주장을 펼쳤습니다. 다만 두 가지 새로운 명령어인 TLOAD와 TSTORE의 값은 각 트랜잭션 후에 삭제됩니다. Optimism의 마크 타인웨이가 설명했듯이, 일시적 저장에는 여러 가지 동기가 있는데, 그 중 하나는 가스 비용을 절약하는 것입니다. 유니스왑에서만 이 EIP는 사용자들이 연간 300만 달러의 가스 비용을 절감할 수 있는 잠재력을 가지고 있습니다. 또한 일반 저장소 대신 임시 저장소를 사용하면 이더 의 기술 채무 줄이는 데 도움이 됩니다. Uniswap과 Optimism 팀은 여러 다른 이더 소프트웨어 클라이언트에서 이 코드 변경을 구현하는 데 많은 노력을 대량 EIP에 대한 포괄적인 테스트 모음을 구축했습니다. Besu(EL) 클라이언트 팀의 Daniel Lehrner는 EIP 1153 구현을 준비하기 위해 외부 개발자에게 요청한 것에 대해 감사를 표했습니다. 그럼에도 불구하고 모든 개발자가 EIP 1153을 통합하는 데 따르는 추가 테스트 부하가 그만한 가치가 있다고 믿는 것은 아닙니다. Geth 개발자인 마리우스 반 더 바이덴은 EIP 1153이 EOF 관련 EIP의 진행 중인 준비를 방해하고 복잡한 문제를 야기할 수 있다고 경고했습니다. 그럼에도 불구하고 반 더 바이든은 코드 변경에 대한 테스트를 늘리는 것에 대해 "기다려보는 접근 방식"을 취하고 있다고 말했습니다. 개발자들은 Uniswap 및 Optimism 팀의 외부 개발자의 도움을 받아 이더리움 Shapella 업그레이드 에 EIP 1153을 포함하기 위한 테스트를 계속하기로 합의했습니다.
3. EIP 2537 , BLS 사전 컴파일 추가: 이더 Foundation의 Alex Stokes는 이더 에 BLS 사전 컴파일을 추가하는 이점을 소개했습니다. 스토크스는 여러 가지 이유에서 이러한 결정을 내렸는데, 그중에는 더 안전한 암호화 증명을 생성할 수 있는 능력, 이더 비콘 체인과의 더 나은 상호 운용성, 탈중앙화 스테이킹 풀의 추가 기능 등이 포함되었습니다. Van der Wijden은 BLS 사전 컴파일을 추가하는 것이 EOF 구현 및 EIP 1153보다 우선할 수도 있는 중요한 코드 변경이라는 데 동의합니다. 그러나 EIP 2537을 구현하는 데 필요한 대량 테스트로 인해 van der Wijden은 이 코드 변경을 추가하면 이더리움 Shapella 업그레이드 지연될 것이라는 우려를 표명했습니다. 이더 재단의 Jared Wasinger는 EIP 2537보다 더 간단한 구현 경로를 제공할 수 있는 병렬 EIP를 작업 중이라고 언급했습니다. 개발자들은 EIP 2537 작업을 진행하고 이더리움 Shapella 업그레이드 에 포함될 수 있도록 다양한 BLS 사전 컴파일의 수를 줄이기 시작하기로 합의했습니다.
4. EIP 2294 : 마지막으로, 구글의 소프트웨어 엔지니어인 자이난 빅터 저우가 EIP 2294를 소개했습니다. 이는 하드 포크 후 노드 검색을 돕는 데 전통적으로 사용되는 이더 의 체인 ID 필드의 바이트 크기를 제한하는 비교적 간단한 코드 변경입니다. 빅터 저우는 컨퍼런스 콜에서 이더 의 미래에 샤딩과 멀티체인 등장할 가능성이 있기 때문에 체인 ID의 사용 사례가 더욱 커지고 중요해질 것이라고 말했습니다. 사람들이 다른 유형의 데이터를 저장하여 체인 ID 필드를 악용하려는 것을 막기 위해, 빅터 저우는 체인 ID 크기에 대한 명시적 바인딩을 요구했습니다. 모든 개발자는 이 변경 사항이 중요하고 구현하기 쉽다는 데 동의했습니다. 마이카 졸투는 이러한 코드 변경에는 소프트 포크 만 필요하다고 강조했으며, 이는 이더 리움 클라이언트 팀이 변경 사항에 대한 특정 블록 높이를 조정하지 않고도 자체 타임라인에 맞춰 변경 사항을 구현할 수 있음을 의미합니다. 개발자들 사이에서는 호출이 끝날 때 체인 ID 크기를 64비트로 제한할지 256비트로 제한할지에 대한 논의도 있었습니다. 팀 베이코는 개발자들에게 오프라인에서 토론하고, 디스코드 채팅에서 비동기적으로 숫자를 처리하도록 격려했습니다.
이더리움 Shapella 업그레이드 에 포함될 EIP 목록이 계속해서 늘어나면서, 개발자들은 핵심 목록 외에 어떤 EIP를 우선적으로 포함해야 할지에 대해 의견이 엇갈리고 있습니다. "lightclient"라는 가명을 사용하는 이더 Foundation 개발자는 개방형 인출을 고수하고 프로토-댄크샤딩, EOF 구현 또는 콜에서 제기된 4가지 EIP 중 하나 등 다른 주요 EIP 하나만 우선시할 것을 제안했습니다. 팀 베이코는 다음 업그레이드에서 EOF 구현, 프로토 댄크샤딩, BLS 사전 컴파일, 임시 저장 명령어 추가 등을 모두 포함하는 것은 비현실적이라고 생각합니다. 미팅 시간이 부족했기 때문에, 베이코는 이더리움 Shapella 업그레이드 계획에 대한 논의를 꺼내고, 개발자들이 다음 ACD 콜에서 스테이킹 ETH 인출 외에 이더리움 Shapella 업그레이드 의 최우선 순위에 대해 논의할 준비를 하도록 격려했습니다.
이더 노드의 운영 비용을 줄이는 방법(검열 저항력 증가)은?
이더리움 Shapella 업그레이드 에 대한 토론 중, 독립 이더 개발자인 Micah Zoltu는 이더 검열 저항성과 관련된 중요한 논의 주제를 제기했습니다. Zoltu는 거의 대부분의 이더 사용자가 거래를 실행하기 위해 자체 노드를 실행하지 않으며, 사람들은 Infura나 Alchemy와 같은 중앙 집중형 서비스에 의존하는데, 이러한 서비스들은 특정 국가의 사용자를 적극적으로 검열하고 Tornado Cash와 같은 이더 의 탈중앙화 애플리케이션(dapp)을 검열한다고 설명했습니다. 개발자들이 EIP 4844를 통해 이더 의 확장성을 개선하기 위해 노력하고 있는 반면, 이더 노드 실행 비용을 줄이고 이더 검열 저항성에 대한 확신을 높이기 위한 노력은 부족했습니다. 이더 Teku(CL) 클라이언트 팀의 개발자인 Mikhail Kalinin은 EIP 4844 구현 후 이더 노드 실행 비용을 줄이는 데 집중할 것을 제안했습니다. Erigon의 Andrew Ashikhmin은 이더 개발자가 두 가지 모두에 집중할 수 있다고 생각합니다. 안스가르 디트리히는 실용적인 이유로 이더 개발자들은 단기적으로 확장성을 위해 검열 저항성을 희생해야 하고, 장기적으로는 검열 저항성에 집중해야 한다고 말했습니다.
이더 재단의 연구원인 단크라드 파이스트는 EIP 4844로 인해 노드 운영자의 운영 비용이 약간 증가하지만 이는 무시할 만한 수준이고 이더 의 검열 방지 기능에 실질적인 피해를 주지 않을 것으로 생각 관점 . Feist는 또한 대부분의 이더 사용자가 비용 때문이 아니라 사용자 경험이 좋지 않기 때문에 자체 노드를 실행하지 않는다고 덧붙였습니다. 디에데릭 뢰라커는 더 높은 수준의 탈중앙화 를 위해서는 확장성이 이더 개발자들의 우선순위가 되어야 한다고 말했습니다. EIP 4844와 같은 코드 변경으로 이더 사용 비용이 저렴해지고 전 세계 더 많은 사람들이 진입 장벽을 낮출 수 있기 때문입니다.
Nethermind EL 클라이언트 팀의 Lukasz Rozmej도 EIP 4844가 이더 의 검열 저항성에 부정적인 영향을 미칠지에 대해 의문을 제기했습니다. 많은 거래가 이론적으로 L2 롤업에서 실행될 것이기 때문입니다. Zoltu는 EIP 4844로 인해 앞으로 검증자가 개별 거래를 검열하기 어려워질 수 있지만, 현재 L2 롤업 작업은 중앙 집중화되어 검열이 가능하다고 설명했습니다. 토론을 마무리하며, 팀 베이코는 이더 노드를 운영하는 사용자 경험을 개선하는 것이 커뮤니티가 앞으로 집중해야 할 핵심 영역이 되어야 한다고 말했습니다. 베이코는 이더 핵심 개발자와 인접한 개발팀이 이더 노드 실행을 단순화하고 일반 사용자가 더 쉽게 접근할 수 있도록 해야 한다고 제안했습니다.
기타 잡다한 것
위에 언급한 사항 외에도 이더 개발자들이 이번 컨퍼런스 콜에서 아직 논의하지 않은 몇 가지 문제가 있습니다. 여기에는 다음이 포함됩니다.
- 엔진 API 사양 개선 제안 : Teku 개발자 Mikhail Kalinin이 이더 의 엔진 API 사양을 개선하기 위한 제안을 작성했습니다. 배경 설명으로, Engine API는 이더 노드의 EL과 CL 클라이언트 간의 쉬운 통신을 가능하게 하는 소프트웨어입니다. Engine API에 대해 제안된 변경 사항은 다음주 목요일에 열리는 이더 CL 회의에서 논의될 예정입니다.
- 상하이 "코어" 대 프로토타입 개발자 테스트넷 : 이더리움 Shapella 업그레이드 위한 EIP를 테스트하려면 여러 개의 전용 테스트 네트워크를 만들어야 합니다. 산둥은 이더 재단 자바스크립트 팀이 출시한 테스트 네트워크입니다. EOF 구현과 관련된 일부 EIP 외에도 EIP 4895, EIP 3860, EIP 3651 및 EIP 3855를 구현했습니다. 다음 몇 차례의 ACD 컨퍼런스 콜에서 개발자들은 클라이언트 팀이 이더리움 Shapella 업그레이드 EIP를 테스트할 수 있도록 보다 전담적인 테스트 네트워크를 만드는 작업을 조정할 것입니다.
- Ropsten 테스트넷 종료일 : 이더 테스트넷 Goerli를 유지 관리하는 개발자 중 한 명인 Afri Schoeden은 계획된 일정에 따라 이더 테스트넷을 출시하고 지원 중단을 제안했습니다. 이는 여러 이더 테스트 네트워크의 지원 중단에 대해 애플리케이션 개발자와 인프라 제공자가 표현한 정서 에 대한 대응입니다. 개발자들은 Ropsten과 같은 공개 이더 테스트넷을 책임감 있게 폐기하는 방법에 대한 아이디어를 이더 포럼 스레드에서 공유해 주시기 바랍니다.
