Label 309의 동작 원리

Label 309는 존재 증명 레코드를 Cardano 트랜잭션 메타데이터에 어떻게 기록하는지 정의합니다. 핵심을 보면, 레코드는 하나 이상의 콘텐츠 해시를 메타데이터 레이블 309 아래에서 Cardano에 고정합니다. 그 트랜잭션의 블록 타임은 바로 그 바이트가 그 순간 또는 그 이전에 존재했음을 보여주는 공개 증인이 됩니다. 레코드가 함께 담을 수 있는 나머지 — 서명, 스토리지 URI, 암호화된 페이로드, 수신자 키 슬롯, Merkle 루트, 이전 레코드를 가리키는 포인터 — 는 모두 그 하나의 클레임에 관한 선택적 메타데이터입니다.

설계 목표는 한마디로 분명합니다. 증명은 독립적으로 검증할 수 있어야 합니다. 기본 클레임을 확인하는 데에는 CardanoWall도, 게시자의 웹사이트도, 비공개 데이터베이스도, 인증 기관도 신뢰할 필요가 없어야 합니다. 필요한 것은 공개 체인뿐이며, 콘텐츠 클레임의 경우 원본 바이트만 추가로 있으면 됩니다.

Label 309는 개방형 표준입니다. 이 표준은 메타데이터 범주 제안으로 Cardano CIP 프로세스에 제출되어 CIP 편집자들의 검토를 받고 있습니다. 지속적인 온체인 식별자는 메타데이터 레이블 그 자체이며, 웹 앱과 CLI, SDK는 표준 자체가 아니라 그 표준의 참조 구현입니다. 더 넓은 그림이 먼저 궁금하다면 존재 증명이란 실제로 무엇인지부터 보십시오.

레이블 309 아래 블록체인에는 무엇이 저장됩니까?

Label 309 레코드는 정수 레이블 309 아래의 Cardano 트랜잭션 메타데이터에 저장됩니다. 트랜잭션 하나당 정확히 레코드 하나이며, 검증기는 다른 모든 메타데이터 레이블을 무시합니다.

레코드 본문은 정규 CBOR로 인코딩됩니다. 정규 CBOR는 결정적 이진 형식이므로, 동일한 논리적 레코드를 표현하는 두 구현은 바이트 단위로 동일한 결과를 내놓습니다. Cardano는 단일 메타데이터 문자열을 64바이트로 제한하는데, 직렬화된 레코드는 대개 그보다 큽니다. 그래서 본문은 작은 바이트 문자열 청크로 이루어진 하나의 CBOR 배열로 실어 나르며, 이를 순서대로 이어 붙인 것이 곧 레코드 본문입니다. 검증기는 무엇을 검증하기에 앞서 이 청크들을 다시 이어 붙입니다. 형식이 수행하는 청크 분할은 이것뿐입니다.

이 전송 세부 사항은 구현하는 쪽에 중요하지만, 그 밑에 깔린 발상은 단순합니다.

트랜잭션은 메타데이터 레이블 309를 담습니다.
그 레이블 아래의 값은 하나의 Label 309 레코드로 재조립됩니다.
레코드는 콘텐츠 해시, Merkle 루트, 또는 둘 다에 커밋합니다.
선택적 필드는 서명, 암호화된 페이로드 자료, 스토리지 URI, 대체 포인터를 더합니다.

이것은 자유 형식의 메모 필드가 아닙니다. 레코드는 엄격하고 닫힌 형태를 가지며, 바로 그 점 덕분에 서로 다른 구현이 같은 바이트를 생성하고 검증할 수 있습니다.

콘텐츠 해시는 왜 핵심 클레임입니까?

존재 증명은 정확한 바이트에 관한 클레임이고, 해시는 그 정확한 바이트의 지문이기 때문입니다.

콘텐츠 해시는 Label 309에서 핵심 클레임이며, 나머지 모든 필드는 그에 관한 메타데이터입니다. 단순한 파일 증명에서는 항목 하나가 hashes 맵을 담는데, 이 맵은 이름 붙은 해시 알고리즘 — 예를 들어 sha2-256 또는 blake2b-256 — 을 32바이트 원시 다이제스트와 짝지웁니다. 증명을 확인하려면 검증기가 원본 파일에서 다이제스트를 다시 계산하고, 이를 레코드에 담긴 다이제스트와 비교합니다.

