Label 309 레코드를 검증하는 방법

Label 309 레코드는 단 하나의 입력, 즉 Cardano 트랜잭션 참조에서 출발해 공개 Cardano 체인에서 바로 검증합니다. 그 결과는 CardanoWall에도, 레코드를 게시한 주체에도, 여전히 가동 중인 어떤 서버에도 의존하지 않습니다.

검증기는 공개 Cardano 인프라에서 원시 트랜잭션 바이트를 가져와 메타데이터 레이블 309를 추출하고, 레코드 본문을 다시 조립한 뒤, 정규 CBOR와 스키마를 검사하고, 작성자 서명이 있다면 검증하며, 콘텐츠 바이트나 암호화된 페이로드를 사용할 수 있을 때는 해시를 다시 계산합니다. 이 전체 검사는 신뢰하는 서비스에 보내는 요청이 아니라 일련의 암호학적 비교입니다.

레코드를 게시한 게이트웨이는 권위의 원천이 아닙니다. 레코드가 그 원천입니다. 바로 이것이 표준의 핵심입니다. 한 번 검증한 증명은 어떤 적합한 Label 309 도구로든 누구나, 영원히, 다시 검증할 수 있습니다.

무엇이 있어야 검증할 수 있습니까?

최소 입력은 Cardano 트랜잭션 해시입니다.

이 트랜잭션 해시만으로 검증기는 다음에 답할 수 있습니다.

이 트랜잭션에 Label 309 레코드가 있는가?
그 레코드는 구조적으로 유효한가?
트랜잭션은 충분히 깊게 확정되었는가?
서명이 있다면 레코드 수준 서명이 검증되는가?
레코드가 주장하는 해시, 스토리지 URI, Merkle 루트, 봉인 봉투는 무엇인가?

특정 파일이 바로 그 해시에 대응하는 파일임을 증명하려면, 검증기에는 파일 바이트나 레코드가 참조하는 귀속 가능한 스토리지 객체도 필요합니다.

봉인된 레코드를 복호화하려면 검증기에 수신자의 개인 키가 필요합니다. 그 키는 로컬에서만 사용되며 게시자나 CardanoWall로 절대 되돌려 보내지 않습니다. 검증이 결코 외부에 연결하지 않도록 전체 구조가 설계되어 있습니다.

검증기는 실제로 무엇을 검사합니까?

좋은 검증기는 레코드를 계층으로 나누어 검사해야 합니다.

첫 번째 계층은 구조 검증기입니다. 이는 레코드 바이트에 대한 순수 함수입니다. 네트워크 호출도, 복호화도, 서명 검증도 수행하지 않습니다. 정규 CBOR, 필드 타입, 닫힌 스키마, 등록된 알고리즘 이름, URI 규칙, 그리고 "최소한 하나의 항목 또는 하나의 Merkle 약정이 있어야 한다"와 같은 교차 필드 제약을 검사합니다.

두 번째 계층은 공개 검증기입니다. 검증기가 선택한 Cardano 데이터 소스에서 트랜잭션을 해석하고, 가져온 바이트를 트랜잭션 해시에 결속하며, 레이블 309를 추출하고, 확인 깊이를 검사하고, 레코드 서명을 검증합니다. 공개 감사, CI 작업, 또는 익스플로러가 실행할 수 있는 계층이 바로 이것입니다.

세 번째 계층은 수신자 검증기입니다. 공개 검증기가 하는 모든 일을 수행한 다음, 수신자의 로컬 키로 봉인된 항목을 복호화하려 시도하고, 복호화 후 평문 해시를 다시 계산합니다.

이 계층 구분이 중요한 이유는 모든 증명이 모든 검사를 필요로 하지는 않기 때문입니다. 해시만 담은 레코드는 암호화된 페이로드가 없어도 여전히 유효할 수 있습니다. 공개 검증기는 봉인된 파일을 복호화하지 못하더라도 서명된 레코드를 검증할 수 있습니다.

왜 JSON 뷰가 아니라 원시 트랜잭션 바이트에서 검증합니까?

Label 309 검증은 편리한 JSON 투영이 아니라 원시 체인 데이터에서 동작합니다. 그리고 그 차이는 겉치레가 아닙니다.

