Proovik
प्रमाणित करें
सार्वजनिक सत्यापक · PVK-PROOF/1

Proovik के प्रमाण को Proovik पर भरोसा किए बिना कैसे जाँचें

आपको प्रमाण फ़ाइल (या प्रमाणपत्र का PDF) और मूल दस्तावेज़ की अपनी प्रति चाहिए। कुछ भी अपलोड नहीं होता: हैश की गणना आपके ब्राउज़र में होती है। नीचे, पूरा विनिर्देश, चरण दर चरण और वास्तविक मानों के साथ।

संस्करण 1 नेटवर्क: Kaspa mainnet संदर्भ सत्यापक: Python की 248 पंक्तियाँ, कोई निर्भरता नहीं
उपकरण

ऑनलाइन प्रमाण सत्यापित करें

यहाँ किसी प्रमाणपत्र को उसी इंजन से जाँचें जिसका वर्णन नीचे है। दस्तावेज़ आपके डिवाइस से बाहर नहीं जाता: उसके SHA-256 की गणना आपके ब्राउज़र में होती है और केवल हैश यात्रा करता है। हैश आप देते हैं; वह कभी प्रमाण फ़ाइल से नहीं लिया जाता। अगर आप प्रमाणपत्र का PDF खींचकर छोड़ते हैं, तो संलग्न साक्ष्य पैकेज आपके ब्राउज़र में निकाला जाता है और PDF भी नहीं भेजा जाता।

1 · प्रमाण फ़ाइल

2 · मूल दस्तावेज़

सत्यापक हैश कभी प्रमाण फ़ाइल से नहीं लेता: उसे आप देते हैं।

पैकेज और हैश POST /api/verify/proof पर भेजे जाते हैं। बिना खाते के। सीमा: प्रति घंटा और प्रति IP 120 सत्यापन।

यह प्रमाणपत्र PDF पर छपी होती है और Kaspa एक्सप्लोरर में दिखती है।

आप इसकी गणना दूसरे टैब में दस्तावेज़ खींचकर छोड़कर कर सकते हैं: मान साझा होता है।

यह मोड api.kaspa.org से पूछकर पैकेज को पुनर्निर्मित करता है। Kaspa पूरा हेडर ऐंकरिंग के बाद केवल लगभग 40 घंटे तक देता है: उसके बाद कड़ी 3 और 4 की दोबारा गणना नहीं की जा सकती और फ़ैसला अनिर्णायक होगा, कभी “सिद्ध करता है” नहीं। पूर्ण सत्यापन के लिए उसी समय कैप्चर की गई प्रमाण फ़ाइल का उपयोग करें।

GET /api/verify/proof/{txid}?hash=…। सीमा: प्रति घंटा और प्रति IP 30 (यह नेटवर्क से पूछता है)।

फ़ैसला ·

सिद्ध अनिर्णायक सिद्ध नहीं

चारों कड़ियाँ मेल खाती हैं: इस SHA-256 वाला दस्तावेज़ तब मौजूद था जब बताया गया ब्लॉक माइन हुआ। याद रखें कि प्रमाण क्या सिद्ध नहीं करता: लेखकत्व या सामग्री की सत्यता।

जिसकी दोबारा गणना की जा सकी वह मेल खाता है, पर शृंखला पूरी करने के लिए कुछ डेटा गायब है (आमतौर पर पूरा ब्लॉक हेडर, प्रूनिंग विंडो के बाहर)। यह प्रमाण की विफलता नहीं है: यह एक आंशिक सत्यापन है। उसी समय कैप्चर की गई प्रमाण फ़ाइल के साथ, या पूरे साक्ष्य पैकेज के साथ, इसे पूरा किया जा सकता है।

दिए गए हैश के लिए कम से कम एक कड़ी मेल नहीं खाती। सबसे आम कारण: दस्तावेज़ ठीक वही नहीं है जिस पर मुहर लगी थी (एक भी अलग बाइट SHA-256 बदल देता है) या प्रमाण फ़ाइल इस दस्तावेज़ की नहीं है। हर कड़ी का विवरण देखें।

