상호운용성을 위한 합의 모델의 트레이드오프: 크로스 체인 브리지 보안에서의 PoW, PoS, DPoS 및 BFT
2025년 상반기에만 크로스 체인 브리지에서 23억 달러 이상의 자금이 탈취되었습니다. 이는 이미 2024년 전체 피해액을 넘어선 수치입니다. 업계의 논의가 주로 스마트 컨트랙트 감사와 멀티시그 (multisig) 키 관리에 집중되어 있는 반면, 조용하지만 그만큼 치명적인 취약점인 '서로 다른 블록체인이 합의에 도달하는 방식과 브리지가 이를 가정하는 방식 간의 불일치'는 종종 간과되곤 합니다.
모든 크로스 체인 브리지는 완결성 (finality) 에 대해 암묵적인 가정을 합니다. 이러한 가정이 소스 (source) 또는 대상 (destination) 체인의 실제 합의 모델과 충돌할 때, 공격자는 악용할 수 있는 틈을 발견하게 됩니다. PoW, PoS, DPoS, BFT 합의 메커니즘이 어떻게 다른지, 그리고 이러한 차이점이 브리지 설계 선택과 메시징 프로토콜 선정에 어떻게 영향을 미치는지 이해하는 것은 오늘날 Web3 인프라에서 가장 중요한 주제 중 하나입니다.
브리지에 있어 완결성이 실제로 의미하는 것
합의 유형을 비교하기 전에, 브리지가 체인의 합의 계층에서 실제로 필요로 하는 것이 무엇인지 명확히 할 필요가 있습니다. 그것은 바로 완결성 (finality), 즉 커밋된 트랜잭션이 되돌려질 수 없다는 보장입니다.
완결성에는 두 가지 형태가 있습니다:
- 확률적 완결성 (Probabilistic finality): 트랜잭션 위에 더 많은 블록이 쌓일수록 보안성이 높아지지만, 수학적으로 비가역성이 절대적이지는 않습니다. 비트코인이 전형적인 예시입니다.
- 확정적 완결성 (Deterministic/Instant finality): 검증인의 절대 다수 (supermajority) 에 의해 블록이 커밋되면 되돌릴 수 없습니다. 대부분의 BFT 기반 체인이 이러한 보장을 제공합니다.
브리지에 있어 이 차이는 엄청납니다. 비트코인 예치금이 6개의 블록 이후에 확인되었다고 간주하는 브리지는 확률적인 도박을 하는 것과 같습니다. 반면, 단일 블록 커밋 후에 Cosmos IBC 전송을 확정하는 브리지는 CometBFT 합의 엔진에 내장된 확정적 보장에 의존하는 것입니다.
연결된 체인 간에 완결성 모델이 다를 경우, 브리지는 통계적으로 안전해질 때까지 충분히 기다리거나 리버설 (reversal) 위험을 감수해야 합니다. 이 판단을 그르친 대가로 업계는 수십억 달러의 비용을 치러야 했습니다.
PoW: 강력한 보안, 느린 완결성, 브리지에 비우호적임
비트코인과 같은 작업 증명 (Proof-of-Work) 체인은 베이스 레이어에서 뛰어난 시빌 저항성 (Sybil resistance) 과 검증된 보안을 제공합니다. 비트코인에 대한 51% 공격 비용은 현재 해시 레이트 기준으로 시간당 수십억 달러로 추정되며, 이는 깊은 블록 재구성 (reorganization) 을 경제적으로 불가능하게 만듭니다.
하지만 이러한 보안은 브리지 설계자에게 비용을 발생시킵니다:
- 확률적 완결성만 존재: 비트코인 블록이 "완결"되는 명확한 기준점은 없습니다. 6번의 컨펌 (약 60분) 은 관습일 뿐 프로토콜이 아닙니다.
- 느린 블록 생성 시간: 비트코인의 평균 블록 생성 시간은 10분으로, 브리지는 한 시간을 기다리거나 리버설 위험을 감수해야 합니다.
- 리오그 (Reorg) 윈도우: 충분한 컨펌이 이루어지기 전에 예치를 처리하는 브리지는 블록체인 재구성을 통한 이중 지불 공격에 취약합니다.
진정한 위험은 해시 파워가 약한 PoW 체인 (비트코인이 아닌 소규모 PoW 체인) 이 가치가 높은 DeFi 생태계에 브리징될 때 발생합니다. 이더리움 클래식 (Ethereum Classic) 은 2020년에 51% 공격을 받았으며, 당시 ETC 예치를 너무 빨리 완결된 것으로 처 리한 브리지는 공격의 대상이 되었을 것입니다.
가장 적합한 메시징 프로토콜: PoW 체인은 효율적인 증명 검증을 위한 라이트 클라이언트 (light client) 지원이 부족하기 때문에, 이를 연결하는 브리지는 일반적으로 암호학적 완결성 증명보다는 외부 검증인이나 오라클 위원회에 의존합니다. Axelar (DPoS 보안 검증인 네트워크) 나 LayerZero의 Oracle+Relayer 모델이 IBC 스타일의 라이트 클라이언트 브리지보다 적합합니다. 후자는 효율적인 운영을 위해 소스 체인이 즉각적인 완결성을 가져야 하기 때문입니다.
PoS: 개선된 완결성, 하지만 체크포인트의 복잡성
이더리움의 지분 증명 (Proof-of-Stake) 전환은 크로스 체인 브리지 설계에 상당한 개선을 가져왔습니다. 이더리움의 합의 계층 (구 이더리움 2.0) 은 LMD-GHOST 포크 선택과 Casper FFG 완결성을 결합하여 사용하며, 이는 매 2 에포크 (약 12.8분) 마다 경제적 완결성을 제공합니다.
브리지 입장에서 이는 비트코인에 비해 유의미한 업그레이드입니다:
- 완결된 체크포인트는 스테이킹된 ETH의 절대 다수에 의해 암호학적으로 커밋됩니다.
- 완결된 체크포인트를 지난 재구성은 스테이킹된 전체 ETH의 3분의 1 이상 (현재 수백억 달러 규모) 을 슬래싱 (slashing) 해야 합니다.
- 라이트 클라이언트는 이더리움 의 싱크 위원회 (Sync Committee) 서명을 검증할 수 있어, 더욱 신뢰 최소화된 (trustless) 브리지 설계가 가능합니다.
그러나 PoS는 고유한 복잡성을 수반합니다:
- 검증인 세트 교체: 브리지 라이트 클라이언트는 검증인 세트의 변경을 추적해야 합니다. 오래된 라이트 클라이언트는 더 이상 존재하지 않는 검증인 세트가 서명한 증명을 수락할 위험이 있습니다.
- 즉각적이지 않은 슬래싱 처벌: 경제적 제재는 공격을 억제하지만, 완결 전의 짧은 창구 동안 공격을 완전히 방지하지는 못합니다.
- 완결성 체크포인트로 인한 지연: Casper FFG 완결성을 기다리는 브리지는 크로스 체인 트랜잭션 시간에 12-13분을 추가하게 됩니다. 이는 거액 송금에는 용인될 수 있지만, 일반적인 DeFi 사용자에게는 답답한 시간입니다.
가장 적합한 메시징 프로토콜: 이더리움의 PoS 모델은 ZK 증명 기반 브리지 설계와 점점 더 호환되고 있습니다. Succinct의 Telepathy와 같은 신흥 프로토콜은 ZK-SNARK를 사용하여 이더리움의 싱크 위원회 서명을 온체인에서 검증함으로써, 합리적인 지연 시간 내에 신뢰가 최소화된 브리징을 가능하게 합니다. ZK 증명 DVN (Decentralized Verifier Networks) 을 지원하는 LayerZero v2 또한 검증 가능한 암호학적 상태 증명을 노출하는 PoS 체인과 잘 부합합니다.
DPoS: 빠른 합의, 검증인 세트 위험성
EOS, BNB 체인, 그리고 특히 Axelar의 검증인 네트워크 자체에서 사용되는 위임 지분 증명 (Delegated Proof-of-Stake, DPoS) 시스템은 더 빠른 합의를 달성하기 위해 선출된 소수의 검증인 세트를 도입합니다.
브릿지를 위한 DPoS의 장점:
- 빠른 블록 생성 시간 및 즉각적인 최종성에 근접: 21개에서 101개 사이의 활성 검증인을 보유한 BNB 체인은 약 3초 만에 블록을 확정하며, 약 15초 내에 실질적인 최종성에 도달합니다.
- 예측 가능한 검증인 세트: 검증인 세트가 느린 투표 주기에 따라 변경되므로 브릿지는 더 가벼운 증명을 유지할 수 있습니다.
- 낮은 컴퓨팅 부하: 검증인 수가 적다는 것은 검증해야 할 서명 수도 적다는 것을 의미합니다.
하지만 DPoS는 공격 표면을 압축합니다:
- 공모 위험: 선출된 대리인의 절대다수 (일부 체인에서는 21명 중 11명 정도로 적을 수 있음)가 이론적으로 공모하여 합의를 조작할 수 있습니다. EOS에서는 대리인 선거에서의 투표 매수 공격이 기록된 바 있습니다.
- 카르텔 역학: 실제로 소수의 실체가 여러 대리인 슬롯을 장악하는 경우가 많아 탈중앙화가 저해됩니다.
- 키 탈취 연쇄 작용: 브릿지가 DPoS 검증인 세트에 의존하고 여러 검증인이 동시에 해킹당할 경우, 해당 체인과 함께 브릿지의 보안도 무너집니다.
Axelar 네트워크는 흥미로운 사례입니다. Axelar는 그 자체로 DPoS 체인 (CometBFT 합의와 75개 이상의 활성 검증인을 갖춘 Cosmos SDK 기반)이며, 크로스 체인 메시지 전달을 위한 허브 역할을 합니다. Axelar 가 전달하는 모든 메시지의 보안은 궁극적으로 AXL 스테이킹의 경제적 보안에 의해 뒷받침됩니다. 이는 브릿지 보안 모델을 명시적이고 정량화할 수 있게 만드는 의도적인 설계입니다.
최적의 메시징 프로토콜: DPoS 체인은 목적에 맞게 구축된 DPoS 합의 레이어가 크로스 체인 메시지를 보호하는 Axelar와 같은 허브 앤 스포크 (hub-and-spoke) 상호운용성 아키텍처와 자연스럽게 어울립니다. DPoS 체인이 호환 가능한 라이트 클라이언트 인터페이스를 제공한다면 IBC와 같은 포인트 투 포인트 (point-to-point) 프로토콜도 작동할 수 있지만, 검증인 세트가 작기 때문에 암호학적 보안 임계값은 더 탈중앙화된 PoS 네트워크보다 낮습니다.
BFT: 즉각적인 최종성, IBC의 네이티브 환경
비잔틴 결함 허용 (Byzantine Fault Tolerant, BFT) 합의, 특히 Cosmos 생태계 전반에서 사용되는 CometBFT (구 Tendermint)는 현재 운영 중인 모델 중 브릿지에 가장 친숙한 합의 모델입니다.
BFT의 보장 사항:
- 결정론적이고 즉각적인 최종성: 검증인의 절대다수 (2/3 이상)가 서명하는 즉시 블록은 되돌릴 수 없게 확정됩니다. 확률적인 대기 시간이 없습니다.
- 설계상 포크 없음: 정상적인 네트워크 조건에서 BFT 체인은 포크되지 않습니다. 단일 확정 블록이 정식 체인 (canonical chain)이 됩니다.
- 부정 행위 탐지: IBC의 라이트 클라이언트 프로토콜에는 부정 행위 제출 기능이 포함되어 있습니다. 검증인 세트가 이중 서명 (두 개의 충돌하는 블록에 서명)하는 등의 부정 행위를 할 경우, 온체인에 증거를 제출하여 라이트 클라이언트를 동결하고 추가 피해를 방지할 수 있습니다.
이러한 속성들은 바로 상호 블록체인 통신 (Inter-Blockchain Communication, IBC) 프로토콜이 설계된 핵심 배경입니다. IBC는 다음과 같은 이유로 신뢰를 최소화합니다:
- 외부 검증인이 아닌 상대방 체인 헤더의 라이트 클라이언트 검증에 의존합니다.
- 결정론적인 BFT 최종성 덕분에 라이트 클라이언트는 리오그 (reorgs)에 대비할 필요가 없습니다.
- 수탁자나 멀티시그가 없으며, 오직 상태 포함에 대한 암호학적 증명만 존재합니다.
2025년 3월에 출시된 IBC v2는 ZK 증명을 사용하여 이 모델을 이더리움으로 확장했습니다. 이를 통해 이더리움의 PoS 최종성 체크포인트를 IBC 라이트 클라이언트 컨텍스트 내에서 검증할 수 있게 되었습니다. 이는 획기적인 발전으로, BFT의 네이티브 신뢰 모델이 PoS 체인을 수용하도록 조정되어 IBC 보안 범위를 비약적으로 넓혔습니다.
단점: BFT 합의는 확장성이 떨어집니다. 검증인 세트가 수백 개의 노드를 넘어서면 서명을 수집하기 위한 통신 부하가 기하급수적으로 증가합니다. 이것이 BFT 체인이 더 작고 엄선된 검증인 세트를 지향하는 이유이며, 이는 DPoS가 직면한 중앙화 문제를 다시 불러옵니다.
최적의 메시징 프로토콜: IBC는 BFT 체인을 위한 표준적인 선택이며 신뢰 최소화 크로스 체인 통신의 골드 스탠다드입니다. Hyperlane 또한 이 환경에 적합합니다. Hyperlane의 인터체인 보안 모듈 (ISM)은 BFT 체인 상태를 직접 검증하도록 구성할 수 있으며, 허가 없는 릴레이어 모델 덕분에 누구나 BFT 간 메시지 전달을 위한 인프라를 운영할 수 있습니다.
합의 유형에 따른 메시징 프로토콜 매칭
연결된 체인의 합의 유형에 따라 메시징 프로토콜을 선택하기 위한 실무 프레임워크는 다음과 같습니다:
LayerZero v2는 사실상 모든 체인에서 작동하지만 신중한 DVN 구성이 필요합니다. 애플리케이션 개발자가 자신의 메시지를 검증할 탈중앙화 검증인 네트워크 (DVN)를 직접 선택하는 모듈형 보안 스택을 갖추고 있어, 보안 결정의 책임을 개발자에게 맡기는 대신 체인에 구애받지 않는 유연성을 제공합니다. 단일 최종성 모델이 지배적이지 않은 이기종 환경에 가장 적합합니다.
Axelar는 외부의 경제적 보안을 수용할 수 있는 체인을 위해 특별히 제작되었습니다. Axelar의 DPoS 검증인 네트워크는 합의 불일치를 명시적으로 처리합니다. Axelar 검증인은 메시지를 전달하기 전에 소스 체인의 최종성 (소스 체인이 정의한 방식에 따름)을 관찰합니다. 이는 다재다능하지만 Axelar 자체의 검증인 세트를 신뢰 가정으로 도입하게 됩니다. PoW 또는 PoS 체인을 더 넓은 생태계에 연결하는 데 가장 적합합니다.
IBC는 가장 신뢰 최소화된 옵션이지만 소스 체인이 빠르고 결정론 적인 최종성과 호환 가능한 라이트 클라이언트 구현을 갖추어야 합니다. IBC v2가 이더리움 지원을 확장함에 따라 그 도달 범위가 넓어지고 있습니다. BFT 간 연결에 가장 적합하며, ZK 브릿지를 통한 BFT와 PoS 간 연결에서도 점차 활용도가 높아지고 있습니다.
Hyperlane은 구성 가능한 ISM을 통해 가장 높은 개발자 유연성을 제공합니다. 팀은 소스 체인의 합의 유형에 따라 멀티시그 ISM (Axelar 모델과 유사한 위원회 기반) 또는 ZK 라이트 클라이언트 ISM (IBC와 유사)을 선택할 수 있습니다. 자체 보안 파라미터를 정의해야 하는 소버린 롤업이나 앱체인을 구축하는 팀에 가장 적합합니다.
Chainlink CCIP는 크로스 체인 메시지 검증을 위해 체인링크의 탈중앙화 오라클 네트워크 (DON)에 의존하므로 상대적으로 합의 모델에 구애받지 않습니다. 통합의 단순성과 브랜드 신뢰도가 중요한, 이미 체인링크 가격 피드를 사용 중인 엔터프라이즈 애플리케이션 및 DeFi 프로토콜에 가장 적합합니다.
일치하지 않는 완결성의 숨겨진 비용
2022년에서 2024년 사이를 정의한 브릿지 해킹 사건들 — Ronin ($625M), Wormhole ($320M), Nomad ($190M) — 은 한 가지 공통점을 공유합니다. 바로 연결된 체인의 트랜잭션 완결성 (finality) 에 대해 위험한 가정을 했다는 점입니다.
Ronin의 검증인들은 충분한 온체인 완결성이 확보되기 전에 입금을 확인했습니다. Nomad의 사기 증명 창 (fraud-proof window) 은 연결된 체인의 리오그 (reorg) 리스크를 고려하지 못했습니다. 이는 단순한 스마트 컨트랙트 버그가 아니라, 완결성 모델 간의 아키텍처적 불일치였습니다.
업계가 2025년 상반기에만 23억 달러 이상의 손실을 기록하고 있는 지금, 교훈은 명확합니다. 브릿지 보안은 얼마나 많은 감사자가 컨트랙트를 검토했느냐의 문제만이 아닙니다. 브릿지의 완결성 가정이 네트워크의 가장 약한 고리를 포함하여 연결된 모든 체인의 실제 보장 수준과 일치하는지가 핵심입니다.
미래 전망: 유니버설 어댑터로서의 ZK 증명
브릿지 보안에서 가장 흥미로운 발전은 합의 알고리즘에 구애받지 않는 완결성 검증 계층으로서 ZK 증명 기반 라이트 클라이언트가 등장한 것입니다. Succinct Labs, Polyhedra, IBC v2 이니셔티브와 같은 프로젝트들은 PoS 체크포인트 서명, BFT 검증인 세트, 심지어 PoW 블록 헤더까지 모두 온체인 스마트 컨트랙트 내에서 검증할 수 있는 ZK 회로를 구축하고 있습니다.
ZK 기반 검증이 2025년과 2026년에 걸쳐 예상대로 성숙해진다면, 이 글에서 다룬 핵심적인 긴장 상태를 해결할 수 있을 것입니다. 브릿지는 더 이상 암호학적 증명의 보안성 (확정적 완결성 필요) 과 외부 검증인의 유연성 (모든 완결성 모델을 처리하지만 신뢰 가정이 추가됨) 사이에서 선택할 필요가 없게 됩니다.
그러한 미래가 오기 전까지 실질적인 지침은 명확합니다. 사용 중인 체인의 합의 모델을 파악하고, 해당 체인의 완결성 보장에 부합하는 메시징 프로토콜을 선택하십시오. 확률적 완결성 (probabilistic finality) 만 존재하는 곳에서 확정적 완결성 (deterministic finality) 을 가정하는 브릿지를 절대 구축하지 마십시오.
BlockEden.xyz는 Sui, Aptos, Ethereum, Cosmos 체인을 포함한 27개 이상의 블록체인 네트워크를 위한 엔터프라이즈급 노드 인프라 및 API 서비스를 제공합니다. 크로스 체인 애플리케이션을 구축 중이거나 브릿지 인프라를 위한 안정적인 RPC 액세스가 필요하다면, API 마켓플레이스를 방문하여 프로덕션 안정성을 위해 설계된 기반 위에서 개발을 시작하세요.