---
id: 4
title: 'Pipeline BFT와 실행 디커플링: 실행에 줄 서지 않는 합의'
slug: bitroot-pipeline-bft
date: 2026/08/02
summary: '고전적 BFT의 직렬 단계와 메시징 복잡도가 처리량을 어떻게 제한하는지, Pipeline BFT가 파이프라인에서 높이를 어떻게 겹치는지, 그리고 합의가 실행과 분리된 뒤 정합성 경계가 어디에 있는지를 설명합니다.'
keywords: Pipeline BFT,실행 디커플링,BLS,합의,Bitroot
heroImage: /cms-media/file/5In%20depth%20analysis%20of%20Bitroot%20multi%20engine%20and%20execution%20design.jpg
---

합의와 실행이 묶여 있으면 시스템은 투표를 기다리느라 사이클을 낭비하고 CPU는 놀게 됩니다. 이 블록의 트랜잭션이 끝나야 다음 높이로 안전하게 넘어갈 수 있기 때문입니다. Pipeline BFT는 우선 단계 파이프라이닝과 검증인 통신 비용을 겨냥합니다. 낙관적 병렬 실행과 짝을 이루면, 디커플링 이후에도 최종 상태가 순서가 정해진 직렬 의미론과 일치함을 누가 보장하는지에도 답해야 합니다.

## 고전적 BFT가 멈추는 지점

고전적 BFT(propose, pre-vote, pre-commit, commit)는 안전성은 성숙했지만 지연에는 불친절합니다:

1. **높이 직렬화**: 다음 높이가 이전 높이의 핵심 단계를 기다리는 경우가 많습니다.
2. **거의 2차에 가까운 메시징**: n명의 검증인이 가십할수록 대역폭과 서명 검증 비용이 커집니다.
3. **자원 불일치**: 네트워크를 기다리는 동안 CPU가 놀고, 검증이 몰릴 때 네트워크가 놉니다.

검증인 집합을 키우는 것은 탈중앙화 서사에 도움이 되지만 합의 예산을 초과할 수 있습니다. 이것이 탈중앙화–성능 긴장의 합의 쪽 모습입니다—[탈중앙화 대 성능](/ko/blog/decentralization-performance-tradeoff)을 참고하세요.

## Pipeline BFT: 단계를 쌓는다

직관은 CPU 파이프라인입니다. 서로 다른 명령이 fetch, decode, execute에 동시에 자리합니다. 이를 높이에 대응시키면:

- 높이 N이 커밋되는 동안 N+1은 pre-commit, N+2는 pre-vote를 할 수 있고, 더 새로운 높이가 propose를 시작할 수 있습니다;
- 리더는 VRF 스타일의 검증 가능한 난수로 교체되어, 고정 제안자에서 오는 검열과 단일 리더 위험을 줄입니다;
- BLS12-381급 집계는 많은 투표를 빠르게 검증 가능한 하나의 집계로 압축해, “검증인이 더 많다”가 모든 노드의 검증 부하를 선형으로 증폭하지 않게 합니다.

파이프라이닝은 **순서 지정과 확인 경로의 활용률**을 높일 뿐, 실행 계층 TPS와 자동으로 같지 않습니다. 실행이 단일 스레드로 남으면 빠른 합의는 대기 큐만 키웁니다. 아키텍처 지도: [병렬 EVM 아키텍처 개요](/ko/blog/bitrootevm). 단일 스레드 한계: [EVM 단일 스레드 병목](/ko/blog/evm-single-thread-bottleneck).

## 실행 디커플링: 순서 먼저, 병렬로 수렴

디커플링 이후 역할은 보통 이렇게 나뉩니다:

- **합의**: 전역 트랜잭션 순서(와 블록 경계)를 빠르게 내보냅니다.
- **실행**: 그 순서 아래에서 상태를 낙관적으로 병렬 진행하고, 충돌 시 고정된 규칙으로 재실행해 직렬 의미론이 성립할 때까지 반복합니다.

