مقدمة العملة

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

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

الوصول إلى البيانات على السلسلة

هناك عدد من الطرق التي يمكن من خلالها لـ dapps الوصول إلى البيانات والحالة. تتطلب جميع الأساليب من التطبيق وضع الثقة في البشر/الكيانات أو الأمن الاقتصادي للعملات المشفرة أو التعليمات البرمجية والحصول على بعض المقايضات:

الثقة في البشر/الكيانات:

• عقد الأرشيف: يمكن للمشغلين تشغيل عقدة أرشيف بأنفسهم أو الاعتماد على مزودي خدمة عقدة الأرشيف مثل Alchemy أو Infura للوصول إلى جميع البيانات منذ كتلة Genesis. وهي توفر جميع البيانات نفسها مثل العقدة الكاملة ولكن أيضًا جميع بيانات الحالة التاريخية لسلسلة البلوكشين بأكملها. تستخدم الخدمات خارج السلسلة مثل Etherscan و Dune Analytics عقد الأرشيف للوصول إلى البيانات على السلسلة. يمكن للجهات الفاعلة خارج السلسلة أن تشهد على صحة هذه البيانات، ويمكن للعقود الذكية داخل السلسلة التحقق من توقيع البيانات من قبل ممثل/لجنة موثوقة. لم يتم التحقق من سلامة البيانات الأساسية. يتطلب هذا الأسلوب من dapp أن يثق في أن مزود خدمة عقدة الأرشيف يقوم بتشغيل البنية التحتية بشكل صحيح وبدون أي نية ضارة.

ثق بالأمن الاقتصادي لشركة Crypto:

• المفهرسات: ينظم بروتوكول الفهرسة جميع البيانات الموجودة على بلوكتشين، مما يسمح للمطورين بإنشاء ونشر واجهات برمجة تطبيقات مفتوحة يمكن للتطبيقات الاستعلام عنها. المفهرسون الفرديون هم مشغلو العقد الذين يقومون بتخزين الرموز لتوفير خدمات الفهرسة ومعالجة الاستعلام. ومع ذلك، يمكن أن تحدث النزاعات عندما تكون البيانات المقدمة غير صحيحة ويمكن أن تستغرق عملية التحكيم بعض الوقت. علاوة على ذلك، لا يمكن استخدام البيانات من المفهرسين مثل The Graph بشكل مباشر من خلال منطق الأعمال الخاص بالعقود الذكية ويتم استخدامها في سياق تحليل البيانات المستند إلى web2.
• Oracles: يستخدم موفرو خدمة Oracle البيانات المجمعة من العديد من مشغلي العقد المستقلين. التحدي هنا هو أن البيانات المتاحة من Oracles قد لا يتم تحديثها بشكل متكرر وهي محدودة النطاق. عادةً ما تحافظ Oracles مثل Chainlink على حالات محددة فقط، مثل خلاصات الأسعار والحالات الخاصة بالتطبيق والتاريخ فهي غير مجدية. علاوة على ذلك، يقدم هذا النهج أيضًا مستوى معينًا من الانحراف في البيانات ويتطلب الثقة في مشغلي العقدة.

رمز الثقة:

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

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

تخزين البيانات في بلوكشين

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

لنأخذ كتلة إيثريوم كمثال. تستفيد إيثريوم من نوع معين من شجرة ميركل المعروفة باسم «شجرة ميركل باتريشيا» (MPT). تحتوي رؤوس كتل Ethereum على جذور أربع محاولات مختلفة من Merkle-Patricia، أي تجربة الدولة، تجربة التخزين، تجربة الإيصالات، تجربة المعاملة. تقوم هذه المحاولات الأربع بترميز التعيينات التي تشتمل على جميع بيانات إيثريوم. يتم استخدام أشجار Merkle نظرًا لكفاءتها في تخزين البيانات. باستخدام تجزئات متكررة، يجب تخزين التجزئة الجذرية فقط في النهاية، مما يوفر الكثير من المساحة. إنها تسمح لأي شخص بإثبات وجود عنصر في الشجرة من خلال إثبات أن تجزئة العقد بشكل متكرر تؤدي إلى نفس تجزئة الجذر. تسمح براهين Merkle للعملاء الخفيفين على Ethereum بالحصول على إجابات لأسئلة مثل:

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

