هل سيأكل ZK المكدس المعياري؟

المؤلف: Hannes Huitula; تم تجميعه بواسطة: Vernacular Blockchain

1. ما هو blockchain وما هو كيف هل يمتد نموذج الحوسبة الحالي؟

Blockchain (اسم): آلة تنسيق تمكن المشاركين من جميع أنحاء العالم من التعاون بموجب مجموعة من القواعد المتفق عليها بشكل عام دون تسهيل أي منها من قبل طرف ثالث.

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

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

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

Web3 = القراءة والكتابة والتحقق

2. ZK والنمطية - اتجاهان سيتم تسريعهما

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

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

المهارات التعبيرية – ما هي الضمانات التي يمكنك تقديمها؟ وتشمل هذه قابلية التوسع (التكلفة، وزمن الوصول، والإنتاجية، وما إلى ذلك)، والخصوصية (أو إدارة تدفق المعلومات)، وقابلية البرمجة، وقابلية التركيب.

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

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

من ناحية أخرى، تمكن Zero Knowledge Proofs (ZKPs) أحد الأطراف (المُثبِّت) من أن يثبت لطرف آخر (المُحقق) أنه يعرف شيئًا ما الأمور صحيحة دون الكشف عن أي معلومات إضافية غير صحتها. يؤدي هذا إلى زيادة قابلية التوسع والكفاءة عن طريق تجنب إعادة التنفيذ (الانتقال من التحقق من صحة التنفيذ بالكامل إلى تنفيذ واحد، كل التحقق من الصحة) مع زيادة التعبير عن طريق تمكين الخصوصية (مقيدة). تزيد ZKPs من صعوبة الضمانات عن طريق استبدال الضمانات الاقتصادية المشفرة الأضعف بضمانات أقوى، وهو ما يتمثل في دفع حدود المقايضة إلى الخارج (راجع الرسم البياني أعلاه).

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

1) ما هي أجزاء المجموعة المعيارية التي تتضمن بالفعل إثباتات المعرفة الصفرية، وأي منها لم يتم استكشافها بعد؟

2) ما هي المشاكل التي يمكن لبراهين المعرفة الصفرية حلها؟

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

3. المكدس المعياري في عام 2024

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

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

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

4. دليل المعرفة الصفرية (ZK) في المكدس المعياري

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

1) تجريد عمليات المستخدم

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

