본문으로 건너뛰기

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에는 다음이 포함된다:

  1. 2f+1 validators를 따라가며 새로 커밋된 transactions를 수신한다.
  2. 2f+1 validators가 transaction을 인식하고 있고 transaction이 finality에 도달했는지 확인한다.
  3. 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를 실행할 준비가 되면 다음 단계를 완료해 풀 노드를 설정할 수 있다:

  1. full node YAML template를 복사한다:

    $ cp crates/sui-config/data/fullnode-template.yaml fullnode.yaml
  2. 사용할 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
  3. Testnet 또는 Mainnet의 경우: state synchronization을 위한 peer nodes를 포함하도록 fullnode.yaml file을 편집한다. 현재 configuration 끝에 다음을 추가한다:

    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: 13783584a90025b87d4604f1991252221e5fd88cab40001642f4b00111ae9b7e
  4. Optional: network의 seed-peers보다 뒤처졌을 때 checkpoints를 동기화할 수 있게 하는 Sui 아카이브를 설정한다.

  5. Optional: 기본 resource paths를 사용할 경우 이 단계를 건너뛴다. custom paths를 사용하려면 fullnode.yaml file을 편집한다.

  6. db-path field를 풀 노드 database path로 업데이트한다. db-path: "/db-files/sui-fullnode"

  7. 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"