op-node가 gossip으로 수신한 unsafe 블록을 통합하는 동시에, L1에서 safe 체인을 각자 독립적으로 파생(derive)해 왔습니다. 노드 수가 늘어나고 interop과 같은 향후 기능으로 파생 비용이 증가함에 따라, 소수의 op-node 인스턴스만 L1 파생을 전담하고 나머지는 이러한 소스에 의존하는 특화된 토폴로지로 마이그레이션할 것을 강력히 권장합니다.
특화된 토폴로지에서 light node는 파생 소스를 가리키는 --l2.follow.source와 함께 시작됩니다. 소스는 interop이 활성화되지 않은 체인의 경우 op-node이고, interop dependency set에 속한 체인의 경우 op-supernode입니다(하나의 supernode가 set 내 모든 체인을 함께 파생하고 크로스체인 메시지 검증을 추가로 수행합니다). light node는 자체적인 독립 파생을 비활성화하고 소스로부터 safe 체인을 받으며, gossip과 engine API를 통해 unsafe tip은 계속 추적합니다.
의미
- 소스 노드는 L1에서 전체 체인을 파생합니다. interop이 없는 체인에서는 기존의
op-node이고, interop dependency set에 속한 체인에서는 set 내 모든 체인을 함께 파생하고 크로스체인 메시지를 검증하는op-supernode입니다. - light node는
--l2.follow.source=<source RPC endpoint>로 시작된op-node인스턴스입니다. L1에서 직접 파생하는 것을 중단하고 지정된 소스로부터 safe 체인을 받습니다. 소스는 interop이 아닌 체인의 경우 op-node RPC이고, interop 체인의 경우 op-supernode RPC(체인의/<chainID>경로 접두사 포함)입니다. op-node는 지원 중단되지 않으며, 동종 토폴로지도 제거되지 않습니다. interop이 활성화되지 않은 체인의 경우 이는 필수 마이그레이션이 아니라 권장되는 운영 업그레이드입니다. OP Mainnet, Unichain 및 각각의 Sepolia testnet의 경우 interop 활성화 시점에 필수가 됩니다(위의 경고 참조).- 파생 역할만 변경됩니다. light node는 이전과 마찬가지로 RPC를 제공하고, gossip에 참여하며, 연결된 실행 클라이언트를 구동합니다.
중요한 이유
L1 사용량 감소
소스 노드만 파생을 위해 L1 데이터를 수집합니다. light node는 더 이상 파생 파이프라인을 위한 L1 RPC 호출을 하지 않으므로, 많은 노드를 운영하는 운영자의 L1 API 부하와 제공업체 비용이 크게 줄어듭니다.성능 특화
light node는 L1 파생 작업 부담을 덜고 unsafe 체인 진행과 RPC 제공에 집중할 수 있으며, 소스 노드는 파생에만 집중합니다.비대칭 확장
이제 RPC 제공 용량과 파생 용량을 독립적으로 확장할 수 있습니다. 운영자는 L1 부하를 바꾸지 않고도 읽기 트래픽에 맞춰 light node를 추가하거나 제거할 수 있으며, 파생 요구 사항과 이중화 목표에 따라 소스 계층의 규모를 별도로 정할 수 있습니다.향후 배포 비용 절감
interop을 포함한 향후 업그레이드에는 더 정교한 파생 로직이 필요합니다. 작고 명확하게 정의된 소스 계층으로 파생을 집중시키면, 이러한 업그레이드의 영향을 받는 운영 범위가 최소화되고 노드별 도입 비용이 줄어듭니다.마이그레이션 방법
노드 운영자
파생이 활성화된op-node 인스턴스로 이루어진 동종 구성에서 특화된 토폴로지로의 마이그레이션을 계획합니다.
- 소스 계층을 구축합니다. interop이 없는 체인의 경우 하나 이상의
op-node인스턴스를 소스로 지정하고 전체 L1 파생으로 구성합니다. interop dependency set에 속한 체인의 경우 소스 계층은 set 내 모든 체인을 다루는 하나 이상의op-supernode인스턴스입니다. 어느 경우든 장애 조치(failover)를 위한 이중화를 고려하여 소스 계층의 규모를 정하고 모니터링합니다. - 나머지
op-node인스턴스는--l2.follow.source=<source op-node RPC endpoint>(env:OP_NODE_L2_FOLLOW_SOURCE)를 설정하여 light node로 프로비저닝합니다. light node가 안정적이고 지연 시간이 짧은 네트워크 경로를 통해 소스 엔드포인트에 접근할 수 있는지 확인합니다. - 프로덕션 트래픽을 전환하기 전에 light node가 소스 기준으로 safe 체인을 올바르게 추적하는지 검증합니다.
- 소스 계층의 상태가 light node 계층의 의존성으로 취급되도록 대시보드와 알림을 업데이트합니다.
합의 인식 proxyd를 사용한 고가용성 토폴로지
프로덕션 배포에서는 파생 계층을 합의 인식(consensus-aware)proxyd 뒤에 배치하고, 별도의 RPC 제공 계층을 통해 light node를 사용자에게 노출할 것을 권장합니다.
- Deriver 계층 — 작고 이중화된 소스 인스턴스 집합입니다(interop이 아닌 체인은
op-node, interop 체인은op-supernode). 이 인스턴스들은 라우팅 전략consensus_aware_consensus_layer로 구성된proxyd뒤에 위치하며,proxyd는 여러 소스를 하나의 고가용성 엔드포인트로 통합하고 개별 장애나 reorg를 다운스트림 소비자로부터 숨깁니다. - Light node 계층 — deriver 계층의
proxyd엔드포인트를 가리키는--l2.follow.source로 시작된 lightop-node인스턴스의 수평 확장 가능한 풀입니다. 이 계층은 읽기 트래픽에 따라 독립적으로 확장 및 축소할 수 있습니다. - Edge 계층 — light node 계층 앞단에서 외부 RPC 트래픽, 속도 제한, 라우팅을 처리하는 API 게이트웨이 또는 사용자 대상
proxyd입니다.
체인 운영자
노드 운영자를 위한 모든 안내는 체인 운영자에게도 적용됩니다. sequencer 역할을 하는op-node 인스턴스의 경우, 파생 작업을 분산하기 위해 --l2.follow.source를 사용할 것을 권장합니다. 벤치마크에 따르면 파생을 제거하면 블록 생성 시 일부 병목이 해소되며,
sequencer의 역할은 Unsafe 체인을 유지하고 확장하는 것입니다.
interop이 활성화되지 않은 체인에서 특화된 토폴로지는 권장 사항이며 필수 요구 사항이 아닙니다. 해당 체인의 기존 동종 배포는 계속 작동하며, 마이그레이션은 light node를 하나씩 점진적으로 진행할 수 있습니다.
참고 자료
- Interop 준비 공지 — 이 토폴로지가 권장 사항이 아닌 필수 사항인 OP Mainnet 및 Unichain interop 활성화를 위한 노드 운영자 조치 체크리스트
--l2.follow.source플래그(env:OP_NODE_L2_FOLLOW_SOURCE) —op-node를 소스op-nodeRPC 엔드포인트를 가리키는 light node로 구성합니다.--l2.follow.source.rpc-timeout플래그(env:OP_NODE_L2_FOLLOW_SOURCE_RPC_TIMEOUT) — 소스와 통신할 때 사용하는 RPC 호출 타임아웃을 조정합니다(기본값10s).