퍼블릭 체인 서사에서 가장 흔한 수법 중 하나는 충분히 큰 처리량 숫자를 던지는 것입니다. 홈페이지의 “피크 TPS”와 실시간으로 온체인에서 관측할 수 있는 처리량은 흔히 같은 통계가 아닙니다. 제3자 모니터는 주장된 피크와 측정 처리량을 공개적으로 비교해 왔고, 일부 네트워크에서는 격차가 두 자릿수 이상 벌어집니다. 이는 보통 “누가 거짓말하는가”의 단순한 이야기가 아니라, “이론적 피크”와 “관측 창의 처리량”이 습관적으로 뒤섞이는 문제입니다.
고성능 설계—특히 병렬 EVM—를 평가하는 독자에게는 TPS, BPS, 확인 지연, 최종성, 충돌률이 같은 정의를 공유하기 전까지 비교가 사과 대 오렌지입니다. 병렬 EVM을 읽어야 할 사람은 역할별 읽기 경로를 나눴고, 이 글은 공유 측정 어휘를 제공합니다. 아래 인용한 외부 수치는 측정 차이를 설명하기 위한 공개 자료 예시이며, 프로젝트 평가나 투자 조언이 아닙니다.
TPS: 하나의 약어, 최소 세 가지 공식
TPS는 문자 그대로 초당 트랜잭션 수입니다. 실제로는 최소 세 가지 다른 계산이 있습니다:
- 이론적 / 실험실 피크: 명시된 하드웨어, 클라이언트 버전, 트랜잭션 구성(흔히 단순 전송이나 합성 저충돌 부하) 아래의 상한. 가장 큰 숫자이고, 메인넷으로의 외삽은 가장 약합니다.
- 지속 처리량: 명시된 지연과 실패율 제약 아래에서 시스템이 유지할 수 있는 비율. 결제와 정산에서는 흔히 피크보다 더 의미 있습니다.
- 관측 창 처리량: 선택한 최종성 정의 아래에서 시간 창 안에 포함·확인된 트랜잭션을 초로 나눈 값. 역량 상한이 아니라 실제 수요와 혼잡을 반영합니다.
병렬로든 비교로든 세 가지 질문을 던져야 합니다. 트랜잭션을 어떻게 세는가(투표 / 하우스키핑 포함인가)? 실패하거나 롤백된 트랜잭션도 포함하는가? 창은 얼마나 길고, 어떤 하드웨어와 클라이언트 버전을 썼는가? 병렬 EVM은 네 번째를 더합니다. 테스트 부하의 충돌률이나 핫스팟 분포는 무엇인가? 충돌 분포 없는 피크는 가치가 제한적입니다 — 충돌 핫스팟과 워크로드에서 확장합니다.
같은 체인이 세 가지 TPS 모드를 모두 정직하게 공개할 수 있습니다. 실험실 피크는 상한, 지속 처리량은 사용 가능한 제품 대역, 관측 창은 오늘 수요가 용량을 채우는지를 보여줍니다. 이를 하나의 숫자로 찍어내는 순간 오도가 시작됩니다. “최대”라는 표현을 보면 기본적으로 피크 버킷에 넣고, 지속 및 관측 대응 수치를 찾으세요.
BPS: “더 빠른 블록”을 곧바로 “더 빠른 사용자”로 번역하지 말 것
이 글에서 BPS는 초당 블록 수, 즉 블록 생성 빈도입니다. BPS를 높이면 다음 블록까지의 평균 대기를 줄일 수 있지만, 사용자가 체감하는 지연은 트랜잭션이 제안자 멤풀에 언제 들어가는지, 실행과 충돌 재시도에 얼마나 걸리는지, 프로토콜 최종성에 블록이나 투표 라운드가 몇 개 더 필요한지에도 달려 있습니다.
따라서 BPS는 합의와 패킹 리듬 지표이지, 종단 간 경험의 충분통계량이 아닙니다. 충돌이 높은 실행이 재실행 큐를 쌓으면 BPS를 높여도 여전히 느리게 느껴질 수 있습니다. 자료를 읽을 때는 BPS를 확인 지연, 최종성과 분리해 기록하세요. 더 빠른 블록 시간이 전체 성능 서사를 대신하게 두지 마세요. 문서가 BPS를 다른 의미(예: 바이트 지향 처리량)로 쓴다면 그 페이지의 정의를 따르고, 이 글의 의미와 섞지 마세요.
확인 지연: 전송에서 “보인다”까지
확인 지연은 보통 사용자(또는 지갑)가 트랜잭션을 제출한 시점부터, 네트워크가 어떤 “수용 가능한 확인” 규칙 아래에서 이를 인정할 때까지의 시간을 뜻합니다. 핵심은 “수용 가능”이 무엇인지 적어 두는 것입니다 — 최신 제안 블록에 포함, 이후 k개 블록 생존, 또는 BFT 스타일 커밋 조건 충족.
실용적인 읽기 습관:
- 평균만 보지 말고 p50 / p95 / p99를 선호하세요. 테일이 지원 티켓과 차익거래 창을 좌우합니다.
- 부하를 기록하세요. 빈 체인 지연과 혼잡 기간 지연은 다른 지표입니다.
- 병렬 실행에서는 충돌 재시도가 지연 분포의 일부를 넓히는지도 지켜보세요.
- “내 로컬 노드에서 실행됨”과 “네트워크에 의해 최종 확정됨”을 분리하세요. 지갑 UI는 때때로 전자를 보여주지만, 정산은 흔히 후자를 필요로 합니다.
완전한 지연 공개는 확인 정의, 백분위, 부하 설명, 클라이언트 표본 방식을 명시합니다. 하나라도 빠지면 그 숫자는 재현하기 어렵습니다. 결제와 가맹점 정산은 특히 예측 가능한 지연 상한이 필요합니다. 평균만 있는 자료는 그런 시나리오에서 의사결정 가치가 거의 없습니다.
최종성: 경제적 최종성과 프로토콜 최종성을 혼동하지 말 것
최종성은 트랜잭션 결과를 되돌리는 데 얼마나 큰 비용이 드는지—또는 프로토콜상 되돌릴 수 있는지—를 나타냅니다. 흔히 뒤섞이는 두 가지 용법:
- 프로토콜 최종성(결정적 최종성): BFT 스타일 합의에서 충분한 투표가 모이면 블록이 커밋 상태에 들어가고, 정직한 노드는 프로토콜상 이를 롤백하지 않습니다. 지연은 흔히 메시지 라운드로 표현됩니다.
- 경제적 / 확률적 최종성: 최장 체인 또는 일부 롤링 확인 규칙에서 블록이 쌓일수록 재조직 확률은 낮아지지만, 이론상 더 긴 체인이 이력을 대체할 수 있습니다. “최종”은 위험 임계값입니다.
확률적 최종성 아래의 “N 확인”을 “최종 확정”이라고 부르면 체인 간 비교가 왜곡됩니다. 정산과 브리지 시나리오에서는 어떤 최종성 모델이 적용되는지, 어떤 가정(적대자 해시파워 / 스테이크 비율 / 네트워크 동기) 아래인지 밝혀야 합니다. Pipeline BFT에 관한 Bitroot의 기술 서사는 빠른 프로토콜 최종성을 목표로 합니다—Pipeline BFT와 멀티 엔진 시너지를 참고하세요. 1초 미만 최종성이라는 제품 주장이 성립하는지는 여전히 그 테스트가 공개한 조건에 묶여 있습니다 — 설계 목표는 검증된 메인넷 사실이 아닙니다.
최종성 시간은 확인 지연과 관련되지만 동일하지는 않습니다. 사용자는 소프트 확인 후 UI를 새로고침할 수 있지만, 브리지와 커스터디언은 여전히 프로토콜 최종성을 기다립니다. 두 체인을 비교할 때는 먼저 어느 수준의 “충분함”을 비교하는지 맞추세요.
충돌률: 병렬 EVM의 “숨은 분모”
충돌률은 낙관적 병렬 아래에서 읽기/쓰기 집합 충돌 때문에 롤백하거나 직렬로 재실행해야 하는 트랜잭션의 비중을 나타냅니다(정의에는 트랜잭션 수 기준인지 가스 기준인지, 계정 입도인지 슬롯 입도인지 밝혀야 합니다). 고전적 단일 스레드 포스터에는 거의 등장하지 않지만, 전송 벤치마크는 왜 빨라 보이고 AMM 벤치마크는 왜 느려지는지를 설명하는 분모입니다.
대략적 직관:
- 충돌률이 0에 가까움: 병렬 속도 향상이 실행 엔진 수에 근접할 수 있습니다(여전히 스케줄링과 상태 접근 오버헤드에 묶임).
- 충돌률 상승: 유효 처리량이 “직렬 실행 + 롤백 비용” 쪽으로 미끄러집니다 — CPU는 바쁘지만 사용자는 여전히 기다립니다.
따라서 정직한 병렬 EVM 벤치마크는 최소 두 수치를 보고합니다. 저충돌 부하와 고충돌(또는 현실적인 혼합 컨트랙트) 부하, 그리고 충돌 정의를 명시해야 합니다. 전송 피크만 공개하면 분모를 숨깁니다. 가스 가중 충돌률도 비교하세요. 소수의 무거운 핫스팟 트랜잭션이 많은 가벼운 충돌보다 처리량을 더 잘 뚫을 수 있습니다.
벤치마크를 읽을 때의 최소 공개 체크리스트
성능 표를 볼 때 다음을 체크하세요:
| 공개 항목 | 중요한 이유 |
|---|---|
| 하드웨어(CPU / RAM / 디스크 / 네트워크)와 노드 수 | 그렇지 않으면 피크가 극단적 장비 위에 쌓인 것인지 알 수 없음 |
| 클라이언트 버전과 구성 | 같은 프로토콜이라도 구현이 다르면 숫자가 다름 |
| 트랜잭션 구성과 충돌률 정의 | 병렬 수치가 외삽 가능한지를 결정 |
| TPS 모드(피크 / 지속 / 관측) | 세 공식을 하나로 비교하는 것을 방지 |
| 확인 정의와 백분위 | “평균은 빠르고 테일은 느림”이 숨는 것을 방지 |
| 최종성 유형(프로토콜 / 경제적) | 모델 간 거짓 비교를 방지 |
| 메인넷, 테스트넷, 실험실 | 테스트넷 수치는 프로덕션 안정 성능이 아님 |
빠진 항목이 많을수록 그 숫자는 인용 가치가 낮아집니다. 이는 “크면 클수록 좋다”는 홈페이지 논리와 어긋나지만, 엔지니어링과 연구에서 재현 가능한 유일한 읽기 방식입니다. 다음 글의 탈중앙화 차원과 함께 읽으세요. 한 도시의 고사양 머신 몇 대에서만 측정한 같은 피크는 외삽할수록 더 줄어듭니다.
맺음말
성능 지표는 홈페이지용 형용사가 아니라, 첨부물을 요구하는 측정값입니다. TPS에는 단일한 참값이 없고, BPS는 사용자 지연을 대체할 수 없으며, 확인과 최종성은 비교 전에 정의되어야 하고, 충돌률은 이제 병렬 EVM 읽기에서 빠져서는 안 됩니다. 이 용어집이 정렬되면, 탈중앙화 대 하드웨어 장벽—그리고 핫 워크로드에서의 처리량 붕괴—논의가 단일 피크에 납치될 가능성이 줄어듭니다.