읽는 데 10분
CardanoWall 증명은 오프라인에서 동작합니까?
Label 309 레코드와 그 콘텐츠, 그리고 키가 기기에 동기화되고 나면 CardanoWall Desktop은 네트워크 없이도 이를 탐색하고 검색하고 복호화하고 검증할 수 있습니다. 다만 한 번도 캐시하지 않은 데이터를 가져올 수는 없습니다.

이미 기기에 있는 것이라면 동작합니다. Label 309 레코드와 그 콘텐츠 또는 암호문, 그리고 이를 열 키가 동기화되고 나면 CardanoWall Desktop은 네트워크 연결 없이도 이를 탐색하고 검색하고 복호화하고 검증할 수 있습니다. 할 수 없는 일은 한 번도 본 적 없는 데이터를 지어내는 것입니다. 동기화한 적 없는 트랜잭션이나 다운로드한 적 없는 암호문이 그렇습니다.
CardanoWall Desktop은 오프라인 우선으로 동작합니다. 눈앞 화면이 따르는 기준은 로컬 데이터베이스이며, 네트워크는 그 데이터베이스를 채워 넣는 백그라운드 동기화 장치입니다. 그래서 "오프라인"은 오류가 아니라 정상 모드입니다. 로컬 기기는 이미 내려받은 증명 세계의 일부를 담은 작업 사본이 됩니다.
바로 그 작업 사본 덕분에 증명이 현장에서 쓸모를 발휘합니다. 출장 중이거나, 감사나 법무 검토, 사고 대응 상황이거나, 연결이 불안정한 어디서든 마찬가지입니다. 탭이 서버에 닿지 못한다는 이유만으로 증명을 읽을 수 없게 되어서는 안 됩니다. CardanoWall Desktop은 오픈 소스입니다. 오픈 소스 Rust SDK 위에서 Rust와 Tauri로 만들었고, 코드는 github.com/cardanowall에 있습니다. 따라서 이 설명을 그저 믿는 대신, 동작 방식을 직접 읽어 확인할 수 있습니다.
동기화한 증명으로 오프라인에서 무엇을 할 수 있습니까?
데이터가 이미 로컬에 있는 한, 할 수 있는 일이 많습니다. 데이터가 로컬에 있다면 CardanoWall Desktop에서 다음을 할 수 있습니다.
- 동기화된 공개 Label 309 레코드를 탐색합니다.
- 콘텐츠 해시를 포함해 로컬 레코드 미러를 검색합니다.
- 시험 복호화로 이미 발견된 받은편지함 레코드를 봅니다.
- 캐시된 암호문을 엽니다.
- 봉인된 파일을 로컬 키로 복호화합니다.
- 로컬 파일에 대해 해시를 검증합니다.
- 캐시된 레코드의 구조를 확인합니다.
- 보낸 레코드 이력을 검토합니다.
- 나중에 게시할 초안을 준비합니다.
이는 캐시된 스크린샷이 아니라 실제 암호 연산입니다. 해시 검사, 서명 검사, 시험 복호화는 모두 디스크에 이미 있는 바이트를 대상으로 앱의 Rust 코어에서 로컬로 실행됩니다.
오프라인에서 할 수 없는 일은 무엇입니까?
오프라인 모드에는 분명한 한계가 있으며, 그 한계가 어디인지에 대해 솔직합니다. 앱은 한 번도 가지지 않았던 데이터를 만들어 낼 수 없습니다.
- 트랜잭션을 한 번도 동기화하지 않았다면, 네트워크나 그 메타데이터의 다른 로컬 사본 없이는 앱이 해당 트랜잭션의 존재를 알 수 없습니다.
- 암호문을 한 번도 다운로드하지 않았다면, 앱은 오프라인에서 이를 복호화할 수 없습니다.
- 레코드가 스토리지 URI를 가리키는데 그 바이트가 캐시되지 않았다면, 앱은 연결 없이 이를 가져올 수 없습니다.
- 새 증명을 게시하려 한다면 앱에는 게이트웨이와 네트워크가 필요합니다. 게시 가격을 책정하고, 업로드하고, Cardano 트랜잭션을 제출하고, 이를 확인해야 하기 때문입니다. (게시는 항상 게이트웨이를 거칩니다. 게시에 비용이 드는 이유를 참고하십시오.)
오프라인 우선은 앱이 빠진 데이터를 메워 줄 수 있다는 주장이 아닙니다. 데이터가 일단 로컬에 있으면 앱이 이를 일급으로 취급한다는 주장입니다.
앱은 무엇을 캐시하며, 각 계층은 얼마나 민감합니까?
민감도가 높아지는 순서로 네 계층이 있습니다.
공개 레코드 메타데이터. 데스크톱은 사용자가 설정한 게이트웨이로부터 봉인된 레코드와 공개 레코드를 아우르는 Label 309 레코드의 완전한 로컬 미러를 유지합니다. 각 레코드는 작아서(단일 트랜잭션의 메타데이터로, Cardano의 약 16 KB 메타데이터 한도보다 한참 아래로 제한됩니다), 수년간 많이 사용한 뒤에도 전체 글로벌 집합은 수백 메가바이트 수준에 머뭅니다. 이 미러는 검색, 받은편지함 발견, 보낸 레코드 추적, 오프라인 검사의 기반입니다. 여기에는 이미 체인상에 공개된 내용만 담기므로, 설계상 암호화하지 않고 저장합니다. 공개 데이터의 사본을 암호화해 봐야 얻을 것이 없기 때문입니다.
암호문. 봉인된 레코드는 콘텐츠 주소 지정 스토리지(ar:// 또는 ipfs://)를 통해 암호화된 페이로드를 참조합니다. 그 암호문을 캐시하는 것은 안전합니다. 이미 암호화되어 있고, 일치하는 키를 가진 사람만 열 수 있기 때문입니다. 데스크톱이 이를 캐시하므로 받은 파일을 다시 여는 작업은 즉시 이루어지고 오프라인에서도 동작합니다.
복호화된 콘텐츠. 이것이 민감한 계층이며, 앱은 이를 신중하게 다룹니다. 기본적으로 요청이 있을 때 메모리로 복호화하고, 평문을 디스크에 절대 쓰지 않습니다. 매번 다시 키를 풀지 않고도 즉시 미리 보기를 원하는 사용자를 위해 별도로 암호화된 복호화 파일 캐시를 선택적으로 둘 수 있지만, 이는 기본적으로 꺼져 있으며, 평문은 사용자가 명시적으로 저장을 선택할 때만 일반 위치에 기록됩니다. 복호화된 파일이 언제, 어디에, 어떻게 보호되어 보관되는지는 항상 알 수 있어야 합니다.
신원 자료. 신원 시드(Identity Seed)는 암호화된 볼트에 저장되며 로컬에서 잠금이 해제됩니다. 해당 신원이 잠금 해제되지 않은 상태에서도 봉인된 레코드는 미러에 공개 레코드로 나타날 수 있습니다. 다만 그 콘텐츠를 열 수 없을 뿐입니다. 시드 자체는 기기를 절대 떠나지 않으며 어떤 게이트웨이에도 도달하지 않습니다. (그 경계가 왜 중요한지는 키가 기기를 절대 떠나지 않는 이유를 참고하십시오.)
증명을 오프라인에서 검증할 수 있습니까?
검사에 필요한 입력을 갖추고 나면 검증할 수 있습니다. Label 309 검증은 공개 데이터만으로 실행되도록 설계되었으므로, 암호 검사는 CardanoWall의 서버에 전혀 의존하지 않습니다. 각 검사에 필요한 것은 다음과 같습니다.
- 해시 증명에는 레코드와 원본 바이트가 필요합니다. 검증기는 바이트로부터 해시를 다시 계산해 레코드에 커밋된 해시와 비교합니다. 완전히 오프라인입니다.
- 서명된 증명에는 레코드와 그 안에 포함된 서명이 필요합니다. 서명 키는 레코드의 서명 구조에 담겨 있거나 그로부터 해석되므로, 레코드가 로컬에 있으면 서명 검증이 오프라인으로 실행됩니다.
- 봉인된 증명에는 레코드, 암호문, 그리고 이를 여는 수신자 키(또는 패스프레이즈)가 필요합니다. 이들이 로컬에 있으면 앱은 복호화하고, 평문 해시를 다시 계산해 레코드의 커밋과 대조합니다. 이 단계가 암호화된 바이트를 타임스탬프된 클레임과 다시 묶어 줍니다.
- Merkle 증명에는 레코드의 루트와 포함 증명(또는 이를 재구성할 리프 목록)이 필요합니다. 그러면 포함 검사가 게이트웨이 없이 오프라인으로 실행됩니다. Merkle 트리를 구성하고 포함을 검증하는 것은 순수 계산입니다. 수천 개 파일을 위한 단 하나의 레코드를 참고하십시오.
보통 네트워크가 필요한 일은 아직 가지지 않은 데이터를 얻는 것과, 현재 체인 상태를 확인하는 것뿐입니다. 수학 자체는 로컬에서 실행됩니다. (전체 검증 모델은 Label 309 레코드를 검증하는 방법을 참고하십시오.)
오프라인일 때 블록체인 확인은 어떻게 됩니까?
증명의 타임스탬프와 확인 상태는 Cardano에서 비롯되며, 이는 앱이 체인에서 읽어 오는 사실입니다. 앱은 이를 절대 지어내지 않습니다.
앱이 이미 트랜잭션과 그 확인 깊이를 동기화했다면, 캐시된 그 상태를 오프라인에서 보여 줄 수 있습니다. 오프라인에서 할 수 없는 일은 새로운 확인, 체인 재구성, 또는 갱신된 어떤 맥락을 알아내는 것입니다. 그러려면 Cardano 탐색기에 질의해야 하기 때문입니다.
그래서 신중하게 설계된 클라이언트는 다음 상태를 구분해 둡니다.
- 캐시되어 로컬에서 검증된 레코드 데이터;
- 각 항목이 마지막으로 동기화된 시각;
- 마지막 동기화 시점 기준 확인 깊이;
- 아직 대기 중이거나 확인 임계값 미만인 레코드;
- 온라인에서 새로 다시 확인해야 하는 레코드.
오프라인 표시는 최신성에 대해 솔직해야 합니다. 지난주의 확인 깊이를 마치 현재 값인 것처럼 보여 주어서는 절대 안 됩니다.
오프라인 받은편지함 발견은 어떻게 동작합니까?
받은편지함은 레코드 미러와 잠금 해제된 신원이라는 두 가지로부터 로컬에서 계산됩니다. 게이트웨이는 의도적으로 수신자를 식별하지 않습니다. 어떤 봉인된 레코드가 "사용자의 것"인지 전혀 모릅니다. 그래서 자신의 메일을 찾는 일은 설계상 로컬 작업입니다.
앱이 봉인된 레코드를 동기화해 두었다면, 기기에서 바로 사용자의 신원에 대해 이를 시험 복호화합니다. 봉인된 슬롯마다 복호화를 시도하며, 사용자의 키로 열리는 것이 사용자의 메시지입니다. 사용자가 누구인지 어떤 서버에도 묻지 않습니다.
오래된 신원 시드를 가져오는 작업이 오프라인에서 깔끔하게 되는 것도 이 때문입니다. 일치 여부는 오로지 수신자 키가 결정하므로, 앱은 그 신원에 대해 이미 존재하는 로컬 미러를 다시 스캔하여 그 신원으로 향했던 더 오래된 봉인된 레코드를 드러냅니다. 다시 다운로드하지 않는 로컬 작업입니다. (사용자의 신원은 바로 그 시드입니다. 사용자의 신원은 시드입니다를 참고하십시오.)
미러가 불완전하면 받은편지함도 불완전할 수 있습니다. 네트워크가 돌아오면 앱은 빠진 레코드를 동기화하고 발견을 이어 갑니다.
왜 모든 것을 클라우드에만 두지 않습니까?
클라우드가 신뢰의 근원이 되어서는 안 되기 때문입니다. 호스팅 서비스는 편리합니다. 레코드를 게시하고, 피드를 제공하고, 가격을 처리하고, 인터페이스를 쉽게 만들 수 있습니다. 그러나 증명은 어느 한 서비스 계정보다 오래 살아남아야 하며, Label 309의 핵심은 검증에 공개 인프라만 있으면 된다는 점입니다. 바로 트랜잭션 메타데이터, 선택적으로 콘텐츠 바이트, 그리고 공개 Cardano 탐색기입니다. 사용자가 중요하게 여기는 레코드의 로컬 작업 사본은 그 독립성을 실천으로 구현한 것입니다.
그 로컬 사본은 단일 웹 세션이 너무 취약한 바로 그런 상황에서 제값을 합니다. 감사, 사고 대응, 법적 보존, 증거 검토, 저널리즘, 연구 아카이브, 규제 워크플로, 그리고 장기 보존이 그렇습니다.
팀은 오프라인 증명을 어떻게 활용해야 합니까?
네트워크 없이 무엇을 증명해야 할지 미리 정하고, 네트워크가 사라지기 전에 검증 자료를 동기화하고 캐시하십시오.
"무엇을 캐시할지"의 모양은 업무를 따릅니다.
- 법무 팀은 승인된 기기에 암호화된 증거 패키지를 캐시해 두고 싶을 수 있습니다.
- 컴플라이언스 팀은 감사 중에 매일의 증명 레코드와 포함 증명을 쓸 수 있도록 해 두고 싶을 수 있습니다.
- 릴리스 또는 DevSecOps 팀은 빌드 증명과 릴리스 매니페스트를 릴리스 아카이브와 함께 캐시해 두고 싶을 수 있습니다.
- AI 팀은 데이터셋 매니페스트와 모델 출력 커밋을 로컬에 미러링해 두고 싶을 수 있습니다.
규칙은 단순합니다. 오프라인에서 증명해야 할 가능성이 있다면, 연결이 사라지기 전에 그것을 동기화하고 그것을 증명하는 자료를 캐시하십시오. 봉인된 콘텐츠라면 관련 신원 시드가 백업되어 있고 정책에 따라 적절한 사람이나 기기에서 쓸 수 있는지도 확인하십시오. 그것이 없으면 암호문은 닫힌 채로 남습니다.
증명을 로컬에 보관할 때의 위험은 무엇입니까?
오프라인 접근은 일부 책임을 기기로 옮기며, 이 점을 분명히 해 둘 가치가 있습니다.
로컬 저장소 위험이 있습니다. 기기를 도난당하면 그 캐시가 문제입니다. 캐시된 암호문은 암호화되어 있어 키 없이는 열 수 없지만, 사용자가 보관하기로 선택한 복호화된 파일은 민감하며, 신원 볼트는 보호되어야 합니다. 운영 체제, 디스크 암호화, 사용자 계정, 패스프레이즈, 그리고 전반적인 기기 보안 모두가 신뢰 구조의 일부가 됩니다. CardanoWall Desktop은 암호화된 볼트, 자동 잠금, 메모리 내 키를 최대한 영점화하는 기능으로 노출을 줄이지만, 완전히 장악당해 잠금이 풀린 기기는 방어할 수 없습니다. 그리고 이를 분명하게 밝힙니다.
최신성 위험도 있습니다. 캐시된 증명은 마지막 동기화 시점 기준으로 유효하지만, 앱은 다시 연결되기 전까지 현재 체인 상태를 알 수 없습니다.
좋은 소프트웨어는 이런 경계를 눈에 보이게 합니다. 마지막 동기화 시각을 보여 주고, 캐시된 검증을 새로운 온라인 검사와 구분하며, 복호화된 평문을 안전하지 않은 위치에 조용히 쓰지 않습니다.
장기 증명을 위해 무엇을 보관해야 합니까?
수년간 중요한 증명이라면 트랜잭션 해시 이상을 보관하십시오. 증명 유형에 따라 다음을 의미합니다.
- 트랜잭션 참조;
- Label 309 레코드 바이트(또는 검증된 내보내기);
- 원본 파일 또는 평문;
- 봉인된 레코드의 경우 암호문;
- 복호화에 필요한 신원 시드 또는 수신자 비밀;
- Merkle 리프 목록 또는 포함 증명;
- 귀속에 필요한 서명이나 공개 키;
- 증명이 어떻게 생성되었고 어느 프로세스에 속하는지에 대한 짧은 메모.
블록체인은 공개 앵커를 제공합니다. 바로 이 정확한 바이트가 공개 블록 타임까지 존재했다는 사실입니다. 사용자의 로컬 아카이브는 그 앵커를 나중에 쓸모 있게 만드는 맥락을 보존합니다. (그리고 그 앵커가 무엇을 주장하고 무엇을 주장하지 않는지 기억하십시오. 증명이 증명하지 않는 것을 참고하십시오.)
요약
오프라인 증명은 마법이 아니라 준비입니다. 레코드, 콘텐츠, 암호문, 키, 그리고 포함 증명이 로컬에 있다면 암호 검사는 모두 로컬에서 실행됩니다. 무언가를 한 번도 동기화하거나 캐시하지 않았다면, 앱은 그것을 가져오기 위해 네트워크가 필요합니다. 그리고 앱은 그렇게 있는 척하는 대신 그 사실을 알려 줍니다.
CardanoWall Desktop은 그 로컬 작업 사본을 평범한 것으로 만듭니다. 레코드를 동기화하고, 봉인된 받은편지함 항목을 기기에서 발견하고, 암호화된 파일을 캐시하고, 증명을 검증하며, 네트워크가 사라져도 이미 동기화된 증거를 계속 쓸모 있게 유지합니다.
더 읽을거리
- CardanoWall Desktop — 이 글이 설명하는 오픈 소스 데스크톱 클라이언트.
- Label 309 레코드를 검증하는 방법 — 전체 검증 모델.
- 수천 개 파일을 위한 단 하나의 레코드 — Merkle 배칭, 게시를 제외하면 모두 오프라인.
- 증명이 증명하지 않는 것 — 타임스탬프된 존재 증명의 한계.
- 오픈 소스 코드, CLI, SDK: github.com/cardanowall.