보호된 콜드 서명
핵심 개념: 컴패니언 지갑은 보호된 거래를 구축하고 모니터링하는 데 필요한 모든 정보를 확인합니다. 하드웨어 지갑만이 지출을 승인할 권한을 보유합니다. 이 분리가 보호된 콜드 서명의 핵심입니다.
Zcash에서의 보호는 자금을 공개된 투명 주소에서 비공개 보호 주소로 이동시키고, Zcash의 프라이버시 기능을 사용해 거래 세부 정보를 숨기는 것을 포함합니다.
ZEC를 보호하면 무엇이 바뀌나요?
투명한 Zcash 거래에서는 다음과 같은 정보가:
블록체인에서 관찰될 수 있습니다.
ZEC를 보호하면 자금은 비공개 풀(예: Ironwood)로 이동합니다. 블록체인은 비공개 거래 세부 정보를 공개하지 않고도 거래의 유효성을 검증할 수 있습니다. 2026년 7월 28일 NU6.3 업그레이드 이후, 이전 Orchard 풀은 더 이상 신규 입금을 받지 않고 출금만 허용하므로 새로 보호된 자금은 Ironwood 풀로 들어갑니다.
보호된 거래의 구성 요소
1. 노트(보호된 잔액 기록)
노트는 사용자가 소유한 미사용 ZEC 금액을 나타내는 비공개 암호학적 기록입니다.
잔액이 평문으로 나열되는 공개 블록체인과 달리, 보호된 노트는 가치와 소유권 세부 정보를 암호화하므로 온체인 관찰자는 누가 자금을 소유하는지 볼 수 없습니다.
거래를 시작할 때 컴패니언 지갑은 원장을 스캔하고 사용자의 미사용 노트를 식별한 뒤 지출할 노트를 선택합니다.
2. 널리파이어(이중 지출 탐지 메커니즘)
노트의 세부 정보는 공개 원장에 숨겨져 있으므로, 네트워크에는 어떤 노트가 지출되는지 공개하지 않고 이중 지출을 탐지하는 메커니즘이 필요합니다.
널리파이어는 특정 노트에서 파생된 고유한 암호학적 표식입니다. 노트가 지출되면 해당 널리파이어가 블록체인에 게시됩니다.
네트워크는 널리파이어가 이전에 기록되지 않았는지 검증합니다. 기록되지 않았다면 지출이 승인될 수 있습니다. 중요한 점은 외부 관찰자가 널리파이어를 사용해 그것이 어떤 특정 노트에서 왔는지 알아낼 수 없다는 것입니다.
컴패니언 지갑은 거래 데이터를 조립하는 과정에서 적절한 널리파이어를 파생하고 구성합니다.
키
키는 자금에 대한 접근을 제어하고 지갑이 ZEC 수신, 조회, 지출과 같은 작업을 수행하도록 하는 암호학적 정보입니다.
지갑은 여러 서로 다른 키를 보유하며, 각각은 서로 다른 목적을 수행합니다. 이는 단일 계정이 읽기 접근과 쓰기 접근에 별도의 자격 증명을 둘 수 있는 것과 같습니다.
키는 컴패니언 지갑과 하드웨어 지갑의 관계에서 핵심입니다. 서로 다른 키가 서로 다른 목적을 수행하며, 그중 하나만 안전하게 보관하면 되기 때문입니다.
모든 보호 풀은 키를 파생 트리로 구성하며, 화살표는 구성 요소에서 그로부터 파생할 수 있는 항목을 가리킨다는 점을 아는 것이 중요합니다. 보호된 결제를 수신하려는 사용자는 지출 키에서 생성되는 보호 결제 주소를 보유해야 합니다.
키 계층 구조
1. 지출 키
이 키는 보안상 가장 민감한 키입니다. ZEC 지출을 승인할 암호학적 능력을 제공합니다.
이 보고서의 다른 부분에서 “하드웨어 지갑이 키를 보유한다”라고 언급할 때 가리키는 키가 바로 이것입니다.
콜드 서명 아키텍처에서 지출 키는 하드웨어 지갑 내부에 보관되며 컴패니언 지갑에 절대 노출되지 않습니다. 컴패니언 지갑은 이 키를 전혀 보유할 필요가 없습니다.
Sapling와 Orchard 모두에서 키 계층 구조는 루트 지출 키로부터 지출 권한과 조회 기능을 두 개의 구분된 분기로 파생합니다.
- Sapling: 확장 지출 키(𝑎𝑠𝑘,𝑛𝑠𝑘,𝑜𝑣𝑘)는 증명 승인 키(𝑎𝑘,𝑛𝑠𝑘)와 전체 조회 키(𝑎𝑘,𝑛𝑘,𝑜𝑣𝑘)를 파생하며, 이들은 다시 수신 조회 키(𝑖𝑣𝑘)와 다양화된 주소를 생성합니다.
- Orchard: 루트 지출 키(𝑠𝑘)는 지출 승인 키(𝑎𝑠𝑘)와 전체 조회 키(𝑎𝑘,𝑛𝑘,𝑟𝑖𝑣𝑘)로 직접 분기됩니다.
이 구조적 분리는 하드웨어 키 격리를 위한 공식적인 암호학적 토대를 제공합니다. 지갑은 잔액 동기화와 거래 구축을 위해 조회 분기(UFVK)를 호스트 컴퓨터로 내보내는 반면, 지출 승인 분기는 기기에 영구적으로 잠긴 상태로 유지됩니다.
키 파생은 엄격하게 단방향입니다. 즉, 조회 키를 역으로 계산해 지출 권한을 재구성할 수 없습니다. 이 암호학적 비가역성 덕분에 Unified Full Viewing Key(UFVK)를 내보내는 것은 안전합니다. 기기 내 지출 비밀을 노출하지 않고 완전한 지갑 가시성을 제공하기 때문입니다.
2. 조회 키
Zcash는 보호된 활동을 볼 수 있는 능력과 이를 지출할 수 있는 능력을 분리합니다. 조회 키는 지출 권한을 부여하지 않고도 지갑이나 기타 승인된 당사자가 보호된 거래 정보를 볼 수 있도록 합니다.
- Full Viewing Key (FVK), Unified Full Viewing Key (UFVK)로 래핑됨: 지출 키에서 의도적으로 파생되며, 소프트웨어가 지갑의 보호된 활동을 감지하고 복호화하여 거래를 식별할 수 있게 합니다. 또한 지출을 승인할 수는 없지만 잔액을 계산할 수 있게 합니다. 이는 시드의 약한 복사본이 아니라 지출 키에서 파생된, 프라이버시가 더 낮은 요소로 설명하는 것이 가장 적절합니다.
Full Viewing Key (FVK)는 엄격한 보안 분리를 유지하면서 완전한 읽기 전용 가시성을 제공합니다. 수신 및 발신 노트 암호문을 모두 복호화함으로써(발신 조회 키 구성 요소를 통해), FVK만 보유한 컴패니언 지갑은 단순한 누적 잔액이 아니라 완전하고 레이블이 지정된 거래 기록을 표시할 수 있습니다.
여러 개의 연결 불가능한 다양화된 결제 주소는 동일한 FVK 및 수신 조회 키(IVK)를 공유하므로, 블록체인 스캔 오버헤드를 늘리지 않고 무제한으로 주소를 생성할 수 있습니다.
이 기능적 분리는 콜드 서명 워크플로의 기반을 이룹니다. 지속적인 체인 스캔, 기록 추적 및 주소 관리는 모두 호스트 소프트웨어로 오프로드되고, 지출 권한은 하드웨어 기기에 격리된 채 유지됩니다.
핵심 구분: UFVK 대 지출 키
UFVK는 공유할 수 있습니다. 지출 키는 하드웨어 지갑에 남아 있어야 합니다.
컴패니언 지갑은 조회 키를 사용해 지갑을 모니터링하고, 수신 자금을 감지하며, 노트를 식별하고, 거래 준비를 돕습니다. 지출을 승인하는 데 필요한 개인 키는 보유하지 않습니다.
앞서 설명한 것처럼 키의 분리는 콜드 서명 아키텍처의 기반입니다.
컴패니언 지갑은 자금을 제어하지 않고도 거래 준비에 필요한 작업 대부분을 수행할 수 있습니다. 하드웨어 지갑은 준비된 거래를 수신하고 최종 서명 작업만 수행하면 됩니다.
하드웨어 지갑 제조업체가 이 분리를 직접 고안할 필요는 없습니다. Zcash의 키 설계는 이미 프로토콜 수준에서 조회 기능과 지출 권한을 분리하며, 제조업체는 이 기존 구조 위에 서명 및 내보내기 기능을 구축할 뿐입니다. 프로토콜은 보호 주소나 전체 조회 키 같은 정보를 지출 키에서 파생할 수 있게 하는 한편 지출 키 자체는 비공개로 유지합니다. 따라서 Ledger, Keystone 및 Hito 같은 하드웨어 지갑은 자금을 지출할 수 있는 개인 키를 절대 노출하지 않고도 컴패니언 소프트웨어에 필요한 조회 정보를 제공할 수 있습니다.
컴패니언 지갑이 실제로 키 정보를 사용하는 방식
조회 키 자료를 사용하여 컴패니언 지갑은 다음을 수행할 수 있습니다.
- 자금과 노트를 식별
- 어떤 노트를 지출할 수 있는지 판단
- 관련 주소를 파생하거나 식별
- 거래 구성
- 필요한 증명 생성 또는 조정
- 거래를 서명용으로 준비
거래를 구성해야 한다는 것은 개인 지출 키가 필요하다는 것과 다르다는 점을 아는 것이 중요합니다. 이러한 분리는 하드웨어 지갑 통합의 핵심 보안 개념 중 하나입니다.
보호된 거래 구성 및 승인
다음은 거래를 생성하고 승인하는 데 관련된 과정입니다. 간단히 말해, 이 과정들은 지갑이 해당 데이터를 사용해 실제로 자금을 보내는 방식입니다.
거래 구성(보호된 거래 조립)
거래 구성은 사용자가 의도한 결제에서 유효한 Zcash 거래를 만드는 데 필요한 정보를 조립하는 과정입니다.
거래 구성 과정은 선택된 노트, 수신자, 금액, 수수료, 널리파이어 및 기타 필요한 거래 데이터를 거래 구조로 결합합니다. 보호된 거래의 경우 필요한 영지식 증명과 서명을 생성하는 데 필요한 정보도 준비합니다.
일반적으로 컴패니언 지갑이 이 단계를 수행합니다. 컴패니언 지갑은 다음을 수행합니다.
- 지출할 노트 선택
- 거래의 입력과 출력 결정
- 필요한 값 계산
- 나중에 증명되고 서명될 거래 데이터 준비
콜드 서명 설정에서는 결과 거래 데이터를 PCZT로 패키징해 보안상 중요한 서명 단계를 위해 하드웨어 지갑에 전달할 수 있습니다.
증명(프로토콜 유효성 입증)
증명은 거래가 Zcash 프로토콜 규칙을 준수함을 보여주는 영지식 증명(예: Halo 2 또는 Groth16)을 생성하는 것을 의미합니다.
증명은 네트워크가 다음을 보장하도록 돕습니다.
- 지출 사용자가 노트를 지출할 권한이 있음
- 노트가 실제로 존재함
- 해당 널리파이어가 고유함
- 총입력이 총출력과 수수료의 합과 같음
이 모든 과정은 기초가 되는 비공개 세부 정보를 공개하지 않고 수행됩니다.
증명 생성은 계산 집약적입니다. 이 책임을 컴패니언 기기로 오프로드하면 하드웨어 지갑이 멈추거나 메모리가 부족해지는 것을 방지할 수 있습니다.
서명(지출 승인)
서명은 증명과 근본적으로 다릅니다. 디지털 서명은 개인 키 보유자가 생성하는 명시적인 승인 표식입니다.
영지식 증명이 거래의 유효성을 검증하는 반면, 디지털 서명은 지출 권한을 증명합니다. 서명은 실제 소유자가 특정 전송 매개변수를 승인했음을 인증합니다.
서명에는 최소한의 컴퓨팅 성능만 필요하므로 하드웨어 지갑에 이상적입니다.
보호된 콜드 서명이란 무엇인가요?
보호된 콜드 서명은 인터넷에 연결된 컴패니언 지갑에서 개인 지출 키를 격리된 상태로 유지하면서 Zcash 보호 거래를 승인하는 방법입니다. 거래는 온라인 컴퓨터에서 구성 및 준비할 수 있고, 오프라인 상태이거나 달리 격리된 별도의 하드웨어 지갑이 보호된 키를 사용하여 거래를 승인합니다.
과정은 다음과 같이 단순화할 수 있습니다.
컴패니언 지갑은 구조화된 거래 매개변수를 하드웨어 기기로 전송하고, 기기는 개인 지출 키를 호스트 장치로 절대 내보내지 않은 채 내부적으로 페이로드에 서명합니다.
컴패니언 지갑과 하드웨어 지갑
보호된 거래에는 컴패니언 지갑과 하드웨어 지갑이 모두 관여할 수 있으며, 각각은 구별되는 기능을 수행합니다.
컴패니언 지갑
컴패니언 지갑이란 무엇인가요?
컴패니언 지갑은 컴퓨터 또는 모바일 기기에서 실행되며, 다음과 같이 거래 생성에 관련된 대부분의 작업을 수행합니다.
- 지출할 노트 선택
- 거래 구성
- 필요한 거래 데이터 계산
- 필요한 영지식 증명 생성 조정
컴패니언 지갑은 왜 유용한가요?
컴패니언 지갑은 거래 생성 과정을 처리하지만, 컴퓨터가 악성코드에 감염되면 공격자는 다음을 할 수 있습니다.
- 사용자가 수행하는 작업 확인,
- 서명되지 않은 거래 수정,
- 무언가를 승인하도록 사용자를 속이려 시도.
컴패니언 지갑은 하드웨어 지갑에 저장된 개인 키에 접근할 필요가 없으므로, 하드웨어 지갑이 개인 키의 보안 경계를 제공하는 동안 거래 구성 및 기타 계산 작업을 처리할 수 있습니다.
하드웨어 지갑
하드웨어 지갑은 연결된 휴대전화나 컴퓨터로부터 개인 키를 격리하는 오프라인 물리적 기기로, 암호화폐 자산을 위한 안전한 금고처럼 작동합니다.
하드웨어 지갑은 왜 유용한가요?
컴퓨터가 악성코드에 감염되면 공격자는 다음을 할 수 있습니다.
- 사용자가 수행하는 작업 확인,
- 서명되지 않은 거래 수정,
- 무언가를 승인하도록 사용자를 속이려 시도.
개인 키는 하드웨어 지갑에서 단순히 추출할 수 없으므로, 기기는 보안 경계 역할을 할 수 있습니다.
컴패니언과 하드웨어 기능 이미지
이 두 지갑 사이의 분리는 보호된 거래에서 특히 중요합니다. 보호된 거래는 투명 거래보다 복잡하며 보호된 노트, 널리파이어, 커밋먼트, 영지식 증명, 거래 서명과 같은 구성 요소를 포함하기 때문입니다.
하드웨어 지갑이 모든 계산 작업을 수행하는 것은 비현실적입니다. 대신 컴패니언 지갑이 거래를 준비하고 서명에 필요한 정보를 하드웨어 지갑에 제공하며, 개인 지출 키는 하드웨어 기기 내부에 격리된 채 유지됩니다.
키 격리
키 격리란 지출을 승인할 수 있는 개인 키가 하드웨어 지갑을 절대 벗어나지 않음을 의미합니다. 컴패니언은 트랜잭션을 준비할 수는 있지만 서명할 수는 없습니다.
키 격리는 트랜잭션을 승인하는 데 필요한 개인 키를 컴패니언 지갑 및 해당 지갑이 실행되는 기기와 분리해 두는 것을 의미합니다. 실드 콜드 서명 설정에서 컴패니언 지갑은 트랜잭션을 구성하고 필요한 증명을 조율할 수 있지만, 하드웨어 지갑은 민감한 개인 지출 키를 격리된 상태로 유지합니다.
컴패니언 컴퓨터나 휴대폰이 손상되면 공격자는 서명되기 전의 트랜잭션과 상호작용할 수 있을 수 있지만, 이상적으로는 하드웨어 지갑에서 개인 키를 추출할 수 없습니다. 따라서 키는 하드웨어 기기의 보안 경계 내에 유지됩니다.
이러한 분리를 통해 컴패니언 지갑은 트랜잭션 승인을 위해 필요한 키 자료에 직접 접근하지 않고도 트랜잭션 구성 및 계산 작업을 수행할 수 있습니다.
여기서 핵심적으로 구분해야 할 점은 "조회 키"가 앱이 시드의 약화된 버전을 받는다는 뜻은 아니라는 것입니다.
Zcash에서 Full Viewing Key (FVK/UFVK)는 지출 키로부터 의도적으로 파생되며, 보유자가 관련 실드 활동을 탐지하고 복호화할 수 있게 하지만 지출을 승인할 수는 없게 합니다. FVK는 지출 키에서 파생된 덜 비밀스러운 값입니다.
한 가지 중요한 프라이버시 주의 사항:
따라서 앱은 UFVK만으로 자금을 탈취할 수는 없지만 지갑의 비공개 실드 활동을 볼 수 있다는 점을 알아야 합니다.
이것이 컴패니언 애플리케이션을 단순히 "공개 정보"를 가진다고 말하기보다 조회 권한을 가진다고 설명하는 편이 더 정확한 이유입니다.
전체 개념을 가장 간단히 말하면, 컴패니언 지갑은 지갑에서 무슨 일이 일어나는지 알기에 충분한 키 자료를 받지만 지갑 자금에 일어나는 일을 승인하기에 충분한 키 자료는 받지 않는다는 것입니다. 반면 하드웨어 지갑은 지출 권한을 격리해 두고 사용자가 트랜잭션을 승인할 때만 이를 사용합니다.
이것이 이러한 실드 Zcash 하드웨어 지갑 설계의 핵심 키 격리 모델이며, 곧 다룰 Ledger, Keystone 및 Hito에서도 구현별로 나타나는 동일한 모델입니다.
PCZT
PCZT는 부분 생성 Zcash 트랜잭션을 의미합니다. 이는 Zcash 트랜잭션과 이를 한 단계에서 다음 단계로 완료하는 데 필요한 정보를 담는 패키지입니다.
이는 트랜잭션이 아직 구축 중인 동안의 Zcash 트랜잭션을 위한 표준화된 형식입니다. 서로 다른 참여자나 기기가 트랜잭션 생성 과정의 서로 다른 부분을 수행하고, 부분적으로 완료된 트랜잭션을 서로 전달할 수 있게 합니다.
트랜잭션 구성은 Zcash와 같은 영지식 암호화폐 프로토콜에서 단순한 공개 전송에 서명하는 것보다 훨씬 복잡합니다. 실드 트랜잭션에는 Halo 2 또는 Groth16을 사용해 생성되는 것과 같은 계산 집약적인 영지식 증명이 필요합니다. 따라서 하드웨어 지갑과 같은 저전력 기기는 전체 트랜잭션 워크플로를 처리할 메모리와 처리 능력이 부족할 수 있습니다.
PCZT의 도입은 실드 암호화 아키텍처의 여러 핵심 과제를 해결합니다. PCZT는 트랜잭션 생성을 모듈식의 독립적인 역할로 나누는 표준화된 중간 데이터 형식입니다. 성능이 높은 컴패니언 컴퓨터가 트랜잭션 조립과 증명 생성을 처리하도록 하면서, 오프라인 하드웨어 지갑은 엄격히 승인과 서명으로 역할을 제한할 수 있습니다.
하드웨어 및 콜드 스토리지의 한계
하드웨어 지갑은 개인 지출 키를 보호하는 안전한 환경을 제공하지만, 일반적으로 컴패니언 컴퓨터에 비해 RAM, 컴퓨팅 성능 및 데이터 전송 기능이 제한적입니다. 이러한 제약으로 인해 계산 집약적인 영지식 증명 생성을 수행하거나 트랜잭션 구성 과정에서 필요한 전체 트랜잭션 상태를 유지하는 것은 비현실적입니다.
그 결과 컴패니언 지갑은 계산 부담이 큰 작업을 처리할 수 있고, 하드웨어 지갑은 보호된 지출 키로 트랜잭션을 승인하는 보안상 중요한 작업에 집중할 수 있습니다.
기기가 이렇게 제약되어 있다면, 신뢰할 수 있을 만큼 충분한 검증을 어떻게 수행하는지 궁금해집니다.
간단히 말하면, 하드웨어 지갑은 컴패니언 컴퓨터의 임의 값을 받아 서명할 수 없습니다. 서명되는 값이 사용자가 승인하려는 트랜잭션에 해당한다는 것을 확인할 수 있는 충분한 정보가 필요합니다. 이로 인해 어려운 균형 문제가 생기는데, 기기는 메모리, 연산, 펌웨어 크기 및 구현 복잡성에 대한 엄격한 제한 안에서 작동하면서도 서명 과정을 보호하기에 충분한 파싱과 검증을 수행해야 하기 때문입니다.
Ledger의 Orchard PCZT 처리는 이러한 과제의 한 사례로, 특수한 회로 종속 파싱이 제약된 기기에서 구현을 더 관리하기 쉽게 만들 수 있지만 지원되는 트랜잭션 구조나 회로가 발전할 때 펌웨어 변경도 필요할 수 있음을 시사합니다.
두 가지 진행 중인 노력은 이 동일한 제약에 대한 서로 다른 대응을 보여 줍니다.
오픈 소스 하드웨어 지갑 아키텍처와 일반 컴퓨터에 적합한 완전한 상수 시간 증명 파이프라인에 관한 연구 제안이 Grant #423에서 제시되었습니다. 목표는 C 또는 Rust와 같은 환경에서 안전하게 구현할 수 있으면서 실드 Zcash 지원의 복잡성과 유지보수 부담을 줄이는 암호화 인프라를 조사하는 것이었습니다.
한편 대안적 접근법은 저렴하고 쉽게 구할 수 있는 구성 요소로 제작된 오픈 소스 에어갭 서명기인 제안된 Zcash SeedSigner로 대표됩니다. 제안된 워크플로는 컴패니언 컴퓨터를 서명 기기와 분리하고, 기기 내 검증과 서명을 위해 PCZT를 에어갭을 넘어 전달합니다.
https://forum.zcashcommunity.com/t/grant-application-research-on-a-fully-constant-time-proving-pipeline-for-open-source-hardware-wallet-architectures-reusable-for-standard-computers/57555
이러한 접근법들은 함께 실드 하드웨어 지갑의 더 광범위한 엔지니어링 과제를 보여 줍니다. 트랜잭션 구성과 증명은 보안상 중요한 기기 외부에서 발생할 수 있지만, 서명기는 결과 트랜잭션을 안전하게 승인할 수 있는 충분한 정보와 검증 능력을 여전히 갖춰야 합니다.
PCZT가 분리 아키텍처를 가능하게 함
부분 생성 Zcash 트랜잭션(PCZT) 표준은 컴패니언 지갑과 하드웨어 지갑을 연결하는 공식 데이터 구조입니다.
컴패니언 지갑은 노트 선택, 널리파이어 계산 및 영지식 증명 생성을 모두 자체적으로 처리할 수 있습니다. 널리파이어를 파생하는 데 사용되는 키를 포함하여 이러한 단계에 필요한 정보는 지출 권한과 연결된 것이 아니라 조회 키에서 나오기 때문에 이것이 가능합니다. 이후 컴패니언 지갑은 이러한 요소를 PCZT 컨테이너에 패키징합니다.
PCZT는 하드웨어 지갑에 전달되고, 하드웨어 지갑은 트랜잭션 컨텍스트(예: 금액 및 수신자 주소)를 읽고, 보호된 지출 키를 사용해 서명을 적용한 뒤, 업데이트된 PCZT를 컴패니언 기기로 다시 전달합니다.
이 설계는 엄격한 보안 경계를 확립합니다. 성능이 높은 호스트 하드웨어는 지출 키에 접근할 필요 없이 복잡한 영지식 수학을 수행할 수 있으며, 저전력 콜드 스토리지 기기는 무거운 암호 연산을 계산할 필요 없이 금융 보안을 강제할 수 있습니다.
증명자의 프라이버시 절충
영지식 증명 생성을 컴패니언 지갑이나 다른 증명자에게 위임하면 지출 키는 격리되지만, 증명자는 여전히 노트 값, 수신자 주소 및 커밋먼트와 같은 민감한 트랜잭션 정보에 접근해야 합니다.
PCZT는 승인에 필요한 개인 지출 키를 전송하지 않고도 이 정보가 증명을 위해 제공될 수 있도록 보장함으로써 아키텍처적 분리를 유지합니다.
이는 증명 권한이 지출 권한과 분리됨을 보장합니다. 증명자는 사용자의 자금을 지출할 암호학적 권한을 얻지 않고도 계산 집약적인 증명 생성을 수행할 수 있습니다.
PCZT 상호운용성
PCZT가 Zcash 하드웨어 지갑, 다중서명 및 에어갭 서명 워크플로의 중요한 부분이 되면서, 독립적인 구현 간 상호운용성이 점점 더 중요해지고 있습니다.
AngryDavee의 2026년 6월 제안은 PCZT 구현이 Ledger, Keystone, Hito, OneKey 및 librustzcash의 참조 구현을 포함한 여러 프로젝트에 이미 존재한다고 언급했습니다. 그러나 이 제안은 이러한 구현이 PCZT를 일관되게 해석하는지 확인하기 위한 공유 테스트가 부족하다고 지적했습니다.
제안된 해결책은 표준 PCZT 테스트 벡터와 완전한 생성 → 서명 → 완료 워크플로를 다루는 구현 간 테스트를 포함하는 오픈 소스 상호운용성 테스트 모음이었습니다. 또한 서로 다른 서명자의 부분 서명 정보가 트랜잭션 완료 전에 결합될 수 있는 Combiner와 같은 역할 경계를 테스트하는 방안도 제안했습니다.
이는 하드웨어 지갑과 특히 관련이 있는데, PCZT는 트랜잭션 구성과 서명을 분리할 수 있게 하기 때문입니다. 컴패니언 지갑은 트랜잭션을 구성하고 PCZT를 준비할 수 있으며, 하드웨어 기기는 필요한 서명 정보를 받아 보안상 중요한 서명 작업을 수행합니다.
이 제안은 Zcash Community Grants가 제안을 검토하고 커뮤니티 피드백을 고려한 뒤 보조금을 진행하지 않기로 결정했기 때문에 구현되지 않았습니다. 그 결과 제안된 구현 간 테스트 모음은 이 보조금을 통해 개발되지 않았습니다. 따라서 이는 현재 Zcash 전반에 존재하는 표준이 아니라, 확인된 PCZT 상호운용성 과제에 대한 제안된 대응입니다.
https://forum.zcashcommunity.com/t/pczt-interoperability-test-suite-feedback-before-at-grant-submission/55931
PCZT의 수명 주기
| # | 단계 | 설명 |
|---|
| 1 | Creator | 트랜잭션 버전, 합의 브랜치 ID 및 풀 플래그를 포함한 전역 트랜잭션 메타데이터로 PCZT를 초기화합니다. |
| 2 | Constructor | 투명, Sapling, Orchard 또는 Ironwood 풀 전반에 걸쳐 의도한 입력과 출력을 트랜잭션에 채웁니다. |
| 3 | IO Finalizer | 입력과 출력 집합이 완료되었음을 선언하고, 바인딩 서명 키를 계산하며, 필요할 경우 더미 지출에 서명합니다. |
| 4 | Updater | 전체 조회 키, 앵커 및 Merkle 위트니스와 같이 후속 참여자에게 필요한 컨텍스트 데이터를 첨부합니다. |
| 5 | Prover and Signer | 영지식 증명 생성과 암호학적 서명을 실행합니다. 최신 PCZT 버전에서는 이 두 작업이 완전히 독립적이며 순차적으로 또는 병렬로 발생할 수 있습니다. |
| 6 | Combiner | 서로 다른 기기가 같은 트랜잭션의 측면을 동시에 작업할 경우 여러 PCZT 인스턴스를 결정론적으로 병합합니다. 병합 규칙은 우발적인 데이터 손실을 방지하기 위해 엄격한 충돌 해결을 요구합니다. |
| 7 | Spend Finalizer & Extractor | 필요한 모든 암호학적 요소를 검증하고 중간 컨텍스트 메타데이터를 제거하며 네트워크 브로드캐스트 준비가 된 최종 Zcash 트랜잭션을 생성합니다. |
실제 하드웨어 지갑 구현
한눈에 보기
| 기기 | 컴패니언이 받는 것 | 기기에 남는 것 | 전송 방식 |
|---|
| Ledger | UFVK / Orchard FVK, 주소 | 지출 권한 | USB / BLE |
| Keystone | UFVK + Unified Address | 시드 / 지출 키 | QR (에어갭) |
| Hito | UFVK, Unified Address, 시드 지문 | 시드 및 개인 지출 키 | QR / 로컬 |
여러 하드웨어 지갑 구현은 민감한 지출 키를 컴패니언 지갑에서 격리한 채 Zcash 실드 트랜잭션을 지원하는 방법을 탐색하기 위해 개발되었습니다. Ledger, Keystone 및 Hito은 하드웨어 기반 키 보호를 Zcash 트랜잭션 워크플로와 통합하는 서로 다른 접근법을 나타냅니다.
이들이 실드 자금을 어떻게 보호하는지 이해하려면 지출 키와 조회 키를 구분하는 것이 중요합니다. 세 가지 모두에서 분리는 같은 형태를 따릅니다.
| 기기 | 컴패니언 앱이 받을 수 있는 것 | 기기에서 보호된 채 유지되는 것 |
|---|
| Ledger | UFVK / Orchard FVK, 주소 및 공개 정보 | 지출 권한 / 개인 키 자료 |
| Keystone | UFVK + Unified Address | 시드 / 지출 키 |
| Hito | UFVK, Unified Address, 시드 지문 및 네트워크 정보 | 시드 및 개인 지출 키 |
하드웨어 서명 환경으로서의 Ledger
Ledger는 하드웨어 지갑 회사입니다. 이 회사의 기기는 개인 키 자료를 보관하고 기기의 나머지 부분 및 연결된 모든 것으로부터 물리적으로 격리하도록 설계된 전용 칩인 Secure Element를 중심으로 제작됩니다. 이 Secure Element야말로 Ledger 기기가 콜드 스토리지에 신뢰할 수 있는 이유의 전부입니다. 즉, 연결된 컴퓨터나 휴대폰이 손상되더라도 Secure Element 내부의 키는 추출될 수 없습니다.
하지만 Ledger 기기는 그 자체로 특정 암호화폐와 관련해서는 비어 있습니다. 해당 통화의 고유한 암호 방식을 처리할 줄 아는 애플리케이션이 설치되어야 합니다.
Ledger 기기는 특정 암호화폐와 관련해서는 비어 있으므로 해당 통화의 암호 방식을 이해하는 애플리케이션이 필요합니다. Zcash에는 두 세대가 있었습니다.
- 기존 Zondax 제작 “Zcash Shielded” 앱은 Zkool 같은 컴패니언 지갑과 함께 사용되었으며 2026년 11월 5일에 지원이 중단될 예정이고,
- Ledger의 더 새로운 Zcash 앱(3.9.4+)은 Ledger Wallet Desktop 4.21+에서 Ironwood 실드 ZEC에 네이티브로 사용됩니다.
아래의 키 격리 모델은 둘 다에 적용됩니다.
Zkool는 해당 앱과 통신하는 휴대폰 또는 컴퓨터의 컴패니언 지갑입니다. 트랜잭션을 구성하고 Ledger로 전송하면 기기의 Zondax 앱이 이를 서명하고 서명을 다시 보냅니다.
따라서 Zondax는 하드웨어에서 실행되는 소프트웨어이고, Zkool는 Zondax의 앱을 사용해 기기와 통신하며 그 외부에서 실행되는 소프트웨어입니다.
Ledger에서 나오는 것은 무엇인가?
Ledger의 Zcash 소프트웨어에는 지갑의 조회 키를 내보내는 특정 기능이 포함되어 있습니다. 이 키는 소프트웨어가 어떤 것도 지출할 수 없이 잔액과 트랜잭션을 볼 수 있게 해 줍니다.
이 기능은 다음 두 가지 중 하나를 반환할 수 있습니다.
- Unified Full Viewing Key (UFVK): Zcash의 모든 실드 풀을 한 번에 포괄하는 전체 조회 키, 또는
- Orchard Full Viewing Key (FVK)
어느 쪽이든 나오는 것은 오직 조회 키입니다. 어떤 버전을 요청하든 이 기능은 실제로 누군가가 자금을 이동할 수 있게 하는 유일한 정보인 지출 키를 반환할 방법이 없습니다.
이것이 바로 이러한 방식으로 구축된 핵심입니다. 컴패니언 앱에 안전하게 전달할 수 있는 것만 내보낼 수 있도록 설계되었습니다.
Zcash의 키 계층은 각 실드 풀에 대해 지출 키가 두 개의 별도 항목을 파생하도록 구성됩니다.
그런 다음 FVK는 자체적으로 추가 조회 관련 기능을 파생할 수 있지만, 어느 시점에서도 그 파생 경로가 지출 권한으로 되돌아가지는 않습니다. 키가 계층 구조의 조회 측으로 분기되면 그 상태에 머물며, 원래의 지출 권한 키를 재구성하는 데 사용할 수 없습니다.
Ironwood는 Orchard의 기반 키 및 노트 구성을 재사용하므로 동일한 패턴을 따릅니다. 하지만 합의 수준에서는 자체 커밋먼트 트리와 널리파이어 집합을 가진 별개의 풀입니다. 즉 UFVK는 하나의 평평한 키가 아니라 풀별 조회 키(투명, Sapling, Orchard 및 이제 Ironwood)의 묶음입니다.
Ironwood가 활성화되기 전에 내보낸 UFVK에는 그 풀이 아직 존재하지 않았으므로 Ironwood 조회 키가 포함되지 않습니다. 이것이 바로 지갑이 NU6.3 업그레이드 이후 Ironwood 기능의 UFVK를 인식하고 파생하도록 업데이트해야 했던 이유입니다.
Ledger에 남는 것은 무엇인가?
지출 권한은 기기에 유지됩니다.
Ledger Signer는 호스트에서 트랜잭션/PCZT를 받고 트랜잭션이 어느 풀에서 지출하는지에 따라 지출 승인 서명을 생성합니다(Ledger의 현재 통합이 Ironwood만 지원하므로 Ironwood 풀). 서명은 이후 기기에서 생성되며, 호스트는 개인 지출 키가 아니라 서명만 받습니다.
이는 Ledger의 일반적인 보안 모델과도 일치합니다. Secure Element는 개인 키 자료를 격리하며, Ledger의 애플리케이션 보안 요구 사항은 특히 애플리케이션이 이러한 비밀을 호스트에 노출하는 것을 금지합니다.
Ledger의 서명기는 독립적으로 트랜잭션 서명을 수행하면서 FVK/UFVK를 내보낼 수 있습니다. 두 기능은 하나로 묶이지 않고 별도의 기능을 통해 제공됩니다.
이것이 실제로 무엇을 의미할까?
Ledger에 10 ZEC가 있다고 가정해 보겠습니다.
컴패니언 지갑은 UFVK를 보유할 수 있으므로 "이 지갑은 10 ZEC를 받았다"는 것을 판단할 수 있습니다. 트랜잭션과 잔액을 스캔하고 표시할 수 있습니다.
하지만 누군가 컴패니언 지갑을 손상시키더라도 UFVK만으로는 지출 승인 서명을 생성할 수 없습니다.
별도의 지출 승인 서명의 목적은 하드웨어 지갑과 같은 제약된 기기가 전체 zk-SNARK 증명을 직접 수행하지 않고도 실드 지출을 승인할 수 있게 하는 것입니다.
Zondax Ledger 애플리케이션; 하드웨어 지갑 측면
Zondax란 무엇인가?
Zondax는 Ledger Zcash 앱을 구축한 제3자 개발 회사입니다. 이는 Ledger 하드웨어에서 실행되는 실제 펌웨어 애플리케이션으로, 기기가 처음부터 Zcash 트랜잭션을 이해하고 처리할 수 있는 능력을 제공합니다.
Zondax는 외부 개발자입니다. Ledger 하드웨어에는 Zcash 트랜잭션을 처리하는 선천적인 능력이 없으며, 이 기능은 전적으로 Zondax의 소프트웨어에서 나옵니다.
기존 Zcash Ledger 구현
Zondax의 Ledger Zcash 앱 저장소는 Ledger 기기에서 실행되는 소프트웨어입니다. 이 앱은 Orchard가 Zcash의 주요 실드 풀이 되기 전에 처음에는 Sapling 실드 트랜잭션에 집중했으므로, Sapling 지원은 Ledger 기기가 실드 ZEC로 할 수 있는 범위의 전부였습니다.
이 아키텍처는 호스트/컴패니언 측이 트랜잭션 정보를 준비하고 Ledger가 민감한 키 작업과 서명을 처리하는 분리를 보여 줍니다.
Zcash 하드웨어 지갑 지원의 가장 초기 버전에서도 호스트에서 구성과 증명을 수행하고 기기에서 서명을 격리하는 핵심 원칙은 이미 설계에 포함되어 있었습니다.
Orchard로의 발전
Ledger의 작업은 Orchard + PCZT 방향으로 옮겨갔습니다. Orchard는 다른 증명 시스템(Halo 2, Sapling의 Groth16 대비)과 다른 노트 및 키 구성을 사용하므로, 이는 사소한 업데이트가 아니라 의미 있는 전환이었습니다. 따라서 Sapling 전용 펌웨어를 확장하여 Orchard 서명을 처리하려면 단순한 펌웨어 패치가 아니라 기기 측에서 새로운 암호학적 기반 작업이 필요했습니다.
그러나 Zcash가 Ironwood로 나아감에 따라, Zondax와 Ledger는 이후 Ironwood에 맞게 다시 설계해야 할 Orchard 구현을 완성하는 대신 Ironwood를 직접 지원하는 쪽으로 개발 초점을 옮겼습니다. 이는 Ironwood가 Orchard 암호학 아키텍처를 기반으로 하면서 별도의 실드 풀과 추가 프로토콜 변경 사항을 도입함에 따라, Ledger 구현 발전의 한 단계 더 진전된 모습을 나타냅니다.
이 Ledger 앱 내부에서 일어나는 일
결과적인 흐름은 다음과 같이 설명됩니다.
- 호스트가 PCZT를 구성합니다.
- 호스트가 관련 트랜잭션 정보를 Ledger 기기로 전송합니다.
- 기기가 Orchard 지출 승인 서명을 생성합니다.
- 호스트가 바인딩 서명과 최종 트랜잭션 조립을 포함한 그 이후의 모든 작업을 처리합니다.
Ledger 내부에서 실행되는 앱은 지출 승인 서명 자체 외의 어떤 것도 보거나 생성하지 않으며, 계산량이 많거나 데이터 요구량이 큰 작업(증명, 바인딩, 조립)은 모두 호스트에 남습니다. 호스트는 키 자료를 신뢰받을 필요가 없습니다.
Ledger의 네이티브 실드 통합; Ledger Wallet Desktop
Ledger의 최신 Zcash 통합은 실드 트랜잭션 구성과 보안상 중요한 서명이 컴패니언 소프트웨어와 하드웨어 지갑 사이에서 어떻게 분리될 수 있는지에 대한 구체적인 사례를 제공합니다.
Ledger Wallet Desktop 4.21+ 및 Zcash 기기 앱 3.9.4+를 사용하면, 사용자는 Ledger Wallet Desktop을 통해 Ironwood 실드 ZEC를 직접 보내고 받을 수 있습니다. 이 통합은 비공개 간 전송, 투명 풀에서 실드화, 투명 풀로의 언실드화, 비공개 수신 주소 및 메모를 지원합니다. 트랜잭션은 컴퓨터에 표시되는 정보에만 의존하는 대신 Ledger 기기에서 검증되고 서명됩니다.
이 아키텍처의 핵심 부분은 조회 및 지출 기능의 분리입니다. 비공개 잔액 동기화 중 Ledger는 컴퓨터에 로컬로 저장되는 Unified Full Viewing Key (UFVK)를 내보냅니다. UFVK는 Ledger Wallet Desktop이 관련 실드 트랜잭션을 탐지하고 지갑 잔액을 판단할 수 있게 하지만, 자금을 지출할 권한은 제공하지 않습니다. 보안상 중요한 지출 권한은 최종 서명 작업을 수행하는 Ledger 기기에 유지됩니다. 이로써 지갑 상태를 관리하고 트랜잭션을 구성하는 컴퓨터와 지출 승인을 위한 기능을 보호하는 하드웨어 기기 사이에 명확한 경계가 생깁니다.
하지만 현재 통합은 구체적으로 Ironwood 전용입니다. Ledger Wallet Desktop을 통해 Orchard 또는 Sapling 자금을 표시하거나 관리하지 않습니다. 이는 역사적으로 중요한데, Ledger의 초기 Zcash 개발은 구현이 Ironwood 프로토콜 방향으로 발전하기 전 Orchard 실드 지원과 연관되어 있었기 때문입니다.
이 전환은 키 및 계정 호환성의 중요성도 강조합니다. Ledger에는 Zondax가 개발하고 YWallet 및 zkool과 같은 통합에서 사용했던, 현재 퇴역 중인 이전 “Zcash Shielded” 애플리케이션이 있습니다. 해당 이전 애플리케이션은 실드 계정에 다른 파생 방식을 사용했기 때문에, 그 Sapling 계정은 새 Ledger 애플리케이션에서 단순히 재현될 수 없습니다.
따라서 이 통합은 실드 하드웨어 지갑 지원의 진전과 남아 있는 한계를 모두 보여 줍니다. Ledger는 이제 컴패니언 소프트웨어가 지갑 동기화와 트랜잭션 준비를 처리하고 하드웨어 기기는 지출을 위한 보안 경계로 남는 완전한 Ironwood 경험을 제공할 수 있습니다.
동시에 과거 계정 호환성, 특정 실드 풀만의 지원, 하드웨어 트랜잭션 크기 제한, 플랫폼 제약, 그리고 실드 트랜잭션 파싱 및 검증에 수반되는 계산 및 펌웨어 제약은 Zcash의 하드웨어 지갑 지원이 프로토콜 기능뿐 아니라 각 개별 구현의 설계와 자원에도 좌우됨을 보여 줍니다.
Zkool + Ledger — 공식 Zondax 앱 사용
Ywallet의 후속인 Zkool는 실드 콜드 서명이라는 목표를 이어받았지만, 암호화만으로는 서명 앱을 안전하게 배포할 수 없으면 통합을 사용할 수 없다는 사실에 의해 직접 형성된 다른 경로를 택했습니다.
https://youtu.be/eagkCIv3BlQ?si=7w5YfLlRER77bASw
Zkool의 Zondax 애플리케이션 사용
Zkool는 Ywallet의 폐기된 독점 Ledger 애플리케이션 대신 Zondax가 개발한 공식 Ledger Zcash 앱을 사용하는 방향으로 옮겨갔습니다. Ledger의 스토어가 수용하지 않을 커스텀 앱을 유지하는 대신, Zkool는 이미 수용되어 Ledger 자체 생태계를 통해 배포되는 앱을 기반으로 구축했습니다.
이러한 전환으로 사용자는 이 통합을 사용하기 위해 서명되지 않은 커스텀 Ledger 애플리케이션을 설치하는 데 더 이상 의존할 필요가 없어졌습니다. Zondax의 앱은 Ledger 생태계를 통해 공식적으로 배포되었기 때문입니다.
하지만 이 통합은 Ledger가 기존 Zcash Shielded 앱을 단계적으로 폐지하면서 지원 종료가 예정된 2026년 11월 5일에 중요한 변화를 맞게 됩니다. Zkool의 Ledger 통합은 이 애플리케이션에 의존하므로, 이 변경은 기존 연결의 향후 이용 가능성에 관한 의문을 제기합니다. Zkool에 미칠 정확한 영향은 Ledger Wallet 외부에서 기존 앱을 계속 사용할 수 있는지, 또는 호환 가능한 대안으로 전환할 수 있는지에 달려 있습니다.
지원되는 실드 풀
Ywallet 개발자에 따르면, Zkool의 Ledger 통합은 Zondax가 개발한 공식 Ledger 애플리케이션을 사용했으며 투명 및 실드 Zcash를 모두 지원했습니다. 그러나 실드 지원은 Sapling로 제한되었고 Orchard는 지원하지 않았으며, 유형별 최대 5개의 입력과 출력, Ledger Live 호환성 부재 같은 다른 통합 제한도 있었습니다.
이 제한은 당시 기본 Zondax Ledger 구현의 범위를 반영한 것이었습니다. Zondax의 이전 Ledger 작업은 Sapling 지원을 제공했으며, 이후 2024년에 출시된 Zcash Shielded Ledger 앱은 처음에는 Orchard 및 Unified Addresses를 제외했습니다. 따라서 해당 애플리케이션을 중심으로 구축된 통합은 의존하던 하드웨어 지갑 구현의 기능과 한계를 그대로 물려받았습니다.
이후 2024년 11월 전용 Zcash Shielded Ledger App이 출시되며 상황이 발전했습니다. Zondax는 해당 애플리케이션이 Ledger Live를 통해 공식 출시되었다고 밝혔고, 이후 다른 지갑들이 이를 통합할 수 있도록 통합 가이드와 Rust 및 JavaScript 패키지를 공개했습니다. 하지만 출시 당시 이 애플리케이션은 Zecwallet Lite Desktop과만 통신했으며, 더 폭넓은 지갑 통합은 여전히 개발 중이었습니다.
다음 단계는 Ledger의 더 새로운 Rust 기반 Zcash 애플리케이션 개발이었습니다. 2026년 6월까지 Ledger는 UFVK 공유와 Orchard Unified Address 생성이 구현되었으며, Orchard 거래 서명 및 ClearSign는 여전히 개발 중이라고 보고했습니다. Ledger는 프로토콜이 변경됨에 따라 이 작업이 Ironwood 경로로 이어질 것이라고도 밝혔습니다.
이후 Ironwood는 Zcash 지갑 생태계 전반의 업데이트를 요구했습니다. Zkool는 버전 6.24.0부터 Orchard에서 Ironwood로의 마이그레이션 지원을 출시했으며, 이후 릴리스에서 마이그레이션 및 거래 파이프라인을 계속 개선했습니다. 한편 Ledger는 7월 27일 새 애플리케이션에 PCZT v2 서명을 병합했지만, 8월 20일 시점에는 구현이 Ledger의 검토와 Ledger Live 배포를 아직 완료하지 못했습니다. 이 이정표는 이후 출시되었으며, 현재 Ledger Wallet Desktop 4.21+는 기본 Ironwood 지원을 직접 제공합니다.
https://forum.zcashcommunity.com/t/a-path-forward-for-ledger-and-zcash/50951/177
따라서 이러한 발전은 단일 Zondax-에서-Ironwood 업그레이드가 아니라, 여러 관련 발전으로 이해하는 편이 더 정확합니다. 즉, 원래의 Sapling 중심 Zondax 구현, 2024년의 Zcash Shielded Ledger App, Orchard 및 PCZT 지원을 갖춘 더 새로운 Ledger Rust 애플리케이션, Ledger Wallet Desktop에서 이루어진 Ledger의 자체 기본 통합, 그리고 생태계가 Ironwood로 전환됨에 따라 Zkool 같은 지갑에서 병행된 업데이트입니다.
Zcash에 대한 현재 Ledger 기기 및 플랫폼 지원
Ledger에서의 Zcash 지원은 다음에 따라 달라집니다.
- 기기 모델
- 설치된 애플리케이션
- 이를 관리하는 데 사용되는 플랫폼 및
- 거래가 투명 거래인지 차폐 거래인지 여부.
2026년 7월 21일 기준(Ledger의 마지막 업데이트), Zcash Shielded 앱은 Nano S Plus, Stax 및 Flex에서 지원되지만 Nano X 또는 Nano Gen5에서는 아직 지원되지 않습니다.
Nano X 및 원래 Nano S을 제외한 다른 모델은 여전히 투명 거래와 차폐된 자금을 투명 주소로 지출하는 것(비차폐화)은 지원하지만, 차폐-대-차폐 서명은 지원하지 않는 클래식 Zcash 앱을 사용할 수 있습니다. 원래 Nano S은 어느 앱도 지원하지 않습니다. Ledger가 해당 기기에 대한 지원을 단계적으로 종료하고 있으며, 최신 Zcash 앱을 그 기기에서 사용할 수 없기 때문입니다. 기기는 Ledger Wallet(이전 명칭 Ledger Live)에 연결되며, 이는 Ledger의 동반 애플리케이션으로 데스크톱에서는 Windows, macOS 및 Linux에서, 모바일에서는 iOS 및 Android에서 사용할 수 있습니다.
Ledger는 별도 동반 지갑의 필요성을 없애는 Ironwood 풀 기반의 기본 차폐 Zcash을 Ledger Wallet Desktop에 추가했습니다. 다만 iOS 및 Android용 Ledger 모바일 앱에서는 아직 차폐 ZEC이 지원되지 않으며, 모바일 지원은 향후 릴리스에 계획되어 있습니다.
Ledger 자체 소프트웨어 외부에서 차폐 사용은 호환되는 동반 지갑과 그 지갑이 지원하는 플랫폼에 따라 달라집니다. Ledger가 계속 Ironwood 지원을 확대함에 따라 호환성은 기기 모델, 펌웨어, 앱 버전 및 운영체제에 좌우되므로, 일반적인 Zcash 지원이 반드시 호환성을 보장하는 것은 아닙니다.
https://www.youtube.com/watch?v=VhkhfG0LCFs
YWallet 콜드 서명: 이전 접근 방식
Ywallet는 Ledger 및 Zondax 모두와 별개인 동반 지갑으로, 차폐 콜드 서명을 향한 자체 경로를 추구했습니다.
Ywallet는 서명 기기를 온라인 지갑과 분리해 둘 수 있다는 의미의 Zcash 콜드 서명을 탐구했다는 점에서 역사적으로 중요합니다.
Ledger 하드웨어에서 이러한 구조를 구현하기 위해 Ywallet는 이전 절에서 다룬 Zondax 앱과는 구별되는 독점 앱인 자체 Ledger 애플리케이션을 구축했습니다. 즉, Ywallet는 Zondax의 기존 Sapling 구현에 의존하지 않았으며, 관계의 서명 측을 실행하는 자체 펌웨어를 보유하고 있었습니다.
이 통합이 중요했던 이유
암호화와 서명 코드를 갖추는 것만으로는 충분하지 않습니다. 하드웨어 지갑 통합은 순전히 암호학적 문제만이 아니라, 피할 수 없는 배포 및 플랫폼 문제이기도 합니다. 최소한 다음 사항이 포함됩니다.
- 애플리케이션 승인/배포 — 하드웨어 제조사의 공식 앱 스토어가 앱을 승인하고 배포할지 여부
- 펌웨어/애플리케이션 보안 — 앱이 키 자료 처리에 관한 제조사의 보안 요구사항을 충족하는지 여부
- 통신 프로토콜 — 동반 지갑과 기기가 실제로 거래 데이터를 교환하는 방식
- 지갑과의 호환성 — 서명 앱의 데이터 형식과 흐름이 동반 지갑의 기대와 일치하는지 여부
- 지원되는 차폐 풀 — 앱이 실제로 서명할 수 있는 Sapling, Orchard, (그리고 현재는 Ironwood)의 범위
Ywallet의 독점 Ledger 앱은 암호학적 및 구조적 요구사항을 충족했습니다. 차폐된 Zcash 거래에 서명할 수 있었지만, Ledger의 공식 앱 스토어에는 승인되지 않았습니다.
독점 Ledger 앱에서의 전환
앱이 공식적으로 승인되지 않았기 때문에, Ywallet는 사용자가 이를 사용하려면 서명되지 않은 펌웨어를 설치하도록 요청해야 했을 것입니다. 이는 사용자에게 실질적인 보안 저하이며, Ywallet는 사용자에게 이를 요구하지 않기로 했습니다. 그래서 Ywallet는 결국 그 경로를 택하기보다 해당 통합을 중단했습니다.
독점 앱을 되살리는 대신, 이후 개발은 Zkool(Ywallet의 후속 제품)를 통해 Zondax가 구축한 공식 Ledger 앱으로 옮겨갔습니다. 이는 맞춤형이지만 거부된 구현을 Ledger의 배포 생태계에서 이미 승인된 표준화된 구현으로 교체한 것입니다. 이 전환이 궁극적으로 작동하는 Ledger 통합을 다시 가능하게 했습니다.
Ywallet의 유산
Ywallet 자체가 활발한 개발에서 물러난 뒤에도, ZCG 구성원이기도 한 제작자 Hanh는 특히 Ironwood의 마이그레이션 과정에서 사라진 것처럼 보이는 자금에 관한 보고된 문제가 발생했을 때 생태계에서 중요한 목소리로 남았습니다.
ZODL: 실제 사용자가 Orchard → Ironwood 마이그레이션 후 자금 누락을 경험함
사용자 Jmo0615는 이전에 자신의 ZODL 지갑에서 보이던 자금이 Orchard-에서-Ironwood 마이그레이션 후 더는 나타나지 않는다고 보고했습니다. 이 사용자는 원래 시드를 복원하고, 지갑을 재설정 및 복구했으며, ZODL 버전 3.14.1 (1)이 완전히 동기화되도록 두었다고 밝혔습니다. 또한 관련된 Keystone 하드웨어 지갑이 없었다고 확인했습니다.
자금이 실제로 손실되었다는 사실은 확립되지 않았습니다. 오히려 이는 이전에 표시되던 자금이 Ironwood로 전환된 뒤 더 이상 표시되지 않게 된 지갑 검색 또는 마이그레이션 관련 문제로 추정됩니다. 감지되거나 표시되지 않는 자금을 자동으로 영구적으로 손실된 자금이라고 설명해서는 안 되며, 이 구분은 마이그레이션 문제를 이해하는 데 중요합니다.
https://forum.zcashcommunity.com/t/funds-not-showing-since-ironwood/57792
Zkool: "잠긴 노트"는 사용 불가능해 보이는 자금을 설명할 수 있음
차폐 지갑의 또 다른 중요한 측면은 지갑 상태가 사용자가 실제로 지출할 수 있는 자금에 영향을 줄 수 있다는 점입니다. Hanh는 사용자가 지출에 사용할 노트를 수동으로 선택할 수 있게 하는 기능인 코인 컨트롤을 통해 실수로 노트를 잠글 수 있다고 설명했습니다. 이 상황에서 노트는 여전히 지갑에 존재할 수 있지만 지출에는 사용할 수 없는 것으로 표시될 수 있습니다.
이는 지갑 문제를 조사할 때 중요한 구분을 강조합니다. 지갑에 존재하는 ZEC의 양은 현재 지출 가능한 양과 항상 같지는 않습니다. 노트 선택, 동기화, 마이그레이션 상태, 지갑 복구, 코인 컨트롤 설정과 같은 요소가 표시되거나 지출 가능한 잔액에 영향을 줄 수 있습니다. 따라서 “자금 누락” 보고는 감지되거나 표시되지 않는 자금, 감지되지만 지출할 수 없는 자금, 실제로 손실된 자금을 신중하게 구분해야 합니다.
https://youtube.com/shorts/eAOMRVYJFTA?si=xytBs-wZKn8hmu8D
2. Keystone
Keystone란 무엇인가요?
Keystone는 에어갭 하드웨어 지갑입니다. 서명 기기는 서명 과정 자체 동안 동반 앱과 직접적인 유선 또는 무선 연결이 없으며, 대신 QR 코드를 통해 통신합니다. 여기서는 현재 Zodl로 리브랜딩된 Zashi, 즉 Zcash 기본 동반 지갑과 함께 사용되며, 이 조합은 키 격리 원칙을 유난히 명확하고 쉽게 추적할 수 있게 합니다.
Keystone/Zashi 흐름
Keystone의 Zcash와 Zashi 통합은 이 분리를 특히 명확하게 보여 줍니다. Keystone를 Zashi에 연결하면 Unified Full Viewing Key가 Keystone에서 Zashi로 전송됩니다.
따라서 흐름은 다음과 같습니다.
Zashi는 UFVK로 무엇을 할 수 있나요?
Zashi는 이를 사용하여 다음을 할 수 있습니다.
- 수신된 차폐 거래 식별
- 잔액 확인
- 차폐 활동에 관한 정보 획득
하지만 UFVK를 보유하고 있다는 이유만으로 자금을 지출할 수는 없습니다.
UFVK는 잔액과 거래를 파악할 수 있게 하지만 지출은 허용하지 않는 "조회 기능"입니다.
Keystone 내부에 남는 것은 무엇인가요?
시드/지출 권한은 Keystone에 남아 있습니다. Zashi는 시드, 지출 키 또는 지출 승인 개인 키를 받지 않습니다. 조회 전용 운영에 필요한 UFVK, 주소 정보 및 정보를 받습니다.
이 두 부분을 함께 보면 전체 그림이 완성됩니다. UFVK, 주소, 조회 전용 정보처럼 기기 밖으로 나가는 것은 Zashi가 계정을 모니터링하기에 충분하지만, 기기를 떠나는 어떤 것도 자금을 외부로 옮기기에 충분하지 않습니다.
이것이 Zashi와 Keystone 통합이 차폐 콜드 스토리지를 제공할 수 있는 이유입니다. 지갑 애플리케이션은 계정에서 지출하는 데 필요한 권한을 보유하지 않고도 계정을 모니터링할 수 있습니다. 이 통합은 특히 차폐된 ZEC의 콜드 스토리지를 가능하게 하기 위해 출시되었습니다.
지출하려는 경우:
3. Hito
Hito는 Keystone와 매우 유사한 키 격리 모델을 따르지만 구현은 더 새롭습니다. Zashi 같은 기존 동반 지갑과 페어링하는 대신, Hito는 자체 Android 지갑과 함께 제공되며, 하드웨어 기기와 해당 Android 앱 간의 온보딩 과정은 Hito의 개발 이정표에 문서화되어 있습니다.
온보딩: Hito 앱이 받는 것
Android 지갑은 하드웨어 계정을 온보딩할 때 다음을 사용합니다.
- Unified Full Viewing Key (UFVK)
- Unified Address
- ZIP-32 시드 지문
- 네트워크 정보
Android 애플리케이션은 하드웨어 지갑의 시드 또는 개인 지출 키를 절대 받지 않는다는 점에 유의하세요.
Hito 앱은 무엇을 받나요?
문서화된 온보딩 정보에는 다음이 포함됩니다.
- UFVK
- Unified Address
- ZIP-32 시드 지문
- 네트워크
UFVK는 Android 지갑이 시드를 받지 않고도 조회 가능한 지갑으로 계정을 운영하는 데 필요한 정보를 제공합니다. 시드 지문은 시드에서 파생된 고정 길이 식별자로, 어느 계정이 어느 것인지를 인식하는 데 사용됩니다. 이는 시드 자체가 아니며 어떠한 지출 권한도 부여하지 않으므로, 그 존재는 위의 "시드를 절대 받지 않는다"는 주장과 모순되지 않습니다.
Hito에 남는 것은 무엇인가요?
실제 시드, 개인 지출 키 및 서명 권한은 하드웨어 기기에 남아 있습니다. 그 후 Hito는 오프라인으로 서명합니다.
현재 Hito 이정표는 전체 생성, 내보내기, 오프라인 서명 및 가져오기 워크플로가 작동하며, BLE 전송과 서명된 PCZT의 BBQr QR 내보내기를 제공한다고 명시합니다.
이 워크플로는 이 보고서 앞부분에서 다룬 완전한 주기의 구체적인 사례이므로 명시적으로 이름 붙일 가치가 있습니다. Android 지갑이 서명되지 않은 PCZT을 생성하여 Hito로 내보내고, Hito가 격리된 키 자료로 오프라인 서명한 후, 서명된 PCZT이 Android 지갑으로 다시 가져와집니다.
어느 시점에서도 시드나 지출 키는 어느 방향으로든 그 경계를 넘지 않습니다.
Orchard에서 Ironwood까지: 하드웨어 지갑 지원의 진화
Orchard는 Zcash 프로토콜의 실드 풀로, 사용자가 향상된 프라이버시로 ZEC를 보관하고 거래할 수 있게 합니다. 네트워크 업그레이드 5(NU5)에서 도입된 Orchard는 Halo 2 증명 시스템과 재설계된 암호학 아키텍처를 사용하여 발신자, 수신자, 금액과 같은 민감한 거래 정보를 드러내지 않고 실드 거래를 지원합니다.
Ironwood는 Zcash의 NU6.3 네트워크 업그레이드에서 Orchard 풀의 후속으로 도입된 실드 풀입니다. Orchard 암호학 프로토콜을 사용하면서 양자 복구 가능성과 공급 무결성에 대한 더 강력한 보장을 포함해 실드 자금의 장기적 보안을 개선하도록 설계된 변경 사항을 도입합니다.
처음부터 분명히 해둘 점은 Ironwood가 Orchard 프로토콜을 완전히 새로운 암호학 시스템으로 대체한 것은 아니라는 것입니다. Ironwood는 기존 Orchard 프로토콜을 기반으로 구축된 새로운 실드 풀로 도입되었습니다. 이는 두 풀이 동일한 Action 구조, 동일한 Halo 2 증명 시스템, 동일한 노트 및 키 구성을 가진다는 뜻입니다.
Ironwood에는 자체 노트 커밋먼트 트리, 널리파이어 세트, 앵커 및 가치 풀이 있으므로 합의 수준에서는 실질적으로 분리된 풀입니다. 하지만 암호학적으로는 재구축이 아니라 Orchard의 확장입니다.
이렇게 설계된 이유는 다음과 같습니다.
- 공급 무결성. 2026년 5월 29일, 보안 연구자 Taylor Hornby는 Orchard의 영지식 증명 시스템에 심각한 건전성 결함이 있음을 비공개로 공개했습니다. 이 결함은 온체인 흔적을 남기지 않고 위조된 ZEC를 생성할 수 있게 했을 수 있습니다. Orchard의 거래 데이터는 비공개이므로, 수정 전 위조된 ZEC가 생성되지 않았음을 누구도 독립적으로 검증할 수 없습니다. 이전 풀을 봉인하고 0에서 새 풀을 시작하는 방식은 Orchard를 제자리에서 패치하는 것으로는 해결할 수 없었던 이 문제를 해결합니다.
- 양자 복구 가능성 보장. Ironwood는 기반이 되는 이산 로그 가정이 언젠가 깨지더라도 해당 자금이 향후 복구 메커니즘에 참여할 수 있도록 설계되었습니다.
- 구현 변경 최소화. 완전히 새로운 실드 프로토콜을 설계하는 대신 Orchard의 검증된 아키텍처를 재사용했습니다. 즉, 새 거래, 증명, 지갑 및 하드웨어 지갑 코드를 처음부터 훨씬 적게 작성해도 되었습니다.
공개 타임라인
- 5월 29일: Orchard 취약점이 공개됩니다.
- 6월: 초기 수정 사항이 NU6.2를 통해 배포되는 동안 Orchard 거래가 일시적으로 제한됩니다. 6월 12일, 한 핵심 개발자는 전체 업그레이드 목표일을 7월 21일로 잡았으나 이후 일주일 연기됩니다. Keystone 보유자가 가장 마지막에 마이그레이션하게 될 것이라는 커뮤니티 우려가 제기되자, 핵심 개발자는 Keystone가 첫날부터 Ironwood를 지원할 것이며, 최종 서명 상수와 Zcash 코어의 Orchard API 변경을 전제로 펌웨어 목표일은 7월 3일이라고 답변했습니다.
- 7월 초: NU6.3가 테스트넷에 도달하고, Zebra 6.0.0이 7월 10일에 출시됩니다.
- 7월 27~28일: Ledger의 Ironwood PCZT v2 서명 작업이 통합 브랜치에 병합됩니다. Ironwood(NU6.3)는 7월 28일 블록 3,428,143에서 활성화되어, 원래의 Orchard 풀을 턴스타일 뒤에 봉인합니다. 이 턴스타일은 Orchard에서 빠져나갈 수 있는 ZEC의 양을 해당 풀에 정당하게 예치된 양으로 제한하며, 새 거래 형식을 도입합니다.
zcashd는 새 합의 규칙을 지원하지 않으므로 Zebra가 필수 노드가 됩니다. Ironwood가 Orchard의 수신자 구조를 재사용하므로 주소는 바뀌지 않으며, 지갑은 기존 주소를 자동으로 새 풀로 라우팅합니다. 다만 지갑에는 마이그레이션 기능이 필요합니다. Orchard 자금은 궁극적으로 소유자가 Ironwood로 옮겨야 하고, 이제 Orchard를 받는 새 출력은 합의에 의해 완전히 차단되기 때문입니다.
기술적으로 바뀐 점
거래 형식이 버전 5에서 버전 6으로 바뀌면서, 단일 거래가 기존 Sapling/Orchard/투명 구성 요소와 함께 Ironwood 구성 요소를 포함할 수 있게 되었습니다. PCZT도 이에 맞춰 확장되었습니다.
- 인코딩이 PCZT v1에서 v2로 변경되었습니다.
- 이제 별도의 Ironwood 번들이 Sapling 및 Orchard 번리와 나란히 위치합니다.
- v6 거래와 새로운 v6 sighash가 지원됩니다.
- 노트 평문에 새 버전(V3)이 추가되었습니다.
sighash 변경은 특히 하드웨어 지갑에 가장 중요합니다. v6에서는 Orchard 및 Ironwood 앵커가 서명 해시에서 제외되고 승인 데이터 다이제스트에만 반영됩니다. 이는 단순한 버전 상승이 아니라 실제 펌웨어 변경입니다. 기기는 새 sighash를 올바르게 구현하고, 컴패니언 앱이 승인한다고 주장하는 내용을 신뢰하는 대신 스스로 이를 재계산해야 합니다.
격리 계약 자체는 바뀌지 않았습니다. 기기는 여전히 지출 승인 서명만 반환하며, 절대로 alpha를 반환하지 않고 바인딩 서명도 생성하지 않습니다. 호스트는 여전히 증명과 그 밖의 모든 작업을 처리합니다.
다만 v6에서 서명자 규칙 하나는 바뀌었습니다. 더미 패딩 지출은 기기가 실제 노트 데이터와 대조해 검증할 방법이 없으므로 기기 대신 IO Finalizer가 서명합니다. 기기의 Signer 역할은 검증할 수 없는 것에 서명하라는 요청을 받는 대신 이를 건너뜁니다. 또한 v6 거래는 같은 거래에서 두 풀 중 어느 쪽에서도 지출할 수 있으므로, 표시되는 수수료는 이제 Orchard와 Ironwood 가치 잔액을 모두 합산합니다.
이 풀 회계를 올바르게 처리하는 일은 이론뿐 아니라 실무에서도 중요합니다. 최근 Brave 자체 Zcash 지갑에서 발생한 버그가 유용한 예시입니다. 수수료 계산이 모든 실드 입력이 레거시 Orchard 풀에 속한다고 가정하여, 거래에 실제로 Ironwood가 포함될 때마다 중복된 액션과 부정확한 수수료 추정이 발생했습니다. 이는 하드웨어 지갑 서명의 “호스트를 신뢰하지 말고 직접 재계산하라”는 원칙이 포착하기 위해 존재하는 바로 그 종류의 오류입니다. 컴패니언 지갑이 풀 회계를 잘못 처리했고, 기기가 자체 계산을 독립적으로 확인해야만 서명 전에 이를 표시할 수 있습니다.
각 서명자의 현황
Ledger가 판도를 완전히 바꿨습니다. 2026년 9월 23일, Ledger는 별도의 컴패니언 앱 없이 Ledger Wallet Desktop 내부에 네이티브 실드 Zcash 지원을 출시했습니다. 지출 키는 기기에 남아 있고, 컴퓨터가 거래 계산을 수행하며, 서명되기 전에 화면에서 모든 것을 승인합니다. 이는 기존 Orchard 또는 Sapling 풀이 아니라 Ironwood만 지원합니다. 단점은 Zondax가 구축했고 작동을 위해 Zkool 같은 컴패니언 지갑이 필요했던 레거시 “Zcash Shielded” 앱이 중단된다는 점입니다. Ledger는 11월 5일에 해당 구형 앱의 제공을 중단하므로, 아직 사용 중인 사람은 그 전에 자금을 옮겨야 합니다.
Keystone는 좋은 상태입니다. 펌웨어 3.0.2는 7월에 완전한 Ironwood 지원을 추가했으며, 지금도 이것이 현재의 안정적인 요구 사항입니다. 다만 무엇이든 서명하려면 이 버전 이상이 필요합니다.
Hito는 초기 테스트넷 이정표를 넘어 진전했습니다. 물리적 하드웨어에서 최초의 실제 Orchard-대-Ironwood 거래에 성공적으로 서명하고 제출했습니다(처음에는 테스트넷에서). 이후 업데이트에서는 프로덕션 하드웨어에서 메인넷 흐름(Ironwood→Ironwood, Ironwood→Transparent 및 기타)을 확인했습니다. 안정 펌웨어와 더 폭넓은 출시는 계속 진행 중입니다.
Zondax와 Zkool는 현재 변화 중입니다. Zondax의 앱은 Ledger에서 중단되는 앱입니다. 해당 앱을 통해 Ledger 기기와 통신했던 Zkool는 구형 앱이 사라진 뒤 그 역할이 어떻게 될지 밝히지 않았습니다. 앞으로 Ledger 사용자에게 계속 관련성이 있을지, 또는 향후에는 주로 다른 기기에 집중할지는 불분명합니다.
마이그레이션 자체가 가장 큰 파급 효과입니다. 풀 간 이동 금액은 공개되므로, 지갑은 한 번에 눈에 띄는 단일 잔액을 옮기는 대신 시간이 지남에 따라 표준 단위로 전송을 분산합니다. 이는 마이그레이션당 서명할 거래가 많아진다는 뜻이며, 하드웨어 지갑에서 일괄 PCZT 서명이 그토록 중요했던 이유입니다.
Ledger의 펌웨어 작업도 하드웨어 한계에 부딪혔습니다. 실제 노트 지출은 단일 명령에서 수만 건의 암호학 시스템 호출에 이를 수 있어 기기 워치독을 작동시킬 수 있었습니다. 이 문제를 해결하기 위해 필드 연산을 소프트웨어로 옮기고 Nano X의 스택 제약 내에 맞도록 공유 스크래치 상태가 필요했습니다.
https://forum.zcashcommunity.com/t/ironwood-is-here-updated-wallets-libraries-aug-20/56557/40
한 장의 그림으로 보는 진화