تجريد الحساب (AA) يمكّن العقود الذكية من إجراء المعاملات دون الحاجة إلى توقيع المستخدم لكل عملية (" حساب التشفير القابل للبرمجة" "). يمكن استخدامه لتحديد من يمكنه التوقيع (إدارة المفاتيح)، وما يجب التوقيع عليه (حمولة المعاملة)، وكيفية التوقيع (خوارزمية التوقيع)، ومتى يتم التوقيع (شروط الموافقة على المعاملة). يتيح الجمع بين هذه الميزات القيام بأشياء مثل التفاعل مع التطبيقات اللامركزية باستخدام تسجيل الدخول الاجتماعي، والمصادقة الثنائية (2FA)، واسترداد الحساب، والأتمتة (توقيع المعاملات تلقائيًا). بينما تركز المناقشة غالبًا على إيثريوم (تم تمرير ERC-4337 في ربيع عام 2023)، فإن العديد من السلاسل الأخرى لديها بالفعل تجريد حساب أصلي مدمج (Aptos، وSui، وNear، وICP، وStarknet، وzkSync).

يسمح تجريد السلسلة للمستخدمين بتوقيع المعاملات على سلاسل مختلفة أثناء التفاعل مع حساب واحد فقط (واجهة واحدة، سلاسل متعددة). تعمل العديد من الفرق على حل هذه المشكلة، بما في ذلك Near وICP وdWallet. تستفيد هذه الحلول من MPC وتوقيعات السلسلة، حيث يتم تقسيم المفاتيح الخاصة للشبكة الأخرى إلى أجزاء أصغر ومشاركتها بين المدققين في سلسلة المصدر، الذين يوقعون المعاملات عبر السلسلة. عندما يريد المستخدم التفاعل مع سلسلة أخرى، يلزم وجود عدد كافٍ من المدققين لتوقيع المعاملات لتلبية حد التشفير. وهذا يحافظ على الأمان لأنه لا تتم مشاركة المفتاح الخاص بشكل كامل في أي مكان. لكنها تواجه خطر تواطؤ المدقق، وهذا هو السبب في أن أمن الاقتصاد المشفر للسلسلة الأساسية ولامركزية المدقق لا يزالان مهمين للغاية.

النية، على مستوى عالٍ، تترجم رغبات المستخدمين واحتياجاتهم إلى إجراءات يمكن تنفيذها بواسطة blockchain. وهذا يتطلب محللي النوايا - وكلاء مخصصين خارج السلسلة مسؤولين عن إيجاد أفضل حل لنوايا المستخدم. يوجد بالفعل العديد من التطبيقات التي تستخدم الأغراض المتخصصة، مثل مجمع DEX ("أفضل سعر") ومجمع الجسر ("أرخص/أسرع جسر"). تم تصميم شبكات تسوية النوايا العالمية (Anoma وEssential وSuave) لتسهيل على المستخدمين التعبير عن نوايا أكثر تعقيدًا وتمكين المطورين من إنشاء تطبيقات تتمحور حول النوايا. ومع ذلك، لا تزال هناك العديد من الأسئلة التي لم تتم الإجابة عليها، بما في ذلك كيفية إضفاء الطابع الرسمي على هذه العملية، وكيف ستبدو اللغة التي تركز على النية، وما إذا كان هناك دائمًا حل أمثل، وكيفية العثور عليه.

تكامل ZK الحالي

مصادقة AA x ZK: مثال على ذلك هو zkLogin بواسطة Sui ، والذي يسمح للمستخدمين بتسجيل الدخول باستخدام بيانات اعتماد مألوفة مثل عناوين البريد الإلكتروني. ويستخدم ZKPs لمنع الجهات الخارجية من ربط عناوين Sui بمعرفات OAuth المقابلة لها.

تحقق أكثر كفاءة من التوقيع لمحافظ AA: يمكن أن يكون التحقق من المعاملات في عقود AA أكثر تكلفة بكثير من المعاملات التي تبدأ باستخدام الحسابات التقليدية (EOA). تحاول Orbiter حل هذه المشكلة من خلال خدمة مجمعة تستخدم ZKPs للتحقق من صحة توقيعات المعاملة والحفاظ على قيمة nonce وتوازن الغاز لحساب AA (عبر شجرة حالة Merkle العالمية). يتيح ذلك توفيرًا كبيرًا في التكاليف من خلال تجميع الأدلة وحتى توزيع تكاليف التحقق عبر السلسلة على جميع المستخدمين.

المشكلات المفتوحة التي قد تحلها ZKPs

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

حماية الخصوصية لتسوية النوايا: تهدف بروتوكولات مثل Taiga إلى الحماية الكاملة لوظيفة تسوية النوايا لحماية خصوصية المستخدم - وهذه خطوة إلى الأمام في مجال شبكات Blockchain هي جزء من حركة أوسع لإضافة جوانب الخصوصية (أو على الأقل السرية). ويستخدم ZKPs (Halo2) لإخفاء المعلومات الحساسة حول انتقالات الحالة (نوع التطبيق والأطراف وما إلى ذلك).

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

2) التسلسل

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

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

تكامل ZK الحالي

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

المشكلات المفتوحة التي قد تحلها ZKPs

قواعد الفرز القابلة للتحقق (VSR): الموضوع مع مقدم العرض /orderer لمجموعة من القواعد المتعلقة بترتيب التنفيذ، مع ضمانات إضافية باتباع هذه القواعد. يمكن إجراء التحقق من خلال ZKPs أو إثباتات الاحتيال، حيث يتطلب الأخير إيداعًا اقتصاديًا كبيرًا بما يكفي يمكن قطعه إذا أساء مقدم الطلب/الأمر التصرف.

