Cardano에 첫 존재 증명 게시하기

가장 단순한 Label 309 증명은 Cardano에 고정된 해시입니다.

파일을 하나 가져와 그 암호 해시를 계산하고, 그 해시를 Cardano 메타데이터 레이블 309 아래의 Label 309 레코드로 게시한 뒤, 그 결과로 나온 트랜잭션 해시를 보관합니다. 이후 원본 파일을 가진 사람은 누구든 해시를 다시 계산해, 일치하는 커밋먼트가 트랜잭션의 블록 타임보다 늦지 않은 시점에 체인에 있었음을 확인할 수 있습니다. 이를 확인하는 데 게시자의 서버도, 도메인도, 신원도 필요하지 않습니다. 오직 트랜잭션 참조와 공개 Cardano 탐색기만 있으면 됩니다.

이것이 존재 증명의 첫 단계입니다. 나머지 모든 것은 그 위에 쌓입니다. 이 안내서는 주로 cardanowall 명령줄 도구를 사용해 증명 하나를 게시하는 과정을 따라가며, 그것이 실제로 동작했는지 확인하는 방법으로 마무리합니다.

실제로 무엇을 게시합니까?

기본 증명을 만들 때 파일 자체를 게시하지는 않습니다.

게시하는 것은 파일에 대한 커밋먼트, 즉 그 다이제스트입니다. 다이제스트는 고정 길이의 암호 지문입니다. 파일이 단 1바이트라도 바뀌면 다이제스트는 완전히 달라집니다. 바로 이 속성 덕분에 해시가 정확한 바이트를 대신하는 신뢰할 수 있는 대용물이 됩니다.

해시만 담은 증명은 다음과 같은 대상에 잘 맞습니다.

계약서와 송장;
릴리스 산출물과 빌드 매니페스트;
AI 산출물과 데이터셋 스냅샷;
정책 문서와 증거 패키지;
다른 시스템이 이미 산출한 체크섬.

이 증명은 파일 내용을 드러내지 않습니다. 드러내는 것은 해시, 사용자가 선택한 해시 알고리즘, 그리고 레코드에 포함하기로 정한 선택적 메타데이터뿐입니다. 어떤 필드가 체인에 올라가는지에 대한 자세한 내용은 블록체인에 올라가는 것을 참고하십시오.

게시하기 전에 무엇이 필요합니까?

게시에는 게이트웨이가 필요합니다. 검증에는 필요하지 않습니다.

검증은 전적으로 공개 체인 데이터에서 실행됩니다. 게시는 다릅니다. 무언가가 Cardano 트랜잭션을 빌드하고 제출해야 하고, 네트워크 수수료를 지불해야 하며, 확인을 처리해야 하고, 파일을 오프체인에 저장한다면 스토리지 비용도 지불해야 합니다. Label 309 게이트웨이는 이 모든 일을 수행하는 서비스입니다. 오픈소스 게이트웨이와 그 주변 도구는 게이트웨이에 종속되지 않으므로, 키를 보유한 게이트웨이를 도구가 가리키도록 지정하면 됩니다.

첫 증명을 위해 필요한 것은 다음과 같습니다.

파일 또는 미리 계산된 다이제스트;
Label 309 게이트웨이의 기본 URL;
해당 게이트웨이의 API 키 또는 단기 계정 토큰;
게이트웨이 계정의 충분한 잔액;
레코드에 서명하려는 경우, 선택적으로 신원 시드(Identity Seed).

호스팅형 CardanoWall 게이트웨이를 사용하면 CardanoWall이 게이트웨이 계정과 선불 잔액을 대신 운영합니다. 자체 게이트웨이를 운영한다면 Cardano 지갑과 스토리지 지갑에 직접 자금을 채웁니다. 어느 쪽이든 실제 수수료가 사용자를 대신해 지불되므로 게시에는 비용이 듭니다. 이는 게시에 가격이 붙는 이유에서 다루는 주제입니다.

왜 절차가 견적 먼저, 그다음 게시입니까?

게이트웨이는 조용히 게시한 뒤 청구서로 사용자를 놀라게 해서는 안 됩니다. 그래서 모든 게시는 동일한 2단계 형태를 따릅니다. 가격을 고정한 뒤 제출합니다.

