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

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

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

بينما يُصف Web3 في كثير من الأحيان بأنه "read, write, own"، نعتقد أن مفهومًا أفضل للإصدار الثالث من الإنترنت هو "read, write, verify" نظرًا لأن المنفعة الرئيسية للسلاسل العمومية هيالحساب المضمونوالتحقق السهل من أن هذه الضمانات تمت الالتزام بها. يمكن أن يكون الملكية جزءًا من الحوسبة المضمونة إذا بنينا الآثار الرقمية التي يمكن شراؤها وبيعها والتحكم فيها. ومع ذلك، تستفيد العديد من حالات استخدام سلاسل الكتل من الحوسبة المضمونة ولكن لا تشمل ملكية مباشرة. على سبيل المثال، إذا كانت صحتك في لعبة تمامًا على السلسلة 77/100 - هل تمتلك تلك الصحة أم أنها مجرد إلزام على السلسلة وفقًا للقواعد المتفق عليها عمومًا؟ سنجادل بأن الأخير، ولكن كريس ديكسونقد تختلف الآراء.

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

ZK والتناسق - اتجاهان سيسرعان

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

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

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

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

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

نعتقد أن كل من التجزئة و'ZKfication of everything' هما اتجاهان سيستمران في التسارع. بينما كل منهما يوفر عدسات مثيرة لاستكشاف المجال بشكل فردي - نحن مهتمون بشكل خاص بتداخل الاثنين. السؤالان الرئيسيان اللذان نحن مهتمون بهما هما:

1. أي أجزاء من الكتلة المعدلة قد اعتمدت بالفعل ZKPs وأي منها لم يتم استكشافه بعد؟
2. ما هي المشاكل التي يمكن تخفيفها باستخدام ZKPs؟

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

الكومة المتكاملة في عام 2024

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

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

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

ZK في الشبكة القابلة للتعديل

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

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

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

• تجريم التجريم (AA) يتيح للعقود الذكية إجراء المعاملات دون الحاجة إلى توقيع المستخدم لكل عملية (“حساب العملات الرقمية القابل للبرمجةيمكن استخدامه لتحديد من يمكنه التوقيع (إدارة المفاتيح) ، وما يجب توقيعه (حمولة tx) ، وكيفية التوقيع (خوارزمية التوقيع) ، ومتى يجب التوقيع (شرط موافقة المعاملة). مجتمعة ، تمكن هذه الميزات من أشياء مثل استخدام تسجيل الدخول الاجتماعي للتفاعل مع dApps ، و 2FA ، واستعادة الحساب ، والتشغيل التلقائي (توقيع tx تلقائيًا). بينما تدور المناقشة في كثير من الأحيان حول إيثريوم (ERC-4337تمر في ربيع عام 2023)، لديها سلاسل أخرى العديد من الحسابات المضمنة، والتجريد الأصلية بالفعلAptos, Sui, قريب, ICP, ستاركنت, و zkSync).
• يتيح التجريد السلسلي للمستخدمين توقيع المعاملات على سلاسل مختلفة مع التفاعل فقط مع حساب واحد (واجهة واحدة، سلاسل متعددة). هناك عدة فرق تعمل على هذا، بما في ذلك قريب، ICP, و محفظة.تستفيد هذه الحلول من تقنية حوسبة السر وتواقيع السلاسل، حيث يتم تقسيم المفتاح الخاص للشبكة الأخرى إلى قطع صغيرة عدة ومشاركتها عبر المحققين على سلسلة المصدر الذين يوقعون على معاملات السلسلة المتقاطعة. عندما يرغب المستخدمون في التفاعل مع سلسلة أخرى، يجب على عدد كاف من المحققين التوقيع على المعاملة لتحقيق تشفير الحد الأدنى. يحافظ ذلك على الأمان، حيث لا يتم مشاركة المفتاح الخاص بشكل كامل في أي مكان. ومع ذلك، فإنه يواجه خطر التواطؤ بين المحققين وهذا هو السبب في أن أمان التشفير الاقتصادي ولامركزية المحققين للسلسلة الأساسية لا زالت ذات أهمية كبيرة.
• تتيح النوايا ، على مستوى عال ، سد رغبات المستخدم واحتياجاته في العمليات التي يمكن تنفيذها بواسطة blockchain. وهذا يتطلب حل النوايا - وكلاء متخصصون خارج السلسلة مكلفون بإيجاد أفضل حل ممكن لنية المستخدم. هناك بالفعل العديد من التطبيقات التي تستخدم مقاصد متخصصة ، مثل مجمعات DEX ("أفضل سعر") ومجمعات الجسور ("أرخص / أسرع تجسير"). شبكات تسوية النوايا العامة (Anoma، ضروري, لطيف) تهدف إلى تسهيل تعبير المستخدمين عن نوايا أكثر تعقيدًا ولبناء تطبيقات مركزة على النية من قبل المطورين. لا تزال هناك العديد من الأسئلة المفتوحة، ومنها كيفية تشكيل العملية، وكيف يبدو لغة مركزة على النية، وما إذا كانت الحلول الأمثل موجودة دائمًا، وإذا كان بإمكان العثور عليها.

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

