모든 글

읽는 데 10분

존재 증명이란 무엇입니까?

존재 증명은 정확한 데이터가 공개 타임스탬프보다 늦지 않은 시점에 존재했음을, 비공개 파일 자체를 공개하지 않고 보여 줍니다. 그 작동 방식과, 무엇을 증명하고 무엇을 증명하지 않는지 살펴봅니다.

존재 증명은 누구나 확인할 수 있는 공개 타임스탬프를 사용해, 정확한 데이터가 특정 시점보다 늦지 않게 존재했음을 보여 주는 방법입니다.

방법은 간단합니다. 데이터를 해시하고, 그 해시를 공개된 타임스탬프 레코드에 게시합니다. 이후 원본 데이터를 가진 사람이라면 누구나 해시를 다시 계산해 레코드와 대조할 수 있습니다. 두 해시가 일치하면 검증하는 측은 동일한 바이트가 그 레코드 시점보다 늦지 않게 존재했음을 알게 됩니다. 사용자나 서버, 계정을 신뢰할 필요가 없습니다. 공개 레코드와 수학만 있으면 됩니다.

파일 자체를 공개할 필요는 전혀 없습니다. 콘텐츠는 비공개로 유지하면서도 증명은 공개할 수 있습니다.

존재 증명은 무엇을 증명합니까?

존재 증명은 좁지만 유용한 하나의 주장을 증명합니다.

바로 이 바이트가 이 공개 시점보다 늦지 않게 존재했다.

기본 증명이 단언하는 것은 이것이 전부이며, 그 힘은 얼마나 구체적인가에서 나옵니다.

거의 모든 것은 암호학적 해시로 환원할 수 있습니다. 문서, 이미지, 동영상, 데이터셋, 소스 코드 아카이브, 빌드 산출물, 계약서, 로그 파일, 모델 출력, 매니페스트가 모두 그렇습니다. 해시는 정확히 하나의 바이트 시퀀스를 나타내는 짧은 지문입니다. 단 한 바이트만 바뀌어도 지문은 완전히 달라집니다.

그 해시가 공개 레코드에 고정되면, 그 레코드는 시간의 증인이 됩니다. 이후 누군가에게 원본 파일을 보여 주면 그 사람은 파일을 다시 해시합니다. 새 해시가 기록된 해시와 일치하면, 눈앞의 파일이 이전에 커밋된 바로 그 데이터, 즉 레코드의 타임스탬프 시점 또는 그 이전에 커밋된 데이터와 동일함을 확인할 수 있습니다.

이 때문에 존재 증명은 시점이 중요한 모든 상황에서 가치를 가집니다.

  • 분쟁이 발생하기 전에 파일이 존재했음을 보여 줄 때;
  • 감사 마감 전에 보고서가 존재했음을 보여 줄 때;
  • 릴리스 시점에 소프트웨어 산출물이 존재했음을 보여 줄 때;
  • 수정되기 전에 데이터셋 스냅샷이 존재했음을 보여 줄 때;
  • 이의가 제기되기 전에 AI 출력, 프롬프트 세트, 미디어 파일이 존재했음을 보여 줄 때.

증명은 파일에 대한 설명이 아닙니다. 그것은 파일의 정확한 바이트에 대한 암호학적 커밋입니다.

파일을 공개할 필요가 없는 이유는 무엇입니까?

공개되는 주장이 파일이 아니라 해시이기 때문입니다.

좋은 해시 함수는 단방향 지문처럼 작동합니다. 누구나 파일로부터 해시를 계산할 수 있지만, 해시만 본 사람은 그것으로 파일을 복원할 수 없습니다. 비공개 문서가 공개 증명을 담을 수 있는 이유가 바로 여기에 있습니다. 레코드는 바이트를 드러내지 않고 "누군가가 이 시점에 바로 이 바이트에 커밋했다"라고 말합니다.

예를 들어 어떤 회사는 기밀 데이터셋 매니페스트를 해시하고 해시만 게시할 수 있습니다. 데이터셋은 비공개로 유지됩니다. 이후 스냅샷에 무엇이 들어 있었는지 증명해야 한다면, 전체 매니페스트, 그 일부, 또는 단일 항목의 포함 증명 가운데 상황에 맞는 것을 공개하면 됩니다.

이것이 존재 증명이 법무·컴플라이언스·보안 팀에 잘 맞는 이유이기도 합니다. 비공개 증거를 공개 데이터베이스에 올리지 않고도 외부 타임스탬프를 만들어 내기 때문입니다. 이 패턴을 더 자세히 살펴보려면 공개 파일 없이 이루어지는 기밀 공개를 참고하십시오.