بدلاً من تنزيل كل معاملة وكل كتلة، يمكن لـ «العميل الخفيف» فقط تنزيل سلسلة رؤوس الكتل والتحقق من المعلومات باستخدام Merkle Proofs. هذا يجعل العملية الشاملة عالية الكفاءة. ارجع إلى هذه المدونة التي كتبها مقال بحثي من Vitalik و Maven11 لفهم التنفيذ والمزايا والتحديات المرتبطة بـ Merkle Trees بشكل أفضل.

براهين التخزين

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

ما الذي يمكن أن تتيحه براهين التخزين؟

تسمح براهين التخزين بوظائفين رئيسيين:

1. يمكنك الوصول إلى البيانات التاريخية على السلسلة التي تتجاوز آخر 256 كتلة، وصولًا إلى كتلة التكوين
2. يمكنك الوصول إلى البيانات الموجودة على السلسلة (التاريخية والحالية) لسلسلة بلوكشين واحدة على بلوكشين آخر بمساعدة التحقق الإجماعي أو جسر L1-L2 في حالة L2s

كيف تعمل براهين التخزين؟

تقوم أدلة التخزين على مستوى عالٍ جدًا بالتحقق مما إذا كانت الكتلة المحددة جزءًا من التاريخ الكنسي لـ blockchain ثم التحقق مما إذا كانت البيانات المحددة المطلوبة جزءًا من الكتلة. يمكن تحقيق ذلك من خلال:

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

1. الوصول إلى البيانات على نفس السلسلة: يمكن استخدام دليل ZK للتأكيد على أن رأس الكتلة التاريخية التعسفي هو سلف أحد أحدث 256 رأسًا من رؤوس الكتل التي يمكن الوصول إليها داخل بيئة التنفيذ. الطريقة الأخرى هي فهرسة التاريخ الكامل لسلسلة المصدر وإنشاء دليل ZK على ذلك لإثبات أن الفهرسة حدثت بشكل صحيح. يتم تحديث هذا الدليل بانتظام عند إضافة كتل جديدة إلى سلسلة المصدر. الوصول إلى البيانات عبر السلاسل: يقوم الموفر بجمع رؤوس الكتل للسلسلة المصدر في سلسلة الوجهة ويشهد على صحة رؤوس الكتل هذه باستخدام دليل إجماع ZK. من الممكن أيضًا استخدام حل AMP موجود مثل Axelar أو Celer أو LayerZero للاستعلام عن رؤوس الكتل.
2. يتم الاحتفاظ بذاكرة التخزين المؤقت لتجزئات رؤوس الكتل للسلسلة المصدر، أو التجزئة الجذرية لمجمع تجزئة الكتلة خارج السلسلة، في سلسلة الوجهة. يتم تحديث ذاكرة التخزين المؤقت هذه على أساس منتظم ويتم استخدامها لإثبات وجود كتلة معينة بكفاءة على السلسلة ولديها ارتباط مشفر بتجزئة كتلة حديثة يمكن الوصول إليها من الولاية. تُعرف هذه العملية بإثبات استمرارية السلسلة. من الممكن أيضًا استخدام بلوكشين مخصص لتخزين رؤوس الكتل لجميع سلاسل المصدر.
3. يتم الوصول إلى البيانات/الكتلة التاريخية من البيانات المفهرسة خارج السلسلة أو ذاكرة التخزين المؤقت على السلسلة (اعتمادًا على مدى تعقيد الطلب) وفقًا لطلب dapp في سلسلة الوجهة. بينما يتم الاحتفاظ بذاكرة التخزين المؤقت لتجزئة رؤوس الكتل على السلسلة، فقد يتم تخزين البيانات الفعلية خارج السلسلة.
4. يتم التحقق من وجود البيانات في الكتلة المحددة من خلال براهين تضمين merkle ويتم إنشاء إثبات zk لها. يتم دمج هذا الدليل مع إثبات zk للفهرسة الصحيحة أو إثبات إجماع ZK ويتم توفير الدليل على السلسلة للتحقق غير الموثوق به.
5. يمكن لـ dapps بعد ذلك التحقق من هذا الإثبات على السلسلة واستخدام البيانات لتنفيذ الإجراء المطلوب. إلى جانب التحقق من إثبات ZK، يتم فحص المعلمات العامة مثل رقم الكتلة وتجزئة الكتلة مقابل ذاكرة التخزين المؤقت لرؤوس الكتل التي يتم الاحتفاظ بها على السلسلة.

