الخلفية

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

مع مرور الوقت، تطورت ZKP من مفهوم نظري مجرد إلى بروتوكولات ملموسة يمكن دمجها في تطبيقات مختلفة. في عام 2010، نشر غروث ورقة بعنوان حجج المعرفة الصفرية غير التفاعلية القائمة على الاقتران القصير، والتي أصبحت عملاً أساسيًا في تطوير ZK-SNARK، وهو حل مهم في ZKP. أهم تطبيق عملي لـ ZKP هو نظام إثبات عدم المعرفة الذي استخدمته Z-cash في عام 2015، والذي حقق حماية الخصوصية للمعاملات والمبالغ. بعد ذلك، تم دمج ZK-SNARK مع العقود الذكية، مما أدى إلى مجموعة واسعة من التطبيقات.

المبادئ الفنية لـ zk-SNARK

المبادئ التي يجب على ZKP التقليدية الالتزام بها هي كما يلي:

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

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

ويقوم Zk-SNARK بإجراء مزيد من الترقيات على هذا الأساس، بالخصائص التالية:

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

في ورقة غروث، اقترح طريقة غير تفاعلية لإثبات المعرفة الصفرية استنادًا إلى عمليات الاقتران التي تحول مشكلة حسابية إلى برنامج حسابي تربيعي (QAP)، ثم تقوم ببناء دليل فعال باستخدام تشفير المنحنى الإهليلجي ووظائف التجزئة. تتضمن التصميمات اللاحقة لـ zk-SNARK عمومًا أربع خطوات:

• الإعداد: يتم تنفيذه بواسطة طرف ثالث موثوق به، ويقوم بإنشاء CRS الذي يتضمن مفتاح إثبات (pk) لتوليد البراهين ومفتاح التحقق (vk) للتحقق من البراهين. يجب تنفيذ هذه العملية مرة واحدة فقط، ويمكن إعادة استخدام CRS عدة مرات.
• تشفير المشكلة: يتم تحويل مشكلة الحساب f (x) = y إلى نموذج QAP A (x) · B (x) = C (x) · Z (x)، حيث A (x)، B (x)، C (x) هي متعددة الحدود تحددها بنية الدائرة لـ f، Z (x) هي متعددة الحدود ثابتة، x هي نقطة مختارة عشوائيًا، و y هي ناتج f. يمكن تنفيذ هذه الخطوة بواسطة المُثبت أو المدقق، أو يمكن القيام بها مسبقًا بواسطة طرف ثالث.
• إنشاء الإثبات: يتم إجراؤه بواسطة المُثبت، ويستخدم pk و x والمدخلات w من f لإنشاء إثبات ₽ لإثبات أنهم يعرفون w الذي يرضي f (w) = y، دون الكشف عن القيمة المحددة لـ w. تتضمن هذه العملية حسابات متعددة الحدود وعمليات المنحنى الإهليلجي وعمليات دالة التجزئة، مما يؤدي في النهاية إلى إنشاء ₽ تتكون من عدة نقاط منحنى إهليلجي وقيمة تجزئة.
• التحقق من الإثبات: يتم إجراؤه بواسطة المدقق، ويستخدم vk و x و y و ₽ للتحقق مما إذا كان المُثبت يعرف بالفعل w الذي يرضي f (w) = y. تتضمن هذه العملية أيضًا حسابات متعددة الحدود وعمليات المنحنى الإهليلجي وعمليات دالة التجزئة، مما يؤدي في النهاية إلى الحصول على قيمة منطقية تشير إلى صحة الإثبات.

