Prover (المُثبِت)

ما هو Prover في عالم العملات المشفرة؟

Prover هو شخص أو برنامج أو عقدة أو خدمة أو نظام أجهزة ينشئ إثباتًا تشفيريًا يبيّن صحة عبارة أو عملية حسابية أو مجموعة معاملات أو انتقال للحالة.

يُستخدم هذا المصطلح في العملات المشفرة غالبًا في إثباتات المعرفة الصفرية، وتجميعات التحقق (validity rollups)، وآلات zkVM الافتراضية، وبروتوكولات الخصوصية، وأنظمة الحوسبة القابلة للتحقق.

تتمثل مهمة Prover في تنفيذ العمليات الحسابية المكثفة اللازمة لإنشاء إثبات يستطيع طرف آخر التحقق منه بتكلفة أقل.

يُسمى هذا الطرف الآخر Verifier.

يمكن لـ Prover إثبات إجراء عملية حسابية على نحو صحيح من دون إجبار كل Verifier على إعادة تنفيذ العملية كاملة.

تكتسب هذه الفكرة أهمية في توسيع نطاق البلوكشين، إذ تحتاج البلوكشينات العامة إلى اتفاق عدد كبير من المشاركين على صحة تغييرات الحالة.

إذا اضطرّت كل عقدة إلى إعادة تنفيذ كل معاملة بالتفصيل، فقد تصبح الشبكة بطيئة ومكلفة.

تتيح أنظمة الإثبات لـ Prover تنفيذ عبء عمل كبير أو التحقق منه خارج السلسلة، ثم إرسال إثبات موجز على السلسلة.

توضح وثائق إثباتات المعرفة الصفرية في Ethereum أن الحوسبة القابلة للتحقق تتيح لعقدة تنفيذ معاملة خارج Ethereum وإرسال إثبات يبيّن صحة التنفيذ خارج السلسلة.

أبسط طريقة لفهم Prover هي اعتباره الجهاز أو الجهة التي تنشئ إيصالًا رياضيًا يثبت تنفيذ عملية حسابية على نحو صحيح.

كيف يعمل Prover؟

يبدأ Prover بعبارة مطلوب إثباتها.

قد تكون العبارة بسيطة، مثل إثبات معرفة قيمة سرية.

وقد تكون معقدة، مثل إثبات معالجة آلاف معاملات Layer 2 وفق قواعد البروتوكول.

ويستخدم Prover أيضًا مدخلات.

قد تكون بعض المدخلات عامة، أي يمكن لـ Verifier الاطلاع عليها.

وقد تكون مدخلات أخرى خاصة، أي يستخدمها Prover من دون الكشف عنها مباشرة.

تُسمى المدخلات الخاصة في كثير من أنظمة الإثبات «الشاهد» (witness).

بعد ذلك، يتبع Prover خوارزمية إثبات تحوّل العبارة والقيود والمدخلات العامة والشاهد إلى إثبات.

يكون الإثبات عادةً أصغر بكثير وأسهل في التحقق من العملية الحسابية الأصلية.

يتحقق Verifier من الإثبات باستخدام خوارزمية تحقق.

إذا كان الإثبات صحيحًا، يقبل Verifier صحة العبارة وفق قواعد نظام الإثبات.

يتيح ذلك للبلوكشينات الوثوق بنتيجة عملية حسابية من دون الوثوق شخصيًا بـ Prover.

Prover مقابل Verifier

يؤدي Prover وVerifier دورين متعاكسين في نظام الإثبات.

ينشئ Prover الإثبات.

أما Verifier فيتحقق من الإثبات.

تكون مهمة Prover أصعب عادةً، لأن إنشاء الإثبات قد يتطلب موارد حسابية كبيرة.

أما مهمة Verifier فتكون أسهل عادةً، إذ صُممت عملية التحقق من الإثبات لتكون سريعة ومنخفضة التكلفة.

يفيد هذا التفاوت البلوكشينات، إذ يمكن لـ Prover واحد تنفيذ عمليات مكثفة خارج السلسلة، بينما تتحقق عقد أو عقود ذكية عديدة من النتيجة بكفاءة.

في ZK-rollup، على سبيل المثال، قد ينشئ Prover إثبات صلاحية لمجموعة كبيرة من المعاملات.

بعد ذلك، يتحقق عقد Verifier على السلسلة من الإثبات قبل قبول تحديث حالة التجميعة.

توضح وثائق ZK-rollup في Ethereum أن ZK-rollups تستخدم إثباتات الصلاحية لتأكيد المعاملات على Ethereum.

لا يحتاج Verifier إلى الوثوق بنزاهة Prover، لأن الإثبات غير الصحيح يفترض أن يفشل في التحقق.

Prover مقابل Sequencer

Prover ليس هو نفسه Sequencer.

يرتب Sequencer المعاملات، ويساعد عادةً في إنشاء مجموعات المعاملات ضمن نظام التجميع.

أما Prover فينشئ الإثبات التشفيري على صحة المجموعة أو انتقال الحالة.

في بعض الأنظمة، قد تشغّل الجهة نفسها البنية التحتية للترتيب والإثبات معًا.

وفي أنظمة أخرى، قد تتوزع هاتان المهمتان بين خدمات أو عقد أو أسواق أو مشاركين من المجتمع مختلفين.

هذا التمييز مهم لأن ترتيب المعاملات وإثبات صحتها صلاحيتان مختلفتان.

يمكن لـ Sequencer التأثير في ترتيب المعاملات وزمن الاستجابة وتجربة المستخدم.

أما Prover فيمكنه التأثير في توافر الإثباتات وتوقيت الإنهاء وتكلفة البنية التحتية.

قد يكون التجميع سليمًا من الناحية التقنية، لكنه يظل معرضًا لمخاطر المركزية إذا اعتمد الإثبات على مشغّل واحد.

يدرس بحث حديث مثل بحث CrowdProve حول الإثبات المجتمعي كيفية توزيع أعمال الإثبات الخاصة بـ ZK rollups على عدد كبير من Provers الأصغر بدلًا من الاعتماد على بنية تحتية مركزية فقط.

Prover في إثباتات المعرفة الصفرية

في إثباتات المعرفة الصفرية، يحاول Prover إقناع Verifier بصحة عبارة ما من دون الكشف عن معلومات إضافية تتجاوز حقيقة العبارة.

قد يعرف Prover سرًا خاصًا أو بيانات معاملة خاصة أو سمة هوية خاصة أو نتيجة عملية حسابية خاصة أو شاهدًا خاصًا.

ينبغي ألا يكشف الإثبات إلا ما صُمم النظام لكشفه.

