Tempo: 특화 블록체인이 나아갈 방향

Key Takeaways

• 기관의 블록체인 도입은 결제에서 시작되고 있다. 이들에게 블록체인은 단순히 제품을 배포하는 네트워크가 아니라 제품의 일부로 여겨진다.
• 템포는 완성형 프레임워크 대신 커먼웨어라는 부품 상자에서 합의, 전파, 암호 알고리즘을 부품 단위로 조립한다. 그 결과 EVM 기반 실행 계층과 임계 심플렉스 합의 계층을 하나의 바이너리로 만든 결제 특화 L1이다.
• 템포는 결제에 필요한 요구조건들을 애플리케이션이 아니라 프로토콜 자체에 내재화했다. 리오그(reorg) 없는 0.5초 결정적 정산, 네트워크 혼잡과 무관하게 보장되는 결제 블록 공간과 수수료, 발행사의 정책 집행과 프라이버시가 전부 합의 규칙과 토큰 표준의 일부로 들어왔다.
• 특화된 목적을 위해 재조립된 새로운 블록체인은 그 목적에 최적화된 성능과 통제력을 얻지만, 전통적인 블록체인으로서의 여러 가치들에 대한 트레이드오프가 존재한다. 탈중앙 네트워크와 특화 네트워크는 서로의 대체재가 아닌 보완재이며, 템포는 특화 쪽이 나아갈 기술적 방향을 보여주는 사례다.

1. 들어가며: 제품의 일부가 되어가는 블록체인

수많은 블록체인 네트워크들이 생겨났다 사라지고, 이더리움을 포함한 소수의 범용 블록체인으로 표준화가 되는 것으로 보였다. 하지만 최근 기관들의 본격적인 진입에 따라 블록체인은 다시 산업별 인프라로 분화하고 있다.

과거에도 특정 애플리케이션을 위한 블록체인 네트워크는 존재했다. 그러나 그때의 전용 체인들은 특정 게임이나 디파이 서비스의 처리량과 속도를 확보하기 위한 것이었다. 최근 등장하는 기관향 체인들은 금융 기관, 거래 플랫폼과 결제 기업들이 자산의 흐름을 직접 통제하기 위한 수요로 만들어진다. 이들에게 블록체인은 자체 제품의 수수료와 확정성, 접근 권한, 개인정보 보호와 규제 대응이 가능한 맞춤형 인프라여야 한다. 기관들에게 블록체인은 단순히 제품을 배포하는 네트워크가 아니라 제품의 일부분으로 여겨지는 것이다.

기관향 체인들이 자체 네트워크를 만드는 방법은 크게 세 가지다.

• 이더리움의 보안과 EVM 생태계를 활용할 수 있는 이더리움 L2를 만든다. 로빈후드 체인(Robinhood Chain), 기와(GIWA) 등이 이에 해당한다.
• EVM 실행 엔진을 사용해 EVM 호환성을 갖춘 자체 L1을 출시한다. 스테이블(Stable), 플라즈마(Plasma), 아크(Arc) 등이 이에 해당한다.
• 완전히 새로운 자체 L1을 출시한다. 칸톤(Canton)이 이에 해당한다.

대부분 EVM 실행 엔진을 사용하고 있지만, 하나의 표준화된 기술 스택은 존재하지 않는다. 이들은 공통적으로 빠른 정산, 낮고 예측 가능한 비용, 규제 대응과 통제 가능한 운영, 높은 프로그래머빌리티를 추구하지만 모두 다른 기술 스택을 택했다. 특히 자체 L1을 택한 프로젝트들을 보면 흥미로운 점을 발견할 수 있다. 실행 계층에서는 플라즈마, 아크, 템포 모두 Reth를 채택한 반면, 합의 계층은 StableBFT, PlasmaBFT, Malachite, 커먼웨어의 심플렉스(Simplex)등 여러가지로 나눠진다.

실행 환경에는 EVM 호환성이 사실상 표준으로 자리 잡았지만, 합의는 각자의 수요에 맞게 선택의 폭이 넓다는 뜻이다. 향후 기관의 진입이 가속화될수록 각 기관의 요구에 맞는 맞춤형 블록체인에 대한 수요가 늘어날 것이다. 이를 통해 앞으로 등장할 블록체인 네트워크들은 각 레이어별로 더 모듈화된 형태로 발전할 것임을 예상할 수 있다.

이러한 변화 속에서 완성형 블록체인 프레임워크보다 더 작은 단위의 구성요소를 조합할 수 있는 커먼웨어(Commonware)가 새로운 대안으로 등장한다. 커먼웨어는 합의, 네트워크, 스토리지, 암호학 각각을 독립적인 모듈로 제공하며, 개발팀이 특정 워크로드에 맞춰 블록체인 스택을 직접 구성해 조립할 수 있도록 한다.

스트라이프(Stripe)와 패러다임(Paradigm)이 인큐베이팅한 결제를 위한 블록체인 템포(Tempo)는 Reth 기반 EVM 실행 환경에 커먼웨어의 합의 및 네트워크 스택을 결합한 새로운 독립 L1을 출시했다. 이 글에서는 템포가 커먼웨어를 통해 구성한 블록체인 스택에 대해 알아보고, 기존의 이더리움 L2나 흔히 사용되는 CometBFT와 결합한 형태의 EVM 호환 L1과 비교해 어떤 차이와 트레이드오프를 갖는지 살펴본다.

2. 결제를 위한 네트워크에 요구되는 것들

2.1 예측 가능성

블록체인의 성능은 대체로 평균값으로 이야기된다. 평균 TPS가 얼마인지, 평균 수수료는 얼마인지가 비교의 기준이 되는 것이다. 하지만 결제 사업자가 필요로 하는 데이터는 결코 평균이 아니다. 최악의 상황에서 정산이 얼마나 지연되는지, 수수료는 얼마까지 오를 수 있는지가 결제 서비스의 수준을 결정하기 때문이다.

이더리움이나 솔라나와 같은 범용 블록체인에서 이 최악의 값은 결제와 전혀 무관한 사건에 좌우된다. 인기 있는 NFT 발행, 시장 변동으로 인한 대규모 청산 등은 블록 공간 경쟁을 심화시키고 이에 따라 결제 트랜잭션의 대기 시간과 비용도 함께 올라간다. 바쁜 이웃(noisy neighbor) 문제다. 결제 사업자 입장에서 이는 단순한 불편을 넘어선다. 결제는 송금 한 건당 마진이 고정된 사업이고, 네트워크 사용을 위한 수수료인 가스비가 예측 불가능한 수준으로 뛰면 손실을 입을 수 있다. 단순히 평균 수수료가 낮은 것보다 예측 가능성이 더 중요한 이유다.

2.2 확정성 문제

이더리움의 슬롯은 12초고, 두 번의 에포크를 거쳐 약 13분 뒤에 완결성(finality)이 확정된다. 이를 받는 백엔드 시스템에서는 승인과 정산을 서로 다른 상태(state)로 관리해야 하고, 완결성이 확정되기 전에 정산 완료로 처리한 거래가 뒤집힐 가능성을 상시 예외 케이스로 유지해야 한다. 이 예외는 회계와 환불, 분쟁 처리까지 전파된다.

