تركيبة Layer-2 لـ ZKBase

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

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

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

تفاعل ذاكرة التخزين المؤقت لـ ZKBase مع مدير الحالة الغير قابل للتداخل وجهاز العرض الافتراضي لـ Ethereum (EVM)

تحتوي حلول Layer-2 في ZKBase على عدة مكونات تعمل بالتنسيق معًا لضمان صحة المعاملات وكفاءة الشبكة. يعد بركة الذاكرة خارج السلسلة (off-chain memory pool) مكان تخزين المعاملات غير المؤكدة قبل معالجتها. بعد الدخول إلى بركة الذاكرة ، يقوم مدير حالة النظام (state keeper) بمراقبة حالة جميع الحسابات والمعاملات في بيئة ZKBase. يضمن مدير حالة النظام تنفيذ المعاملات الصالحة فقط ، وبالتالي الحفاظ على حالة متسقة في جميع المستخدمين والتطبيقات.

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

من خلال اتصال WebSocket ، يتم التواصل بين ذاكرة التخزين المؤقت للسلسلة الجانبية والمستخدمين ، وتتبع المعاملات المعلقة وضمان قدرتها على المعالجة بكفاءة. بمجرد تجميع المعاملات في دفعة واحدة ، يتم التحقق من صحة هذه الدفعة بواسطة نظام البراهين المعرفية ثم يتم إرسالها إلى EVM للتحقق النهائي من الحالة. يتيح هذا التصميم لـ ZKBase الحفاظ على أمان Ethereum وخاصية عدم الحاجة إلى الثقة مع تفريغ معظم العمليات الحسابية.

كيف تضمن البرهانات الصفرية المعرفة أمان النظام

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

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

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