증명을 만들면 블록체인에는 무엇이 올라갑니까?

CardanoWall로 증명을 만들면 Cardano에 올라가는 것은 파일이 아니라 작은 증명 레코드입니다. 일반 존재 증명에서는 이 레코드가 증명 대상이 되는 바로 그 바이트의 해시를 담습니다. 봉인된 증명에서는 여기에 암호화 봉투와, 다른 곳에 저장된 암호화 암호문을 가리키는 콘텐츠 주소 지정 링크까지 함께 담을 수 있습니다. 평문 파일 자체는 Cardano에 전혀 올라갈 필요가 없습니다.

바로 이 구분이 핵심입니다. 공개된 증명은 공개된 콘텐츠와 같지 않습니다. 문서에 대한 영구적이고 타임스탬프가 찍힌 약속을 만들면서도 문서 자체는 비공개로 유지할 수 있습니다.

이것이 CardanoWall이 구현하는 개방형 표준 Label 309의 모델입니다. 이 글의 나머지 부분에서는 각 증명 유형에서 정확히 무엇이 공개되는지 차근차근 짚어 봅니다.

해시 전용 증명에서는 무엇이 공개됩니까?

해시 전용 증명에서 공개되는 것은 레코드와 해시뿐입니다. 그 외에는 아무것도 없습니다.

이 레코드는 사실상 다음과 같이 말합니다. 누군가가 이 Cardano 블록 타임 시점에 바로 이 바이트에 약속했다. 해시는 그 바이트의 암호학적 지문입니다. 나중에 검증기는 원본 파일에서 동일한 해시를 다시 계산해 체인상의 해시와 일치하는지 확인할 수 있습니다.

체인을 읽는 사람은 누구나 다음을 볼 수 있습니다.

• Cardano 트랜잭션;
• 메타데이터 레이블 309;
• Label 309 레코드 바이트;
• 콘텐츠 해시(또는 여러 해시);
• 블록 타임과 확인 정보.

볼 수 없는 것은 파일 자체입니다. 다만 그 파일을 별도로 어딘가에 게시하는 경우는 예외입니다.

이것이 존재 증명이 비공개 문서, 데이터셋, 법적 자료, 컴플라이언스 로그, 내부 산출물에 잘 맞는 이유입니다. 콘텐츠를 드러내지 않으면서도 공개되고 타임스탬프가 찍힌 약속을 얻습니다. 이 개념이 처음이라면 존재 증명이란 무엇인가에서 기초를 다룹니다.

Cardano가 제 파일을 저장합니까?

아닙니다. CardanoWall의 일반적인 증명 모델에서는 그렇지 않습니다.

Cardano는 트랜잭션과 그 메타데이터를 저장합니다. Label 309에서는 이 메타데이터가 증명 레코드를 담으며, 레코드에는 해시, 선택적 스토리지 링크, 선택적 서명, 선택적 Merkle 루트, 선택적 암호화 봉투 데이터가 들어갈 수 있습니다. 파일 자체가 평문으로 Cardano 메타데이터에 업로드되는 일은 결코 없습니다.

확실한 기술적 이유도 있습니다. Cardano는 각 메타데이터 문자열을 64바이트로 제한하므로, 레코드 본문은 오직 전송을 위해 작은 청크로 나뉘었다가 누군가 읽기 전에 다시 합쳐집니다. 파일 하나는 결코 들어맞을 수 없습니다. 블록체인은 비공개 파일을 쏟아 붓는 곳이 아니라, 나중에 다른 사람이 검증할 수 있는 약속을 고정하는 곳입니다. 전체 동작 방식은 Label 309가 작동하는 방식을 참고하십시오.

파일을 첨부하면 어떻게 됩니까?

어떤 종류의 증명을 만드느냐에 따라 다릅니다. 모드는 세 가지입니다.

해시 전용. CardanoWall은 브라우저에서 파일을 해시하고 레코드에는 해시만 게시합니다. 원본 파일은 사용자에게 그대로 남고 기기를 절대 떠나지 않습니다.

스토리지 링크가 있는 공개 콘텐츠. 파일 바이트를 콘텐츠 주소 지정 스토리지에 두고, Label 309 레코드가 그 스토리지 위치를 참조합니다. 콘텐츠는 공개되며, 링크는 가져온 바이트를 레코드에 결속합니다.

