[블록미디어 명정선 기자] 이더리움 프로토콜 개발자들이 13일(현지시간) 줌(Zoom)을 통해 ‘All Core Developers Execution(Call #205)’ 회의를 열고 퍼블릭 테스트넷 업그레이드 일정과 다음 업그레이드 ‘퓨사카(Fusaka)’의 범위 확정 방안을 논의했다.
이날 회의에서 개발자들은 이더리움 퍼블릭 테스트넷인 홀레스키(Holesky)와 세폴리아(Sepolia)에 ‘펙트라(Pectra)’ 업그레이드를 각각 2월 24일과 3월 5일에 적용하는 일정을 확인했다.
또한, ‘펙트라’가 메인넷에 적용되기 전까지 ‘퓨사카’ 업그레이드의 범위를 확정하자는 팀 베이코(Tim Beiko)의 제안이 나왔으나, 게스(Geth) 개발자들은 시간적 촉박함과 ‘EOF’를 포함하는 것에 대한 반대 입장을 밝혔다.
#’펙트라’ 개발 순항…퍼블릭 테스트넷 준비 완료
이더리움 재단의 파리토쉬 자얀티(Parithosh Jayanthi)는 ‘펙트라’ 개발 네트워크 상태가 양호하며 검증자 참여율이 매우 높다고 보고했다. 각 클라이언트 팀들은 퍼블릭 테스트넷 업그레이드 준비가 완료됐음을 확인했으며, 2월 13일 회의 후 에페메리(Ephemery) 테스트넷에도 ‘펙트라’가 적용될 예정이다. 베이코는 ‘펙트라’ 관련 EIP 작성자들에게 깃허브(GitHub)에서 ‘마지막 호출(last call)’ 단계로 이동할 것을 요청했다.
#’퓨사카’ 범위 확정, 개발자 의견 엇갈려
게스 개발자 마리우스 반 데르 와이든(Marius van der Wijden)은 ‘퓨사카’에 △PeerDAS △FOCIL △EOF △modexp 상한 설정 EIP만 포함하자는 의견을 냈으나, 자얀티는 FOCIL의 준비도가 낮다고 지적했다. FOCIL은 ‘Fork-Choice Improvements Layer’의 약자로, 이더리움 블록체인에서 어떤 블록이 최종적으로 선택될지를 결정하는 ‘포크 선택 규칙’을 개선하려는 기술을 뜻한다.
이더리움 테스트 엔지니어 마리오 베가(Mario Vega)는 EIP 테스트 워크플로 개선을 위해 EELS와 EEST를 필수 요건으로 포함하는 제안을 했다. 그러나 게스 개발자들은 이 제안이 EELS 팀의 과도한 권한을 초래할 수 있다고 우려했다. EELS는 이더리움 실행 레이어의 코드 명세를 다루는 팀인데, 이 팀이 EIP를 테스트하고 승인하는 역할까지 맡게 되면 특정 제안이 이 팀의 의사에 따라 좌우될 가능성이 있다는 걱정이 나온 것이다.
#’펙트라’ 회고와 빠른 업그레이드 필요성
‘펙트라’ 회고 포럼에서 가장 많이 언급된 개선 사항은 업그레이드 주기의 단축이었다. 베이코는 ‘펙트라’가 메인넷에 적용된 후 바로 ‘퓨사카’ 범위를 확정하고, ‘글램스터담(Glamsterdam)’ 업그레이드 논의를 병행할 것을 제안했다.
하지만 게스 개발자 라이트클라이언트(Lightclient)는 ‘퓨사카’ 범위 확정이 시기상조라고 반박했다. 베이코는 개발자들에게 4월 10일까지 ‘퓨사카’ 범위를 확정하는 일정을 제시하며, 3월 13일까지 EIP 제안, 3월 27일까지 각 클라이언트 팀의 의견 공유를 요청했다.
#EOF 포함 여부 놓고 개발자 의견 분분
EOF 포함 여부를 두고도 개발자들의 의견이 엇갈렸다. EOF는 ‘EVM Object Format’의 약자로, 이더리움 가상머신(EVM)에서 스마트 컨트랙트를 더 안전하고 효율적으로 관리하기 위한 새로운 표준으로 스마트 컨트랙트를 보다 쉽게 개선하고 오류를 방지할 수 있게 도와준다.
하지만 개발자들은 이게 지금 꼭 필요한지 의견이 엇갈리고 있다. 게스 팀 일부는 EOF 포함에 반대했으나, 독립 개발자들은 EOF가 향후 EVM 개선의 기반이 될 것이라고 주장했다. 이와 관련 베이코는 EOF가 ‘PeerDAS’ 적용을 1개월 이상 지연시킬 경우 재논의할 수 있다고 밝혔다.
#이더리움 검증자 요건 논의
이더리움 재단 케본드레이 웨더번(Kevaundray Wedderburn)은 검증자가 블록에 포함할 최대 블롭(blob) 수를 설정할 수 있는 기능을 제안했으며, 롤업(rollup) 팀들도 이 기능을 긍정적으로 평가했다. 이에 대한 추가 논의는 다음 회의에서 이어질 예정이다.
같이 보면 좋은 기사