이는 다른 프로젝트가 “합의와 실행 분리 / 지연 실행”으로 논의하는 것과 같은 엔지니어링 판단입니다. 순서가 안정되면 실행은 비동기로 따라잡을 수 있습니다. Bitroot 쪽 실행 세부: [멀티 엔진 병렬 실행](/ko/blog/bitroot-evm)과 [낙관적 병렬화](/ko/blog/bitrootevm-). 데이터베이스 OCC 배경: [OCC 입문](/ko/blog/optimistic-concurrency-control-intro); 경로 대비: [병렬 실행으로 가는 세 가지 길](/ko/blog/parallel-execution-approaches).

정합성의 세 가지 레드라인은 마케팅보다 설계에서 더 중요합니다:

1. 같은 순서의 배치를 재생하는 모든 정직한 노드는 같은 상태 루트에 도달해야 합니다.
2. 병렬 스케줄링은 스레드 타이밍에 의존하는 비결정성을 도입해서는 안 됩니다.
3. 비잔틴 검증인은 로컬 실행 결과를 위조하는 것만으로 정규 상태를 정의할 수 없습니다—정규 상태는 여전히 합의 순서와 결정적 실행 함수에서 나옵니다.

## AI / 에이전트 시나리오와의 관계 (절제된 서술)

낮고 예측 가능한 확인 지연은 에이전트가 온체인에서 정산하고 리스크를 관리하는 데 도움이 됩니다. AI 학습 자체는 보통 합의 핫 패스에서 돌지 않습니다. Pipeline BFT를 “AI 학습을 위해 설계됐다”고 부르는 것은 과장입니다. 더 정확히는, 고빈도 자동 정산을 위한 합의 기반을 제공하는 것입니다. 컴퓨팅 네트워크와 검증 가능 컴퓨팅은 다른 층에 있습니다—[탈중앙화 AI 스택](/ko/blog/aibitrootweb3ai)을 참고하세요.

확인 지연과 처리량에 대한 테스트넷 또는 엔지니어링 목표는 조건을 명시해야 합니다. 따라잡기 속도는 충돌률에 따라 달라집니다—파이프라인 깊이를 안정적인 TPS 약속으로 바꾸지 마세요. 지표 읽기: [성능 지표 용어집](/ko/blog/performance-metrics-glossary). 제품 경계: [Bitroot 포지셔닝](/ko/blog/bitroot-positioning).

## 파이프라인에서도 안전성과 활성은 선택이 아니다

검증인 집합을 키우고 파이프라인을 깊게 하면서도, 결함 임계값 안에서 이중 커밋을 막아야 하고(안전성) 동기 구간에서 블록을 계속 생산해야 합니다(활성). 리더 교체와 타임아웃은 보통 활성을 담당하고, 집계 가능한 서명은 주로 검증을 빠르게 할 뿐 그 자체로 결함 임계값을 바꾸지 않습니다. 합의 단계 시간은 실행 따라잡기 지연과 분리해 모니터링하세요. 기준선: [EVM 단일 스레드 병목](/ko/blog/evm-single-thread-bottleneck).

운영 관점에서 Pipeline BFT 문제는 흔히 이렇게 나타납니다. 투표가 정족수에 도달하지 못하거나, 뷰 체인지가 잦거나, 실행 지연이 “합의가 멈췄다”로 오독되는 경우입니다. 로그는 제안 도착, 집계 서명 완료, 실행 상태 루트 커밋을 분리해 보여줘야 합니다. 그래야 네트워킹 확장, 타임아웃 튜닝, 충돌 감지 수정 중 무엇을 할지 결정할 수 있습니다. 확장 지도: [블록체인 확장 지도](/ko/blog/blockchain-scaling-map); 탈중앙화 긴장: [탈중앙화–성능 트레이드오프](/ko/blog/decentralization-performance-tradeoff).

검증인 운영자에게 파이프라이닝은 하드웨어와 대역폭 프로필도 바꿉니다. 메시징은 더 연속적이 되고, 검증은 집계 경로에 의존하며, 디스크는 실행 따라잡기와 스냅샷에 끌려갑니다. 용량 계획은 합의만 돌린 프로필과 합의+실행 프로필을 따로 측정해야 합니다—빈 블록 TPS로는 부족합니다. 용어: [성능 지표 용어집](/ko/blog/performance-metrics-glossary).