بعض المشاريع التي تتبنى هذا النهج هي هيرودوت ولاغرانج وأكسيوم وهايبر أوراكل وشبكة بريفيس ومؤسسة نيل. وفي حين تُبذل جهود كبيرة لجعل التطبيقات على دراية بالحالة عبر سلاسل بلوكتشين المتعددة، تبرز IBC (الاتصالات عبر بلوكتشين) كمعيار للتشغيل البيني يمكّن تطبيقات مثل ICQ (استعلامات Interchain) و ICA (حسابات Interchain). يمكّن ICQ التطبيقات على السلسلة A من الاستعلام عن حالة السلسلة B من خلال تضمين الاستعلام في حزمة IBC بسيطة ويسمح ICA لبلوكشين واحد بالتحكم الآمن في حساب على بلوكشين آخر. يمكن أن يؤدي الجمع بينهما إلى تمكين حالات استخدام مثيرة للاهتمام عبر السلاسل. يقدم موفرو RaaS مثل Saga هذه الوظائف لجميع سلاسل التطبيقات الخاصة بهم افتراضيًا باستخدام IBC.

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

• الوصول إلى البيانات
• معالجة البيانات
• إنشاء ZK Proof للوصول إلى البيانات ومعالجتها

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

• بلوكشين إيثريوم الحالي: يمكن استخدام البنية الحالية لبلوكتشين لإيثيريوم لإثبات قيمة أي فتحة تخزين تاريخية فيما يتعلق برأس الكتلة الحالي باستخدام ZKP. يمكن اعتبار هذا كدليل كبير على التضمين. إنه دليل على أنه، بالنظر إلى رأس الكتلة الأخير X عند الارتفاع b، يوجد blockheader Y وهو سلف X عند ارتفاع b-k. وهو يعتمد على أمان إجماع Ethereum ويتطلب نظامًا سريعًا للكفاءة. هذا هو النهج الذي تستخدمه Lagrange.
• ذاكرة التخزين المؤقت لسلسلة سلاسل جبال Merkle (MMR): يمكن عرض سلسلة جبال Merkle كقائمة بأشجار Merkle حيث يتم دمج أشجار Merkle الفردية عندما تصل شجرتان إلى نفس الحجم. يتم دمج أشجار Merkle الفردية في MMR عن طريق إضافة العقد الأم إلى الجذور السابقة للأشجار. MMR عبارة عن بنية بيانات مشابهة لأشجار Merkle مع بعض الفوائد الإضافية، مثل الإلحاق الفعال للعناصر واستعلامات البيانات الفعالة، خاصة عند قراءة البيانات المتسلسلة من مجموعات البيانات الكبيرة. يتطلب إلحاق رؤوس جديدة عبر شجرة Merkle تمرير جميع العقد الشقيقة في كل مستوى. من أجل إلحاق البيانات بكفاءة، تستخدم Axiom MMR للحفاظ على ذاكرة التخزين المؤقت لتجزئة رؤوس الكتل على السلسلة. يقوم Herodotus بتخزين التجزئة الجذرية لمجمع تجزئة كتلة MMR على السلسلة. يتيح لهم ذلك التحقق من البيانات التي تم جلبها مقابل تجزئات رأس الكتلة هذه عبر براهين التضمين. يتطلب هذا النهج تحديث ذاكرة التخزين المؤقت على أساس منتظم ويثير مخاوف تتعلق بالحياة إن لم يكن لامركزيًا.
• يحتفظ هيرودوت بنوعين مختلفين من MMR. واعتمادًا على البلوكشين أو الطبقة المحددة، يمكن تصميم المجمعات لاستخدام وظائف التجزئة المختلفة، وتحسين الكفاءة والتكاليف الحسابية. للإثبات على Starknet، يمكن استخدام هاش poseidon ولكن يمكن استخدام تجزئة Keccack لسلاسل EVM.
• ذاكرة التخزين المؤقت لـ MMR خارج السلسلة: يحتفظ Herodotus بذاكرة تخزين مؤقت خارج السلسلة للاستعلامات والنتائج التي تم جلبها مسبقًا للسماح بجلب البيانات بشكل أسرع في حالة طلب البيانات مرة أخرى. يتطلب هذا بنية أساسية إضافية بدلاً من مجرد تشغيل عقدة أرشيف. يمكن أن تؤدي التحسينات التي تم إجراؤها على البنية التحتية خارج السلسلة إلى خفض التكاليف للمستخدم النهائي.
• بلوكشين مخصص للتخزين: تعتمد Brevis على مجموعة ZK المخصصة (طبقة التجميع) لتخزين جميع رؤوس الكتل لجميع السلاسل التي تشهد عليها. وبدون طبقة التجميع هذه، ستحتاج كل سلسلة إلى تخزين رؤوس الكتل لكل سلسلة أخرى، مما يؤدي إلى «اتصالات» O (N2) لـ N blockchains. ومن خلال تقديم طبقة تجميع، تحتاج كل سلسلة بلوكشين فقط إلى تخزين جذر الحالة للمجموعة، مما يقلل الاتصالات الإجمالية إلى O (N). تُستخدم هذه الطبقة أيضًا لتجميع براهين متعددة لرؤوس الكتلة/نتائج الاستعلام ويمكن تقديم إثبات واحد للتحقق على كل بلوكشين متصل.
• تمرير رسالة L1-L2: يمكن تجنب التحقق من إجماع سلسلة المصدر في حالة L2s لأن L2s تدعم الرسائل الأصلية لتحديث عقود L2 على L1. يمكن تحديث ذاكرة التخزين المؤقت على إيثريوم ويمكن استخدام تمرير رسالة L1-L2 لإرسال تجزئة الكتلة أو جذر الشجرة التي تم تجميعها خارج السلسلة إلى L2s أخرى. يتبنى هيرودوت هذا النهج ولكن هذا غير ممكن بالنسبة لـ alt L1s.

