Validity Proof

ما هو برهان الصلاحية؟

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

في الكريبتو، تُناقش براهين الصلاحية غالبًا في ZK-rollups وValidiums وVolitions وzkVMs وzkEVMs وأنظمة التوسعة الأخرى التي تعالج المعاملات خارج السلسلة وتثبت النتيجة على السلسلة.

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

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

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

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

لماذا تهم براهين الصلاحية في الكريبتو؟

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

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

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

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

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

كيف يعمل برهان الصلاحية؟

يبدأ برهان الصلاحية عادةً بتنفيذ خارج السلسلة. يتلقى Sequencer أو مشغّل أو شبكة مُثبتين أو بيئة تنفيذ معاملات المستخدمين، ثم يحسب الحالة الناتجة.

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

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

براهين الصلاحية وانتقالات الحالة

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

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

يثبت برهان الصلاحية أن الدفعة الكاملة غيّرت الحالة بصورة صحيحة. لذلك يُوصف أحيانًا بأنه إثبات لصحة التنفيذ؛ فهو لا يثبت مجرد وجود المعاملات، بل يثبت معالجتها وفق قواعد النظام.

براهين الصلاحية مقابل براهين المعرفة الصفرية

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

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

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

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

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

براهين الصلاحية مقابل براهين الاحتيال

براهين الصلاحية وبراهين الاحتيال طريقتان مختلفتان لتأمين تحديثات حالة Layer 2.

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

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

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

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

براهين الصلاحية وZK-Rollups

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

تتحقق السلسلة الأساسية من البرهان وتقبل جذر الحالة الجديد إذا كان صالحًا. وبذلك يوسع rollup التنفيذ مع استخدام سلسلة التسوية للتحقق النهائي.

تنشر ZK-rollups أيضًا بيانات كافية ليتمكن المستخدمون والمراقبون من إعادة بناء حالة rollup. وتهم إتاحة البيانات لأن المستخدمين يحتاجون إلى بيانات المعاملات أو فروقات الحالة للتحقق من الأرصدة والسحب بأمان.

يوضح تحليل مخاطر L2BEAT أن rollups تنشر التزامات الحالة على Ethereum وتتحقق منها إما عبر براهين الصلاحية أو آليات الاعتراض المتفائلة.

يعتمد أمان ZK-rollup على نظام البرهان وعقد المُتحقق وإتاحة البيانات وتصميم الجسر وضوابط الترقية. وبرهان الصلاحية أساسي، لكنه ليس عامل الخطر الوحيد.

براهين الصلاحية وValidium

تستخدم أنظمة Validium أيضًا براهين الصلاحية، لكنها تتعامل مع إتاحة البيانات بصورة مختلفة عن ZK-rollups.

يثبت Validium صحة التنفيذ خارج السلسلة، لكنه لا ينشر جميع بيانات المعاملات على سلسلة التسوية. وتوضح وثائق Ethereum حول Validium أن Validiums تستخدم براهين الصلاحية مثل ZK-rollups، لكنها تبقي بيانات المعاملات خارج Ethereum.

قد يجعل ذلك Validium أقل تكلفة من rollup، لأن بيانات أقل تُنشر على السلسلة، لكنه يخلق مخاطر إضافية لإتاحة البيانات. فإذا حُجبت البيانات، فقد لا يستطيع المستخدمون إعادة بناء الحالة أو السحب بأمان.

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

براهين الصلاحية وVolition

Volition تصميم هجين لإتاحة البيانات يتيح للمستخدمين أو التطبيقات الاختيار بين بيانات على السلسلة بأسلوب rollup وبيانات خارج السلسلة بأسلوب Validium.

توضح وثائق StarkEx حول إتاحة البيانات أن Volition يتيح للمستخدمين استخدام خزائن ZK-Rollup وValidium معًا في التطبيق نفسه.

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

براهين الصلاحية وإتاحة البيانات

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

توضح وثائق Ethereum حول إتاحة البيانات أن إتاحة البيانات تضمن نشر بيانات الكتل وإمكانية وصول المشاركين في الشبكة إليها.

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

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

براهين الصلاحية وطبقات التسوية

طبقة التسوية هي السلسلة أو النظام الذي يتحقق من البراهين ويخزن الالتزامات وينهي تحديثات الحالة. تعمل Ethereum كطبقة تسوية للعديد من أنظمة Layer 2 الخاصة بها.

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

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