على سبيل المثال، قد يثبت مستخدم معرفته بكلمة مرور صحيحة من دون الكشف عنها.

وفي عالم العملات المشفرة، قد يثبت المستخدم امتثال معاملة للقواعد من دون كشف جميع تفاصيلها الخاصة.

ليست الخصوصية الهدف الأساسي لكل إثبات يُستخدم في التجميعات.

تستخدم كثير من التجميعات إثباتات الصلاحية أساسًا لزيادة قابلية التوسع وضمان الصحة، لا لإخفاء تفاصيل المعاملات كلها.

لذلك يستخدم بعض الأشخاص مصطلح «إثبات الصلاحية» الأوسع عندما يتعلق الإثبات بصحة التنفيذ، لا بالخصوصية الكاملة.

يظل Prover هو المكوّن الذي ينتج الإثبات.

ويتوقف استخدام الإثبات للخصوصية أو التوسع أو كليهما على تصميم البروتوكول.

Prover في ZK-Rollups

في ZK-rollup، ينشئ Prover إثباتًا على معالجة مجموعة من المعاملات خارج السلسلة بصورة صحيحة.

ينفذ التجميع معاملات عديدة بعيدًا عن السلسلة الأساسية.

ثم يرسل بيانات مضغوطة وإثبات صلاحية إلى السلسلة الأساسية.

تتحقق السلسلة الأساسية من الإثبات بدلًا من إعادة تنفيذ كل معاملة في المجموعة.

يمكن أن يقلل ذلك العمليات الحسابية على السلسلة ويحسن قابلية التوسع.

يُعد Prover من أهم مكونات ZK-rollup، لأن المستخدمين يعتمدون على الإثباتات لتأكيد تحديثات الحالة.

إذا كان إنشاء الإثبات بطيئًا، فقد يتأخر الإنهاء.

إذا كان إنشاء الإثبات مكلفًا، فقد ترتفع تكاليف تشغيل التجميع.

إذا كانت عملية إنشاء الإثبات مركزية، فقد يعتمد التجميع بدرجة مفرطة على مزود بنية تحتية واحد.

إذا تعذر إنشاء الإثبات، فقد يواجه التجميع صعوبة في إرسال تحديثات حالة جديدة وصحيحة.

لذلك، يُعد تصميم Prover وأداؤه ولامركزيته وموثوقيته من الموضوعات الرئيسية في تطوير Layer 2.

Prover في zkVMs

zkVM هي آلة افتراضية للمعرفة الصفرية يمكنها إثبات التنفيذ الصحيح للبرامج.

بدلًا من كتابة دائرة مخصصة لكل مهمة، يمكن للمطورين تشغيل التعليمات البرمجية داخل آلة افتراضية وإنشاء إثبات على تنفيذها بصورة صحيحة.

تصف وثائق مطوري RISC Zero الحوسبة القابلة للتحقق بأنها وسيلة للتحقق تشفيريًا من أن خوارزمية محددة أنتجت مخرجات بيانات معينة.

في zkVM، يشغّل Prover البرنامج ويسجل تنفيذه وينشئ إثباتًا لهذا التنفيذ.

بعد ذلك، يستطيع Verifier التحقق من الإثبات من دون إعادة تشغيل البرنامج كاملًا.

قد يجعل هذا النموذج تطوير ZK أكثر سهولة، إذ يمكن للمطورين استخدام لغات برمجة مألوفة أو أهداف الآلات الافتراضية.

يمكن استخدام Provers الخاصة بـ zkVM في التجميعات والجسور وأنظمة الهوية وتطبيقات الخصوصية وسير عمل الذكاء الاصطناعي القابل للتحقق والألعاب القابلة للتحقق والحوسبة خارج السلسلة.

لكن عملية الإثبات في zkVM قد تتطلب موارد كبيرة.

يعتمد الأداء على حجم البرنامج واستخدام الذاكرة ونظام الإثبات والأجهزة وتصميم التكرار وخيارات التحسين.

Prover في أنظمة STARK

تستخدم الأنظمة القائمة على STARK نوعًا من الإثبات يمكن التحقق منه من دون الاعتماد على افتراضات الإعداد الموثوق نفسها التي تستخدمها بعض أنظمة الإثبات الأخرى.

في نظام STARK، يحوّل Prover عملية حسابية إلى إثبات يستند إلى قيود جبرية وبيانات سجل التنفيذ.

يمكن للإثبات أن يبيّن امتثال برنامج أو مجموعة معاملات للقواعد المطلوبة.

تصف وثائق SHARP في Starknet عقود Verifier على السلسلة التي تتحقق من إثباتات STARK التي ينشئها SHARP.

يُعد SHARP مثالًا على بنية تحتية مشتركة للإثبات، يمكنها تجميع عمليات تنفيذ برامج أو تطبيقات متعددة وإثباتها.

تشتهر Provers الخاصة بـ STARK بخصائصها القوية في قابلية التوسع ومزايا الشفافية.

وقد تنتج أيضًا إثباتات أكبر من بعض أنظمة SNARK، بحسب طريقة البناء.

وكما هو الحال مع أي نظام إثبات، تعتمد المفاضلات العملية على وقت الإثبات وتكلفة التحقق وحجم الإثبات والافتراضات الأمنية وتجربة المطور.

يتولى Prover جانبًا كبيرًا من هذا التعقيد التقني، كي يتمكن Verifier من التحقق من إثبات موجز.

Prover في أنظمة SNARK

تستخدم أنظمة SNARK إثباتات موجزة قد تكون صغيرة جدًا وسريعة التحقق.

ينشئ Prover في نظام SNARK إثباتًا مضغوطًا على توافق عملية حسابية مع مجموعة من القيود.

تتطلب أنظمة SNARK كثيرة إعدادًا موثوقًا، وإن كانت تصميمات أحدث قد تقلل هذا المتطلب أو تغيره.

يحتاج Prover في SNARK غالبًا إلى مفتاح إثبات يُنشأ أثناء الإعداد.

ويستخدم Verifier مفتاح تحقق لفحص الإثبات.

قد تكون Provers الخاصة بـ SNARK مفيدة عندما يجب أن تكون تكلفة التحقق على السلسلة منخفضة جدًا.

وهذا مهم لأن بلوكشينات الطبقة الأساسية تفرض رسومًا على العمليات الحسابية والتخزين.

يمكن لإثبات صغير ومنخفض التكلفة في التحقق أن يجعل التطبيقات المتقدمة أكثر قابلية للتطبيق.

ومع ذلك، قد يظل إنشاء الإثبات مكلفًا على Prover.

