증명 파일(또는 인증서 PDF)과 원본 문서의 사본이 필요합니다. 아무것도 업로드되지 않으며 해시는 브라우저에서 계산됩니다. 아래에 실제 값과 함께 단계별 전체 명세가 있습니다.
아래에 설명된 것과 같은 엔진으로 여기서 인증서를 확인하세요. 문서는 기기를 벗어나지 않습니다. SHA-256은 브라우저에서 계산되고 해시만 전송됩니다. 해시는 당신이 제공하며 증명 파일에서 가져오는 일은 없습니다. 인증서 PDF를 끌어다 놓으면 첨부된 증거 패키지가 브라우저에서 추출되며 PDF도 전송되지 않습니다.
1 · 증명 파일
2 · 원본 문서
검증기는 증명 파일에서 해시를 가져오지 않습니다. 해시는 당신이 제공합니다.
패키지와 해시가 POST /api/verify/proof로 전송됩니다. 계정은 필요 없습니다. 한도: IP당 시간당 검증 120회.
인증서 PDF에 인쇄되어 있고 Kaspa 탐색기에서 볼 수 있습니다.
다른 탭에서 문서를 끌어다 놓아 계산할 수 있습니다. 값은 서로 공유됩니다.
GET /api/verify/proof/{txid}?hash=…. 한도: IP당 시간당 30회(네트워크에 질의합니다).
네 고리가 모두 일치합니다. 이 SHA-256을 가진 문서는 해당 블록이 채굴된 시점에 존재했습니다. 이 증명이 증명하지 않는 것도 기억하세요. 작성자와 내용의 진실성은 증명하지 않습니다.
다시 계산할 수 있었던 부분은 일치하지만, 사슬을 닫는 데 필요한 데이터가 일부 없습니다(대개 가지치기 창을 벗어난 전체 블록 헤더). 증명의 실패가 아니라 부분 검증입니다. 당시에 확보한 증명 파일이나 완전한 증거 패키지가 있으면 마무리할 수 있습니다.
제공된 해시로는 적어도 하나의 고리가 일치하지 않습니다. 가장 흔한 경우는 문서가 봉인된 바로 그 문서와 정확히 같지 않거나(1바이트만 달라도 SHA-256이 바뀝니다) 증명 파일이 이 문서의 것이 아닌 경우입니다. 각 고리의 상세 내용을 확인하세요.
패키지에 수락 증거가 없습니다. 선택 사항이며 판정에 영향을 주지 않습니다.
경고
여기서는 웅변보다 정확성이 더 중요합니다. 증명이 반대신문을 견뎌 내느냐가 여기에 달려 있기 때문입니다.
SHA-256이 특정 값인 바이트열이 Kaspa 네트워크의 트랜잭션에 포함되었고, 그 트랜잭션이 어느 블록의 헤더 안에 커밋되었으며, 타임스탬프를 담고 있는 그 헤더 위에서 유효한 작업증명이 수행되었다는 사실. 타임스탬프가 작업의 대상이 된 데이터 안에 있으므로, 그것을 바꾸면 작업이 무효가 됩니다. 날짜는 누군가의 선언이 아니라 이미 소모된 물리량입니다.
누가 문서를 만들었는지, 그 내용이 사실인지, 작성자에게 그것을 만들 권리가 있었는지, 그리고 문서가 그 이전에 존재하지 않았는지는 입증하지 않습니다. 어느 시점보다 앞섰다는 사실을 입증할 뿐, 작성자나 진실성을 입증하지는 않습니다. Proovik은 어느 순간에도 문서를 보지 않으며 그 해시만 받습니다.
SHA-256은 256비트 다이제스트 함수입니다. 다이제스트가 같은 서로 다른 두 문서를 찾아낸 사례는 한 번도 없었고, 그에 필요할 것으로 추정되는 노력은 인류가 계산할 수 있는 범위를 넘습니다. 그래서 제출된 문서의 다이제스트가 체인에 있는 값과 일치하면 그 문서는 같은 문서이며, 현실적으로 의심의 여지가 없습니다.
검증은 하나의 사슬입니다. 고리마다 다음 고리로 이어지며, 하나만 끊어져도 증명은 쓸모가 없어집니다. 아래에 나오는 값은 실제 값으로, 2026년 9월 20일에 발급된 인증서의 것입니다.
payload가 있습니다. Proovik은 거기에 문서 SHA-256의 32바이트를 기록하며, 그 밖에는 아무것도 넣지 않습니다. 확인은 글자 그대로의 비교입니다.SHA-256(documento) == transaccion.payload
acceptedIdMerkleRoot는 단순한 Merkle 루트가 아니라 연쇄된 값입니다. 부모 블록의 커밋과 수락된 트랜잭션의 루트를 결합합니다. 이 연쇄를 무시한 재계산은 실패하며, 이것이 검증 오류의 가장 흔한 원인입니다.nodo(a,b) = blake2b-256( clave = "MerkleBranchHash", a ‖ b ) AIMR = raiz Merkle sobre las transacciones aceptadas, en orden canonico SeqCommit = nodo( SeqCommit_del_padre_seleccionado , AIMR ) valido ⟹ SeqCommit == cabecera.acceptedIdMerkleRoot
수락된 트랜잭션의 순서는 API가 돌려주는 순서도, 해시 순서도 아닌 KIP-15가 정한 정규 순서입니다. 그리고 블록 트리의 잎은 — 수락이 아니라 포함을 검증할 때 — txid가 아니라 전체 인코딩(서명 스크립트와 저장 질량 커밋 포함)으로 계산한 tx::hash입니다.
h = blake2b-256( clave = "BlockHash" )
h ← version u16 little-endian
h ← numero de niveles u64 little-endian
para cada nivel:
h ← numero de padres u64 little-endian
h ← cada hash de padre 32 bytes
h ← hashMerkleRoot 32 bytes
h ← acceptedIdMerkleRoot 32 bytes
h ← utxoCommitment 32 bytes
h ← timestamp u64 little-endian ← la marca temporal
h ← bits u32 little-endian
h ← nonce u64 little-endian
h ← daaScore u64 little-endian
h ← blueScore u64 little-endian
h ← longitud de blueWork u64 little-endian
h ← blueWork big-endian, sin ceros a la izquierda
h ← pruningPoint 32 bytes
헤더는 모든 부모 레벨에 대해 커밋합니다. 오늘 기준 56개 레벨, 200개가 넘는 해시입니다. 하나라도 빠지면 다이제스트를 재구성할 수 없습니다. 증명 파일이 앵커링 시점에 온전한 헤더를 확보해야 하는 이유가 이것입니다. 서른 시간쯤 지나면 네트워크가 그 데이터를 버리고, 공개 서비스는 잘린 헤더를 돌려줍니다.
pre = hash_de_cabecera( con timestamp = 0 y nonce = 0 )
M = matriz 64x64 generada con xoshiro256++ sembrado con pre,
regenerada hasta que su rango sea 64
p = cSHAKE256("ProofOfWorkHash")( pre ‖ timestamp ‖ 32 ceros ‖ nonce )
r = cSHAKE256("HeavyHash")( (M · nibbles(p)) ⊕ p )
valido ⟹ entero_little_endian(r) ≤ objetivo(bits)
이 부분이야말로 반대신문에서 흔히 요구되는 대목이니, 논증하기보다 보여 주는 편이 낫습니다. 타임스탬프는 헤더 안에 있고, 헤더는 작업증명의 입력입니다. 시각을 바꾸면 입력이 바뀌고, 작업은 더 이상 유효하지 않습니다. 4단계에서 검증한 헤더를 변형해 계산을 되풀이하면 실험으로 확인할 수 있습니다:
| 헤더 | 작업 결과 | 판정 |
|---|---|---|
| 원본, 손대지 않음 | 0x15222b53caabb3b049ec… | 유효 |
nonce + 1 | 0x6775abc19ba960657f66… | 무효 |
timestamp를 1초 앞으로 이동 | 0xaee1e8274b1d268866ed… | 무효 |
문서를 다른 날짜로 제시하려면 네트워크의 실제 난이도에 맞서 그 헤더의 작업증명을 다시 해야 합니다. 이것은 비용의 장벽이 아니라, 위조하려는 구간 동안 네트워크 전체의 총 연산력에 해당하는 계산의 장벽입니다. 아무도 날짜를 선언하지 않습니다. 날짜는 대가를 치르고 얻습니다.
정직한 답은 그렇다이며, 그 이유를 이해해 둘 필요가 있습니다. 확보해 둔 증명은 네트워크에 대한 실시간 질의가 아니라, 앵커링된 시점에 유효했던 규칙으로 검증되는 역사적 사실입니다. Kaspa는 시간이 지나며 바뀝니다. 예컨대 Crescendo/Toccata 전환은 DAA의 주기와 난이도 계산 방식을 바꾸었습니다. 그러나 그것이 과거를 지우지는 않습니다. 2026년 1월의 블록은 2026년 1월의 규칙으로, 3년 뒤의 블록은 3년 뒤의 규칙으로 검증된다는 뜻일 뿐입니다.
참조 검증기는 바로 그것을 위해 만들어졌습니다. 시대를 구분합니다. 각 합의 변경의 활성화 시점(예를 들어 CRESCENDO_DAA_MAINNET 상수)을 알고 있으며, 각 블록에 오늘의 규칙이 아니라 그 시대의 규칙을 적용합니다. 이후의 하드포크는 새로운 시대를 추가할 뿐, 이전의 시대를 무효로 만들지 않습니다.
그러므로 증명의 영속성은 세 가지 조건에 달려 있으며, 모두 증명을 가진 사람이 통제할 수 있습니다:
네트워크가 전체 데이터를 버리기 전에(약 30~40시간) 앵커링 시점의 온전한 헤더를 저장하세요.
증명 파일(또는 그것을 내장한 PDF)은 그 자체로 충분합니다. 어떤 서버도, 온라인 조회도 필요로 하지 않습니다.
의존성 없는 공개 코드 248줄로, Kaspa의 공개 소스에서 다시 도출할 수 있습니다. 잃어버리더라도 다시 작성하면 됩니다.
참조 검증기는 외부 의존성이 없는 Python 248줄입니다. 키를 사용하는 blake2b, Keccak-f[1600] 순열, xoshiro256++ 생성기, 행렬 연산을 구현합니다. 하루 저녁이면 읽고, 이틀이면 감사할 수 있습니다.
$ python3 verificador_kaspa.py prueba.json 0f7383b381366cc3a75dadd7e4a1e8998c492f7c5c5610f4384d7320f484aad8 OK 1. El payload on-chain es el hash del documento OK 2. La transaccion esta en el arbol Merkle del bloque OK 3. La cabecera produce el hash de bloque declarado OK 4. La prueba de trabajo de esa cabecera es valida RESULTADO: PRUEBA VALIDA
파일 두 개입니다. 같은 폴더에 두고 첫 번째를 실행하십시오. 아무것도 설치하지 않으며 네트워크에 접속하지도 않습니다.
남의 코드를 실행하고 싶지 않다면 직접 다시 구현할 수 있습니다. 네 가지 알고리즘은 위에 모호함 없이 설명되어 있고, 모든 매개변수는 rusty-kaspa의 공개 소스 코드에서 나옵니다. 대조를 위해 아무 공개 Kaspa 탐색기에서 트랜잭션을 조회하는 것도 똑같이 정당하지만, 그 차이는 알아 둘 필요가 있습니다. 탐색기는 증언이고, 계산은 증명입니다. 이 명세는 전자에 의존하지 않기 위해 존재합니다.
Proovik은 (EU) 규정 910/2014 제3조 제16호 i)의 의미에서 비적격 전자 타임스탬프 서비스를 제공합니다. 그것이 무엇을 뜻하는지 분명히 밝혀 둘 필요가 있습니다.
Proovik은 문서의 내용, 작성자, 적법성을 검증하지 않으며 어느 순간에도 문서에 접근하지 않습니다. 오직 그 암호학적 다이제스트만 받습니다. 입증되는 것은 특정 시점에 대한 존재 및 선행 일자 증명입니다.
Kaspa 참조 구현(rusty-kaspa)의 소스 코드에 따른 헤더 및 트랜잭션 직렬화, Merkle 트리 구성, 작업증명: consensus/core/src/hashing/header.rs, consensus/core/src/hashing/tx.rs, consensus/core/src/merkle.rs, crypto/hashes/src/pow_hashers.rs, consensus/pow/.
예시로 쓰인 값은 실제 인증서의 것이며 누구나 확인할 수 있습니다. 이 명세에는 버전이 매겨집니다. 각 증명은 발급될 때의 버전을 그 안에 표시합니다.