نظرة عامة على Rollup

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

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

بالمقارنة مع البرامج التي تعمل خارج السلسلة، تتميز Rollups بخصائصين:

• تم حل توفر بيانات الحالة للطبقة الثانية عن طريق تخزينها على السلسلة الرئيسية. تسجل منصة الطبقة 2 جميع معلومات المعاملات أو تغييرات الحالة الكاملة في الطبقة 2 في كتل على السلسلة الرئيسية. في حالة فقدان حالة الطبقة 2، يمكن لأي شخص استعادة الحالة المفقودة من المعلومات المخزنة على السلسلة الرئيسية.
• في نظام Rollup، يتعين التحقق بطريقة ما على السلسلة الرئيسية من تغييرات جذر الحالة في الطبقة 2 المعبأة والمخزنة على السلسلة الرئيسية. بعد التحقق، سيتم قفل حالة الطبقة 2 على سلسلة الطبقة 1 الرئيسية. لذلك، في ظل نظام التحقق الآمن، يمكن للطبقة 2 الاستمتاع بنفس مستوى الأمان كما في الطبقة 1.

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

نوع آخر من حلول الRollup هو zk Rollup. في هذا النوع من النظام، بعد تنفيذ تحديث حالة الطبقة 2، يجب على مشغل الطبقة 2 تقديم دليل على صحة تحديث الحالة وتقديمه إلى السلسلة الرئيسية مع تحديث الحالة. سيقوم العقد على السلسلة الرئيسية بالتحقق من الدليل لتحديد صحة تحديث الحالة.

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

كما هو موضح في الشكل أدناه، في مجال توسيع الطبقة 2 Rollup، يحتل zkRollup بالفعل أكثر من نصف الأراضي ويتطور بسرعة.

مصدر الصورة

البيانات المُسترجعة في: 18 يناير 2024

من zkRollup المتخصص إلى zkRollup العام

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

الفرق بين هاتين النوعين من تقنية zkRollup يكمن أساسا في ما إذا كانت منصة الطبقة 2 تنفذ منطق متخصص محدد كتبته مزود المنصة أم منطق عقد ذكي تم كتابته بواسطة المستخدمين في المعاملات.

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

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

لماذا لا تسمح zkRollups المتخصصة للمستخدمين بنشر واستخدام عقودهم الذكية الخاصة؟ يعود ذلك إلى بنية البرهان لذات zkRollup.

لضمان أن تكون عمليات انتقال الحالة L2 صحيحة وموثوقة، في zkRollup، يجب كتابة جميع منطق انتقال حالة L2 كدوائر إثبات معرفة الصفر والتحقق منها من قبل عقود L1. يمكن قبول الحالات التي تمر بالتحقق فقط من قبل L1 وفي نهاية المطاف إكمال الRollup. يتطلب هذا العملية أن يتم التحقق من جميع منطق تنفيذ المعاملات لمنصة zkRollup في دائرة إثبات معرفة الصفر. ومع ذلك، دعم تنفيذ منطق العقد التعاقدي العشوائي في دوائر إثبات معرفة الصفر يشكل تحديًا (سيتم شرح أسباب هذا الصعوبة لاحقًا في النص). ونتيجة لذلك، غالبًا ما دعمت مشاريع zkRollup المبكرة فقط عددًا محدودًا من المعاملات البسيطة نسبيًا.

القدرة على تنفيذ عدد ثابت فقط من المعاملات البسيطة لا يلبي بوضوح توقعاتنا لـ zkRollup. لحسن الحظ، تم حل تقنية zkVM (الجهاز الظاهري Zero-Knowledge) صعوبة إثبات تنفيذ أي كود Turing-complete تعسفي ضمن دوائر البرهان Zero-Knowledge، مما يجعل منصة zkRollup العامة إمكانية. فيما يلي، سيقدم هذا المقال مبادئ التنفيذ لـ zkVM، مما يتيح للقراء فهم كيفية عمل هذا الجزء الأساسي الأكثر أهمية من تقنية zkRollup العامة.

مبادئ تنفيذ zkVM

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

مقدمة إلى الأدلة الصفرية المعرفة

البراهين الصفرية في zkRollup تخدم لإثبات أن تم تنفيذ معاملات الطبقة 2 بشكل صحيح وأن حالة الطبقة 2 تم تحديثها بشكل صحيح.

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

لماذا تحتاج البراهين دون المعرفة الصفرية

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

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

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

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

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

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

عملية الأدلة بدون معرفة

المقال التالي سيستخدم الحساب البسيط أدناه كمثال لشرح عملية البراهين بدون معرفة.

c=a²+b+5

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

عند الإثبات، يختار الإثبات قيمة أولية ل a و b على التوالي كمدخلات ويحسب قيمة c. هنا، نضع a = 3، b = 2، ثم c = 16. بعد إتمام جميع الحسابات، يمكن للمثبت إنشاء دليلًا على عدم المعرفة لهذه القيم والعمليات.

بعد إكمال الإثبات، سيقدم المثبت للتحقق المدخلات العامة للإثبات (أي قيم a و c) بالإضافة إلى دليل الصفر المعرفة.

بمجرد استلام البرهان، يمكن للمحقق، من خلال التحقق من البرهان الخالي من المعرفة، أن يقتنع بأن المثبت قد استخدم إدخالًا سريًا b، مما يجعل الصيغة أعلاه صحيحة عندما a = 3 و c = 16 (أي قيم الإدخال العامة)، وغير قادر على الحصول على أي معلومات خارج الإدخالات العامة (a = 3، c = 16)

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

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

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

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