يجب أن يوازن تصميم التطبيقات القائمة على SNARK بين حجم الإثبات ووقت إنشائه وافتراضات الإعداد الموثوق وتعقيد التطوير.

الشاهد والمدخلات العامة والخاصة

يتعامل Prover عادةً مع مدخلات عامة وأخرى خاصة.

المدخلات العامة قيم يُسمح لـ Verifier بالاطلاع عليها.

أما المدخلات الخاصة فهي قيم يستخدمها Prover من دون الكشف عنها مباشرة.

يُسمى الإدخال الخاص غالبًا «الشاهد».

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

في إثبات تجميعة، قد تشمل المدخلات العامة جذور الحالة القديمة والجديدة والتزامات المجموعة أو معلمات البروتوكول.

وقد يشمل الشاهد تفاصيل المعاملات أو سجلات التنفيذ أو مسارات Merkle أو التوقيعات أو بيانات الحساب الوسيطة، بحسب التصميم.

يستخدم Prover الشاهد لإنشاء الإثبات.

ويتحقق Verifier من توافق الإثبات مع المدخلات العامة.

ينبغي ألا يسمح نظام الإثبات الآمن لـ Prover بإنشاء إثبات صحيح لعبارة زائفة.

الدوائر والقيود

تتطلب أنظمة إثبات كثيرة التعبير عن العملية الحسابية في صورة دائرة أو مجموعة قيود.

تصف الدائرة ما يجب إثباته بصيغة يفهمها نظام الإثبات.

وتحدد القيود القواعد التي يجب أن تستوفيها المدخلات الصحيحة وخطوات الحساب.

على سبيل المثال، قد تشترط الدائرة احتساب التجزئة بصورة صحيحة، أو صحة التوقيع، أو امتثال تحديث الرصيد لقواعد البروتوكول.

يجب على Prover إثبات وجود شاهد يستوفي جميع القيود.

إذا لم يستوفِ الشاهد القيود، فينبغي ألا يتمكن Prover من إنشاء إثبات صحيح.

يُعد تصميم الدوائر من أصعب جوانب تطوير ZK.

قد تثبت دائرة مكتوبة بصورة سيئة شيئًا غير المقصود عن طريق الخطأ.

وقد تكون الدائرة صحيحة لكنها غير فعالة، ما يجعل عملية الإثبات بطيئة أو مكلفة.

غالبًا ما يبدأ تحسين أداء Prover بتصميم جيد للدائرة.

سجلات التنفيذ

تستخدم بعض أنظمة الإثبات سجلات التنفيذ بدلًا من الدوائر التقليدية المخصصة للتطبيق.

سجل التنفيذ هو توثيق لخطوات الحساب التي ينفذها برنامج أو آلة افتراضية.

يستخدم Prover السجل لإثبات امتثال كل خطوة لقواعد الآلة أو البروتوكول.

هذا النموذج شائع في أنظمة STARK وzkVM.

قد يصبح إنشاء السجل عائقًا رئيسيًا أمام الأداء، لأن البرامج الكبيرة قد تنتج سجلات ضخمة.

ركزت الأبحاث الحديثة حول آلات ZK الافتراضية على تحسين إنشاء السجلات وخطوط أنابيب الإثبات وتسريع الأجهزة.

تساعد السجلات الفعالة على خفض تكلفة Prover وزمن الاستجابة.

في التجميعات، قد يؤدي تسريع إنشاء السجل إلى إرسال الإثبات بسرعة أكبر وتسوية المعاملات في وقت أقصر.

وفي التطبيقات، يمكن للسجلات الأسرع أن تجعل الحوسبة القابلة للتحقق أكثر عملية للمستخدمين الفعليين.

يتولى Prover تحويل التنفيذ الخام إلى بيانات جاهزة للإثبات.

أداء Prover

يُعد أداء Prover من أهم التحديات العملية في أنظمة العملات المشفرة القائمة على المعرفة الصفرية.

قد يتطلب إنشاء الإثبات موارد كبيرة من وحدة المعالجة المركزية (CPU) ووحدة معالجة الرسومات (GPU) والذاكرة والتخزين والأجهزة المتخصصة.

بعض أنظمة الإثبات أسرع في إنشاء الإثبات، لكنها أبطأ في التحقق منه.

وبعضها أبطأ في إنشاء الإثبات، لكنه ينتج إثباتات أصغر أو أقل تكلفة.

تخصص فرق التجميعات جهدًا هندسيًا كبيرًا لتحسين خطوط أنابيب Prover.

يمكن لـ Prover الأسرع تقليل تأخير التسوية.

ويمكن لـ Prover الأقل تكلفة خفض تكاليف المستخدمين.

كما يمكن لـ Prover الأعلى قابلية للتوسع دعم عدد أكبر من المعاملات والتطبيقات الأكثر تعقيدًا.

يؤثر أداء Prover أيضًا في اللامركزية، لأن متطلبات الأجهزة الباهظة جدًا قد تحد من عدد المشاركين القادرين على تشغيل Provers.

وقد يزيد ذلك اعتماد الشبكة على مشغّلين متخصصين.

لامركزية Prover

تعني لامركزية Prover أن جهة واحدة لا تتحكم في إنشاء الإثباتات.

غالبًا ما تكون البنية التحتية للإثبات مركزية في أنظمة ZK المبكرة بسبب تعقيد التقنية وارتفاع تكاليف تشغيلها.

ومع مرور الوقت، تسعى مشاريع كثيرة إلى توزيع عملية الإثبات على جهات أكثر.

قد يشمل الإثبات الموزع عدة Provers أو أسواق إثبات أو شبكات إثبات مشتركة أو إثباتًا مجتمعيًا أو منافسة بين مزودي الأجهزة.

يمكن أن يقلل الإثبات اللامركزي مخاطر الرقابة وتعطل التشغيل والاعتماد على مشغّل واحد.

لكنه يطرح أيضًا تحديات في التنسيق.

يجب على النظام إسناد مهام الإثبات، والتحقق من عمل Prover، ودفع مستحقاته، ومنع الرسائل غير المرغوب فيها، ومعالجة المهام الفاشلة، وحماية بيانات الشاهد الحساسة عند الحاجة.

تبحث دراسات الإثبات المجتمعي في إمكانية مساهمة عدد كبير من الأجهزة الصغيرة في إنشاء إثباتات للتجميعات.

قد يجعل ذلك البنية التحتية للإثبات أكثر انفتاحًا إذا نجحت الجوانب الاقتصادية والأمنية.

ولا تقتصر لامركزية Prover على الجانب التقني، إذ تعتمد أيضًا على الحوافز والحوكمة وإمكانية الوصول إلى الأجهزة وسهولة استخدام البرمجيات.

