Optimism Documentation

이 페이지는 op-supernode/v1.0.4 릴리스를 기준으로 합니다. op-supernode가 무엇이며 왜 존재하는지에 대한 배경 정보는 supernode 설명을 참조하십시오.

이 가이드는 단일 op-supernode 프로세스를 처음부터 구성합니다. 바이너리를 빌드하고, engine API를 통해 각 체인의 실행 클라이언트를 연결하고, 프로세스를 시작한 후, 의존성 집합(dependency set)의 모든 체인이 동기화되고 있는지 확인합니다. 완료되면 하나의 op-supernode가 호스팅하는 모든 체인의 합의 레이어 역할을 하며, 체인마다 별도의 op-node를 실행할 필요가 없어집니다. 이 페이지는 프로세스를 실행하고 검증하는 단계까지 다룹니다. 권장 프로덕션 설정(beacon archiver 폴백, 실행 클라이언트 데이터 보존, Light CL 플릿, HA 풀)은 supernode 구성 가이드에서 이어서 확인하십시오. 아래에서 사용하는 모든 플래그는 op-supernode 구성 레퍼런스에 정리되어 있습니다.

시작하기 전에

다음이 필요합니다.

체인당 하나의 실행 클라이언트. 의존성 집합의 각 체인에는 engine API(authrpc)가 활성화된 자체 실행 클라이언트가 필요합니다. 하나의 실행 클라이언트로 두 체인을 지원할 수 없습니다. 클라이언트 옵션은 실행 클라이언트 구성 가이드를 참조하고, 실행 클라이언트의 전체 과정은 소스에서 node 실행하기 튜토리얼을 참조하십시오.
L1 엔드포인트. eth 네임스페이스가 활성화된 L1 JSON-RPC 엔드포인트와 L1 beacon node HTTP 엔드포인트가 필요하며, 모든 체인이 이를 공유합니다. beacon archiver 폴백을 강력히 권장합니다. blob archiver 구성하기를 참조하십시오.
supernode가 호스팅할 모든 체인의 chain ID. op-node의 내장 네트워크 레지스트리에 있는 체인(예: op-mainnet, unichain-mainnet)은 네트워크 이름만으로 충분합니다. 그 외의 체인은 체인별 rollup 구성 JSON 파일이 필요합니다.

op-supernode 빌드

바이너리는 Optimism Monorepo에서 빌드합니다. 빌드 환경은 모노레포 빌드에 필요한 툴체인을 설치하는 mise로 관리합니다. 모노레포 루트의 mise.toml을 참조하십시오.

모노레포를 클론하고 릴리스 태그 체크아웃하기

git clone https://github.com/ethereum-optimism/optimism.git
cd optimism
git checkout op-supernode/v1.0.4

바이너리 빌드하기

cd op-supernode
just op-supernode

바이너리는 op-supernode/bin/op-supernode에 생성됩니다.

빌드 확인하기

./bin/op-supernode --version

플래그 집합은 --chains 목록에서 동적으로 생성되므로, 사용하는 체인에 대한 전체 도움말 출력을 확인하려면 ./bin/op-supernode --chains=<chainIDs> --help를 실행하십시오.

JWT secret 생성 및 engine API 연결

각 체인의 가상 node는 공유 JWT secret을 사용하여 engine API를 통해 해당 체인의 실행 클라이언트에 인증합니다.

secret 생성하기

openssl rand -hex 32 > jwt-secret.txt

secret으로 각 실행 클라이언트 시작하기

모든 체인의 실행 클라이언트를 authrpc가 수신 대기하고 동일한 secret 파일을 가리키도록 하여 시작합니다. op-reth의 경우 --authrpc.jwtsecret=<path>를 사용합니다. 실행 클라이언트는 supernode보다 먼저 시작하십시오. supernode가 연결될 때까지 블록을 받지 않을 뿐입니다.

각 실행 클라이언트의 engine API 엔드포인트 기록하기

다음 섹션에서 각 체인의 engine API 엔드포인트(관례상 포트 8551)를 --vn.<chainID>.l2로 supernode에 전달합니다. 모든 실행 클라이언트가 하나의 secret을 공유하는 경우 supernode 측에서는 단일 --vn.all.l2.jwt-secret=<path> 플래그를 사용합니다. 클라이언트에 별도의 secret이 필요한 경우에만 체인별 --vn.<chainID>.l2.jwt-secret 형식을 사용하십시오.

op-supernode 시작

chain ID 목록, 공유 L1 엔드포인트, 각 체인의 네트워크 식별 정보 및 engine API 엔드포인트를 지정하여 supernode를 시작합니다. 아래 예시는 op-reth 실행 클라이언트로 OP Mainnet(chain ID 10)과 Unichain(chain ID 130)을 호스팅합니다. testnet 쌍의 경우 11155420과 1301을 네트워크 op-sepolia 및 unichain-sepolia와 함께 사용하십시오. 플레이스홀더를 채우고, 의존성 집합에 맞게 체인별 --vn.<chainID>.* 그룹을 추가하거나 제거하십시오.

