해시, 서명, 봉인, 공유: CardanoWall 증명의 네 단계

CardanoWall 증명에는 네 개의 실용적인 단계가 있으며, 이 사다리를 어디까지 오를지는 직접 선택합니다.

• 해시는 특정 바이트가 공개된 시점에 존재했음을 증명합니다.
• 서명은 특정 신원이 레코드를 보증했다는 키 기반 클레임을 더합니다.
• 봉인은 원본 파일을 암호화하여 증명과 함께 비공개로 보존할 수 있게 합니다.
• 공유는 봉인된 파일을 특정 수신자를 위해 감싸므로, 수신자가 나중에 자기 키로 이를 발견하고 복호화할 수 있습니다.

각 단계는 그 아래 단계 위에 쌓이며, 이 모든 단계의 바탕에 있는 동일한 표준이 Label 309입니다. 이것이 CardanoWall이 무엇인지 이해하는 가장 간단한 방법입니다. CardanoWall은 블록체인에 해시를 올리는 곳에 그치지 않고, 레코드를 견고하고 비공개이며 검증 가능하게 만드는 층위적 방식입니다. 맨 처음에는 단순한 타임스탬프에서 출발해, 상황이 실제로 요구하는 보호만 더해 나갑니다.

1단계: 해시 — 특정 바이트가 특정 시점에 존재했음을 증명하기

첫 번째 단계는 고전적인 존재 증명입니다.

파일, 메시지, 데이터셋, 미디어 자산, 빌드 산출물, 보고서, 매니페스트를 대상으로 삼습니다. CardanoWall은 그 정확한 바이트의 암호학적 해시를 계산하고, 그 해시를 Label 309 레코드에 담아 Cardano에 게시합니다.

나중에 동일한 원본 바이트를 가진 사람은 누구나 해시를 다시 계산할 수 있습니다. 그 값이 레코드의 해시와 일치하면, 검증기는 해당 바이트가 트랜잭션의 블록 타임보다 늦지 않게 존재했음을 알게 됩니다. 이 검사는 공개된 Cardano 체인을 대상으로 실행됩니다. CardanoWall 계정이 필요 없고, 어떤 CardanoWall 서버도 신뢰하지 않습니다.

유용한 점은 파일 자체를 공개할 필요가 전혀 없다는 것입니다. 비공개 계약서, 데이터셋 스냅숏, 소프트웨어 릴리스 매니페스트, 법적 증거 묶음은 저마다 공개 증명을 가질 수 있습니다. 레코드는 이 바이트가 존재했다고 말합니다. 그 바이트를 보여 줄 필요는 없습니다.

해시 증명은 어디에 유용합니까?

해시 증명은 질문이 시점과 무결성에 관한 것일 때 강력합니다. 다음과 같은 물음에 답합니다.

• 이 정확한 파일이 마감 이전에 존재했습니까?
• 이것이 지난달에 타임스탬프를 찍은 그 PDF와 동일한 파일입니까?
• 이 릴리스 매니페스트가 사고 발생 이전에 이미 커밋되어 있었습니까?
• 이 데이터셋 스냅숏이 모델 학습에 쓰이기 이전에 존재했습니까?
• 이 미디어 파일이 편집되거나 분쟁이 일기 이전에 존재했습니까?

해시 증명은 효율적이기도 합니다. 수 기가바이트짜리 파일이 짧은 다이제스트 하나로 압축되고, 비공개 파일이 그 내용을 공개하지 않은 채 공개적인 약속이 됩니다.

한계도 그만큼 중요합니다. 해시는 누가 파일을 만들었는지, 파일이 참인지, 누가 소유하는지는 증명하지 않습니다. 해시는 정확한 바이트가 공개된 시점에 존재했음을 증명할 뿐, 그 이상은 아닙니다. 많은 업무 흐름에서는 이것으로 충분합니다. 그렇지 않은 경우를 위해 CardanoWall은 다음 층위를 더합니다.

2단계: 서명 — 레코드에 신원 키를 붙이기

두 번째 단계는 서명을 더합니다.

서명은 키가 레코드를 보증하도록 합니다. 바이트가 존재했다는 것만 증명하는 데 그치지 않고, 레코드는 특정 신원 키가 그 증명에 서명했음도 보일 수 있습니다. Label 309에서 이는 레코드 본문에 대한 선택적이고 분리된 COSE_Sign1 서명이며, 작성자 표시는 결코 필수가 아닙니다. 서명이 없는 레코드도 여전히 완전하고 온전히 검증 가능한 증명입니다.

