- 을 가져야 하며, 이는 병합되지 않은 풀 리퀘스트로 제출될 수 있습니다. 이는 EELS 팀이 업그레이드에 대한 최종 승인 권한을 갖는 것을 방지합니다.
- Fusaka 업그레이드 일정과 EIP EOF 포함 여부에 대한 논쟁이 논의되었으며, Geth 개발자들은 더 많은 유연성을 요구하고 있습니다.
- 일부 개발자들이 업그레이드 과정의 지연을 우려하며 EIP에 대한 필수 EELS 및 EEST 테스트에 대해 우려를 표명했습니다.
이더리움 개발자들은 다가오는 네트워크 업그레이드 일정을 최종 확정했습니다. 주요 변경 사항은 2월 24일, 3월 5일, 4월 8일에 이루어질 예정입니다. 주요 결정 사항은 2025년 2월 13일에 열린 최근 All Core Developers Execution (ACDE) Call 205에서 최종화되었습니다.
격주 Zoom 회의 회의 중 논의된 사항에는 스테이블코인의 미래가 포함되었습니다. 위원회는 은행이 지분의 50% 이상을 보유하여 결제용 디지털 화폐가 안정적이고 전통적인 금융 기관에 의해 뒷받침되도록 하는 스테이블코인 발행 모델을 제안했습니다. 는 이더리움 재단(EF) 프로토콜 지원 책임자 Tim Beiko가 이끌었습니다. 개발자들은 Pectra 업그레이드가 2월 24일 Holesky 테스트넷에서 활성화될 것이라고 확인했습니다. 이후 3월 5일에 Sepolia 테스트넷이 활성화됩니다.
두 롤아웃이 모두 원활하게 진행되면, 이더리움 메인넷은 4월 8일경 업그레이드를 받게 됩니다.
Beiko는 테스트넷 둘 모두에서 Pectra 시스템 계약을 배포할 자원자를 찾기 위해 팀들과 조정할 것이라고 말했습니다.
미래 이더리움 포크 및 업그레이드 속도에 대한 논쟁
또한 개발자 팀은 Pectra와 Fusaka 이후의 다음 계획된 업그레이드에 대해 논의했습니다. Beiko 제안했습니다 Pectra가 메인넷에서 출시될 때 Fusaka의 범위를 동결
했습니다. 이 일정은 개발자들이 Fusaka 작업을 시작하면서 동시에 후속 하드포크인 Glamsterdam을 계획할 수 있도록 합니다.
Geth 개발 팀은 이 일정으로 작업하기를 원하지 않습니다. 그들은 Fusaka 범위를 확정하는 것이 시기상조라고 주장합니다. 이더리움 개선 제안(EIP) EOF의 Fusaka 포함은 상당한 논쟁을 불러일으켰습니다. 개발자 파벌 중 일부는 다가오는 업그레이드에서 이를 제외해야 한다고 주장합니다.
EOF(이더리움 객체 형식)은 업그레이드를 따릅니다. 이더리움 블록체인에서 스마트 계약이 구조화되고 실행되는 방식을 개선
하기 위한 것입니다. Geth 개발자 Lightclient는 Fusaka 범위 동결을 가속화하는 것에 반대했습니다. 이 개발자는 이더리움의 우선순위가 향후 2년 동안 변경될 수 있다고 주장합니다. 그는 개발자들이 6개월 업그레이드 주기를 목표로 하지만, 실제 세계의 지연으로 인해 8개월 이상으로 늘어날 수 있다고 지적했습니다.
이는 중요한 개선 사항이 수년간 구현되지 않을 수 있음을 의미합니다.
Lightclient는 EOF의 통합에 대한 우려를 제기하며 이더리움의 영지식 롤업 기술(zkEVMs)의 빠른 진전을 강조했습니다. 개발자들은 이러한 변경 사항이 가상 머신과 어떻게 상호작용하는지에 대해 여전히 알지 못합니다.
토의 동안, Geth 개발자 Marius van der Wijden은 PeerDAS, FOCIL, EOF 및 modexp의 상한선을 포함하는 Fusaka에 대한 자신의 선호 범위를 나열했습니다. EF 개발 운영 엔지니어 Parithosh Jayanthi는 FOCIL이 PeerDAS와 EOF만큼 구현 준비가 되지 않았다고 반박했습니다.
Pectra 소프트웨어 테스트넷 업그레이드 및 커뮤니티 피드백 개발자들은 Fusaka에 대한 불일치를 넘어. Pectra 배포
에 대한 자신감을 표현했습니다.
EF 개발 및 운영 엔지니어 Parithosh Jayanthi는 Pectra Devnet 6가 거의 완벽한 검증자 참여율로 잘 수행되고 있다고 보고했습니다. GitHub. 또한 이더리움의 Ephemery 테스트넷은 ACDE 통화 몇 시간 후 Pectra 업그레이드를 활성화하여 개발자들이 추가 테스트를 수행할 수 있도록 했습니다.
Beiko는 Pectra EIP 저자들에게 그들의 제안을
Beiko의 제안 Fusaka 범위 최종 확정 일정에 따르면, 3월 13일까지 개발자는 업그레이드에 포함될 EIP를 제안해야 합니다. 2주 후인 3월 27일, 클라이언트 팀은 Fusaka를 위해 고려해야 할 EIP에 대한 선호도를 공유합니다. 마지막으로, 4월 10일까지 업그레이드 범위가 최종 확정됩니다.
최종 호출(last call) 단계로 이동
하도록 요청했습니다. 이는 메인넷 구현 전의 최종 단계를 신호합니다. 그는 또한 이더리움 커뮤니티의 피드백을 조사했습니다. 이를 위해 그는 가장 일반적인 요청이 업그레이드 주기를 가속화하는 것이라고 언급했습니다.
이에 대해 그는 이더리움 개발자들이 이전 업그레이드가 메인넷에서 가동되는 즉시 각 업그레이드의 범위를 최종화하는 것을 목표로 해야 한다고 제안했습니다.
그러나 EF 연구원 Ansgar Dietrichs는 타이밍에 대한 예외를 추가했습니다. 그는 Pectra 업그레이드의 핵심 구성 요소인 PeerDAS 코드 개선 사항이 완료되는 즉시 이더리움 메인넷에 업로드되어야 한다고 언급했습니다. 이 요구 사항에 반대하는 사람은 없었습니다.
EELS 및 EIP 테스트 표준에 대한 우려
ACDE 통화 동안 또 다른 우려 사항은 EF 테스트 엔지니어 Mario Vega의 제안이었습니다. 이는 이더리움 실행 계층 테스트 프레임워크와 관련이 있었습니다. Vega는 하드 포크에 포함되는 모든 EIP에 EELS(이더리움 실행 계층 사양)와 EEST(이더리움 실행 사양 테스트 케이스)를 의무화할 것을 제안했습니다. 그는 이것이 테스트 워크플로우를 개선하고 채택 전 EIP가 평가되는 방식을 표준화할 것이라고 제안했습니다. 그러나 여러 개발자들이 이 제안에 반대했습니다. 이유는 무엇일까요? 이 요구 사항이 업그레이드 과정을 늦출 수 있기 때문입니다. Van der Wijden은 EELS 유지 관리자들이 EIP 포함의 사실상 관문 지킴이가 될 수 있다고 주장했습니다. 왜냐하면 모든 개발자가 자신의 제안에 대한 Python 기반 구현을 작성할 수 있는 것은 아니기 때문입니다.
Wijden은 대안 접근 방식을 제안했습니다. ETH는 이더리움 EELS 구현
암호화폐 뉴스를 단순히 읽는 것을 넘어, 이해하세요. 뉴스레터에 구독하세요. 무료입니다.
면책 조항. 제공된 정보는 투자 조언이 아닙니다. Cryptopolitan.com 본 페이지에 제공된 정보를 바탕으로 이루어진 투자에 대해 어떠한 책임도 지지 않습니다. 투자 결정을 내리기 전에 반드시 독립적인 조사나 자격을 갖춘 전문가의 상담을 강력히 권장합니다.
플로렌스 무차이
플로렌스는 지난 6년 동안 암호화폐, 게임, 기술 및 AI 뉴스를 다루어 왔습니다. 메루 과학기술대학교에서 컴퓨터학을, MMUST에서 재난 관리 및 국제 외교를 전공하며 언어, 관찰력 및 기술적 역량을 충분히 갖추었습니다. 플로렌스는 VAP 그룹에서 근무했으며 여러 암호화폐 미디어 하우스의 편집자로 활동했습니다.
