길리랩blog

블록체인 TPS와 지연 시간을 함께 다루는 성능 최적화

블록체인 TPS, 블록 생성 시간, 지연 시간과 확정성을 기준으로 합의·네트워크·실행·스토리지 계층의 성능 최적화 방법을 정리합니다.

2026-08-14 · 최초 발행 2025-10-31

TPS와 확정성 사이에서 성능을 읽는 법

블록체인 성능은 공공망과 컨소시엄망 모두에서 처리량, 블록 생성 시간, 지연 시간을 함께 관리하는 문제다. TPS를 높여도 전파와 검증이 따라가지 못하면 확정까지의 시간이 늘거나 포크 위험이 커질 수 있다.

TPS는 초당 처리 가능한 트랜잭션 수를 뜻한다. 대략적으로는 다음과 같이 볼 수 있다.

  • TPS ≈ (블록당 트랜잭션 수) / (블록 생성 시간)
  • 가스 모델에서는 TPS ≈ (Block Gas Limit) / (평균 Tx Gas) / (Block Time)

블록 생성 시간은 블록 제안 사이의 평균 간격이다. 합의 방식, 네트워크 전파 지연, 노드 부하가 이 값을 좌우한다. 간격을 줄이면 대기시간을 낮출 수 있지만, 공공망에서는 오펀·엉클 비율과 포크율이 높아질 수 있다.

지연 시간은 트랜잭션 제출부터 확정성에 도달하기까지의 전체 시간이다. 클라이언트와 메모리풀에서의 대기, 네트워크 전파, 합의 라운드 또는 파이프라인, 블록 포함, 확정성 도달이 모두 포함된다.

확정성의 성격도 성능 판단에 영향을 준다. Tendermint와 HotStuff 같은 BFT 계열은 블록 커밋 시 결정적 확정성을 제공한다. 반면 PoW·PoS 기반 나카모토 합의 계열은 일정 확인 수 이후 안전하다고 보는 확률적 확정성을 사용한다.

병목은 계층별로 나타난다

합의 방식과 블록 파라미터

Tendermint·HotStuff 같은 BFT 계열은 낮은 블록 타임(≈1s 가능)과 즉시 확정성을 제공하지만, 검증자 수와 네트워크 품질에 민감하다. 나카모토 계열은 높은 탈중앙성과 검열 저항을 제공하는 대신 블록 타임을 과도하게 낮추면 포크율이 증가할 수 있다.

타임아웃, 라운드 체인지(view change), 파이프라인 단계 수는 처리량과 지연에 직접 영향을 준다. 값을 짧게 설정하면 TPS와 지연이 개선될 수 있지만, 네트워크 품질이 낮을 때는 재시도가 늘어난다.

가십 전파와 피어 구성

P2P 전파에서는 피어 수, 랜덤·메쉬 형태의 토폴로지, 메시지 배치와 압축, 블록·트랜잭션 우선순위 큐를 함께 다룬다. 피어가 지나치게 많으면 대역폭과 CPU가 낭비되고, 너무 적으면 전파가 늦어진다. 환경에 맞는 경험적 최적점을 찾아야 한다.

MTU와 버퍼, TLS·암호화 오버헤드, RTT와 패킷 손실도 고려 대상이다. 리전이 분산된 환경에서는 릴레이 노드를 배치해 전파 경로를 조정할 수 있다.

실행 엔진과 메모리풀

EVM·WASM 실행 비용, 상태 접근 과정의 Trie·DB I/O, 가스 스케줄, JIT·인터프리터 성능이 실행 계층의 처리량을 제한한다. 계정·스토리지 충돌을 피할 수 있는 병렬 실행은 TPS를 높일 잠재력이 있지만, 구현과 안전성 검증이 필요하다(최신 정보 확인 필요).

메모리풀은 수수료, 도착 시간, 종속성을 기준으로 정렬할 수 있다. 크기 제한과 스팸 방어 정책, 배치 구성 효율은 TPS와 지연 시간 모두에 영향을 준다.

상태와 스토리지

블록 크기나 가스 리밋은 블록당 연산량의 상한이다. 값을 키우면 TPS는 증가할 수 있지만, 전파와 검증 지연 때문에 전체 지연이 오히려 늘어날 수 있다.

