모네로 view key: 읽기 전용 지갑이 보는 것과 못 보는 것 (2026)
view key는 모든 입금과 발행한 모든 서브주소를 복호화하지만 1 piconero도 옮길 수 없습니다. 키 대수를 다시 구현해 모네로 공식 테스트 벡터로 검증하고, 감사자에게 무엇을 넘기고 넘기지 말아야 하는지 정리했습니다.
view key는 모네로 지갑의 '읽기 전용 절반'이며, 암호화폐 회계에서 가장 흔히 과다 공유되는 비밀입니다. 표준 모네로 주소는 95자 안에 두 개의 공개키를 담습니다: spend 공개키 B와 view 공개키 A. A의 개인키가 view key a, 32바이트이며 보통 64자리 16진수로 씁니다. a만 있으면 그 지갑으로 들어온 모든 전송을 복호화해 금액을 읽을 수 있고, a만으로는 1 piconero도 옮길 수 없습니다. 이 비대칭이 회계·감사·자금팀이 view key를 요구하는 이유이며, 선의가 아니라 규칙이 필요한 이유입니다.
이 대수는 그대로 옮긴 것이 아니라 다시 구현해 확인했습니다. 지갑은 저장되는 것이 아니라 유도됩니다: spend 비밀 b = Hs(seed), view 비밀 a = Hs(b), 주소는 varint(18) || B || A || keccak256(keccak256(varint(18) || B || A))의 앞 4바이트를 base58로 인코딩한 것입니다. 아래 주장을 검증하려고 이 파이프라인을 다시 만들었습니다. Keccak-256은 표준 벡터(빈 입력은 c5d24601...)와 일치합니다. base58 인코더는 모네로 공식 tests/unit_tests/base58.cpp의 블록 벡터 14개를 모두 통과했고, 8바이트 FF..FF가 jpXCZedGfVQ가 되어야 하는 케이스와 선행 0 두 케이스도 포함됩니다. 종단 검증으로, 모네로 지갑 직렬화 테스트에 하드코딩된 두 공개키 쌍을 테스트넷 접두사 53으로 다시 인코딩하면 9svHk1wHPo3...과 9y52S6PH8tz...가 나오며, 이는 모네로가 그 지갑 파일을 명명할 때 쓰는 앞 6자와 같습니다. (모네로 확인 대기)
view key로 실제 무엇을 얻는가. 새 시드에서 메인넷 주소를 유도했습니다: 49DEK2pVdZBTkmY4yYkxs5EXMG45X83RygMDVi34zxC6HHDKMgKN4wrBv2xBs5oyamEu4Vy5RzZ3XU9Sn8XRVSrNGRzc1Um, 95자, 접두사 18. view key는 8b2f295c...5a05입니다. 두 가지 능력이 따라옵니다. 첫째, 모든 거래는 tx 공개키 R을 공개합니다. 지갑은 거래마다 공유 비밀 aR을 한 번 계산하고, 출력 인덱스 i마다 Hi = Hs(aR || i)를 구해 P' = Hi*G + B를 만들고 온체인 출력 키와 비교합니다. 일치하면 '내 출력'이고, 같은 공유 비밀이 금액을 복호화합니다. 둘째, 서브주소는 view key만으로 유도됩니다: m = Hs('SubAddr' || a || major || minor), D = B + mG, C = a*D. a와 공개된 B만으로 (0,1), (0,2), (0,3) 서브주소 — 84Y1S91V..., 82b5J7zr..., 88shGQ6Z... — 를 만들었습니다. 각 95자, 모두 8로 시작(접두사 42)하며 spend 키는 건드리지 않았습니다.
그리고 그것이 곧 리스크입니다. view key는 '읽기 전용이니 무해'가 아닙니다. 지갑이 존재하는 동안의 모든 입금 — 과거와 미래, 정확한 금액과 시각 — 을 드러내고, 서브주소가 같은 대수에서 나오므로 지금까지 발행한 모든 청구 주소를 하나의 지갑에 묶습니다. 출금은 보이지 않으며 그 공백에는 실무적 결과가 따릅니다: 읽기 전용 지갑은 key image를 계산할 수 없습니다. key image는 (Hs(aR || i) + b) * Hp(P)이고 b가 없기 때문입니다. 따라서 어떤 출력이 이미 사용됐는지 알 수 없고, spend 지갑이 자금을 옮기면 표시 잔액은 위로 벌어집니다. view key 쪽 잔액은 '사용 가능'이 아니라 '누적 수취'로 취급하십시오. 테스트 거래에서 읽기 전용 스캔은 출력 1을 서브주소 (0,3)에 일치시키고 금액까지 복호화했지만, 계산할 수 있었던 것은 지급 측 스칼라 Hs(aR || 1) = d2a1346b...까지였고 key image는 b를 되돌려 넣은 뒤에야 나타났습니다.
실제 체인에서는 이렇게 보입니다. 블록 3,796,140(오늘 13:18:40 UTC)은 30,980바이트에 거래 18건을 담고 있습니다. 거래 38488d18...은 2,220바이트이고 수수료 0.0001776 XMR: 바이트당 80,000 piconero로, 노드가 현재 제시하는 하한 20,000 piconero/B의 네 배입니다. 입력 2개는 각각 링 멤버 16개를 가지고, 출력 2개의 표시 금액은 모두 0입니다. 이 0은 버그가 아니라 RingCT가 금액을 암호화 필드로 옮기고 체인에는 커밋먼트만 남긴 결과입니다. extra 필드는 0x01과 32바이트 tx 공개키로 시작하고, 이어 0x02와 9바이트 논스(암호화된 결제 ID)가 들어 있습니다. 외부 관찰자가 할 수 있는 일은 출력이 둘이라고 세고 추측하는 것뿐이고, 수취인의 view key가 할 수 있는 일은 후보 출력 키 두 개를 시험해 금액 하나를 복호화하는 것뿐입니다.
지갑을 넘기지 않고 키만 넘기는 방법. 메인 지갑 파일을 복사하지 말고 읽기 전용 지갑을 따로 만드십시오: monero-wallet-cli --generate-from-view-key audit.dat --restore-height N 으로 view key를 붙여넣고, --subaddress-lookahead를 발행한 주소를 덮을 만큼 높입니다. 룩어헤드를 넘어선 과거 서브주소는 인식되지 않기 때문입니다. 복원 높이가 다른 어떤 플래그보다 중요합니다. 제네시스부터 스캔하는 것은 낭비이고 스캔 비용은 실재합니다. 최근 30개 블록에서 크기 중앙값 67,089바이트, 평균 102,540바이트(30개 중 2개는 거래 1건 이하)였고, 이는 팁을 따라가는 데 하루 약 74MB, 연간 약 27GB의 체인 데이터에 해당합니다. 감사자에게는 첫 예상 입금 직전의 복원 높이를 주고 대상 기간을 문서로 남기십시오.
노출을 작게 유지하는 네 가지 규칙. 첫째, 사본만 넘기고 원본 파일은 넘기지 않으며 업무가 끝나면 사본을 삭제합니다 — 키에는 만료가 없습니다. 둘째, 키보다 내보내기를 우선합니다. 입금 CSV는 회계 질문 대부분에 답하고 미래 입금은 전혀 드러내지 않습니다. 셋째, 실시간 추적이 정말 필요하면 키에 종료일과 수취인 목록을 붙이고, 보유자가 그 지갑의 이후 모든 입금을 본다고 가정하십시오. 넷째, view key를 그 주소와 같은 경로로 보내지 말고, 글자 단위로 대조하지 않은 키를 보내지 마십시오. view key와 spend key는 모두 64자리 16진수라 명령 하나만 틀려도 다른 쪽을 넘기게 됩니다. 공개 spend 키와 공개 view 키를 개인 view 키 옆에 출력해, 그 쌍이 청구서의 주소에 실제로 속하는지 확인하십시오. (모네로 확인 대기)
인스턴트 스왑의 위치. 스왑에는 view key가 필요 없고 요구해서도 안 됩니다. VeilSwap 주문 엔드포인트는 정확히 7개 필드를 받습니다: fromAsset, toAsset, fromAmount, toAddress, toExtraId, refundAddress, refundExtraId. 환불 주소는 2026년 10월 25일부터 필수이고, 카탈로그는 현재 516개 자산·75개 네트워크(그중 60개 스테이블코인)이며 XMR에는 extra ID가 필요 없습니다. 견적은 120초 유효, 입금 창은 30분이고, 지급은 풀이 서명하며 당신 지갑은 관여하지 않습니다. 입금을 '확인'하라며 view key를 붙여넣으라고 하면 위험 신호로 보십시오. 입금 주소와 트랜잭션 해시만으로 도착이 증명되고, 지급을 풀기 위해 그 이상은 필요 없습니다. (모네로 확인 대기)
요약. view key는 수입을 읽어야 하는 회계 담당에게는 맞는 도구이고, '다른 것은 읽히지 않았다'를 확신하려는 사람에게는 틀린 도구입니다. 가능하면 내보내기 파일을, 꼭 필요하면 기간 한정 읽기 전용 지갑을 넘기고, spend 키 — 서명할 수 있고 key image를 계산할 수 있는 유일한 키 — 는 감사자가 건드리지 않는 기기에 두십시오. 환율은 움직이므로 여기 모든 숫자는 시각이 붙은 기록입니다: 오늘 14:03 UTC 기준 100 USDT-TRC20은 0.14880904 XMR(함의 671.99 USDT/XMR, 현물 592.60), 10,000 USDT는 16.61076502 XMR, 1 XMR은 574.509235 USDT, 0.05 BTC는 6.4437305 XMR이었습니다. 페이지의 실시간 견적만이 의미를 갖습니다. (XMR→USDT 출구 루트)