3) التنفيذ (الكتابة الموسعة)

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

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

تكامل ZK الحالي

التغليف المتداول zkEVM: نوع خاص من zkVM، محسّن للتوافق مع Ethereum وبيئة تنفيذ EVM المثبتة. ومع ذلك، كلما زاد التوافق مع الإيثريوم، زادت مقايضة الأداء. تم إطلاق العديد من أجهزة zkEVM في عام 2023، بما في ذلك Polygon zkEVM وzkSync Era وScroll وLinea. أعلنت شركة Polygon مؤخرًا عن إطلاق مُثبت zkEVM من النوع 1، والذي يمكنه إثبات كتل Ethereum على الشبكة الرئيسية مقابل 0.20 دولار - 0.50 دولار لكل كتلة (ستعمل التحسينات القادمة على تقليل التكاليف بشكل أكبر). لدى RiscZero أيضًا حل يمكنه إثبات كتل Ethereum، ولكنه أكثر تكلفة وله معايير محدودة.

وحدات zkVM البديلة: اختارت بعض البروتوكولات مسارًا آخر، مما أدى إلى تحسين الأداء/قابلية الإثبات (Starknet، Zorp) أو سهولة المطورين بدلاً من محاولة تحقيق أقصى قدر من التوافق مع Ethereum. تتضمن الأمثلة على الأخير بروتوكول zkWASM (Fluent وDelphinus Labs) وzkMOVE (M2 وzkmove).

وحدات zkVM التي تركز على الخصوصية: في هذه الحالة، تخدم وحدات ZKP غرضين: تجنب عمليات إعادة التنفيذ وتمكين الخصوصية. في حين أن الخصوصية التي يمكن تحقيقها من خلال ZKPs وحدها محدودة (فقط الدولة الخاصة الفردية)، فإن البروتوكول القادم يضيف الكثير من التعبير وقابلية البرمجة للحلول الحالية. تشمل الأمثلة Aleo’s snarkVM، وAztec’s AVM، وPolygon’s MidenVM.

المعالج المساعد ZK: يسمح بإجراء العمليات الحسابية على البيانات خارج السلسلة (ولكن بدون حالة). تُستخدم معالجات ZKP لإثبات التنفيذ الصحيح والتسوية بشكل أسرع من المعالجات المساعدة المتفائلة، ولكن هناك مقايضة في التكلفة. نظرًا للتكلفة و/أو صعوبة إنشاء ZKPs، نرى بعض الإصدارات المختلطة، مثل Brevis coChain، مما يسمح للمطورين بالاختيار بين ZK أو الوضع المتفائل (مفاضلة بين التكلفة والصعوبة المضمونة).

المشكلات المفتوحة التي قد تحلها ZKPs

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

zkSVM: بينما يتم استخدام SVM بشكل أساسي في Solana L1 اليوم، تقوم فرق مثل Eclipse بتجربة الاستفادة من SVM لتجديد التسويات على Ethereum. تخطط Eclipse أيضًا لاستخدام Risc Zero في SVM لإثباتات الاحتيال ZK لمعالجة التحديات المحتملة لانتقالات الحالة في SVM. ومع ذلك، لم يتم استكشاف zkSVM الكامل بعد - ربما بسبب تعقيد المشكلة وحقيقة أن SVMs تم تحسينها لأشياء أخرى إلى جانب إمكانية الإثبات.

4) استعلام البيانات (قراءة التوسيع)