LevelDB·RocksDB 옵션, 캐시, 스냅샷, 프루닝 정책을 조정하고 아카이브 노드와 프루닝 노드를 혼합 운영하는 방식이 상태 관리에 쓰인다. 상태 팽창을 억제하는 작업도 빠질 수 없다.

L1 밖으로 넓히는 확장 계층

Optimistic·ZK 롤업, 채널, 샤딩은 L1 보안을 유지하면서 TPS를 크게 확대하는 수단이다. 대신 지연 시간, 확정성, 운영 복잡도 사이의 트레이드오프가 생긴다. 데이터 가용성(DA)과 증명 지연도 전체 지연 시간에 추가된다.

측정값을 기준으로 튜닝 순서를 잡는다

먼저 TPS(P50/P95), 트랜잭션 지연(P50/P95/P99), 블록 전파 시간, 포크·오펀율, CPU·메모리·디스크·네트워크 사용률을 수집한다. 읽기·쓰기 비율, 스마트컨트랙트 가스 패턴, 서명 검증 비중, 키·값 접근 지역성까지 반영한 테스트 프로파일을 만들고 Caliper 또는 Locust+SDK 등을 활용한다.

합의와 블록 파라미터는 가스 리밋을 높이거나 블록 타임을 줄여 TPS를 높일 수 있다. 다만 전파 지연과 검증 비용이 임계치를 넘으면 역효과가 난다. BFT 타임아웃 값은 네트워크 RTT의 3~5배 가이드가 있으며, 파이프라인 단계를 늘리면 처리량은 높아지는 대신 장애 시 재시도 오버헤드도 커진다.

퍼블릭망에서는 30~60 피어 범위에서 최적점을 탐색할 수 있다. 컨소시엄망은 허브형 또는 스패닝 트리와 릴레이 노드 구성을 통해 대역폭을 절감한다. 블록 우선 전파, 트랜잭션 배치 크기 조정, Snappy·Zstd 압축, 고지연 구간의 중간 캐시·프록시 배치도 검토 대상이다.

실행 계층에서는 수수료 기반 우선순위와 동일 발신자 쿼터로 메모리풀 노이즈를 억제하고, 대형 트랜잭션이 배치를 혼잡하게 만들지 않도록 한다. JIT·WASM 최적화, 상태 캐시 확장, 트라이 업데이트 배치를 적용할 수 있으며, 병렬 실행을 도입할 때는 충돌 감지와 롤백 비용을 고려한다.

RocksDB에서는 블록 캐시·바이트 버퍼와 Compaction 전략(Level/Universal)을 조정할 수 있다. 스냅샷과 프루닝은 IOPS를 줄이는 데 쓰이며, 임대·가비지 정책, 이벤트 인덱스 외부화, L2 오프로딩은 스테이트 성장을 억제하는 선택지다.

블록 타임을 지나치게 줄이면 포크율 상승, 합의 실패, 가용성 저하로 이어질 수 있다. 가스 리밋을 과도하게 높이면 전파 지연과 노드 탈락 위험이 커진다. 단계적 롤아웃, 다크 런, 가시성 대시보드, SLO 위반 시 자동 롤백을 함께 준비해야 한다.

트랜잭션이 확정되기까지의 경로

⤢✕State/DBConsensusGossip NetworkValidator/Full NodeClientState/DBConsensusGossip NetworkValidator/Full NodeClientLatency = enqueue + propagation + consensus + execution + finalityalt[Timeout/Byzantin-e]Tx SubmitMempool enqueue (fee/nonce check)Tx Gossip (batch/compress)Tx propagation to validatorsPropose Block (selected tx batch)Prevote/Precommit or Slot finalizationCommit BlockApply state changes (write set, trie)Tx Included + (Finality status)View change / new round

선택지별 성능과 운영 부담

전략 성능 확장성 일관성/확정성 안정성 운영 편의
보수적 L1 파라미터(기본) 중간 TPS, 안정 지연 제한적(수직 확장) 높음(포크율 낮음) 높음 높음(기본값 유지)
공격적 L1 튜닝(블록 타임↓, 가스↑) TPS↑, 지연↓(정상 시) 제한적, 노드 스펙↑ 필요 포크/오펀 위험↑ 중간(네트워크 품질 민감) 중간(지속 모니터링)
L2 롤업(Optimistic/ZK) L2 TPS 매우 높음 높음(수평 확장) L1 보안 상속, 증명 지연 존재 높음(분리된 장애 영역) 중간~낮음(브릿지/운영 복잡)