결정론적 완결성은 이 예외 경로 자체를 없앤다. 블록이 완결되면 되돌아가지 않는다는 보장이 있으면 승인과 정산을 하나의 상태로 합칠 수 있다. 결제 시스템에서 확정성이 사용자 경험의 문제를 넘어선 시스템 복잡도의 문제인 이유다.

BFT 계열 합의는 결정론적 완결성을 갖는다. 각 블록 투표가 끝남과 동시에 블록이 확정되는 것이다. 대신 BFT 계열 합의는 “체인이 쉽게 멈출 수 있다”는 치명적인 대가를 치른다. 일정 비율 이상의 검증자가 응답하지 않으면 체인은 새 블록을 만들지 못하고 멈춘다. 결제 인프라에서 네트워크의 멈춤은 손실이지만, 이중 정산보다는 낫다는 판단이 깔려 있다. 사실 기존 은행 시스템도 정산 마감이나 시스템 점검 시간에 이체를 중단하는 비슷한 선택을 하고 있다. 잠시 이체가 불가능한 것은 불편하지만, 잘못 처리된 이체를 사후에 되감는 것보다는 비용이 낮다.

이와 같은 요구사항이 범용 블록체인의 설계 목표와 충돌한다는 점은 이더리움 진영에서도 명시적으로 인정하는 부분이다. 비탈릭 부테린(Vitalik Buterin)은 이더리움 L1이 1초 이하의 완결성을 목표로 삼아서는 안 되며, 매우 낮은 지연시간이 필요한 애플리케이션은 L2를 사용해야 한다는 이야기를 했다. 이는 이더리움이 탈중앙성과 안정성을 우선하는 오래전부터 지켜온 입장이지만, 결제 시스템 입장에서는 이더리움과 같은 범용 체인 위에서 해결하기 어려운 요구가 존재한다는 뜻이기도 하다.

2.3 프라이버시

급여를 온체인으로 지급하면 모든 직원의 연봉이 공개된다. 결제 사업자가 가맹점과 정산하면 거래량과 단가가 경쟁사에 그대로 노출된다. 기존 블록체인의 투명성은 이 문제를 해결하지 못한다. 기업 입장에서 공개 원장은 투명성이 아니라 영업 정보의 상시 유출에 가깝다.

동시에 규제 대응은 정반대 방향을 요구한다. 제재 대상 주소의 자산을 동결할 수 있어야 하고, 트레블 룰(Travel Rule)에 따라 일정 금액 이상의 이전에는 송수신자 정보가 따라붙어야 하며, 관할권마다 다른 허용 목록을 적용할 수 있어야 한다. 누가 무엇을 볼 수 있고 누가 무엇을 막을 수 있는지를 발행자가 정의할 수 있어야 한다는 것이다.

범용 블록체인에서 이 요구는 대체로 스마트 컨트랙트로 처리된다. 그러나 컨트랙트에 얹은 통제는 토큰마다 따로 구현되고, 구현이 다르면 정책도 갈라진다. 프로토콜이 알지 못하는 규칙은 프로토콜이 강제할 수도 없다. 이 차이가 결제 특화 체인이 정책 집행과 기밀성을 애플리케이션이 아니라 프로토콜 계층에서 다루려는 이유다.

다만 규제 대응은 한 레이어에서 끝나지 않는다. 자산 레이어에서는 누가 무엇을 보유하고 이전할 수 있는지가 문제가 되고, 데이터 레이어에서는 거래가 어떤 정보를 수반하며 누가 그것을 열람할 수 있는지가 문제가 된다. 그리고 운영 레이어가 남는다. 이 체인을 검증하는 주체가 누구인가도 중요하다. 결제 전용 블록체인에서는 밸리데이터 집합이 식별 가능한 규제 대상 기관으로 구성되어 있어야 하는 요구사항이 존재한다. 비허가형(permissionless)을 추구하는 기존 범용 블록체인들과 가장 다른 지점이다.

2.4 다섯 가지 요구조건

즉, 결제 워크로드가 인프라에 요구하는 것은 다음 다섯 가지로 정리해볼 수 있다.

1. 확정적 정산: 되돌아가지 않는 완결성. 승인과 정산을 분리하지 않아도 되는 구조
2. 예측 가능한 비용: 예측 가능하며 상한이 안정적인 수수료
3. 네트워크 혼잡 시 보장: 다른 활동이 블록을 채워도 결제가 사용할 수 있는 공간이 보장된 블록스페이스
4. 정책 집행과 기밀성: 거래 내용을 감출 수 있으면서도 발행자가 정의한 통제와 감독 기관의 감사 접근은 유지되는 구조
5. 운영 연속성: 일부 밸리데이터 노드 장애가 전체 서비스 중단으로 이어지지 않는 시스템

3. 템포의 아키텍처: EVM 호환, 특화된 합의

3.1 템포의 실행 레이어

템포는 실행 계층을 새로 만들지 않았다. 결제 사업자와 스테이블코인 발행사가 이미 보유한 EVM향 코드, 감사(audit) 경험, 개발 인력이 가진 기술 스택이 여기서도 유효하다는 뜻이다.

템포는 실행 레이어를 위해 이더리움의 실행 클라이언트 중 하나인 Reth를 사용하지만, Reth를 그대로 포크해 쓰는 것은 아니다. 의존성 목록을 보면 약 50개의 레스 크레이트(Crate)가 패러다임의 업스트림 저장소 특정 커밋에 고정되어 있고, 템포 노드는 Reth SDK의 노드 빌더(reth-node-builder)가 제공하는 컴포넌트 조립 방식으로 구성된다.

트랜잭션 풀, 페이로드 빌더, 실행기 같은 구성요소를 자체 구현으로 교체하되 나머지는 업스트림을 그대로 쓰는 구조라고 할 수 있다. EVM 실행은 REVM이, 타입과 인코딩은 Alloy가 담당한다. 라이브러리로 의존하므로 업스트림 Reth가 개선될 경우 템포는 고정 커밋을 옮기는 것으로 따라간다.

3.2 템포 노드의 두 엔진

템포 노드는 단일 바이너리로 동작한다. 이는 합의 엔진과 실행 클라이언트를 별도 프로세스로 띄워 연결하는 여러 EVM L1들과 다르다. 프로세스가 시작되면 먼저 Reth 노드가 뜨고, 별도 스레드에서 커먼웨어의 런타임이 시작되어 합의 스택을 실행한다.

실행 계층은 트랜잭션 풀 관리, 페이로드 구성, EVM 실행, 상태 저장, JSON-RPC 서빙을 담당하고, 합의 계층은 심플렉스 합의 엔진, 에포크 관리자, DKG 관리자, 밸리데이터 간 P2P를 담당한다. 서로 다른 일을 하는 두 시스템이 하나의 프로세스 안에 공존한다. 때문에 중요한 것은 이 둘이 만나는 경계다.