봉인. 파일을 먼저 암호화합니다. 암호화된 페이로드는 Arweave나 IPFS 같은 콘텐츠 주소 지정 스토리지를 통해 저장되고, 레코드는 암호문을 참조하면서 올바른 키 보유자가 복호화하는 데 필요한 봉투 데이터를 담습니다.

모든 모드에서 증명은 곧 해시입니다. 스토리지는 사람들이 바이트를 가져오도록 돕기만 하고, 암호화는 누가 읽을 수 있는지를 통제하기만 합니다. 이는 해시, 서명, 봉인, 공유에서 설명한 것과 동일한 해시-서명-봉인-공유 진행 과정입니다.

봉인된 증명에서는 무엇이 공개됩니까?

봉인된 증명은 공개 약속이 붙은 비공개 콘텐츠입니다. 체인은 언제인지를 증명하고, 암호화는 누가 읽을 수 있는지를 통제합니다.

공개 레코드는 의도적으로 좁게 한정된 사실만 드러냅니다.

• 레코드가 봉인되었다는 사실(봉투가 존재한다는 것);
• 평문 해시;
• ar://...나 ipfs://... 같은 콘텐츠 주소 지정 암호문 링크;
• 암호화 봉투의 헤더;
• 수신자 슬롯에 사용된 키 캡슐화 계열 — 예를 들어 클래식인지 하이브리드 포스트 양자인지;
• 암호화된 키 슬롯의 개수;
• 레코드에 포함된 모든 서명;
• 트랜잭션 시각과 온체인 메타데이터.

공개 레코드가 드러내지 않는 것은 다음과 같습니다.

• 평문 파일;
• 복호화된 메시지;
• 읽을 수 있는 수신자 목록;
• 수신자의 개인 키;
• 발신자의 개인 키.

암호문은 한 가지 좁은 의미에서만 공개됩니다. 누구나 스토리지에서 내려받을 수 있다는 뜻입니다. 그러나 맞는 키가 없으면 읽을 수 없는 상태로 남습니다. 이것이 봉인된 레코드의 일반적인 패턴입니다. 증명은 공개되고, 콘텐츠는 암호화되며, 복호화는 수신자의 기기에서 로컬로 일어납니다.

수신자 주소가 체인에 기록됩니까?

아닙니다. 레코드 어디에도 읽을 수 있는 수신자 디렉터리는 없습니다.

Label 309 봉인된 레코드에서 수신자에게는 암호화된 키 슬롯을 통해 도달합니다. 수신자의 클라이언트는 공개된 봉인 레코드를 스캔하면서 각 슬롯을 자신의 개인 키로 조용히 열어 봅니다. 슬롯이 열리면 클라이언트는 페이로드를 복호화해 받은편지함에 레코드를 표시할 수 있습니다. 체인에는 "수신자: Alice"라고 적힌 필드나 공개 프로필을 지목하는 필드가 결코 실리지 않습니다. 수신자 관계는 게시되는 것이 아니라 로컬 복호화 성공을 통해 발견됩니다.

이 정보 노출을 더욱 줄이기 위해, 발신자는 게시 전에 안전한 난수 생성기로 슬롯의 순서를 섞습니다. 그래서 슬롯의 순서조차 누가 먼저인지에 대한 어떤 신호도 담지 않습니다. 체인이 노출하는 수신자 관련 사실은 슬롯이 몇 개인지뿐이며, 그 슬롯이 누구의 것인지는 결코 드러나지 않습니다.

바로 이 점이 이 설계를 대부분의 메시징 시스템과 구분합니다. 수신자가 자신의 레코드를 찾기 위해 서버가 수신자가 누구인지 알 필요가 없습니다. 봉인된 레코드를 받는 입장이라면 봉인된 레코드를 받는 방법에서 받은편지함 쪽을 설명합니다.

"봉인"이 익명을 뜻합니까?

아닙니다. 봉인이란 레코드 형식이 평문이나 읽을 수 있는 수신자 목록을 게시하지 않는다는 뜻입니다. 이것은 진정으로 유용하지만, 완전한 익명성과 같지는 않습니다.

주변의 여러 신호가 여전히 정보를 드러낼 수 있습니다.

