[AI Payment #2] 같은 이더리움인데 가스비가 0원이라고? — Hyperledger Besu와 QBFT 톺아보기

이더리움 메인넷에서 USDC를 한 번 보내려면 수천 원이 듭니다. 가스비가 비쌀 땐 만 원이 넘기도 합니다.

그런데 같은 EVM, 같은 Solidity, 같은 OpenZeppelin 라이브러리를 쓰면서 트랜잭션 비용이 0원인 블록체인이 있다고 합니다.

처음 이 얘기를 들었을 때 솔직히 의심부터 들었습니다.. “EVM이 같은데 어떻게 비용 구조가 그렇게 다르지? 어디서 비용을 숨기고 있나?”

1편에서 x402가 깔린 진짜 이유 중 하나로 “L2 가스비 1센트 미만”을 얘기했었는데요. 회사에서 사업 아이디어를 검토하면서 한국형 AI 결제 인프라를 가정해보다 보니, L2가 아니라 허가형 블록체인 쪽도 직접 만져봐야겠다는 생각이 들었습니다.

그래서 Hyperledger Besu를 PoC로 직접 띄워봤습니다. 결론부터 말하면 정말로 0원이 가능했고, 그 이유는 의외로 단순했습니다.

바로 본론으로 들어가겠습니다!!

그래서 가스비가 0원이 어떻게 가능한가?

먼저 결론만 압축해서 말하면 이렇습니다.

공개형 블록체인의 가스비는 “스팸 방어 + 검증자 보상” 용도입니다.
허가형 블록체인은 검증자가 이미 알려진 기관(은행, 금융기관 등)이라 스팸 방어가 필요 없습니다.
검증자 보상도 운영비를 따로 정산하면 되니 가스비가 필요 없습니다.
그래서 설정 파일에 zeroBaseFee: true 한 줄과 노드 옵션 몇 개만 더하면 0원이 됩니다.

이걸 처음 봤을 때 든 생각은 하나였습니다.

“어? 이게 다라고?”

핵심 설정은 정말 단순했습니다. 하지만 이게 가능하려면 블록체인의 신뢰 모델 자체가 다르게 설계되어야 했습니다. 그게 공개형(Public)과 허가형(Permissioned)의 차이입니다.

공개형 vs 허가형 — 사실 다른 기술입니다

블록체인을 한 덩어리로 부르긴 하지만, 공개형과 허가형은 거의 다른 기술이라고 봐도 될 만큼 설계 철학이 다른 것 같습니다.

쉽게 비유하면 이렇습니다.

공개형 블록체인 = 인터넷 — 누구나 참여, 누구도 신뢰 안 됨, 그래서 비싸고 느림
허가형 블록체인 = 사내 인트라넷 — 알려진 참가자만 참여, 서로 신뢰, 그래서 싸고 빠름

공개형 vs 허가형 블록체인 비교

구분	공개형 (Ethereum, Bitcoin)	허가형 (Besu QBFT, Fabric)
참가자	누구나	사전 승인된 기관만
검증자	익명, 수만~수십만 명	식별 가능, 보통 4~20개
합의 알고리즘	PoW, PoS (확률적)	BFT 계열 (확정적)
블록 확정 시간	12초~10분	1~2초
가스비	필수 (스팸 방어 + 보상)	0원 설정 가능
TPS	15~30 (L1 기준)	수백~수천
거버넌스	코드와 포크	컨소시엄 합의

여기서 가장 중요한 건 합의 알고리즘의 차이인 것 같습니다. 공개형은 “익명의 다수가 어떻게든 합의에 도달”하는 문제를 풀어야 해서 PoW나 PoS 같은 확률적 합의를 씁니다. 반면 허가형은 검증자가 누구인지 다 아니까 BFT 계열의 확정적 합의가 가능합니다.

이게 왜 중요하냐면, BFT 합의는 블록이 확정되면 그걸로 끝이기 때문입니다. 공개형은 6블록 정도 기다려야 안전하다고 보는데, 허가형은 1블록이면 끝납니다.

금융 결제처럼 “이 거래가 확정됐는가?” 가 명확해야 하는 영역에서는 이게 결정적인 차이입니다.

Hyperledger 재단이란?

Besu 얘기로 들어가기 전에 Hyperledger 재단을 짧게만 짚고 가겠습니다.

Hyperledger는 2015년 Linux Foundation이 시작한 기업용 블록체인 우산 프로젝트입니다. IBM, Intel, JP모건 등 30개 기업이 founding members로 참여했고, 그 아래에 여러 블록체인 프로젝트가 있습니다.

Hyperledger 재단 우산 구조

주요 프로젝트만 정리하면 이렇습니다.

Hyperledger Fabric — IBM 주도. 가장 많이 쓰이는 허가형 블록체인. EVM 호환 안 함
Hyperledger Besu — ConsenSys 기여. EVM 호환되는 허가형 블록체인
Hyperledger Indy — 분산신원확인(DID) 특화
Hyperledger Cacti — 블록체인 간 상호운용

이 중에서 AI 결제 인프라를 가정했을 때 Besu가 유리한 이유는 EVM 호환 하나로 다 설명됩니다. 다음 섹션에서 풀어보겠습니다.

Besu를 택하는 진짜 이유 — EVM 호환의 힘

처음에는 Fabric도 후보였습니다. 사실 운영 사례나 자료 수만 보면 Fabric이 훨씬 많습니다. 그런데 파보면 팔수록 결론은 Besu로 기울었습니다.

이유는 단 하나, EVM 호환 때문입니다.

EVM 호환 생태계

EVM 호환이라는 게 단순히 “Solidity로 컨트랙트 짤 수 있다” 수준이 아닙니다. 그 위에 쌓여 있는 15년치 이더리움 생태계 도구를 그대로 쓸 수 있다는 의미입니다.

영역	도구	Besu에서 사용 가능?
스마트계약 언어	Solidity, Vyper	✅
표준 라이브러리	OpenZeppelin	✅
토큰 표준	ERC-20, ERC-721, ERC-3009	✅
개발 프레임워크	Hardhat, Foundry	✅
지갑	MetaMask, WalletConnect	✅
서명 표준	EIP-712	✅
AI 결제 표준	x402 (Coinbase)	✅

특히 마지막이 결정적입니다. 1편에서 봤듯이 x402가 EIP-712 + EIP-3009를 전제로 설계되어 있는데, 이게 전부 EVM 호환 환경을 가정합니다. Fabric으로 가면 이 표준들을 처음부터 새로 만들어야 합니다..

반면 Besu는 같은 EVM이라 공개형 이더리움에서 검증된 컨트랙트를 거의 그대로 올릴 수 있습니다. 이게 작은 차이처럼 보이는데, 실제 PoC를 만져보면 개발 시간이 압도적으로 차이가 납니다.

QBFT 합의 알고리즘 — 2/3의 마법

자, 이제 Besu의 핵심 합의 알고리즘인 QBFT(Quorum Byzantine Fault Tolerance) 를 톺아보겠습니다.

QBFT는 BFT 계열 합의 알고리즘인데, 핵심은 “검증자의 2/3 이상이 동의하면 블록 확정” 이라는 단순한 규칙입니다.

QBFT 합의 프로세스

여기서 갑자기 의문이 듭니다. 2/3? 왜 절반(1/2)이 아니라 2/3일까요?

이건 분산 시스템에서 유명한 “비잔틴 장군 문제” 와 연결됩니다. 검증자 중 일부가 악의적으로 행동할 수 있다고 가정할 때, 시스템이 정상 작동하려면 다음 공식이 필요합니다.

N ≥ 3f + 1

N = 전체 검증자 수
f = 허용 가능한 악의적 검증자 수

이 공식이 의미하는 건 이렇습니다.

검증자 4명이면 → 1명까지 배신 OK (4 ≥ 3×1+1)
검증자 7명이면 → 2명까지 배신 OK (7 ≥ 3×2+1)
검증자 10명이면 → 3명까지 배신 OK (10 ≥ 3×3+1)

그래서 검증자 4명짜리 네트워크에선 3명(=2/3 이상)이 동의해야 블록이 확정됩니다.

이 알고리즘의 진짜 이점은 블록이 확정되는 순간 되돌릴 수 없다는 점인 것 같습니다. 공개형 이더리움은 51% 공격 같은 이론적 롤백 가능성이 있는데, QBFT는 한 번 합의되면 그걸로 끝입니다.

금융 결제에는 이게 매우 중요합니다. “이 결제가 확정됐는가?”라는 질문에 “네, 1초 안에” 라고 답할 수 있어야 하니까요!!

free-gas 모드의 비밀 — 그 한 줄, 그리고 함정

자, 이제 도입부에서 던졌던 의문의 답입니다. 가스비가 어떻게 0원이 되는가?

Besu에서는 genesis.json 파일에 이 한 줄이 핵심입니다.

{
  "config": {
    "chainId": 1337,
    "londonBlock": 0,
    "zeroBaseFee": true,
    "qbft": {
      "blockperiodseconds": 2,
      "epochlength": 30000,
      "requesttimeoutseconds": 4
    }
  }
}

zeroBaseFee: true. 정말 핵심은 이게 다입니다..

근데 자료만 보고 따라 하다가 첫 트랜잭션을 날렸을 때 다음 에러를 받았습니다.

{"code":-32009,"message":"Gas price below configured minimum gas price"}

genesis.json에 zeroBaseFee: true를 분명히 넣었는데도 트랜잭션이 거부됩니다.. 한참을 헤매다 공식 문서를 다시 봤더니, 빠뜨린 게 있었습니다.

free-gas 메커니즘

free-gas가 실제로 작동하려면 모든 노드를 시작할 때 다음 옵션을 같이 줘야 합니다.

besu --genesis-file=genesis.json \
     --min-gas-price=0 \
     --api-gas-price-max=0 \
     ...

--min-gas-price=0을 한 노드라도 빠뜨리면, 그 노드는 gas price가 0인 트랜잭션을 조용히 drop 합니다. 에러 메시지가 친절하게 나오지도 않습니다. 디버깅하기 진짜 까다로웠습니다..

그래도 본질은 단순합니다. genesis.json의 한 줄 + 노드 옵션 한 줄, 이렇게 두 곳만 맞추면 가스비 0원이 됩니다.

그런데 왜 이게 가능한지, 그 원리를 한번 따라가보겠습니다.

공개형 이더리움에서 가스비가 존재하는 이유는 크게 두 가지입니다.

스팸 방어 — 익명의 누군가가 무한정 트랜잭션을 날리는 걸 막아야 함
검증자 보상 — 채굴자/검증자가 블록을 만들 경제적 유인

그런데 허가형 블록체인은 이 두 문제가 이미 해결되어 있습니다.

스팸 방어 → 검증자가 사전 승인된 기관이고, 클라이언트도 인증을 거쳐서 접속함. 스팸 자체가 발생할 수 없는 구조
검증자 보상 → 검증자가 컨소시엄 멤버이고, 운영비는 별도로 정산(예: 회원 분담금). 가스비로 보상받을 필요 없음

그래서 두 이유가 다 사라지니, 가스비도 사라지는 게 자연스럽습니다!! 결국 가스비는 공개형의 특수한 신뢰 모델 때문에 필요했던 것이지, 블록체인 기술 자체의 본질이 아니었던 것 같습니다.

이걸 깨닫고 나서야 1편에서 봤던 “L2 가스비 1센트 미만”이라는 표현이 더 명확해졌습니다. L2는 공개형의 신뢰 모델을 일부 유지하면서 비용을 낮춘 거고, 허가형은 신뢰 모델 자체를 바꿔서 비용을 아예 0으로 만든 것입니다.

TPS의 솔직한 평가 — 만능은 아닙니다

여기까지 보면 “Besu가 무조건 좋은 거 아닌가?” 싶지만, 솔직히 한계도 명확합니다.

가장 큰 한계는 TPS(초당 트랜잭션 수) 입니다.

결제 인프라별 TPS 비교

시스템	TPS	비고
Bitcoin	7	공개형, PoW
Ethereum L1	15~30	공개형, PoS
Hyperledger Besu QBFT	420~1,000	허가형 (공식 벤치마크, 4-validator/free-gas)
Visa	24,000 (평균), 65,000 (피크)	카드망

Besu의 420 TPS는 공개형 이더리움보다는 압도적으로 빠르지만, 카드망(Visa)에는 한참 못 미칩니다. 튜닝을 해도 1,000 TPS급이 한계이고, 이건 검증자 간 합의 메시지가 네트워크를 오가야 하는 BFT의 구조적 한계인 것 같습니다.

그래서 Besu는 모든 결제를 대체하는 인프라가 아니라, 특정 영역에 적합한 인프라입니다. 예를 들어:

✅ AI 에이전트의 초소액·고빈도 결제 — 건당 단가는 작지만 처리 속도가 핵심
✅ 기관 간 정산 (B2B) — 거래 빈도가 많지 않고 신뢰성이 중요
❌ 카드망 전체 대체 — TPS가 1~2 자릿수 모자람
❌ 공개형 토큰 거래소 — 누구나 참여하는 시장에는 부적합

그러면 “Besu가 무조건 답인가?”라는 질문에는 솔직히 “용도에 따라 다르다” 가 답인 것 같습니다.

PoC로 직접 만져본 후기 — 함정들

자료를 보고 이해한 것과 직접 띄워보는 건 또 다른 얘기였습니다.. 한 달 정도 만져보면서 부딪힌 함정들을 정리해보겠습니다. (위에서 다룬 free-gas 옵션 함정 외에도 몇 가지 더 있었습니다!!)

함정 1: 한국어 자료가 거의 없습니다

이게 가장 큰 함정이었습니다. Besu 공식 문서는 영어로 잘 되어 있는데, 한국어로 된 실전 튜토리얼이 정말 없습니다. 블로그 글도 대부분 “설치해봤다” 수준에서 끝나고, 실제 운영 노하우가 담긴 글은 거의 없었습니다.

결국 공식 문서 + GitHub 이슈 + Discord 커뮤니티 글들을 뒤져가며 진행해야 했습니다.

함정 2: extraData를 직접 만들려고 하지 마세요

QBFT 네트워크를 띄울 때 genesis.json의 extraData 필드에 검증자 주소들이 RLP 인코딩되어 들어가야 합니다. 처음엔 이걸 어떻게 만들어야 하는지 한참 찾았습니다..

다행히 Besu가 헬퍼 커맨드를 제공합니다.

# 검증자 키 + extraData가 들어간 genesis.json을 자동 생성
besu operator generate-blockchain-config \
  --config-file=qbftConfigFile.json \
  --to=networkFiles \
  --private-key-file-name=key

qbftConfigFile.json에 검증자 수만 적어주면 키 페어와 extraData가 들어간 genesis.json이 한 번에 만들어집니다. 이걸 모르고 손으로 RLP 인코딩하려고 하면.. 정말 힘듭니다.

함정 3: Docker Compose의 부트노드 enode 주소

4-validator 네트워크를 Docker Compose로 구성할 때, 각 노드가 서로를 발견하려면 부트노드의 enode 주소가 필요합니다. 그런데 이 주소는 노드가 처음 켜질 때 생성됩니다.

# 부트노드를 먼저 띄우고
bootnode:
  image: hyperledger/besu:latest
  command:
    - --p2p-host=0.0.0.0
    - --p2p-port=30303
    - --rpc-http-enabled

# 다른 노드는 부트노드 enode를 환경변수로 주입
validator2:
  depends_on:
    - bootnode
  command:
    - --bootnodes=enode://...@bootnode:30303

저는 처음에 docker-compose up 한 번에 다 띄우려고 했는데, 부트노드 enode를 모르니까 다른 노드들이 서로를 못 찾는 상황이 생겼습니다. 결국 부트노드를 먼저 띄워서 enode 주소를 확인한 다음 다른 노드를 띄우는 2단계 절차로 가야 했습니다.

함정 4: nonce 관리

EVM 호환이라 좋긴 한데, nonce 충돌이 의외로 자주 났습니다. 트랜잭션을 빠르게 연속으로 보내면 클라이언트 라이브러리가 nonce를 제대로 추적 못 해서 reject가 발생합니다.

이건 ethers.js나 web3.js의 nonce 관리 로직을 직접 다뤄야 해서 따로 정리할 일이 많았습니다.. (특히 EIP-3009 같은 사전 서명 방식에서 nonce 관리가 어떻게 다른지는 다음 편(3편 x402 톺아보기)에서 자세히 다뤄볼 예정입니다!!)

Besu vs Fabric — 정리하면

마지막으로 Besu와 Fabric을 어떻게 선택해야 할지 한번 정리해보겠습니다.

Besu vs Fabric 결정 트리

핵심 질문은 이거입니다.

“기존 이더리움 생태계 도구를 그대로 쓰고 싶은가?”

상황	적합한 선택
x402, ERC-20, EIP-712 같은 이더리움 표준을 활용해야 함	Besu
외부 공개 체인과 상호운용 가능성이 있음	Besu
완전히 폐쇄된 컨소시엄, 표준 호환 필요 없음	Fabric
채널별 격리(다자 거래)가 중요함	Fabric
운영 사례·레퍼런스가 많이 필요함	Fabric

저는 AI 결제 인프라처럼 글로벌 표준(x402)을 채택해야 하는 영역에서는 Besu가 거의 유일한 선택지인 것 같습니다. Fabric은 표준이 다 따로 놀기 때문에, x402 같은 글로벌 흐름에 올라타려면 결국 EVM 호환이 답이라고 봅니다.

2편을 마치며

정리하면 이번 글에서 얻은 통찰은 이렇습니다.

“블록체인은 비싸고 느리다”는 공개형 한정 — 신뢰 모델이 다르면 트레이드오프도 완전히 달라짐
가스비는 본질이 아니라 신뢰 모델의 부산물 — 스팸 방어와 검증자 보상이 필요 없으면 0원이 자연스러움
QBFT의 2/3 합의는 비잔틴 장군 문제의 답 — N ≥ 3f+1 공식이 BFT 계열 합의의 토대
Besu의 진짜 가치는 EVM 호환 — 15년치 이더리움 생태계 도구를 그대로 쓸 수 있다는 것이 핵심
TPS 420~1,000은 만능이 아님 — 카드망 대체용은 아니지만, AI 에이전트 결제 영역에는 충분

특히 1번이 한 달간 파면서 가장 크게 깨진 고정관념이었습니다.. “블록체인 = 비싸고 느림”이라는 인식이 너무 강해서, “0원에 1초”가 가능하다는 걸 처음엔 받아들이기 어려웠습니다.

다음 편에서는 1편에서 살짝만 다뤘던 x402 프로토콜의 깊은 부분 — Facilitator의 동작 원리, EIP-3009의 서명 구조, replay attack 방어 메커니즘 — 을 자세히 톺아보려 합니다!

다음 글에서 이어가겠습니다!!

감사합니다!!

Besu 4-validator 네트워크 구조

Besu 4-validator 네트워크

[AI Payment #2] 같은 이더리움인데 가스비가 0원이라고? — Hyperledger Besu와 QBFT 톺아보기

그래서 가스비가 0원이 어떻게 가능한가?

공개형 vs 허가형 — 사실 다른 기술입니다

Hyperledger 재단이란?

Besu를 택하는 진짜 이유 — EVM 호환의 힘

QBFT 합의 알고리즘 — 2/3의 마법

free-gas 모드의 비밀 — 그 한 줄, 그리고 함정

TPS의 솔직한 평가 — 만능은 아닙니다

PoC로 직접 만져본 후기 — 함정들

함정 1: 한국어 자료가 거의 없습니다

함정 2: extraData를 직접 만들려고 하지 마세요

함정 3: Docker Compose의 부트노드 enode 주소

함정 4: nonce 관리

Besu vs Fabric — 정리하면

2편을 마치며

Besu 4-validator 네트워크 구조

MiloDev

Error

그래서 가스비가 0원이 어떻게 가능한가?

공개형 vs 허가형 — 사실 다른 기술입니다

Hyperledger 재단이란?

Besu를 택하는 진짜 이유 — EVM 호환의 힘

QBFT 합의 알고리즘 — 2/3의 마법

free-gas 모드의 비밀 — 그 한 줄, 그리고 함정

TPS의 솔직한 평가 — 만능은 아닙니다

PoC로 직접 만져본 후기 — 함정들

함정 1: 한국어 자료가 거의 없습니다

함정 2: extraData를 직접 만들려고 하지 마세요

함정 3: Docker Compose의 부트노드 enode 주소

함정 4: nonce 관리

Besu vs Fabric — 정리하면

2편을 마치며

Besu 4-validator 네트워크 구조

Templates (for web app):

Error