레코드를 빌드하거나 추정합니다.
게이트웨이에 견적을 요청합니다.
견적 ID와 가격 내역(네트워크 수수료, 스토리지, 서비스 마진)을 받습니다.
그 견적으로 최종 레코드를 제출합니다.
트랜잭션이 아직 제출되는 중에도 게이트웨이 레코드 ID를 즉시 받습니다.
트랜잭션이 체인에서 확인될 때까지 상태를 추적합니다.
결과를 독립적으로 검증합니다.

견적은 제한된 시간 동안 가격을 고정합니다. 현재는 15분입니다. 게시하기 전에 만료되면 새 견적을 요청하면 됩니다. 환율이 움직였다면 가격이 달라질 수 있지만, 그 외에는 아무것도 바뀌지 않습니다.

이 2단계 패턴이 자동화를 안전하게 만듭니다. 스크립트는 견적을 기록하고, 자체 지출 정책을 적용한 다음에야 게시할 수 있습니다. 그래서 가격 급등이나 잘못 입력된 배치 작업이 잔액을 함부로 소진하는 일이 결코 일어나지 않습니다.

CLI로 파일 게시하기

로컬 파일의 경우 명령줄 흐름은 의도적으로 단순합니다.

cardanowall submit \
  --file ./contract.pdf \
  --base-url https://your-gateway.example \
  --api-key "$CARDANOWALL_API_KEY"

CLI는 파일을 해시하고, Label 309 레코드를 빌드하고, 게이트웨이에 견적과 게시를 요청한 뒤 결과를 출력합니다. --base-url과 --api-key는 CARDANOWALL_BASE_URL과 CARDANOWALL_API_KEY 환경 변수에서도 읽으므로, CI에서는 명령에서 생략할 수 있습니다.

반복 사용 시에는 매번 엔드포인트를 넘기는 대신 게이트웨이를 명명된 프로필로 저장하십시오.

cardanowall gateway add prod --base-url https://your-gateway.example
cardanowall gateway use prod
cardanowall submit --file ./contract.pdf

cardanowall 바이너리는 단일하고 자체 완결적인 네이티브 도구로, 설치할 런타임이 없습니다. cargo install cardanowall-cli로 crates.io에서 설치하거나(크레이트는 cardanowall-cli이고, 설치되는 명령은 cardanowall입니다), github.com/cardanowall의 오픈소스 저장소에서 빌드하십시오.

이미 가지고 있는 해시는 어떻게 게시합니까?

빌드 파이프라인, 컨테이너 레지스트리, 릴리스 프로세스, 데이터 아카이브에서 나온 다이제스트가 이미 존재하는 경우도 있습니다. 그럴 때는 파일을 다루지 않고 다이제스트를 직접 게시하십시오.

cardanowall submit --hash <64-hex-digest>

기본 해시 모드는 sha2-256입니다. 그 대신 다른 알고리즘이 필요하면 --alg blake2b-256을 넘기십시오. 레코드는 사용한 알고리즘을 기록하므로, 검증기는 나중에 다이제스트를 어떻게 다시 계산할지 알 수 있습니다.

미리 계산된 해시를 게시하는 것은 원본 파일이 너무 크거나, 너무 민감하거나, 너무 엄격하게 통제되어 범용 도구로 옮길 수 없을 때에도 올바른 선택입니다. 중요한 것은 단 하나, 정확한 바이트와 정확한 해싱 과정이 재현 가능하게 유지되는 것입니다. 그렇지 않으면 누구도 일치하는 다이제스트를 다시 계산할 수 없습니다.

레코드에 서명해야 합니까?

특정 Label 309 신원이 레코드를 보증했음을 증명하고 싶을 때 레코드에 서명하십시오.

해시만 담은 증명은 이렇게 말합니다. 이 바이트가 이 시점까지 존재했다. 서명된 증명은 여기에 이렇게 덧붙입니다. 그리고 이 서명 키가 바로 이 레코드를 뒷받침한다. 그 추가 주장은 회사 릴리스 레코드, 공식 아카이브, CI/CD 파이프라인, 법적 증거 워크플로, AI 출처 증명 로그, 그리고 오래 유지되는 모든 공개 게시자 신원에 중요합니다.

