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

1. تاريخ براهين المعرفة الصفرية

نشأ نظام إثبات عدم المعرفة الحديث من الورقة التي تم نشرها بشكل مشترك من قبل Goldwasser و Micali و Rackoff: التعقيد المعرفي لأنظمة الإثبات التفاعلية (GMR85)، والتي تم اقتراحها في عام 1985 ونشرت في عام 1989. تشرح هذه الورقة بشكل أساسي مقدار المعرفة التي يجب تبادلها بعد جولات K من التفاعلات في نظام تفاعلي لإثبات صحة العبارة. إذا كان من الممكن جعل المعرفة المتبادلة صفرية، فإنها تسمى دليل المعرفة الصفرية. من المفترض أن المُثبت لديه موارد غير محدودة وأن المدقق لديه موارد محدودة فقط. تكمن مشكلة الأنظمة التفاعلية في أن الدليل ليس قابلاً للإثبات رياضيًا تمامًا، ولكنه صحيح بالمعنى الاحتمالي، على الرغم من أن الاحتمال صغير جدًا (1/2 ^ n).

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

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

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

أهم إنجاز في إثبات المعرفة الصفرية هو ورقة غروث لعام 2010 القائمة على الاقتران القصير «حجج المعرفة الصفرية غير التفاعلية»، والتي تعد أيضًا الرائد النظري لأهم مجموعة من ZK-SNARKS في ZKP.

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

بعض الإنجازات الأكاديمية الهامة خلال هذه الفترة تشمل:

1. بينوكيو (PGHR13) في عام 2013: بينوكيو: حساب عملي تقريبًا يمكن التحقق منه، والذي يضغط وقت الإثبات والتحقق إلى النطاق المطبق، هو أيضًا البروتوكول الأساسي الذي تستخدمه Zcash.
2. Groth16 في عام 2016: حول حجم الحجج غير التفاعلية القائمة على الاقتران، والتي تبسط حجم الإثبات وتحسن كفاءة التحقق، هي حاليًا خوارزمية ZK الأساسية الأكثر استخدامًا.
3. اقترحت Bulletproof (BBBPWM17) Bulletproof: البراهين القصيرة للمعاملات السرية والمزيد في عام 2017 خوارزمية Bulletproof، وهي عبارة عن دليل قصير جدًا غير تفاعلي قائم على المعرفة ولا يتطلب إعدادًا موثوقًا به. سيتم تطبيقه على Monero بعد 6 أشهر وهو سريع جدًا. الجمع بين النظرية والتطبيق.
4. في عام 2018، اقترحت ZK-Starks (BBHR18) التكامل الحسابي القابل للتطوير والشفاف والآمن بعد الكم بروتوكول خوارزمية ZK-STARK الذي لا يتطلب إعدادات موثوقة. هذا اتجاه آخر ملفت للنظر لتطوير ZK في الوقت الحاضر، ويستند أيضًا على هذا الأساس، ولدت StarkWare، أهم مشروع ZK.

التطورات الأخرى بما في ذلك PLONK و Halo2 وما إلى ذلك هي أيضًا تقدم مهم للغاية وأدخلت أيضًا بعض التحسينات على ZK-SNARK.

2. وصف موجز لتطبيق إثبات عدم المعرفة

التطبيقان الأكثر انتشارًا لبراهين المعرفة الصفرية هما حماية الخصوصية وتوسيع السعة. في الأيام الأولى، مع إطلاق معاملات الخصوصية والعديد من المشاريع المعروفة مثل Zcash و Monero، أصبحت معاملات الخصوصية ذات مرة فئة مهمة جدًا. ومع ذلك، نظرًا لأن ضرورة معاملات الخصوصية لم تكن بارزة كما كانت الصناعة تأمل، بدأ هذا النوع من المشاريع التمثيلية في التباطؤ. ادخل ببطء إلى معسكرات المستوى الثاني والثالث (لا تنسحب من مرحلة التاريخ). على مستوى التطبيق، زادت الحاجة إلى التوسع إلى النقطة التي تحولت فيها Ethereum 2.0 (التي تمت إعادة تسميتها بطبقة الإجماع) إلى مسار يركز على التجميع في عام 2020. عادت سلسلة ZK رسميًا إلى اهتمام الصناعة وأصبحت محور التركيز.

