بروتوكول لا مركزي لتوسيع نطاق التحقق من SNARKs في البلوكتشين

مقدمة

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

تلعب zkSNARKs دورًا حاسمًا في تمكين حالات الاستخدام حينما تكون خصوصية بيانات المستخدم أمرًا أساسيًا أثناء المشاركة في التطبيقات اللامركزية.

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

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

على سبيل المثال، يتيح ذلك للعقد الذكي على السلسلة التحقق من العمليات المتعلقة ببيانات المستخدمين من خلال التحقق من صحة إثبات "zero-knowledge"، مما يلغي ضرورة الوصول إلى البيانات الخاصة للمستخدمين.

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

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

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

هناك استعمال مهم آخر لـ zkSNARKs يتعلق بقابلية التوسع. كما ذكرنا جزئيًا أعلاه، وبمعنى أكثر عمومية، يمكن اعتبار إثبات SNARK بمثابة إثبات مقتضب للحساب. على سبيل المثال، إذا كانت العملية الحسابية تتضمن تنفيذ جهاز افتراضي (VM)، من الممكن إنشاء إثبات موجز على تنفيذ الجهاز الافتراضي، بما في ذلك جهاز إيثريوم افتراضي (EVM).

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

علاوة على ذلك، فإن دمج مبادئ "zero-knowledge" مع الذكاء الاصطناعي يحمل إمكانات هائلة. فهو يسمح باستخدام نماذج الذكاء الاصطناعي دون الحاجة للتنفيذ على السلسلة. وبدلاً من ذلك، يتم التحقق من النتيجة المنفذة فقط على السلسلة، مما يقلل من الحمل الحسابي مع الحفاظ على سلامة عمليات الذكاء الاصطناعي.

في مثل هذا السيناريو، يصبح من الضروري تصميم نظام يمكنه دعم عدد متزايد من المعاملات باستخدام إثباتات ZK ليتم التحقق منها على السلسلة.

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

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

نموذج

يتمثل النهج الذي يمكنه مواجهة هذه التحديات في بناء نظام يستفيد من مزايا تكوين الإثبات العودي الفعال. يتضمن تكوين الإثبات العودي إنشاء إثبات جديد يلخص ويتحقق من العديد من الإثباتات الموجودة، مما يقلل من تكلفة التحقق ويحسن قابلية التوسع لنظام بلوكتشين الذي يدعم معاملات "zero-knowledge".

 

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

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

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

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

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

في مثل هذا السيناريو، من أجل التفاعل مع التطبيق، يجب على المستخدم تقديم إثبات ZK مع المعاملة.

 

مخطط رفيع المستوى

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

على مستوى عالٍ جدًا، يقوم بروتوكول SNARKtor بمعالجة الإثباتات بشكل مستمر من خلال تجميعها بطريقة لا مركزية ويقدم بشكل دوري إثباتاً مجمعًا على السلسلة.

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

يمكن جعل هذه العملية شفافة تمامًا للمستخدم من خلال تنفيذ واجهة مستخدم جيدة التصميم.

 

الجهات الفاعلة

وبالنظر عن كثب، يمكننا تحديد الجهات الفاعلة التالية المشاركة في البروتوكول:

المستخدمين:

يقدم المستخدمون طلبات لإثباتات ZK التي يريدون تجميعها. عندما يتم تجميع إثبات ZK المقابل وإرساله على السلسلة، يمكن للمستخدم إرسال معاملة تشير إلى الإثبات المجمع.

المجدولون:

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

المثبتون:

العاملون الفعليون الذين يقومون بمهمة دمج الإثباتات حسب الجدول الزمني المقدم من المجدولين.

المقدمون:

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

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

سير عمل التجميع

يعمل البروتوكول في بيئة يتم فيها تقسيم الوقت إلى أقسام ذات مدة ثابتة.

• يقدم المستخدمون بشكل مستمر الإثباتات الخاصة بهم مما يزيد من قائمة انتظار الإثباتات.

• يتم تعيين كل قسم لمجدول إثباتات وفي بداية كل قسم يلتقط المجدول مجموعة من الإثباتات من قائمة انتظار الإثباتات ويصدر جدولاً يحدد أي من المثبتين يجب أن يدمج أي من إثباتات ZK.

• يقوم كل مُثبِّت معين بدمج الإثباتات المعينة ومشاركة الإثبات المدمج الناتج مع المشاركين الآخرين في الشبكة.

• تتم إضافة الإثباتات المدمجة الناتجة إلى قائمة انتظار الإثباتات وتتم إزالة إثباتات المصدر ذا الصلة منها.

• تستمر حلقة الجدول الزمني إلى ما لا نهاية.

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

• يتم تعيين كل فترة تقديم لمقدم معين.

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

 

العوائد

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

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

https://eprint.iacr.org/2024/099.pdf

الاستنتاجات

تلعب تقنيات "zero-knowledge" دورًا متزايد الأهمية في نظام البلوكتشين مما يسمح بمجموعة واسعة من التطبيقات المختلفة، مثل المعاملات التي تحمي بيانات المستخدمين، والمطابقة، ومجموعات ZK، وقابلية التشغيل البيني الغير المعتمدة على الثقة بين السلاسل، وغيرها الكثير.

ومع ذلك على الرغم من كل التطورات في تحسين أنظمة إثبات ZK، فإن تنفيذها على السلسلة لا يزال مكلفًا.

مع SNARKtor، نقترح حلاً لا مركزيًا لتقليل تكلفة التحقق بشكل كبير وتحسين قابلية التوسع لنظام بلوكتشين الموجود.

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