## 파이프라인 깊이와 테일 지연

더 깊은 파이프라인은 평균 높이 진행을 높일 수 있지만 테일 지연 원인을 증폭합니다. 한 높이에서 투표가 막히면 뒤에 겹친 단계들이 쌓일 수 있습니다. 엔지니어링에는 타임아웃, 뷰 체인지, 그리고 합의 단계 시간과 실행 따라잡기 지연을 분리하는 명확한 모니터링이 필요합니다—그렇지 않으면 실행 핫스팟이 합의 결함으로 오진됩니다. BLS 집계는 검증 비용을 줄이지만 결함 임계값을 바꾸지 않습니다. 리더 교체는 검열 표면을 개선하지만 처리량의 유일한 결정 요인은 아닙니다.

낙관적 병렬 실행과 짝을 이루면, 충돌률이 급등할 때 순서만 정해지고 아직 수렴하지 않은 배치가 불어나는지도 지켜봐야 합니다. 큐 증가는 Pipeline BFT가 여전히 높이를 진행하는 동안에도 1초 미만 확인 목표를 지워버릴 수 있습니다. 지표: [성능 지표 용어집](/ko/blog/performance-metrics-glossary). 핫스팟이 충돌을 키우는 방식: [충돌 핫스팟과 워크로드](/ko/blog/parallel-evm-workload-hotspots).

## 최종성 및 확인 지연과의 관계

사용자가 “빠른 확인”이라고 할 때는 투표 수집, 상태 루트 조회 가능, 또는 다운스트림 서비스가 이미 영수증을 본 상태를 의미할 수 있습니다. Pipeline BFT는 첫 번째를 직접 최적화하고, 디커플링 이후 나머지는 실행 따라잡기에 달려 있습니다. 제품 문서는 합의 최종성 목표, 실행 가시성 목표, 테스트넷 관측 범위를 따로 공개해야 합니다.

그렇지 않으면 합의 대시보드는 초록인데 지갑은 pending을 보여주는 상황이 됩니다. 확인 지연, 최종성, 충돌률을 함께 읽으세요—[성능 지표 용어집](/ko/blog/performance-metrics-glossary). 낙관성이 가시성에 미치는 영향: [낙관적 병렬화](/ko/blog/bitrootevm-).

파이프라인 합의는 고성능 L1에 필요하지만 충분하지 않습니다. 결정적 병렬 실행과 통제된 상태 증가가 없으면, 빠른 순서 지정은 더 빠른 큐잉일 뿐입니다. 닫힌 루프를 보려면 멀티 엔진과 OCC 글을 함께 읽으세요.

## 구현에서 흔한 두 가지 크기 산정 실수

첫째: 파이프라인은 깊은데 실행 엔진이 적은 경우—합의는 높이를 진행하지만 실행 큐가 폭발합니다. 둘째: 엔진은 많은데 합의 메시징이 여전히 거의 2차인 경우—검증과 대역폭이 먼저 포화됩니다. 용량 계획은 검증인 규모, 파이프라인 깊이, 엔진 수, 목표 충돌률을 함께 명시하고 그 행렬을 테스트넷에서 회귀 검증해야 합니다—손잡이 하나만 돌리지 마세요.

## 핵심 요약

Pipeline BFT는 단계 겹치기와 서명 집계로 BFT의 직렬·통신 비용을 덜어줍니다. 실행 디커플링은 순서 지정이 실행에 끌려가지 않게 합니다. 실제 시스템 역량은 파이프라인 합의와 낙관적 병렬 실행이 결정적 재현에서 정렬되는지에 달려 있습니다. 한쪽만 최적화하면 다른 쪽이 곧 새로운 병목이 됩니다.

## 더 읽기

- [병렬 EVM 아키텍처 개요](/ko/blog/bitrootevm)
- [멀티 엔진 병렬 실행](/ko/blog/bitroot-evm)
- [Bitroot 포지셔닝](/ko/blog/bitroot-positioning)