바이트가 일치하면 증명은 통과합니다. 바이트를 하나만 바꿔도 다이제스트가 달라지므로 증명은 실패합니다.

콘텐츠가 크거나 비공개일 때에도 클레임이 작게 유지되는 이유가 바로 이것입니다. 레코드에는 파일이 결코 필요하지 않습니다. 필요한 것은 지문입니다.

items, uris, enc란 무엇입니까?

items는 레코드 안의 콘텐츠별 커밋먼트입니다. 각 항목은 하나의 콘텐츠 클레임입니다. 필수로 요구되는 부분은 비어 있지 않은 hashes 맵 하나뿐이고, 나머지는 선택입니다.

항목이 담을 수 있는 것은 다음과 같습니다.

hashes — 해시 알고리즘과 원시 다이제스트를 짝지은 필수 맵;
uris — ar://…(Arweave)나 ipfs://…(IPFS) 같은 선택적 콘텐츠 주소 지정 위치;
enc — 봉인된(암호화된) 레코드를 위한 선택적 암호화 봉투.

여기서 핵심은 uris가 증명이 아니라는 점입니다. 증명은 해시입니다. URI는 검증기가 확인할 바이트를 찾도록 돕는 검색 힌트이거나 스토리지 커밋먼트입니다. URI가 없는 해시 전용 레코드도 완전하고 유효한 증명입니다. URI가 있는 레코드는 공개 콘텐츠나 암호문을 가져오는 데 도움이 됩니다. 봉인된 레코드는 평문을 체인 밖에서 암호화된 상태로 유지하면서도 그것이 언제 존재했는지를 여전히 증명합니다.

왜 `ar://`와 `ipfs://`만 허용합니까?

Label 309 v1은 스토리지 URI를 콘텐츠 주소 지정 스킴 — Arweave와 IPFS — 으로 제한하고, https://를 포함한 그 밖의 모든 것을 거부합니다. 이 제한은 일시적인 것이 아니라 의도된 것입니다.

일반적인 https:// URL은 DNS, TLS, 서버 동작, 리디렉션, 그리고 나중에 그 주소에 무엇이 호스팅되는지에 의존합니다. 콘텐츠 주소 지정 URI는 다릅니다. 주소 자체가 콘텐츠에서 파생되기 때문입니다(IPFS CID는 바이트의 멀티해시이고, Arweave 트랜잭션 ID는 Arweave 합의 아래에서 그 데이터에 커밋합니다). 그래서 검증기는 스토리지 게이트웨이도, DNS도, 인증 기관도 신뢰하지 않고 "내가 가져온 바이트가 생산자가 커밋한 바로 그 바이트"임을 확인할 수 있습니다. 가져온 바이트는 여전히 온체인 커밋먼트와 일치해야 하며, 스토리지 계층은 그 자체로 진실의 원천이 결코 아닙니다.

서명은 무엇을 증명하며 — 무엇을 증명하지 않습니까?

Label 309 레코드는 선택적인 최상위 sigs 배열을 담을 수 있습니다. 각 항목은 sigs 필드를 제거한 레코드 본문에 대한 분리형 COSE_Sign1 서명입니다. 쉽게 말하면, 서명자는 레코드 전체를 한 번에 보증합니다. 모든 항목, 모든 해시, 모든 URI, 모든 봉인 봉투, 모든 Merkle 루트, 대체 포인터, 그리고 모든 확장 필드가 그 대상입니다.

서명은 추가적입니다. 서명이 없는 레코드도 여전히 존재를 증명합니다. 유효한 서명이 있는 레코드는 특정 키가 그 레코드를 뒷받침했다는 사실을 추가로 보여줍니다.

해시 전용: 이 바이트는 이 공개 시점까지 존재했다;
서명됨: 이 바이트는 이 공개 시점까지 존재했으며, 이 키가 그 레코드를 보증했다.