للمساعدة في الفهم، دعنا نفكر في مثال بسيط: لنفترض أن لديك خريطة كنز يمكن أن ترشدك إلى الموقع الدقيق للكنز المدفون. تريد أن تثبت لشخص ما أنك تعرف موقع الكنز دون الكشف عن محتويات الخريطة أو الموقع الفعلي للكنز. إذا كنت تستخدم تقنية zk-SNARK، فستحتاج إلى إنشاء لغز معقد لخريطة الكنز. يمكنك اختيار قطعة صغيرة من اللغز (دليل) وإظهارها للشخص، مما يقنعه بأنك تعرف كيف يتناسب اللغز الكامل معًا، أي موقع الكنز، دون رؤية اللغز بأكمله. ومع ذلك، لتحقيق ذلك، ستحتاج إلى الحصول على علامات خاصة من دار طباعة موثوقة، والتي تكون بمثابة دليل على أن قطعة اللغز الخاصة بك أصلية.

لماذا نحتاج إلى ZK-SNARK؟

يتضمن النهج التقليدي لبراهين المعرفة الصفرية أساليب إثبات تفاعلية، حيث يسأل المُثبت المدقق مرارًا وتكرارًا «نعم أم لا؟» أسئلة حتى يتم الوصول إلى إجابة صحيحة. هذه العملية غير فعالة. ومع ذلك، يلغي ZK-SNARK الحاجة إلى التفاعلات المتكررة من خلال الحصول على CRS من طرف ثالث موثوق به. يمكن لجميع المزودين مقارنة CRS مباشرة لتحديد المصداقية. هذا يحسن بشكل كبير من كفاءة براهين المعرفة الصفرية.

بالإضافة إلى ذلك، تقدم Zk-snark المزايا التالية:

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

تطبيقات العالم الحقيقي لـ zk-SNARK

أول تطبيق لـ ZK-SNARK هو Zcash، والذي يسمح للمستخدمين بالانخراط في معاملات مجهولة تمامًا عن طريق إخفاء معلومات مثل المرسلين والمستلمين والمبالغ باستخدام ZK-SNARK. في مساحة Web3 الحالية، تلعب تقنية ZK-SNARK دورًا مهمًا في قابلية تطوير blockchain وإدارة احتياطي الصرف.

قابلية تطوير البلوك تشين

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

تلعب ZK-SNARK دورًا مهمًا في هذا الحل، حيث يمكنها ضغط المعاملات أو الحسابات على Layer2 إلى دليل صغير وسريع، يتم تقديمه بعد ذلك للتحقق على السلسلة الرئيسية، مما يضمن صحة واتساق الطبقة 2. يوجد حاليًا حلان رئيسيان من Layer2 يعتمدان على ZK-SNARK: ZK-rollup و Validium.

• ZK-rollup: يخزن هذا الحل جميع بيانات الحالة على السلسلة الرئيسية ولكنه يستخدم البراهين للتحقق من صحة انتقالات الحالة. وهذا يضمن توفر بيانات الطبقة الثانية وأمانها ولكنه يزيد من عبء التخزين على السلسلة الرئيسية. على سبيل المثال، تقوم ZKSync بتخزين بيانات الحالة على سلسلة Ethereum الرئيسية وتضمن صحة انتقالات الحالة من خلال براهين المعرفة الصفرية. وتشمل المشاريع المماثلة بوليغون وZKEVM وScroll.
• Validium: يخزن هذا الحل جميع بيانات الحالة على Layer2 أو جهات خارجية موثوقة أخرى، ويستخدم فقط البراهين للتحقق من صحة انتقالات الحالة، وتقديم البراهين إلى السلسلة الرئيسية. وهذا يقلل من عبء التخزين على السلسلة الرئيسية ولكنه قد يقلل من توفر بيانات الطبقة الثانية وأمانها. تستخدم DeversiFi تقنية Validium للحفاظ على سرعة وكفاءة معاملات Layer2 مع ضمان خصوصية البيانات. يوفر Loopring وضع Validium لتخفيف ضغط التخزين على السلسلة الرئيسية.

احتياطي الأموال في البورصات

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

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

