فاليديوم

فاليديوم هو حل للتوسع يفرض سلامة المعاملات باستخدام إثباتات الصلاحية مثل رول أب المعرفة الصفرية، لكنه لا يخزن بيانات المعاملات على شبكة إيثريوم الرئيسية. بينما يؤدي توفر البيانات خارج السلسلة إلى مقايضات، فإنه يمكن أن يؤدي إلى تحسينات هائلة في قابلية التوسع (يمكن لشبكات فاليديوم معالجة ~9,000 معاملة، أو أكثر، في الثانية (opens in a new tab)).

المتطلبات الأساسية

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

ما هو الفالديوم ؟

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

يمكن أن تأتي "أدلة الصلاحية" هذه في شكل ZK-SNARKs (حجة المعرفة المختصرة غير التفاعلية ذات المعرفة الصفرية) أو ZK-STARKs (حجة المعرفة الشفافة القابلة للتطوير ذات المعرفة الصفرية). المزيد حول إثباتات المعرفة الصفرية (opens in a new tab).

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

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

هذا هو الفرق الرئيسي بين validiums و ZK-rollups - مواقعهما على طيف توفر البيانات. يتعامل كلا الحلول مع تخزين البيانات بشكل مختلف، مما له آثار على الأمن وانعدام الثقة.

كيف تتفاعل validiums مع إيثريوم؟

Validiums عبارة عن بروتوكولات توسيع مبنية على سلسلة إيثريوم الموجودة. على الرغم من تنفيذ المعاملات خارج السلسلة، فإن سلسلة فالديوم تُدار بواسطة مجموعة من العقود الذكية المنشورة على الشبكة الرئيسية بما في ذلك:

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

تعتمد Validiums أيضًا على سلسلة إيثريوم الرئيسية فيما يلي:

التسوية

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

حماية

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

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

كيف يعمل فالديوم؟

المعاملات

يقوم المستخدمون بإرسال المعاملات إلى المشغل، وهي العقدة المسؤولة عن تنفيذ المعاملات على سلسلة فالديوم. قد تستخدم بعض شبكات فاليديوم مُشغِّلاً وحيداً لتنفيذ السلسلة أو تعتمد على آلية إثبات الحصة (PoS) لتدوير المُشغِّلين.

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

التزامات الحالة

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

لإجراء تحديث للحالة، يجب على المشغل حساب جذر حالة جديد (بعد تنفيذ المعاملات) و تسليمة إلى عقد السلسلة. إذا تم التحقق من صحة الدليل، فسيتم قبول الحالة المقترحة ويتم تبديل الصلاحية إلى جذر الحالة الجديد.

الإيداعات والسحوبات

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

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

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

تقديم الدُفعات

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

على عكس ZK-rollup، لا يُطلب من منتجي الكتل على فالديوم نشر بيانات المعاملات لدفعات المعاملات (رؤوس الكتل فقط). وهذا يجعل فاليديوم بروتوكول توسع خارج السلسلة بشكل بحت، على عكس بروتوكولات التوسع "الهجينة" (أي الطبقة 2) التي تنشر بيانات الحالة على سلسلة إيثريوم الرئيسية باستخدام بيانات blob، أو calldata، أو مزيج منهما.

توفر البيانات

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

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

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

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

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

لجنة توفر البيانات (DAC)

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

ومع ذلك، يتعين على المستخدمين الثقة في DAC لجعل البيانات متاحة عند الحاجة إليها (على سبيل المثال، لتوليد أدلة ميركل). هناك احتمال أن يتعرض أعضاء لجان توفر البيانات للاختراق من قبل جهة فاعلة خبيثة (opens in a new tab) يمكنها بعد ذلك حجب البيانات خارج السلسلة.

توفر البيانات المضمون بسندات

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

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

Volitions وفاليديوم

توفر Validiums العديد من الفوائد ولكنها تأتي مع بعض التنازلات (أبرزها توفر البيانات). ولكن، كما هو الحال مع العديد من حلول التوسع، فإن validiums مناسبة لحالات استخدام محددة - وهذا هو السبب في إنشاء volitions.

يجمع Volitions بين سلسلة ZK-rollup و فاليديوم ويسمح للمستخدمين بالتبديل بين حلول التوسع. باستخدام Volitions، يمكن للمستخدمين الاستفادة من توفر البيانات خارج السلسلة في فاليديوم لبعض المعاملات، مع الاحتفاظ بحرية التبديل إلى حل توفر البيانات على السلسلة (ZK-rollup) إذا لزم الأمر. وهذا يمنح المستخدمين حرية اختيار التنازلات حسب ظروفهم الفريدة.

قد تفضل البورصة اللامركزية (DEX) استخدام البنية التحتية القابلة للتطوير والخاصة لـ فاليديوم للتداولات ذات القيمة العالية. يمكنه أيضًا استخدام ZK-rollup للمستخدمين الذين يريدون ضمانات أمان أعلى وعدم ثقة من ZK-rollup.

شبكات فاليديوم وتوافق آلة إيثريوم الافتراضية (EVM)

مثل ZK-rollups، فإن validiums مناسبة في الغالب للتطبيقات البسيطة، مثل تبادل الرموز والمدفوعات. يصعب تنفيذ دعم الحساب العام وتنفيذ العقود الذكية بين شبكات فاليديوم، نظرًا للتكاليف الإضافية الكبيرة لإثبات تعليمات آلة إيثريوم الافتراضية (EVM) في دائرة إثبات المعرفة الصفرية.

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

ومع ذلك، تحاول بعض الفرق تحسين أكواد عمليات EVM الحالية للدوائر التي تثبت ZK. سيؤدي هذا إلى تطوير آلة افتراضية إيثريوم بدون معرفة (zkEVM)، وهي آلة افتراضية متوافقة مع EVM تنتج أدلة للتحقق من صحة تنفيذ البرنامج. باستخدام zkEVM، يمكن لسلاسل validium تنفيذ العقود الذكية خارج السلسلة وإرسال أدلة الصلاحية للتحقق من صحة الحساب خارج السلسلة (دون الحاجة إلى إعادة تنفيذه) على إيثريوم.

المزيد حول zkEVMs (opens in a new tab).

كيف تقوم Validiums بتوسيع نطاق إيثريوم؟

1. تخزين البيانات خارج السلسلة

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

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

2. الإثباتات العودية

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

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

إيجابيات وسلبيات فاليديوم

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

استخدام فاليديوم/Volitions

توفر العديد من المشاريع تنفيذات لـ Validium وvolitions التي يمكنك دمجها في تطبيقاتك اللامركزية:

StarkWare StarkEx - StarkEx هو حل توسع للطبقة 2 (L2) من إيثريوم يعتمد على إثباتات الصلاحية. يمكن تشغيله في وضعي توفر البيانات ZK-Rollup أو Validium.

Matter Labs zkPorter- zkPorter هو بروتوكول توسع للطبقة 2 يعالج توفر البيانات بنهج هجين يجمع بين أفكار رول أب المعرفة الصفرية والتقسيم. يمكنه دعم أي عدد من الأقسام، ولكل منها سياسة توفر البيانات الخاصة به.