معالجة البيانات:

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

يسمح Hyper Oracle، على سبيل المثال، للمطورين بتحديد الحسابات المخصصة خارج السلسلة باستخدام JavaScript. صممت Brevis سوقًا مفتوحًا لمحركات ZK Query التي تقبل استعلامات البيانات من dApps وتعالجها باستخدام رؤوس الكتل المعتمدة. يرسل العقد الذكي استعلامًا عن البيانات، يتم التقاطه بواسطة مُثبت من السوق. يقوم Prover بإنشاء إثبات استنادًا إلى إدخال الاستعلام ورؤوس الكتل ذات الصلة (من طبقة تجميع Brevis) والنتائج. قدمت لاغرانج ZK Big Data Stack لإثبات نماذج البرمجة الموزعة مثل SQL و MapReduce و Spark/RDD. تُعد البراهين معيارية ويمكن إنشاؤها من أي رأس كتلة ينشأ من الجسور عبر السلاسل الحالية وبروتوكولات AMP. ZK MapReduce، المنتج الأول في مكدس Lagrange ZK BigData، هو محرك حساب موزع (يعتمد على نموذج برمجة MapReduce المعروف) لإثبات نتائج الحساب التي تتضمن مجموعات كبيرة من البيانات متعددة السلاسل. على سبيل المثال، يمكن استخدام دليل ZKMR واحد لإثبات التغييرات في سيولة DEX المنشورة على 4-5 سلاسل خلال نافذة زمنية محددة. بالنسبة للاستعلامات البسيطة نسبيًا، يمكن أيضًا إجراء الحساب مباشرة على السلسلة كما يقوم به هيرودوت في الوقت الحالي.

جيل الإثبات:

• البراهين القابلة للتحديث: يمكن استخدام البراهين القابلة للتحديث عند الحاجة إلى حساب الإثبات وصيانته بكفاءة عبر تيار متحرك من الكتل. عندما يرغب dapp في الاحتفاظ بإثبات المتوسط المتحرك لمتغير العقد (مثل سعر الرمز المميز)، حيث يتم إنشاء كتل جديدة، دون إعادة حساب الإثبات الجديد من البداية، يمكن تحديث البراهين الحالية بكفاءة. لإثبات الحساب الديناميكي المتوازي للبيانات في حالة على السلسلة، يقوم Lagrange ببناء التزام متجه دفعي، يسمى Recproof، فوق جزء من MPT، ويقوم بتحديثه سريعًا، ويقوم بحسبه ديناميكيًا فوقه. من خلال إنشاء شجرة Verkle بشكل متكرر فوق MPT، يمكن لـ Lagrange حساب كميات كبيرة من بيانات الحالة الديناميكية على السلسلة بكفاءة.
• أشجار Verkle: على عكس أشجار Merkle، حيث نحتاج إلى توفير جميع العقد التي تشترك في أحد الوالدين، تتطلب Verkle Trees فقط المسار إلى الجذر. هذا المسار أصغر بكثير مقارنة بجميع العقد الشقيقة في حالة شجرة Merkle. تستكشف إيثريوم أيضًا استخدام أشجار Verkle في الإصدارات المستقبلية لتقليل مقدار الحالة التي يجب أن تحتفظ بها العقد الكاملة لإيثيريوم. تستفيد Brevis من Verkle Tree لتخزين رؤوس الكتل المصدقة ونتائج الاستعلام في طبقة التجميع. إنه يقلل بشكل كبير من حجم إثبات تضمين البيانات، خاصة عندما تحتوي الشجرة على عدد كبير من العناصر، كما يدعم إثبات التضمين الفعال لمجموعة من البيانات.
• مراقبة Mempool لتوليد إثبات أسرع: أعلن Herodotus مؤخرًا عن turbo، والذي يسمح للمطورين بإضافة بضعة أسطر من التعليمات البرمجية إلى رمز العقد الذكي الخاص بهم لتحديد استعلام البيانات. يقوم Herodotus بمراقبة mempool لمعاملات العقود الذكية التي تتفاعل مع العقد التوربيني. تبدأ عملية إنشاء الإثبات عندما تكون المعاملة في mempool نفسه. بمجرد إنشاء الدليل والتحقق منه على السلسلة، تتم كتابة النتائج في عقد المبادلة التوربينية على السلسلة. لا يمكن كتابة النتائج إلا في عقد المبادلة التوربينية بمجرد مصادقتها بواسطة براهين التخزين. بمجرد حدوث ذلك، تتم مشاركة جزء من رسوم المعاملات مع المُسلسل أو مُنشئ الكتل، مما يحفزهم على الانتظار لفترة أطول قليلاً لتحصيل الرسوم. بالنسبة لاستعلامات البيانات البسيطة، من الممكن أن تكون البيانات المطلوبة متاحة على السلسلة قبل تضمين المعاملة من المستخدم في الكتلة.

تطبيق براهين الحالة/التخزين

يمكن لبراهين الحالة والتخزين فتح العديد من حالات الاستخدام الجديدة للعقود الذكية في طبقة التطبيقات والبرامج الوسيطة والبنية التحتية. بعض هذه هي:

طبقة التطبيق:

الحوكمة:

• التصويت عبر السلاسل: يمكن أن يسمح بروتوكول التصويت على السلسلة للمستخدمين في السلسلة B بإثبات ملكية الأصول على السلسلة A. لن يضطر المستخدمون إلى ربط أصولهم للحصول على قوة التصويت على سلسلة جديدة. مثال: SnapshotX على هيرودوت
• توزيع رموز الحوكمة: يمكن للتطبيقات توزيع المزيد من رموز الحوكمة على المستخدمين النشطين أو المستخدمين الأوائل. مثال: RetroPGF على لاغرانج

الهوية والسمعة:

• إثبات الملكية: يمكن للمستخدم تقديم إثبات ملكية بعض NFT أو SBT أو الأصول في السلسلة A، مما يمكّنه من تنفيذ إجراءات معينة على السلسلة B. على سبيل المثال، قد تقرر سلسلة تطبيقات الألعاب إطلاق مجموعة NFT الخاصة بها على سلسلة أخرى مع السيولة الحالية مثل Ethereum أو أي L2. سيسمح هذا للعبة بالاستفادة من السيولة الموجودة في مكان آخر وسد أداة NFT دون الحاجة فعليًا إلى سد NFT.
• إثبات الاستخدام: يمكن منح المستخدمين خصومات أو ميزات متميزة بناءً على استخدامهم التاريخي للمنصة (إثبات أن حجم X المتداول من قبل المستخدم على Uniswap)
• إثبات OG: يمكن للمستخدم إثبات أنه يمتلك حسابًا نشطًا عمره أكثر من X يومًا
• درجة الائتمان على السلسلة: يمكن لمنصة درجات الائتمان متعددة السلاسل تجميع البيانات من حسابات متعددة لمستخدم واحد لإنشاء درجة ائتمان