이 선택지는 실질적인 의미를 바꿉니다. 개인 창작자에게 서명된 레코드는 작업 결과물을 창작자의 CardanoWall 신원과 연결할 수 있습니다. 기업에게는 승인된 키가 보고서, 릴리스 매니페스트, 컴플라이언스 스냅숏, 데이터셋 커밋을 뒷받침했음을 보일 수 있습니다. 자동화된 업무 흐름에서는 "누군가 이 파일에 타임스탬프를 찍었다"와 "우리 시스템이 절차의 일부로 이 레코드에 서명했다"를 구분해 줍니다.

서명은 해시를 대체하지 않습니다. 해시 위에 얹힙니다.

• 해시는 말합니다: 이 정확한 바이트가 존재했다.
• 서명은 말합니다: 이 키가 그 클레임을 담은 레코드에 서명했다.

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

서명은 강력하지만 만능은 아닙니다.

서명은 서명 시점에 키를 제어하고 있었음을 증명합니다. 서명 자체만으로는 그 키 뒤에 있는 사람이나 회사의 실제 신원을 증명하지는 않습니다. 그 신원은 맥락에서 나옵니다. 키가 어떻게 생성되었는지, 어떻게 공개되었는지, 조직이 그것을 어떻게 관리하는지, 그리고 다른 사람들이 그것을 어떻게 신뢰하게 되었는지에서 나옵니다.

또한 서명은 서명자가 트랜잭션 수수료를 냈거나 트랜잭션을 Cardano에 제출했음을 증명하지 않습니다. Label 309에서 서명은 레코드 본문을 덮을 뿐, Cardano 트랜잭션 전체를 덮지는 않습니다. 이는 의도된 설계이며, 레코드를 이식 가능하게 유지하는 핵심입니다. 게이트웨이, 자동화 시스템, 또는 임의의 제3자가 콘텐츠의 작성자가 되지 않고도 서명된 레코드를 게시할 수 있습니다. 검증된 서명은 "이 키가 서명했다"로 읽힐 뿐, 결코 "이 키가 트랜잭션을 제출했다"로 읽히지 않습니다.

쉽게 말해, 증명이 "이것이 존재했다"뿐 아니라 "이 신원이 증명을 뒷받침했다"까지 말하기를 원할 때 서명합니다.

3단계: 봉인 — 증명과 함께 암호화된 사본을 보존하기

세 번째 단계는 암호화된 보존을 더합니다.

해시만 담은 증명에는 한 가지 실용적인 약점이 있습니다. 검증기에는 여전히 원본 바이트가 필요하다는 점입니다. 파일을 잃어버리거나 단 한 바이트라도 바꾸면, 더는 레코드와 일치하는 콘텐츠를 만들어 낼 수 없습니다.

봉인은 파일을 암호화하고 그 암호화된 페이로드를 증명과 함께 Arweave나 IPFS 같은 콘텐츠 주소 지정 위치에 보관함으로써 이를 해결합니다. 온체인 레코드는 여전히 평문 해시에만 묶이며 — 암호문에는 결코 묶이지 않으므로 — 타임스탬프 클레임은 바뀌지 않습니다. 파일은 결코 평문 상태로 게시되지 않습니다. 올바른 키를 가진 사람은 누구나 나중에 암호문을 가져와 복호화하고, 평문 해시를 다시 계산하여, 이것이 레코드 뒤에 있는 그 파일임을 증명할 수 있습니다.

이로써 경험이 달라집니다. 해시만 담은 증명에서는 원본 파일을 직접 보관합니다. 봉인된 증명에서는 증명 업무 흐름 그 자체의 일부로 원본의 암호화된 사본을 보존할 수 있습니다.

봉인할 가치가 있는 경우는 언제입니까?

봉인은 원본 파일을 잃어버리면 증명이 약해질 만큼 그 파일이 중요할 때 의미가 있습니다. 다음을 떠올려 보십시오.

• 법적 증거 묶음과 서명된 계약서;
• 컴플라이언스 보고서와 민감한 사고 로그;
• 원본 창작 파일과 연구 데이터;
• 데이터셋 매니페스트, AI 프롬프트와 출력, 릴리스 산출물.

이 모든 경우에 해시는 유용하지만, 나중에 실제로 만들어 내야 할 수도 있는 것은 원본 바이트입니다. 봉인된 존재 증명은 타임스탬프를 공개로 유지하면서 그 바이트를 암호화된 상태로 보관하게 해 줍니다. 체인은 시간 흐름을 증명하고, 암호화는 콘텐츠를 보호합니다.