معاملات الخصوصية: هناك العديد من المشاريع التي نفذت معاملات الخصوصية، بما في ذلك Zcash باستخدام SNARK و Tornado و Monero باستخدام bulletproof و Dash. لا يستخدم Dash ZKP بالمعنى الدقيق للكلمة، ولكنه نظام خلط العملات البسيط والخام الذي يمكنه فقط إخفاء العنوان ولكن ليس المبلغ. لن أذكرها هنا.

خطوات معاملة ZK-snarks التي تطبقها Zcash هي كما يلي:

المصدر: إزالة الغموض عن دور ZK-snarks في Zcash

1. تقوم مرحلة إعداد النظام بإنشاء مفتاح الإثبات (متعدد الحدود المضاد للتشفير) ومفتاح التحقق باستخدام وظيفة KeyGen
2. يتم استخدام طريقة تشفير ECIES لمرحلة CPA (نظام التشفير المتكامل للمنحنى البيضاوي) لإنشاء مفاتيح عامة وخاصة
3. مرحلة سك العملات، عدد العملات الجديدة التي تم إنشاؤها. الخطاب العام والالتزام بالعملة
4. في مرحلة الصب، يتم إنشاء شهادة ZK-SNARK وإضافتها إلى دفتر معاملات pour.
5. في مرحلة التحقق، يتحقق المدقق مما إذا كانت أحجام معاملات Mint and Pour صحيحة.
6. في مرحلة الاستلام، يتلقى المتلقي عملات معدنية. إذا كنت ترغب في استخدام العملات المستلمة، استمر في الاتصال بـ Pouring لنموذج التحقق من ZK-Snark، كرر الخطوات المذكورة أعلاه 4-6 لإكمال المعاملة.

لا تزال Zcash تواجه قيودًا في استخدام المعرفة الصفرية، أي أنها تستند إلى UTXO، لذا فإن جزءًا من معلومات المعاملة محمي فقط، ولا يتم التستر عليه حقًا. نظرًا لأنها شبكة منفصلة تعتمد على تصميم Bitcoin، فمن الصعب توسيعها (دمجها مع تطبيقات أخرى). معدل الاستخدام الفعلي للحماية (أي المعاملات الخاصة) أقل من 10٪، مما يدل على أن المعاملات الخاصة لم يتم توسيعها بنجاح. (من عام 2202)

تعتبر بركة الخلط الكبيرة الوحيدة التي تستخدمها Tornado أكثر تنوعًا وتعتمد على شبكة «مجربة ومختبرة» مثل Ethereum. Torndao هو في الأساس تجمع لخلط العملات باستخدام ZK-SNARK، ويستند إعداد الثقة إلى ورقة Groth 16. تشمل الميزات المتوفرة مع تورنادو كاش ما يلي:

1. يمكن سحب العملات المودعة فقط.
2. لا يمكن سحب أي عملات معدنية مرتين
3. عملية الإثبات مرتبطة بإشعار إلغاء العملة (Nullifier). لن تسمح تجزئة نفس الدليل ولكن المبطل المختلف بسحب العملات.
4. مستوى الأمان هو 126 بت ولن يتدهور بسبب التكوين.

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

التوسع: يمكن توسيع ZK على شبكة المستوى الأول، مثل Mina، أو على شبكة المستوى الثاني، أي zk-roll up. قد تكون فكرة طرح ZK قد نشأت من منشور Vitalik في عام 2018، حيث تم توسيع نطاق السلسلة إلى ما يقرب من 500 tx/sec من خلال التحقق الشامل من صحة الضرائب.

