올바른 릴리스 버전
체인 운영자와 노드 운영자는 항상 OP Stack 오프체인 구성 요소의 최신 프로덕션 릴리스를 실행해야 합니다. 최신 릴리스 노트와 변경 로그는 GitHub에서 확인할 수 있습니다.- OP monorepo 릴리스 (
op-node및 기타 Go 기반 OP 구성 요소 포함) - op-geth 릴리스 (독립 저장소)
- op-contracts 릴리스 (
op-contracts/로 시작하는 태그 확인)
-
프로덕션 릴리스는 특정 OP 구성 요소에 대해 항상
<component-name>/v<semver>형식으로 태그가 지정됩니다. 예시:op-node의 경우op-node/v1.7.5op-challenger의 경우op-challenger/v1.0.0
-
Monorepo 릴리스는 일반적으로 단순한
v<semver>형식(예:v1.7.7)을 사용하며, 모든 Go 기반 OP Stack 구성 요소(op-*)가 함께 업데이트되었음을 나타냅니다. 여기에는 새 L1 컨트랙트 릴리스가 포함되지 않습니다. -
컨트랙트 릴리스는
op-contracts/v<semver>(예:op-contracts/v1.6.0) 형식으로 태그가 지정되며 Bedrock L1 컨트랙트에 대한 업데이트를 포함합니다. -
op-geth버전 체계는 semver 안에 업스트림 geth의 버전을 포함합니다. 예를 들어 업스트림 geth가v1.12.0이면op-geth릴리스는v1.101200.0이 될 수 있습니다. geth의 major 버전을 minor 버전으로 사용하고(필요한 경우 왼쪽을 0으로 채움), patch 버전을 뒤에 붙입니다.
배포 아티팩트 보관
Ethereum에 컨트랙트를 배포한 후에는 모든 배포 아티팩트를 기록으로 보관해야 합니다. 여기에는 모든 op-deployer 아티팩트와op-deployer 및 op-contracts의 릴리스 태그 및 커밋 해시가 포함됩니다.
체인을 Superchain Registry에 추가하려면 이러한 아티팩트가 필요합니다.
점진적 업그레이드 롤아웃
node를 업그레이드할 때는 단계적인 방식을 사용하세요. 즉, 모든 node를 변경하기 전에 인프라 전반에 업그레이드를 점진적으로 배포하고 예상대로 작동하는지 확인해야 합니다.Sequencer 격리
sequencer node를 인터넷에 직접 연결하지 않음으로써 격리할 수 있습니다. 대신 수신 트래픽을 프록시 뒤에서 처리할 수 있습니다. 프록시가 트래픽을 레플리카로 전달하고, 레플리카가 내부적으로 트랜잭션을 gossip하도록 구성하세요.P2P 트랜잭션의 안정성 향상
다음 플래그는 내부 레플리카 node와 sequencer node 간 P2P 트랜잭션의 안정성을 향상시킬 수 있습니다. sequencer node의 경우:자체 런북 작성
OP Stack 체인 운영에 대비하여 맞춤형 런북을 작성하세요. 시스템의 주요 구성 요소에 메트릭 엔드포인트와 모니터링을 설정하고, 예상대로 동작하지 않을 때 실행할 런북을 작성해야 합니다.전제 조건
op-proposer는 아카이브 모드를 전제로 합니다
op-proposer는 현재 op-geth가 아카이브 모드로 실행되고 있다고 가정합니다.
이는 향후 네트워크 업그레이드에서 변경될 가능성이 높지만, 현재로서는 L2 출금에
필요합니다.
프로덕션 환경에서 운영하기