تخطي إلى المحتوى الرئيسي
Change page

فاليديوم

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

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

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

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

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

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

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

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

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

كيف تتفاعل شبكات فاليديوم مع إيثيريوم؟

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

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

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

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

التسوية

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

الأمان

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

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

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

المعاملات

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

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

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

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

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

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

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

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

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

تقديم الدفعة

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

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

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

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

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

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

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

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

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

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

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

المزيد حول لجان توفر البيانات في شبكات فاليديوم (opens in a new tab).

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

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

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

المزيد حول توفر البيانات المضمون بسندات في شبكات فاليديوم (opens in a new tab).

الإرادات (Volitions) وفاليديوم

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

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

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

شبكات فاليديوم وتوافق EVM

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

تحاول بعض مشاريع فاليديوم تجنب هذه المشكلة عن طريق تصريف اللغات المتوافقة مع EVM (مثل Solidity و Vyper) لإنشاء رمز بايت مخصص ومحسن للإثبات الفعال. من عيوب هذا النهج أن الأجهزة الافتراضية الجديدة الصديقة لإثبات المعرفة الصفرية قد لا تدعم أكواد تشغيل EVM المهمة، ويجب على المطورين الكتابة مباشرة باللغة عالية المستوى للحصول على تجربة مثالية. هذا يخلق المزيد من المشاكل: فهو يجبر المطورين على بناء تطبيقات لامركزية (dapps) باستخدام حزمة تطوير جديدة تمامًا ويكسر التوافق مع البنية التحتية الحالية لإيثيريوم.

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

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

كيف تقوم شبكات فاليديوم بتوسيع إيثيريوم؟

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

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

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

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

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

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

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

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

استخدام فاليديوم/الإرادات

توفر مشاريع متعددة تطبيقات لفاليديوم والإرادات التي يمكنك دمجها في تطبيقاتك اللامركزية (dapps):

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

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

قراءة إضافية