BTC
ETH
HTX
SOL
BNB
시장 동향 보기
简中
繁中
English
日本語
한국어
ภาษาไทย
Tiếng Việt

하나의 기사에서 이더리움 상하이 업그레이드의 잠재적인 업데이트에 대해 알아보십시오.

DeFi之道
特邀专栏作者
이 기사는 약 4721자로, 전체를 읽는 데 약 7분이 소요됩니다
오픈 스테이킹 출금 확인, EIP-4844‌ 등 아직 보류 중
AI 요약
펼치기
오픈 스테이킹 출금 확인, EIP-4844‌ 등 아직 보류 중

원래 제목: "Ethereum All Core Developers Call #149 Writeup》

저자: 크리스틴 김

원문 편집: 하룻밤죽

원래 제목: "

저자: 크리스틴 김

2022년 11월 10일, 이더리움 개발자들이 모여 제149차 ACD(All Core Developers) 컨퍼런스 콜을 진행했습니다. 병합된 이더리움 네트워크(상하이라고 함)의 첫 번째 주요 업그레이드. 이 통화 중에 개발자는 상하이 업그레이드에 포함될 수 있는 4개의 다른 EIP에 대해서도 논의했습니다. 각 제안은 이더리움에 몇 가지 고유한 장점과 이점을 제공하지만, 어떤 EIP를 우선적으로 포함해야 하는지에 대해 개발자들 사이에는 여전히 상당한 논쟁이 있습니다. 상하이 업그레이드에 대한 논의 외에도 개발자들은 검열 저항이라는 주제와 네트워크 확장성에 대한 이더리움의 검열 저항 기능의 잠재적 트레이드 오프에 대해 간략하게 언급했습니다.여기상하이 업그레이드 계획

이전 ACD 통화에서 이더리움 개발자들은 상하이 업그레이드에 핵심 EIP 목록을 포함하는 데 동의했습니다. ACD Call #148의 전체 통화 기록은 다음 위치에 있습니다.

여기

. 이 핵심 EIP 목록에서 개발자는 약정된 ETH 인출 제안을 상하이 업그레이드에 포함하는 데 동의했지만 후자의 두 제안이 나올 때까지 동일한 업그레이드에 EOF 또는 proto-danksharding을 포함하기로 약속하지 않았습니다. 더욱 구체화되었습니다. 특히 EOF 주제에 대해 개발자들은 상하이 업그레이드의 EIP 부분 중 작은 부분을 통해 EOF를 구현할지 아니면 상하이 이후의 이더리움 업그레이드에 EOF의 전체 비전을 묶을지 고민해 왔습니다.

Proto-danksharding

EOF 구현EIP 4844Hedera의 수석 소프트웨어 엔지니어인 Danno Ferrin은 이번 주 컨퍼런스 콜에서 상하이의 EOF 구현 진행 상황에 대한 업데이트를 제공했습니다. 그는 개발자들이 EOF 구현과 관련된 대부분의 EIP를 가능한 한 빨리 하나의 대규모 업그레이드로 묶는 경향이 있다고 설명했습니다. 상하이 업그레이드에서 개발자들이 고려한 EOF 구현과 관련된 EIP는 EIP 3540, EIP 3670, EIP 4200 및 EIP 4750입니다. EIP 5450이 EOF와 관련된 코드 변경 목록에 포함되어야 하는지에 대해 개발자들 사이에 여전히 의견이 분분합니다.GithubErigon Execution Layer(EL) 클라이언트 팀의 Andrew Ashikhmin도 Solidity 스마트 계약 언어 팀이 4개(또는 5개) EIP를 모두 완벽하게 지원하고 구현할 수 있을지에 대한 우려를 표명했습니다. Ashikhmin은 상하이에서 이러한 EIP를 업그레이드하고 활성화하기 전에 먼저 Solidity 팀이 이러한 EIP를 구현할 준비가 되었는지 확인해야 한다고 강조했습니다. Ashikhmin은 전화 통화에서 Geth EL 클라이언트 팀의 Marius van der Wijden이 반향한 "필요한 건전성 검사"라고 말했습니다.

그런 다음 개발자들은 proto-danksharding의 최신 개발에 대해 논의했습니다. EOF 구현과 달리 단 하나의 EIP만 proto-danksharding 코드 변경과 연결됩니다.

. OP Labs의 연구원인 Diederik Loerakker(종종 "Protolambda"라고 함)에 따르면 EIP 4844와 관련하여 여전히 논의 중인 몇 가지 문제가 있습니다. Ethereum Foundation의 Ansgar Dietrichs는 이러한 문제 중 일부는 blob 트랜잭션의 최소 가격을 설정하고 상하이 업그레이드를 위한 blob 트랜잭션 처리량을 줄이는 것과 관련이 있다고 덧붙였습니다. 이 할일은

1、EIP 4758요약이 있습니다.