لذلك، يمكن أيضًا تمثيل دائرة البوابة للدائرة الحسابية في الشكل التالي:

بيان:

أ ، ج

شاهد:

ب، د، ه

قيد:

d = a * a

e = b + 5

c = k + e

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

في التطبيقات الفعلية، يحتاج مستخدمو الأدلة بدون معرفة إلى كتابة المنطق الذي يحتاجونه في كود المصدر zk circuit وتوليد VK مقابله من خلال التدقيق. يتم تسليم هذا VK إلى المتحقق. يتم تقديم المدخلات العامة التي أثبتها المثبت، جنبًا إلى جنب مع الدليل المولد، ويمكن للمتحقق التحقق مما إذا كانت هذه المدخلات العامة تفي بالقيود. في هذا المثال، يمكن للمثبت توليد دليل بقيم a و b و c. يمكن للمتحقق التحقق مما إذا كان a2 + b يساوي C دون أداء هذه العملية.

القيود المتعلقة بدوائر البرهان بدون معرفة

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

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

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

خذ العملية التالية كمثال:

if (flag) {

c = k + k

} else {

c = x * x

}

عند تحويل هذه العملية إلى دائرة حسابية، ستتم تحويلها إلى القيود المبينة أدناه. من الواضح أنه سيتم إضافة شاهدَين جديدين، temp1 وtemp2، إلى الدائرة. بالإضافة إلى ذلك، سيتم حساب قيمة x+x وقيمة x*x على حد سواء.

وهذا يعني أن في دائرة zk، سيتم حساب جميع الفروع والمنطق، سواء تم تنفيذها أم لا.

temp1 = x + x

temp2 = k * k

c = flagtemp1 + (1-flag)temp2

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

إثبات تنفيذ أي برنامج — إثبات وجود آلة حالة عالمية في دائرة

مصدر الصورة

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

نفترض أن هذه الآلة الحاسبة العالمية لديها سجلات عامة (A و B)، وبالإضافة إلى ذلك، سجل عداد البرنامج الذي يخزن رقم التعليمة الحالية.

حالة السجلات قبل تنفيذ التعليمة

الشكل أدناه يظهر سير عمل أساسي لدائرة إثبات جهاز الكم الافتراضي ZK:

يمكن اعتبار الحالة 0 الحالة الأولية لهذه الآلة الافتراضية قبل التشغيل. تصل الحالة الأولية، بعد إجمالي عدد m من التعليمات، إلى الحالة النهائية m. بالإضافة إلى الحالة الأولية، تحتوي هذه الآلة الافتراضية على جدولي إدخال منتظمين:

• جدول البايتكود: يخزن البرنامج الذي تم تنفيذه في الجهاز العامل.
• الجدول الخاص بالإدخال/الإخراج: يخزن جميع الإدخالات والإخراجات التي تم إنشاؤها أثناء تنفيذ الجهاز الظاهري.

في الشكل، يتم تجريد عملية تنفيذ التعليمة الفرعية وعرضها على اليسار. ينتقل حالة الجهاز الحالية، الحالة n، إلى الحالة n+1 بعد تنفيذ التعليمة الفرعية. نفس الدائرة، بعد m تكرارًا، تحقق تنفيذ m تعليمات في vm.

هناك قضيتان هنا.

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

الثاني هو كيفية إثبات ما إذا كان عدد التعليمات التي يجب تنفيذها ليست m؟

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

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

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

إثبات تعليم أساسي

هنا بعض التعليمات الحسابية الأساسية كمثال على كيفية إثبات التعليمات الأساسية في الدائرة:

مصدر الصورة

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

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

من هذه الشكل، يمكننا أن نرى أنه من أجل بناء قيود لتغييرات الحالة، يقدم الدائرة بعض الحالات التحكم الإضافية:

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

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

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

إثبات الأحكام الشرطية والقفزات في تدفق التحكم

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

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

أولاً، نقدم دليل الحكم على الشرط:

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

هذه العملية مقيدة بالصيغتين في الرسم التخطيطي.

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

بمجرد أن نحصل على حالة الدعم الفرعية هذه isZero condition، يمكننا المضي قدماً في إثبات تعليمات القفز الشرطية:

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

العمليات المعقدة والإدخال/الإخراج

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

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

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

مصدر الصورة: 1 2

الرسم البياني على اليسار هو هندسة الدائرة لمشروع Scroll، والرسم البياني في الزاوية السفلية اليمنى هو هندسة الدائرة لـ Polygon. كلاهما يستخدمان نهجًا مماثلاً كما هو موضح في الرسم البياني في الزاوية العلوية.

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

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

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

صحة كل مكالمة وقيمة إرجاع في جدول البحث مقيدة ومثبتة بواسطة دائرة متخصصة.

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

يحتاج العقد L1 فقط إلى التحقق من هذا البرهان الكلي لتأكيد صحة عملية تنفيذ الجهاز الظاهري بأكمله.

استنتاج

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

ومع ذلك، مع تطوير ونضوج الآلات الافتراضية zk، أصبح دعم تنفيذ Turing-complete للعقود الذكية التعسفية ممكنًا. سيتم الكشف عن الإمكانيات الحقيقية لـ zkRollup، محققًا رؤيتها في كسر مأزق البلوكشين.

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

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