레코드는 정규 CBOR입니다. 서명은 바이트 단위로 정확한 정규 CBOR를 포괄합니다. Cardano 트랜잭션 메타데이터에는 JSON이 손실 없이 보존할 수 없는 바이트 문자열, 텍스트 문자열, 배열, 맵, 그리고 순서 규칙이 있습니다.

따라서 검증기는 원시 트랜잭션 CBOR를 가져와 트랜잭션 ID를 다시 계산하고, 보조 데이터를 트랜잭션 본문에 결속한 다음, 레이블 309 청크 배열을 원래의 레코드 본문으로 다시 조립해야 합니다.

익스플로러는 유용한 인프라일 수 있습니다. 하지만 신뢰의 대상이 되어서는 안 됩니다. 검증기는 익스플로러 응답을 결속하고, 검사하고, 교차 확인할 데이터로 취급해야 합니다.

레이블 309 레코드 안에는 무엇이 있습니까?

Label 309 레코드는 Cardano 트랜잭션 메타데이터 레이블 309 아래에 실려 운반됩니다.

온체인 값은 느슨한 JSON 객체가 아닙니다. 레코드 본문은 정규 CBOR로 한 번 직렬화된 뒤, 바이트 문자열 배열로 운반됩니다. Cardano 메타데이터의 바이트 문자열과 텍스트 문자열이 64바이트로 제한되기 때문입니다.

재조립을 마치면 레코드 본문은 하나의 CBOR 맵입니다. 그 최상위 키는 다음과 같습니다.

