Proovik
تصديق
أداة التحقق العامة · PVK-PROOF/1

كيف تتحقق من إثبات Proovik دون الوثوق بـ Proovik

تحتاج إلى ملف الإثبات (أو شهادة PDF) وإلى نسختك من المستند الأصلي. ولا يُرفَع أي شيء: تُحسَب البصمة في متصفحك. وفي الأسفل، المواصفة الكاملة، خطوة بخطوة وبقيم حقيقية.

الإصدار 1 الشبكة: Kaspa mainnet أداة التحقق المرجعية: 248 سطرًا من Python، بلا اعتماديات
الأداة

التحقق من إثبات عبر الإنترنت

افحص هنا شهادةً بالمحرّك نفسه الموصوف في الأسفل. المستند لا يغادر جهازك: تُحسَب بصمته SHA-256 في متصفحك ولا تنتقل سوى البصمة. وأنت من يقدّم البصمة، ولا تُؤخَذ أبدًا من ملف الإثبات. وإذا سحبت شهادة PDF، فإنّ حزمة الأدلة المرفقة تُستخرَج في متصفحك ولا يُرسَل ملف PDF أيضًا.

1 · ملف الإثبات

2 · المستند الأصلي

لا تأخذ أداة التحقق البصمة من ملف الإثبات أبدًا: فأنت من يقدّمها.

تُرسَل الحزمة والبصمة إلى POST /api/verify/proof. دون حساب. الحد: 120 عملية تحقق في الساعة لكل عنوان IP.

يظهر في شهادة PDF وفي مستكشف Kaspa.

يمكنك حسابها بسحب المستند في التبويب الآخر: فالقيمة مشتركة.

يعيد هذا الوضع بناء الحزمة بالاستعلام من api.kaspa.org. ولا تقدّم Kaspa الترويسة الكاملة إلا نحو 40 ساعة بعد الترسيخ: وبعد تلك المهلة لا يمكن إعادة حساب الحلقتين 3 و4 وسيكون الحُكم غير حاسم، ولن يكون أبدًا «يُثبت». وللتحقق الكامل استخدم ملف الإثبات الملتقَط في حينه.

GET /api/verify/proof/{txid}?hash=…. الحد: 30 في الساعة لكل عنوان IP (لأنّه يستعلم الشبكة).

الحُكم ·

مُثبَت غير حاسم غير مُثبَت

الحلقات الأربع متّسقة: فالمستند صاحب بصمة SHA-256 هذه كان موجودًا حين جرى تعدين الكتلة المشار إليها. وتذكّر ما لا يُثبته الإثبات: لا التأليف ولا صحة المحتوى.

ما أمكن إعادة حسابه متّسق، لكن تنقص بعض البيانات (عادةً ترويسة الكتلة الكاملة، خارج نافذة التشذيب) لإغلاق السلسلة. وليس هذا خللًا في الإثبات: إنّه تحقق جزئي. ويمكن إكماله بملف الإثبات الملتقَط في حينه، أو بحزمة الأدلة الكاملة.

حلقة واحدة على الأقل غير متّسقة مع البصمة المقدَّمة. والأكثر شيوعًا: أن يكون المستند ليس هو بالضبط ما جرى ختمه (فبايت واحد مختلف يغيّر SHA-256) أو ألّا يكون ملف الإثبات عائدًا إلى هذا المستند. راجِع تفاصيل كل حلقة.

عرض المعاملة في الشبكة
مستند
txid
block_hash
شبكة
وضع
ترويسة
مُتحقَّق منه

الحلقات، واحدة تلو الأخرى

  1. شاهد القبول (KIP-15)

    لا تتضمّن الحزمة شاهد قبول. وهو اختياري: لا يؤثر في الحُكم.

التنبيهات

ماذا تعني كل حلقة

نطاق الإثبات

ما الذي يُؤكَّد بالضبط