4단계: 공유 — 봉인된 파일을 특정 수신자에게 전달하기

네 번째 단계는 비공개 수신자 전달을 더합니다.

증명이 자신만을 위한 것이 아닐 때도 있습니다. 암호화된 증거를 변호사, 감사인, 파트너, 기자, 고객, 규제 기관, 또는 내부 팀에 보내야 할 수 있습니다.

수신자의 수신 주소를 알고 있다면, CardanoWall은 수신자가 나중에 자기 키로 열 수 있는 봉인된 레코드를 만들 수 있습니다. 그 레코드는 여전히 공개 타임스탬프를 가지며 여전히 평문 해시에 묶입니다. 여전히 암호화된 파일을 보존할 수 있습니다. 그런데 이제 그 암호화된 페이로드를 발신자뿐 아니라 특정 수신자가 열 수 있습니다. 이 지점에서 CardanoWall은 타임스탬프 도구라기보다 안전한 레코드 전달 시스템처럼 느껴지기 시작합니다.

공개 주소록 없이 비공개 전달은 어떻게 이루어집니까?

수신자 전달에는 체인상의 공개 주소록이 필요 없으며, 어떤 수신자의 공개 키도 레코드에 읽을 수 있는 필드로 기록되지 않습니다.

흐름은 이렇습니다. 수신자에게는 수신 주소가 있습니다. 발신자는 이를 대역 외 경로로 얻습니다. 수신자에게서 직접, 프로필에서, 회사 페이지에서, 또는 다른 신뢰할 수 있는 경로에서 얻습니다. 발신자가 봉인된 레코드를 만들 때, 봉투에는 의도된 수신자만 열 수 있는 수신자별 암호화 키 슬롯이 담깁니다.

받는 쪽에서는 수신자의 소프트웨어가 공개된 봉인 레코드를 훑으며 시험 복호화를 합니다. 각 슬롯을 자기 키로 로컬에서 시험 삼아 엽니다. 어떤 슬롯이 열리면, 그 레코드가 해당 수신자의 받은편지함에 나타납니다. 서버는 메시지를 결코 복호화하지 않으며, 수신자가 누구인지 알 필요도 없습니다. (수신자 측의 자세한 내용은 봉인된 레코드를 받는 방법을 참고하십시오.)

이것이 완벽한 익명성을 약속하지는 않습니다. 타이밍, 결제 흐름, 네트워크 메타데이터, 브라우저 동작, 운영상의 실수가 여전히 정보를 흘릴 수 있고, 수신자는 일단 복호화한 뒤에는 언제든 평문을 공유할 수 있습니다. 설계가 제공하는 것은 더 좁지만 실질적입니다. Label 309 레코드 자체는 평문도, 사람이 읽을 수 있는 수신자 목록도 게시하지 않습니다. 관찰자는 어떤 레코드가 봉인되었다는 것과 그것이 키 슬롯을 몇 개 담고 있는지만 볼 뿐, 누구를 향한 것인지는 결코 보지 못합니다.

포스트 양자 암호화가 공유 이야기에 속하는 이유는 무엇입니까?

봉인된 레코드는 아주 오래 존재할 수 있습니다. 암호화된 콘텐츠가 영구적으로 또는 준영구적으로 저장된다면, 공격자는 오늘 그것을 깰 필요가 없습니다. 지금 암호문을 저장해 두었다가 더 나은 하드웨어와 더 나은 암호 해독 기법으로 나중에 시도할 수 있습니다. 이것이 "지금 수집하고 나중에 복호화하기" 문제입니다.

그래서 Label 309는 알고리즘 민첩성을 진지하게 다룹니다. 수신 주소는 두 가지 형태로 제공됩니다. 클래식 X25519 주소와, X25519를 ML-KEM-768과 결합한 선택적 하이브리드 포스트 양자 주소(X-Wing 방식 구성)입니다. 하이브리드는 클래식 X25519 보안을 바닥으로 유지하면서 미래의 양자 공격자에 대한 저항성을 더하므로, 오늘의 암호학적 가정보다 오래 버텨야 할 콘텐츠에는 더 나은 기본값입니다. 요점은 영구적인 보안을 주장하는 것이 아니라 — 정직하다면 그 누구도 그럴 수 없습니다 — 오늘의 암호학적 안락함이 영원히 유지되리라 가정하는 증명 시스템을 설계하지 않는 데 있습니다.