블록체인은 어떤 역할을 합니까?

블록체인은 공개된 시간의 증인입니다. 게시자를 포함한 누구도 조용히 다시 쓸 수 없는 부분입니다.

해시가 자신의 데이터베이스에만 존재한다면, 증명은 전적으로 자신의 시스템에 의존합니다. 이후 타임스탬프에 의문이 제기되면, 누군가는 데이터베이스가 다시 작성되었는지, 백업에서 복원되었는지, 관리자가 편집했는지, 날짜를 소급해 기입했는지 합리적으로 물을 수 있습니다. 공개 블록체인은 그 의심을 없앱니다. 트랜잭션이 확인되고 나면 타임스탬프가 찍힌 레코드는 누구에게나 보이며, 더 이상 게시자 혼자만의 통제 아래 있지 않습니다.

CardanoWall에서 증명 레코드는 메타데이터 레이블 309 아래 Cardano 트랜잭션 메타데이터에 고정됩니다. 검증하는 측은 자신이 선택한 공개 Cardano 탐색기에서 트랜잭션을 가져와 레코드를 읽고, 콘텐츠 해시를 원본 바이트와 대조합니다. 이 확인에는 어떤 CardanoWall 서버도 관여하지 않습니다. 증명이 우리 없이도 성립한다는 것이 바로 핵심입니다.

블록체인은 문서를 이해하지 못하며, 이해할 필요도 없습니다. 블록체인은 증명 데이터를 기록할 뿐, 의미는 검증하는 측이 해시를 다시 계산하고 바이트가 일치함을 확인하는 데서 나옵니다.

가장 단순한 증명은 무엇입니까?

가장 단순한 증명은 해시 전용 증명입니다.

파일을 하나 고릅니다. 소프트웨어가 SHA-256 또는 BLAKE2b-256 같은 해시를 계산합니다. 그 해시는 Cardano 메타데이터에 게시되는 레코드로 들어갑니다. 이후 검증하는 측이 원본 파일에 대해 해시 계산을 다시 수행하고, 다이제스트가 일치하면 증명이 통과합니다.

따라서 첫 번째 수준은 세 가지 사실로 정리됩니다.

  1. 콘텐츠가 존재한다.
  2. 그 해시가 온체인에 고정되어 있다.
  3. 원본 콘텐츠를 가진 사람은 누구나 일치 여부를 검증할 수 있다.

많은 용도에서는 이것으로 충분합니다. 타임스탬프가 찍힌 해시는 단순하기 때문에 오히려 강력합니다. 잘못 설정할 여지가 거의 없고, 신뢰해야 할 대상도 없습니다.

해시만으로 부족한 경우는 언제입니까?

단순한 해시는 한 가지 질문에는 잘 답하지만, 모든 질문에 답하지는 못합니다.

해시는 누가 파일을 만들었는지 말해 주지 않습니다. 바이트가 존재했다는 것만 보여 줄 뿐입니다. 두 사람이 같은 공개 PDF를 가지고 있다면, 둘 중 누구든 그 해시를 게시할 수 있으므로 해시만으로는 작성자에 대해 아무것도 말해 주지 않습니다.

해시는 파일을 보존하지도 않습니다. 원본 바이트를 잃으면 공개 해시는 남아도 그에 대조할 대상이 아무것도 남지 않을 수 있습니다.

또한 해시는 파일을 누구에게도 전달하지 않습니다. 다른 사람이 원본 데이터를 필요로 한다면, 단순한 해시가 그것을 건네주지는 않습니다.

이것이 기반 레코드 형식이 계층적으로 구성된 이유입니다. 해시 전용 레코드도 완전히 유효하지만, 표준은 서명, 봉인된(암호화된) 페이로드, 수신자 지정 전달, Merkle 배칭도 지원하며, 각 기능은 타임스탬프 위에 하나의 능력을 더합니다.

서명은 증명을 어떻게 바꿉니까?

서명은 키로 뒷받침되는 진술을 더합니다.

서명된 레코드는 "이 바이트가 이 시점까지 존재했다"보다 더 많은 것을 말합니다. "이 키가 이 레코드에 서명했다"라고도 말할 수 있습니다. 이는 작성자 표시, 승인, 내부 통제, 비즈니스 워크플로에 중요합니다. 조직은 특정 시스템, 팀, 또는 신원이 레코드를 보증했음을 서명 키로 보여 줄 수 있고, 창작자는 증명에 서명해 자신의 신원을 작품과 연결할 수 있습니다.