الاستعلام عن البيانات، أو من كتلة قراءة البيانات من السلسلة جزء مهم من معظم التطبيقات. على الرغم من أن معظم المناقشات والجهود في السنوات الأخيرة ركزت على توسيع نطاق عمليات الكتابة (التنفيذ)، إلا أن توسيع نطاق القراءات أكثر أهمية بسبب عدم التوازن بين الاثنين (خاصة في البيئات اللامركزية). تختلف نسب القراءة/الكتابة بين سلاسل الكتل، ولكن إحدى نقاط البيانات هي تقدير Sig أن أكثر من 96% من جميع المكالمات إلى العقد على Solana هي مكالمات مقروءة (استنادًا إلى عامين من البيانات التجريبية) - نسبة القراءة/الكتابة هي 24:1.

تتضمن القراءات الموسعة الأداء المحسن (المزيد من القراءات في الثانية) وتعقيد التنفيذ من خلال عملاء التحقق المخصصين (مثل Sig on Solana) والاستعلامات (الجمع بين القراءة والحسابات)، على سبيل المثال بمساعدة المعالج المساعد.

منظور آخر هو طريقة الاستعلام عن البيانات اللامركزية. اليوم، تتم معالجة معظم طلبات استعلام البيانات في blockchain من قبل أطراف ثالثة موثوقة (استنادًا إلى السمعة)، مثل عقد RPC (Infura) والمفهرسات (Dune). تتضمن أمثلة الخيارات اللامركزية عوامل تشغيل الرسم البياني وإثبات التخزين (يمكن التحقق منها أيضًا). هناك أيضًا بعض المحاولات لإنشاء شبكات RPC لامركزية، مثل Infura DIN أو Lava Network (بالإضافة إلى RPC اللامركزية، تخطط Lava أيضًا لتوفير خدمات إضافية للوصول إلى البيانات في المستقبل).

تكامل ZK الحالي

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

المشكلات المفتوحة التي قد تحلها ZKPs

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

5) الإثبات

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

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

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

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

تكامل ZK الحالي

أغلفة STARK وSNARK: تعد مثبتات STARK سريعة ولا تتطلب إعداد ثقة، ولكن العيب هو أن التحقق من البراهين الكبيرة التي تنتجها على Ethereum L1 مكلف. يمكن أن يؤدي تغليف STARKs في SNARKs كخطوة أخيرة إلى تقليل تكلفة التحقق على Ethereum بشكل كبير. ومع ذلك، فإن القيام بذلك يزيد من التعقيد، ولم يتم دراسة أمن "أنظمة الإثبات المركبة" هذه بشكل شامل. تتضمن أمثلة التطبيقات الحالية Polygon zkEVM وBoojum في عصر zkSync وRISC Zero.

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

المشكلات المفتوحة التي قد تحلها ZKP

إثبات احتيال ZK: في الحلول المتفائلة، يمكن لأي شخص تحدي انتقال الدولة وإنشاء دليل على الاحتيال أثناء التحدي. ومع ذلك، فإن التحقق من أدلة الاحتيال لا يزال أمرًا شاقًا للغاية لأنه يتم من خلال إعادة التنفيذ. تهدف ZK Fraud Proofs إلى حل هذه المشكلة عن طريق إنشاء أدلة على تحولات الحالة التي يتم تحديها، مما يسمح بالتحقق الأكثر كفاءة (لا حاجة لإعادة التنفيذ) وربما التسوية بشكل أسرع. على الأقل، تعالج Optimism (بالشراكة مع O1 Labs وRiscZero) وAltLayer x RiscZero هذه المشكلة.

تجميع البراهين الأكثر كفاءة: من الميزات الرائعة لـ ZKPs أنه يمكنك تجميع البراهين المتعددة في برهان واحد دون زيادة تكلفة التحقق بشكل كبير. وهذا يجعل من الممكن توزيع تكلفة التحقق عبر إثباتات أو تطبيقات متعددة. يعد تجميع الأدلة أيضًا دليلًا، ولكن الإدخال عبارة عن دليلين وليس تتبع التنفيذ. ومن أمثلة المشاريع في هذا المجال NEBRA وGevulot.

6) إصدار البيانات (التوفر)

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

