
Lumoz, Etrog 대규모 업그레이드 완료

Etrog 업그레이드 개요
Polygon CDK 생태계 내의 중요한 구성 요소로서 Lumoz는 Polygon CDK의 모든 업그레이드를 주목하며 여러 차례 조사와 개발, 최적화를 진행해 왔으며, 그 배경에 있는 기술적 세부 사항을 일반 대중이 이해하기 쉬운 방식으로 해설해 왔습니다. 이를 통해 CDK Validium 초기 버전에서 Etrog 버전으로의 업그레이드 경로를 포괄적으로 정리하고 보완함으로써, Polygon CDK는 물론 블록체인 산업 전반의 발전 가능성을 효과적으로 확장하고자 합니다.
폴리곤 zkEVM의 Etrog 업그레이는 2024년 2월에 완료되었습니다. 이 업그레이는 폴리곤 zkEVM이 메인넷에 출시된 이후 가장 중대한 업그레이드로, 하위 회로층에서 여러 사전 컴파일된 스마트 계약을 지원하게 되었으며, 체인 자체의 트랜잭션 패키징 및 블록 생성 메커니즘을 최적화하고, 전체 스마트 계약 아키텍처를 재구성함으로써 향후 Polygon CDK 생태계 및 AggLayer, Unified Bridge 등 새로운 기능들을 위한 기반을 마련했습니다. 전반적으로 이번 업데이트는 폴리곤 zkEVM과 이더리움 간의 호환성을 향상시키고, 노드의 실행 및 조회 효율성을 크게 개선했으며, Polygon CDK 생태계의 가능성 또한 넓혔습니다.
본 문서는 폴리곤 zkEVM의 스마트 계약과 노드 코드 관점에서 이번 업그레이드의 기술적 세부 사항을 심층적으로 분석하며, 오픈소스 Rollup 업그레이드 솔루션을 기반으로 CDK Validium 초기 버전에서 Etrog 버전으로의 업그레이드 경로를 포괄적으로 정리하고 보완합니다.
스마트 계약 재구성
Etrog 업그레이드 이전, 폴리곤 zkEVM의 스마트 계약은 주로 합의 계약(Consensus Contract)과 브리지 계약(Bridge Contract) 두 부분으로 구성되어 있었습니다.
합의 계약
합의 계약은 체인 ID, 버전 등의 기본 정보와 함께 배치(batch), 증명 제출 기록 등 레이어 2 체인의 실시간 상태 정보를 포함하여 대부분의 정보를 기록합니다. 또한 Validium의 경우, 배치 내 원래 트랜잭션 데이터는 합의 계약에 기록되지 않고, 별도의 committee 계약을 통해 오프체인 DA(데이터 가용성) 노드 그룹 내에서 저장됩니다. 이러한 기본 정보와 실시간 상태 정보를 결합함으로써 누구든지 레이어 2 체인의 상태를 완전히 복원할 수 있습니다.
브리지 계약
다른 한편으로, 브리지 계약은 일련의 출금 루트(exit root) 상태를 관리하여 레이어 1과 레이어 2 사이의 모든 크로스체인 상태를 기록하며, Lock/Mint 방식을 통해 두 레이어 간 자산 이동을 수행합니다. 출금 루트의 하위 노드는 브리지 계약과 합의 계약이 공동으로 업데이트하며, 전자는 레이어 1에서 레이어 2로의 입금(deposit) 트랜잭션 상태를 관리하고, 후자는 ZK 증명 제출을 통해 레이어 2에서 레이어 1로의 출금(withdraw) 상태를 관리합니다.
Etrog 업그레이드가 스마트 계약 층에서 가져온 가장 큰 변화는 다중 네트워크 솔루션을 도입하여, 기존의 단일 레이어 2 네트워크 관리에서 벗어나 하나의 계약 세트로 여러 레이어 2 네트워크를 관리·유지하는 것을 가능하게 한 것입니다. 동시에 새로 도입된 Unified Bridge를 활용해 이러한 레이어 2 네트워크 간의 자산 상호 운용성을 구현하였으며, 전체 생태계의 미래 발전을 위한 더 나은 기반을 마련했습니다.
기존의 계약 구조는 다중 네트워크 배포를 지원하지 않았기 때문에, Etrog 업그레이는 전체 계약 구조를 재구성하였습니다.
-
모든 레이어 2 네트워크 정보를 관리하는 RollupManager 계약을 도입;
-
브리지 계약과 GlobalExitRoot의 구조를 수정하여 모든 네트워크의 크로스체인 상태를 유지할 수 있도록 하여, 서로 다른 레이어 2 네트워크 간의 자산 상호 운용성을 보장.
Etrog 버전 미만에서 실행 중인 폴리곤 zkEVM 레이어 2 네트워크의 경우, 이러한 수정은 계약 데이터에 큰 파괴성을 가지므로 해당 업그레이드 솔루션은 작은 과제가 아닙니다. 본 문서에서는 여전히 합의 계약과 브리지 계약 두 부분으로 나누어 업그레이드 솔루션의 구체적인 세부 사항을 각각 상세히 설명합니다.
합의 계약
Etrog 업그레이드에서 합의 계약 부분의 가장 큰 변경점은全新한 RollupManager 계약의 도입입니다. 새 버전에서 권한 관리 등 대부분의 계약 관련 작업이 새로 도입된 RollupManager 계약에 집중되기 때문에, 폴리곤 공식 업그레이드 계획에서는 기존의 폴리곤 zkEVM 프록시 구현을 RollupManager 계약으로 업데이트하고, 새로 배포된 서브 네트워크 계약인 PolygonZkEVMExistentEtrog를 기존 네트워크의 새로운 합의 계약으로 사용합니다. 그리고 새로운 RollupManager 계약의 초기화 호출 시 롤업 네트워크의 전역 정보를 기록합니다. 이 PolygonZkEVMExistentEtrog는 Etrog 업그레이드 이후 일반적인 레이어 2 네트워크 계약인 PolygonZkEVMEtrog보다 업그레이드 과정 중 전환 로직을 위해 initializeUpgrade 메서드를 추가로 구현하고 있습니다.
업그레이드 후 프록시 계약 변수의 슬롯(slot)을 일치시키기 위해 RollupManager는 기존 버전 변수를 저장하기 위한 전용 LegacyZKEVMStateVariables 계약을 상속받습니다. 반면, 업그레이드 전후의 배치 상태 일관성을 보장하기 위해 RollupManager는 초기화 시 일련의 작업을 수행하여 기존 데이터를 새 계약에 다시 할당하고, 업그레이드 후 규칙에 따라 레이어 1에서 forcedBatch를 생성하여 Etrog 업그레이드의 전환 배치로 노드가 처리하도록 합니다.
브리지 계약
Etrog 업그레이는 브리지 계약에 맞춤형 가스 토큰 기능을 제공했으며, globalExitRoot 생성 방식도 수정하여 기존 데이터 일관성을 유지하면서 여러 레이어 2 체인의 출금 루트 업데이트를 지원함으로써 다수의 레이어 2 간 자산 상호 운용성을 실현했습니다.
노드 업데이트
노드 측면에서 Etrog 업그레이는 주로 sequencer와 synchronizer 모듈을 업데이트하였으며, 새 버전의 계약과 상호작용하기 위해 계약 ABI도 업데이트했습니다.
sequencer 모듈
-
이번 업그레이는 블록과 배치의 패키징 로직을 수정했습니다. Etrog 이전에는 각 레이어 2 블록이 단 하나의 트랜잭션만 포함했으며, 블록 시간과 해당 배치 시간이 동일했습니다. 이러한 설계는 이더리움 모델과 차이가 크며, 체인 상 애플리케이션 입장에서는 블록을 기준으로 트랜잭션을 탐색하는 일반적인 로직과 매우 호환되지 않았습니다. 따라서 Etrog 업그레이드 후 레이어 2 블록의 패키징 로직이 조정되었으며, 고정된 시간 간격으로 블록을 생성하고, 하나의 블록이 여러 트랜잭션을 포함할 수 있게 되어 기존 버전의 호환성 문제를 해결했습니다.
-
synchronizer 모듈
Etrog의 변경사항은 두 부분으로 나뉩니다. 먼저 새 버전 계약의 이벤트 및 해당 처리 로직에 적응하는 것으로, 전환 배치 처리 방법, 새로운 배치/증명 제출 이벤트 처리, info_tree 업데이트 이벤트 처리 등을 포함합니다. 또 다른 부분은 전체 동기화 로직의 재구성입니다. Etrog 이전 버전에서는 동기화 로직 전체가 직렬화되어 있었습니다. permissionless 노드의 경우, 일차 레이어 데이터가 배치 순서대로 완전히 동기화될 때까지 기다린 후에야 주 노드로부터 제출 대기 데이터를 동기화할 수 있었습니다. 이로 인해 이러한 노드와 주 노드 사이의 데이터는 항상 지연이 존재했습니다. Etrog 업그레이는 이 로직을 완전히 재구성하여 일차 레이어와 이차 레이어의 동기화 작업을 각각의 스레드로 분리하여 관리함으로써 위의 지연 문제를 해결하고, 일차 레이어 데이터 동기화 속도도 빠르게 했습니다.
Lumoz의 CDK Validium 업그레이드
일반적인 zkEVM 네트워크는 공식 저장소의 오픈소스 코드를 사용하여 완전히 업그레이드 절차를 마칠 수 있지만, 공식적으로 Validium 업그레이드 솔루션은 지원하지 않습니다. Lumoz 팀은 조사와 개발을 거쳐 Validium 업그레이드 솔루션을 완성하고, CDK Validium 기반의 여러 테스트넷과 Merlin 메인넷의 업그레이드를 성공적으로 수행했습니다. 본 섹션에서는 Validium의 구체적인 업그레이드 경로를 중심으로 설명합니다.
코드 구현
스마트 계약 측면
Validium의 업그레이드 솔루션은 기본적으로 공식 Rollup의 변경 사항을 참조하여 Validium 합의 계약용 PolygonValidiumExistentEtrog 계약을 구현할 수 있습니다. 이 계약은 기존 CDKValidium 계약을 기반으로 하며, zkEVMExistentEtrog와 마찬가지로 initializeUpgrade 메서드를 구현해야 하며, 업그레이드 트랜잭션 실행 중에 기존 데이터를 상속하고 노드 처리를 위한 업그레이드 배치를 생성합니다. zkEVM과 다른 점은 새 버전의 CDK Validium에서 DataCommittee 주소가 새로 배포된 PolygonValidiumExistentEtrog 계약에 의해 관리된다는 점입니다. 따라서 업그레이드 과정에서 기존 CDKDataCommittee 주소를 dataAvailabilityProtocol 변수에 다시 설정해야 합니다.
노드 측면
공식 최신 Validium 노드 코드는 updateEtrogSequence 이벤트 처리 로직을 구현하지 않아 직접 사용할 수 없습니다. 그러나 여기에서도 Rollup의 처리 프로세스를 참조하여 구현할 수 있습니다. 반면, 코드 내 의존하는 계약 ABI도 수정하여 Valdium 계약 인터페이스에 적합하게 만들고, 기존의 Rollup 계약 인터페이스를 대체해야 합니다.
주의: Etrog를 건너뛰고 바로 Eldberry 버전 이상으로 업그레이드하는 경우, 배치 데이터 처리 방식이 다르기 때문에 노드에서 일부 추가 수정이 필요합니다. 계약 업그레이드 과정에서 일차 레이어에 생성된 전환 forcedBatch는 여전히 Etrog 버전 방식으로 생성되므로, 노드가 이 배치를 처리할 때 기본 Eldberry 프로세서를 사용해서는 안 되며, 대신 Etrog 버전의 프로세서를 다시 사용해야 합니다. 그렇지 않으면 호환성 문제가 발생합니다.
업그레이드 절차
업그레이드 전, 일차 레이어와 이차 레이어 네트워크 각각에 RollupManager, ValidiumExistentEtrog, GlobalExitRootV2, BridgeV2 등 모든 새 버전 계약을 미리 배포해야 합니다. 구체적으로는 공식 업그레이드 스크립트를 참조하여 zkEVM 관련 계약을 Validium 관련 계약으로 교체하면 됩니다. 관련 계약 배포가 완료되면, 일차 레이어에서 CDKValidium 프록시 업그레이드를 위한 트랜잭션 데이터를 미리 생성하고, 새로 구현된 initialize 메서드를 호출하여 위의 데이터 재할당 및 전환 배치 생성 등의 작업을 완료합니다. 이후 Timelock 계약의 관련 권한 주소가 schedule 메서드를 호출하여 업그레이드 트랜잭션을 예약하고, timelock 계약의 잠금 시간을 기다립니다. 일차 레이어의 작업과 유사하게, 이차 레이어에서도 브리지 계약 업그레이드를 위한 트랜잭션 데이터를 미리 생성하고, 이차 레이어의 Timelock 계약 내에서 업그레이드 트랜잭션을 예약합니다.
RollupManager의 initialize 로직은 Proof가 최신 상태까지 제출되었는지 확인하여 업그레이드 전후의 배치 실행과 증명이 동일한 버전에서 이루어지도록 요구하므로, 잠금 시간이 도달한 후에도 신뢰할 수 있는 노드에 대해 일부 조정이 필요합니다. 업그레이드 중 다운타임을 최소화하기 위해 sequencer 서비스 내 StopSequencerOnBatchNum 매개변수를 미리 설정하여 해당 배치 번호에 도달하면 트랜잭션 패키징을 중단하고, 배치와 해당 증명 제출에 충분한 시간을 확보할 수 있습니다. 반면, 새 버전과 구버전 Validium은 pool_db의 migration 파일에 일부 수정이 있으므로, 수동으로 또는 노드 코드 내에서 데이터베이스의 'supernets-0001.sql' 관련 기록을 처리하여 새 버전 노드의 데이터베이스 구조와 일치시켜야 합니다.
Proof가 최신 상태로 제출되고 데이터베이스 정리가 완료되면, 일차 레이어 Timelock 계약의 관련 권한 주소가 execute 메서드를 호출하여 이전에 예약한 업그레이드 작업을 실행하고, 모든 구성 파일을 업데이트하며, 동시에 신뢰할 수 있는 노드의 모든 서비스 버전을 업데이트합니다. 신뢰할 수 있는 노드가 서비스를 복구하고 다시 트랜잭션 패키징을 시작하면, 모든 permissionless 노드도 구성 파일을 업데이트하고 새 버전 코드로 서비스를 재시작해야 합니다. 이차 레이어의 업그레이드 작업도 Timelock이 설정한 시간에 도달한 후 execute 메서드를 실행하여 이차 레이어 브리지 계약 업그레이드를 완료할 수 있습니다.
TechFlow 공식 커뮤니티에 오신 것을 환영합니다
Telegram 구독 그룹:https://t.me/TechFlowDaily
트위터 공식 계정:https://x.com/TechFlowPost
트위터 영어 계정:https://x.com/BlockFlow_News