الدقة هنا أهم من البلاغة، لأنّ صمود الإثبات في المناقشة القضائية يتوقف على ذلك.

ما يُثبته الإثبات

أنّ سلسلة بايتات بصمتها SHA-256 قيمة محدَّدة قد أُدرِجت في معاملة على شبكة Kaspa، وأنّ تلك المعاملة صارت مثبَّتة داخل ترويسة كتلة، وأنّ إثبات عمل صحيحًا نُفِّذ على تلك الترويسة —التي تتضمّن طابعًا زمنيًا—. وبما أنّ الطابع الزمني موجود داخل البيانات التي جرى العمل عليها، فإنّ تعديله يُبطل العمل. والتاريخ ليس إقرارًا من أحد: إنّه مقدار فيزيائي أُنفِق فعلًا.

ما لا يُثبته الإثبات

من أنشأ المستند، ولا صحة محتواه، ولا ما إذا كان لمؤلفه حق إنشائه، ولا أنّ المستند لم يكن موجودًا من قبل. فهو يُثبت الأسبقية على لحظة بعينها، لا التأليف ولا الصحة. ولا ترى Proovik المستند في أي وقت: فهي لا تتسلّم سوى بصمته.

عن البصمة

SHA-256 دالة تلخيص بطول 256 بت. ولم يُتوصَّل قط إلى مستندين مختلفين لهما الملخّص نفسه، والجهد المقدَّر لذلك يتجاوز ما تستطيع البشرية حسابه. ولذلك، إذا تطابق ملخّص المستند المقدَّم مع الملخّص المسجَّل في السلسلة، فالمستند هو نفسه، دون هامش شك عملي.

مثال حقيقي · 2026-09-20

الحلقات الأربع

التحقق سلسلة. وكل حلقة ترتبط بالتالية، ويكفي أن تفشل واحدة ليفقد الإثبات قيمته. والقيم الواردة أدناه حقيقية: فهي تعود إلى شهادة صدرت في 20 سبتمبر 2026.

1 2 3 4

1 · بيانات المعاملة هي ملخّص المستند

يتطابق
ماذا يفحص
أنّ بصمة ملفك هي بالضبط تلك المسجَّلة في Kaspa.
لو فشل
لكان أحدهم قد غيّر المستند، ولو ببايت واحد.
كيف
تقبل كل معاملة في Kaspa حقلًا حرًا، payload. وتكتب Proovik هناك 32 بايت من بصمة SHA-256 للمستند، ولا شيء غير ذلك. والفحص مقارنة حرفية.
عرض الحساب 
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
تسلسل الأب2b3265225d51e5b051e46b9f164dc116cf2e21d566827abc8a7b1ae036d8330d
محسوب7843221eda25f05ddf9872ed57b59fb95c4f15aa7bf15017105e9797ef09caa5
في الترويسة7843221eda25f05ddf9872ed57b59fb95c4f15aa7bf15017105e9797ef09caa5
مَزلقان مُتحقَّق منهما

ترتيب المعاملات المقبولة هو الترتيب المعياري الذي تحدده KIP-15، لا الترتيب الذي تعيده واجهة API ولا الترتيب حسب البصمة. وأوراق شجرة الكتلة —عند التحقق من الإدراج بدلًا من القبول— ليست txid بل tx::hash، محسوبة بالترميز الكامل (بما في ذلك نصوص التوقيع والتزام حجم التخزين).

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 خدمة طابع زمني إلكتروني غير مؤهَّل بمفهوم المادة 3.16.i) من اللائحة (الاتحاد الأوروبي) 910/2014. ويجدر أن نكون صريحين بشأن ما يعنيه ذلك.

  • ووفقًا للمادة 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/.

القيم المستخدمة كأمثلة تعود إلى شهادات حقيقية ويمكن لأي شخص التحقق منها. وهذه المواصفة مُرقَّمة بإصدارات: فالإثباتات تشير في داخلها إلى الإصدار الذي صدرت به.