trusted setup은 일부 영지식 증명과 다항식 커밋먼트가 사용할 공통 참조 문자열을 만드는 절차다. 생성 과정의 비밀 엔트로피가 남으면 거짓 증명 위험이 생길 수 있어 다자간 ceremony는 참여자 중 최소 한 명이 자신의 비밀을 안전하게 폐기했다는 가정으로 위험을 분산한다. 투명한 설정은 이 가정을 줄이지만 증명 크기와 계산 비용 같은 다른 절충이 있다.
CRS가 필요한 이유와 위험
비대화형 영지식 증명은 증명자와 검증자가 공통으로 쓰는 공개 매개변수를 필요로 할 수 있다. 이 묶음을 common reference string, CRS라고 부른다. 특정 방식에서는 CRS 생성에 사용한 비밀값을 아는 사람이 건전성을 깨는 증명을 만들 가능성이 있으므로 생성 뒤 비밀을 폐기하는 절차가 보안 가정에 들어간다.
trusted라는 말은 운영자가 항상 정직하다는 보증이 아니다. 어떤 비밀이 생성되고, 누가 기여하며, 어느 조건에서 위조가 가능해지는지를 명시한 위협 모델이다. 프로젝트 설명에서 'ZK'라는 단어만 확인하고 신뢰 가정이 없다고 결론 내리면 안 된다.
설정의 투명성은 믿음의 유무가 아니라 어디에 어떤 가정을 두는지 드러내는 문제다.
JOBCOIN 해설
다자간 ceremony가 위험을 줄이는 방식
다자간 계산에서는 각 참여자가 이전 결과에 자신의 무작위 비밀을 섞고 다음 결과를 공개한다. 설계가 올바르고 최소 한 참여자가 자신의 비밀을 복구할 수 없게 폐기하면 다른 참가자가 공모해도 최종 비밀 전체를 알 수 없다는 가정을 쓴다. 참여자 수가 많다는 사실보다 각 기여의 검증 가능성과 최종 transcript가 중요하다.
Ethereum KZG ceremony는 EIP-4844에 쓰일 structured reference string을 만들었고 공식 결산은 141,416개 기여와 transcript 검증 자료를 기록했다. 이 사례는 KZG 커밋먼트용 설정이며 모든 ZK 롤업이 같은 transcript를 사용하거나 같은 보안 조건을 가진다는 뜻은 아니다.
회로별 설정과 범용 설정, 투명한 설정
일부 시스템은 회로가 바뀔 때 새 설정이 필요하고, 범용·업데이트 가능한 설정은 한 번 만든 매개변수를 여러 회로나 후속 기여에 활용한다. STARK 계열처럼 공개 검증 가능한 randomness에 의존해 trusted setup을 요구하지 않는 방식도 있다. 하지만 투명하다는 이유만으로 모든 성능과 구현 위험이 사라지지는 않는다.
| 방식 | 주요 신뢰 가정 | 확인할 증거 |
|---|---|---|
| 회로별 trusted setup | 해당 회로 ceremony의 비밀 폐기 | 회로 결속과 transcript |
| 범용·업데이트 가능 setup | 최소 한 유효 기여의 비밀 폐기 | 초기·후속 기여 검증 |
| 투명한 setup | 공개 randomness와 해시 가정 | randomness 출처와 사양 |
| KZG SRS | 설정 비밀을 아무도 완전히 알지 못함 | SRS 버전과 transcript 해시 |
프로젝트 문서에서 확인할 질문
증명 시스템 이름, 곡선과 커밋먼트, setup 범위, transcript 위치, 검증 도구, 회로 또는 프로그램 버전을 먼저 찾는다. 'ceremony 완료'라는 홍보 문구만 있고 최종 산출물 해시나 재현 가능한 검증 절차가 없다면 독립 확인 범위가 제한된다. 감사 보고서가 어떤 commit과 파일을 검토했는지도 본다.
가정 예시로 범용 SRS를 사용하더라도 애플리케이션 회로 컴파일 단계에서 별도 키를 파생할 수 있다. 이때 범용 ceremony의 안전성과 회로 제약식이 의도한 계산을 표현하는지는 서로 다른 질문이다. 아래 절차는 교육 목적이며 특정 프로젝트의 안전성을 보증하지 않는다.
- 증명 시스템과 commitment scheme의 정확한 이름을 확인한다
- setup이 회로별인지 범용인지 문서에서 구분한다
- 최종 transcript 해시와 검증 명령을 찾는다
- 감사 대상 commit과 현재 배포 버전을 대조한다
- 비상 업그레이드 키와 증명 검증 계약 권한을 별도로 확인한다
ceremony가 해결하지 않는 것
정상적인 CRS가 있어도 회로가 잘못 작성되면 허용하지 말아야 할 상태를 유효하다고 증명할 수 있다. verifier 계약 구현, 입력 공개 방식, 데이터 가용성, 시퀀서 검열과 업그레이드 권한도 독립된 위험이다. trusted setup 검증을 전체 시스템 감사로 확대 해석하지 않는다.
반대로 setup이 필요한 시스템을 곧바로 중앙집중적이라고 단정하는 것도 부정확하다. 다자간 기여와 공개 transcript는 단일 운영자 의존을 줄이기 위한 장치다. 비교할 때는 증명 크기, 검증 비용, 양자 내성 가정, 구현 성숙도까지 같은 표에 놓는다.
보도와 발표를 검증하는 방법
'신뢰 없는 ZK'라는 표현을 보면 setup이 없다는 뜻인지, 다자간 ceremony로 신뢰를 분산했다는 뜻인지 원문을 확인한다. 참가자 수는 절차 규모를 보여 주지만 각 클라이언트의 정확성, 기여 포함 여부, 최종 SRS 사용 여부까지 자동 증명하지 않는다.
검증 기록에는 공식 사양 URL, transcript 해시, 조회 날짜, 사용한 검증기 버전과 결과를 남긴다. 실시간 배포 상태나 미공개 키 관리를 확인하지 않았다면 현재 안전하다고 단정하지 않는다. 암호 설계의 신뢰 가정은 투자 수익이나 토큰 가격 전망과 별개다.
자주 묻는 질문
trusted setup이 있으면 한 기관을 믿어야 하나요?
반드시 그렇지 않다. 다자간 ceremony는 최소 한 참여자가 비밀을 폐기했다는 조건으로 단일 참여자 의존을 줄일 수 있다.
STARK는 아무 신뢰 가정도 없나요?
trusted setup 가정은 줄지만 해시 함수, 구현, 공개 randomness, 회로 정확성 같은 다른 가정은 남는다.
참여자가 많으면 안전이 증명되나요?
참여자 수만으로 충분하지 않다. 기여 검증, 최종 transcript, SRS 버전, 실제 배포가 그 산출물을 쓰는지 확인해야 한다.