2、EIP 1153자체 파괴 opcode 및 기타 잠재적 EIP 비활성화

3、EIP 2537개발자가 상하이 업그레이드를 위한 EOF 및 proto-danksharding 작업을 준비하는 동안 개발자는 이더리움의 다음 업그레이드에 포함하기 위해 다른 4개의 EIP 작업을 계속하기로 잠정적으로 동의했습니다.

4、EIP 2294, 이더리움에서 'selfdestruct' opcode 비활성화: 개발자는 개발자가 스마트 계약 및 분산 응용 프로그램(dapps)에서 유용하다고 널리 간주하는 opcode 비활성화에 대한 마지막 ACD 통화에서 대화를 다시 방문합니다. 이 opcode는 배포하는 데 고정된 가스 비용이 있지만 잠재적으로 네트워크에 대한 스토리지 비용이 무제한인 몇 안 되는 레거시 opcode 중 하나입니다. 독립 개발자 Micah Zoltu는 이더리움의 일부 활성 스마트 계약이 여전히 selfdestruct opcode를 사용하고 있으며 이를 비활성화하면 기능이 중단될 것이라고 반복했습니다. 팀 베이코(Tim Beiko)는 이러한 특수한 사례의 경우 몇 가지 해결 방법과 이더리움 재단(Ethereum Foundation)의 더 많은 커뮤니티 지원이 있을 수 있다고 말했습니다.

, Ephemeral Storage Opcode 추가: Uniswap 및 Optimism 팀의 대표는 이 두 가지 새로운 opcode를 제외하고 Ethereum의 일반 스토리지 opcode와 동일하게 작동하는 임시 스토리지 opcode를 도입하기 위해 강력한 사례를 만들었습니다. TLOAD 및 TSTORE의 값은 각 거래 후 폐기됩니다. 임시 저장에 대한 많은 동기가 있으며 Optimism의 Mark Tyneway가 설명한 것처럼 그 중 하나는 가스 비용을 절약하는 것입니다. Uniswap에서만 이 EIP는 사용자에게 연간 가스 비용 300만 달러를 절약할 수 있는 잠재력이 있습니다. 또한 일반 저장소 대신 임시 저장소를 사용하면 이더리움의 기술적 부채를 줄이는 데 도움이 됩니다. 유니스왑과 옵티미즘 팀은 여러 다른 이더리움 소프트웨어 클라이언트에서 이 코드 변경의 구현을 만들고 EIP를 위한 포괄적인 테스트 스위트를 구축하는 데 도움을 주기 위해 많은 작업을 수행했습니다. Besu(EL) 클라이언트 팀의 Daniel Lehrner는 EIP 1153 구현을 준비하라는 외부 개발자의 요청에 감사를 표했습니다. 그럼에도 불구하고 모든 개발자가 EIP 1153을 통합하는 추가 테스트 부하가 가치가 있다고 생각하는 것은 아닙니다. Geth 개발자 Marius van der Wijden은 EIP 1153이 EOF 관련 EIP에 대한 진행 중인 준비를 방해하고 합병증을 유발할 수 있다고 경고했습니다. 그럼에도 불구하고 van der Wijden은 코드 변경에 대한 테스트 노력을 늘리는 것에 대해 "기다려보고 있다"고 말했습니다. 개발자들은 상하이 업그레이드에 포함하기 위해 Uniswap 및 Optimism 팀의 외부 개발자의 도움을 받아 EIP 1153을 계속 테스트하기로 합의했습니다.

, BLS 사전 컴파일 추가: 이더리움 재단의 Alex Stokes는 BLS 사전 컴파일을 이더리움에 추가하는 이점을 설명합니다. 여기에는 더 안전한 암호화 증명을 생성할 수 있는 능력, 이더리움 비콘 체인과의 더 나은 상호 운용성, 분산된 스테이킹 풀의 추가된 기능 등 여러 가지 이유가 있다고 Stokes는 설명했습니다. Van der Wijden은 BLS 사전 컴파일 추가가 EOF 구현 및 EIP 1153보다 우선할 수 있는 중요한 코드 변경이라는 데 동의합니다. 그러나 EIP 2537을 구현하는 데 필요한 광범위한 테스트로 인해 van der Wijden은 이 코드 변경을 추가하면 상하이의 업그레이드가 지연될 것이라는 우려를 표명했습니다. Ethereum Foundation의 Jared Wasinger는 EIP 2537보다 더 간단한 구현 경로를 제공할 수 있는 병렬 EIP를 작업 중이라고 언급했습니다. 개발자들은 EIP 2537 작업에 동의하고 상하이 업그레이드를 통합할 수 있도록 다양한 BLS 사전 컴파일 수를 줄이기 시작했습니다.