أسواق Prover

سوق Prover هو نظام تتنافس فيه Provers المختلفة أو تتعاون لإنشاء إثباتات للتطبيقات.

قد ترسل تجميعة أو جسر أو تطبيق zkVM أو نظام خصوصية مهمة إثبات إلى شبكة من Provers.

وقد تقدم Provers عروضًا لتنفيذ المهمة أو يجري اختيارها وفق قواعد البروتوكول.

بعد أن ينشئ Prover إثباتًا صحيحًا، قد يحصل على مقابل.

يمكن لأسواق Prover خفض التكاليف عبر تشجيع المنافسة.

كما قد تحسن الموثوقية لأن التطبيقات لا تقتصر على خادم إثبات واحد.

لكن هذه الأسواق تحتاج إلى تحقق قوي، إذ يجب على النظام رفض الإثباتات غير الصحيحة ومعالجة العمل الفاشل.

كما تحتاج إلى حماية الخصوصية عندما تتضمن مهام الإثبات بيانات شاهد حساسة.

يمكن الاستعانة بجهات خارجية بأمان في بعض مهام الإثبات التي تستخدم بيانات عامة فقط.

أما المهام الأخرى فقد تتطلب حوسبة سرية أو شهودًا مشفرين أو أجهزة موثوقة أو تصميمًا دقيقًا للبروتوكول.

الإثبات التكراري

يعني الإثبات التكراري استخدام إثبات للتحقق من إثبات آخر، ثم إثبات صحة عملية التحقق هذه.

قد تبدو الفكرة مجردة، لكنها مفيدة جدًا في أنظمة التوسع.

يمكن لـ Prover إنشاء إثباتات صغيرة عديدة ثم دمجها في إثبات واحد أكبر.

قد يخفض ذلك تكلفة التحقق ويقلل كمية البيانات المرسلة على السلسلة.

يمكن للإثباتات التكرارية مساعدة التجميعات على ضم مجموعات عديدة من المعاملات.

كما يمكنها مساعدة zkVMs على إثبات عمليات حسابية طويلة على مراحل أصغر.

قد يحسن الإثبات التكراري قابلية التوسع، لكنه يضيف تعقيدًا تقنيًا.

يجب أن يدير مسار عمل Prover تركيب الإثباتات ودوائر التحقق وجداول التجميع والمفاضلات المتعلقة بالأداء.

وقد يؤثر تصميم الإثبات التكراري أيضًا في زمن الاستجابة، لأن الإثبات النهائي قد يعتمد على اكتمال الإثباتات السابقة أولًا.

غالبًا لا يلاحظ المستخدمون الإثبات التكراري، لكنه قد يؤثر في السرعة والرسوم والإنهاء.

تجميع الإثباتات

تجميع الإثباتات هو عملية دمج إثباتات متعددة في إثبات واحد أو عملية تحقق واحدة.

قد يأخذ Prover أو مجمّع عددًا من الإثباتات الفردية وينشئ إثباتًا واحدًا يمثلها كلها.

قد يقلل ذلك تكاليف التحقق على السلسلة، لأن السلسلة الأساسية تتحقق من إثبات مجمّع واحد بدلًا من إثباتات منفصلة عديدة.

يفيد التجميع في التجميعات ومجمعات الخصوصية والتسويات المجمعة وأنظمة المراسلة بين السلاسل.

كما قد يدعم البنية التحتية المشتركة للإثبات، بحيث تستفيد تطبيقات متعددة من خط أنابيب الإثبات نفسه.

لكن المقابل هو احتمال إضافة تأخير، لأن النظام قد ينتظر جمع عدد كافٍ من الإثباتات لضمها معًا.

وقد ينشأ أيضًا اعتماد على المجمّع أو خدمة الإثبات المشتركة.

يوازن التصميم الجيد للتجميع بين الكفاءة وزمن الاستجابة واللامركزية والموثوقية.

يُعد تجميع الإثباتات أحد أسباب تحول Provers إلى طبقة بنية تحتية مهمة في عالم العملات المشفرة.

كلما زاد استخدام التطبيقات لإثباتات ZK، ازدادت أهمية التجميع الفعال.

استمرارية عمل Prover

تعني استمرارية عمل Prover قدرة نظام الإثبات على مواصلة إنتاج الإثباتات عند الحاجة.

إذا احتاجت تجميعة إلى إثباتات لتأكيد المجموعات، فقد يؤدي تعطل Prover إلى تأخير التسوية.

وإذا احتاج جسر إلى إثباتات لإتاحة الأموال، فقد يؤدي تعطل Prover إلى تأخير السحب.

وإذا احتاج تطبيق خصوصية إلى إثباتات لتنفيذ إجراءات المستخدمين، فقد يمنع تعطل Prover المستخدمين من إتمام معاملاتهم.

لا تقتصر استمرارية العمل على الأمان الرياضي لنظام الإثبات.

بل تشمل أيضًا قدرة البنية التحتية الفعلية على مواصلة التشغيل في ظل ضغط العمل والانقطاعات والهجمات وأعطال الأجهزة.

يمكن تعزيز استمرارية عمل Prover عبر التكرار والإثبات الموزع وقوائم انتظار المهام وProvers احتياطية والمراقبة وإجراءات الطوارئ الواضحة.

ينبغي للمستخدمين إدراك أن نظام ZK قد يقلل الحاجة إلى الثقة في صحة النتائج، لكنه يظل معتمدًا على بنية الإثبات التحتية لضمان التشغيل في الوقت المناسب.

لا يفيد الإثبات الصحيح إذا لم ينشئه أحد.

لذلك، تُعد عمليات Prover جزءًا من موثوقية البروتوكول.

سلامة Prover

السلامة (Soundness) هي خاصية تمنع Prover غير النزيه من إقناع Verifier بصحة عبارة زائفة.

تُعد السلامة أساسية في العملات المشفرة، لأن الإثبات الزائف قد يسمح بانتقالات حالة غير صحيحة أو عمليات سحب مزيفة أو أرصدة خاطئة أو إجراءات غير مصرح بها.

قد يكون نظام الإثبات خطرًا حتى لو كان سريعًا، إذا كانت سلامته ضعيفة.

تعتمد السلامة على الافتراضات التشفيرية وجودة التنفيذ واختيار المعلمات وصحة الدائرة وصحة Verifier.

قد يكون Prover خبيثًا، لكن ينبغي لـ Verifier رفض الإثباتات غير الصحيحة.

وهذا هو السبب الأساسي لقوة أنظمة الإثبات.

لا يحتاج البروتوكول إلى الوثوق بنزاهة Prover.