नेटवर्क पर लेनदेन देखें
दस्तावेज़
txid
block_hash
नेटवर्क
मोड
हेडर
सत्यापित

कड़ियाँ, एक-एक करके

  1. स्वीकृति साक्षी (KIP-15)

    पैकेज में स्वीकृति साक्षी शामिल नहीं है। यह वैकल्पिक है: इससे फ़ैसले पर असर नहीं पड़ता।

चेतावनियाँ

हर कड़ी का क्या अर्थ है

प्रमाण का दायरा

वास्तव में क्या दावा किया जाता है

यहाँ वाक्पटुता से ज़्यादा परिशुद्धता मायने रखती है, क्योंकि इसी पर निर्भर करता है कि प्रमाण जिरह में टिकेगा या नहीं।

प्रमाण क्या सिद्ध करता है

कि बाइटों की एक ऐसी शृंखला, जिसका SHA-256 एक निश्चित मान है, Kaspa नेटवर्क के एक लेनदेन में शामिल की गई, कि वह लेनदेन एक ब्लॉक हेडर के भीतर प्रतिबद्ध हुआ, और कि उस हेडर पर — जिसमें एक टाइमस्टैम्प शामिल है — एक वैध प्रूफ़ ऑफ़ वर्क निष्पादित किया गया। चूँकि टाइमस्टैम्प उसी डेटा के भीतर है जिस पर वह काम किया गया था, उसे बदलने से वह काम अमान्य हो जाता है। तारीख किसी की घोषणा नहीं है: यह पहले ही खर्च की जा चुकी एक भौतिक राशि है।

प्रमाण क्या सिद्ध नहीं करता

कि दस्तावेज़ किसने बनाया, उसकी सामग्री सच है या नहीं, उसके लेखक को उसे बनाने का अधिकार था या नहीं, और न ही यह कि दस्तावेज़ पहले मौजूद नहीं था। यह किसी क्षण के सापेक्ष पूर्वता सिद्ध करता है, लेखकत्व या सत्यता नहीं। Proovik दस्तावेज़ को किसी भी समय नहीं देखता: उसे केवल उसका हैश मिलता है।

हैश के बारे में

SHA-256 एक 256-बिट डाइजेस्ट फलन है। एक ही डाइजेस्ट वाले दो अलग दस्तावेज़ खोजना आज तक कभी संभव नहीं हुआ है और अनुमानित प्रयास उससे कहीं अधिक है जितना मानवता गणना कर सकती है। इसीलिए, अगर प्रस्तुत दस्तावेज़ का डाइजेस्ट चेन पर मौजूद डाइजेस्ट से मेल खाता है, तो दस्तावेज़ वही है, संदेह की कोई व्यावहारिक गुंजाइश नहीं।

वास्तविक उदाहरण · 20-09-2026

चार कड़ियाँ

सत्यापन एक शृंखला है। हर कड़ी अगली से जुड़ती है, और एक भी कड़ी टूटने पर प्रमाण बेकार हो जाता है। नीचे दिखाए गए मान वास्तविक हैं: वे 20 सितंबर 2026 को जारी किए गए एक प्रमाणपत्र के हैं।

1 2 3 4

1 · लेनदेन का डेटा दस्तावेज़ का डाइजेस्ट है

मेल खाता है
यह क्या जाँचता है
कि आपकी फ़ाइल का हैश ठीक वही है जो Kaspa पर है।
अगर यह विफल हो
तो किसी ने दस्तावेज़ बदला होगा, चाहे एक ही बाइट क्यों न हो।
कैसे
हर Kaspa लेनदेन में एक मुक्त फ़ील्ड होता है, payload। Proovik वहाँ दस्तावेज़ के SHA-256 के 32 बाइट लिखता है, और कुछ नहीं। जाँच एक शाब्दिक तुलना है।
गणना देखें 
SHA-256(documento) == transaccion.payload
documento0f7383b381366cc3a75dadd7e4a1e8998c492f7c5c5610f4384d7320f484aad8
payload0f7383b381366cc3a75dadd7e4a1e8998c492f7c5c5610f4384d7320f484aad8

2 · लेनदेन ब्लॉक हेडर में प्रतिबद्ध है

