세리머니의 안전성은 참여자 수가 많다는 사실만으로 결정되지 않는다. 각 기여가 이전 결과에 새 비밀값을 섞고 그 비밀을 폐기했으며, 최소 한 명이 이를 실제로 지웠다는 1-of-N 가정이 핵심이다. 공시에서는 protocol·curve·SRS 크기, sequencer 역할, 공개 transcript의 hash와 독립 verifier, 최종 산출물이 실제 client에 포함된 hash까지 확인해야 한다.
trusted setup은 무엇을 신뢰하는가
KZG 같은 polynomial commitment는 공개된 SRS를 사용하지만 생성 과정의 비밀값 tau를 누군가 알면 허위 opening을 만들 위험이 있다. 다자 세리머니는 첫 기여의 결과에 다음 참여자가 자기 randomness를 섞는 과정을 반복한다. 최종 비밀은 각 기여의 곱과 연결되므로 한 참여자라도 자기 secret을 공개하지 않고 폐기하면 전체 trapdoor를 재구성하기 어렵다는 가정에 기대고 있다.
Ethereum KZG FAQ는 이를 1-of-N trust assumption으로 설명하며, 모든 참여자가 secret을 추출하고 서로 공모해야 안전이 깨진다고 적는다. 다만 공통 구현 bug가 randomness를 누출하는 실패 모드는 별개다. 사람 수와 software·hardware 다양성을 함께 공시해야 하는 이유다.
세리머니의 숫자는 안전성의 대리 지표일 뿐, 최소 한 독립 비밀이 실제로 폐기됐다는 가정을 대신하지 못한다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- trusted setup은 무엇을 신뢰하는가
KZG 같은 polynomial commitment는 공개된 SRS를 사용하지만 생성 과정의 비밀값 tau를 누군가 알면 허위 opening을 만들 위험이 있다.
- 참여자 수를 고유 신원 수로 읽지 않는다
Ethereum Foundation의 KZG 마무리 공지는 transcript와 검증 도구를 공개하면서 contribution 목록을 airdrop용 고유 신원 목록으로 쓰지 말라고 경고했다.
- sequencer를 신뢰하지 않아도 된다는 말의 범위를 본다
sequencer는 대기열을 관리하고 이전 Powers of Tau를 참여자에게 보내며 새 contribution을 검증해 다음 사람에게 넘긴다.
AI로 제작한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
참여자 수를 고유 신원 수로 읽지 않는다
Ethereum Foundation의 KZG 마무리 공지는 transcript와 검증 도구를 공개하면서 contribution 목록을 airdrop용 고유 신원 목록으로 쓰지 말라고 경고했다. 여러 address가 한 주체와 연결된 흔적이 있어도 entropy 추가 자체는 최종 산출물의 건전성을 해치지 않는다고 구분했다.
따라서 ‘14만 명 참여’ 같은 headline은 Sybil 저항과 cryptographic soundness를 동시에 증명하지 않는다. 참여 인증 방식, rate limit, special contribution, 서로 다른 client 구현과 randomness source를 따로 본다. 동일 운영자가 여러 기여를 했어도 그 사실만으로 transcript가 무효가 되지는 않지만 독립 폐기 가정의 강도를 과장해서도 안 된다.
| 항목 | 확인 증거 | 판단 범위 |
|---|---|---|
| Protocol | curve·SRS 차수·spec | 어떤 proof에 쓰이는가 |
| Contribution | witness·서명·순서 | 전환 계산의 유효성 |
| Transcript | SHA-256·CID·mirror | 동일 산출물 확보 |
| Verifier | 독립 구현·재현 log | 전체 기여 연결 검증 |
| Deployment | client 내 SRS hash | 실제 적용 산출물 |
sequencer를 신뢰하지 않아도 된다는 말의 범위를 본다
sequencer는 대기열을 관리하고 이전 Powers of Tau를 참여자에게 보내며 새 contribution을 검증해 다음 사람에게 넘긴다. Ethereum FAQ는 공개 transcript가 모든 randomness contribution을 검증 가능하게 하므로 sequencer가 편향되거나 잘못된 최종 출력을 만들지 않았는지 독립 확인할 수 있다고 설명한다.
그러나 sequencer 장애는 availability와 inclusion에 영향을 줄 수 있다. 제출이 성공했다는 UI와 최종 transcript 포함은 다르므로 참여자는 자기 identity·witness가 최종 파일에 있는지 확인해야 한다. 검증 가능한 coordinator와 무중단 coordinator를 같은 속성으로 표현하지 않는다.
최종 transcript를 실제로 재검증한다
마무리 공지는 최종 transcript의 SHA-256과 IPFS CID, GitHub 사본을 제시했다. 검토자는 서로 다른 mirror에서 파일을 받아 hash를 대조하고 전용 verifier로 각 contribution의 pairing relation과 최종 Powers 구조를 검사한다. 단순 다운로드 성공이나 JSON parse 성공은 cryptographic verification이 아니다.
검증 log에는 verifier repository·commit, build 환경, transcript hash와 결과를 남긴다. Ethereum repository에는 transcript와 security assessment가 함께 공개돼 있다. audit가 있다는 사실만 인용하지 말고 어떤 component와 threat가 범위였는지 보고서에서 확인한다.
- 공식 spec의 curve·SRS 규모를 기록한다
- transcript SHA-256과 CID를 두 출처에서 대조한다
- 독립 verifier의 commit과 실행 결과를 보존한다
- 자기 contribution과 witness 포함 여부를 확인한다
- 배포 client가 같은 SRS를 읽는지 hash로 연결한다
비밀 폐기 증명에는 한계가 있다
올바른 contribution proof는 참여자가 이전 결과를 일관되게 변환했음을 보일 수 있지만 secret의 모든 복사본을 삭제했다는 물리적 사실까지 증명하지는 못한다. 그래서 서로 독립적인 여러 참여자와 다양한 구현을 모집한다. 공개적으로 randomness 생성 장면을 연출하는 것은 추가 신뢰 신호일 수 있어도 transcript 검증을 대체하지 않는다.
모든 참여자가 공모하거나 공통 bug로 secret이 새면 trapdoor 위험이 남는다. 공시는 이 실패가 허용할 공격, 예를 들어 blob data에 대한 거짓 claim 생성 가능성을 구체적으로 적어야 한다. ‘군사급 보안’ 같은 형용사 대신 broken setup이 어떤 verifier를 속일 수 있는지 기술한다.
세리머니 완료와 프로토콜 적용을 분리한다
최종 transcript가 검증돼도 network upgrade가 그 SRS를 실제로 사용하기 전에는 기능이 활성화된 것이 아니다. specification constant, client repository에 포함된 trusted setup file, release와 activation fork를 연결한다. testnet 산출물과 production 산출물을 혼동하지 않는다.
후속 protocol이 더 큰 SRS나 다른 curve를 요구하면 기존 세리머니 결과를 그대로 재사용할 수 있는지 새 spec에서 확인해야 한다. ceremony complete라는 과거 공지를 미래 proof system 전체의 영구 보증으로 확대하지 않는다. 적용 범위와 version을 공시 첫 화면에 둔다.
자주 묻는 질문
참여자가 많으면 무조건 안전한가요?
아니다. 최소 한 참여자의 독립 secret 폐기 가정과 기여 계산·transcript의 검증 가능성이 함께 필요하다.
transcript hash가 맞으면 cryptographic 검증도 끝난 건가요?
hash는 같은 파일인지 확인한다. 각 contribution과 Powers 관계는 verifier로 별도 검사해야 한다.
참여 증명 NFT가 고유 사람 수를 보여 주나요?
그렇지 않다. 공식 KZG 공지도 contribution 목록을 강한 anti-Sybil 신원 자료로 쓰지 말라고 설명한다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
