파일 수천 개를 레코드 하나로: Merkle 배칭

Label 309 레코드 하나로 파일 수천, 수백만 개가 특정 시점에 존재했음을 증명할 수 있습니다.

파일마다 블록체인 트랜잭션을 하나씩 게시하는 대신, 모든 파일을 해시하고 그 해시들을 Merkle 트리로 접은 다음, 32바이트짜리 Merkle 루트 하나만 게시합니다. 나중에 그 묶음에 속한 파일 하나가 포함되어 있었음을 간결한 포함 증명으로 입증할 수 있습니다. 나머지를 드러내지 않고, 모든 항목을 체인에 올리지도 않습니다.

이것이 존재 증명을 문서 하나에서 임의로 큰 집합까지 확장하는 방식입니다.

Merkle 배칭은 어떤 문제를 해결합니까?

블록체인은 긴 목록을 저장하기에 적합한 곳이 아닙니다. 모든 바이트에 수수료가 들고, Cardano 트랜잭션에는 엄격한 크기 상한이 있습니다.

로그, 모델 출력, 릴리스 빌드, 인보이스, 보고서, 증거 항목처럼 산출물이 꾸준히 쏟아지는 시스템이라면, 해시마다 별도의 온체인 레코드로 게시하는 방식은 금세 비싸지고 번잡해집니다.

Merkle 배칭은 순서가 있는 해시 목록을 단일 루트 커밋으로 압축합니다. 루트는 크기가 고정되어 있고(32바이트), 묶음은 무한정 커질 수 있으며, 어떤 항목 하나의 증명도 작게 유지됩니다. 증명 크기는 묶음 크기의 로그에 비례해서만 늘어납니다. 덕분에 대용량 워크플로에서도 정기적인 커밋이 실용적입니다.

Merkle 루트란 무엇입니까?

Merkle 루트는 순서가 있는 목록 전체를 커밋하는 단일 해시입니다.

리프 목록에서 시작합니다. 존재 증명 워크플로에서 각 리프는 보통 파일, 이벤트, 또는 매니페스트 항목의 해시입니다. 리프들을 이진 트리 위로 쌍을 지어 결합하고, 맨 위에 놓인 해시가 Merkle 루트입니다.

이 커밋은 세 가지 면에서 정확합니다.

리프가 하나라도 바뀌면 루트가 바뀝니다.
리프의 순서가 바뀌면 루트가 바뀝니다.
커밋은 리프가 몇 개인지도 기록하므로, 크기가 다른 목록은 같은 묶음으로 위장할 수 없습니다.

루트를 게시하는 것은 순서가 있는 목록 전체에 대한 지문을 게시하는 것과 같습니다.

실제로 체인에 올라가는 것은 무엇입니까?

루트뿐입니다. 리프의 전체 목록은 체인 밖에 남습니다.

Label 309 레코드는 이 커밋을 일반적인 파일별 해시와는 분리된 전용 merkle 필드에 담습니다. 각 커밋은 작고 고정된 구조입니다.