v, 스키마 버전 (현재 1);
items, 콘텐츠별 약정의 선택적 배열 — 각 항목은 필수 hashes 맵을 담으며, 선택적으로 콘텐츠 주소 지정 스토리지(ar://, ipfs://)를 위한 자체 uris 목록과 봉인된 콘텐츠를 위한 enc 봉투를 담습니다;
merkle, 하나의 온체인 루트를 오프체인 리프 목록에 결속하는 선택적 목록 약정 — 대용량 배치를 고정하는 방식입니다;
sigs, 선택적 레코드 수준 작성자 서명;
supersedes, 이전 레코드를 가리키는 선택적 추가 전용 포인터;
crit과 네임스페이스가 지정된 확장 키, 전방 호환 추가를 위한 것입니다.

적합한 레코드는 최소한 하나의 items 항목 또는 하나의 merkle 약정을 담아야 합니다. 스토리지 URI와 봉인 봉투는 최상위가 아니라 항목 안에 있습니다 — 레코드를 직접 파싱할 때 정확히 짚어 둘 가치가 있는 세부 사항입니다.

핵심 클레임은 언제나 콘텐츠 우선입니다. 이 해시들, 또는 이 Merkle 루트가 블록 타임보다 늦지 않은 시점에 이 트랜잭션에 고정되었다는 것입니다.

자동화는 어떤 판정을 예상해야 합니까?

검증은 모든 문제를 "유효" 또는 "무효"로 뭉뚱그려서는 안 됩니다.

Label 309 검증기 모델은 네 가지 기계 판정을 사용합니다.

valid: 필요한 모든 검사를 통과했습니다.
failed: 레코드 자체가 구조, 서명, 또는 귀속 가능한 무결성 검사에 실패했습니다.
unverifiable: 인프라 부재나 가져올 수 없는 콘텐츠처럼 레코드에 귀속되지 않는 이유로 필요한 검사를 완료할 수 없었습니다.
pending: 트랜잭션은 체인에 있지만 검증기의 확인 임계값 아래에 있습니다.

이 구분은 실제 시스템에서 중요합니다.

스토리지 게이트웨이가 다운되었다면 레코드를 단죄해서는 안 됩니다. 가져온 바이트가 약정된 URI에 귀속되는데 그 해시가 일치하지 않는다면 레코드는 실패해야 합니다. 트랜잭션의 확인이 단 하나뿐이라면, 검증기는 이미 최종성에 도달한 척하는 대신 보류 중이라고 말해야 합니다.

오픈 소스 cardanowall CLI는 이 상태들을 종료 코드에 곧바로 매핑하므로, 어떤 JSON도 파싱하지 않고 판정이 셸 스크립트로 그대로 전달됩니다.

cardanowall verify <tx-hash> --json

종료 코드	판정	의미
`0`	valid	필요한 모든 검사를 통과함
`1`	failed	레코드에 귀속되는 검사가 실패함 (무결성, 구조, 또는 서명)
`2`	unverifiable	레코드 결함은 없으나 필요한 검사를 실행할 수 없었음 (네트워크 또는 정책)
`3`	pending	아직 확인이 충분하지 않음 — 보류 중인 레코드에서 나온 결과는 최종이 아님
`4`	—	CLI 입력 오류 (잘못된 인수 또는 누락된 필수 입력)

이 구분은 지속적 통합에서 바로 원하는 것입니다. 스크립트가 "증명이 잘못되었다"(종료 코드 1, 오작동하는 익스플로러가 결코 조작할 수 없음)와 "나중에 다시 시도하라"(종료 코드 2)를 구별할 수 있습니다. 동일한 검증기가 TypeScript, Python, Rust SDK에 함께 들어 있으므로, 애플리케이션은 종료 코드 대신 전체 구조화 보고서를 읽을 수 있습니다. 이를 파이프라인에 연결하는 패턴은 자동화에서 CLI 사용하기를 참고하십시오.

파일은 어떻게 검증합니까?

간단한 파일 증명의 작업 흐름은 다음과 같습니다.

트랜잭션 해시를 가져옵니다.
Label 309 레코드를 가져와 검증합니다.
약정된 해시 알고리즘과 다이제스트를 식별합니다.
파일 바이트를 로컬에서 해시합니다.
자신의 다이제스트를 레코드의 다이제스트와 비교합니다.
확인 깊이와 블록 타임을 검사합니다.
레코드 서명이 있다면 검증합니다.

파일이 단 한 바이트라도 다르면 해시가 달라집니다.

이것이 콘텐츠 해시 증명의 강점입니다. 이 증명은 파일이 참되거나, 합법적이거나, 원본이거나, 가치 있다는 것을 증명하지는 않습니다. 검증기의 최종성 정책에 따라, 해시와 일치하는 정확한 바이트가 고정된 블록 타임보다 늦지 않은 시점에 존재했다는 것을 증명합니다.

봉인된 레코드는 어떻게 검증합니까?

봉인된 레코드는 암호화된 콘텐츠를 추가합니다.

공개 레코드는 여전히 평문 해시에 약정합니다. 암호문은 예를 들어 Arweave나 IPFS를 통해 오프체인에 저장할 수 있습니다. 온체인 봉투에는 의도된 수신자가 콘텐츠 키를 로컬에서 복원하는 데 필요한 정보가 담겨 있습니다.

수신자 검증기는 다음을 수행해야 합니다.

먼저 공개 검증 경로를 실행합니다.
제공된 개인 키를 봉인된 슬롯에 시험해 봅니다.
슬롯이 열리면 암호문을 복호화합니다.
평문 해시를 다시 계산합니다.
그 값을 온체인 해시 약정과 비교합니다.

이 마지막 해시 검사는 "무언가를 복호화했다"와 "이것이 타임스탬프가 찍힌 바로 그 콘텐츠다" 사이를 잇는 다리입니다. 바이트를 복호화하는 것만으로는 충분하지 않습니다. 다시 계산한 평문 해시는 암호화가 이루어지기 전에 레코드가 만든 약정과 일치해야 합니다.

수신자 키는 로컬에 머뭅니다. 검증에는 신뢰하는 CardanoWall 계정도, 발행자 서버도, 레코드를 게시한 사람에게 보내는 콜백도 필요 없습니다. 봉인된 레코드는 평문을 키 보유자에게만 비밀로 유지합니다 — 다만 그 한계에 유의하십시오. 이는 익명성을 보장하지 않으며, 일단 수신자가 콘텐츠를 복호화하면 그 평문으로 무엇이든 할 수 있습니다.

Merkle 약정은 어떻게 검증합니까?

Merkle 약정은 배치를 위한 것입니다.

수천 개의 해시를 하나의 레코드에 직접 게시하는 대신, 생산자는 하나의 Merkle 루트를 게시하고 순서가 지정된 리프 목록과 포함 증명을 오프체인에 보관할 수 있습니다.

배치에서 한 항목을 검증하려면 다음과 같이 합니다.

항목을 해시하거나 약정된 리프 다이제스트를 얻습니다.
Merkle 루트에 대해 포함 증명을 검증합니다.
루트와 leaf_count가 Label 309 레코드에 있는지 검사합니다.
Cardano 트랜잭션과 확인 깊이를 검증합니다.

루트만으로는 충분하지 않습니다. 생산자나 아카이브는 리프 목록과 포함 증명을 보존해야 합니다. Label 309는 배치에 공개 고정점을 부여합니다. 배치를 둘러싼 운영 증거는 여전히 보관해야 합니다. 이것이 바로 하나의 레코드가 수천 개의 파일을 증명하는 방식이며, 그것도 고정된 온체인 비용으로 이루어집니다.

무엇을 신뢰해서는 안 됩니까?

게시자의 웹사이트를 진실의 원천으로 신뢰하지 마십시오.

트랜잭션의 스크린샷을 신뢰하지 마십시오.

JSON 익스플로러 뷰를 암호학적 입력으로 신뢰하지 마십시오.

단지 바이트를 반환했다는 이유만으로 스토리지 게이트웨이를 신뢰하지 마십시오.

무엇이 검사되었는지 밝히지 않는 "검증됨" 배지를 신뢰하지 마십시오.

검증기는 보고서를 생성할 수 있어야 합니다. 트랜잭션 해시, 사용한 Cardano 데이터 소스, 확인 깊이, 블록 타임, 레코드 다이제스트, 서명 결과, 콘텐츠 해시 결과, 스토리지 가져오기 결과, Merkle 검사, 그리고 건너뛴 모든 검사가 그것입니다.

그 보고서가 바로 감사와 자동화에서 증명을 쓸모 있게 만드는 것입니다.

검증은 무엇을 증명하지 않습니까?

검증은 정밀합니다. 과장해서 팔아서는 안 됩니다.

유효한 Label 309 레코드는 그 자체만으로 다음을 증명하지는 않습니다.

콘텐츠에 대한 법적 소유권, 또는 그에 대한 독점적 권리;
콘텐츠가 참이라는 것;
게시자에게 그것을 게시할 권한이 있었다는 것;
실제 인물이 서명 키를 통제한다는 것;
법원, 규제 기관, 또는 고객이 뒷받침 증거 없이 그 증명을 받아들이리라는 것 — 증거능력은 관할권에 따라 다르며, 증명은 사건을 뒷받침할 수는 있어도 변호인을 대체하지는 않습니다;
스토리지 내구성이 별도로 유지되지 않는 한, 오프체인 스토리지가 영원히 가용한 채로 남으리라는 것.

검증은 레코드가 실제로 만드는 클레임을 증명합니다. 해시 또는 Merkle 루트가 Cardano에 고정되었고, 레코드에 대한 서명이 있다면 모두 검증되었으며, 콘텐츠나 복호화 검사가 있다면 모두 약정과 일치했다는 것입니다. 다시 말해, 진실이나 소유권이나 권리가 아니라 시점과 무결성을 확립합니다.

바로 그 더 좁은 클레임이 검증을 쓸모 있게 만듭니다. 타임스탬프가 할 수 있는 것과 할 수 없는 것의 전체 경계는 증명이 증명하지 않는 것을 참고하십시오.

더 읽을거리

전체 검증 파이프라인, 판정 상태, 그리고 타입이 지정된 오류 카탈로그를 포함한 Label 309 표준: label309.org.
오픈 소스 검증기 — cardanowall CLI와 동일한 검사를 모두 실행하는 TypeScript, Python, Rust SDK: github.com/cardanowall.
Label 309는 Cardano CIP 프로세스에 제출되어 Metadata 범주 제안으로 CIP 편집자의 검토를 받고 있습니다: 열린 풀 리퀘스트.