بل يحتاج فقط إلى أمان نظام الإثبات وVerifier.

لكن إذا أثبتت الدائرة عبارة خاطئة، فقد يكون الإثبات صحيحًا بالنسبة إلى الدائرة، من دون أن يحمي التطبيق.

لذلك يجب مراعاة السلامة على مستوى نظام الإثبات وعلى مستوى تصميم التطبيق.

اكتمال Prover

يعني الاكتمال (Completeness) أن Prover النزيه ينبغي أن يتمكن من إنشاء إثبات لعبارة صحيحة.

إذا كانت العملية الحسابية صحيحة وكان لدى Prover الشاهد المناسب، فينبغي لنظام الإثبات إنشاء إثبات يقبله Verifier.

الاكتمال مهم، لأن النظام الذي يرفض إثباتات صحيحة أو لا يستطيع إنشاءها بموثوقية لا يصلح للاستخدام.

في التجميعات، قد يعني ضعف الاكتمال تعذر تأكيد مجموعات معاملات صحيحة.

وفي تطبيقات الخصوصية، قد يعني عدم قدرة المستخدمين النزهاء على إثبات إجراءات صحيحة.

وفي zkVMs، قد يعني فشل البرامج الصحيحة في الحصول على إثبات بسبب أخطاء التنفيذ أو محدودية الموارد.

يعتمد الاكتمال على صحة البرمجيات وتوافر ذاكرة كافية وقدرة حسابية كافية ومعلمات إثبات متوافقة وبنية تحتية مستقرة.

عمليًا، يختبر المطورون أنظمة الإثبات على نطاق واسع للتأكد من إمكانية إثبات أعباء العمل الصحيحة بموثوقية.

يجب أن يكون Prover آمنًا ضد الإثباتات الزائفة وعمليًا لإثبات العبارات الصحيحة.

ويوازن التصميم الجيد لـ Prover بين الأمان وسهولة الاستخدام.

خاصية المعرفة الصفرية في Prover

خاصية المعرفة الصفرية هي أن الإثبات لا يكشف معلومات غير ضرورية تتجاوز صحة العبارة المطلوب إثباتها.

تكتسب هذه الخاصية أهمية عندما يتضمن الشاهد بيانات خاصة.

قد يعرف Prover مفتاحًا سريًا أو قيمة معاملة مخفية أو سمة هوية خاصة أو مدخلًا سريًا لعملية حسابية.

ينبغي لإثبات المعرفة الصفرية أن يتيح لـ Prover إثبات الادعاء المطلوب من دون كشف السر.

لكن ليس كل إثبات صلاحية مستخدم في العملات المشفرة بحاجة إلى خصوصية قوية.

تستخدم بعض الأنظمة تقنية الإثبات أساسًا لخفض تكلفة التحقق.

عندما تكون الخصوصية مطلوبة، يجب على المطورين تصميم الدوائر والمدخلات العامة والتعامل مع البيانات الوصفية وواجهات المستخدم بعناية.

قد يكون الإثبات من نوع المعرفة الصفرية، بينما تظل البيانات المحيطة به كاشفة للمعلومات.

على سبيل المثال، قد يكشف التوقيت أو عناوين المحافظ أو بيانات IP أو أنماط المعاملات عن سلوك المستخدم.

يمكن لـ Prover حماية الشاهد رياضيًا، لكن على التطبيق بأكمله حماية الخصوصية على مستوى التشغيل.

أجهزة Prover

قد تستخدم Provers وحدات CPU أو GPU أو FPGA أو ASIC أو البنية التحتية السحابية، بحسب نظام الإثبات وعبء العمل.

قد ينطوي إنشاء الإثبات على عمليات رياضية كبيرة مثل الحساب في الحقول المنتهية والتزامات كثيرات الحدود والتجزئة وتحويلات فورييه السريعة ومعالجة سجلات التنفيذ.

يمكن أن تستفيد هذه المهام من المعالجة المتوازية والأجهزة المتخصصة.

قد يقلل تسريع الأجهزة وقت الإثبات وتكلفته.

لكنه قد يزيد أيضًا الضغط نحو المركزية إذا كان مشغّلون ممولون جيدًا وحدهم قادرين على تحمل تكلفة أفضل أجهزة الإثبات.

تحاول بعض المشاريع الحد من هذه المشكلة بتحسين كفاءة البرمجيات ودعم الأجهزة المتاحة تجاريًا.

وتستخدم مشاريع أخرى مجموعات إثبات متخصصة لتحقيق إنتاجية مرتفعة.

تعتمد المفاضلة المتعلقة بالأجهزة على أهداف الشبكة.

قد يقبل النظام المصمم لتحقيق أقصى إنتاجية ببنية إثبات أكثر تخصصًا.

أما النظام المصمم لتوسيع المشاركة، فقد يعطي الأولوية لتصاميم Prover القابلة للتشغيل على أجهزة يسهل الوصول إليها.

رسوم Prover والاقتصاديات

يتطلب تشغيل Provers إنفاق المال.

فهي تحتاج إلى أجهزة وكهرباء ونطاق ترددي وهندسة وصيانة ومراقبة.

في التجميعة، قد تُغطى تكاليف الإثبات من رسوم المعاملات أو إيرادات البروتوكول أو الإعانات أو أموال المشغّل.

وفي سوق Prover، قد تُدفع مستحقات Provers مباشرة مقابل مهام الإثبات المكتملة.

تكتسب اقتصاديات Prover أهمية لأن ارتفاع تكاليف الإثبات قد يؤدي إلى زيادة رسوم المستخدمين.

كما قد يحد من أنواع التطبيقات القابلة للتطبيق.

قد لا تعمل لعبة أو تطبيق اجتماعي أو نظام دفع منخفض القيمة جيدًا إذا تطلب كل إجراء إثباتًا مكلفًا.

غالبًا ما يحسّن المطورون الدوائر ويجمعون أعباء العمل ويجمعون الإثباتات ويستخدمون التكرار لخفض تكلفة الإثبات لكل معاملة.

قد لا يرى المستخدمون رسوم Prover مباشرة، لكنهم قد يشعرون بأثرها عبر تكاليف المعاملات أو تأخر التسوية أو قيود التطبيق.

يُعد الإثبات الفعال أحد مفاتيح انتشار تطبيقات ZK على نطاق واسع.

مخاطر أمان Prover

أول مخاطر Prover هي أخطاء التنفيذ.

قد ينشئ Prover الذي يحتوي على أخطاء إثباتات غير صحيحة، أو يفشل تحت ضغط العمل، أو يكشف بيانات الشاهد الحساسة.

الخطر الثاني هو مركزية الإثبات.

