Proovik
প্রত্যয়ন
সর্বজনীন যাচাইকারী · PVK-PROOF/1

Proovik-কে বিশ্বাস না করেই একটি Proovik প্রমাণ কীভাবে যাচাই করবেন

আপনার দরকার প্রমাণ ফাইলটি (বা সার্টিফিকেটের PDF) এবং মূল নথির আপনার নিজের কপি। কিছুই আপলোড হয় না: হ্যাশ আপনার ব্রাউজারেই হিসাব হয়। নিচে রয়েছে সম্পূর্ণ স্পেসিফিকেশন, ধাপে ধাপে ও বাস্তব মানসহ।

সংস্করণ 1 নেটওয়ার্ক: Kaspa mainnet রেফারেন্স যাচাইকারী: 248 লাইন Python, কোনো নির্ভরতা ছাড়াই
সরঞ্জাম

অনলাইনে একটি প্রমাণ যাচাই করুন

নিচে বর্ণিত একই ইঞ্জিন দিয়ে এখানেই একটি সার্টিফিকেট যাচাই করে দেখুন। নথিটি আপনার ডিভাইস ছাড়ে না: এর SHA-256 আপনার ব্রাউজারেই হিসাব হয় এবং কেবল হ্যাশটিই যায়। হ্যাশটি আপনিই দেন, তা কখনোই প্রমাণ ফাইল থেকে নেওয়া হয় না। সার্টিফিকেটের PDF টেনে ছাড়লে সংযুক্ত সাক্ষ্য প্যাকেজটি আপনার ব্রাউজারেই বের করা হয় এবং PDF-ও পাঠানো হয় না।

1 · প্রমাণ ফাইল

2 · মূল নথি

যাচাইকারী কখনোই প্রমাণ ফাইল থেকে হ্যাশ নেয় না: সেটি আপনিই দেন।

প্যাকেজ ও হ্যাশ POST /api/verify/proof-এ পাঠানো হয়। অ্যাকাউন্ট লাগে না। সীমা: প্রতি ঘণ্টায় প্রতি IP-তে 120টি যাচাই।

এটি সার্টিফিকেট PDF-এ ছাপা থাকে ও Kaspa এক্সপ্লোরারে দেখা যায়।

অন্য ট্যাবে নথিটি টেনে ছেড়ে আপনি তা হিসাব করে নিতে পারেন: মানটি ভাগ করে নেওয়া হয়।

এই ধরনটি api.kaspa.org-এ জিজ্ঞাসা করে প্যাকেজটি আবার গড়ে তোলে। নোঙর করার পর প্রায় 40 ঘণ্টা পর্যন্তই Kaspa সম্পূর্ণ হেডার সরবরাহ করে: সেই সময় পেরোলে 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 script এবং স্টোরেজ-ভরের প্রতিশ্রুতিসহ)।

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 ছাড়াই করুন

রেফারেন্স যাচাইকারীটি বাইরের কোনো নির্ভরতা ছাড়া 248 লাইনের Python: এতে রয়েছে কি-যুক্ত 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/।

উদাহরণ হিসেবে ব্যবহৃত মানগুলি বাস্তব সার্টিফিকেটের এবং যে কেউ তা যাচাই করতে পারে। এই স্পেসিফিকেশনের সংস্করণ রাখা হয়: প্রমাণগুলি নিজেদের ভিতরেই জানিয়ে দেয় কোন সংস্করণে সেগুলি ইস্যু হয়েছিল।