Celestia هو أول مشروع يطلق شبكته الرئيسية بدلاً من طبقة DP (31 أكتوبر)، ولكن من المتوقع إطلاق مشاريع مثل Avail وEigenDA وNear DA في بحلول عام 2024، سيكون هناك قريبًا العديد من البدائل للاختيار من بينها. بالإضافة إلى ذلك، تعمل ترقية EIP 4844 الخاصة بـ Ethereum على تحسين كفاءة نشر البيانات على Ethereum (مع إنشاء سوق رسوم منفصلة لتخزين البيانات الثنائية الكبيرة) وتمهد الطريق لتقاسم الخزان بالكامل. تتوسع DP أيضًا في أنظمة بيئية أخرى - أحد الأمثلة على ذلك هو Nubit، الذي يهدف إلى بناء DP أصلي على Bitcoin.

توفر العديد من حلول DP أيضًا خدمات تتجاوز نشر البيانات البحتة، بما في ذلك الأمان المشترك للمجموعات المجمعة السيادية (مثل Celestia وAvail) أو المزيد بين مجموعات التشغيل التفاعلية السلسة (مثل رابطة أفاييل). هناك أيضًا مشاريع مثل Dom1C0n وZero Gravity التي توفر نشر البيانات بالإضافة إلى تخزين الحالة على المدى الطويل، وهو اقتراح مقنع. وهذا أيضًا مثال على إعادة تجميع مكونين في مكدس معياري، وهو شيء قد نشهده أكثر في المستقبل (تجربة المزيد من التفكيك وإعادة التجميع).

تكامل ZK الحالي

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

جسر البيانات المقدم من عميل ZK Light: لا تزال المجموعات المجمعة التي تستخدم طبقة نشر البيانات الخارجية بحاجة إلى إخطار طبقة التسوية بأن البيانات قد تم نشرها بشكل صحيح. هذا هو المكان الذي تأتي فيه جسور مصادقة البيانات. يمكن أن يؤدي استخدام ZKPs إلى جعل التحقق من توقيعات إجماع سلسلة المصدر على Ethereum أكثر كفاءة. يتم تشغيل جسور مصادقة البيانات لـ Avail (VectorX) وCelestia (BlobstreamX) بواسطة عملاء ZK light الذين تم تصميمهم بالشراكة مع Succinct.

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

ZK-proof DAS: تم إجراء بعض الاستكشافات حول توفر بيانات ZK-proof، حيث تحتاج العقد الخفيفة فقط إلى التحقق من جذور Merkle وZKP دون تنزيل بيانات الكتلة الصغيرة لأخذ العينات العادية. سيؤدي هذا إلى تقليل متطلبات العقد الخفيفة بشكل أكبر، ولكن يبدو أن التطوير قد توقف.

7) التخزين طويل المدى (الحالة)

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

بالإضافة إلى ذلك، هناك موفري تخزين لامركزي مثل Filecoin أو Arweave يقدمون حلول تخزين لامركزية طويلة الأجل وبأسعار معقولة. في حين أن معظم سلاسل الكتل لا تحتوي على عملية تخزين أرشيفية رسمية (تعتمد فقط على شخص يقوم بتخزينها)، فإن بروتوكولات التخزين اللامركزية تقوم بتخزين البيانات التاريخية وإضافة بعض التكرار (على الأقل عقد X لتخزين البيانات) من خلال الحوافز المضمنة في شبكة التخزين) وهو خيار جيد.

تكامل ZK الحالي

إثبات التخزين: يحتاج موفرو التخزين طويل المدى إلى إنشاء ZKP بانتظام لإثبات أنهم قاموا بتخزين جميع البيانات التي يطالبون بها. أحد الأمثلة على ذلك هو إثبات المكان والزمان (PoSt) الخاص بـ Filecoin، حيث يتلقى مزود التخزين مكافأة كتلة في كل مرة يجيب فيها بنجاح على تحدي PoSt.

المشكلات التي يمكن لـ ZKP حلها

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