• 트랜잭션 타이밍;
• 결제 흐름;
• 게이트웨이에서의 계정 활동;
• 네트워크 메타데이터;
• 브라우저나 기기 지문;
• 슬롯 개수의 반복되는 패턴;
• 발신자나 수신자의 운영상 실수.

민감한 작업에서는 이 경계를 신중하게 지키십시오. Label 309는 평문과 수신자를 공개 레코드 밖에 둘 수 있습니다. 그러나 주변의 네트워크, 결제, 기기, 사람의 절차에서 생기는 모든 흔적을 지울 수는 없습니다. 또한 봉인된 파일을 복호화한 수신자는 그 후 언제든 평문을 유출하기로 선택할 수 있습니다. 콘텐츠의 기밀성은 참여자의 익명성과 같지 않습니다.

레코드에 서명하면 무엇이 공개됩니까?

레코드에 서명이 포함되면 그 서명은 공개되며, 각 서명 뒤에 있는 키도 함께 공개됩니다.

Label 309 서명은 키가 레코드 본문을 보증하도록 합니다. 이는 회사, 창작자, 시스템, 신원이 어떤 증명을 뒷받침하고자 할 때 유용합니다. 그러나 서명은 공개 키도 노출하며, 서명 경로에 따라 지갑과 연결된 정보까지 노출할 수 있습니다. 공개 증명에서는 이것이 바로 원하는 바일 수 있습니다. 민감한 봉인 레코드에서는 대개 그렇지 않습니다.

이것이 서명이 선택 사항이고 결코 필수가 아닌 이유입니다. 해시 전용 레코드는 그 자체로 존재를 증명합니다. 봉인되고 서명되지 않은 레코드는 어떤 발신자 신원도 레코드에 결속하지 않을 수 있습니다. 서명된 레코드는 책임성이 목표일 때 책임성을 더합니다. 올바른 선택은 전적으로 워크플로에 달려 있습니다.

분명히 짚어 둘 한 가지 주의점이 있습니다. 검증된 서명은 어떤 키가 레코드 본문에 서명했다는 사실을 증명합니다. 그 키가 트랜잭션을 제출했거나 블록 타임을 정했다는 것을 증명하지는 않습니다. 동일한 본문은 누구나 다시 게시할 수 있기 때문입니다. 검증된 서명은 "이 키가 서명했다"로 읽어야지, "이 키가 이 시점에 게시했다"로 읽어서는 안 됩니다.

Merkle 증명에서는 무엇이 공개됩니까?

Merkle 증명은 단일 루트 약속 하나만 게시하며, 그 배치에 관한 다른 것은 아무것도 게시하지 않습니다.

수천 개의 해시를 Cardano 메타데이터에 직접 넣는 대신, 순서가 정해진 항목 목록으로 Merkle 트리를 만들어 32바이트짜리 루트 하나만 게시할 수 있습니다. 루트는 공개되고, 전체 항목 목록은 오프체인에 남습니다. 나중에 포함 증명을 가진 사람은 특정 항목 하나가 약속된 목록에 들어 있었다는 것을 보일 수 있으며, 그 증명은 공개 루트까지 거슬러 올라가 접혀 들어갑니다.

이는 모든 항목을 노출하지 않으면서 체인이 큰 배치에 약속해야 할 때마다 알맞은 도구입니다.

• 지속적 통합(CI) 및 릴리스 산출물;
• 일일 감사 로그;
• AI 콘텐츠 산출물과 데이터셋 매니페스트;
• 컴플라이언스 증거;
• 법적 증거 세트.

루트는 목록 전체에 대한 약속을 증명하고, 공개되지 않은 항목들은 아무것도 드러내지 않습니다. 절충점은 운영에 있습니다. 루트만으로는 오프체인 리프 목록과 포함 증명 자료를 복원할 수 없으므로, 조직이 이를 보존해야 합니다. 이 패턴은 수천 개 파일을 위한 하나의 레코드에서 깊이 있게 다룹니다.

CardanoWall이 제 봉인된 파일을 읽을 수 있습니까?

설계상 읽을 수 없습니다. 봉인과 복호화는 사용자의 기기에 머무는 키로 이루어지며, 게이트웨이는 봉인된 콘텐츠를 복호화하는 데 필요한 개인 키를 결코 받지 않도록 만들어졌습니다.