환경에 따라 달라지는 적용 장면

컨소시엄 체인 결제망에서는 BFT 합의와 블록 타임 1s, MaxTx/Block 2k 설정을 사용할 수 있다. 데이터센터 3개 리전에 릴레이 노드를 배치해 전파 시간 <150ms를 확보하는 구성이다.

퍼블릭 L1의 파라미터를 조정하는 경우에는 블록 가스 리밋을 15M→25M으로 상향하고, 전파 지연 P95 350ms 미만을 유지 조건으로 삼을 수 있다. 포크율을 모니터링하면서 점진적으로 적용한다.

거래소 입출금에서는 확률적 확정성 체인의 컨펌 수를 20→12로 조정하고 MEV 리오그 모니터링을 연동할 수 있다. 이 구성에서는 평균 입금 지연이 40% 감소한다.

IoT 데이터 집계에서는 L2 옵티미스틱 롤업에 배치 인서트를 보내고 L1에는 체크포인트를 기록한다. 지연에 민감한 이벤트는 채널로 처리한다.

계산으로 보는 블록 파라미터의 영향

Block Gas Limit=30,000,000, 평균 Tx Gas=50,000, Block Time=12s라고 가정한다.

  • 블록당 트랜잭션 수 ≈ 30,000,000 / 50,000 = 600건
  • TPS ≈ 600 / 12 = 50 TPS
  • Block Time을 4s로 단축하면 이론 TPS ≈ 600 / 4 = 150 TPS
  • 전파 지연과 검증 부하를 반영한 실효 TPS는 120~140 TPS 범위이며 네트워크 품질에 의존한다.

이 조정은 사용자 체감 대기시간을 줄이고 피크 부하 흡수 능력을 높일 수 있다. 비용·수수료의 안정성과 운영 예측 가능성도 함께 개선 대상이 된다.

Geth PoA 개발망에서 파라미터 조정하기

환경은 go-ethereum v1.13+, Linux x86_64, 로컬/동일 리전이다. 블록 타임 2s, 블록 가스 리밋 30M, txpool 튜닝을 목적으로 한다.

genesis.json 발췌:

{
  "config": {
    "chainId": 1337,
    "clique": { "period": 2, "epoch": 30000 }
  },
  "gasLimit": "0x01C9C380"
}

노드 실행:

geth --networkid 1337 --http --http.api eth,net,web3,txpool \
  --txpool.globalslots 32768 --txpool.accountslots 2048 \
  --cache 4096 --syncmode full

period를 1s 이하로 낮추면 로컬 환경 외 전파 지연이 증가할 때 오펀율이 상승할 위험이 있다.

Fabric 오더러 배치 크기와 타임아웃

환경은 Fabric v2.5, Kafka/Raft 오더링, 동일 리전 권장 구성이다. 블록 크기와 타임아웃을 조정해 지연과 처리량의 균형을 맞춘다.

configtx.yaml 발췌:

Orderer:
  BatchTimeout: 1s
  BatchSize:
    MaxMessageCount: 500
    AbsoluteMaxBytes: 15 MB
    PreferredMaxBytes: 2 MB

BatchTimeout↓는 지연↓로 이어지지만, 작은 배치가 지나치면 TPS↓가 될 수 있다. 네트워크와 피어 검증 시간을 감안해 단계적으로 조정한다.

운영 중 지켜볼 신호

Canary·Shadow 노드에서 파라미터를 먼저 검증하고, 슬로우 스텝(10~20%)으로 증분 적용한다. 블록 전파 시간, 포크율, 합의 라운드 재시도, DB 대기열, GC·메모리 프래그먼트 메트릭은 대시보드에서 지속적으로 확인한다.

장애에 대비해 파라미터 리버트 스위치, 합의 타임아웃 상향 자동화, 릴레이 재배치 스크립트를 준비한다. 가스·수수료 바닥과 per-sender rate limit으로 스팸을 방어하고, 동시 검증 상한과 P2P 유입 제한으로 DoS를 완화한다.

단기에는 합의 타임아웃, 메모리풀, 네트워크 배치를 다듬는다. 이후 스토리지와 상태 관리, 블록 파라미터 재설계를 검토하고, 장기적으로는 L2·샤딩 같은 구조적 확장을 병행한다. 체인별 최신 릴리스와 기본값은 최신 정보 확인이 필요하다.

블록체인TPS지연 시간합의 알고리즘롤업