Sui 풀 노드 구성
이 지침은 고급 사용자를 위한 것이다. 로컬 개발 환경만 필요하다면 Create a Local Sui Network의 지침을 따라 로컬 풀 노드, validators, faucet을 만들어야 한다.
Sui 풀 노드는 transactions, checkpoints, epoch changes를 포함한 blockchain 활동을 검증한다. 각 풀 노드는 blockchain state와 history에 대한 queries를 저장하고 제공한다.
이 역할을 통해 validators는 transactions 제공과 처리에 집중할 수 있다. validator가 새로운 transactions 집합(또는 transactions block)을 커밋하면 validator는 이를 연결된 모든 풀 노드로 push하고, 풀 노드가 clients의 queries를 제공한다.
Features
Sui 풀 노드는 다음을 수행한다:
- blockchain state를 독립적으로, 로컬에서 추적하고 검증한다.
- clients의 read requests를 제공한다.
State synchronization
Sui 풀 노드는 validators와 동기화하여 network의 새 transactions를 수신한다.
transaction 하나가 transaction certificate(TxCert)를 형성하려면 2f+1 validators와 몇 차례 round trip을 해야 한다.
이 synchronization process에는 다음이 포함된다:
- 2f+1 validators를 따라가며 새로 커밋된 transactions를 수신한다.
- 2f+1 validators가 transaction을 인식하고 있고 transaction이 finality 에 도달했는지 확인한다.
- transaction을 로컬에서 실행하고 로컬 DB를 업데이트한다.
이 synchronization process는 풀 노드가 모든 새 transactions를 올바르게 처리했음을 보장하려면 최소 2f+1 validators를 수신해야 한다. Sui는 checkpoints 도입과 다른 풀 노드와 동기화하는 기능을 통해 synchronization process를 개선할 예정이다.
Architecture
Sui 풀 노드는 본질적으로 네트워크 state의 읽기 전용 view이다. validator 노드와 달리 풀 노드는 transactions에 서명할 수 없지만, quorum의 validators가 이전에 커밋한 transactions를 다시 실행하여 chain의 무결성을 검증할 수는 있다.
현재 Sui 풀 노드는 chain의 전체 history를 유지할 가능성이 있다. 이것은 gRPC 도입과 JSON-RPC 단계적 종료로 바뀔 것이다.
validator 노드는 object graph의 frontier에 있는 최신 transactions만 저장한다(예: 미사용 output objects가 0보다 큰 transactions).
Full node setup
자체 Sui 풀 노드를 실행하려면 여기의 지침을 따른다. Sui 풀 노드는 sui-node binary를 사용해 실행된다.
Hardware requirements
Sui 풀 노드를 실행하기 위한 권장 최소 하드웨어는 다음과 같다:
- CPUs: 물리 코어 8개 / 16 vCPUs
- RAM: 128 GB
- Storage (SSD): 4 TB NVMe drive
Software requirements
Sui는 Linux에서 Sui 풀 노드를 실행할 것을 권장한다. Sui는 Ubuntu와 Debian distributions를 지원한다. macOS에서도 Sui 풀 노드를 실행할 수 있지만, 이는 개발용으로만 권장되며 production 사용에는 권장되지 않는다.
update Rust를 반드시 수행한다.
추가 Linux dependencies를 설치하려면 다음 명령을 사용한다.
$ sudo apt-get update \
&& sudo apt-get install -y --no-install-recommends \
tzdata \
libprotobuf-dev \
ca-certificates \
build-essential \
libssl-dev \
libclang-dev \
libpq-dev \
pkg-config \
openssl \
protobuf-compiler \
git \
clang \
cmake
Considerations to enable gRPC
풀 노드에서 gRPC support를 활성화해야 한다. JSON-RPC는 deprecated 상태이다. 전체 전환 계획에 대한 안내는 Sui's data serving roadmap을 참고한다.
gRPC API를 제공하려면 gRPC 전용 데이터를 indexing하도록 풀 노드에서 이를 활성화해야 한다. 초기 gRPC indexing 단계에서는 풀 노드가 deprecated JSON-RPC requests를 포함해 다른 트래픽을 처리하지 못할 수 있다. rollout을 신중히 계획하고(rolling upgrade 메커니즘 사용 등), 다운타임이 있다면 고객과 파트너에게 미리 알린다. gRPC indexes 동기화에 걸리는 시간은 풀 노드의 하드웨어와 소프트웨어 구성에 따라 달라진다.
fullnode.yaml configuration에 다음 항목을 추가해 풀 노드에서 gRPC indexing을 활성화한다:
rpc:
enable-indexing: true
gRPC를 JSON-RPC와 함께 실행하면 풀 노드의 storage 사용량이 증가한다. 모든 client applications가 JSON-RPC에서 이전한 후 JSON-RPC를 비활성화해 이 storage를 회수할 수 있다. 모든 applications는 점진적으로 gRPC 또는 GraphQL RPC로 이전해야 한다. gRPC와 JSON-RPC를 서로 다른 nodes에서 실행해 resource usage를 최적화하고 client applications에 성능 좋고 복원력 있는 RPC 경험을 제공할 수도 있다. 풀 노드의 fullnode.yaml configuration에 다음을 추가해 JSON-RPC를 선택적으로 비활성화한다:
enable-index-processing: false
풀 노드의 fullnode.yaml configuration에 다음을 추가하면 gRPC index의 retention window를 구성할 수 있다:
authority-store-pruning-config:
num-epochs-to-retain: 14
num-epochs-to-retain-for-checkpoints: 14
gRPC data retention 기간은 풀 노드의 resource profile과 JSON-RPC 비활성화 여부에 따라 조정한다. 어떤 경우든 longer retention period를 애플리케이션에서 gRPC를 사용하거나 다른 개발자에게 제공하기 전에 성능과 확장성 측면에서 테스트한다.
Running a full node
sui-node binary를 build, install, download하는 지침은 Install from Binaries 가이드에서 확인할 수 있다.
이 install 지침은 sui CLI에 특화되어 있지만 sui-node binary에도 동일하게 적용된다.
Sui 풀 노드는 여러 방식으로 실행할 수 있으며(bare metal, virtual machine, Kubernetes StatefulSet 등), 어떤 방식을 선택할지는 구체적인 요구 사항과 사용 가능한 인프라에 따라 다르다.
어떤 환경에서 실행하든 공통으로 고려해야 할 사항이 있다:
- 제네시스: 연결하려는 network의 genesis blob을 다운로드하고
sui-node에서 사용할 수 있게 해야 한다. - 데이터 관리: Sui 풀 노드는 blockchain history를 저장하기 위해 상당한 디스크 공간이 필요할 수 있다. 풀 노드를 사용해 RPC requests를 제공할 계획이라면 index files 저장도 고려해야 하며, 이 역시 상당한 디스크 공간이 필요하다.
- Sui 노드 모니터링: Sui 풀 노드는 node의 건강 상태와 Sui network 상태에 대한 metrics를 노출한다.
- 풀 노드 업 데이트하기: Sui 풀 노드는 network와 동기화 상태를 유지하려면 최신 버전으로 업데이트되어야 한다.
- Sui 아카이브: archival fallback을 사용하면 chain history의 어느 시점에서든 checkpoints를 동기화할 수 있다. 아래의 network
seed-peers는 몇 개 epoch 분량의 history만 유지한다.
Using Docker Compose
Sui repository에는 Docker Compose를 통해 풀 노드를 실행하는 가이드가 있다. 이 방법만으로는 production 환경에 적합하지 않지만, 개발 목적의 virtual machine이나 로컬 머신에서 풀 노드를 빠르게 구동하는 데 사용할 수 있다. production use cases와 관련된 지침은 Running a full node를 참고한다.
Setting up a full node
production 환경에서 sui-node를 실행할 준비가 되면 다음 단계를 완료해 풀 노드를 설정할 수 있다:
-
full node YAML template를 복사한다:
$ cp crates/sui-config/data/fullnode-template.yaml fullnode.yaml -
사용할 network의 genesis blob을 다운로드한다:
- Devnet genesis blob:
$ curl -fLJO https://github.com/MystenLabs/sui-genesis/raw/main/devnet/genesis.blob - Testnet genesis blob:
$ curl -fLJO https://github.com/MystenLabs/sui-genesis/raw/main/testnet/genesis.blob - Mainnet genesis blob:
$ curl -fLJO https://github.com/MystenLabs/sui-genesis/raw/main/mainnet/genesis.blob
- Devnet genesis blob:
-
Testnet 또는 Mainnet의 경우: state synchronization을 위한 peer nodes를 포함하도록
fullnode.yamlfile을 편집한다. 현재 configuration 끝에 다음을 추가한다:- Mainnet
- Testnet
p2p-config:
seed-peers:
- address: /dns/mel-00.mainnet.sui.io/udp/8084
peer-id: d32b55bdf1737ec415df8c88b3bf91e194b59ee3127e3f38ea46fd88ba2e7849
- address: /dns/ewr-00.mainnet.sui.io/udp/8084
peer-id: c7bf6cb93ca8fdda655c47ebb85ace28e6931464564332bf63e27e90199c50ee
- address: /dns/ewr-01.mainnet.sui.io/udp/8084
peer-id: 3227f8a05f0faa1a197c075d31135a366a1c6f3d4872cb8af66c14dea3e0eb66
- address: /dns/lhr-00.mainnet.sui.io/udp/8084
peer-id: c619a5e0f8f36eac45118c1f8bda28f0f508e2839042781f1d4a9818043f732c
- address: /dns/sui-mainnet-ssfn-1.nodeinfra.com/udp/8084
peer-id: 0c52ca8d2b9f51be4a50eb44ace863c05aadc940a7bd15d4d3f498deb81d7fc6
- address: /dns/sui-mainnet-ssfn-2.nodeinfra.com/udp/8084
peer-id: 1dbc28c105aa7eb9d1d3ac07ae663ea638d91f2b99c076a52bbded296bd3ed5c
- address: /dns/sui-mainnet-ssfn-ashburn-na.overclock.run/udp/8084
peer-id: 5ff8461ab527a8f241767b268c7aaf24d0312c7b923913dd3c11ee67ef181e45
- address: /dns/sui-mainnet-ssfn-dallas-na.overclock.run/udp/8084
peer-id: e1a4f40d66f1c89559a195352ba9ff84aec28abab1d3aa1c491901a252acefa6
- address: /dns/ssn01.mainnet.sui.rpcpool.com/udp/8084
peer-id: fadb7ccb0b7fc99223419176e707f5122fef4ea686eb8e80d1778588bf5a0bcd
- address: /dns/ssn02.mainnet.sui.rpcpool.com/udp/8084
peer-id: 13783584a90025b87d4604f1991252221e5fd88cab40001642f4b00111ae9b7ep2p-config:
seed-peers:
- address: /dns/yto-tnt-ssfn-01.testnet.sui.io/udp/8084
peer-id: 2ed53564d5581ded9b6773970ac2f1c84d39f9edf01308ff5a1ffe09b1add7b3
- address: /dns/yto-tnt-ssfn-00.testnet.sui.io/udp/8084
peer-id: 6563732e5ab33b4ae09c73a98fd37499b71b8f03c27b5cc51acc26934974aff2
- address: /dns/nrt-tnt-ssfn-00.testnet.sui.io/udp/8084
peer-id: 23a1f7cd901b6277cbedaa986b3fc183f171d800cabba863d48f698f518967e1
- address: /dns/ewr-tnt-ssfn-00.testnet.sui.io/udp/8084
peer-id: df8a8d128051c249e224f95fcc463f518a0ebed8986bbdcc11ed751181fecd38
- address: /dns/lax-tnt-ssfn-00.testnet.sui.io/udp/8084
peer-id: f9a72a0a6c17eed09c27898eab389add704777c03e135846da2428f516a0c11d
- address: /dns/lhr-tnt-ssfn-00.testnet.sui.io/udp/8084
peer-id: 9393d6056bb9c9d8475a3cf3525c747257f17c6a698a7062cbbd1875bc6ef71e
- address: /dns/mel-tnt-ssfn-00.testnet.sui.io/udp/8084
peer-id: c88742f46e66a11cb8c84aca488065661401ef66f726cb9afeb8a5786d83456e -
Optional: network의
seed-peers보다 뒤처졌을 때 checkpoints를 동기화할 수 있게 하는 Sui 아카이브를 설정한다. -
Optional: 기본 resource paths를 사용할 경우 이 단계를 건너뛴다. custom paths를 사용하려면
fullnode.yamlfile을 편집한다. -
db-pathfield를 풀 노드 database path로 업데이트한다.db-path: "/db-files/sui-fullnode" -
genesis-file-location을 genesis.blob path로 업데이트한다.genesis:
genesis-file-location: "/sui-fullnode/genesis.blob"
Starting your full node
풀 노드를 genesis 시작점부터 동기화해서는 안 된다. 이렇게 하면 시간이 매우 오래 걸리고 많은 resources를 소비하며, 디스크도 쉽게 가득 찰 수 있다.
대신 최근 snapshot에서 풀 노드를 시작한다. snapshot 획득 방법은 데이터베이스 스냅샷에서 확인한다.
이제 풀 노드 config file 을 설정했고 snapshot도 확보했으므로, fullnode.yaml configuration file과 함께 sui-node binary를 실행해 풀 노드를 시작할 수 있다:
$ sui-node --config-path fullnode.yaml
production 환경에서는 systemd 같은 도구를 사용해 풀 노드를 관리하는 것이 좋다.
Troubleshooting
cannot find -lpq error가 발생하면 libpq library가 없는 것이다. Linux에서는 sudo apt-get install libpq-dev, macOS에서는 brew install libpq로 설치한다. macOS에 설치한 뒤에는 brew link --force libpq로 Homebrew link를 만든다. 자세한 배경은 issue on Stack Overflow를 참고한다.
다음과 같은 error가 발생하면:
panicked at error binding to 0.0.0.0:9184: error creating server listener: Address already in use (os error 98)
fullnode.yaml file의 metrics address를 9180 port로 변경한다.
metrics-address: "0.0.0.0:9180"