Fabric 롤업, 성능 착시 피하기 (접수TPS, 최종성, 시퀀서)

 

Fabric 롤업, 성능 착시 피하기 (접수TPS, 최종성, 시퀀서)

Hyperledger Fabric의 병목을 “L2 시퀀서로 접수와 정산을 분리”해 풀겠다는 이 논문은 방향이 명료합니다. 다만 202 Accepted 기반의 체감 성능과 실제 최종성 성능을 같은 문장에 섞는 순간, 독자가 “Fabric이 100 TPS로 확장됐다”라고 오해할 여지가 커집니다.

접수 성능(접수)의 ‘10×’는 무엇을 뜻하나

이 논문이 제시하는 핵심 아이디어는 Fabric의 표준 트랜잭션 플로우(endorse→order→validate)가 고부하에서 처리량과 지연을 제한하므로, L2에 해당하는 off-chain sequencer를 두어 트랜잭션을 “즉시 접수(ingestion)”하고 “나중에 정산(settlement)”하자는 것입니다. 아키텍처는 클라이언트가 REST API로 /submit을 호출하면 시퀀서가 Redis-backed transaction pool에 넣고, 32개씩 배치로 꺼내 Merkle tree를 구성한 뒤 PLONK 기반 ZK-SNARK proof를 생성하고, 비더미 트랜잭션은 JSON으로 IPFS에 업로드하여 CID를 얻은 다음, Fabric 체인코드에는 Merkle root + proof + CID + 메타데이터만 기록하는 흐름입니다(그림/설명, 알고리즘 1).

논문이 “10× throughput, 80% latency 감소”라고 말할 때, 측정 정의를 보면 본질이 드러납니다. 베이스라인은 /submit-direct에서 HTTP 200 OK(완전 커밋 완료)까지 기다리는 동기식 방식이고, 롤업은 /submit에서 HTTP 202 Accepted(시퀀서가 접수했음을 의미)만 받으면 요청이 끝납니다. 즉, throughput/latency의 기준점이 애초부터 다릅니다. 논문도 이를 “client-perceived latency”로 표현하며, ZK-rollup 실험은 “온체인 정산이 완료됐는지와 무관하게 접수된 시점”을 지표로 잡았다고 명시합니다.

이 구조 자체는 서비스 설계로는 충분히 타당합니다. 예를 들어 “메타버스 이벤트 같은 수요 스파이크를 흡수”하려면, 사용자가 버튼을 눌렀을 때 즉시 응답을 주고(202), 백그라운드에서 정산을 천천히 따라가게 하는 방식이 실무에서 자주 쓰입니다. 논문도 “ingestion을 fast하게, settlement를 background에서 병렬로”라는 설명을 반복합니다.
다만 학술적 주장, 특히 “Fabric scalability를 해결했다”는 결론을 쓰려면, 최소한 다음 두 문장을 분리해서 써야 정직해집니다.

우리는 Fabric의 최종성 처리량(finality TPS)을 높였다.

우리는 Fabric의 최종성을 늦추되, 사용자 체감 지연과 접수 처리량을 높였다.

현재 논문은 두 문장이 한 단락 안에서 섞여 읽히는 구간이 있어, 독자가 “100+ TPS로 처리한다”를 최종성까지 포함한 수치로 받아들일 위험이 있습니다. 특히 초록에서 baseline 5–7 TPS, 평균 지연 4초에 대비해 L2가 ingestion 70–100 TPS라고 말하는 문맥은 매우 강한 인상을 주는데, 그 수치가 202 기반이라는 점을 더 전면에 내세우는 편이 안전합니다.

여기서 “좋은 아이디어가 왜 오해를 부르는가”를 한 줄로 정리하면, 지표의 이름이 너무 일반적이기 때문입니다. 논문은 “throughput(request/s)”로 표현하지만, 실제로는 “acceptance throughput”입니다. 따라서 보강 실험 없이도, 표기만 바꿔도 과학적 정확도가 올라갑니다. 예를 들어 결과 그래프의 레이블을 “ingestion throughput(202)”과 “settlement throughput(batch commit)”로 명확히 분리하면, 같은 데이터라도 독자의 신뢰가 달라집니다.

