ERC-7812 ZK 신원 레지스트리 (ZK Identity Registry)

Review · 서명·인증 · 2024-11-08 작성

비밀 데이터에 대한 커밋먼트를 고정 주소의 단일 온체인 레지스트리에 저장해 두고 나중에 데이터를 공개하지 않고도 영지식 증명으로 그 유효성과 진위를 입증할 수 있게 합니다.

왜 필요한가

영지식 증명을 쓰는 프라이버시 프로토콜은 많지만 증명 가능한 진술(statement)을 어디에 어떻게 저장할지는 제각각이었습니다. 프로토콜마다 자체 저장소를 만들면 한 곳에서 만든 진술을 다른 프로토콜이 다시 쓰기 어렵고 다른 체인으로 옮기기도 번거롭습니다. 원문은 이런 저장과 발급을 한곳에 모아 정리할 필요에서 이 제안이 나왔다고 밝힙니다. 증명 가능한 진술을 표준화된 단일 레지스트리에 모으면 재사용성, 이식성, 보안이 크게 좋아지고 앞으로 나올 프로토콜들이 이 레지스트리에 연결해 서로의 데이터를 활용할 수 있습니다. 또 레지스트리를 일부러 추상적으로 정의해 두어 신원 기반, 평판 기반, 참석 증명 기반 등 다양한 프로토콜을 거의 제약 없이 구현할 수 있습니다. 구체적인 진술과 커밋먼트 구조는 별도 EIP로 나오도록 기반만 깔아 두는 제안입니다.

구현해야 하는 것

심층 설명

세 가지 구성 요소: EvidenceRegistry, EvidenceDB, Registrar

이 시스템은 EvidenceRegistry와 EvidenceDB, 그리고 Registrar로 이루어집니다. EvidenceRegistry는 프로토콜 전체가 공유하는 증명 가능 데이터베이스 EvidenceDB의 진입점이며, 임의의 32바이트 데이터를 기록하고 나중에 증명할 수 있습니다. Registrar는 신원, 평판, 참석 증명 같은 구체적인 사업 용도를 구현하는 주체로, 데이터를 구조화해 EvidenceRegistry를 통해 EvidenceDB에 넣습니다. 이 EIP는 앞의 두 요소만 표준화하고 Registrar 명세는 별도 제안으로 다룹니다. 데이터의 포함이나 배제는 머클 증명으로 입증하며, Registrar가 데이터를 어떻게 넣었는지 알면 Circom 등 어떤 스택으로든 온체인 ZK 검증기를 구현할 수 있습니다.

EvidenceDB의 요구 사항

EvidenceDB는 임의의 증명 가능한 키/값 자료구조를 쓸 수 있지만 원소의 추가(addition), 갱신(update), 제거(removal)를 반드시 지원해야 합니다. 모든 쓰기 연산은 멱등성을 유지해야 하며 추가 후 제거하면 데이터베이스 상태가 바뀌지 않아야 합니다. 선택한 자료구조는 원소의 포함 증명과 배제 증명을 모두 제공할 수 있어야 하고 상태를 바꾸는 함수는 EvidenceRegistry만 호출할 수 있어야 합니다. 참조 인터페이스는 스파스 머클 트리 기반으로, 루트와 형제 해시 배열, 존재 여부, 보조 노드(auxKey, auxValue, auxExistence) 정보를 담는 Proof 구조체를 정의합니다.

호출자별 키 격리

addStatement, removeStatement, updateStatement는 진술 키를 반드시 격리해 호출자마다 전용 네임스페이스를 할당해야 합니다. 격리 방식은 isolatedKey = hash(msg.sender, key)로, 추가하려는 격리 키가 이미 존재하거나 제거·갱신하려는 격리 키가 존재하지 않으면 반드시 되돌려야 합니다. 이 네임스페이스 분리는 데이터베이스 셀에 대한 쓰기 권한을 나누어 발급자 외에는 누구도 그 내용을 바꿀 수 없게 하기 위한 선택입니다. 다만 이 결정은 접근 제어 관리 책임을 전적으로 레지스트라에 맡기므로, 레지스트라 개발 시 중요하게 고려해야 할 부분입니다.

루트 이력 관리와 getRootTimestamp

EvidenceRegistry는 EvidenceDB 루트의 선형 이력을 반드시 유지해야 합니다. getRootTimestamp는 절대 되돌리지 않아야 하며 조회한 루트가 존재하지 않으면 0을, 최신 루트를 조회하면 block.timestamp를 반환해야 합니다. 온체인에는 가스 비용을 고려해 최소한의 루트 이력만 유지하며 더 자세한 이력이 필요하면 RootUpdated 이벤트를 파싱하는 오프체인 서비스를 구현하는 것이 권장됩니다.

해시 함수와 프라임 필드 제한

EvidenceRegistry와 EvidenceDB는 반드시 같은 보안 해시 함수를 써야 하며 데이터베이스 증명을 쉽게 하려면 poseidon 같은 ZK 친화 해시 함수가 권장됩니다. ZK 친화 해시를 쓰는 경우 EvidenceRegistry는 기반 타원곡선의 프라임 필드 크기(BN128 기준 21888242871839275222246405745257275088548364400416034343698204186575808495617)를 넘는 키나 값을 받아들이지 않아야 합니다. 참조 구현은 Poseidon 해시를 쓰고 이 범위를 검사하는 onlyInPrimeField 검증을 둡니다.

싱글톤 설계와 결정적 배포

명세 과정에서 프로토콜마다 레지스트리를 두는 방식과 모든 프로토콜이 싱글톤 레지스트리를 공유하는 방식을 비교했고 후자를 택했습니다. SMT 루트인 bytes32 값 하나만 체인 간에 보내면 레지스트리 상태를 증명할 수 있는 크로스체인 이식성, 사용자가 허가가 필요 없는 불변 컨트랙트 하나만 신뢰하면 되는 신뢰 집중, 그리고 인터페이스와 해시 함수, 증명 구조를 공식화해 통합을 단순하게 하는 점, 이 세 가지가 근거입니다. EvidenceRegistry는 0x4e59b44847b379578588920ca78fbf26c0b4956c의 결정적 배포 프록시와 솔트 0x04834e077c463de76a20df3770a7b96a5e5eb826922d1514f943cd5b41ccaed0으로 0x781246D2256dc0C1d8357c9dDc1eEe926a9c7812에 배포됩니다.

참조 구현과 후속 표준

참조 구현으로 EvidenceRegistry와 EvidenceDB 솔리디티 컨트랙트, 그리고 레지스트리 상태를 검증하는 Circom 회로가 제공됩니다. SMT 높이는 80으로 설정되며 회로는 루트를 공개 입력으로 받고 주소와 키로 격리 키를 다시 계산해 포함 또는 배제 증명을 검사합니다. 구현은 @openzeppelin/contracts v5.1.0과 circomlib v2.0.5에 의존합니다. 이 제안 위에서 국가 여권의 온체인 기록용 레지스트라, EIP-4337 기밀 계정 신원 관리 레지스트라, POAP용 레지스트라처럼 커밋먼트 생성과 커밋먼트 키 관리, 진술 증명 절차를 구체화한 후속 EIP들이 나올 것으로 기대됩니다.

제안 상태: Review

이 제안은 아직 검토(Review) 단계입니다. 내용이 바뀔 수 있는 제안이므로 구현 전에 최신 원문을 확인해야 합니다.

쓸 때 주의할 점

ERC 원문 · ← ERCs