براهين الصلاحية والمُثبتون والمُتحققون

المُثبت هو النظام الذي ينشئ برهان الصلاحية. في rollup، يأخذ المُثبت دفعة المعاملات أو أثر التنفيذ أو انتقال الحالة وينشئ برهانًا تشفيريًا.

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

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

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

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

براهين الصلاحية وSNARKs

تُعد SNARKs عائلة شائعة من أنظمة الإثبات المستخدمة لإنشاء براهين الصلاحية. ويعني SNARK: Succinct Non-Interactive Argument of Knowledge.

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

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

براهين الصلاحية وSTARKs

STARKs عائلة رئيسية أخرى من أنظمة الإثبات المستخدمة لبراهين الصلاحية. ويعني STARK: Scalable Transparent Argument of Knowledge.

تشتهر STARKs بالشفافية لأنها لا تتطلب النوع نفسه من الإعداد الموثوق المستخدم في بعض أنظمة SNARK.

يصف عرض StarkEx StarkEx بأنه محرك توسعة يستخدم براهين STARK ويدعم أوضاع إتاحة بيانات rollup وValidium وVolition.

قد تكون STARKs جذابة للعمليات الحسابية الكبيرة وأنظمة التوسعة، لكنها قد تمتلك أحجام براهين أكبر من بعض تصميمات SNARK، حسب التنفيذ. ومثل SNARKs، لا تصبح STARKs خاصة تلقائيًا لمجرد استخدامها في أنظمة ZK.

براهين الصلاحية وzkEVMs وzkVMs

zkEVM هو نظام إثبات معرفة صفرية مصمم لإثبات تنفيذ عقود ذكية شبيهة بـ Ethereum أو عمليات حسابية متوافقة مع EVM. وتُعد براهين الصلاحية مركزية فيه، لأن النظام يجب أن يثبت تنفيذ EVM بصورة صحيحة.

تلك مهمة صعبة لأن EVM لم يُصمم أساسًا ليسهل إثباته. يجب على zkEVM التعامل مع opcodes وقواعد Gas والتخزين والاستدعاءات والسجلات وprecompiles وتحديثات الحالة. والهدف هو تمكين المطورين من نشر تطبيقات بأسلوب Ethereum مع الاستفادة من قابلية التوسع التي تقدمها البراهين القائمة على الصلاحية.

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

يجعل ذلك براهين الصلاحية أكثر مرونة لـ appchains وrollups والجسور والمعالجات المساعدة والعمليات الحسابية خارج السلسلة، لكن العمومية قد ترافقها تكاليف أداء؛ فقد تكون الدائرة المخصصة أسرع لمهمة محددة، بينما يكون zkVM أسهل في البناء وأصعب في التحسين.

براهين الصلاحية التكرارية

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

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

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

براهين الصلاحية والجسور

تمثل الجسور أحد أهم المواضع التي تؤثر فيها براهين الصلاحية على أموال المستخدمين. قد يقفل جسر rollup الأصول على Ethereum ويضيف أرصدة مقابلة على Layer 2.

عند السحب، يجب أن يعرف الجسر أن تحديث حالة Layer 2 صالح. ويمكن لبرهان الصلاحية مساعدة الجسر على التحقق من تضمين السحب في انتقال حالة صحيح، ما يقلل الاعتماد على مشغّل موثوق.

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

براهين الصلاحية وسرعة السحب والنهائية

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

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

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

لكن للنهائية طبقات تشمل التأكيد الداخلي لـ rollup وإنشاء البرهان والتحقق على سلسلة التسوية ونهائية سلسلة التسوية، وقد تؤثر مخاطر الترقية أو الحوكمة في النهائية العملية. ينبغي التمييز بين تأكيد سريع في واجهة Layer 2 والتسوية النهائية على الطبقة الأساسية.

براهين الصلاحية وتكاليف Gas

قد تخفض براهين الصلاحية إجمالي رسوم الغاز عبر تمكين البلوكشين من التحقق من برهان واحد بدل تنفيذ كل معاملة مباشرة، لكن التحقق من البرهان نفسه يستهلك Gas.