구분	논문에서 실제로 잰 값의 의미
Baseline TPS/지연	HTTP 200 OK(온체인 endorse→order→commit 완료)까지의 처리량/지연
Rollup TPS/지연	HTTP 202 Accepted(시퀀서 접수 완료)까지의 처리량/지연
정산 병목	배치당 ZK proof 생성 35–45초(8코어 테스트 환경), IPFS 업로드 1–2초

이 표가 말하는 핵심은 간단합니다. 논문이 성능을 “높였다”고 할 때, 무엇을 높였는지(접수 vs 최종성)가 먼저 고정되어야 합니다. 이 고정이 안 되면, 리뷰어는 ‘지연을 숨긴 것’인지 ‘실제로 확장한 것’인지부터 의심하게 됩니다. 사용자가 지적한 “클라이언트가 202를 받는 속도” 중심이라는 비판은, 논문 텍스트 자체가 그 전제를 깔고 있다는 점에서 매우 정확합니다.

최종성(최종성) 처리량은 어디서 결정되나

논문이 스스로 인정하듯, 현재 실험의 “진짜 정산(settlement)”은 증명 생성 시간이 지배합니다. 평가 섹션에서 배치당 ZK-Proof generation time이 35–45초라고 명시되어 있고, 이는 “test hardware(8 CPU cores)” 때문에 CPU-bound 병목이 발생한다고 설명합니다. 또한 배치 크기는 32개로 고정이며, 트랜잭션 풀이 부족하면 dummy transaction으로 패딩해 회로 크기를 일정하게 유지한다고 적습니다.

이 조건을 그대로 두면, 단순 근사로 “정산 TPS”는 32건/40초 ≈ 0.8 TPS 수준이 됩니다. 여기에 Fabric 체인코드 검증/커밋, 네트워크 지연, 재시도까지 포함하면 더 낮아질 수 있습니다. 논문은 “production hardware에서 GPU/FPGA 병렬화로 <1초, 그러면 정산도 ingestion을 따라간다”고 주장하지만, 이 문장은 현재 데이터로 증명된 사실이 아니라 가정(전망치)에 가깝습니다.

여기서 중요한 논점은 “그럼 이 논문은 실패인가”가 아닙니다. 오히려 논문이 가진 가치는, Fabric에 롤업을 붙일 때 필연적으로 생기는 두 개의 속도계를 한 시스템 안에 넣어 보여줬다는 점입니다. 즉,

acceptance throughput(큐에 넣는 속도)

settlement throughput(최종성으로 밀어넣는 속도)
가 분리되는 순간, 시스템은 큐(backlog)라는 제3의 상태 변수로 평가되어야 합니다.

따라서 논문을 한 단계 더 ‘성능 논문’으로 올리는 최소 보강은 “backlog의 안정성 그래프”입니다. 예를 들어 30초 부하 테스트 동안 100 TPS로 접수했으면 총 3,000건 가까이 쌓입니다. 배치가 32개이고 증명 생성이 40초면, 같은 시간 동안 정산되는 배치는 0개 또는 1개 수준일 수 있습니다. 이때 큐 길이가 시간이 지날수록 계속 증가한다면, 시스템은 확장이 아니라 “지연을 뒤로 미룬 것”이 됩니다. 반대로 큐 길이가 일정 구간에서 안정화(steady state)되면, 그때 비로소 “스케일링이 된다”고 말할 근거가 생깁니다.

논문에도 ‘진짜 정산 지표’를 로그로 기록한다고 별도 항목(3.4)을 두어 ingestion과 settlement를 구분하겠다고 말합니다. 하지만 결과 제시는 여전히 ingestion 그래프(그림 7)와 체감 지연 그래프(그림 8)가 전면에 있고, 정산 TPS를 독자가 한눈에 읽을 수 있는 형태로는 충분히 나오지 않습니다. 이 구성은 “메시지의 강약”을 실제와 다르게 전달할 수 있습니다. 즉, 독자는 ‘정산의 느림’을 각주처럼 읽고, ‘접수의 빠름’을 결론처럼 읽게 됩니다.

또 한 가지, 최종성 지연을 쪼개 보여주는 것이 중요합니다. 이 시스템은 실제로 최소 3개의 지연 축을 갖습니다.

Data availability latency: IPFS 업로드 완료까지(논문에서는 1–2초 수준이라고 설명)

Proof generation latency: 배치 증명 생성(35–45초)

