tech

안정적인 블록체인 서비스를 위한 Full Node 구축기

#기술블로그 #블록체인 #tech #XPLA #Full Node

X-PLANET 마켓플레이스는 XPLA를 통해 NFT 2차 거래를 지원하는 탈중앙화 거래소다. 이 플랫폼은 XPLA에서 제공하는 Public LCD(Light Client Daemon)를 사용하여 블록체인과 통신한다. 서비스 운영 중 Public LCD의 한계가 있어, 증가하는 블록체인 트래픽을 처리하기 위해 Full Node를 구축했다. 이를 통해 더 안정적인 서비스를 제공할 수 있게 됐다.

회로망	CPU 코어	숫양	디스크	대역폭
`dimension_37-1`	4 (+4개 스레드)	32GB (32기가바이트)	2TB(SSD 2000MB/s R/W)	300Mbps
`cube_47-5`	2 (+2 스레드)	16기가바이트	500GB(SSD 1000MB/s R/W)	150Mbps
`private-network`	1	2GB(2기가바이트)	20GB(SSD 500MB/s R/W)	없음

XPLA Full Node를 구축하기 위한 하드웨어 최소 요구 사항은 낮은 편은 아니다. 무료로 공개하는 엔드 포인트도 존재한다. “그럼에도 불구하고 왜 Full Node를 구축해야 할까?” 🔗XPLA 문서를 참고하면 공개된 엔드 포인트는 개발에만 사용하고 상용 서비스는 비공개 엔드 포인트를 권장하고 있다.

공개된 엔드 포인트는 많은 XPLA기반 서비스들이 사용하기 때문에 과부하로 인하여 통신이 원활하지 않을 수 있다. 블록체인이 아닌 블록체인과 통신을 하는 LCD, RPC(Remote Procedure Call)의 중단이기 때문에 공개된 엔드 포인트를 사용한 서비스만 중단되거나 느린 응답으로 인하여 타 서비스에 비해서 사용자에게 부정적인 경험을 줄 수 있다. 부정적인 사용자 경험은 서비스 이탈로 자연스럽게 이어진다.

2023년 3월, 모 기업의 블록체인 지갑 서비스가 주말 동안 장애를 겪은 적이 있다. 블록체인 플랫폼과 통신을 하기 위한 API서비스 오류 때문이었다. 해당 기업의 블록체인 지갑 서비스는 공개된 엔드포인트를 사용했고 다른 서비스에서 NFT가 대량 민팅되면서 처리 시간이 지연되어 문제가 발생했다.

이와 같이 공개된 엔드 포인트를 사용하면 비용과 편리함이라는 이점이 있지만 장애 상황이 생길 수 있다. Full Node를 직접 운영하면 장애 상황뿐만 아니라 데이터의 완전성, 독립성, 보안, 성능 최적화 등 다양한 측면에서 이점을 얻을 수 있다. 이러한 점에서 XPLA는 Full Node를 구축하고 운영하기 시작했다.

Full Node 구축에는 두 가지 방법이 있다. 처음부터 구축하거나 스냅샷을 이용하여 구축하는 것이다. 스냅샷은 특정 시점의 블록체인 상태를 저장하는 기능으로 노드 구축을 용이하게 하는 기능이다. 스냅샷을 이용하면 빠르고 쉽게 적용이 가능해서, 빠른 구축을 위해서 기자는 스냅샷을 이용한 방법을 먼저 시도했다.

Bware Labs에서 XPLA 스냅샷을 제공하고 있다. 🔗Bware Labs Snapshots 페이지에서 메인넷, 테스트넷을 제공한다. 테스트넷 기준으로 스냅샷을 이용하는 방법은 다음과 같다.

# 기간에 맞는 스냅샷 다운로드 한다.
wget https://snapshots.bwarelabs.com/xpla/testnet/xpla20240620.tar.lz4