서명은 언제나 선택 사항입니다. 서명되지 않은 증명도 여전히 완전하고 온전히 검증 가능한 존재 증명입니다. Label 309는 설계상 발행자에 종속되지 않으며, 검증기는 게시자를 신뢰할 필요가 결코 없습니다. 서명은 다른 질문에 답할 뿐입니다. 누가 레코드를 보증하는가이지, 바이트가 존재했는지 여부가 아닙니다.

신원 시드는 게이트웨이로 절대 전송해서는 안 됩니다. CLI와 SDK는 서명이 로컬에서 일어나고 완성된 서명만 전송되도록 설계되어 있습니다. 명령줄 인수는 셸 히스토리, 프로세스 목록, CI 로그를 통해 새어 나가므로, 시드는 그냥 --seed 인수로 넘기지 말고 --seed-stdin이나 --seed-file로 공급하십시오.

cardanowall submit --file ./release-manifest.json --seed-stdin

파일을 첨부해야 합니까, 아니면 해시만 게시해야 합니까?

체인에 무엇을 커밋하는지에 따라 점점 커지는 순서로 세 가지 선택지가 있습니다.

해시만. 가장 작고 가장 사적인 증명입니다. 파일이 본인이 통제하는 어딘가에 보존될 것을 이미 알고 있을 때 이것으로 충분합니다. 레코드는 다이제스트만 담고, 검색에 관한 정보는 담지 않습니다.

해시와 콘텐츠 주소 지정 링크. ar://(Arweave)나 ipfs://(IPFS) URI를 첨부하면 검증기가 나중에 바이트를 가져올 수 있습니다. 가져온 바이트가 일치하는지는 여전히 해시가 결정합니다. 콘텐츠 주소 지정 URI는 바이트를 링크 자체에 묶으므로, 검증기는 올바른 파일을 가져왔는지 알기 위해 게이트웨이도, DNS도, TLS도 신뢰할 필요가 없습니다.

봉인. 파일을 암호화하고, 암호문을 오프체인에 저장하며, 봉인 봉투를 레코드에 넣습니다. 이는 기밀 레코드, 지정한 수신자에게 전달하는 경우, 그리고 로컬 사본을 잃었을 때 나중에 콘텐츠를 복구하려는 경우를 위한 경로입니다.

첫 증명은 해시만으로 시작하십시오. 서명, 오프체인 스토리지, Merkle 배칭, 봉인 전달은 실제 사용 사례가 요구할 때 추가하면 됩니다.

실제로 동작했는지 어떻게 압니까?

"게이트웨이가 수락했다"에서 멈추지 마십시오. 증명은 트랜잭션이 체인에 올라가 검증될 때 비로소 완성됩니다.

게시하면 게이트웨이는 레코드 ID를 곧바로 돌려주고, 트랜잭션 해시는 트랜잭션이 빌드되어 제출된 뒤 비동기로 채워집니다. 그러므로 게시 후에는 다음을 보관하십시오.

Cardano 트랜잭션 해시;
게이트웨이를 사용했다면 게이트웨이 레코드 ID;
원본 파일 또는 다이제스트;
서명했다면 서명 키의 공개 신원;
배치 처리했다면 Merkle 리프 목록이나 포함 증명;
증명이 봉인되어 있다면 복구 자료.

그런 다음 제3자라면 누구나 하는 방식 그대로, 게이트웨이 없이 공개 체인에서 트랜잭션을 검증하십시오.

cardanowall verify <tx-hash> --json

valid 판정이 결승선입니다. 다른 판정은 다음에 무엇을 해야 하는지 알려줍니다.

pending — 트랜잭션이 아직 충분히 깊게 확정되지 않았습니다. 확인을 더 기다린 뒤 다시 시도하십시오.
unverifiable — 레코드에는 결함이 없지만, 필요한 검사를 실행할 수 없었습니다. 데이터 소스, 오프체인 스토리지 가용성, 네트워크 정책을 확인하십시오.
failed — 실제로 레코드에 귀속되는 문제입니다. 레코드 자체를 조사하십시오.