On-chain finality latency: Fabric에 root/proof/CID를 제출하고 endorsement/ordering/commit이 끝나는 시간(논문에서는 별도 수치가 전면에 나오지 않음)

이 세 가지를 분리하면, “202로 줄어든 지연”이 어떤 지연을 줄인 것인지가 명확해집니다. 지금처럼 200 OK 기반 baseline과 202 Accepted 기반 rollup을 직접 비교하면, 실제 최종성은 줄지 않았는데도 그래프에서 큰 개선으로 보이기 쉽습니다(사용자 비평의 핵심). 결국 이 논문이 주장하는 “80% latency 감소”는 대체로 “사용자 체감(perceived)”의 감소이며, 최종성(finality)의 감소가 아닐 가능성이 큽니다.

여기서 실천 팁을 하나 제안하면, 논문이 다음 버전에서 결과 섹션을 이렇게 재배치하는 것이 좋습니다.

첫 페이지 결과: 정산 TPS(배치/초) + backlog 곡선 + 최종성 지연(p50/p95)

두 번째 페이지 결과: 체감 지연(202) + 접수 TPS
이 순서를 바꾸는 것만으로도 “성능을 숨기지 않는 설계”라는 인상을 줄 수 있습니다.

시퀀서(시퀀서) 신뢰·가용성·프라이버시를 어떻게 다룰까

이 논문의 구조는 permissioned Fabric이라는 맥락에서 합리적인 절충처럼 보이지만, 동시에 “시퀀서가 사실상의 단일 운영 포인트”가 됩니다. 논문은 시퀀서가 트랜잭션을 받아 Redis에 저장하고, 32개씩 배치하며, Merkle root와 PLONK proof를 만들고, IPFS에 업로드하고, 마지막으로 Fabric에 제출하는 전 과정을 주도한다고 설명합니다. 이때 ZK proof가 보장하는 것은 주로 “정확성(이 배치 루트가 이 트랜잭션 집합에 대응한다)” 쪽입니다. 그러나 롤업 시스템에서 실제 운영 리스크는 정확성만이 아니라 다음 항목에서 터집니다.

첫째, 검열(censorship)과 누락(omission)입니다. 시퀀서가 어떤 트랜잭션을 “받았다(202)”고 응답해 놓고, 실제 배치에 넣지 않거나, 특정 참가자의 트랜잭션을 의도적으로 늦출 수 있습니다. 현재 설계는 202가 곧 “포함 보장”을 뜻하지 않습니다. 논문이 강해지려면, 클라이언트가 “내 트랜잭션이 특정 배치 Merkle root에 포함되었다”를 증명할 수 있는 inclusion proof를 제공하거나, 최소한 배치 ID/인덱스와 함께 검증 가능한 영수증을 내려주는 프로토콜이 필요합니다. 논문은 온체인 메타데이터 구조(배치ID, CID, proof, merkleRoot, timestamp)를 보여주지만, 클라이언트 관점의 포함 증명 UX까지는 충분히 설계되지 않습니다.

둘째, 데이터 가용성(DA)입니다. 논문은 IPFS에 JSON을 업로드하고 CID로 참조하면 “무결성과 가용성”을 얻는다고 서술합니다. 하지만 IPFS의 가용성은 핀닝/리플리케이션/접근권한에 달려 있고, permissioned 환경이라면 오히려 “누가 핀을 유지하는가, 운영 주체가 서비스를 중단하면 CID는 남아도 데이터는 사라질 수 있는가”가 핵심 질문입니다. 이 논문이 Fabric ‘스케일링’만 말할 거라면 DA는 부차적일 수 있지만, 초록과 서론에서 “privacy-preserving”을 동기로 삼는다면 DA/접근통제(암호화, 키 관리)를 더 구체적으로 적어야 동기와 구현이 일치합니다.

셋째, 프라이버시입니다. 논문에서 각 트랜잭션은 CreateAsset 체인코드 호출이며 AssetID, Participant Identifier, IPFS CID를 포함한다고 설명합니다. 그리고 배치 데이터는 JSON으로 IPFS에 올라갑니다. 이 구조는 “온체인에 원본을 안 올린다”는 의미에서 프라이버시와 유사한 효과를 줄 수 있지만, IPFS에 올라간 페이로드가 암호화되지 않으면 프라이버시 주장은 약해집니다. 또한 CID는 내용 기반 주소이므로, 접근 가능한 사람이면 그대로 내용을 열람할 수 있습니다. 따라서 최소한 다음 중 하나는 필요합니다.