يحتوي ZK-rollup على نوعين من الأدوار، أحدهما هو Sequencer والآخر هو Aggregator. يعتبر Sequencer مسؤولاً عن تغليف المعاملات، والمجمع مسؤول عن دمج عدد كبير من المعاملات وإنشاء مجموعة، وتشكيل دليل SNARK (يمكن أن يكون أيضًا دليلًا على عدم المعرفة استنادًا إلى خوارزميات أخرى). ستتم مقارنة هذا الإثبات بالحالة السابقة لـ Layer1، ثم تحديث شجرة Ethereum Merkle، وحساب شجرة حالة جديدة.

المصدر: بوليجون

مزايا وعيوب مجموعة ZK:

1. المزايا: التكلفة المنخفضة، على عكس OP الذي سيتعرض للهجوم الاقتصادي، لا حاجة لتأخير المعاملات، يمكن حماية الخصوصية، ويمكن تحقيق النهاية بسرعة
2. العيوب: يتطلب تشكيل إثبات ZK قدرًا كبيرًا من الحسابات ومشكلات الأمان (يتطلب SNARK إعدادًا موثوقًا به) ولا يقاوم الهجمات الكمومية (SNARK، STARK can)، قد يتم تغيير ترتيب المعاملة

المصدر: أبحاث إيثريوم

استنادًا إلى توفر البيانات وطرق الإثبات، يحتوي Starkware على مخطط تصنيف كلاسيكي لـ L2 (يمكن تحديد طبقة توفر بيانات Volition على السلسلة أو خارج السلسلة):

المصدر: ستاركوير

تشمل مشاريع مجموعة ZK الأكثر تنافسية الموجودة حاليًا في السوق: StarkNet من Starkware، و ZKSync من Matterlabs، و Aztec connect من Aztec، و Hermez و Miden من Polygon، و Loopring، و Scroll، وما إلى ذلك.

يكمن المسار الفني بشكل أساسي في اختيار SNARK (وإصداراته المحسنة) و STARK، بالإضافة إلى دعم EVM (بما في ذلك التوافق أو التكافؤ).

1. قامت شركة Aztec بتطوير بروتوكول SNARK المعمم - بروتوكول PLONK. قد يدعم Aztec3 قيد التشغيل EVM، لكن الخصوصية لها الأسبقية على توافق EVM.
2. يستخدم Starnet ZK-stark، وهو zkp لا يتطلب إعدادات موثوقة، ولكنه لا يدعم حاليًا EVM ولديه مترجم ولغة تطوير خاصة به.
3. يستخدم ZKSync أيضًا الرابط ويدعم EVM. ZKSync 2.0 متوافق مع EVM ولديه zKevm الخاص به
4. Scroll، وهي مجموعة ZK متوافقة مع EVM، يعد الفريق أيضًا مساهمًا مهمًا في مشروع zKevm التابع لمؤسسة Ethereum

ناقش باختصار مشكلات التوافق مع EVM:

لطالما كان التوافق بين نظام ZK و EVM يمثل مشكلة، وستختار معظم المشاريع بين الاثنين. أولئك الذين يؤكدون على ZK قد يبنون جهازًا افتراضيًا في نظامهم الخاص، ولديهم لغة ZK الخاصة بهم ومترجمها، ولكن هذا سيجعل من الصعب على المطورين التعلم، ولأنه في الأساس ليس مفتوح المصدر، فسيصبح صندوقًا أسود. بشكل عام، لدى الصناعة حاليًا خياران. الأول هو أن يكون متوافقًا تمامًا مع أكواد تشغيل Solidity، والآخر هو تصميم جهاز افتراضي جديد صديق لـ ZK ومتوافق مع Solidity. لم تتوقع الصناعة مثل هذا التكامل السريع في البداية، ولكن التكرار السريع للتكنولوجيا في العام أو العامين الماضيين قد رفع التوافق مع EVM إلى مستوى جديد، ويمكن للمطورين تحقيق درجة معينة من الترحيل السلس (أي سلسلة Ethereum الرئيسية إلى ZK rollup) يعد تطورًا مثيرًا سيؤثر على بيئة تطوير ZK والمشهد التنافسي. سنناقش هذه المسألة بالتفصيل في التقارير اللاحقة.