이 정밀함이 중요한 이유는, 서명이 사람들이 흔히 가정하는 것보다 적은 것을 증명하기 때문입니다. 검증된 서명은 같은 키가 Cardano 트랜잭션의 비용을 냈거나 제출했다는 것, 블록 타임을 선택했다는 것, 또는 이름이 알려진 실제 인물에게 속한다는 것을 증명하지 않습니다. 그것은 그 키가 레코드 본문에 서명했다는 것을 증명할 뿐, 그 이상은 아닙니다. 그러므로 이를 "이 키가 서명함"으로 표현하고, 결코 "이 키가 게시함"으로 표현하지 마십시오. 이렇게 좁고 정직한 의미야말로 서명된 증명이 서로 다른 앱과 게이트웨이 사이에서 이식 가능하게 만드는 요소입니다. 작성자 표시는 언제나 선택이며, 검증기가 확인할 수 없는 서명(지원되지 않는 알고리즘, 해석할 수 없는 키)은 존재 클레임을 결코 무효화하지 않습니다. 서명은 부드럽게 실패하지만, 존재는 그렇지 않습니다.

봉인된 레코드란 무엇입니까?

봉인된 레코드는 콘텐츠를 기밀로 유지하면서도 그것이 언제 존재했는지를 여전히 증명합니다.