IPFS 페이로드 암호화(대칭키) + 키 배포/접근정책 명시

또는 ZK proof의 역할을 “정확성”에서 “내용 비공개 검증”으로 확장(예: 특정 속성만 증명)
현재 논문은 PLONK proof를 “Merkle root correctness attestation” 중심으로 사용하므로, 프라이버시 동기는 구현 세부와 다소 어긋날 수 있습니다.

넷째, 장애 복구와 감사(audit)입니다. 시퀀서가 죽으면 어떤 일이 생기는지, Redis에 쌓인 풀은 어떻게 보존되는지, 배치 생성 도중 실패하면 롤백/재시도는 어떻게 하는지, 그리고 그 과정이 Fabric 감사 로그와 어떻게 정렬되는지가 운영에서 매우 중요합니다. 논문은 k6로 30초 부하를 주고 여러 번 반복 실행한 그래프를 보여주는 좋은 습관은 있지만, 장애/재시도/이중 제출 같은 “현실적 실패 모드”는 거의 다루지 않습니다.
이 논문이 엔터프라이즈를 겨냥한다면, “단일 시퀀서” 대신 “다중 시퀀서(동일 오더/리더 선출)” 또는 “감사 가능한 로그(append-only)” 같은 최소 안전장치의 방향성을 제시해 두는 것만으로도 신뢰가 커집니다.

마지막으로, 평가 환경의 크기 문제입니다. 논문은 모든 실험을 KinD(로컬 8코어/8GB)에서 수행했다고 밝힙니다. 이 선택은 재현 가능성 측면에서 장점이 있지만, Fabric 성능은 endorsement policy, block size, batch timeout, peer/orderer 리소스, DB 선택(LevelDB/CouchDB), 네트워크 지연에 따라 크게 달라집니다. 따라서 “baseline 5–7 TPS”를 Fabric 일반 한계처럼 읽히게 하기보다는, “우리 설정에서 관측된 baseline”으로 표현을 낮추고, 주요 설정값을 표로 고정해 주는 편이 안전합니다. 논문도 baseline이 기존 문헌과 일치한다고 말하지만, 독자 입장에서는 설정이 공개되어야 공정 비교로 인정하기 쉽습니다.

이 논문은 Fabric 병목을 “접수-정산 분리”로 풀려는 방향과 구현 자체는 설득력이 있습니다. 다만 202 기반 접수 TPS를 최종성 성능처럼 읽히지 않게 분리 보고하고, 35–45초 증명 병목에 따른 backlog/정산 TPS, 시퀀서 신뢰·DA·프라이버시 설계를 보강하면 결론이 훨씬 단단해집니다.

자주 묻는 질문 (FAQ)

Q. 논문에서 말하는 100+ TPS는 Fabric이 실제로 처리하는 TPS인가요? A. 본문 정의상 100+ TPS는 /submit에서 HTTP 202 Accepted를 받는 “ingestion(접수) 처리량”입니다. 온체인 최종성은 배치 증명 생성(35–45초/배치)과 Fabric 커밋에 의해 제한될 수 있어, 별도로 settlement TPS로 제시되는 것이 안전합니다.

Q. 지연이 300–400ms로 줄었다는 결과는 무엇이 줄어든 건가요?
A. 베이스라인은 HTTP 200 OK(온체인 커밋 완료)까지 기다리지만, 롤업은 202(접수 완료)까지만 기다리므로 “사용자 체감 지연(perceived latency)”이 줄어든 것입니다. 최종성 지연(finality latency)은 별도 측정으로 분리 보고하는 것이 해석에 유리합니다.

Q. 시퀀서를 신뢰해야 한다면 ZK proof의 의미가 줄어드나요?
A. ZK proof는 배치 커밋의 “정확성”을 강화하지만, 검열/누락, 데이터 가용성(특히 IPFS 핀닝), 장애 복구 같은 운영 리스크는 별도 설계가 필요합니다. 클라이언트 inclusion proof, DA/암호화 정책, 시퀀서 장애 대응이 함께 제시되면 전체 신뢰 모델이 완성됩니다.

[출처]
https://arxiv.org/html/2602.08870v1