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

المؤلف: هانيس هويتولا المصدر: أبحاث مختبرات التوازن الترجمة: شان أوبا، جولدن فاينانس

ما هي سلاسل الكتل وكيف تعمل على توسيع نموذج الحوسبة الحالي؟

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

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

p>

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

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

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

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

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

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

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

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

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

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

p>

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

1. ما هي أجزاء المكدس المعياري؟ تم دمجها مع ZKP، ما هي الأجزاء التي لا يزال يتعين استكشافها؟

2. ما هي المشاكل التي يمكن أن يخففها ZKP؟

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

المكدس المعياري لعام 2024

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

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

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

ZK في المكدس المعياري

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

p>

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

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

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

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

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

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

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

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

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

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

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

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

2 - التسلسل

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

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

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

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

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

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

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) أو Optimize من أجل سهولة المطورين بدلاً من محاولة التوافق إلى أقصى حد مع Ethereum. تتضمن الأمثلة على الأخير بروتوكول zkWASM (Fluent وDelphinus Labs) وzkMOVE (M2 وzkmove).

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

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

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

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

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

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

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

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

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

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

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

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

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

5 - الإثبات

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

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

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

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

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

< li>

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

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

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

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

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

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

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

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

p>

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

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

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

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

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

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

• إثبات ZK DAS: كان هناك بعض الاستكشاف لتوفر بيانات إثبات ZK، حيث ستتحقق العقد الخفيفة ببساطة من جذور 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 إلى حل هذه المشكلة عن طريق إلغاء مكافآت الستاكينغ وبدلاً من ذلك التعامل مع الأسهم غير المراهنة والملكية كأصول منفصلة. يحافظ هذا الأسلوب على خصوصية التفويضات الفردية، بينما يظل المبلغ الإجمالي المرتبط بكل مدقق عامًا.

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

المشكلات المفتوحة التي يمكن لـ 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 وإخضاعها لمخاطر تقليص إضافية (شروط جزائية) بدلاً من يحاول كل مكون تشغيل الأمان الخاص به. كانت هناك بعض المحاولات المبكرة لفعل الشيء نفسه في شبكات إثبات العمل (التعدين المدمج)، ولكن الحوافز غير المتسقة تجعل من السهل على القائمين بالتعدين التواطؤ واستغلال البروتوكول (بما أن العمل يحدث في العالم المادي، فمن الصعب معاقبة السلوك السيئ ، أي استخدام حساب القدرة). يعد أمان PoS أكثر مرونة ويمكن استخدامه بواسطة بروتوكولات أخرى لأنه يحتوي على حوافز إيجابية (مكاسب الرهان) وحوافز سلبية (تقطيع).

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

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

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

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

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

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

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

11 - إمكانية التشغيل التفاعلي

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

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

p>

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

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

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

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

• ZK Oracles: تعمل Oracles كوسطاء، حيث تربط بيانات العالم الحقيقي بـ blockchain. تعمل أوراكل ZK على تحسين نماذج أوراكل الحالية القائمة على السمعة من خلال إثبات أصل البيانات وسلامتها وأي حسابات يتم إجراؤها على تلك البيانات.  

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

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

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

متى التهم ZK المجموعة المعيارية؟

لنفترض أنه يمكننا الوصول إلى حالة يصبح فيها توليد ZKP سريعًا جدًا (بسرعة الضوء تقريبًا) ورخيصًا جدًا< م >(مجاني تقريبًا)، فكيف سيبدو الوضع النهائي؟ بمعنى آخر - متى أكل ZK المكدس المعياري؟

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

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

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

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

مخاطر أطروحتنا

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

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

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

p>

هل أداء ZK جيد بما فيه الكفاية؟  

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

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

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

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

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

الملخص

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

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

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

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