다만 표현은 정확하게 유지해야 합니다. 서명은 그 키가 레코드에 서명했음을 보여 줄 뿐, 현실에서 누가 그 키를 보유하는지는 보여 주지 않습니다. 키를 사람과 연결하는 일은 레코드 밖에서 형성된 맥락에 달려 있습니다. (CardanoWall은 설계상 서명을 선택 사항으로 둡니다. 누구나 게시할 수 있고, 검증하는 측은 게시자를 신뢰할 필요가 전혀 없습니다.)

봉인은 증명을 어떻게 바꿉니까?

봉인된 증명은 암호화된 보존을 더합니다.

봉인된 레코드에서도 온체인 증명은 여전히 평문의 해시에 커밋합니다. 다만 파일 자체는 암호화되어 콘텐츠 주소 지정 위치, 즉 ar://(Arweave) 또는 ipfs:// 주소에 저장되고, 레코드에는 그 참조만 담깁니다. 체인은 평문을 결코 보지 않습니다.

이는 원본 파일을 잃으면 해시를 쓰기 어려워지는 상황에서 중요합니다. 봉인된 증명이 있으면, 올바른 키를 가진 사람이 이후 저장된 암호문을 가져와 복호화하고, 평문 해시를 다시 계산해, 복호화된 파일이 체인에 커밋된 콘텐츠와 정확히 일치함을 확인할 수 있습니다. 저장 주소가 바이트 자체에서 파생되기 때문에, 수신자는 스토리지 게이트웨이를 신뢰하지 않고도 그 게이트웨이가 올바른 바이트를 반환했는지 알 수 있습니다.

공개 체인은 평문을 결코 노출할 필요가 없습니다. 암호화된 페이로드는 증명과 함께 이동하고, 복호화 키는 그것을 보유해야 할 사람에게 남습니다.

수신자 전달은 증명을 어떻게 바꿉니까?

수신자 전달은 봉인된 레코드를 다른 사람을 위해 암호화할 수 있게 합니다.

수신자의 수신 주소(그들이 공유한 공개 키)를 알고 있다면, 그 사람만 자신의 키로 열 수 있는 봉인된 레코드를 게시할 수 있습니다. 특히 그 레코드에는 "이것은 Alice에게 보내는 것이다"라고 말하는 필드가 없습니다. 체인상에는 수신자 정보가 전혀 없습니다. 수신자의 소프트웨어가 공개 레코드를 스캔하면서 자기 키로 향했을 수 있는 항목을 조용히 시험 복호화하고, 실제로 자기에게 온 것만 엽니다.

이로써 존재 증명은 개인적인 타임스탬프를 넘어섭니다. 기밀 공개, 법적 증거 교환, 비공개 컴플라이언스 패키지, 내부 감사 인계 등, 타임라인은 공개되어야 하지만 콘텐츠는 공개되어서는 안 되는 워크플로를 지원할 수 있습니다. 다만 누군가에게 무언가를 봉인하기 전에, 그 키가 정말 그 사람의 것인지 확인할 가치가 있습니다. 파일을 봉인하기 전에 수신자를 확인하기를 참고하십시오.

솔직하게 짚어야 할 한 가지 한계가 있습니다. 암호화는 바이트를 보호하지, 사람을 보호하지는 않습니다. 봉인은 평문을 키 보유자만 읽을 수 있도록 하지만 익명성을 보장하지는 않으며, 수신자는 일단 복호화하고 나면 언제든 평문을 유출할 수 있습니다.

Merkle 배칭은 증명을 어떻게 바꿉니까?

Merkle 배칭은 하나의 레코드로 여러 항목에 한 번에 커밋할 수 있게 합니다.

파일마다 트랜잭션을 하나씩 만드는 대신, 시스템은 수천 또는 수백만 개의 항목을 해시하고, 그 해시들을 Merkle 트리로 접어, 단일 32바이트 루트를 게시할 수 있습니다. 이후 포함 증명은 특정 항목 하나가 커밋된 배치의 일부였음을 보여 줍니다. 검증하는 측은 모든 파일이 온체인에 있을 필요가 없습니다. 루트가 공개 커밋이고, 배치 크기의 로그에 비례해서만 커지는 짧은 포함 증명이 개별 항목을 그 루트로 다시 연결합니다. 배치 안의 다른 모든 항목은 비공개로 유지됩니다.