मेल खाता है
यह क्या जाँचता है
कि यह लेनदेन उसी ब्लॉक का हिस्सा है जो प्रमाण घोषित करता है, किसी और का नहीं।
अगर यह विफल हो
लेनदेन तो होता, पर उस ब्लॉक में नहीं और न उस तारीख के साथ।
कैसे
Kaspa चेन के हर हेडर में उन लेनदेनों के प्रति एक प्रतिबद्धता दर्ज करता है जिन्हें वह ब्लॉक स्वीकार करता है। KIP-15 के लागू होने के बाद से वह फ़ील्ड, 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
AIMRb3bc256951640ff6468511fb62ec8fb280dafb99ebf7ecd00245d0cc3c9debb3
पैरेंट seq.2b3265225d51e5b051e46b9f164dc116cf2e21d566827abc8a7b1ae036d8330d
गणना किया गया7843221eda25f05ddf9872ed57b59fb95c4f15aa7bf15017105e9797ef09caa5
हेडर में7843221eda25f05ddf9872ed57b59fb95c4f15aa7bf15017105e9797ef09caa5
दो जाँची हुई भूलें

स्वीकृत लेनदेनों का क्रम वह विहित क्रम है जो KIP-15 तय करता है, न वह क्रम जिसमें कोई API उन्हें लौटाए और न हैश के अनुसार क्रम। और किसी ब्लॉक के वृक्ष की पत्तियाँ — जब स्वीकृति के बजाय समावेशन सत्यापित किया जाता है — txid नहीं, बल्कि tx::hash होती हैं, जिनकी गणना पूर्ण एन्कोडिंग से की जाती है (signature scripts और स्टोरेज-मास प्रतिबद्धता सहित)।

3 · हेडर से घोषित ब्लॉक हैश बनता है

मेल खाता है
यह क्या जाँचता है
कि प्राप्त हेडर, बाइट-दर-बाइट दोबारा गणना करने पर, ठीक यही ब्लॉक हैश देता है।
अगर यह विफल हो
तब हेडर उस ब्लॉक का नहीं होता: उसमें मौजूद तारीख बेकार होती।
कैसे
किसी ब्लॉक का हैश उसके क्रमबद्ध हेडर का डाइजेस्ट होता है। उसकी दोबारा गणना करना यह सिद्ध करता है कि प्रस्तुत हेडर ठीक वही है जो होने का दावा करता है, और उसका कोई भी फ़ील्ड — टाइमस्टैम्प सहित — छुआ नहीं गया है।
गणना देखें 
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
ब्लॉक77ee3a38aecdb3d8e97a010f7f8f78927e48282d22ebfae3004713ba8a9d51fc
अनिवार्य शर्त

हेडर सभी पैरेंट स्तरों के प्रति प्रतिबद्ध होता है — आज वे 56 हैं, दो सौ से अधिक हैश के साथ —। अगर एक भी गायब हो, तो डाइजेस्ट दोबारा नहीं बनाया जा सकता। यही कारण है कि प्रमाण फ़ाइल को ऐंकरिंग के समय पूरा हेडर कैप्चर करना चाहिए: लगभग तीस घंटे बाद नेटवर्क वह डेटा हटा देता है और सार्वजनिक सेवाएँ कटा हुआ हेडर लौटाती हैं।

4 · उस हेडर पर एक वैध प्रूफ़ ऑफ़ वर्क निष्पादित किया गया था

वैध कार्य
यह क्या जाँचता है
कि काम इसी हेडर पर हुआ, जिसके भीतर यह तारीख है। तारीख बदलने से काम अमान्य हो जाता है।
अगर यह विफल हो
तब तारीख एक घोषणा होती, पहले ही खर्च की जा चुकी भौतिक राशि नहीं।
कैसे
यहीं पर प्रमाण एक कथन नहीं रह जाता और तथ्य की पुष्टि बन जाता है। Kaspa यह अपेक्षा करता है कि हेडर पर उसका कार्य-फलन (kHeavyHash) लगाने का परिणाम एक सीमा से नीचे रहे। उस तक पहुँचने के लिए खरबों-खरब प्रयास चाहिए: वास्तविक ऊर्जा, अपरिवर्तनीय रूप से खर्च की गई।
गणना देखें 
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)
pre6e4f2ca8feb279a54f2c4ac8d57c867917f1766a7936a5bd7bd9351557d3c6f7
परिणाम0x15222b53caabb3b049ec84e25d0a0c7a35512f9d557adb4bc20
लक्ष्य0x2345b0000000000000000000000000000000000000000000000
ऐंकर किया गया2026-09-20 00:03:00 UTC
तारीख