게이트웨이는 공개 레코드 데이터, 암호문, 견적 및 게시 메타데이터, 계정 활동, 스토리지 세부 정보를 봅니다. 증명을 게시하는 데 사용자의 신원 시드나 어떤 수신자의 개인 키도 필요하지 않으며, 그런 비밀은 게이트웨이로 결코 전송되지 않습니다.

다만 기밀성은 프로토콜만의 속성이 아닙니다. 손상된 기기, 악성 브라우저 확장, 피싱 사이트, 부주의한 백업, 평범한 운영상 실수가 여전히 비밀을 노출할 수 있습니다. 레코드 형식은 제대로 봉인된 파일을 게이트웨이가 읽지 못하게 유지할 수 있지만, 사용자가 넘겨준 키까지 보호할 수는 없습니다. 따라서 실질적인 조언은 변함없습니다. 신원 시드를 보호하고, 민감한 데이터의 경우 수신 주소를 별도 경로로 확인하며, 신뢰할 수 있는 소프트웨어를 사용하십시오. CardanoWall이 볼 수 있는 것에서 이 경계를 자세히 짚습니다.

해시 외에는 아무것도 저장하고 싶지 않다면 어떻게 합니까?

그렇다면 해시 전용 증명을 만드십시오. Label 309는 어떤 스토리지 링크도 요구하지 않으며, 해시 전용 레코드는 그 자체로 완전히 유효합니다. 원본 파일은 비공개로 보관하고 증명 레코드만 게시합니다.

이는 다음과 같은 경우에 흔히 알맞은 모델입니다.

• 비공개 계약서;
• 기밀 데이터셋;
• 내부 보고서;
• 민감한 법적 자료;
• 이미 비공개 저장소에 있는 소스 산출물;
• 공개 저장이 위험만 더하고 이점은 없는 모든 것.

절충점은 단순합니다. 해시는 영원히 존재하지만, 원본 파일을 잃어버리면 그에 일치하는 바이트를 더 이상 만들어 낼 수 없을 수 있으며, 일치하는 바이트가 없는 해시는 증명하는 바가 거의 없습니다. 특정 문서에서 그 위험이 중요하다면 봉인된 증명이 더 나은 선택입니다.

암호화된 파일을 보존하고 싶다면 어떻게 합니까?

그렇다면 봉인된 증명을 만드십시오. 봉인된 증명은 원본 바이트가 중요하고 나중에 복구해야 할 수 있는 경우를 위해 만들어졌습니다. 파일은 암호화되고, 암호문은 저장되거나 참조되며, 공개 레코드는 평문 해시에 약속합니다.

나중에 맞는 키를 가진 사람은 암호문을 복호화하고 그 평문이 온체인 약속과 일치함을 보일 수 있습니다. 이는 장기 증거, 민감한 레코드, 그리고 기밀로 유지되어야 하지만 사라져서는 안 되는 데이터에 적합합니다. 특정 사람들과 기밀로 공유해야 한다면 공개 파일 없이 기밀 공개하기가 실용적인 안내서입니다.

짧게 요약하면

• Cardano는 증명 레코드를 저장합니다. 파일은 저장하지 않습니다.
• 레코드는 해시, 서명, Merkle 루트, 암호화 봉투 데이터, 콘텐츠 주소 지정 링크를 담을 수 있습니다.
• 평문 파일은 Cardano에 올라갈 필요가 결코 없습니다.
• 봉인된 파일은 Cardano 밖에 암호문으로 존재하며, 나중에 온체인 평문 해시와 대조해 검증합니다.
• 수신자는 체인의 수신자 필드를 읽어서가 아니라 로컬 복호화로 발견됩니다.

이것이 한 줄로 요약한 개인정보 보호 모델입니다. 공개된 약속, 비공개 콘텐츠, 로컬 검증.

더 읽을거리

• 존재 증명이란 무엇인가와 Label 309가 작동하는 방식 — 증명 레코드의 기반.
• CardanoWall이 볼 수 있는 것과 증명이 증명하지 않는 것 — 솔직한 한계.
• 개방형 표준은 label309.org에, 소스 코드는 github.com/cardanowall에 있으며, CIP 편집자들이 검토 중인 Cardano 메타데이터 제안은 PR #1205에 있습니다.