تحذير
تم أرشفة هذا الصندوق. انتقل التطوير إلى مستودع zksync-crypto. يرجى استخدامه بدلا من ذلك.
zkSync Era عبارة عن طبقة تراكمية من الطبقة الثانية تستخدم براهين المعرفة الصفرية لتوسيع نطاق Ethereum دون المساس بالأمان أو اللامركزية. نظرًا لأنه متوافق مع EVM (Solidity/Vyper)، يمكن إعادة نشر 99% من مشاريع Ethereum دون إعادة البناء أو إعادة تدقيق سطر واحد من التعليمات البرمجية. يستخدم zkSync Era أيضًا مترجمًا يستند إلى LLVM والذي سيسمح للمطورين في النهاية بكتابة عقود ذكية بلغة C++ وRust وغيرها من اللغات الشائعة.
الغرض من هذه المكتبة هو العمل باستخدام عملية حسابية محددة للغاية مع افتراضات إضافية حول حجم الحقل. تقريبًا، نتوقع أن يكون لدينا حقل F مع |F| ~ 64 بت (حجم كلمة الآلة) (الافتراض حول حجم الحقل ليس مهمًا لاستراتيجية الحساب ووضع البوابة، ولكن يتم التأكيد عليه في تطبيقات الأجهزة لوظائف معينة تعتمد على حجم حقل محدد).
يحتوي النظام على تسلسل هرمي للوظيفة المنطقية (الأدوات) - البوابات (الكيانات التي يمكنها تسجيل نفسها في التتبع) - والمقيمين (العلاقات بين كثيرات الحدود). تتم كتابة المقيِّمين في شكل سمة تتيح لنا لاحقًا إنشاء وظائف تلقائيًا للتحقق من مدى الإرضاء وحساب البراهين، بالإضافة إلى تجميع أدوات التحقق البسيطة والمتكررة. تحتوي البوابات على أدوات إضافية ملحقة بها تسمح للبوابات نفسها بتتبع منطق المكان الذي يجب وضعها فيه في التتبع. لاحظ أننا نعتمد على قيود النسخ الخاصة بـ Plonk ونعمل على الكيانات المنطقية القابلة للنسخ لـ "المتغيرات" لتكوين بيان نهائي قابل للإثبات. النظام غير مخصص لحساب AIR ولا يسمح بالتعبير عن القيود التي تمتد عبر صفوف متعددة من التتبع.
بشكل عام، يقيد التتبع أنواعًا قليلة من الأعمدة. والفصل الرئيسي هو بين:
بالإضافة إلى ذلك، يتيح لك التتبع إضافة وسيطة بحث، والتي يمكنها أيضًا استخدام أعمدة متخصصة لإيواء إدخالات جداول البحث، أو استخدام أعمدة ذات أغراض عامة فقط. يتم ترميز الجداول كمجموعة واحدة فقط من متعددات الحدود في الوقت الحالي، لذا يجب أن يكون إجمالي طول التتبع أكبر من إجمالي عدد الإدخالات في الجداول.
لاحظ أن كل "بوابة" (كنوع الصدأ) فريدة من نوعها، وبالتالي لا يمكن وضع البوابة إلا في أعمدة مخصصة أو عامة الأغراض، ولكن ليس في كليهما. إذا كان أحد يحتاج إلى مثل هذه الوظيفة فمن الممكن إنشاء غلاف نوع جديد.
تُستخدم الوظائف المنطقية ذات المستوى الأعلى (مثل التحلل المنطقي، والتحقق من النطاق، والفحوصات الصفرية، وما إلى ذلك) لإنشاء دائرة تسجل نفسها داخليًا بطرق مختلفة اعتمادًا على ما إذا كانت بعض البوابات مسموحًا بها أم غير مسموح بها في المثيل المحدد لـ CS. تعتبر مثيلات CS مع مجموعات مختلفة من البوابات نوعًا مختلفًا من منظور Rust، ونحن نعتمد على بعض أعمال الدعم/المترجم المضمنة/الثابتة لتقليل التفرع إلى قفزات ثابتة.
|F| ولذا يتعين علينا تكرار الوسيطات)، ولكن سيتم تغيير هذا بحيث ننتقل إلى حقل الامتداد كما هو بأسرع ما يمكن بعد الالتزام بالشاهد لتجنب فرصة "كبيرة" للحصول على أصفار في المقام. التأثير على النفقات الحسابية في الإثبات لا يكاد يذكر نحن نستخدم وسيطة بحث يتم فرضها عبر العلاقات sum_i selector(x_i) / (witness(x_i) + beta) == sum_i multiplicity(x_i) / (table(x_i) + beta) حيث يتم البحث عن selector(x_i) هي مجرد هوية. نحن أيضًا لا نقوم بتشفير الجداول على أنها متعددة الحدود ذات درجة أصغر للتخلص من عمليات التحقق المرتبطة بالدرجات الإضافية، وبدلاً من ذلك نقوم بحشوها بالأصفار. لاحظ أن إدخالات الجدول لا تحتوي أبدًا على عنصر (0,0,...,0) لأننا نستخدم أعمدة معرف منفصلة لأنواع الجداول في حالة وجود جداول متعددة (حتى في حالة استخدام جدول واحد فقط)، ومعرف مثل هذا يبدأ بـ 1.
إحدى الميزات الرائعة لوسيطة البحث مثل هذه هي أنه نظرًا لطبيعتها المضافة، إذا أجرينا عمليات بحث على كثيرات الحدود witness المتعددة في نفس الجدول، بدلاً من تكرار الوسيطة لكل (مجموعة) من كثيرات الحدود (الأمر الذي قد يتطلب عمود تعدد منفصل، بالإضافة إلى عدد قليل من متعددات الحدود المتوسطة لاحقًا)، يمكننا "جمع" التعدديات وتحويل الوسيطة إلى شيء مثل sum_i selector_0(x_i) / (witness_0(x_i) + beta) + sum_i selector_1(x_i) / (witness_1(x_i) + beta) == sum_i total_multiplicity(x_i) / (table(x_i) + beta) ، بحيث تكون التكلفة الإجمالية للبحث هو مجرد عمود واحد من التعددات، و2 (مرتبط بالشاهد) + 1 (متعلق بالجدول) متعددات الحدود المتوسطة إلى تشفير العلاقات lhs وrhs على جذور الوحدة.
وصحة هذه الحجة واضحة. من أجل السلامة، نستخدم الوسيطة الأصلية كما في ورقة "القسمة المخبأة لعمليات البحث السريعة"، Lemma 2.4. وعلينا أن نبين أنه يكفي الالتزام بالتعدد total_multiplicity وليس بتعدد witness_0 witness_1 على حدة.
افترض أن المعادلة sum_i selector_0(x_i) / (witness_0(x_i) + X) + sum_i selector_1(x_i) / (witness_1(x_i) + X) == sum_i total_multiplicity(x_i) / (table(x_i) + X) يحمل. نحن بحاجة إلى إظهار أن witness_0 witness_1 موجودان في الجدول t . دع f = (witness_0 | witness_1) سلسلة من القيم. تتضمن المعادلة أعلاه sum_i selector_i / (f_i + X) == sum_i total_multiplicity_i / (t_i + X) (لاحظ أن طول الفاصل الزمني لـ i على LHS هو ضعف ما ورد أعلاه). بواسطة Lemma 2.4 نحصل على f subset t : "مجموعة فرعية" بمعنى أن كل إحداثي للمتجه f هو إحداثي t . على وجه الخصوص، witness_0, witness_1 subset f subset t .
لاحظ أن الحجة تنطبق على العديد من witness_i أيضًا. بقية حجة السلامة، بالنسبة إلى beta المختارة، تتبع مباشرة كما في العمل أعلاه.
2^-40 للحصول على 0 في المقامات توجد معايير لـ 8 كيلو بايت من SHA256 باستخدام ما نعتقد أنه التكوين الأمثل إلى حد ما للبوابات + الجداول لدائرة SHA256. لاحظ أنه على الرغم من أن البرهان سريع نوعًا ما، إلا أننا لم نقم بتحسين FFT بشكل صحيح وما زلنا نستخدم Poseidon (وليس Poseidon2) للتكوينات حيث نتوقع استخدام الدليل للتكرار. يسمح لك نصان برمجيان sha256_bench_recursive.sh و sha256_bench_non_recursive.sh بتشغيل الاختبارات المقابلة (سواء كان من المتوقع استخدام الدليل في العودية أم لا)، ويجب عليك البحث عن سطر Proving is done, taken ... لمعرفة وقت الإثبات ، لأن المدقق الذي يتم تشغيله بعده مطول تمامًا. تستخدم هذه المعايير عامل LDE بقيمة 8، على الرغم من أن جميع القيود لدينا هي من الدرجة 4 أو أقل - ومع ذلك، فهي معلمة يتم استخدامها في بعض المعايير العامة الأخرى. نحن أيضًا لا نستخدم إثبات العمل (PoW) في تلك البراهين لأن إثبات العمل (PoW) لـ 20 بت لا يكاد يذكر (30 مللي ثانية)، ونحن لا ندعم إثبات العمل (PoW) على التجزئة الجبرية حتى الآن (على الرغم من أن هذه أبطأ بمقدار 2x فقط، لذا فهي أيضًا لا تذكر). يبلغ مستوى الأمان 100 بت تقريبًا، ولكن يمكن تعزيز سلامة FRI عن طريق زيادة عدد الاستعلامات، ولا تؤدي الزيادة في عدد الاستعلامات إلى زيادة وقت الإثبات (يجب عدم الخلط بينه وبين تغيير معدل FRI). طول التتبع هو 2^16 ويستخدم 60 عمودًا للأغراض العامة و8 وسيطات بحث بعرض 4.
ملاحظة: تحاول المعايير فقط التحويل البرمجي إلى القوس الأصلي ويتم عادةً اختبار قوس AArch64 (اقرأ Apple M1) فقط من البداية إلى النهاية في الوقت الحالي. تم اختبار التطبيقات الحسابية x86-64 للتأكد من صحتها، ولكن ليس من طرف إلى طرف في البراهين الكاملة. لاحظ أن الحد الأقصى للأداء x86-64 يتطلب إشارات إضافية لميزات المترجم بالإضافة إلى cpu = native (لا يتم استخدام مجموعة AVX512 بواسطة مترجم Rust حتى على وحدات المعالجة المركزية الأصلية)
يتم توزيع المثل Boojum تحت شروط أي منهما
في خيارك.
لقد مر zkSync Era بالعديد من الاختبارات وعمليات التدقيق. على الرغم من أنه حي، إلا أنه لا يزال في حالة ألفا وسيخضع لمزيد من عمليات التدقيق وبرامج مكافآت الأخطاء. نحن نحب أن نسمع أفكار واقتراحات مجتمعنا حول هذا الموضوع! من المهم الإشارة إلى أن تفرعها الآن قد يؤدي إلى فقدان التحديثات الأمنية المهمة والميزات المهمة وتحسينات الأداء.
يتضمن هذا البرنامج مكونات من أطراف ثالثة. للحصول على قائمة كاملة بهذه المكونات وتراخيصها، راجع ملف إشعارات الطرف الثالث.