إذا كان مشغّل واحد فقط قادرًا على إنشاء الإثباتات، فقد يتعرض النظام للتعطل أو الرقابة إذا أخفق ذلك المشغّل.

الخطر الثالث هو تسرب الشاهد.

إذا تلقت خدمة الإثبات مدخلات خاصة، فقد يؤدي ضعف الأمان إلى كشف بيانات المستخدمين.

الخطر الرابع هو أخطاء الدوائر.

يمكن لـ Prover إنشاء إثبات صحيح لدائرة غير صحيحة إذا لم تفرض الدائرة القواعد المقصودة.

الخطر الخامس هو اختراق الأجهزة.

قد تكشف أجهزة الإثبات المخترقة الأسرار أو تؤخر المهام أو تهاجم البنية التحتية للتطبيق.

الخطر السادس هو الإخفاق الاقتصادي.

إذا لم يحصل Provers على مقابل كافٍ، فقد تصبح قدرة الإثبات غير كافية.

الخطر السابع هو مخاطر التحديث.

قد تؤدي التغييرات في برمجيات الإثبات أو الدوائر أو عقود Verifier إلى ثغرات جديدة.

Prover وتوافر البيانات

يثبت Prover صحة العملية، لكنه لا يضمن تلقائيًا توافر البيانات.

يعني توافر البيانات إمكانية وصول المستخدمين أو العقد إلى بيانات المعاملات أو الحالة اللازمة لإعادة بناء حالة النظام أو التحقق منها.

هذا التمييز مهم في التجميعات.

قد يثبت إثبات الصلاحية صحة انتقال الحالة، لكن المستخدمين يحتاجون أيضًا إلى بيانات كافية لمعرفة أرصدتهم أو الخروج من مراكزهم أو إعادة بناء الحالة.

تعالج تصاميم التجميع والتوسع المختلفة توافر البيانات بطرق مختلفة.

يرسل بعضها البيانات إلى سلسلة أساسية.

ويستخدم بعضها طبقات منفصلة لتوافر البيانات.

ويستخدم بعضها لجانًا أو نماذج أخرى.

مسؤولية Prover هي إثبات عبارة، لا حل كل مشكلة تتعلق بتوافر البيانات بمفرده.

يحتاج نظام التوسع الآمن إلى إثباتات صحيحة وبيانات متاحة معًا.

Prover والإنهاء

يعني الإنهاء قبول معاملة أو تحديث حالة بوصفه مستقرًا وفق قواعد الشبكة.

في الأنظمة القائمة على الصلاحية، قد يؤثر إنشاء الإثبات في توقيت الإنهاء.

قد تُنفذ مجموعة معاملات بسرعة على Layer 2، بينما تنتظر التسوية النهائية على السلسلة الأساسية إثباتًا.

إذا كان Prover سريعًا، فقد تتم التسوية في وقت أقرب.

وإذا كان بطيئًا أو مثقلًا بالعمل، فقد ينتظر المستخدمون مدة أطول للحصول على التأكيد النهائي أو السحب.

قد يحسن الإثبات التكراري وتجميع الإثباتات الكفاءة، لكنهما قد يضيفان تأخيرًا بسبب تجميع المعاملات.

يعتمد الإنهاء أيضًا على زمن الكتلة في السلسلة الأساسية وقواعد التأكيد وتنفيذ عقد Verifier.

يمثل Prover جزءًا واحدًا فقط من مسار الإنهاء.

ومع ذلك، تُعد سرعة Prover غالبًا أحد أبرز العوائق أمام أداء أنظمة ZK.

يمكن لـ Provers الأفضل جعل تطبيقات ZK أسرع وأكثر موثوقية في نظر المستخدمين.

Prover والجسور

يمكن استخدام Provers في الجسور لإثبات أحداث أو انتقالات حالة أو رسائل من سلسلة إلى أخرى.

قد يتيح الجسر القائم على الإثبات لسلسلة ما التحقق من معلومات تخص سلسلة أخرى من دون الوثوق بمجموعة موقّعين مركزية.

على سبيل المثال، قد ينشئ Prover إثباتًا على صحة معاملة أو جذر حالة أو رسالة معينة على سلسلة المصدر.

وبعد ذلك، يمكن لعقد Verifier على سلسلة الوجهة التحقق من الإثبات.

قد يقلل ذلك افتراضات الثقة مقارنة ببعض نماذج الجسور.

لكن الجسور القائمة على الإثبات تظل معقدة.

فهي مطالبة بالتعامل مع إعادة تنظيم السلسلة وافتراضات الإنهاء وصحة Verifier وتوافر البيانات وتكلفة الإثبات ومخاطر التحديث.

يمكن لـ Prover تحسين افتراضات الثقة في الجسر، لكنه لا يجعل تصميمه آمنًا تلقائيًا.

ينبغي للمستخدمين مواصلة التعامل مع الأنظمة العابرة للسلاسل بوصفها بنية تحتية عالية المخاطر.

يعتمد أمان الجسر على بنيته الكاملة، لا على وجود Prover وحده.

Prover والخصوصية

في تطبيقات العملات المشفرة التي تركز على الخصوصية، يمكن لـ Prover مساعدة المستخدمين على إثبات امتثالهم للقواعد مع إبقاء المعلومات الحساسة مخفية.

على سبيل المثال، قد يثبت المستخدم امتلاكه وثيقة اعتماد من دون الكشف عنها كاملة.

وقد يثبت صحة رصيد معاملة من دون كشف جميع تفاصيلها الخاصة.

كما قد يثبت انتماءه إلى مجموعة من دون الكشف عن هويته بين أعضائها.

ينشئ Prover الإثبات باستخدام مدخلات خاصة.

ويتحقق Verifier من الإثبات باستخدام قواعد عامة.

يتيح ذلك الإفصاح الانتقائي.

لكن الخصوصية تعتمد على ما هو أكثر من الإثبات نفسه.

فقد تكشف البيانات الوصفية ونشاط الشبكة والتوقيت وإعادة استخدام العناوين وبصمة المتصفح وسجلات التطبيق معلومات عن المستخدم.

يجب أن يحمي نظام الخصوصية القوي رحلة المستخدم كاملة، لا الشاهد التشفيري وحده.

Prover والامتثال

يمكن لـ Provers دعم تصميمات متوافقة مع المتطلبات في عالم العملات المشفرة، عبر إثبات معلومات من دون الكشف عن بيانات خاصة غير ضرورية.

على سبيل المثال، قد يثبت المستخدم استيفاءه شرط أهلية من دون نشر وثيقة هويته كاملة على السلسلة.