8) الإجماع

بالنظر إلى أن blockchain هو نظام P2P موزع، لا يوجد يحدد طرف ثالث موثوق به الحقيقة الشاملة. وبدلاً من ذلك، تتوصل العقد في الشبكة إلى إجماع حول الحقيقة الحالية (أي الكتلة صحيحة) من خلال آلية تسمى الإجماع. يمكن تصنيف طرق الإجماع المستندة إلى PoS على أنها تعتمد على BFT (حيث تحدد مجموعة من المدققين البيزنطيين المتسامحين مع الأخطاء الحالة النهائية) أو تعتمد على السلسلة (حيث يتم تحديد الحالة النهائية بأثر رجعي من خلال قواعد اختيار الشوكة). في حين أن معظم تطبيقات إجماع PoS الحالية تعتمد على BFT، فإن Cardano هو مثال على أطول سلسلة تنفيذ. هناك أيضًا اهتمام متزايد بآليات الإجماع المستندة إلى DAG، مثل Narwhal-Bullshark، والتي يتم تنفيذها بأشكال مختلفة في مشاريع مثل Aleo وAptos وSui.

يعد الإجماع جزءًا أساسيًا من العديد من المكونات المختلفة في المجموعة المعيارية، بما في ذلك أجهزة التسلسل المشتركة، والإثباتات اللامركزية، وشبكات نشر البيانات القائمة على blockchain (لا تعتمد على اللجان، مثل إيجيندا).

تكامل ZK الحالي

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

الحوكمة الخاصة: كان تحقيق التصويت المجهول يمثل تحديًا منذ فترة طويلة في مجال العملات المشفرة، ويحاول مشروع Nouns Private Voting تعزيز هذا التقدم. الأمر نفسه ينطبق على الحكم، على الأقل تعمل شركة بينومبرا على التصويت المجهول على المقترحات. في هذه الحالة، يمكن استخدام ZKP لإثبات أن شخصًا ما لديه الحق في التصويت (على سبيل المثال من خلال ملكية الرمز المميز) واستيفاء معايير تصويت معينة (على سبيل المثال، لم يتم إجراء التصويت بعد).

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

تجميع التوقيع: يمكن أن يؤدي استخدام ZKP لتجميع التوقيعات إلى تقليل الاتصالات والحمل الحسابي للتحقق من التوقيع بشكل كبير (التحقق من إثبات مجمع بدلاً من كل توقيع فردي). تم استغلال هذا بالفعل في عملاء ZK light، ولكن يمكن توسيعه ليشمل الإجماع أيضًا.

9) التسوية

التسوية تشبه المحكمة العليا - فهي تتحقق من صحة انتقال الدولة والمصدر النهائي للحقيقة لحل النزاعات. تعتبر المعاملة نهائية عند نقطة اللارجعة (أو، في حالة النهاية الاحتمالية، النقطة التي يكون من الصعب التراجع عندها). يعتمد الوقت المطلوب للنهائية على طبقة التسوية الأساسية المستخدمة، والتي تعتمد بدورها على قواعد النهاية المحددة وأوقات الكتلة المستخدمة.

تمثل النهاية البطيئة مشكلة خاصة في الاتصال المتبادل، لأن مجموعة التحديثات تحتاج إلى انتظار التأكيد من Ethereum قبل الموافقة على المعاملة (بالنسبة لمجموعة التحديثات المتفائلة، يجب الانتظار 7 أيام؛ للحصول على مجموعة بيانات الصلاحية، عليك الانتظار 12 دقيقة ووقت التحقق). وهذا يؤدي إلى تجربة مستخدم سيئة. توجد حاليًا جهود متعددة لمعالجة هذه المشكلة، بما في ذلك استخدام الحلول الخاصة بالنظام البيئي المؤكدة مسبقًا مع مستوى معين من الأمان (مثل Polygon AggLayer أو zkSync HyperBridge)، بالإضافة إلى الحلول ذات الأغراض العامة مثل Near's Fast Finality Layer ، والتي تهدف إلى تحقيق ذلك من خلال الاستفادة من EigenLayer. يربط الأمن الاقتصادي بين العديد من الأنظمة البيئية التراكمية المختلفة. يوجد أيضًا خيار لاستخدام EigenLayer لجسر التجميع المحلي المؤكد بشكل بسيط لتجنب انتظار النهاية الكاملة.