• المصادقة باستخدام AA x ZK: أحد الأمثلة على ذلك هو سوي’sتسجيل الدخول zk, والذي يتيح للمستخدمين تسجيل الدخول باستخدام بيانات اعتماد مألوفة مثل عنوان البريد الإلكتروني. يستخدم ZKPs لمنع الأطراف الثالثة من ربط عنوان Sui بمعرف OAuth المقابل له.
• تحقق توقيع أكثر كفاءة لمحافظ AA: يمكن أن يكون التحقق من عمليات التداول في عقود AA أكثر تكلفة بشكل كبير من تلك التي بدأتها حساب تقليدي (EOA).المداريحاول مواجهة هذه المشكلة من خلال خدمة التجميع التي تستفيد من ZKPs للتحقق من صحة تواقيع المعاملات والحفاظ على قيمة العدم ورصيد الغاز لحساب AA (من خلال شجرة حالة العالم Merkle). بمساعدة تجميع الدليل ومشاركة تكلفة التحقق في السلسلة بالتساوي بين جميع المستخدمين، يمكن أن يؤدي هذا إلى توفير تكاليف كبيرة.

المشاكل المفتوحة التي يمكن أن تحلها ZKPs

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

2 - تسلسل

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

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

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

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

المشاكل المفتوحة التي يمكن أن تحلها ZKPs

• قواعد التسلسل التي يمكن التحقق منها (VSR): تخضع المقترح/المتسلسل لـ مجموعة قواعد تتعلق بترتيب تنفيذ الأوامرمع ضمانات إضافية بأن هذه القواعد تُتبع. يمكن أن يتم التحقق إما من خلال ZKPs أو دلائل الاحتيال، حيث يتطلب الأخير وجود كفالة اقتصادية كبيرة تُقطع إذا تصرف المقترح/المرتب بشكل غير لائق.

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

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

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

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