तारीख एक भौतिक राशि क्यों है, घोषणा क्यों नहीं

जिरह में आमतौर पर यही हिस्सा माँगा जाता है, इसलिए इसे तर्क देने के बजाय दिखाना बेहतर है। टाइमस्टैम्प हेडर के भीतर है, और हेडर ही प्रूफ़ ऑफ़ वर्क का इनपुट है। समय बदलिए तो इनपुट बदल जाता है, और काम वैध नहीं रहता। इसे प्रयोगात्मक रूप से जाँचा जाता है: चरण 4 में सत्यापित हेडर को बदलकर गणना दोहराई जाती है:

हेडर बदलने का प्रूफ़-ऑफ़-वर्क परिणाम पर असर
हेडर कार्य का परिणाम फ़ैसला
मूल, बिना छेड़छाड़0x15222b53caabb3b049ec…वैध
nonce + 10x6775abc19ba960657f66…अमान्य
timestamp एक सेकंड आगे बढ़ाया गया0xaee1e8274b1d268866ed…अमान्य
नतीजा

दस्तावेज़ को किसी और तारीख के साथ प्रस्तुत करने के लिए उस हेडर का प्रूफ़ ऑफ़ वर्क नेटवर्क की वास्तविक कठिनाई के विरुद्ध दोबारा करना पड़ेगा। यह लागत की बाधा नहीं है: यह गणना की ऐसी बाधा है जो, जिस अंतराल को कोई झुठलाना चाहे, उसमें पूरे नेटवर्क की कुल शक्ति के बराबर है। तारीख कोई घोषित नहीं करता। तारीख चुकाई जाती है।

स्थायित्व

क्या यह भविष्य के हार्डफ़ोर्क के बाद भी काम करेगा?

ईमानदार उत्तर है हाँ, और यह समझना ज़रूरी है कि क्यों। कैप्चर किया गया प्रमाण नेटवर्क से की गई कोई जीवंत क्वेरी नहीं है: यह एक ऐतिहासिक तथ्य है, जो उन नियमों के तहत सत्यापित होता है जो ऐंकर करते समय लागू थे। Kaspa समय के साथ बदलता है — उदाहरण के लिए, Crescendo/Toccata संक्रमण ने DAA की गति और कठिनाई की गणना बदल दी — पर इससे अतीत मिटता नहीं: इसका सिर्फ़ इतना अर्थ है कि जनवरी 2026 का ब्लॉक जनवरी 2026 के नियमों से सत्यापित होता है, और तीन साल बाद का ब्लॉक तीन साल बाद के नियमों से।

संदर्भ सत्यापक इसी के लिए बनाया गया है: वह युगों में भेद करता है। वह हर सर्वसम्मति-परिवर्तन का सक्रियण बिंदु जानता है (उदाहरण के लिए, CRESCENDO_DAA_MAINNET स्थिरांक) और हर ब्लॉक पर उसके युग के नियम लागू करता है, आज के नहीं। बाद का कोई हार्डफ़ोर्क एक नया युग जोड़ता है; वह पिछले युगों को अमान्य नहीं करता।

इसलिए प्रमाण का स्थायित्व तीन शर्तों पर टिका है, और तीनों उसी के नियंत्रण में हैं जिसके पास प्रमाण है:

1

विंडो के भीतर कैप्चर करें

ऐंकरिंग के समय पूरा हेडर सहेज लें, इससे पहले कि नेटवर्क पूरा डेटा हटा दे (लगभग 30-40 घंटे)।

2

प्रमाण सहेजकर रखें

प्रमाण फ़ाइल (या वह PDF जिसमें वह अंतर्निहित है) आत्मनिर्भर है: वह न किसी सर्वर की ओर इशारा करती है और न कोई ऑनलाइन क्वेरी करती है।