وقد يثبت بروتوكول امتثال عملية حسابية لمجموعة قواعد من دون كشف بيانات الأعمال الخاصة.

وقد يثبت تطبيق مالي امتثال انتقال حالة لقيود محاسبية من دون نشر جميع السجلات الداخلية.

لكن هذا لا يعني أن إثباتات المعرفة الصفرية تحل جميع مشكلات الامتثال تلقائيًا.

تختلف المتطلبات القانونية بحسب الولاية القضائية وحالة الاستخدام.

وقد تظل بعض القواعد تقتضي حفظ السجلات أو إجراء عمليات تدقيق أو التحقق من الهوية أو تقديم تقارير أو إفصاحات.

يمكن لـ Prover الحد من الكشف غير الضروري عن البيانات، لكنه لا يغني عن التحليل القانوني.

ينبغي أن يجمع التصميم الجيد للامتثال بين التشفير والسياسات والحوكمة وموافقة المستخدم.

يمكن لـ Provers إتاحة التحقق الانتقائي، لكن البشر يظلون مسؤولين عن تحديد ما يجب إثباته.

فوائد Provers

الفائدة الأولى لـ Prover هي قابلية التوسع.

يمكنه ضغط العمليات الحسابية الكبيرة في إثباتات أقل تكلفة للتحقق.

الفائدة الثانية هي الخصوصية.

يمكنه إثبات معلومات عن بيانات خاصة من دون الكشف عن البيانات نفسها، عندما يُصمم نظام الإثبات لتوفير المعرفة الصفرية.

الفائدة الثالثة هي تقليل الحاجة إلى الثقة.

لا يحتاج Verifiers إلى الوثوق بنزاهة Prover إذا كانت الإثباتات غير الصحيحة تُرفض.

الفائدة الرابعة هي قابلية التشغيل البيني.

يمكن للإثباتات مساعدة نظام على التحقق من معلومات تخص نظامًا آخر.

الفائدة الخامسة هي قابلية التدقيق.

يمكن للإثبات تقديم دليل رياضي على امتثال عملية حسابية لقواعد محددة.

الفائدة السادسة هي الأتمتة.

يمكن للعقود الذكية التحقق من الإثباتات واتخاذ الإجراءات بناءً عليها من دون مراجعة يدوية.

الفائدة السابعة هي الكفاءة.

يمكن لتجميع الإثباتات والتكرار تقليل تكاليف التحقق المتكرر عبر معاملات أو تطبيقات عديدة.

قيود Provers

القيد الأول هو التكلفة.

قد يتطلب إنشاء الإثباتات موارد حسابية كبيرة.

القيد الثاني هو زمن الاستجابة.

قد يستغرق إنشاء الإثبات وقتًا، ما قد يؤخر التسوية أو السحب.

القيد الثالث هو التعقيد.

تتطلب أنظمة Prover خبرة متخصصة في التشفير والهندسة ومراجعة الأمان.

القيد الرابع هو الضغط نحو المركزية.

قد تجعل متطلبات الأجهزة المرتفعة تشغيل Provers صعبًا على عدد كبير من الجهات المستقلة.

القيد الخامس هو الاعتماد على الدائرة.

لا يثبت الإثبات إلا ما تتحقق منه الدائرة أو البرنامج فعليًا.

القيد السادس هو تسرب الخصوصية خارج نطاق الإثبات.

لا يخفي إثبات المعرفة الصفرية البيانات الوصفية أو عيوب تصميم التطبيق تلقائيًا.

القيد السابع هو مخاطر التحديث.

قد يؤدي تغيير برمجيات الإثبات أو الدوائر أو عقود Verifier إلى افتراضات أمنية جديدة.

كيف ينبغي للمستخدمين فهم Provers؟

لا يتعامل معظم المستخدمين مع Provers مباشرة.

بل يستخدمون محافظ أو تجميعات أو جسورًا أو تطبيقات خصوصية أو تطبيقات لامركزية تعتمد على Provers في الخلفية.

مع ذلك، ينبغي للمستخدمين فهم دور Prover، لأنه يؤثر في السرعة والرسوم والإنهاء وافتراضات الثقة.

إذا اعتمدت تجميعة على Prover مركزي واحد، فينبغي للمستخدمين معرفة ما سيحدث إذا توقف عن العمل.

وإذا استخدم تطبيق خصوصية خدمة إثبات عن بُعد، فينبغي للمستخدمين معرفة ما إذا كانت البيانات الخاصة تُرسل إلى تلك الخدمة.

وإذا اعتمد جسر على الإثباتات، فينبغي للمستخدمين معرفة ما الذي يتحقق منه الإثبات وما الذي لا يتحقق منه.

ينبغي للمستخدمين أيضًا التحقق مما إذا كان عقد Verifier خضع للتدقيق، وما إذا كان لنظام الإثبات نموذج أمني واضح.

وجود Prover ليس ضمانًا سحريًا للأمان.

لا تكون قيمة Prover حقيقية إلا إذا صُمم نظام الإثبات والدائرة وVerifier وتوافر البيانات والحوكمة على نحو صحيح.

ينبغي للمستخدمين اعتبار الإثبات طبقة واحدة من طبقات الأمان، لا النظام بأكمله.

أفضل الممارسات للمطورين

ينبغي للمطورين تحديد العبارة المطلوب من Prover إثباتها بوضوح.

وينبغي لهم تصميم دوائر أو برامج تفرض القواعد المقصودة بدقة.

كما ينبغي لهم استخدام أنظمة إثبات خضعت لمراجعة جيدة وتجنب التشفير المخصص، إلا إذا راجعه خبراء.

ينبغي اختبار إنشاء الإثبات على أعباء عمل واقعية وحالات طرفية وظروف فشل.

كما ينبغي قياس وقت Prover واستخدام الذاكرة ومتطلبات الأجهزة وتكلفة التحقق.

ينبغي حماية الشهود الخاصة عندما يتضمن الإثبات بيانات مستخدم حساسة.

كما ينبغي توثيق المدخلات العامة كي يفهم المستخدمون والمدققون ما يتحقق منه Verifier فعليًا.

ينبغي فصل البنية التحتية لـ Prover عن صلاحيات الإدارة الموثوقة متى أمكن.

كما ينبغي التخطيط لتعطل Prover وإعادة محاولات المهام والمراقبة وخيارات الطوارئ الاحتياطية.

ينبغي توضيح مخاطر التحديث عند تغيير الدوائر أو مفاتيح الإثبات أو عقود Verifier أو برمجيات Prover.

مفاهيم خاطئة شائعة عن Provers

من المفاهيم الخاطئة أن Prover يجب أن يكون موضع ثقة.