: 마지막으로 Google의 소프트웨어 엔지니어인 Zainan Victor Zhou는 EIP 2294를 소개했는데, 코드 변경이 비교적 간단하지만 단순히 하드포크 후 노드 탐색을 돕기 위해 전통적으로 사용되는 이더리움의 체인 ID 필드의 바이트 크기를 제한하는 것입니다. Victor Zhou는 컨퍼런스 콜에서 향후 이더리움의 샤딩 및 다중 체인 가능성으로 인해 체인 ID의 사용 사례가 더 커지고 중요해질 것이라고 말했습니다. 사람들이 체인 ID 필드에 다른 유형의 데이터를 저장하여 체인 ID 필드를 악용하지 못하도록 하기 위해 Victor Zhou는 체인 ID 크기에 대한 명시적 바인딩을 요청했습니다. 모든 개발자는 이 변경 사항이 중요하고 구현하기 쉽다는 데 동의합니다. Micah Zoltu는 이러한 코드 변경에는 소프트 포크만 필요하며, 이는 이더리움 클라이언트 팀이 변경을 위한 특정 블록 높이를 조정할 필요 없이 자체 타임라인에 변경 사항을 구현할 수 있음을 의미한다고 강조했습니다. 또한 통화가 끝날 때 체인 ID 크기를 64비트 또는 256비트로 제한할지 여부에 대해 개발자들 사이에서 약간의 논의가 있었습니다. Tim Beiko는 개발자가 오프라인에서 토론하고 Discord 채팅에서 비동기적으로 숫자를 계산하도록 권장합니다.

상하이 업그레이드에 포함될 예정인 EIP의 증가하는 목록에 따라 개발자는 핵심 목록 외부에 포함하기 위해 우선 순위를 지정할 EIP로 나뉩니다. "lightclient"라는 가명의 이더리움 재단 개발자는 개방형 인출을 고수하고 다른 주요 EIP(proto-danksharding, EOF 구현 또는 통화에서 제안된 4개 중 하나)에만 우선 순위를 지정할 것을 제안했습니다. Tim Beiko는 다음 업그레이드에서 EOF 구현, proto-danksharding, BLS 사전 컴파일 및 임시 스토리지 opcode 추가를 번들로 시도하는 것은 비현실적이라고 생각합니다. 회의 시간 부족으로 인해 Beiko는 상하이 업그레이드 계획에 대한 논의를 시작했으며 개발자들에게 다음 ACD 컨퍼런스 콜에서 약정된 ETH 인출 외에 상하이 업그레이드의 최우선 순위에 대해 논의할 준비를 하도록 독려했습니다.

Ethereum 노드의 운영 비용을 줄이는 방법(검열 저항력 증가)은 무엇입니까?

상하이 업그레이드에 대한 이야기에서 독립적인 이더리움 개발자인 Micah Zoltu는 이더리움의 검열 저항에 관한 중요한 토론 항목을 가져왔습니다. 거래를 실행하기 위해 자체 노드를 실행하는 이더리움 사용자는 거의 없으며 사람들은 특정 국가의 사용자를 적극적으로 검열하고 Tornado Cash와 같은 이더리움 애플리케이션(dapps)의 탈중앙화를 검열하는 Infura 또는 Alchemy와 같은 중앙 집중식 서비스에 의존한다고 Zoltu는 설명했습니다. 개발자들이 EIP 4844를 통해 이더리움의 확장성을 개선하기 위해 노력하고 있지만, 이더리움 노드 운영 비용을 줄이고 이더리움의 검열 저항에 대한 더 큰 확신을 장려하기 위한 노력은 부족했습니다. Ethereum Teku(CL) 클라이언트 팀의 개발자인 Mikhail Kalinin은 EIP 4844 구현 후 Ethereum 노드 실행 비용을 줄이는 데 집중할 것을 제안했습니다. Erigon의 Andrew Ashikhmin은 Ethereum 개발자가 동시에 두 가지에 집중할 수 있다고 믿습니다. 그리고 Ansgar Dietrichs는 실용적인 이유로 이더리움 개발자들이 단기적으로 확장성을 위해 검열 저항을 희생하고 장기적으로 검열 저항에 집중해야 한다고 말했습니다.

이더리움 재단의 연구원 Dankrad Feist의 견해는 EIP 4844가 노드 운영자의 운영 비용을 미미하게 증가시키고 이더리움의 검열 방지 특성에 상당한 피해를 입히지 않을 것이라는 것입니다. Feist는 또한 대부분의 이더리움 사용자가 비용 때문이 아니라 열악한 사용자 경험 때문에 자체 노드를 실행하지 않는다고 덧붙였습니다. Diederik Loerakker는 EIP 4844와 같은 코드 변경으로 인해 이더리움이 사용하는 데 더 저렴하고 전 세계 더 많은 사람들이 더 쉽게 접근할 수 있기 때문에 더 높은 수준의 분산화를 만들기 위해서는 확장이 이더리움 개발자에게 우선 순위가 되어야 한다고 말했습니다. 기입.


ETH
Odaily 공식 커뮤니티에 가입하세요