تكامل ZK الحالي

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

10) الأمان

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

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

تتضمن البروتوكولات المبنية حول الأمان المشترك ما يلي:

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

أطلقت Cosmos برنامج Interchain Security (ICS) في مايو 2023، والذي يمكّن Cosmos Hub، وهي واحدة من أكبر السلاسل في Cosmos، والتي تتكون من دعم Stake ATOM بقيمة 2.4 مليار دولار تقريبًا ) يضفي أمانها على سلسلة المستهلكين. وباستخدام نفس مجموعة أدوات التحقق التي تشغل Cosmos Hub للتحقق من صحة الكتل في سلاسل المستهلكين، فإنها تهدف إلى تقليل الحواجز التي تحول دون إطلاق سلاسل جديدة أعلى مجموعة Cosmos Stack. ومع ذلك، لا يوجد حاليًا سوى سلسلتين استهلاكيتين نشطتين (نيوترون وسترايد).

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

تتضمن إعادة التخزين على الشبكات الأخرى Octopus on Near وPicasso على Solana. تستخدم مظلات Polkadot أيضًا مفهوم الأمان المشترك.

تكامل ZK الحالي

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

11) قابلية التشغيل البيني

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

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

على الرغم من أننا لا نزال نفتقر إلى تعريف واضح للأنواع المختلفة من العملاء الخفيفين (أو العقد)، يشرح دينو، المؤسس المشارك لـ Fluent وModular Media، في هذه المقالة مقدمة رائعة . يتحقق معظم العملاء الخفيفين اليوم من الإجماع فقط، ولكن من الناحية المثالية يجب أن يكون لدينا عملاء خفيفون يمكنهم التحقق من التنفيذ وDA لتقليل افتراضات الثقة. وهذا سيجعل من الممكن التعامل مع أمان العقدة الكاملة دون متطلبات الأجهزة العالية.

تكامل ZK الحالي

عملاء ZK Light (التحقق من الإجماع): يمكن لمعظم عملاء Light الحاليين التحقق من إجماع السلاسل الأخرى - إما المجموعة الكاملة من أدوات التحقق (إذا كانت صغيرة بما يكفي) أو مجموعة فرعية من إجمالي أدوات التحقق من الصحة (على سبيل المثال، لجنة مزامنة Ethereum). يتم استخدام ZKPs لتسريع وتقليل تكاليف التحقق لأن نظام التوقيع المستخدم في السلسلة الأصلية قد لا يكون مدعومًا أصلاً في السلسلة المستهدفة. في حين أنه من المتوقع أن تزداد أهمية عملاء ZK Light في التجسير، فإن الاحتكاك الحالي مع الطرح يشمل تكلفة التصديق والتحقق، بالإضافة إلى تنفيذ عملاء ZK light لكل سلسلة جديدة. تتضمن أمثلة البروتوكولات في هذا المجال Polyhedra وAvail وCelestia’s Data Confirmation Bridge وElectron Labs’s zkIBC.

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

ZKOracle: تعمل Oracle كوسيط وتقوم بتوصيل بيانات العالم الحقيقي إلى blockchain. تعمل ZK Oracle على تحسين نموذج Oracle الحالي القائم على السمعة من خلال القدرة على إثبات أصل البيانات وسلامتها، بالإضافة إلى أي حسابات يتم إجراؤها على البيانات.

المسائل المفتوحة التي يمكن حلها عن طريق إثبات المعرفة الصفرية (ZKP)

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

