ZKP PRIVACY / VERIFICATION BBATON PROTOCOL

드러내지 않고, 필요한 사실만 증명합니다.

영지식증명(ZKP)은 개인정보 전체를 제출하는 대신, 서비스에 필요한 사실만 검증하는 방식입니다. BBATON은 이 원리를 익명 인증 구조에 적용해 성인 여부처럼 필요한 결과만 전달하는 방향을 설명합니다.

Prove what matters.
Reveal nothing else.

01 / ZKP의 핵심

왜 ZKP가 필요한가.

실서비스가 필요한 것은 대개 신원 전체가 아니라 특정 조건의 충족 여부입니다. ZKP는 ‘참/거짓’만 검증하고 나머지 데이터는 노출하지 않도록 설계된 증명 체계입니다.

01

완전성

Completeness

주장이 참이면 올바른 증명은 검증을 통과해야 합니다. 실제 서비스에서는 정당한 사용자가 필요한 조건을 안정적으로 입증할 수 있어야 한다는 의미입니다.

02

건전성

Soundness

주장이 거짓이면 임의의 조작이나 우회로 검증자를 속일 수 없어야 합니다. 운영 관점에서는 허위 인증이나 위조된 결과가 통과되지 않는다는 뜻입니다.

03

영지식성

Zero-Knowledge

검증자는 ‘주장이 참이다’라는 사실 외에 추가 정보를 얻지 못해야 합니다. 검증 과정에서 이름, 생년월일, 문서 원본 같은 불필요한 데이터가 새지 않는 구조입니다.

02 / 검증 구조

서비스 관점의 검증 구조.

운영 환경에서는 사용자의 비밀, 기기에서 생성된 증명, 검증 결과를 해석하는 서비스가 분리되어야 합니다. 핵심은 서비스가 원본 데이터 없이도 필요한 결과만 받을 수 있다는 점입니다.

STEP 01
SECRET
PROVER / 사용자 측

비밀은
사용자 측에 남습니다.

사용자의 생년월일, 문서 정보, 개인식별값은 사용자 기기 또는 사용자 제어 영역에 남아 있어야 합니다. 서비스는 원본 전체를 수집하지 않는 구조를 지향합니다.

예시 입력 birthdate = 1985-06-14
nationality = KOR
증명 생성
STEP 02
PROOF
PROOF / 증명

증명은
질의마다 생성됩니다.

서비스가 ‘성인인가’처럼 특정 조건을 묻으면, 기기는 해당 주장에 대한 증명을 로컬에서 계산합니다. 원본 문서나 상세 속성은 증명에 직접 포함되지 않습니다.

서비스가 요청한 주장 claim = age ≥ 19
proof = 0x8f3a...b2e1
검증
STEP 03
VERIFIER / 서비스

서비스는
결과만 확인합니다.

서비스는 증명이 유효한지와 정책에 필요한 결과만 확인합니다. 검증이 끝나도 사용자의 원본 정보는 알 수 없습니다.

결과 verify(proof) → true
knowledge leaked → none
BBATON / 적용 방향

원본은 사용자 기기에 두고, 서비스는 결과만 받습니다.

BBATON이 지향하는 구조는 원본 정보의 중앙 집중 보관이 아니라, 사용자 기기 내 보관과 결과 중심 검증입니다. 서비스는 질문을 보내고, 기기는 그 질문에 필요한 증명만 생성해 결과를 반환하는 방식으로 설계됩니다.

01 · ENROLL
DEVICE / 사용자 기기

등록하고,
기기 안에 보관.

최초 등록 시 필요한 문서 정보를 읽고, 사용자 기기에만 보관할 비밀 정보와 검증 재료를 생성합니다.

기기 내부에 생성 passport_data
biometric_template
secret_key (device-only)
기기 내부
02 · CUSTODY
ON-DEVICE
CUSTODY / 로컬 보관

서버 대신
기기가 보관.

원본 여권 이미지나 생년월일 전체를 중앙 서버나 블록체인에 올리지 않는 방향을 설명합니다. 운영 시스템은 필요한 최소 정보만 다룹니다.

외부로 전송되지 않는 것 여권 이미지, 생년월일, 이름
셀피, 얼굴 특징점
비밀키
요청 시
03 · PROVE
SERVICE QUERY TRUE ✓
PROVE / 결과 전달

요청이 오면,
주장만 증명.

서비스가 조건을 요청하면 사용자 기기가 로컬 정보로 증명을 만들고, 서버는 결과와 검증 가능한 증거만 받습니다. 원본 신원 정보는 전달되지 않습니다.

서비스가 받는 것 claim: age ≥ 19
result: true
leaked info: none
03 / 사용 예시

필요한 정보만 확인합니다.

서비스가 진짜로 필요한 것은 대개 신원 전체가 아니라 특정 조건의 충족 여부입니다. 편의점에서 성인 여부를 확인하는 장면은, 왜 ZKP가 실서비스에 필요한지 가장 직관적으로 보여줍니다.

BEFORE / 기존 방식

신분증 전체를 보여준다.

점원에게 전달된 것
NAME
김민수
ID NO.
950614-1******
ADDRESS
서울시 강남구 테헤란로···
노출: 이름, 주민번호, 주소, 사진, 발급일

필요한 것은 성인 여부 하나인데, 실제로는 불필요한 개인정보가 함께 노출됩니다. 수집 목적과 노출 정보의 범위가 맞지 않는 구조입니다.

AFTER / ZKP 방식

성인 여부만 확인한다.

점원에게 전달된 것
CLAIM
만 19세 이상
♦ VERIFIED
비공개: 이름, 주민번호, 주소, 생년월일

서비스는 정책에 필요한 결과만 확인하고, 이름·주소·생년월일 같은 원본은 알지 못합니다. 검증 목적과 수집 정보가 일치하는 구조입니다.

04 / BBATON 방향

현재 운영과 다음 단계.

BBATON은 현재도 최소 정보 원칙에 맞춰 검증 구조를 설계하고 있습니다. 앞으로는 검증 시점에도 원본 속성 노출을 더 줄이는 방향으로 구조를 확장할 수 있습니다.

PHASE / 현재 운영

해시 기반
최소 정보 검증.

속성값 + salt
keccak256 해시
Base L2 온체인 기록
  • 원본 정보 온체인 미기록
  • 무결성 점검 가능
  • 검증 시 속성 확인 단계 존재
  • 서비스 정책에 따라 추가 조회가 필요할 수 있음
NEXT / 확장 방향

ZKP 기반
결과 중심 검증.

속성값 (사용자 기기 내)
zk-SNARK 증명 생성
증명만 전송 / 원본 미전송
  • 원본 정보 직접 미전송
  • 검증자는 참/거짓 중심으로 판단
  • 서비스 노출 정보 최소화
  • 적용 범위 확대 검토

개발가이드에서
구현 흐름을 확인하세요.

개발자 가이드