المثال النموذجي هو Gate.io، الذي يستخدم مزيجًا من أشجار Zk-snark و Merkle. يقومون بتشفير بيانات المستخدم وإنشاء أدلة على 100 صندوق احتياطي من الرموز المختلفة باستخدام دوائر مقيدة لإثبات قدرتها على الملاءة المالية بنسبة 100٪.

المصدر: https://www.gate.io/proof-of-reserves

مزيد من القراءة: كيف تعمل Zk-snark على تحسين إثبات Gate.ioللاحتياطيات

بالإضافة إلى تطبيقات Web3، يمكن أيضًا استخدام zk-SNARK في المجالات غير المتسلسلة، مثل:

• مصادقة الهوية: تسمح zk-SNARK للمستخدمين بإثبات حيازتهم لسمات أو مؤهلات هوية معينة لأطراف ثالثة دون الكشف عن أي معلومات شخصية، مثل العمر والجنسية والتعليم وما إلى ذلك. يكون هذا مفيدًا في السيناريوهات التي تتطلب مصادقة الهوية أو التفويض، مثل التسوق عبر الإنترنت والتعليم عبر الإنترنت والتوقيعات الرقمية وما إلى ذلك.
• التصويت الإلكتروني: يتيح zk-SNARK للمستخدمين إثبات مشاركتهم في أنشطة تصويت معينة والامتثال لبروتوكولات أو قواعد محددة لأطراف ثالثة دون الكشف عن أي محتوى تصويت أو بيانات وصفية. وهذا مفيد في السيناريوهات التي تتطلب حماية خصوصية التصويت وأمنه، مثل الانتخابات الديمقراطية، وإدارة المجتمع، وصنع القرار العام، وما إلى ذلك.

القيود الفنية والتحديات

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

• المعلمات الموثوقة: تتطلب zk-SNARK نظام CRS الذي تم إنشاؤه بواسطة طرف ثالث موثوق به، والذي قد يحتوي على معلومات حساسة. إذا تم تسريبه أو العبث به، فقد يؤدي ذلك إلى تعريض أمن النظام للخطر. لمعالجة هذه المشكلة، اعتمدت بعض المشاريع نهج الحساب متعدد الأطراف (MPC) لإنشاء CRS، حيث يساهم العديد من المشاركين بشكل مشترك في عملية التوليد وتدمير معلوماتهم السرية. ومع ذلك، لا يزال هذا النهج يواجه تحديات مثل نزاهة المشاركين وتكاليف الاتصال وصعوبات التنسيق.
• العالمية: حاليًا، لا يمكن تطبيق zk-SNARK إلا على مشكلات حسابية محددة، مثل QAP أو R1CS، ولا يمكن تطبيقها على المشكلات الحسابية التعسفية. لمعالجة هذا القيد، استكشفت بعض المشاريع استخدام الدوائر العامة (GC) أو الإثبات التكراري العام (GRS) لتوسيع نطاق تطبيق ZK-SNARK. ومع ذلك، يأتي هذا النهج مع مقايضات مثل زيادة حجم الإثبات وانخفاض الكفاءة وزيادة التعقيد.
• إمكانية التحقق: بينما يضمن zk-SNARK عدم قيام المُثبت بتسريب أي معلومات خاصة، فإنه لا يضمن أن المُثبت لن يغش المدقق أو يخدعه. لمعالجة هذه المشكلة، أدخلت بعض المشاريع وظائف عشوائية يمكن التحقق منها (VRF) أو وظائف التأخير التي يمكن التحقق منها (VDF) لتعزيز سلامة المُثبت. ومع ذلك، فإن هذا النهج يزيد أيضًا من تعقيد النظام ونفقاته.

باختصار، هناك طرق مختلفة لمعالجة القيود المتأصلة في zk-SNARK.

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

ZK-SNARK، كتقنية تشفير مبتكرة، لديها سيناريوهات تطبيقات مستقبلية واسعة، خاصة في مجال الخصوصية:

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

الاستنتاج

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