사용자가 마주하는 버전은 단순합니다. 자신의 신원 시드(Identity Seed)를 보호하고, 수신자가 하이브리드 포스트 양자 수신 주소를 게시했다면 그것을 우선하며, 암호화는 소프트웨어에 맡기십시오.

네 단계는 어떻게 함께 작동합니까?

이 단계들은 별개의 제품이 아닙니다. 하나의 표준 위에 놓인 층위입니다.

• 타임스탬프만 필요할 때는 단순한 해시 증명을 게시합니다.
• 신원 키가 레코드를 보증하기를 원할 때는 서명을 더합니다.
• 정확한 원본 바이트를 보존하는 것이 중요할 때는 파일을 봉인합니다.
• 특정 수신자가 비공개 접근을 필요로 할 때는 봉인된 파일을 공유합니다.

동일한 바탕 표준이 이 모든 선택을 지원하기 때문에, 단순하게 시작했다가 상황이 요구할 때만 더 강한 층위로 손을 뻗을 수 있습니다.

어떤 단계를 사용해야 합니까?

• 해시는 원본 파일을 보관하기 쉽고, 유일한 질문이 그 바이트가 특정 시점에 존재했는지일 때.
• 서명은 키 기반 신원이 증명을 뒷받침하기를 원할 때.
• 봉인은 원본 바이트가 민감하거나 중요해서 증명과 함께 암호화된 사본을 보존할 가치가 있을 때.
• 공유는 다른 누군가가 암호화된 콘텐츠를 받아 나중에 검증해야 할 때.

이 네 가지를 가로지르는 다섯 번째 도구도 있습니다. 바로 Merkle 배칭으로, 하나씩 게시하기에는 해시가 너무 많을 때 쓰입니다. CI/CD 산출물, 일일 로그, 데이터셋 스냅숏, 생성된 미디어, 또는 수천 개의 항목을 단일 레코드와 루트 아래에 묶어야 하는 모든 업무 흐름이 그렇습니다.

이 증명들이 여전히 증명하지 못하는 것은 무엇입니까?

네 단계를 모두 갖추더라도, 존재 증명은 자신이 무엇을 주장하는지에 대해 정확함을 유지합니다.

존재 증명은 정확한 바이트가 존재했음, 어떤 키가 레코드에 서명했음, 암호화된 콘텐츠가 보존되었음, 콘텐츠가 특정 키에 전달되었음을, 그리고 — Merkle 루트와 함께라면 — 어떤 항목이 커밋된 배치에 속했음을 증명할 수 있습니다.

그러나 존재 증명만으로는 콘텐츠가 참인지, 누군가 법적 소유권을 가졌는지, 데이터셋이 합법적으로 수집되었는지, 허술한 절차가 건전한지는 증명하지 않습니다. 그 경계에 대한 자세한 내용은 증명이 증명하지 못하는 것을 참고하십시오. CardanoWall은 견고한 증명 층위를 제공하지만, 그 증명을 둘러싼 비즈니스 절차는 여전히 중요합니다.

짧게 정리하면

• 해시는 타임스탬프입니다.
• 서명은 신원 클레임입니다.
• 봉인은 암호화된 보존입니다.
• 공유는 비공개 전달입니다.

이 네 가지가 함께 작동하면, 존재 증명은 체인 위의 단순한 해시에서 파일, 데이터셋, 증거, 소프트웨어 릴리스, AI 출력, 기밀 레코드를 위한 실용적인 업무 흐름으로 바뀝니다. 그리고 Label 309는 오픈 소스 도구를 갖춘 개방형 표준이므로, 동일한 네 단계가 웹사이트를 통해서든, CLI를 통해서든, 다른 누군가의 구현을 통해서든 작동합니다.

더 읽을거리

• 존재 증명이란 무엇입니까? — 해시 단계를 깊이 있게 다룹니다.
• 봉인된 레코드를 받는 방법 — "공유"의 수신자 측 이야기.
• 수천 개 파일을 위한 하나의 레코드 — 네 단계를 가로지르는 Merkle 배칭.
• 증명이 증명하지 못하는 것 — 염두에 둘 한계.
• Label 309 — Cardano CIP 절차에 제안되어 CIP 편집자들의 검토를 받고 있는 개방형 표준(PR #1205).
• github.com/cardanowall — 오픈 소스 SDK와 cardanowall CLI.