ب. طبقة التجميع: تهدف AggLayer الخاصة بـ Polygon إلى تحقيق إمكانية التشغيل البيني السلس بين L2 داخل النظام البيئي من خلال الاستفادة من أدلة التجميع وعقود التجسير الموحدة. تعمل البراهين المجمعة على تمكين التحقق الأكثر كفاءة وتوفير قدر أكبر من الأمان - فرض حالة سلسلة التبعية واتساق الحزمة، والتأكد من أنه إذا كانت حالة التجميع تعتمد على حالة غير صالحة لسلسلة أخرى، فلا يمكن حل هذه الحالة على Ethereum. تتبع HyperChains من zkSync وAvail's Nexus نهجًا مشابهًا.

5. ماذا سيحدث عندما يبتلع دليل المعرفة الصفرية (ZKP) المكدس المعياري؟

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

بشكل عام، نعتقد أن هناك حالتين حقيقيتين في هذا الموقف:

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

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

الشرط الثالث يتعلق بالخصوصية (أو إدارة تدفق المعلومات)، لكن هذا أكثر تعقيدًا. باستخدام الدليل من جانب العميل، يمكن استخدام ZKP في بعض تطبيقات الخصوصية، وهو ما تبني عليه منصات مثل Aleo أو Aztec أو Polygon Miden، ولكن تحقيق حماية خصوصية واسعة لجميع حالات الاستخدام المحتملة يعتمد أيضًا على تقدم MPC وFHE - هذا موضوع محتمل لمقالة مدونة مستقبلية.

6. مخاطر حجتنا

إذا كنا مخطئين، فلن يكون المستقبل كذلك. وحدات أليست المعرفة صفر؟ تتضمن بعض المخاطر المحتملة لحجتنا ما يلي:

النمطية تزيد من التعقيد

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

هل سيكون ZK فعالاً بدرجة كافية؟

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

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

يحاول Ingonyama إنشاء بعض معايير الأداء المثبتة من خلال مقياس قابل للمقارنة يسمى درجة ZK. ويعتمد على تكلفة تشغيل الحساب (OPEX) وتتبع MMOPS/WATT، حيث يشير MMOPS إلى عمليات المضاعفة المعيارية في الثانية. لمزيد من القراءة حول هذا الموضوع، ننصحك بمدونتي Cysic وIngonyama، بالإضافة إلى هذه المحادثة التي كتبها Wei Dai.

هل الخصوصية التي توفرها ZKP المحدودة مفيدة؟

لا يمكن استخدام ZKP إلا لتحقيق الخصوصية للحالات الفردية، بدلاً من الحالات المشتركة حيث تحتاج أطراف متعددة إلى إجراء حسابات على البيانات المشفرة (مثل Uniswap الخاص). تتطلب الخصوصية الكاملة أيضًا FHE وMPC، ولكن هناك حاجة إلى تحسينات كبيرة في التكلفة والأداء لتصبح خيارات قابلة للتطبيق للاستخدام على نطاق أوسع. ومع ذلك، لا يزال ZKP مفيدًا لبعض حالات الاستخدام التي لا تتطلب حالة مشتركة خاصة، مثل حلول الهوية أو المدفوعات. ليس من الضروري حل جميع المشاكل بنفس الأداة.

7. الملخص

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

بينما لا نزال في المرحلة التجريبية، يجب أن تستقر الأمور بمرور الوقت عندما نكتشف ما هو الأفضل لكل حالة استخدام وأين هي أفضل المقايضة ؟ وهذا بدوره سيوفر مساحة لظهور المعايير (غير الرسمية أو الرسمية) وتوفير المزيد من الاستقرار لأولئك الذين يبنون على رأس هذه السلاسل.

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

بينما تركز هذه المقالة على ZKP، فإننا أيضًا مهتمون بشكل متزايد بكيفية عمل حلول التشفير الحديثة (ZKP وMPC وFHE وTEE) معًا، وهو ما نقوم به 'لقد بدأت بالفعل في رؤية.