وقد توجد تكاليف لنشر البيانات وتحديث جذور الحالة ومعالجة السحوبات وصيانة عقود الجسر. وبعد تغييرات Ethereum المعتمدة على blobs، قد تكون تكاليف بيانات rollups أقل من التصميمات القديمة المعتمدة على calldata.

توضح وثائق خارطة طريق Ethereum danksharding أن proto-danksharding قدم blobs كمساحة بيانات أقل تكلفة لـ rollups. وتؤثر كفاءة التحقق من البرهان وإتاحة البيانات واستراتيجية التجميع كلها في الرسوم النهائية.

براهين الصلاحية وافتراضات الأمان

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

كما يعتمدون على المشغلين أو Sequencers لاستمرارية العمل ما لم توجد آليات احتياطية قوية، وعلى المحافظ والمستخدمين لتوقيع معاملات آمنة.

يثبت البرهان أنه لا ينبغي قبول عملية حسابية غير صالحة، لكنه لا يضمن أن النظام لامركزي أو مقاوم للرقابة أو منخفض التكلفة أو خاص أو خالٍ من مخاطر الترقية.

براهين الصلاحية ومخاطر Sequencer

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

لكن مركزية Sequencer قد تخلق مخاطر: فقد يتوقف عن العمل أو يفرض رقابة على المعاملات أو يعيد ترتيبها لاستخراج MEV أو يؤخر السحوبات حتى تُنشر الدفعة ويُثبت صحتها.

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

براهين الصلاحية ومخاطر الترقية

تُعد مخاطر الترقية من أكثر المسائل التي يُغفل عنها في أنظمة التوسعة القائمة على الصلاحية. فقد يستخدم rollup براهين الصلاحية مع اعتماده على عقود قابلة للترقية.

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

تقيّم صفحات مخاطر L2BEAT غالبًا تأخيرات الترقية وضوابط الحوكمة وما إذا كان المستخدمون يستطيعون السحب قبل تطبيق التغييرات الخطرة.

براهين الصلاحية والخصوصية

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

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

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

براهين الصلاحية وDeFi

قد تكون براهين الصلاحية مفيدة جدًا للتمويل اللامركزي (DeFi) لأنه يحتاج إلى تنفيذ آمن ورسوم أقل.

يوضح دليل Ethereum حول DeFi أن التمويل اللامركزي يستخدم البلوكشين العامة والعقود الذكية لتقديم خدمات مالية.

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

لكن يجب على مستخدمي DeFi مراعاة السيولة ومخاطر Oracle ومخاطر التصفية ومخاطر الجسر وSequencer وإتاحة البيانات. قد يكون مركز DeFi صالحًا رياضيًا ويخسر المال بسبب مخاطر السوق، وقد ينطوي rollup منخفض التكلفة على مخاطر عقود أو حوكمة.

براهين الصلاحية وNFTs والألعاب

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

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

يوضح دليل Ethereum حول NFT أن NFTs قد تمثل ملكية عناصر فريدة. وإذا احتُفظ بـ NFTs داخل نظام قائم على الصلاحية، فينبغي فهم كيفية إثبات الملكية وعمل السحب ومكان تخزين البيانات الوصفية.

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

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

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

براهين الصلاحية والذكاء الاصطناعي على السلسلة

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

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

الفكرة مماثلة لـ rollups: نفّذ العمل المكلف خارج السلسلة، وأثبت النتيجة على السلسلة. لكن إثبات أعباء عمل الذكاء الاصطناعي بكفاءة قد يكون أصعب بكثير من إثبات تحويلات توكنات بسيطة، ولا تزال تطبيقات كثيرة تجريبية.

براهين الصلاحية والمعالجات المساعدة

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

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

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

فوائد براهين الصلاحية

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

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

مخاطر وقيود براهين الصلاحية

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

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

كيفية تقييم نظام برهان الصلاحية

ابدأ بالسؤال عما يثبته البرهان فعليًا: هل يثبت انتقال حالة كاملًا، أم برنامجًا محددًا، أم سحبًا، أم رسالة جسر، أم جزءًا فقط من النظام؟

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

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

مفاهيم خاطئة شائعة حول براهين الصلاحية

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

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