# XPLA 서비스 동작한다면 중지한다.
sudo systemctl stop XPLA.service

# priv_validator_state.json을 백업 해둔다.
mv <XPLA_HOME>/data/priv_validator_state.json <XPLA_HOME>

# 기존 XPLA 파일을 지운다.
rm -rf <XPLA_HOME>/data/*

# 다운로드 받은 스냅샷을 압축을 푼다.
lz4 -c -d xpla20240620.tar.lz4  | tar -x -C <XPLA_HOME>/data

# 스냅샷의 priv_validator_state을 삭제하고 백업한 파일로 변경한다.
rm <XPLA_HOME>/data/priv_validator_state.json
mv <XPLA_HOME>/priv_validator_state.json <XPLA_HOME>/data/

스냅샷 이용한 노드는 제공하는 노드의 운영체제와 설정에 종속된다. Bware Labs의 스냅샷은 상태 동기화 및 인덱서가 꺼진 상태에서 우분투 22.04를 실행하는 시스템에서 도커 컨테이너로 호스팅되고 있었다. 블록 검증을 위한 밸리데이터를 위한 설정이기 때문에 DApp 개발에 적용하기에는 힘들었다.

# in app.toml
pruning = "custom"
pruning-keep-recent = "100"
pruning-keep-every = "0"
pruning-interval = "10"

인덱서가 꺼진 상태로 최신 블록만 저장되어 과거의 블록과 트랜잭션을 볼 수 없었다. Full Node를 적용할 운영체제 환경도 달랐기 때문에 스냅샷을 이용한 방법은 적용하기 힘들다는 판단을 내렸다.

XPLA Full Node를 구축하기 전에 golang 1.2.x 이상 버전과 build-essential 설치가 필요하다. 설치가 완료된 리눅스 운영체제라는 가정으로 테스트넷 Full Node 구축을 설명해 보겠다.

git clone https://github.com/xpladev/xpla

xpla 소스 코드를 git clone 한다.

git checkout tags/v1.0.0

버전에 따라서 포함되는 블록과 설정이 다르기 때문에 초기 버전부터 차례대로 올려야한다. 가장 초기 버전인 v1.0.0으로 설정한다.

make install

xplad version --long

xpla 노드 서비스 xplad를 설치하고 버전을 확인한다.

xplad를 시작하기 전에 주요 옵션을 알아보자. 블록이 올라가면 다시 변경하기 어렵기 때문에 요구사항에 맞게 노드를 구축하지 않는다면 다시 설정이 필요할 수 있다. xplad config는 app.toml, client.toml, config.toml으로 구성된다. 상세한 옵션을 보고 싶다면 ~/.xpla/config에서 확인 가능하다.

app.toml
- Base Configuration
  - pruning: 블록체인 상태를 유지하고 관리하는 방법이다.
  - index-events: 인덱스 이벤트 집합을 정의하는 설정이다.
- State Sync Configuration
  - snapshot-interval: 로컬 상태 동기화 스냅샷 블록 간격을 지정한다.
  - snapshot-keep-recent: 유지되고 제공되는 스냅샷의 수를 지정한다.
client.toml
- broadcast-mode: 트랜잭션 브로드캐스팅 모드를 설정한다.
  - sync: 트랜잭션이 브로드캐스팅되고 모든 노드에 도달한 후 응답을 기다린다.
  - async: 트랜잭션이 브로드캐스팅되고 네트워크에 전파되는 동안 응답을 기다리지 않고 즉시 반환한다.
  - block: 트랜잭션이 브로드캐스팅되고 특정 블록에 포함될 때까지 응답을 기다린다.
config.toml
- P2P Configuration Options: 노드 간 연결을 설정한다.
- Transaction Indexer Configuration Options
  - indexer: 트랜잭션 인덱서에 사용할 유형을 설정한다.

# moniker: 노드 명칭
xplad init [moniker] --chain-id cube_47-5

# account-name: 계정 이름
xplad keys add [account-name]

wget https://raw.githubusercontent.com/xpladev/testnets/main/cube_47-5/genesis.json
cp genesis.json ~/.xpla/config/genesis.json

# ~/.xpla/config/config.toml
seed="9ddfac28dc6b28601e3039902ee5a8915dc7891f@3.35.54.221:26656"

# external address 설정
sed -i -e 's/external_address = \"\"/external_address = \"'$(curl httpbin.org/ip | jq -r .origin)':26656\"/g' ~/.xpla/config/config.toml

# 노드 시작
xplad start

요구사항에 맞는 설정 파일을 수정했다면 노드를 네트워크에 연결하고 실행한다. 실행하다가 일정 블록에 도달하면 멈추게 된다. 이는 xplad 버전이 올라가서 블록정보가 달라져서 생기는 문제로 xplad 버전을 업데이트하면 해결된다. 업데이트 순서와 블록은 다음과 같다.

mainnet
- v1.0.0(755000) -> v1.1.0(2459600) -> v1.2.2(6881850) -> 1.3.0(8373900) -> v1.4.0
testnet
- v1.0.0(12700) -> v1.1.0-cube(2184000) -> v1.2.2(2459600) -> v1.3.0-rc6(6679014) -> 1.4.0-rc0(7516478) -> 1.5.1-rc1(9229980)

자체 구축을 하다보면 다양한 이슈를 경험하게 된다. 기자가 경험한 이슈와 해결방법에 대해 이야기해 보겠다.

invalid json-rpc config value, JSON-RPC feehistory-cap cannot be negative or 0

xplad v1.2.0부터 EVM 지원을 시작하면서 EVM 설정이 필요하다. .xpla/config/app.toml에 EVM 관련 설정을 추가해 주면 해결된다.

wrong Block.Header.AppHash

블록이 올라가는 과정에서 블록 높이와 상태 정보의 🔗불일치로 인하여 생기는 문제로 롤백이 필요하다. 블록을 순서대로 올리고 올리기 전에 설정을 꼭 확인하고 올려야 한다.

code = NotFound desc = tx not found

indexer=null을 옵션으로 노드 실행하고 LCD에서 과거의 트랜잭션을 볼 수 없는 상황이거나 트랜잭션이 유실되는 상황이 이다. 트랜잭션 재수집이 필요하다. 다행으로🔗 tendermint 기반의 xplad는 reindex라는 명령어를 지원한다. xplad reindex-event를 입력하면 다시 트랜잭션을 수집하여 해결할 수 있다.

ERR prevote step ProposalBlock is invalid err

5,312,080 블록에서 발생했던 오류로 노드 설정 옵션이 꼬여서 생긴 문제이다. xplad rollback 명령어를 통해 다시 블록을 쌓아서 해결할 수 있다.

invalid coin denomination

유효하지 않은 단위가 설정되어 생긴 문제로 업데이트 순서에 따른 버전 설정을 올바르게 하면 해결된다.

대부분의 이슈는 버전에 따른 설정을 하지 않아서 생기는 이슈로 가이드를 잘 따라서 설정을 적용하는 게 중요하다. Full Node 구축 중에 오류가 발생한다면 🔗 XPLA Validators discord에 문의하면 친절한 답변을 받을 수 있다.

테스트넷 기준으로 Public Node는 초당 15~20회 API 응답속도를 가졌고, 구축한 Full Node는 초당 75~80회 API 응답속도로 환경에 따라서 변동은 있지만 최소 3배의 성능 향상을 얻었다고 볼 수 있다. 블록체인 서비스 운용에 있어서 Full Node 구축은 성능 향상뿐만 아니라 안정성을 가져 타 서비스에 비해 큰 이점을 제공한다. 이는 서비스 사용자에게 더 좋은 경험을 제공하면서 XPLA 생태계 발전에 기여도 가능하다.