옵티미즘(OP) 거버넌스가 OP 스택의 결함 증명 방식을 'Output Root'에서 'Super Root' 기반으로 바꾸는 업그레이드20을 승인했다. 다만 거버넌스 승인이 메인넷 계약 실행이나 상호운용성 활성화를 의미하는 것은 아니다.
옵티미즘 Agora는 업그레이드20을 9월 16일 오후 9시26분 한국시간 기준 'SUCCEEDED'로 표시했다. 반대 표는 7만1701 OP로, 거부에 필요한 투표 가능 물량 20%보다 낮은 0.13%였다. 이번 제안은 반대 표가 기준을 넘지 않으면 통과되는 '낙관적 승인' 방식으로 처리됐다.
공식 거버넌스 제안문은 업그레이드20이 OP 스택 체인의 L1 스마트계약을 바꾸는 업그레이드라고 설명했다. L2 하드포크나 합의 수준의 활성화 시점은 포함하지 않으며, 변경 사항은 서명된 superchain-ops 실행을 통해 L1에서 전달된다.
핵심 변화는 결함 증명 게임이 상태를 확인하는 기준이다. 기존 Output Root Dispute Game은 특정 L2 블록 번호에 대응하는 상태를 검증했지만, Super Root Dispute Game은 블록 번호 대신 타임스탬프를 기준으로 슈퍼 루트의 상태 전이를 검증한다.
OP 스택 사양은 새 게임에서 잘못된 제안 시각이 슈퍼 루트 상태 전이 과정에서 무효화된다고 설명한다. 이에 따라 잘못된 L2 블록 번호를 별도로 도전하는 절차는 사라진다.
새 게임 유형으로는 SUPER_PERMISSIONED와 SUPER_CANNON_KONA가 도입된다. 각각 게임 유형 5와 9에 해당하며, 기존 PERMISSIONED_CANNON과 CANNON_KONA 구현은 교체된다. 분쟁 게임을 직접 연동한 개발자는 새 유형과 rootClaimByChainId를 인식하도록 도구를 점검해야 한다.
이번 변경은 향후 OP 스택 체인 간 상호운용성을 위한 사전 조건이다. 여러 체인의 상태를 같은 시점에 묶어 검증할 수 있는 형식을 마련하는 것이 목적이지만, 업그레이드20 자체가 체인 간 자산 이동이나 데이터 교환을 시작하는 것은 아니다.
공식 제안문은 각 체인이 자체 AnchorStateRegistry와 DisputeGameFactory를 유지한다고 밝혔다. 이번 단계의 분쟁 게임도 단일 체인의 상태를 다루기 때문에, 여러 체인의 분쟁 인프라가 하나로 통합되는 절차와는 구분된다.
업그레이드에는 OPCM v8.0.0의 업그레이드 순서 검증과 프록시별 ProxyAdmin·SystemConfig 처리도 포함된다. 초기화 슬롯 재사용을 막고 일부 SystemConfig 기능을 제거하는 유지보수 항목도 함께 진행된다.
SystemConfig.batchInbox()와 기존 setGasConfig(uint256,uint256) 호출은 업그레이드 뒤 되돌려질 수 있다. 해당 기능을 사용하는 개발자 도구는 계약 변경 이후의 호환성을 점검해야 한다.
일반 사용자는 별도 조치를 취할 필요가 없다. 공식 제안문은 업그레이드20 이전에 제출된 출금 증명이 계속 유효하고, 기존 Output Root 게임도 계속 해결된다고 설명했다.
반면 체인 운영자와 관련 개발자는 새 결함 증명 방식에 맞춰 소프트웨어를 조정해야 한다. viem/op-stack 사용자는 viem 2.51.0 이상을 사용하고, 출금 증명 과정에서 L2 블록 번호 대신 출금 시점의 타임스탬프를 적용해야 한다.
9월 24일 메인넷 적용은 거버넌스 승인과 세폴리아 테스트넷의 7일 검증을 전제로 한 목표 일정이다. 4개 테스트넷에서 검증한 뒤 메인넷 적용을 추진하는 조건부 일정으로 제시됐으며, 공식 제안문은 해당 날짜를 확정 완료일로 명시하지 않았다.
PGov는 업그레이드20이 상호운용성을 즉시 활성화하지 않으면서도 결함 증명 형식을 먼저 전환한다는 점을 들어 찬성 입장을 밝혔다. 반면 실제 메인넷 실행 여부와 운영 환경에서의 호환성은 계약 실행과 후속 점검을 통해 확인해야 한다.
업그레이드20은 옵티미즘의 상호운용성 로드맵에서 검증 인프라를 먼저 바꾸는 단계다. 거버넌스 승인은 끝났지만, 메인넷 적용은 별도의 L1 계약 실행 절차와 운영 환경 검증을 거쳐 진행될 예정이다.


서지우 기자
댓글0
첫 댓글을 남겨 보세요.