يمكن استخدام جميع البراهين المذكورة أعلاه لتوفير تجربة مخصصة للمستخدمين. يمكن أن تقدم Dapps خصومات أو امتيازات للاحتفاظ بالمتداولين أو المستخدمين ذوي الخبرة وتقديم تجربة مستخدم مبسطة للمستخدمين المبتدئين.

ديفي:

• الإقراض عبر السلاسل: يمكن للمستخدمين الاحتفاظ بالأصول على السلسلة A والحصول على قرض من السلسلة B بدلاً من سد الرموز
• التأمين على السلسلة: يمكن تحديد حالات الفشل من خلال الوصول إلى البيانات التاريخية على السلسلة ويمكن تسوية التأمين بالكامل على السلسلة.
• TWAP لسعر الأصل في المجمع: يمكن للتطبيق حساب وجلب متوسط سعر الأصل في تجمع AMM خلال فترة زمنية محددة. مثال: Uniswap TWAP أوراكلمع اكسيوم
• تسعير الخيارات: قد يقوم بروتوكول الخيارات أحادي السلسلة بتسعير خيار باستخدام تقلب أحد الأصول على مدى الكتل n الماضية في بورصة لامركزية.

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

البرامج الوسيطة:

• النوايا: ستسمح براهين التخزين للمستخدمين بأن يكونوا أكثر وضوحًا ووضوحًا في نواياهم. في حين أن مهمة الحل هي تنفيذ الخطوات اللازمة لتحقيق نية المستخدم، يمكن للمستخدم تحديد الشروط بشكل أكثر وضوحًا بناءً على البيانات والمعايير على السلسلة. يمكن للحلول أيضًا إثبات صحة البيانات على السلسلة التي يتم الاستفادة منها للعثور على الحل الأمثل.
• تجريد الحساب: يمكن للمستخدمين الاعتماد على البيانات الواردة من سلاسل أخرى باستخدام براهين التخزين لوضع القواعد عبر تجريد الحساب. مثال: كل محفظة لها اسم. يمكننا أن نثبت أنه قبل عام واحد، كان الاسم رقمًا معينًا، وحاليًا الرقم هو نفسه. يمكن استخدام هذا لإثبات أن هذه المحفظة لم يتم استخدامها على الإطلاق ويمكن بعد ذلك تفويض الوصول إلى المحفظة إلى محفظة أخرى.
• التشغيل الآلي على السلسلة: يمكن للعقود الذكية أتمتة إجراءات معينة بناءً على شروط محددة مسبقًا تعتمد على البيانات داخل السلسلة. يُطلب من البرامج الآلية استدعاء العقود الذكية على فترات زمنية معينة للحفاظ على تدفق الأسعار الأمثل لـ AMM أو للحفاظ على بروتوكولات الإقراض صحية من خلال تجنب الديون المعدومة. يتيح Hyper Oracle التشغيل الآلي إلى جانب الوصول إلى البيانات على السلسلة.

البنية التحتية

• Oracle غير الموثوق به على السلسلة: تقوم شبكات أوراكل اللامركزية بتجميع الاستجابات من العديد من عُقد أوراكل الفردية داخل شبكة أوراكل. يمكن لـ Oracle Networks التخلص من هذا التكرار والاستفادة من أمان التشفير للبيانات على السلسلة. يمكن لشبكة Oracle استيعاب البيانات من سلاسل متعددة (L1s و L2s و alt L1s) في سلسلة واحدة وإثبات وجودها ببساطة باستخدام براهين التخزين في مكان آخر. يمكن أن تعمل حلول DeFi ذات الجاذبية الكبيرة على حل مخصص أيضًا. على سبيل المثال، تعاونت Lido Finance، أكبر مزود لحصص السيولة، مع مؤسسة Nil Foundation لتمويل تطوير ZkoRacle. ستتيح الحلول الوصول غير الموثوق للبيانات إلى البيانات التاريخية داخل EVM وتأمين 15 مليار دولار من سيولة Lido Finance المخزنة على Ethereum.
• بروتوكولات AMP: يمكن أن تزيد حلول AMP الحالية من التعبير عن رسائلها من خلال الشراكة مع موفري خدمة إثبات التخزين. هذا هو النهج الذي اقترحه Lagrange في مقالة الأطروحة المعيارية.

الاستنتاج

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

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

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