3.3 합의와 실행의 경계

모듈화된 블록체인에서 합의와 실행이 만나는 경계는 크게 세 가지 형태로 구분해볼 수 있다.

• 이더리움은 합의 클라이언트(CL)와 실행 클라이언트(EL)를 별도 프로세스로 분리하고, Engine API라는 JSON-RPC 인터페이스로 연결한다. 프로세스 경계다. 두 클라이언트를 독립적으로 개발하고 자유롭게 조합할 수 있어 클라이언트 다양성이 확보되지만, 모든 상호작용이 로컬 소켓 위의 RPC 호출로 이루어진다.
• 코스모스(Cosmos SDK) 계열은 애플리케이션 로직과 CometBFT를 ABCI(Application Blockchain Interface)로 연결한다. 합의 엔진이 애플리케이션을 호출할 때마다 메시지를 직렬화해 주고받는 직렬화 경계다. 프로세스는 하나로 합칠 수 있지만, 인터페이스는 언어 중립적인 프로토콜 형태로 고정된다.
• 템포의 경우 합의가 같은 프로세스 안의 라이브러리이기 때문에 합의와 실행의 상호작용은 함수 호출로 이루어진다. 그렇다고 이더리움의 Engine API를 완전히 버린 것은 아니다. 템포는 인터페이스 방식은 유지한 채 경계만 제거했다. 합의 스택은 블록이 확정되면 실행 노드의 엔진 핸들에 fork_choice_updated를 호출하고, 새 페이로드를 받으면 new_payload를 호출한다. 이더리움의 CL이 EL에 보내는 것과 같은 종류의 메시지지만, JSON-RPC 소켓이 아니라 같은 주소 공간 안의 함수 호출로 전달된다. Reth 입장에서 보면 합의 클라이언트가 프로세스 안으로 들어온 셈이다.

합의와 실행의 경계가 중요한 이유는 다음 두 가지에 있다.

첫째는 레이턴시 예산의 정밀도다. 템포의 목표 블록 시간은 550ms고, 이 중 50ms를 블록 전파 예산으로 떼어놓으면 남는 500ms가 제안 처리와 페이로드 빌딩의 몫이다. 합의는 자기 차례에 제안을 시작할 때 이미 흘러간 시간을 빼고 남은 예산을 계산해 함수 인자로 페이로드 빌더에 넘기고, 빌더는 그 예산 안에서 트랜잭션 실행을 언제 멈출지 적응적으로 결정한다. 서브초 블록 시간에서 이런 밀리초 단위의 예산 협상을 프로세스 경계 외부에서 수행하는 것은 낭비다. 원래 이더리움의 Engine API는 12초 슬롯을 전제로 설계되었고, 12초라는 넉넉한 시간에서는 고민의 이유가 없는 문제다.

둘째는 커스터마이징의 자유도다. 템포의 블록 헤더는 표준 이더리움 헤더에 결제 전용 필드를 추가한 확장 타입이고(6장에서 다룬다), 트랜잭션 타입도 자체 정의다. 합의와 실행이 하나의 Rust 타입 시스템을 공유하므로 이런 확장이 양쪽에 동시에 반영된다. ABCI였다면 직렬화 스키마의 문제가 되고, Engine API였다면 표준 인터페이스의 확장 협상이 필요한 일이다.

이 선택으로 포기해야 하는 것도 있다. 프로세스 분리가 제공하던 장애 격리와 클라이언트 다양성을 포기해야 하며, 합의와 실행의 업그레이드가 하나의 배포 단위로 묶이게 된다. 이 트레이드오프에 대해 보다 자세한 사항은 7장에서 다시 다룬다.

3.4 범용성과 특화 사이 어딘가

템포의 실행 환경은 다양한 곳에서 쓰이는 범용 EVM이다. 하지만 블록스페이스와 트랜잭션 규칙은 결제 특화된 형태로 만들어졌다. 결제용 블록 공간을 보장하는 헤더 필드, 스테이블코인 수수료, 결제 트랜잭션 분류 규칙이 여기에 속한다(6장). 그리고 합의와 밸리데이터 네트워크는 결제가 요구하는 확정성과 운영 조건에 맞춰 별도로 최적화되어 있다(5장).

이 경계 때문에 템포를 기존 구분대로 분류하기는 어렵다. 템포가 "EVM 앱체인"은 아니다. 앱체인이라는 말은 코스모스 SDK나 OP Stack 같은 프레임워크가 제공하는 기본 구조 위에 애플리케이션을 얹은 체인을 연상시키지만, 템포에는 그런 프레임워크가 없다. 합의 엔진, 전파 계층, 위원회 전환, 키 관리를 부품 단위로 골라 자체 노드에 조립한 형태다. 그 부품 상자로 쓰인 것이 커먼웨어다. 다음 장에서는 커먼웨어가 기존 블록체인 SDK와 어떤 차이가 있는 도구인지 알아본다.

4. 커먼웨어(Commonware): 블록체인 부품 상자

4.1 기존 블록체인 SDK의 방식

새 체인을 만드는 팀은 보통 프레임워크에서 출발한다. 코스모스 SDK는 CometBFT 합의 위에 계정, 스테이킹, 거버넌스 모듈까지 갖춘 애플리케이션 뼈대를 제공한다. OP Stack은 이더리움 L2의 표준 구성을 쉽게 제공하고, 섭스트레이트(Substrate)는 런타임 모듈(pallet)을 조합하는 방식을 취한다. 일반적으로 체인의 뼈대는 프레임워크가 제공하고, 개발팀은 정해진 자리에 목적에 맞는 로직을 채우는 것으로 체인 개발이 진행된다.

프레임워크를 사용하는 것에 있어 가장 큰 장점은 속도다. 검증된 프레임워크 위에서 출발하므로 짧은 시간 만에 체인 개발을 끝낼 수 있다. 대신 체인에 요구되는 스펙이 기본값에서 벗어나는 순간부터 비용이 커진다. 프레임워크는 바꿀 수 있는 것의 목록이 정해져 있기 때문에, 목록 밖의 변경은 쉽지 않다. 블록 구조를 바꾸거나 합의의 메시지 흐름을 건드리는 작업이 대표적이다.

문제는 결제에 필요한 요구조건들이 대체로 이 목록 밖에 있다는 점이다. 블록 헤더에 결제 전용 가스 한도를 넣는 것, 목표 블록 시간에서 전파 예산을 빼 페이로드 빌더에 넘기는 것, 임계값 서명으로 밸리데이터 위원회를 로테이션 하는 것. 어느 것도 기존 프레임워크로 쉽게 해결할 영역이 아니다.

4.2 커먼웨어의 접근법