لا تمتلك جميع ZK-rollups الأمان نفسه، لأن أنظمة البراهين وعقود المُتحقق وخيارات إتاحة البيانات وضوابط الترقية وتصميم Sequencer تخلق مخاطر مختلفة. كما لا تقدم Validiums الضمانات نفسها لـ ZK-rollups، لأنها تحتفظ بالبيانات خارج السلسلة وتضيف افتراضات إتاحة البيانات.

برهان الصلاحية ببساطة

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

إذا كان البرهان صالحًا، يمكن قبول الحالة الجديدة. يساعد ذلك rollups وأنظمة التوسعة الأخرى على أن تصبح أقل تكلفة وأسرع. وتشيع براهين الصلاحية في ZK-rollups وValidiums، كما تزداد أهميتها في zkVMs وzkEVMs والجسور والمعالجات المساعدة والحساب القابل للتحقق.

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

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

ما هو برهان الصلاحية في الكريبتو؟

هو برهان تشفيري يوضح أن عملية حسابية أو انتقال حالة نُفذ بصورة صحيحة وفق قواعد البروتوكول.

أين تُستخدم براهين الصلاحية؟

تُستخدم في ZK-rollups وValidiums وVolitions وzkEVMs وzkVMs والجسور والمعالجات المساعدة وأنظمة الحساب الأخرى القابلة للتحقق.

هل برهان الصلاحية هو نفسه برهان المعرفة الصفرية؟

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

هل توفر كل براهين الصلاحية الخصوصية؟

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

ما الفرق بين برهان الصلاحية وبرهان الاحتيال؟

يثبت برهان الصلاحية صحة تحديث الحالة قبل قبوله، بينما يعترض برهان الاحتيال على تحديث غير صحيح بعد القبول المتفائل.

لماذا تستخدم ZK-rollups براهين الصلاحية؟

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

هل تستخدم Validiums براهين الصلاحية؟

نعم، تستخدمها لصحة التنفيذ، لكنها تحتفظ ببيانات المعاملات خارج السلسلة.

هل يحل برهان الصلاحية مشكلة إتاحة البيانات؟

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

هل يمكن التحقق من برهان صلاحية على Ethereum؟

نعم، ترسل أنظمة توسعة Ethereum كثيرة براهين الصلاحية إلى عقود ذكية مُتحققة على Ethereum.

ما هو المُثبت؟

المُثبت هو النظام الذي ينشئ برهان الصلاحية بعد التنفيذ خارج السلسلة.

ما هو المُتحقق؟

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

ماذا يحدث إذا كان برهان الصلاحية غير صالح؟

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

هل يمكن لبراهين الصلاحية خفض الرسوم؟

نعم، قد تخفض الرسوم عبر تمكين البلوكشين من التحقق من براهين موجزة بدل تنفيذ كل معاملة مباشرة.

هل تجعل براهين الصلاحية السحوبات أسرع؟

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

ما أكبر مخاطر أنظمة براهين الصلاحية؟

تشمل أكبر المخاطر أخطاء المُتحقق ومشكلات استمرارية المُثبت وفشل إتاحة البيانات وأخطاء الجسر وضوابط الترقية غير الآمنة.

هل تقتصر براهين الصلاحية على Layer 2؟

لا. تهم توسعة Layer 2، لكنها قد تدعم أيضًا الجسور وzkVMs والمعالجات المساعدة والذكاء الاصطناعي القابل للتحقق وأنظمة حساب أخرى خارج السلسلة.

ما الذي ينبغي التحقق منه قبل الوثوق بنظام برهان صلاحية؟

ينبغي التحقق من تغطية البرهان وتدقيق المُتحقق ولامركزية المُثبت وإتاحة البيانات وأمان الجسر وضوابط الترقية وآليات السحب.

هل يكفي برهان الصلاحية لجعل المشروع آمنًا؟

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

الخلاصة

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

لذلك تمثل عنصرًا أساسيًا في ZK-rollups وValidiums وVolitions وzkEVMs وzkVMs والجسور والمعالجات المساعدة والتوجه الأوسع نحو الحساب القابل للتحقق.

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

لكن براهين الصلاحية ليست ضمانات أمان كاملة بذاتها. فهي لا توفر الخصوصية تلقائيًا، ولا تحل إتاحة البيانات تلقائيًا، ولا تزيل مخاطر الجسر أو Sequencer أو الترقيات غير الآمنة أو الحوكمة الضعيفة.

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

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