في نظام إثبات مصمم جيدًا، ينبغي لـ Verifier رفض الإثباتات غير الصحيحة حتى لو كان Prover غير نزيه.

ومن المفاهيم الخاطئة أيضًا أن Prover يوفر الخصوصية دائمًا.

تنشئ بعض Provers إثباتات صلاحية لأغراض التوسع من دون إخفاء جميع بيانات المعاملات.

ومن المفاهيم الخاطئة أن إنشاء الإثبات منخفض التكلفة.

قد تكون عملية الإثبات أغلى بكثير من التحقق، وقد تتطلب بنية تحتية متخصصة.

ومن المفاهيم الخاطئة أن الإثبات الصحيح يثبت كل ما يتعلق بالتطبيق.

لا يثبت الإثبات إلا العبارة المحددة في الدائرة أو البرنامج.

ومن المفاهيم الخاطئة أن لامركزية Prover قد حُلّت بالفعل في كل مكان.

لا تزال أنظمة كثيرة تعمل على تطوير بنية تحتية للإثبات أكثر انفتاحًا ولامركزية.

ومن المفاهيم الخاطئة أن المستخدمين لا يحتاجون أبدًا إلى الاهتمام بـ Provers.

قد لا يشغّل المستخدمون Provers، لكن تصميمها قد يؤثر في السحب والإنهاء والرسوم والخصوصية وموثوقية التطبيقات.

الأسئلة الشائعة

ماذا يعني Prover في عالم العملات المشفرة؟

Prover هو الجهة أو البرنامج أو العقدة أو الخدمة التي تنشئ إثباتًا تشفيريًا يبيّن صحة عبارة أو عملية حسابية أو انتقال للحالة.

ما هو Prover في إثبات المعرفة الصفرية؟

في إثبات المعرفة الصفرية، ينشئ Prover إثباتًا يقنع Verifier بصحة عبارة من دون الكشف عن معلومات خاصة غير ضرورية.

ما الفرق بين Prover وVerifier؟

ينشئ Prover الإثبات، بينما يتحقق Verifier من صحته.

لماذا تُعد Provers مهمة لـ ZK-rollups؟

تُعد Provers مهمة لـ ZK-rollups لأنها تنشئ إثباتات صلاحية تتيح تسوية مجموعات المعاملات على سلسلة أساسية، من دون أن تعيد كل عقدة تنفيذ جميع المعاملات.

هل Prover هو نفسه Sequencer؟

لا. يرتب Sequencer المعاملات، بينما ينشئ Prover إثباتات تشفيرية على صحة التنفيذ أو انتقالات الحالة.

هل يخفي Prover البيانات الخاصة دائمًا؟

لا. تُستخدم بعض Provers أساسًا للتوسع وضمان الصحة، بينما تعتمد الخصوصية على تصميم نظام الإثبات والتطبيق لتوفير المعرفة الصفرية.

هل يستطيع Prover غير نزيه إنشاء إثباتات مزيفة؟

ينبغي لنظام إثبات آمن أن يمنع Prover غير النزيه من إنشاء إثبات صحيح لعبارة زائفة.

لماذا تكون عملية الإثبات مكلفة؟

قد تكون عملية الإثبات مكلفة لأنها تتطلب عمليات حسابية كبيرة وإنشاء سجلات كثيفة الذاكرة وعمليات كثيرات الحدود والتجزئة والتكرار وأجهزة متخصصة.

ما هو الشاهد في عملية الإثبات؟

الشاهد هو البيانات الخاصة أو الداخلية التي يستخدمها Prover لإنشاء إثبات، من دون أن يكشفها بالضرورة لـ Verifier.

ما هو الإثبات التكراري؟

الإثبات التكراري هو إثبات صحة إثبات آخر، وقد يساعد على دمج إثباتات عديدة في إثبات أصغر أو أكثر كفاءة.

ماذا يحدث إذا توقف Prover الخاص بتجميعة عن العمل؟

إذا اعتمدت التجميعة على ذلك Prover، فقد يتأخر إرسال الإثبات والتسوية النهائية إلى أن تعود قدرة الإثبات أو يُستخدم Prover احتياطي.

هل يمكن إنشاء Provers لامركزية؟

نعم، يُعد الإثبات اللامركزي مجالًا نشطًا للتطوير والبحث، لكنه يتطلب حلولًا لإسناد المهام والدفع والموثوقية والخصوصية والتحقق.

الخاتمة

يُعد Prover أحد أهم أدوار البنية التحتية في أنظمة الإثبات الحديثة للعملات المشفرة.

فهو ينشئ إثباتات تشفيرية تتيح لـ Verifiers التحقق من العبارات والعمليات الحسابية ومجموعات المعاملات وانتقالات الحالة من دون إعادة تنفيذ جميع العمليات الأساسية.

تؤدي Provers دورًا محوريًا في إثباتات المعرفة الصفرية وZK-rollups وآلات zkVM وأنظمة STARK وأنظمة SNARK وتجميع الإثباتات والإثبات التكراري وبروتوكولات الخصوصية والجسور والحوسبة القابلة للتحقق.

تتمثل القيمة الأساسية لـ Prover في نقل العمليات الحسابية المكثفة بعيدًا عن Verifier، مع الحفاظ على موثوقية التحقق.

قد يحسن ذلك قابلية التوسع ويقلل العمليات على السلسلة ويدعم الخصوصية ويتيح تصميم تطبيقات جديدة.

لكن Provers تطرح أيضًا تحديات عملية.

فقد يكون إنشاء الإثبات مكلفًا وبطيئًا ويتطلب أجهزة متخصصة ومعقدًا من الناحية التشغيلية، وقد يكون مركزيًا أحيانًا.

تعتمد فائدة الإثبات على العبارة التي يثبتها والدائرة أو البرنامج الذي يتحقق منها وVerifier الذي يصادق عليه والبنية التحتية التي تحافظ على استمرارية الإثبات.

أهم ما ينبغي للمستخدمين إدراكه هو أن Prover يساعد على جعل التحقق التشفيري أكثر كفاءة، لكنه لا يزيل كل المخاطر في التجميع أو الجسر أو تطبيق الخصوصية أو نظام العقود الذكية.

وأهم ما ينبغي للمطورين إدراكه هو ضرورة أن يكون تصميم Prover آمنًا وفعالًا ومختبرًا جيدًا ومراعيًا للخصوصية وموثقًا بوضوح.

أبسط طريقة لفهم Prover هي أنه ينفذ العمل الرياضي الصعب كي تتمكن بقية شبكة العملات المشفرة من التحقق من النتيجة بسرعة ومن دون الحاجة إلى الثقة.