./bin/op-supernode \
  --chains=10,130 \
  --data-dir=/var/lib/op-supernode \
  --l1=<your-l1-eth-rpc> \
  --l1.beacon=<your-l1-beacon-rpc> \
  --l1.beacon-fallbacks=<your-l1-beacon-archiver-rpc> \
  --vn.all.l2.jwt-secret=./jwt-secret.txt \
  --vn.10.network=op-mainnet \
  --vn.10.l2=http://op-mainnet-el:8551 \
  --vn.10.l2.enginekind=reth \
  --vn.130.network=unichain-mainnet \
  --vn.130.l2=http://unichain-el:8551 \
  --vn.130.l2.enginekind=reth \
  --metrics.enabled=true

플래그에 대한 몇 가지 참고 사항은 다음과 같습니다.

op-node의 내장 네트워크 레지스트리에 없는 체인의 경우 --vn.<chainID>.network를 --vn.<chainID>.rollup.config=<path-to-rollup-config.json>으로 바꾸십시오.
--vn.<chainID>.l2.enginekind=reth 줄은 supernode에 실행 클라이언트가 op-reth임을 알립니다. reth가 기본값이므로 생략할 수 있습니다.
P2P는 기본적으로 활성화되어 있으며, 충돌을 피하기 위해 각 가상 node의 수신 포트가 동적으로 선택됩니다. 토폴로지의 다른 node가 unsafe head gossip을 처리하는 경우 --disable-p2p=true를 설정하십시오. op-supernode를 Light CL 플릿과 함께 구성하기를 참조하십시오.
JSON-RPC 서버는 기본적으로 0.0.0.0:8545에서 수신 대기합니다(--rpc.addr / --rpc.port). op-node RPC와 마찬가지로 공용 인터넷에 노출하기 위한 것이 아닙니다.
모든 플래그에는 대응하는 환경 변수(OP_SUPERNODE_*)가 있습니다. 구성 가이드의 예시 구성은 동일한 유형의 설정을 환경 변수 형식으로 보여 주며, 구성 레퍼런스에는 모든 플래그의 정확한 이름이 나와 있습니다.

supernode 작동 확인

로그 확인하기

heartbeat 활동은 프로세스가 살아 있고 활동이 실행 중이라는 기본 신호로 10초마다 heartbeat 메시지를 로그에 남깁니다.

RPC로 활성 상태 확인하기

RPC 루트의 heartbeat_check 메서드는 활성 신호로 임의의 hex 값을 반환합니다.

curl -X POST -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"heartbeat_check","params":[],"id":1}' \
  http://localhost:8545/

전체 동기화 상태 확인하기

RPC 루트의 supernode_syncStatus 메서드는 호스팅된 모든 체인의 체인별 op-node 동기화 상태와 함께 의존성 집합 전체에 대한 필드를 반환합니다. 여기에는 chain ID, 완전히 도출되고 검증된 가장 높은 L1 블록, 집합 전체의 safe, local-safe, finalized L2 타임스탬프가 포함됩니다.

curl -X POST -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"supernode_syncStatus","params":[],"id":1}' \
  http://localhost:8545/

구성한 모든 chain ID가 응답에 나타나고, 보고된 head가 호출 간에 진행되는지 확인하십시오.

개별 체인 확인하기

각 체인의 전체 op-node RPC는 동일한 서버의 /<chainID>/ 경로 접두사 아래에 마운트되므로, 모든 op-node JSON-RPC 메서드를 체인별로 사용할 수 있습니다.

curl -X POST -H "Content-Type: application/json" \
  --data '{"jsonrpc":"2.0","method":"optimism_syncStatus","params":[],"id":1}' \
  http://localhost:8545/10/

체인의 엔드포인트는 해당 체인 컨테이너가 시작된 후에 사용할 수 있습니다. 구성되지 않은 chain ID에 대한 요청은 404 Not Found를 반환합니다.

메트릭 확인하기

--metrics.enabled=true를 설정하면 모든 체인의 메트릭이 메트릭 포트(기본값 7300)의 /metrics에 있는 단일 Prometheus 엔드포인트로 모이며, 체인별로 레이블이 지정됩니다.

curl http://localhost:7300/metrics

다음 단계

supernode 구성 가이드로 배포를 강화하십시오. beacon archiver 폴백, backfill을 위한 실행 클라이언트 데이터 보존, Light CL 플릿, 합의 인식 proxyd 뒤의 HA 풀을 다룹니다.
op-supernode 구성 레퍼런스에서 모든 플래그를 찾아보십시오.
op-supernode가 무엇이며 왜 존재하는지는 supernode 설명을 읽어 보십시오.
OP Mainnet 및 Unichain 활성화를 위한 노드 운영자 조치 체크리스트는 interop 준비 공지를 읽어 보십시오.

노드 실행

가이드

튜토리얼

클라이언트

참조

Supernode 설정

시작하기 전에

op-supernode 빌드

JWT secret 생성 및 engine API 연결

op-supernode 시작

supernode 작동 확인

다음 단계

​시작하기 전에

​op-supernode 빌드

​JWT secret 생성 및 engine API 연결

​op-supernode 시작

​supernode 작동 확인

​다음 단계

시작하기 전에

op-supernode 빌드

JWT secret 생성 및 engine API 연결

op-supernode 시작

supernode 작동 확인

다음 단계