• تراكيب zkEVM: نوع خاص من zkVM محسن ليكون متوافقًا مع إيثيريوم وإثبات بيئة تنفيذ EVM. كلما كانت القرب من إيثيريوم أكبر، كلما كان التضحية في الأداء أكبر. تم إطلاق العديد من تراكيب zkEVM في عام 2023، بما في ذلك بوليجون zkEVM, عصر zkSync،تمرير، و Lineaأعلنت بوليغون مؤخرًا عننوع 1 zkEVM prover، الذي يتيح إثبات كتل Ethereum الرئيسية مقابل 0.20-0.50 دولار لكل كتلة (مع الأماني القادمة لتخفيض التكاليف بشكل أكبر).لدى RiscZero أيضًا حلاًوهذا ما يمكن اثباته بلوكات ايثيريوم ولكن بتكلفة أعلى مع القليل من البيانات المتاحة للقياس.
• أنماط zkVMs البديلة: بعض البروتوكولات تتبع مسارًا بديلًا وتحسين الأداء/القابلية للإثبات ( ستاركنت, زورب) أو ودية المطور، بدلاً من محاولة أن تكون متوافقة بشكل قصوى مع إيثيريوم. أمثلة على ذلك تشمل بروتوكولات zkWASM (طَلِق, Delphinus Labs) و zkMOVE ( M2وzkmove٫
• zkVMs التي تركز على الخصوصية: في هذه الحالة، يتم استخدام ZKPs لشيئين: تجنب إعادة التنفيذ وتحقيق الخصوصية. بينما الخصوصية التي يمكن تحقيقها باستخدام ZKPs وحدها محدودة (فقط الحالة الشخصية الخاصة)، البروتوكولات القادمة تضيف الكثير من التعبير والقابلية للبرمجة إلى الحلول الحالية. الأمثلة تشمل Aleo’s snarkVM, أزتيكAVM، وPolygon’sميدينفم.
• معالجات زد-كيه: تمكن من الحوسبة خارج السلسلة على البيانات داخل السلسلة (ولكن بدون حالة). تُستخدم البراهين الصفرية لإثبات التنفيذ الصحيح، مما يوفر تسوية أسرع من معالجات الشراك التفاؤلية، ولكن هناك تضحية في التكلفة. نظرًا للتكلفة و/أو صعوبة إنشاء البراهين الصفرية، نرى بعض الإصدارات الهجينة، مثل Brevis coChain، الذي يسمح للمطورين باختيار وضع ZK أو التفاؤلي (تضحية بين التكلفة وصلابة الضمانات).

المشاكل المفتوحة التي يمكن أن تحلها ZKPs

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

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

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

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

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

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

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

فتح المشاكل التي يمكن ل ZKPs حلها

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

5 - إثبات

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

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

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

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

مصدر: رأس المال الوهمي

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

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

المشاكل المفتوحة التي يمكن أن تحلها ZKPs

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

المصدر: Figment Capital

6 - نشر البيانات (التوفر)

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

Celestiaكانت طبقة DP البديلة الأولى التي أطلقت شبكتها الرئيسية (31 أكتوبر)، ولكن ستظهر قريبًا العديد من البدائل للاختيار من بينها كـمتاح, EigenDA, و بالقرب من DAمن المتوقع أن تطلق جميعها خلال عام 2024. بالإضافة إلى ذلك، Ethereum’s EIP 4844ترقية نشر البيانات المُقيَّدة على إيثيريوم (بالإضافة إلى إنشاء سوق رسوم منفصلة لتخزين البلوب) وتمهيد الطريق لـ التقسيم الكامل للـ dank. DP يتوسع أيضًا إلى بيئات أخرى - مثال واحد هو @nubit_org/riema-secures-angel-investment-for-launching-the-first-bitcoin-native-data-availability-layer-49ccf0487380">Nubit الذي يهدف إلى بناء Native DP على بيتكوين.

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

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

• إثبات صحة ترميز المحو: يجلب ترميز المحو مستوى معينًا من التكرار بحيث يكون بإمكان استعادة البيانات الأصلية حتى لو كان جزء من البيانات المشفرة غير متوفر. كما أنه شرط مسبق لتقنية DAS حيث تقوم العُقَد الخفيفة بأخذ عينات فقط من جزء صغير من الكتلة لضمان بشكل احتمالي تواجد البيانات هناك. إذا قام مقترح خبيث بترميز البيانات بشكل غير صحيح، فقد لا يمكن استعادة البيانات الأصلية حتى لو أخذت العُقَد الخفيفة عينات كافية من القطع الفريدة. يمكن إثبات صحة ترميز المحو إما باستخدام أدلة الصحة (ZKPs) أو أدلة الاحتيال - الأخيرة تعاني من تأخير مرتبط بفترة التحدي. جميع الحلول الأخرى ما عدا Celestia يعملون على استخدام أدلة الصحة.
• عملاء ZK الخفيفة تدعم جسور البيانات: Rollups التي تستخدم طبقات نشر البيانات الخارجية ما زالت بحاجة إلى التواصل مع طبقة التسوية التي تم نشر البيانات بشكل صحيح. هذا هو الغرض من جسور شهادة البيانات. يجعل استخدام ZKPs التحقق من توقيعات التوافق في سلسلة المصدر أكثر كفاءة على إثريوم. كلا من Avail’s (VectorX) و (CelestiaBlobstreamX) يتم تشغيل جسور التصديق الخاصة بالبيانات بواسطة عملاء ZK الخفيفة التي تم بناؤها بالتعاون مع Succinct.

المشاكل المفتوحة التي يمكن أن تحلها ZKPs

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

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

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

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

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

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

مشاكل مفتوحة يمكن أن تحلها ZKPs

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

8 - التوافق

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

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

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

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

المشاكل المفتوحة التي يمكن أن تحلها ZKPs

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

9 - التسوية

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

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

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

• تسوية أسرع مع تكديس الصلاحية: في مقابل التكديس المتفائل، تكديس الصلاحية لا يتطلب فترة تحدي كما أنه يعتمد بدلاً من ذلك على ZKPs لإثبات انتقال الحالة الصحيحة سواء كان أحد يتحدى أم لا (تكديس متشائم). وهذا يجعل التسوية على الطبقة الأساسية أسرع بكثير (12 دقيقة مقابل 7 أيام على إثيريوم) ويتجنب إعادة التنفيذ.

10 - الأمان

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

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

البروتوكولات التي تبني على فكرة الأمان المشترك تشمل:

• تهدف EigenLayer إلى الاستفادة من أمان Ethereum الموجود لتأمين مجموعة واسعة من التطبيقات. تم إصدار الكتاب الأبيض في بداية عام 2023، ويتواجد EigenLayer حالياً في الإصدار التجريبي الرئيسي، ومن المتوقع أن يتم إطلاق الإصدار الرئيسي بالكامل في وقت لاحق من هذا العام.
• اطلقت كوسموس أمان الشبكات البينية (ICS) في مايو 2023، مما يتيح لهاب كوسموس - واحدة من أكبر السلاسل على كوسموس ومدعومة ب ~2.4 مليار دولار من ATOM المرهونة- لتأجير أمانها لسلاسل المستهلكين. من خلال استخدام نفس مجموعة المحققين التي تدعم Hub كوسموس للتحقق أيضًا من الكتل على سلسلة المستهلكين، تهدف إلى تقليل عتبة إطلاق سلاسل جديدة على أعلى من كوموسوس. حاليًا، ومع ذلك،فقط سلسلتين استهلاكيتين حية (نيوترون وسترايد).
• يحاول بابلون تمكين بيتكوين من استخدام الأمان المشترك أيضًا. لمواجهة المشاكل المتعلقة بالتعدين المدمج (صعوبة معاقبة السلوك السيء)، يتم بناء طبقة PoS افتراضية حيث يمكن للمستخدمين قفل بيتكوين في عقد رهن على بيتكوين (بدون جسر). نظرًا لعدم توفر طبقة العقود الذكية في بيتكوين، فإن قواعد التقليم في عقود الرهن تعبر بدلاً من ذلك بشكل عام عن صفقات UTXO المكتوبة في نص بيتكوين.
• إعادة الرهن على شبكات أخرى تشملأخطبوطعلى Near و Picasso على Solana. Polkadotالسلاسل الجانبيةيستفيد أيضًا من مفهوم الأمان المشترك.

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

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

11 - التوافق

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

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

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

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

• عملاء الضوء ZK (التحقق من الاتفاق): معظم عملاء الضوء الحاليين يتيح التحقق من الاتفاق في السلسلة الأخرى - إما بمجموعة المحققين الكاملة (إذا كانت صغيرة بما فيه الكفاية) أو جزء من المحققين الإجماليين (مثل لجنة مزامنة إيثريوم). يتم استخدام ZKPs لجعل التحقق أسرع وأرخص نظرًا لأن نظام التوقيع المستخدم على السلسلة الأصلية قد لا يكون مدعومًا بشكل أصلي على السلسلة الوجهة. بينما يُتوقع أن يزداد أهمية عملاء ZK الخفيفة في ربط السلاسل، فإن الاحتكاكات الحالية لتبني أوسع تشمل تكلفة الإثبات والتحقق مع تنفيذ عملاء ZK الخفيفة لكل سلسلة جديدة. أمثلة على البروتوكولات في هذا المجال تشمل الأجسام متعددة الأوجه, جسور تصديق البيانات لـ Avail و Celestia، و zkIBC بواسطة Electron Labs.
• دليل التخزين: كما ذكر سابقًا، تتيح أدلة التخزين استعلام البيانات التاريخية والحالية من سلاسل الكتل دون الحاجة إلى جهات ثالثة موثوقة. وهذا أيضًا ذو صلة لقابلية التشغيل المشترك حيث يمكن استخدامها للتواصل عبر سلاسل الكتل. على سبيل المثال، يمكن للمستخدم أن يثبت أن لديه رموز على سلسلة واحدة واستخدام ذلك للحوكمة على سلسلة أخرى (دون الحاجة إلى جسر). وهناك أيضًا محاولات لاستخدام أدلة التخزين للجسور، مثل هذا الحل الذي طورته لامبدا كلاس.
• بوابات: تعمل البوابات كوسطاء وتربط البيانات الحقيقية بالبلوكشين. تعمل بوابات الـ ZK على تحسين نماذج البوابات الحالية المعتمدة على السمعة من خلال تمكين إثبات أصل وسلامة البيانات، جنبًا إلى جنب مع أي عملية حسابية تمت على تلك البيانات.

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

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

متى أكل ZK من الوحدة التكدس؟

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

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

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

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

المخاطر المحتملة لفرضيتنا

ماذا لو كنا مخطئين، وأن المستقبل ليس مرنًا ولا ZK’fied؟ بعض المخاطر المحتملة لأطروحتنا تشمل:

تزيد الوحدات من التعقيد

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

هل سيكون ZK أبدًا كفء بما فيه الكفاية؟

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

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

Ingonyamaقامت بمحاولة إنشاء بعض المعايير الأساسية لأداء البرهان من خلال مقياس قابل للمقارنة يسمى ZK score. يعتمد على تكلفة تشغيل الحسابات (OPEX) ويتتبع MMOPS/WATT ، حيث يعني MMOPS عمليات الضرب العددية النمطية في الثانية. لمزيد من القراءة حول هذا الموضوع ، نوصي بالمدونات التي تنشرها @Cysic/BJQcpVbXn?ref=blog.succinct.xyz">سايسيك و @ingonyamaIngonyama، فضلا عن هذا الحديث منوي داي.

هل الخصوصية المحدودة التي يمكن توفيرها من خلال ZKPs ذات فائدة؟

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

ملخص

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

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

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

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

شكرا على القراءة!

تنصل:

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