ZKP와 동형암호로 설계하는 블록체인 프라이버시와 확장성

비밀은 감추고 결과만 검증하는 암호 기술

Zero-Knowledge Proof(ZKP)는 어떤 주장이 참이라는 점은 증명하지만, 그 판단에 사용한 비밀 입력은 노출하지 않는 대화형 또는 비대화형 증명 메커니즘이다. 블록체인에서는 검증 가능한 계산 위임과 프라이버시 보장을 위한 수단으로 사용된다.

zk-SNARK는 짧은 증명과 빠른 검증이 강점이며, 신뢰 설정(Trusted Setup)과 타원곡선 쌍선형 페어링을 사용한다. zk-STARK는 신뢰 설정 없이 FRI 기반 IOP(Interactive Oracle Proof) 구조를 사용하고 양자내성을 갖지만, 증명 크기가 큰 편이다.

Homomorphic Encryption(동형암호)은 암호문을 복호화하지 않은 상태에서 연산할 수 있도록 설계된 공개키 암호다. Enc(x)와 Enc(y)로부터 Enc(f(x,y))를 직접 계산한다. FHE는 완전동형, SHE는 유한연산, PHE는 부분동형 방식으로 구분되며, 프라이버시 보존형 오프체인 연산과 데이터 협업에 적합하다.

회로, 증명, 키 관리가 맞물리는 방식

프로그램은 R1CS 또는 PLONKish 회로로 산술화한다. 연산 복잡도는 게이트 수와 깊이에 비례한다. 회로를 다듬을 때는 해시 선택(Keccak→Poseidon), 고정 베이스 MSM 사전연산, Lookup 활용이 최적화 지점이 된다.

Prover는 공용 입력과 비밀 증인을 바탕으로 증명 π를 만들고, Verifier는 π와 공용 입력으로 참·거짓을 판정한다. SNARK는 KZG/Pairing을, STARK는 Merkle+FRI를 통해 다항식 위조 불가능성을 보장한다.

SNARK에는 CRS(공통참조문자열) 생성이 필요하다. 다자간(MPC) 의식과 토식 웨이스트 폐기가 요구된다. STARK는 별도 설정이 필요 없지만 보안비트와 Blowup factor 같은 파라미터를 관리해야 한다.

동형암호 파이프라인은 KeyGen, Enc, Eval, Dec으로 이어진다. KeyGen으로 공·개인키를 만들고, Enc로 데이터를 암호화한 뒤, Eval로 암호문 연산을 수행하고, Dec으로 결과를 복호화한다. 연산 깊이에 따라 노이즈 예산을 관리하고 재선형화 또는 리샘플링이 필요하다.

스킴은 연산 성격에 따라 고른다.

CKKS는 실수 근사 연산에 맞아 머신러닝과 통계 처리에 적합하다.
BFV/BGV는 정확한 정수 연산과 규칙 기반 로직에 맞는다.
TFHE는 비트 레벨 게이트와 짧은 레이턴시가 필요한 경우에 쓴다.

오프체인 계산과 온체인 검증의 경계

일반적인 통합 구조에서는 Prover가 오프체인에서 증명을 생성하고, 온체인 컨트랙트가 짧은 증명을 검증한다. 데이터 가용성(DA) 레이어와 결합하면 상태 일관성을 유지할 수 있다.

동형암호를 사용할 때는 오프체인에서 암호문 연산을 수행하고 결과만 복호화한다. 이 과정에는 HSM/KMS 기반의 접근 제어와 키 관리 체계가 함께 필요하다.

⤢✕

검증이 실패하면 트랜잭션을 revert 처리해 상태 불변을 보장한다. 데이터 가용성에 결함이 생기면 블록 생산을 차단하거나 L1 강제 포함 메커니즘을 적용한다. HE 노이즈가 초과되면 재암호화 또는 파라미터 재설정이 필요하다.

롤업부터 연합 분석까지의 적용 범위

zk-Rollup과 Validium은 거래를 집계한 뒤 상태 전이가 올바르다는 사실을 ZKP로 증명하고, L1은 검증만 수행한다. 수천 TPS 달성이 가능하며, 데이터 가용성 전략에 따라 비용과 보안을 조정한다.

zk-KYC와 zk-PoP(Proof of Personhood)는 미성년이 아님, 제재 대상이 아님과 같은 속성만 증명하고 원본 신분정보는 공개하지 않는다. 규제 준수와 탈중앙 특성 사이의 균형을 위한 방식이다.

DEX 주문 매칭이나 MEV 저감 입찰에서는 주문과 입찰 내용을 ZK 또는 FHE로 은닉하고, 결과만 검증 가능한 형태로 공개할 수 있다. 전략 유출을 최소화하고 프런트러닝을 억제하는 데 목적이 있다.

다기관 의료·금융 데이터 연합 분석에서는 동형암호와 프라이버시 예산을 이용해 통계 처리와 ML 모델 학습을 수행한다. 원천 데이터를 이동하지 않고도 합법적으로 활용할 수 있다.

성능과 보안 특성을 함께 비교하기

항목	성능(증명/검증)	확장성(증명 크기/롤업 적합)	일관성(암호가정)	안정성(양자내성/보안)	운영 편의(설정/툴링)	비고
zk-SNARK (Groth16/Plonk)	증명 빠름, 검증 매우 빠름	증명 매우 작음(수백 B)	강한 수학 가정+페어링	양자내성 낮음	Trusted Setup 필요(Plonk는 유연), 도구 성숙	온체인 비용 낮음
zk-STARK	증명 생성 중간~느림, 검증 중간	증명 큼(수십~수백 KB)	표준 해시 가정+FRI	양자내성 높음	설정 불필요, 감사 용이	데이터 가용성과 궁합 우수
FHE (CKKS/BFV/TFHE)	연산 비용 매우 큼	대규모 연산은 오프체인 전제	표준 격자 가정	양자내성 높음	파라미터·노이즈 관리 난도 높음	완전한 비공개 연산 가능