3. المبادئ الأساسية لتنفيذ ZK SNARK

اقترح غولدفاسر وميكالي وراكوف أن براهين المعرفة الصفرية لها ثلاث خصائص:

1. الاكتمال: يمكن التحقق من كل بيان مع شهود معقولين من قبل المدقق
2. السلامة: لا ينبغي التحقق من كل مطالبة مع شهود غير معقولين فقط من قبل المدقق
3. المعرفة الصفرية: عملية التحقق هي المعرفة الصفرية

لذلك من أجل فهم ZKP، نبدأ بـ ZK-SNARK، لأن العديد من تطبيقات blockchain الحالية تبدأ بـ SNARK. أولاً، دعونا نلقي نظرة على ZK-snark.

ZK-snark يعني: إثبات المعرفة الصفرية (Zh-SNARK) هو حجج المعرفة المختصرة غير التفاعلية للمعرفة الصفرية.

1. المعرفة الصفرية: عملية الإثبات هي المعرفة الصفرية ولا تعرض معلومات زائدة عن الحاجة.
2. الإيجاز: حجم التحقق الصغير
3. غير تفاعلية: عملية غير تفاعلية
4. الحجج: الحساب موثوق به، أي أن المُثبت ذو القوة الحاسوبية المحدودة لا يمكنه تزوير الدليل، ويمكن للمُثبت الذي يتمتع بقوة حاسوبية غير محدودة تزوير الإثبات.
5. المعرفة: لا يمكن للمُثبت إنشاء معلمة وإثبات دون معرفة معلومات صحيحة
6. يستحيل على المُثبت إنشاء مجموعة من المعلمات والإثبات دون معرفة الشاهد (مثل إدخال دالة التجزئة أو المسار لتحديد عقدة شجرة ميركل).

مبدأ الإثبات الخاص بـ ZK-snark الخاص بـ Groth16 هو كما يلي:

المصدر: https://learnblockchain.cn/article/3220

الخطوات هي:

1. قم بتحويل المشكلة إلى دائرة
2. قم بتسوية الدائرة في شكل R1CS.
3. تحويل R1CS إلى صيغة QAP (برامج الحساب التربيعي)
4. قم بإنشاء إعداد موثوق به وإنشاء معايير عشوائية، بما في ذلك PK (مفتاح الإثبات) و VK (مفتاح التحقق)
5. إنشاء إثبات والتحقق من ZK-snark

في المقالة التالية، سنبدأ في دراسة مبادئ وتطبيقات ZK-SNARK، ومراجعة تطوير ZK-SNARK من خلال عدة حالات، واستكشاف علاقتها مع ZK-Stark.

إخلاء المسؤولية：

1. تمت إعادة طباعة هذه المقالة من [HashKey Capital]. جميع حقوق التأليف والنشر تنتمي إلى المؤلف الأصلي [HashKey Capital]. إذا كانت هناك اعتراضات على إعادة الطبع هذه، فيرجى الاتصال بفريق Gate Learn ، وسيتعاملون معها على الفور.
2. إخلاء المسؤولية: الآراء ووجهات النظر الواردة في هذه المقالة هي فقط آراء المؤلف ولا تشكل أي نصيحة استثمارية.
3. تتم ترجمة المقالة إلى لغات أخرى بواسطة فريق Gate Learn. ما لم يُذكر ذلك، يُحظر نسخ المقالات المترجمة أو توزيعها أو سرقتها.