커밋 알고리즘(Label 309 v1은 rfc9162-sha256을 등록합니다. SHA-256을 쓰는 RFC 9162 Merkle Tree Hash입니다);
32바이트 루트;
루트를 체인 밖 목록의 크기와 묶어 주는 리프 개수;
리프 목록 파일을 가리키는 선택적 콘텐츠 주소 지정 URI(ar:// 또는 ipfs://).

온체인 레코드는 작게 유지됩니다. 루트 하나가 32바이트라는 고정 비용으로 무한정 큰 목록을 커밋합니다. 세부 내용은 순서가 있는 리프 목록의 형태로 체인 밖에 존재합니다. (레코드의 나머지 부분이 어디에 있는지는 블록체인에는 무엇이 올라가는가를 참고하십시오.)

나중에 파일 하나는 어떻게 입증합니까?

포함 증명을 만들어 냅니다.

포함 증명은 리프 하나에서 루트까지 이어지는 경로를 따라 늘어선 형제 해시들의 짧은 목록입니다. 검증기는 그 리프와 형제 해시들을 트리 위로 다시 접어 올린 뒤, 다시 계산한 루트가 게시된 루트와 정확히 일치할 때만 증명을 받아들입니다.

실제로 이 확인에는 네 가지 입력이 들어갑니다.

입증하려는 파일 또는 항목의 해시;
포함 증명(형제 경로);
Label 309 레코드에 담긴 Merkle 루트;
그 레코드를 실은 트랜잭션의 Cardano 블록 타임.

접어 올린 결과가 게시된 루트를 재현하면, 그 항목은 커밋된 목록 안에 있었던 것이며, 블록 타임이 그 목록이 존재한 시점을 증언합니다. 검증기에는 그 항목 하나와 그 증명만 있으면 됩니다. 묶음 안의 다른 파일은 전혀 필요하지 않습니다.

정확히 짚어 둘 만한 두 가지가 있습니다. 이 구조는 순서에 민감하므로, 리프는 게시할 때와 동일한 순서로 유지해야 합니다. 그리고 리프가 하나뿐인 "트리"는 쓸모 있는 타임스탬프가 되지 못합니다. 리프가 하나인 트리의 루트는 그 리프 자체가 아니므로, 파일 하나를 입증하려면 한 항목짜리 Merkle 커밋이 아니라 평범한 콘텐츠 해시를 게시합니다.

빌드와 검증이 완전히 오프라인으로 이루어진다는 점이 왜 강점입니까?

서버를 거치는 유일한 단계가 루트를 게시하는 것뿐이기 때문입니다.

트리를 빌드하고, 포함 증명을 도출하고, 그것을 검증하는 일은 순수한 계산입니다. 순서가 있는 리프 목록을 가진 사람이라면 누구나 루트를 다시 계산하고 어떤 증명이든 다시 도출할 수 있습니다. 계정도, 게이트웨이도, 네트워크도, 원래 게시한 측의 협조도 필요 없습니다. 검증 시점에 게시자가 끼어들 일은 결코 없습니다.

이는 도구와 벤더보다 오래 살아남아야 하는 증거에 중요합니다. 공개 Cardano 탐색기와 대조해 오프라인으로 확인할 수 있는 증명은 특정 서비스가 사라진 뒤에도 한참 동안 계속 동작합니다. 묶음 커밋도 Label 309 레코드를 검증하는 것과 똑같은 방식으로 검증할 수 있고, 오픈소스 cardanowall 명령줄 도구로 포함 확인을 CI에 곧장 연결할 수 있습니다(merkle-build로 폴더를 루트로 접고, merkle-verify로 어떤 항목이 거기에 속하는지 확인합니다).

이것이 대용량 워크플로에 왜 유용합니까?

현실의 증명 상당수는 단일 파일 형태가 아니라 묶음 형태이기 때문입니다. 어떤 팀은 다음을 보여야 할 수 있습니다.

CI/CD 파이프라인이 무엇을 빌드했고 어떤 산출물이 릴리스에 실렸는지;
취약점이 공개되기 전에 어떤 소프트웨어 자재 명세서(SBOM)가 존재했는지;
어떤 AI 출력이 특정 날짜에 생성되었는지;
학습 실행 전에 어떤 데이터셋 스냅숏이 존재했는지;
감사 전에 어떤 컴플라이언스 로그가 존재했는지;
보존 명령 전에 어떤 법적 증거 파일이 보존되었는지;
특정 시점에 대차대조표가 어떤 준비금을 커밋했는지.

이 중 어느 것도 파일 하나당 트랜잭션 하나라는 모델에 잘 들어맞지 않습니다. Merkle 배칭을 쓰면 묶음마다 커밋 하나를 게시할 수 있습니다. 비공개 항목을 하나하나 노출하지 않고, 묶음 크기에 따라 선형으로 늘어나는 온체인 메타데이터도 없이 말입니다.

리프 목록을 비공개로 유지할 수 있습니까?

가능합니다. 게시된 루트는 자신이 커밋하는 리프에 대해 아무것도 드러내지 않습니다.

리프 목록을 자체 증거 시스템, 릴리스 아카이브, 데이터 룸, 또는 컴플라이언스 저장소 안에 보관해 두었다가, 나중에 필요한 것만 공개할 수 있습니다.

파일 하나와 그 포함 증명;
데이터셋 행 하나, 문서, 또는 릴리스 산출물;
감사 로그 항목 하나;
목록의 일부;
또는 리프 목록 전체.

이는 기반 데이터를 공개하지 않으면서도 공개적이고 타임스탬프가 찍힌 커밋을 원할 때의 패턴이며, 공개 파일 없이 이루어지는 기밀 공개나 Merkle 루트를 이용한 준비금 증명과 밀접하게 관련됩니다.

여기에는 책임이라는 대가가 따릅니다. 루트는 알려진 크기의 어떤 목록이 알려진 시점에 존재했음을 증명할 뿐, 그 자체로는 어떤 특정 항목이 그 안에 있었는지를 입증해 주지는 않습니다. 리프 목록을 비공개로 둔다면 그것을 보존해야 합니다. 리프 목록과 저장해 둔 포함 증명을 모두 잃으면 타임스탬프는 남지만 특정 항목이 커밋되었음을 입증할 능력은 잃습니다.

리프는 무엇이어야 합니까?

리프는 나중에 입증해야 할 수도 있는 바로 그것을 정확히 나타내야 합니다.

파일이라면 리프는 파일 바이트의 해시입니다. 구조화된 데이터라면 보통 정규화된 매니페스트 항목의 해시입니다. CI/CD라면 리프는 산출물 다이제스트, SBOM 다이제스트, 빌드 로그 다이제스트, 커밋 참조, 또는 서명된 릴리스 매니페스트 항목일 수 있습니다. AI 출처 증명이라면 리프는 출력 파일 해시, 프롬프트/출력 매니페스트 항목, 데이터셋 항목 커밋, 또는 콘텐츠 출처 매니페스트 해시일 수 있습니다.

중요한 원칙은 일관성입니다. 리프가 실행마다 다른 방식으로 생성되면 나중의 포함 증명을 신뢰하기 어려워집니다. 리프 정의와 정규화를 한 번 정해 두고, 매번 똑같은 방식으로 적용하십시오.

리프 목록을 게시해야 합니까, 비공개로 유지해야 합니까?

무엇을 입증하려는지, 그리고 누가 보아야 하는지에 달려 있습니다.

리프 목록을 게시하면 제3자 검증이 간단해집니다. 누구나 목록을 가져와 루트를 다시 계산하고 커밋된 집합을 살펴볼 수 있습니다. 비공개로 유지하면 기밀성과 선택적 공개를 얻습니다. 필요할 때만 포함 증명을 공개하면 됩니다. 많은 워크플로는 두 방식을 함께 씁니다. 오픈소스 릴리스에는 공개 리프 목록을, 내부 컴플라이언스 로그에는 비공개 리프 목록을, 민감한 증거에는 봉인된 리프 목록을 쓰는 식입니다.

루트는 공개 커밋입니다. 리프 목록 정책은 그 위에 얹히는 별개의 선택입니다.

루트는 얼마나 자주 게시해야 합니까?

게시 주기를 워크플로에 맞추십시오.

CI/CD 시스템은 릴리스, 빌드, 또는 배포 구간마다 루트 하나를 게시할 수 있습니다. 컴플라이언스 시스템은 시간당, 일당, 또는 통제 주기당 루트 하나를 게시할 수 있습니다. AI 플랫폼은 생성 콘텐츠 묶음당, 학습 스냅숏당, 또는 모델 버전 이벤트당 루트를 게시할 수 있습니다. 법적 증거 시스템은 사건 번들당, 접수 구간당, 또는 보관 연속성 이정표당 루트를 게시할 수 있습니다.

알맞은 주기는 비용, 운영 단순성, 그리고 나중에 입증해야 할 타임라인의 정밀도 사이에서 균형을 잡습니다.

Merkle 루트가 증명하지 않는 것은 무엇입니까?

Merkle 루트는 특정 시점의 목록에 대한 커밋을 증명합니다. 그 목록을 둘러싼 비즈니스 주장을 증명하지는 않습니다. 여느 존재 증명과 마찬가지로, Merkle 루트는 특정 바이트가 공개된 시점까지 존재했음을 보일 뿐입니다. 그것이 참이라거나, 적법하다거나, 특정인이 작성했다거나, 누군가의 소유라는 것까지 보이지는 않습니다(증명이 증명하지 않는 것 참고).

구체적으로는 이렇습니다.

소프트웨어 빌드가 안전했음을 증명하지는 않습니다. 어떤 산출물이나 매니페스트가 릴리스에 포함되었는지는 증명할 수 있습니다.
데이터셋이 적법하게 수집되었음을 증명하지는 않습니다. 특정 시점 이전에 데이터셋 커밋이 존재했음은 증명할 수 있습니다.
로그 항목이 참임을 증명하지는 않습니다. 그 항목이 커밋된 묶음의 일부였음은 증명할 수 있습니다.
작성자가 누구인지는 증명하지 않습니다. 레코드나 그 주변 절차가 서명과 신원 통제를 더하지 않는 한 그렇습니다.

Label 309에서 작성자 표시는 선택적이며 명시적입니다. 레코드는 분리된 서명을 실을 수 있지만 그것이 요구되는 법은 없으며, Merkle 커밋 그 자체만으로는 누가 목록을 만들었는지에 대해 아무 주장도 하지 않습니다. 루트는 타임스탬프가 찍힌 커밋을 제공하고, 그 주변의 절차가 비즈니스적 의미를 부여합니다.

Label 309는 여기에 어떻게 맞물립니까?

Label 309는 Cardano 위의 존재 증명을 위한 개방적이고 벤더 중립적인 표준입니다. Cardano CIP 절차에 제출되었으며 메타데이터 범주 제안으로서 CIP 편집자들의 검토를 받고 있습니다. Merkle 배칭은 별도의 제품이 아니라 표준에 내장된 확장 계층입니다.

묶음 커밋은 단일 파일 증명과 동일한 레코드, 동일한 검증 경로를 사용합니다. 메타데이터 레이블 309 아래의 레코드 하나가 Merkle 루트를 실을 수 있고, 그와 함께 어떤 레코드든 지원하는 동일한 선택적 요소들도 실을 수 있습니다. 일반적인 파일별 해시, 콘텐츠 주소 지정 스토리지 URI, 이전 레코드를 가리키는 대체(supersedence) 포인터, 그리고 작성자 서명 말입니다. 그래서 묶음 증명은 단일 증명이 가진 모든 것을 그대로 물려받습니다.

Cardano 블록 타임 증언;
표준적이고 닫힌 레코드 구조;
공개 탐색기와 대조하는 독립적·오프라인 검증;
여러 언어에 걸친 동일한 오픈소스 도구, 라이브러리, CLI.

모든 항목을 해시하고, 순서가 있는 Merkle 트리를 빌드하고, 루트 하나를 Label 309 레코드에 게시한 뒤, 리프 목록과 필요할 수 있는 증명을 보관하십시오. 나중에 어떤 항목 하나가 커밋된 묶음의 일부였음을 입증할 수 있습니다. 모든 항목을 체인에 올리지 않고도 말입니다. 이것이 존재 증명을 CI/CD, AI 출처 증명, 데이터셋, 컴플라이언스, 법적 증거, 그 밖의 대용량 워크플로에서 실용적으로 만드는 비결입니다.

더 읽을거리

Label 309는 어떻게 동작하는가 — 묶음 커밋이 끼워지는 레코드 구조.
학습 데이터를 드러내지 않고 입증하기 — 비공개 리프 목록에서 시작하는 선택적 공개를 처음부터 끝까지.
Label 309와 OpenTimestamps 비교 — 여러 해시를 하나의 앵커로 묶는 또 다른 프로토콜.
표준, 오픈소스 SDK와 CLI, 그리고 명세 텍스트: label309.org와 github.com/cardanowall.
RFC 9162 — Label 309가 묶음 커밋에 사용하는 Merkle Tree Hash 구조.