zk-SNARK 검증 가스는 대략 200k~~700k gas 수준이며 환경에 의존하므로 최신 정보 확인이 필요하다. zk-STARK 증명 크기는 수십 KB~~수백 KB이고 검증 비용이 증가하는 경향이 있다. L2 롤업 TPS는 L1 대비 10~100배 이상 향상된 사례가 다수다.

이 구조는 민감 데이터의 온체인 노출과 재식별 리스크를 줄이고, STARK 계열을 통해 장기 보안성을 높일 수 있다. 대규모 계산을 오프체인으로 위임하고 온체인 검증을 최소화하며, 규제 준수 증명 자동화로 심사 비용을 절감할 수 있다.

zk-SNARK 회로와 온체인 검증 예시

전제조건은 Node.js >= 18, snarkjs 0.7.x, circom 2.1.x, Docker(optional), Linux/macOS다. 쌍선형 페어링을 지원하는 L1(Ethereum)을 가정한다.

회로 정의는 multiplier2.circom에서 다음과 같이 작성한다.

pragma circom 2.1.6;

template Multiplier2() {
    signal input a;
    signal input b;
    signal output c;
    c <== a * b;
}

component main = Multiplier2();

입력은 다음과 같다.

{
  "a": "3",
  "b": "11"
}

빌드, 증명 생성, 검증, Solidity 검증자 생성은 아래 명령을 사용한다.

# 설치
npm i -g snarkjs
# 컴파일
circom multiplier2.circom --r1cs --wasm --sym
# 신뢰 설정(Groth16)
snarkjs groth16 setup multiplier2.r1cs powersOfTau28_hez_final_10.ptau circuit_0000.zkey
snarkjs zkey contribute circuit_0000.zkey circuit_final.zkey --name="p1"
snarkjs zkey export verificationkey circuit_final.zkey verification_key.json
# 증명 생성
node multiplier2_js/generate_witness.js multiplier2_js/multiplier2.wasm input.json witness.wtns
snarkjs groth16 prove circuit_final.zkey witness.wtns proof.json public.json
# 검증
snarkjs groth16 verify verification_key.json public.json proof.json
# Solidity 검증자 생성
snarkjs zkey export verifier circuit_final.zkey Verifier.sol

Pairing precompile을 사용하고 BN254 곡선 기본값을 활용할 수 있다. 다중 증명을 배치 검증할 때는 공통 부분을 재사용한다.

Trusted Setup는 MPC 의식으로 수행하고, ZK 키 관리와 토식 웨이스트 폐기 증빙을 보관한다. 최신 툴체인 호환성도 확인해야 한다.

BFV 정수 연산 예시

전제조건은 Python 3.10, Pyfhel==3.4.0, BFV 스킴, 정수 모듈러 연산이다.

pip install pyfhel==3.4.0

from Pyfhel import Pyfhel, PyCtxt

HE = Pyfhel()
HE.contextGen(scheme='BFV', n=16384, t_bits=20)  # t ~ 2^20, 정수 연산
HE.keyGen()

a, b = 1234, 5678
ca = HE.encryptInt(a)
cb = HE.encryptInt(b)

csum = ca + cb          # Enc(a+b)
cmul = ca * cb          # Enc(a*b)

print("Dec sum:", HE.decryptInt(csum))  # 6912
print("Dec mul:", HE.decryptInt(cmul))  # 7006652 (mod t 영역 내)

모듈러스 t에 따른 wrap-around를 고려해 정확한 정수 범위 안에서 파라미터를 선택해야 한다. 연산 깊이가 증가하면 재선형화나 부트스트래핑이 필요하며, 성능과 정확도 사이의 트레이드오프를 검토한다.

운영 설계에서 놓치기 쉬운 지점

SNARK 환경에서는 다자간 의식, 오프라인 보관, 감사 로그 유지가 필요하다. 회로가 바뀔 때 재설정을 줄일 수 있는 Universal Setup 구조를 선호할 수 있다. HE 개인키는 HSM/KMS에 보관하고, 키 로테이션·접근통제·데이터 보호 영향평가(DPIA)를 병행한다.

회로는 제약 부재, 오버플로우, 해시 선택 오류를 점검해야 한다. 프로빙 입력으로 위조 불가성을 테스트하고, Lookup 또는 Range Proof를 최적화할 때 부정확한 제약이 들어갈 위험을 관리한다.

온체인 비용 측면에서 SNARK는 검증 함수 인라인을 최소화하고 라이브러리를 재사용하며, 배치 검증과 집계 증명을 적용한다. STARK는 증명 압축, 리커시브 STARK, 데이터 가용성 전략(DA 레이어, 샘플링)을 검토한다.

zk-KYC는 속성증명 범위를 최소화하고 감사 권한을 가진 검증자를 지정할 수 있도록 설계한다. HE 데이터 처리 로그와 접근 이력을 보존하며 관할 규제(GDPR/개인정보보호법)를 준수한다.

단기에는 SNARK를 계속 활용하고, 장기적으로는 STARK와 격자 기반 전환을 준비한다. SNARK 내부에 STARK 또는 해시 기반 구성을 넣는 하이브리드 증명도 검토 대상이다. 증명 생성시간, 검증 실패율, 가스/건, 증명 크기, HE 노이즈 예산 소비율을 모니터링하고 SLO·에러 예산·알림 체계를 운영한다.