커먼웨어는 코인베이스(Coinbase)에서 로제타(Rosetta, 현 Coinbase Mesh API)를 만든 패트릭 오그레이디(Patrick O'Grady)가 2024년 설립한 팀이다. 혼 벤처스(Haun Ventures)와 드래곤플라이(Dragonfly)로부터 900만 달러 시드 투자를 받았고, 스스로를 프레임워크가 아닌 "안티 프레임워크(anti-framework)"로 소개한다.

안티 프레임워크라는 표현대로 커먼웨어에는 체인의 뼈대를 제공하지 않는다. 고정된 레이어 구조를 강제하지 않고, 특정 합의 프로토콜이나 보안 가정을 전제하지 않는다. 블록 형식, 상태 구조, 완결성의 정의, 멤풀, 실행 규칙, 수수료 정책 중 어느 것도 정해져 있지 않다.

커먼웨어가 제공하는 것은 각각 하나의 문제를 풀기 위한 프리미티브(primitive)들이다. 인증된 P2P 연결, 합의, 데이터 전파, 스토리지, 암호학, 비동기 런타임이 각각 독립된 크레이트(Crates)로 존재한다. 2026년 2월 기준 17개 프리미티브와 50여 개의 변형(dialect), 93%의 테스트 커버리지를 갖췄고, 이 글을 쓰는 시점에는 프리미티브가 19개로 늘었다. 전부 Rust로 작성되었으며 오픈소스로 공개되어 있다.

프리미티브, 크레이트, 방언의 관계를 정리하면 다음과 같다.

• 프리미티브(primitive): 하나의 문제를 담당하는 부품의 종류를 뜻한다. 합의, P2P, 스토리지가 각각 하나의 프리미티브다.
• 크레이트(crate): 러스트에서 라이브러리를 배포하는 패키지 단위다. 커먼웨어는 프리미티브 1개를 크레이트 1개로 배포한다 (ex. 합의 프리미티브 → commonware-consensus 크레이트).
• 방언(dialect): 한 프리미티브 안에 들어 있는, 같은 문제에 대한 서로 다른 구현들이다. 크레이트 내부 모듈로 존재한다.

방언(dialect)이라는 표현은 커먼웨어의 성격을 잘 보여준다. 커먼웨어에서 이야기하는 방언은 같은 문제에 대한 다른 구현 변형을 의미한다. 예를 들어 합의 프리미티브의 심플렉스 엔진은 인증서 서명 방식을 플러그인으로 받는다. 프레임워크에서 사용하는 서명 방식이 고정된 것이 아니라 여러 서명 방식들 중 워크로드에 맞는 것을 플러그인 하면 된다. 템포가 쓰는 임계 심플렉스(Threshold Simplex)는 별도의 프로토콜이 아니라 심플렉스 엔진에 BLS threshold 스킴을 플러그인한 조합이다.

런타임(runtime) 프리미티브는 이 부품들이 함께 작동하는 방식을 보여준다. 커먼웨어의 모든 컴포넌트는 비동기 실행을 추상화한 자체 런타임 위에서 돌고, 같은 코드가 프로덕션 런타임과 결정론적 시뮬레이션 런타임 양쪽에서 실행된다. 네트워크 지연과 장애를 재현 가능하게 시뮬레이션하면서 합의 코드를 테스트할 수 있다는 뜻이다.

4.3 템포가 사용하는 구성요소

템포의 의존성 목록에는 커먼웨어 크레이트 12개가 있다.

템포는 이 크레이트들을 자체 합의 크레이트 안에 조립했다. 심플렉스 엔진과 DKG 프리미티브는 커먼웨어에서 오지만, 그것들을 묶는 에포크 관리자와 DKG 관리자, 실행 계층과의 연결부는 템포가 직접 개발하는 형태다.

4.4 모듈성의 의미

커먼웨어에서 이야기하는 모듈성의 의미를 명확히 할 필요가 있다. 커먼웨어의 모듈성은 "모듈러 블록체인"과는 차이가 있다. 모듈러 블록체인 담론은 DA, 실행, 정산을 서로 다른 체인이나 네트워크로 분리하는 이야기다. 즉, 블록체인 네트워크 차원에서의 모듈화를 의미한다. 이 관점에서 템포는 모듈러 블록체인이라고 하기는 어렵다. 커먼웨어의 모듈성은 노드를 운영하는 소프트웨어 내부 구성요소의 교체 가능성이다. 템포는 외부에서 보면 모놀리식 L1이고, 안에서 보면 모듈화된 노드인 것이다.

이 모듈성이 주는 것은 부품 수준의 커스터마이징이다. 워크로드에 맞는 최적화를 부품 단위에서 수행할 수 있고, 각 부품을 독립적으로 벤치마킹하고 업그레이드할 수 있다.

대신 프레임워크가 대신 해주던 각 부품의 통합에 대한 책임이 체인 개발팀으로 넘어온다. 커먼웨어를 사용할 경우 부품들이 함께 작동하는 방식, 운영 모델, 장애 조건까지 직접 설계해야 한다. 합의가 멈추는 조건, 위원회 전환이 실패했을 때의 복구 절차, 밸리데이터에게 요구할 하드웨어와 모니터링 항목 모두 체인 측에서 따로 정의하고 개발해야 한다. 이 비용은 적지 않다.

커먼웨어라는 부품 상자에서 템포가 고른 부품 가운데 가장 중요한 것은 합의다. 다음 장에서는 임계 심플렉스(Threshold Simplex)가 결제의 첫 번째 요구조건인 확정적 정산을 어떻게 구현하는지 뜯어본다.

5. 템포 합의의 중심: 임계 심플렉스(Threshold Simplex) BFT

5.1 심플렉스의 기본 흐름: 블록 하나의 생명주기

심플렉스는 뷰(view) 단위로 진행된다. 각 뷰에는 리더가 한 명 있고(리더 선출 방식은 5.5에서 다룬다), 그 뷰에서 블록 하나의 확정을 시도한다. 템포 블록의 라이프사이클은 다음과 같다.

TODO 인포그래픽 내재화

1. 리더가 블록을 만들어 공증(notarize) 메시지로 전파한다. 심플렉스에서 제안과 리더 자신의 투표는 별도 메시지가 아니라 같은 메시지다.
2. 밸리데이터들은 제안을 검증한 뒤 각자의 공증 투표를 전파한다.
3. 2f+1개의 공증이 모이면 공증 인증서(notarization certificate)가 만들어진다. 이 블록은 공증되었고, 네트워크는 다음 뷰로 진행한다.
4. 공증과 함께 각 밸리데이터는 완결성 투표를 전파하고, 2f+1개가 모이면 완결성 인증서(finalization certificate)가 만들어진다. 이 시점부터 블록은 되돌릴 수 없다.

리더가 침묵하거나 잘못된 제안을 보내면 밸리데이터들은 타이머에 따라 nullify 투표를 전파한다. 2f+1개의 nullify가 모이면 무효화 인증서(nullification certificate)가 만들어지고, 그 뷰는 아무것도 확정하지 않은 채 다음 뷰로 넘어간다. 별도의 뷰 체인지 프로토콜은 없다. 무효화가 곧 뷰 체인지다.

홉 수로 계산하면 제안 전파가 1홉, 공증 투표 전파가 2홉이다. 2홉 만에 블록이 만들어지고 다음 뷰가 시작되는 것이다. 완결성 투표까지가 3홉이다. 블록 생성에 2홉, 완결성까지 3홉이며, 3홉 완결성은 부분 동기 네트워크에서 최적(optimal)이다.

구현은 네 개의 액터로 나뉜다. Batcher는 다른 밸리데이터의 메시지를 수집하고, 쿼럼이 모일 때까지 서명 검증을 미뤄뒀다가 한 번에 배치로 검증한다. Voter는 현재 뷰의 투표를 진행하고, Resolver는 누락된 인증서를 다른 노드에서 받아온다. 블록을 만들고 검증하는 애플리케이션은 직접 구현해야 한다. 네 액터의 상호작용은 전부 논블로킹이라, 애플리케이션이 제안 블록을 검증하는 동안에도 Voter는 다음 메시지를 처리한다.

5.2 공증과 완결성을 나누는 이유

공증은 "이 블록으로 다음 뷰를 진행해도 된다"는 인증이고, 완결성은 "이 블록은 정산이 확정된 상태"라는 인증이다. 이 둘을 나누면 파이프라인이 생긴다. 뷰 v+1은 v의 공증만으로 시작되고, v의 완결성 투표는 그 뒤에서 독립적으로 진행된다. 커먼웨어는 이를 언체인드 완결성(unchained finalization)이라 부른다. 블록 생성은 2홉 주기로, 완결성은 한 박자 뒤에 진행된다.

무효화는 안전장치 역할을 한다. 확정된 블록은 무효화될 수 없다. 완결성 인증서와 무효화 인증서 모두 2f+1 쿼럼을 요구하므로 둘이 같은 뷰에서 공존하려면 f+1개 이상의 정직한 노드가 양쪽 모두에 투표해야 하는데, 정직한 노드의 경우 이런 투표를 하지 않는다. 무효화 인증서는 "이 뷰에서는 아무것도 확정되지 않았다"는 암호학적 증명이 되어, 다음 뷰의 리더가 안심하고 같은 블록을 다시 제안하거나 새 블록을 연결할 수 있게 한다.

네트워크 지연이 발생하면 어떻게 될까? 타이머가 만료되고 뷰들이 무효화로 소모되면서 블록 생성 간격은 늘어난다. 그러나 늘어나는 것은 시간뿐이고, 쿼럼 없이는 어떤 인증서도 만들어지지 않으므로 잘못된 확정은 발생하지 않는다. 다만 BFT 특성상 밸리데이터의 1/3 이상 오프라인이 되면 공증도 무효화도 성립하지 않아 체인은 정지한다.

5.3 텐더민트(Tendermint)와는 무엇이 다른가

코스모스 SDK에서 사용되는 텐더민트와 그 구현인 CometBFT는 propose, prevote, precommit 세 단계로 한 높이를 확정하고, 높이 h가 확정된 뒤에야 h+1에 대한 투표를 시작한다. 블록 생성 자체가 완결성 여부에 묶여 있는 구조다. 심플렉스는 이 묶음을 푼 형태다. 커먼웨어의 표현을 빌리면, 심플렉스는 텐더민트 용어로 "2f+1 PREVOTE는 있지만 2f+1 PRECOMMIT은 아직 없는 시점"에 이미 다음 높이의 투표를 시작한다. 블록 생성은 2홉, 완결성은 3홉으로 서로 다른 주기를 갖는 것이 심플렉스가 더 빠른 블록 타임을 내는 구조적 이유다.

두 번째 차이는 장애 상황에 있다. 텐더민트는 라운드가 실패하면 별도의 라운드 전환 메커니즘으로 넘어간다. 심플렉스의 nullify는 notarize, finalize와 같은 형식의 투표라서 장애 경로가 정상 경로와 같은 메시지 처리, 같은 쿼럼 규칙, 같은 인증서 형태를 쓴다. 프로토콜이 단순해지고, 리더 장애 상황에서 복구를 일반 투표 한 라운드의 비용으로 끝낼 수 있다.

템포 외 결제 특화 L1들 중 많은 체인들이 텐더민트 계열을 선택했다. 이들과 템포가 갖는 차별점은 같은 완결성을 몇 홉 만에, 그리고 리더 장애 시 얼마 만에 회복하며 제공하는가에 있다. 템포는 0.5초대의 블록 타임과 완결성을 동시에 목표로 한다. 때문에 블록 생성과 완결성의 주기를 분리하는 심플렉스 쪽이 구조적으로 유리한 것이다.

5.4 임계 BLS

4.2에서 본 것처럼 템포는 심플렉스 엔진에 BLS 임계 서명 스킴을 플러그인 했다. 기본 구성에서 인증서는 2f+1개의 개별 서명 묶음이다. 임계 스킴에서는 각 밸리데이터가 DKG(Distributed Key Generation, 분산 키 생성)로 받은 서명 조각(signing share)으로 부분 서명을 만들고, 2f+1개의 부분 서명이 모이면 하나의 임계 서명으로 복원된다. 쿼럼은 전체 3f+1 중 2f+1이다.

복원된 인증서는 약 240바이트로, 위원회의 정적 공개키 하나만 알면 BLS 검증 한 번으로 확인된다. 밸리데이터가 누구인지, 몇 명인지, 언제 바뀌었는지 추적할 필요가 없다는 뜻이다. 이 성질은 네트워크 합의 외부에서 힘을 발휘한다. 커스터디 시스템, 브릿지, 정산 증빙처럼 템포 외부에서 완결성을 확인해야 하는 시스템이 노드를 운영하지 않고도 인증서 하나로 블록 확정을 검증할 수 있다.

다만 비용은 키 관리로 이전된다. 임계 서명은 최초 DKG를 요구하고, 위원회가 바뀔 때마다 서명 조각을 재분배(reshare)해야 하며, 밸리데이터의 키 라이프사이클이 "키 하나만 보관하면 되는 것"에서 "매 에포크 갱신되는 키 조각을 관리하는 것"으로 바뀐다.

5.5 리더 선출과 MEV

템포가 쓰는 vrf 방언에서는 모든 투표에 해당 뷰에 대한 부분 서명(attestation)이 하나 더 포함된다. 2f+1개가 모이면 시드(seed)라는 임계 서명이 복원되고, 이 시드가 다음 뷰의 리더를 결정한다. 코드 그대로 옮기면, 뷰 v+1의 리더는 v의 인증서에 포함된 시드 서명을 입력으로 한 무작위 선출(elector::Random)의 결과다.

이 구조는 두 가지 장점을 갖는다. 다음 리더는 현재 뷰가 끝나야 비로소 알려지므로, 특정 리더를 겨냥한 DoS 공격을 준비할 시간이 사실상 없다. 그리고 시드 자체가 2f+1 쿼럼의 임계 서명이라 리더든 소수 담합이든 값을 편향시킬 수 없다.

반면 한계도 존재한다. 이 시드는 같은 뷰 안에서 소비하는 실행 난수로는 안전하지 않다. f개의 비잔틴 부분 서명에 f+1개의 정직한 부분 서명만 더해지면 뷰가 끝나기 전에 값이 유출될 수 있어, 다음 뷰의 리더 선출처럼 한 박자 뒤에 소비하는 용도로만 건전하다. MEV에 대해서도 마찬가지다. 리더 예측이 어려워 사전 담합이나 표적 공격의 여지는 줄지만, 자기 뷰 안에서 트랜잭션 순서를 정하는 권한은 리더에게 그대로 있다. 리더 선출의 무작위화는 MEV의 완화 장치이지 제거 장치가 아니다. 템포의 경우 결제 트랜잭션의 포함 자체는 결제 레인(payment lane) 규칙이 합의 유효성 조건으로 보장하므로(6장에서 자세히 설명한다), 남는 것은 순서에서 나오는 이득이 된다.

5.6 합의와 블록 전파의 분리

심플렉스의 투표는 블록 전체가 아니라 블록의 다이제스트(digest)에 대해 이뤄진다. 실제 블록 데이터는 broadcast 프리미티브가 합의와 별도 채널로 전파하고, 놓친 블록이나 인증서는 resolver와 marshal이 백필한다. 큰 블록의 전파 지연이 투표 지연으로 직결되지 않도록 데이터 경로를 합의의 크리티컬 패스 밖으로 빼둔 구조다.

이렇게 분리된 구조는 평균 처리량보다는 꼬리 지연(tail latency)과 장애 복구 측면에서 더 효과적이다. 투표 메시지는 작고 형식이 고정되어 있어 네트워크 부하가 급변해도 합의 진행은 일정하게 유지되고, 일시적으로 뒤처진 노드는 인증서를 기준점 삼아 필요한 블록만 채워 넣으며 따라잡을 수 있다. Batcher의 지연 배치 검증 설계도 비슷하다. 서명을 하나씩 검증하는 대신 쿼럼이 모인 시점에 한 번에 검증하고, 배치가 실패하면 이분 탐색으로 잘못된 서명자를 찾아 차단한다.

정리하면, 템포의 합의 엔진인 임계 심플렉스 BFT를 통해 550ms 목표 블록 타임에서 약 600ms 주기로 블록이 만들어지게 된다. 또한 0.5초 수준의 리오그 없는 결정적 완결성이 가능하다. 완결성 인증서가 만들어진 순간이 곧 정산이 되기 때문에, 승인과 정산의 분리, 그리고 그 분리가 회계와 분쟁 처리까지 전파시킬 수 있는 문제의 여지가 사라진다.

6. 결제 전용 체인을 위한 템포만의 고유한 기능들

6.1 애플리케이션이 정의하는 블록

커먼웨어의 합의 엔진은 블록이 무엇인지 모른다. 심플렉스가 다루는 것은 다이제스트뿐이고, 다이제스트가 실제로 가리키는 블록의 형식과 유효성은 전부 애플리케이션, 즉 템포가 개발하는 코드의 몫이다. 템포가 새로 정의하는 것은 어떤 트랜잭션이 유효한가, 페이로드를 어떻게 구성하는가, EVM 실행 결과를 언제 합의에 전달하는가, 그리고 블록 시간 예산을 어떻게 배분하는가와 같은 로직이다.

템포의 블록 헤더는 표준 이더리움 헤더 앞에 세 개의 필드를 붙인 확장 타입이다. 비결제 트랜잭션의 가스 상한(general_gas_limit), 서브블록 구간의 가스 한도(shared_gas_limit), 그리고 서브초 블록에 필요한 밀리초 단위 타임스탬프다.

시간 예산은 3장에서 살펴본 구조처럼 목표 블록 시간 550ms에서 전파 예산 50ms를 뺀 나머지가 제안 처리와 페이로드 빌딩에 할당되고, 빌더는 남은 예산을 보며 트랜잭션 실행을 언제 멈출지 결정한다. 블록 시간의 규율이 합의 설정값이 아니라 애플리케이션 코드로 존재하는 것이다.

6.2 결제 레인: 블록스페이스를 합의 규칙으로 보호하기

범용 체인에서 결제 트랜잭션은 NFT 민팅, 대규모 청산과 같은 블록 공간을 두고 경쟁한다. 템포는 블록 전체 가스 한도와 별도로, 비결제 트랜잭션이 쓸 수 있는 가스에는 general_gas_limit이라는 상한이 걸려 있다. 즉, 네트워크에서 다른 트랜잭션들이 아무리 몰려도 이 상한까지만 블록을 채울 수 있고, 나머지 용량은 결제 트랜잭션의 몫으로 남는 것이다. 우선순위 멤풀과 달리 처리 순서를 조정하는 방식이 아니어서, 일반 트랜잭션의 자리를 미리 제한해 결제의 자리를 구조적으로 남겨둘 수 있다.

이 방식을 구현하기 위해서는 "무엇이 결제 트랜잭션인지"를 빠르고 확실하게 판별할 수 있어야 한다. 템포의 분류는 상태 조회 없이 트랜잭션 페이로드만으로 결정된다. 호출 대상이 TIP-20 주소 공간(0x20c0 프리픽스)인지, 호출 형태가 허용된 결제 함수 목록에 맞는지를 바이트만 보고 검사한다. 상태를 읽지 않으므로 분류 비용이 일정하고, 상태를 바꿔 분류를 조작할 여지는 없다.

중요한 것은 이 분류 규칙이 합의 유효성 조건이라는 점이다. general_gas_limit을 초과해 일반 트랜잭션을 채운 블록은 리더가 누구든 무효이고, 밸리데이터의 선의나 멤풀 정책과 무관하게 공증 자체를 받지 못한다. 결제를 위한 프로토콜의 요구조건 중 하나인 “네트워크 혼잡 시 보장”이 프로토콜 차원에서 제공되는 것이다.

6.3 수수료 모델과 대납

템포에서는 가스비와 우선순위 수수료를 스테이블코인으로 사용한다. 수수료로 쓸 수 있는 토큰은 고정된 것이 아니라 달러 표시로 발행된 네이티브 TIP-20이면서 수수료 AMM(Fee AMM)에 충분한 유동성이 있는 토큰이면 가능하다.

밸리데이터마다 받고 싶은 스테이블코인이 다른 문제는 수수료 AMM이 해결해준다. 사용자가 어떤 스테이블코인으로 수수료를 지불하든 프로토콜이 고정 환율로 밸리데이터 선호 토큰으로 변환해준다. 사용자가 1.0을 내면 밸리데이터는 0.9970을 받고 유동성 공급자가 0.3%를 가져가는 구조다. 변환은 트랜잭션 단위 대신 블록 단위로 배치 실행되어, 변환 시점을 노리는 MEV 공격의 여지를 줄인다.

비용 수준 자체는 고정에 가깝다. 기본 수수료는 이더리움식 혼잡 경매 대신 상한과 바닥이 있는 밴드 안에서 움직인다. 표준 전송 기준 상한이 약 $0.0006, 한산할 때 바닥이 약 $0.00003으로, TIP-20 전송은 네트워크 부하와 무관하게 $0.001 아래를 유지한다. 결제 레인이 용량을 보장하고 수수료 밴드가 가격을 보장하므로, 수수료에 대한 예측 가능성을 확보할 수 있다.

수수료 대납도 가능하다. 발신자가 트랜잭션에 서명하고 수수료 부담자가 그 위에 별도 서명 도메인으로 서명하는 이중 서명 구조라, 가스용 잔고가 없는 사용자의 수수료를 사업자가 대신 낼 수 있다. 여러 호출을 원자적으로 묶는 배치, 병렬 논스, 예약 실행까지가 템포 트랜잭션이라는 하나의 EIP-2718 타입에 들어 있다.

6.4 정책 집행: TIP-20과 TIP-403

범용 체인은 프로토콜이 알지 못하는 규칙은 프로토콜이 강제할 수 없다는 한계가 있다. 즉 스마트 컨트랙트로 짠 애플리케이션 코드와 같은 것들은 프로토콜이 강제할 수 없는 것이다. 템포의 경우 토큰 표준 자체에 통제 규칙을 넣었다. TIP-20은 역할 기반 접근 제어(RBAC)를 내장한 템포의 토큰 표준이다. 발행과 소각(ISSUER 롤), 전송 일시 중지와 해제(PAUSE/UNPAUSE 롤), 차단된 주소 잔고의 컴플라이언스 소각(BURN_BLOCKED 롤) 같은 권한이 존재한다. 컨트랙트마다 제각각 구현되던 기능들이 템포에서는 프로토콜에서 정해주는 표준의 일부가 된다.

TIP-403 정책 레지스트리는 이 통제를 토큰 단위에서 정책 단위로 격상한다. 프로토콜 차원에서 허용 목록(whitelist)과 차단 목록(blacklist) 정책을 레지스트리에 등록해두면 여러 토큰이 같은 정책을 참조하는 것이다. 관할권 규칙이 바뀌어 발행사가 목록을 수정하면 그 정책을 쓰는 모든 토큰에 한 번에 적용된다. 토큰마다 정책이 제각각이던 문제가 구조적으로 사라진다. 트레블 룰 대응처럼 관할권마다 다른 규제 요구사항도 이런 도구들을 조합해 구현할 수 있다.

컨트랙트에 얹은 통제는 그 컨트랙트가 잘 구현되었기를 바라야 하지만, 표준에 새긴 통제는 블록체인의 합의 규칙이 된다. 결제로 분류되는 호출 형태 자체가 TIP-20의 함수들로 정의되어 있으므로, 정책 집행과 결제 레인은 결국 같은 표준을 따르게 된다.

6.5 템포 존: 프라이버시와 상호운용성의 절충

이제 남은 것은 공개 원장이 영업 정보를 상시 유출한다는 문제다. 템포 존(Tempo Zones)은 메인넷에 연결된 병렬 프라이빗 실행 환경이다. 각 존은 지정된 시퀀서가 운영하며, 예치 자금은 메인넷의 존 포털(Zone Portal) 컨트랙트에 잠긴다. 존 안에서 일어난 상태 전이는 유효성 증명(validity proof)으로 만들어져 메인넷에서 검증된다. 증명은 Rust로 작성된 상태 전이 함수를 ZKVM이나 TEE에서 실행해 생성하고, 포털 컨트랙트가 온체인에서 상수 비용으로 검증한다. 메인넷 밸리데이터에게는 일반 트랜잭션 실행 이상의 추가 부담이 없다.

구조만 보면 템포 존은 이더리움의 ZK 롤업과 비슷하다. 자금을 부모 체인 컨트랙트에 잠그고, 시퀀서가 외부에서 실행하고, 상태 전이를 증명의 형태로 부모 체인에서 검증한다(굳이 기존 분류에 대응시키면 데이터를 체인 밖에 두는 밸리디움에 가깝다). 방식은 비슷하지만 목적에서 차이가 있다. 롤업은 처리량 확장을 위해 실행을 밖으로 빼는 대신 트랜잭션 데이터를 부모 체인에 공개 게시한다. 이는 누구나 롤업의 상태를 재구성할 수 있게끔 한다. 존은 반대로 프라이버시를 위해 데이터를 밖에 두고 증명만 게시한다. 롤업이 확장성이 주 목적이고, 템포 존은 프라이버시가 목적인 것이다.

템포 시퀀서의 권한은 유효한 트랜잭션의 포함과 순서 결정으로 제한된다. 자금을 탈취하거나 상태를 위조할 수 없고, 발행사의 토큰 정책은 존 안에 그대로 미러링되어 증명이 그 준수까지 커밋한다. 다만 시퀀서에게 남는 힘이 하나 있다. 검열이다. 인출 요청을 포함하지 않고 미루는 것은 가능하고, 문서상 강제 인출 메커니즘은 없다. 탈취와 위조는 불가능하지만 검열은 가능하다는 것이 존의 정확한 신뢰 모델이다.

프라이버시의 관측 범위도 명확하다. 외부에서는 존 안의 잔고, 전송, 거래 내역이 익스플로러와 인덱서에 보이지 않고 유효성 증명만 관측된다. 급여 지급이나 가맹점 정산을 존 안에서 처리하면 유출 문제가 해소된다. 단 이 프라이버시는 외부에서 바라보는 기준이며 시퀀서는 존 안의 모든 거래를 볼 수 있다. 존이 제공하는 것은 운영자와 거래 당사자만 보는 시스템이고, 기존 결제 프로세서의 데이터 접근 구조와 비슷한 수준의 기밀성이라고 보는 것이 정확하다. 템포 존을 통한 프라이버시 송금에 대한 대가는 상호운용성이다. 존과 메인넷, 존과 존 사이의 자금 이동은 포털 경유와 증명 생성 주기를 따라야 한다.

6.6 그 밖의 결제 기능들

이 밖에도 템포에는 결제를 위한 기능들이 여럿 존재한다. 트랜잭션에는 표준화된 메모를 붙일 수 있어 기업 시스템의 대사(reconciliation) 절차와 연결되고(ISO 20022 호환을 염두에 둔 설계다), 예약 결제는 정기 급여나 구독 청구를 온체인 스케줄로 구현할 수 있도록 지원한다. 패스키(WebAuthn/P256) 서명 지원은 하드웨어 보안 모듈이나 휴대폰의 생체 인증으로 트랜잭션에 서명할 수 있게 해, 결제 사업자가 사용자에게 시드 구문을 요구하지 않아도 되게 한다. 이러한 기능들은 결제 사업자가 템포를 사용하면 기존 운영 절차를 온체인에서 그대로 재현할 수 있게끔 돕는다.

7. 트레이드오프: 특화 네트워크 구성을 위해 포기해야 하는 것들

7.1 커스터마이징의 이점과 트레이드오프

2.4에서 정리한 “결제 워크로드가 인프라에 요구하는 다섯 가지 요구조건”을 기준으로 이더리움 L2, CometBFT 계열 EVM L1, 그리고 템포를 비교해보자.

템포가 선택한 기술 스택이 더 좋아 보이는 것이 당연하다. 템포는 결제에 최적화되어 조립된 모듈식 블록체인이기 때문이다. 물론 여기에는 트레이드오프가 존재한다. 템포가 포기한 것들은 다음과 같다.

• 이더리움의 보안을 상속하지 않기 때문에 자체 밸리데이터 집합에 보안을 의존해야 한다.
• IBC와 같은 표준화된 체인간 상호 운용 프로토콜이 존재하지 않기 때문에 외부와의 연결은 브릿지와 인증서 검증을 직접 구축해야 한다.
• 커먼웨어는 이제 막 등장한 신생 기술스택이다. 프레임워크의 검증된 표준이 존재하지 않는다.
• 클라이언트 다양성을 가져가기 어려운 구조다.

이들은 템포가 결제라는 단일 워크로드에 네트워크의 모든 것을 최적화한 것에서 오는 대가다.

7.2 네트워크를 운영하는 밸리데이터

규제 대응 측면에서 체인을 검증하는 주체가 누구인가도 중요하다. 템포의 밸리데이터 집합은 온체인 컨트랙트로 관리되는 허가형 화이트리스트고, 스테이킹도 없다. 템포의 앵커 밸리데이터는 스트라이프, 비자(Visa), 스탠다드차타드 산하 조디아 커스터디(Zodia Custody), 머니그램(MoneyGram)으로, 전부 금융 규제 체계 안에서 신원이 식별되고 책임을 지는 기관들이다. 결제 사업자가 규제 기관에 "이 원장은 누가 운영하는가"를 설명해야 할 때, 익명의 노드 집합보다는 컴플라이언스 심사를 통과한 기관 명단이 더 유리할 것이다.

작은 밸리데이터 집합은 성능에도 유리하다. 5장의 홉 계산이 0.5초로 끝나는 것은 소수의 고성능 노드가 인증된 연결로 묶여 있기 때문이고, 장애 시 책임 소재도 명확하다. 네트워크 참여가 허가형(permissioned)이라는 것, 그리고 지리적/관할권적 다양성이 제한된다는 것은 탈중앙 네트워크로서의 블록체인 정신과는 거리가 있다. 사실 검열 저항성을 범용 체인의 기준으로 평가하면 템포는 높은 점수를 받기 어렵다.

때문에 템포의 리스크는 익명 다수가 네트워크 합의를 장악하는 것이 아니라 식별 가능한 기관의 책임 이행에 있다. 은행 간 정산망을 평가하는 축에 가깝고, 체인이 분기될지언정 멈추지 않는 것이 중요한 이더리움과는 달리 "멈출지언정 틀리지 않는다"는 선택을 한다.

7.3 처리량 외의 병목

합의가 0.5초로 빨라져도 실행과 상태 I/O는 그대로다. 그리고 결제 사업자의 실제 병목은 쓰기보다 읽기일 가능성이 크다. 때문에 템포가 권장하는 RPC 노드 사양은 밸리데이터 권장 사양보다 높다. 결제 서비스는 트랜잭션을 넣는 것만큼이나 상태 조회, 웹훅, 온체인 기록이 자사 장부와 맞는지 대조하는 일을 한다. 결제 네트워크의 성능을 평가하려면 쓰기 TPS 뿐 아니라 조회와 대사(reconciliation)까지 포함한 엔드투엔드 파이프라인을 봐야 하고, 그 병목은 합의 프로토콜 외부에 있다.

7.4 남아 있는 질문

• 비허가형(permissionless)으로의 전환: 템포는 비허가형 밸리데이터로 확장할 것임을 이야기한다. 하지만 템포의 구조에서는 밸리데이터가 늘수록 매 에포크의 DKG 비용이 함께 커진다. 지리적으로 분산된 큰 집합에서 0.5초 완결성과 DKG 주기가 함께 유지되는지는 아직 확인된 바 없다. 또한 스테이킹이 없으므로 슬래싱도 없고, 잘못된 행동에 대한 제재는 프로토콜 밖의 계약과 규제 관계에 있다. 이 모델이 비허가형으로의 확장과 양립할 수 있는지는 미지수다.
• 임계 인증서의 외부 활용: 노드 없이 검증 가능한 240바이트 인증서는 브릿지와 정산 증빙의 재료로 쓰일 수 있지만, 이를 소비하는 표준이 아직 없다.
• 합의 구조의 진화: 커먼웨어는 더 낮은 지연을 노리는 후속 프로토콜 미니밋(Minimmit)을 이미 발표했다. 커먼웨어는 모듈화된 부품 상자이기에 합의 엔진 교체는 기존 체인들보다 수월하다. 템포의 합의는 지금의 임계 심플렉스에서 바뀔 수 있는 것이다.

8. 마치며: 특화된 시스템을 만든다는 것

크립토는 국가와 은행 바깥의 화폐를 꿈꾸던 소수의 사이퍼펑크에서 출발했다. 하지만 지금 이 기술의 주 사용자는 바뀌고 있다. 정부와 금융 기관이 진입하고 있으며, 그 출발점이 결제다. 다양한 기관이 저마다의 방식으로 결제 레일을 블록체인 위에 올리고 있다. 그들 중 하나인 템포는 결제만을 위해 기존 블록체인 스택을 재조립하는 선택을 했다. 범용 실행 환경은 그대로 두고 합의, 블록스페이스, 수수료, 토큰 표준을 결제라는 요구에 맞춰 부품 단위로 재조립했다.

템포는 분명 중앙화된 네트워크며 사실 기존 범용 체인의 기준으로 보면 블록체인다움을 대부분 잃은 셈이다. 우리가 집중해야 하는 것은 중앙화 논쟁 같은 것이 아니다. 흔히 통용되던 블록체인 네트워크의 구성 요소 중, 특정한 요구를 맞추기 위해 어느 부분까지 다시 설계할 수 있는가에 집중해야 한다. 그리고 템포가 도입한 커먼웨어와 같은 부품 상자의 등장은, 세부적인 부분까지 커스터마이징이 필요한 기관향 네트워크의 수요를 명확하게 보여준다.

물론 탈중앙성이 더 이상 중요하지 않다는 것은 아니다. 템포 같은 특화 네트워크들이 자산과 대중 사용자를 온체인으로 온보딩할수록, 검열 저항성과 탈신뢰성을 갖춘 극소수 네트워크의 가치는 오히려 더 높아질 것이다. 그럼에도 탈중앙을 위해 포기해야 하는 성능 문제와, 규제 환경에 들어맞지 않는 검열 저항성으로는 결제와 같은 기관의 워크로드를 감당할 수 없다. 두 종류의 네트워크는 보완재이지 서로의 대체재가 아니다. 그리고 템포는 특화 블록체인이 기술적으로 나아갈 방향을 구체적으로 보여주는 좋은 사례다.