봉인된 Label 309 레코드에서 항목은 여전히 평문 해시에 커밋하며, 암호문에는 결코 커밋하지 않습니다. 평문은 암호화되고, 암호문은 콘텐츠 주소 지정 URI(ar://… 또는 ipfs://…)에 위치하며 결코 체인에 올라가지 않습니다. 온체인 레코드는 선택된 키 보유자가 콘텐츠 암호화 키를 복구하는 데 필요한 자료를 담은 암호화 봉투를 운반합니다. 체인은 평문을 담지 않으며, 수신자 목록을 게시하지도 않습니다.

수신자에게는 검증에 몇 가지 단계가 추가됩니다.

Cardano에서 레코드를 가져옵니다.
콘텐츠 주소 지정 스토리지에서 암호문을 가져옵니다.
로컬에서 일치하는 키 슬롯을 열어 봅니다.
슬롯이 열리면 암호문을 복호화합니다.
평문 해시를 다시 계산해 온체인 커밋먼트와 비교합니다.

온체인 다이제스트가 평문을 묶어 두기 때문에, 봉인된 증명은 정확한 원본 파일을 보존하는 동시에 그것을 비공개로 유지합니다. 여기에는 몇 가지 정직한 한계가 따릅니다. 봉인된 레코드는 시점과 무결성을 증명하지만 익명성을 증명하지는 않으며, 복호화한 수신자는 그 뒤에 평문을 유출하기로 언제든 선택할 수 있습니다.

수신자 필드 없이 수신자는 어떻게 동작합니까?

수신자는 읽을 수 있는 수취인 필드가 아니라 수신 키와 시험 복호화를 통해 동작합니다.

발신자가 수신자의 수신 주소(X25519 공개 키, 선택적으로 하이브리드 포스트 양자 키)를 알고 있다면, 발신자는 그 수신자가 열 수 있는 키 슬롯을 가진 봉인된 레코드를 만들 수 있습니다. 수신자의 공개 키는 레코드 안에서 읽을 수 있는 필드로 결코 나타나지 않습니다. 수신자의 소프트웨어는 Label 309 레코드의 공개 스트림을 지켜보다가, 후보 슬롯을 로컬에서 복호화해 봅니다. 슬롯이 열리면 그 레코드는 해당 수신자의 받은편지함에 속합니다.

CardanoWall 받은편지함이 평범한 서버측 사서함이 아닌 이유가 바로 이것입니다. 게이트웨이는 수신자를 식별하지 않는 레코드 피드를 노출하고, 클라이언트가 복호화할 수 있는 것을 찾아냅니다. 서버는 수신자가 누구인지 알 필요도, 그를 대신해 무엇을 복호화할 필요도 결코 없습니다. (수신자 측의 실제 동작은 봉인된 레코드를 받는 방법을 참고하십시오.)

그래도 분명히 짚어 둘 메타데이터의 한계는 남아 있습니다. 레코드는 평문이나 수신자 열을 결코 게시하지 않으며, 슬롯 순서는 게시 전에 섞이므로 아무 신호도 담지 않습니다. 하지만 슬롯의 개수는 보이며, 시점, 결제 흔적, 운영상의 실수는 레코드 형식 자체로는 숨길 수 없는 정보를 드러낼 수 있습니다.

어떻게 레코드 하나가 수천 개의 파일을 다룹니까?

천 개의 파일이 존재했음을 증명해야 한다고 해서 천 개의 Cardano 트랜잭션이 필요해서는 안 됩니다. Label 309는 Merkle 배칭을 지원합니다. 파일들을 해시하고, 순서가 정해진 해시 목록 위에 Merkle 트리를 만든 뒤, 레코드의 merkle 배열에 단일 32바이트 루트를 게시합니다. 루트와 함께 레코드는 리프 개수를 담는데, 이는 온체인 루트를 체인 밖 목록의 정확한 크기에 묶어 줍니다.

나중에 특정 파일이나 이벤트가 그 배치에 포함되어 있었음을 다음을 제시해 증명할 수 있습니다.

그 파일(또는 그 리프 해시);
포함 증명 — 루트로 가는 경로를 따라 놓인 형제 해시들;
Label 309 레코드에 고정된 Merkle 루트.

검증기는 포함 증명을 루트까지 다시 접어 올리고, 다시 계산한 루트가 게시된 루트와 바이트 단위로 같을 때에만 이를 받아들입니다. 공개되지 않은 모든 리프는 비공개로 유지됩니다. 루트는 자신이 커밋하는 리프에 관해 아무것도 드러내지 않습니다.

이것은 CI/CD 아티팩트, 컴플라이언스 로그, AI 출력, 데이터셋 매니페스트, 릴리스 폴더, 증거 묶음을 위한 확장 계층입니다. 이에 관해서는 수천 개 파일을 위한 레코드 하나에서 따로 다룹니다.

supersedes 포인터는 무엇을 합니까?

supersedes는 이전 Label 309 레코드를 그 트랜잭션 해시로 가리키는 선택적 32바이트 포인터입니다. 이를 통해 더 새로운 레코드가 "이것이 그 이전 레코드를 대체하거나 갱신한다"고 말할 수 있습니다.

이전 레코드는 삭제되지도 무효화되지도 않습니다. Cardano는 추가 전용이므로 두 레코드 모두 영원히 독립적으로 검증 가능한 상태로 남습니다. 포인터는 단지 링크일 뿐이며, 이유 필드를 담지 않습니다. 대체가 사람에게 갖는 의미 — 정정, 수정된 매니페스트, 갱신된 증거 패키지 — 는 메타데이터가 아니라 새 콘텐츠나 애플리케이션 계층에 담깁니다. 이 포인터의 가치는 어떤 벤더 데이터베이스 행도, 독점 레코드 ID도 없이 동작한다는 데 있습니다.

검증은 어떻게 동작합니까?

검증은 계층적입니다. Label 309는 세 가지 검증기 역할을 정의하며, 각각은 앞선 것을 엄격하게 확장합니다.

구조 검증기 — 레코드 바이트에 대한 순수 함수입니다. 정규 CBOR, 스키마 형태, 필드 타입, 필수 필드, 알고리즘 식별자, URI 규칙을 확인합니다. 네트워크 I/O를 수행하지 않고, 어떤 서명도 검증하지 않으며, 아무것도 복호화하지 않습니다.
공개 검증기 — Cardano 트랜잭션 참조에서 시작합니다. 검증기 자신이 선택한 탐색기에서 원시 트랜잭션을 가져와 그 바이트를 요청된 트랜잭션 해시에 묶고, 레이블 309가 있는지 확인하고, 레코드를 재조립하고, 구조 검증을 실행하고, 확인 깊이를 점검하고, 자신이 지원하는 서명을 검증합니다. 콘텐츠 바이트를 쓸 수 있다면 공개 콘텐츠 해시를 다시 계산할 수 있습니다. 복호화는 하지 않습니다.
수신자 검증기 — 공개 검증기가 하는 모든 것에 더해, 봉인된 페이로드를 열고 평문 해시를 다시 계산할 자신의 비공개 키를 갖습니다.

한 가지 미묘한 점이 검증을 정직하게 유지합니다. 공개 검증기는 메타데이터에 대한 탐색기의 JSON 뷰가 아니라 원시 트랜잭션 CBOR를 읽습니다. JSON 투영은 손실이 있습니다. 맵 키 순서와 바이트 대 텍스트의 구분을 버리기 때문입니다. 그래서 그로부터 다시 인코딩하면 적합한 레코드의 모든 서명이 깨집니다. 그리고 Cardano의 확정은 확률적이므로, 블록 한두 개 깊이밖에 안 되는 레코드는 충분한 확인이 쌓일 때까지 valid가 아니라 pending으로 보고됩니다.

이 구조는 신뢰 모델을 깔끔하게 유지합니다. 기본 검증기에는 CardanoWall 계정이 필요 없고, 공개 증명은 게시자 서버 없이 확인되며, 봉인된 증명은 키 보유자의 손에서 로컬로 복호화됩니다. Label 309 레코드 검증하기 설명은 공개 검증기 경로를 처음부터 끝까지 보여 줍니다.

게이트웨이는 어디에 들어맞습니까?

게이트웨이는 레코드를 게시합니다. 게이트웨이는 신뢰의 뿌리가 아닙니다.

Label 309 게이트웨이는 직접 운영하기에는 정말로 까다로운 부분들을 처리합니다. 가격을 견적하고, 암호문을 스토리지에 업로드하고, Cardano 트랜잭션을 만들어 제출하고, 확인을 기다리고, 레코드를 인덱싱하고, 잔액을 관리하고, API를 노출합니다. CardanoWall은 이 게이트웨이 모델을 사용해 일반 사용자와 개발자가 실용적으로 게시할 수 있게 합니다.

하지만 증명은 게이트웨이가 존재한다고 말해서 신뢰되는 것이 아닙니다. 레코드가 체인에 있고, 바이트가 검증되고, 서명이 확인되고, 해시가 다시 계산되기 때문에 신뢰됩니다. 바로 이것이 호스팅 서비스와 증명 표준 사이의 경계입니다. 서비스는 게시를 돕고, 표준은 게이트웨이를 신뢰 경로에서 완전히 배제한 채 누구나 검증할 수 있게 합니다.

최소한의 사고 모델

Label 309를 작고 계층적인 레코드라고 생각하십시오.

items는 정확한 콘텐츠 바이트가 공개 시점까지 존재했음을 증명합니다.
sigs는 키가 레코드를 보증하도록 선택적으로 허용합니다.
enc는 암호화된 콘텐츠가 비공개이면서도 복구 가능하게 유지되도록 합니다.
수신자 키 슬롯은 특정 키 보유자가 봉인된 콘텐츠를 열 수 있게 합니다.
merkle는 레코드 하나가 매우 큰 배치를 대신하게 합니다.
검증은 공개 데이터와 로컬 키로 실행되며, 결코 벤더 신뢰에 기대지 않습니다.

이 계층 구조가 바로 CardanoWall이 웹 앱, API, CLI, 데스크톱 앱, 또는 자체 호스팅 게이트웨이가 될 수 있으면서도 증명 형식은 그대로 유지되는 이유입니다. 제품은 바뀔 수 있지만, 증명은 검증 가능한 상태로 남습니다.

처음부터 끝까지 정직하게 짚어 둘 한 가지가 있습니다. Label 309 증명은 특정 바이트가 공개 시점까지 존재했고 그 이후로 바뀌지 않았음을 보여 줍니다. 그것은 누가 콘텐츠를 작성했는지, 누가 그것을 소유하는지, 또는 그것이 말하는 내용이 사실인지를 증명하지는 않습니다. 그 경계가 어디에 놓이는지는 증명이 증명하지 않는 것을 참고하십시오.