failed와 unverifiable의 구분은 의도적입니다. failed는 레코드가 잘못되었다는 뜻이고, unverifiable은 검증기가 검사를 끝낼 수 없었다는 뜻입니다. 전체 검증 흐름은 Label 309 레코드 검증하기를 참고하십시오.

게시 후 UI는 무엇을 보여 줘야 합니까?

좋은 인터페이스는 "게시됨"이라는 단어 이상을 보여 줍니다. 첫 증명에서는 다음을 드러내십시오.

복사 버튼이 있는 짧은 트랜잭션 해시;
상세 보기의 전체 트랜잭션 해시;
해시 알고리즘과 다이제스트;
게시 상태;
확인되면 표시되는 블록 타임;
검증 판정;
레코드가 서명되었는지 여부;
파일이 첨부되거나 봉인되었는지 여부;
건너뛴 검사가 있는지 여부.

이렇게 하면 누구도 명세를 읽도록 강요하지 않고도 증명을 이해할 수 있습니다.

게시할 때 무엇이 잘못될 수 있습니까?

대부분의 게시 실패는 운영상의 문제이지 알 수 없는 일이 아닙니다. 계정 잔액이 부족할 수 있습니다. 견적이 만료되었을 수 있습니다. 레코드가 Cardano 트랜잭션에 비해 너무 클 수 있습니다. 업로드한 파일이 저장에 실패할 수 있습니다. Cardano 트랜잭션이 영구적으로 실패할 수 있는데, 이 경우 잘 만들어진 게이트웨이는 청구를 스스로 되돌리므로 체인에 올라간 만큼만 청구됩니다. 또는 게이트웨이의 자금이 채워진 지갑에 단순히 점검이 필요할 수도 있습니다.

진지한 게시 워크플로는 재시도를 멱등하게 처리합니다. 게이트웨이는 레코드의 정확한 바이트를 기준으로 게시 재시도를 중복 제거합니다. 동일한 레코드를 다시 제출하면 두 번 지불하는 대신 기존 결과를 반환하며, 업로드 배치에는 멱등성 키를 받아들여 다시 전달된 업로드가 재생에 안전하도록 합니다. 사용자 대면 제품에서는 첫 실제 고객이 네트워크 타임아웃을 겪기 전에, 그 이후가 아니라 미리 재시도 경로를 설계하십시오.

이를 파이프라인에 연결하고 있다면, 자동화에서 CLI 사용하기가 JSON 출력, 종료 코드, 안전한 비밀 처리에 대해 더 깊이 다룹니다.

첫 증명이 증명하지 못하는 것은 무엇입니까?

존재 증명은 무엇을 주장하는지에 대해 정밀하며, 이는 곧 무엇을 주장하지 않는지에 대해서도 정밀하다는 뜻입니다.

소유권을 증명하지는 않습니다.
작성자를 증명하지는 않습니다. 단, 서명하고 서명 키를 주장된 신원에 연결할 수 있다면 예외입니다.
파일이 진실하거나, 합법적이거나, 원본이라는 것을 증명하지는 않습니다.
파일을 어딘가 영속적인 곳에 저장하지 않는 한, 파일을 보존하지도 않습니다.

증명이 실제로 증명하는 것은 정확하고 영속적입니다. 커밋된 해시와 일치하는 바로 그 바이트가 트랜잭션의 블록 타임보다 늦지 않은 시점에 존재했다는 것, 그리고 모든 선택적 서명, 스토리지 검사, 봉인된 콘텐츠 검사가 검증기의 정책에 따라 검증되었다는 것입니다.

이것만으로도 진정으로 유용하며, 신뢰받기에 충분히 정밀합니다. 타임스탬프가 무엇을 입증할 수 있고 무엇을 입증할 수 없는지에 대한 더 온전한 경계는 증명이 증명하지 못하는 것을 참고하십시오.

더 읽을거리

Label 309 레코드 검증하기 — 신뢰가 필요 없고 계정도 필요 없는, 이 절차의 나머지 절반.
게시에 가격이 붙는 이유 — 수수료가 무엇에 쓰이는지.
자동화에서 CLI 사용하기 — JSON 출력, 종료 코드, CI의 비밀.
블록체인에 올라가는 것 — 레코드가 실제로 담는 필드.
개방형 표준과 참조 구현: label309.org와 github.com/cardanowall의 소스.