이는 대량 처리 워크플로에 적합합니다.

  • CI/CD 산출물과 릴리스 매니페스트;
  • 일일 컴플라이언스 로그;
  • 대규모 AI 생성 콘텐츠;
  • 데이터셋 스냅샷;
  • 감사 증거 폴더;
  • 미디어 및 출판 아카이브.

Merkle 모드는 온체인 레코드를 작게 유지하면서도 하나의 증명이 방대한 항목 집합을 포괄하게 합니다. 구체적인 예시는 파일 수천 개를 위한 하나의 레코드를 참고하십시오.

존재 증명이 증명하지 않는 것은 무엇입니까?

이 절은 증명을 정직하게 유지하는 부분입니다. 타임스탬프 커밋은 구체적이기 때문에 강력하며, 구체적이라는 것은 곧 하지 않는 주장이 있다는 뜻입니다.

존재 증명은 문서가 임을 증명하지는 않습니다. 거짓 문서도 참 문서만큼이나 쉽게 타임스탬프를 받을 수 있습니다.

존재 증명은 소유권을 증명하지는 않습니다. 누구나 자신이 소유하지 않은 파일을 해시할 수 있습니다.

존재 증명은 그 자체만으로 작성자를 증명하지는 않습니다. 작성자 입증에는 서명, 키 관리, 그리고 그 위에 얹히는 현실 세계의 맥락이 필요합니다.

존재 증명은 소프트웨어 빌드가 안전함을 증명하지는 않습니다. 특정 시점에 어떤 산출물, SBOM, 로그, 매니페스트가 존재했는지는 보여 줄 수 있지만, 보안은 빌드 과정과 그 주변의 통제에 달려 있습니다.

존재 증명은 데이터셋이 적법하게 수집되거나 사용되었음을 증명하지는 않습니다. 데이터셋 커밋이 존재했음은 보여 줄 수 있고, 이는 중요한 증거가 될 수 있지만, 법적 권리는 관할권과 자문에 따라 달라지는 별개의 문제입니다.

요컨대 존재 증명은 시점과 무결성을 제공할 뿐, 진실이나 권리를 제공하지는 않습니다. 그 위의 모든 추가 주장은 이 토대 위에 신중하게 쌓아 올려야 합니다. 증명이 증명하지 않는 것에서 그 경계가 정확히 어디에 있는지 더 깊이 다룹니다.

CardanoWall이 Label 309 위에 구축하는 이유

증명은 이식 가능한 만큼만 유용합니다. 하나의 웹사이트 안에서만 작동하는 증명은 증명이라 할 수 없습니다. 제대로 된 증명이라면 독립적인 도구로 읽을 수 있고, 공개 인프라에서 검증할 수 있으며, 원래 서비스가 작성하지 않은 소프트웨어로도 이해할 수 있어야 합니다.

이것이 CardanoWall이 Cardano 기반 존재 증명을 위한 개방형 벤더 중립 표준인 Label 309 위에 구축된 이유입니다. 지속되는 산물은 CardanoWall 앱이 아니라 Label 309입니다. 웹 앱, 명령줄 도구, SDK는 모두 그 표준의 하위에 있는 참조 구현입니다. 이 표준은 단순한 타임스탬프에서부터 위로 확장되는 하나의 레코드 형식을 정의합니다.

  • 단순한 존재 증명을 위한 해시 전용 증명;
  • 키로 뒷받침되는 작성자 주장을 위한 서명된 증명;
  • 암호화된 보존을 위한 봉인된 증명;
  • 비공개 전달을 위한 수신자 봉인 증명;
  • 대량 배치를 위한 Merkle 증명;
  • 이름이 부여된 알고리즘 식별자로, 이전 레코드를 깨뜨리지 않고도 암호 기술이 시간에 따라 발전할 수 있게 합니다.

이 형식은 공개 검토도 거치고 있습니다. 메타데이터 레이블 309 아래의 존재 증명은 Cardano CIP 프로세스에 제출되어, Metadata 범주 제안으로 CIP 편집자들의 검토를 받고 있습니다. (메타데이터 레이블 309는 온체인 식별자이며, CIP 번호는 프로세스에서 별도로 부여합니다.) 전체 표준과 그 참조 구현, 오픈 소스 코드는 모두 관대한 라이선스 아래 github.com/cardanowall에 공개되어 있습니다.

CardanoWall은 인터페이스입니다. Label 309는 레코드 형식입니다. 증명은 이 둘, 즉 인터페이스와 그것을 게시하도록 도운 회사보다 오래 살아남도록 설계되었습니다.

더 읽을거리

proof-of-existencelabel-309guides