3

संदर्भ सत्यापक को बनाए रखें

मुक्त स्रोत कोड की 248 पंक्तियाँ, कोई निर्भरता नहीं, Kaspa के सार्वजनिक स्रोत कोड से दोबारा व्युत्पन्न की जा सकने वाली। अगर वह खो भी जाए, तो दोबारा लिखी जा सकती है।

इसे स्वयं सत्यापित करें

इसे Proovik के बिना करें

संदर्भ सत्यापक बाहरी निर्भरताओं के बिना 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

संदर्भ सत्यापक डाउनलोड करें

दो फ़ाइलें। उन्हें एक ही फ़ोल्डर में रखें और पहली चलाएँ। वे कुछ भी इंस्टॉल नहीं करतीं और न नेटवर्क पर जाती हैं।

verificador_kaspa.py kaspa_pow.py

जो किसी और का कोड चलाना न चाहे वह उसे दोबारा लिख सकता है: चारों एल्गोरिदम ऊपर बिना किसी अस्पष्टता के वर्णित हैं, और सभी पैरामीटर rusty-kaspa के सार्वजनिक स्रोत कोड से आते हैं। तुलना के लिए लेनदेन को किसी भी सार्वजनिक Kaspa एक्सप्लोरर में देख लेना भी उतना ही उचित है, पर अंतर समझना ज़रूरी है: एक्सप्लोरर एक गवाही है; गणना एक सिद्धि है। यह विनिर्देश इसीलिए है कि पहले पर निर्भर न रहना पड़े।

कानूनी ढाँचा

कानूनी दायरा

Proovik विनियम (EU) 910/2014 के अनुच्छेद 3.16.i) के अर्थ में गैर-अर्हताप्राप्त इलेक्ट्रॉनिक टाइमस्टैम्प सेवा प्रदान करता है। इसका क्या अर्थ है, इस बारे में स्पष्ट होना उचित है।

  • उक्त विनियम के अनुच्छेद 41.1 के अनुसार, किसी इलेक्ट्रॉनिक टाइमस्टैम्प को केवल इस आधार पर कानूनी प्रभाव या न्यायिक कार्यवाही में साक्ष्य के रूप में ग्राह्यता से वंचित नहीं किया जा सकता कि वह इलेक्ट्रॉनिक रूप में है या अर्हताप्राप्त मुहर की शर्तें पूरी नहीं करता।
  • गैर-अर्हताप्राप्त मुहर को अनुच्छेद 41.2 की तारीख और समय की सटीकता की उपधारणा प्राप्त नहीं है, जो अर्हताप्राप्त मुहरों के लिए आरक्षित है। चुनौती दिए जाने पर, प्रमाण को पुष्ट करने का भार उसे प्रस्तुत करने वाले पक्ष पर होता है।
  • यह विनिर्देश ठीक इसीलिए है: ताकि वह भार प्रदाता की घोषणा के बजाय ऐसी अंकगणितीय जाँच से पूरा हो जिसे कोई भी दोहरा सके।

Proovik दस्तावेज़ों की सामग्री, लेखकत्व या वैधता की जाँच नहीं करता, और किसी भी समय उन तक पहुँच नहीं बनाता: उसे केवल उनका क्रिप्टोग्राफ़िक डाइजेस्ट मिलता है। जो सिद्ध होता है वह किसी निश्चित क्षण तक अस्तित्व और पूर्व-तिथि का प्रमाण है।

संदर्भ

हेडर और लेनदेन का क्रमांकन, Merkle वृक्ष का निर्माण और प्रूफ़ ऑफ़ वर्क, Kaspa के संदर्भ कार्यान्वयन (rusty-kaspa) के स्रोत कोड के अनुसार: 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/।

उदाहरण के रूप में उपयोग किए गए मान वास्तविक प्रमाणपत्रों के हैं और कोई भी उन्हें जाँच सकता है। यह विनिर्देश संस्करणबद्ध है: प्रमाण अपने भीतर वह संस्करण दर्ज करते हैं जिसके साथ वे जारी किए गए थे।