세리머니의 안전성은 참여자가 많다는 사실만으로 정해지지 않습니다. 각 기여가 앞선 결과에 새 비밀값을 섞은 뒤 그 비밀을 버렸고, 적어도 한 명은 실제로 지웠다는 1-of-N 가정이 핵심입니다. 공시에서는 프로토콜·곡선·구조화 참조 문자열(SRS) 크기, 순서 관리자(sequencer)의 역할, 공개된 기록(transcript)의 해시와 독립 검증기, 그리고 최종 산출물이 실제 클라이언트에 들어간 해시까지 확인해야 합니다.
신뢰 설정은 무엇을 믿는가
KZG 같은 다항식 커밋먼트는 공개된 SRS를 쓰지만, 생성 과정의 비밀값 tau를 누군가 알고 있다면 거짓 증명을 만들 위험이 있습니다. 다자 세리머니는 앞 사람의 결과에 다음 참여자가 자기 난수를 섞는 과정을 되풀이합니다. 최종 비밀은 각 기여의 곱과 이어져 있으므로, 참여자 한 명이라도 자기 비밀을 공개하지 않고 버리면 전체 뒷문(trapdoor)을 다시 만들기 어렵다는 가정에 기대고 있습니다.
Ethereum KZG FAQ는 이를 1-of-N 신뢰 가정으로 설명하며, 모든 참여자가 비밀을 빼내고 서로 공모해야 안전이 깨진다고 적습니다. 다만 공통 구현의 버그가 난수를 흘리는 실패 유형은 별개입니다. 사람 수와 함께 소프트웨어·하드웨어의 다양성을 공시해야 하는 이유입니다.
세리머니의 숫자는 안전성을 짐작하게 하는 지표일 뿐, 적어도 하나의 독립된 비밀이 실제로 버려졌다는 가정을 대신하지 못합니다.
JOBCOIN 해설
그림은 이 주제의 공통 개념을 단순화한 설명입니다. 아래 항목에서 이 글의 구체적인 조건과 예외를 함께 읽어보세요.
- 신뢰 설정은 무엇을 믿는가
KZG 같은 다항식 커밋먼트는 공개된 SRS를 쓰지만, 생성 과정의 비밀값 tau를 누군가 알고 있다면 거짓 증명을 만들 위험이 있습니다.
- 참여자 수를 고유한 사람 수로 읽지 않습니다
Ethereum Foundation의 KZG 마무리 공지는 기록과 검증 도구를 공개하면서, 기여 목록을 에어드롭용 고유 신원 목록으로 쓰지 말라고 경고했습니다.
- 순서 관리자를 믿지 않아도 된다는 말의 범위를 봅니다
순서 관리자는 대기열을 관리하고, 직전 Powers of Tau를 참여자에게 보내며, 새 기여를 검증해 다음 사람에게 넘깁니다.
설명을 위한 개념도 · 실제 가격·거래 내역·통계가 아닙니다.
참여자 수를 고유한 사람 수로 읽지 않습니다
Ethereum Foundation의 KZG 마무리 공지는 기록과 검증 도구를 공개하면서, 기여 목록을 에어드롭용 고유 신원 목록으로 쓰지 말라고 경고했습니다. 여러 주소가 한 주체와 연결된 흔적이 있더라도, 무작위성을 더한 것 자체는 최종 산출물의 건전성을 해치지 않는다고 구분했습니다.
그래서 ‘14만 명 참여’ 같은 제목이 다중 계정(Sybil) 저항과 암호학적 건전성을 한꺼번에 증명하지는 않습니다. 참여 인증 방식, 요청 횟수 제한, 특별 기여, 서로 다른 클라이언트 구현과 난수 출처를 따로 봅니다. 한 운영자가 여러 번 기여했다는 사실만으로 기록이 무효가 되지는 않지만, 독립적으로 비밀을 버렸다는 가정의 강도를 부풀려서도 안 됩니다.
| 항목 | 확인 증거 | 판단 범위 |
|---|---|---|
| 프로토콜 | 곡선·SRS 차수·명세 | 어떤 증명에 쓰이는가 |
| 기여 | 증거값·서명·순서 | 변환 계산의 유효성 |
| 기록 | SHA-256·CID·사본 | 같은 산출물 확보 |
| 검증기 | 독립 구현·재현 로그 | 전체 기여의 연결 검증 |
| 배포 | 클라이언트 안의 SRS 해시 | 실제로 쓰이는 산출물 |
순서 관리자를 믿지 않아도 된다는 말의 범위를 봅니다
순서 관리자는 대기열을 관리하고, 직전 Powers of Tau를 참여자에게 보내며, 새 기여를 검증해 다음 사람에게 넘깁니다. Ethereum FAQ는 공개 기록으로 모든 난수 기여를 검증할 수 있으므로, 순서 관리자가 최종 출력을 치우치게 하거나 잘못 만들지 않았는지 독립적으로 확인할 수 있다고 설명합니다.
그러나 순서 관리자에 장애가 나면 가용성과 포함 여부에 영향이 갈 수 있습니다. 제출에 성공했다는 화면과 최종 기록에 포함된 것은 다르므로 참여자는 자기 신원과 증거값이 최종 파일에 있는지 확인해야 합니다. 검증할 수 있는 조정자와 멈추지 않는 조정자를 같은 성질로 표현하지 않습니다.
최종 기록을 실제로 다시 검증합니다
마무리 공지는 최종 기록의 SHA-256과 IPFS CID, GitHub 사본을 제시했습니다. 검토자는 서로 다른 사본에서 파일을 받아 해시를 맞춰 보고, 전용 검증기로 각 기여의 페어링 관계와 최종 거듭제곱 구조를 검사합니다. 내려받기에 성공했다거나 JSON 해석에 성공했다는 것은 암호학적 검증이 아닙니다.
검증 로그에는 검증기 저장소와 커밋, 빌드 환경, 기록 해시와 결과를 남깁니다. Ethereum 저장소에는 기록과 보안 평가 보고서가 함께 공개돼 있습니다. 감사가 있었다는 사실만 인용하지 말고, 어떤 구성 요소와 위협이 범위였는지 보고서에서 확인합니다.
- 공식 명세의 곡선과 SRS 규모를 기록합니다
- 기록의 SHA-256과 CID를 두 출처에서 맞춰 봅니다
- 독립 검증기의 커밋과 실행 결과를 보존합니다
- 자기 기여와 증거값이 포함됐는지 확인합니다
- 배포 클라이언트가 같은 SRS를 읽는지 해시로 연결합니다
비밀 폐기 증명에는 한계가 있습니다
올바른 기여 증명은 참여자가 앞선 결과를 일관되게 변환했다는 것을 보여 줄 수 있지만, 비밀의 모든 사본을 지웠다는 물리적 사실까지 증명하지는 못합니다. 그래서 서로 독립된 여러 참여자와 다양한 구현을 모읍니다. 난수를 만드는 장면을 공개적으로 연출하는 것은 추가 신뢰 신호가 될 수는 있어도 기록 검증을 대신하지 않습니다.
모든 참여자가 공모하거나 공통 버그로 비밀이 새면 뒷문 위험은 남습니다. 공시는 이런 실패가 허용할 공격, 예를 들어 블롭 데이터에 대한 거짓 주장을 만들 가능성을 구체적으로 적어야 합니다. ‘군사급 보안’ 같은 꾸밈말 대신, 설정이 깨졌을 때 어떤 검증자를 속일 수 있는지 적습니다.
세리머니 완료와 프로토콜 적용을 나눕니다
최종 기록이 검증됐더라도 네트워크 업그레이드가 그 SRS를 실제로 쓰기 전까지는 기능이 켜진 것이 아닙니다. 명세의 상수, 클라이언트 저장소에 들어간 신뢰 설정 파일, 릴리스와 활성화 포크를 서로 연결합니다. 테스트넷 산출물과 실운영 산출물을 헷갈리지 않습니다.
이후 프로토콜이 더 큰 SRS나 다른 곡선을 요구하면, 기존 세리머니 결과를 그대로 다시 쓸 수 있는지 새 명세에서 확인해야 합니다. ‘세리머니 완료’라는 과거 공지를 미래 증명 시스템 전체에 대한 영구 보증으로 넓히지 않습니다. 적용 범위와 버전을 공시 첫 화면에 둡니다.
자주 묻는 질문
참여자가 많으면 무조건 안전한가요?
아닙니다. 적어도 한 참여자가 독립적으로 비밀을 버렸다는 가정과, 기여 계산과 기록을 검증할 수 있다는 점이 함께 필요합니다.
transcript hash가 맞으면 cryptographic 검증도 끝난 건가요?
해시는 같은 파일인지 확인해 줄 뿐입니다. 각 기여와 거듭제곱 관계는 검증기로 따로 검사해야 합니다.
참여 증명 NFT가 고유 사람 수를 보여 주나요?
그렇지 않습니다. 공식 KZG 공지도 기여 목록을 강한 다중 계정 방지용 신원 자료로 쓰지 말라고 설명합니다.
더 깊이 읽기
본문에서 다룬 개념과 확인 절차를 다음 글에서 이어서 살펴보세요.
