يصف المؤسس شخصيًا حلول ورؤية Avail "Trinity".

المؤلف: Anurag Arjun، المؤسس المشارك لـ Polygon ومؤسس Avail؛ الترجمة: xiaozou@金财经

في 26 فبراير 2024، أعلنت Avail أنها تلقت جولة تمويل أولية بقيمة 27 مليون دولار أمريكي بقيادة Founders Fund وDragonfly Financing وشاركت أيضًا شركات رأس المال الاستثماري المعروفة الأخرى، بما في ذلك SevenX وFigment وNomad Capital وعدد من المستثمرين الملائكيين. سيتم استخدام هذه الجولة من التمويل لدعم تطوير Avail Trinity - وهي خارطة طريق من ثلاث مراحل توحد النظام البيئي web3 بأكمله.  

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

p>

1. نظرة عامة

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

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

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

في هذه المقالة، سنتعمق في خلفية ونظرية Avail Trinity ونوضح كيف يحل مشكلات تجزئة المستخدم وقابلية التوسع التي يواجهها النظام البيئي الحالي. سنوضح كيف أن Avail DA هو الأساس المثالي للعديد من عمليات التجميع التي تتوق إلى توفر بيانات فعال، وتضع الأساس للتنفيذ السلس لنية المستخدم عبر النظام البيئي web3 من خلال Avail Nexus، وهو مركز تنسيق غير مصرح به. يكمل Avail Fusion Security برنامج Avail Trinity، مما يحل الحاجة المتزايدة للأمن المشترك ويجعل النظام البيئي الموحد web3 المزدهر أقوى.

2. المقدمة

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

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

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

● نظرًا لمحدودية التوفر، يؤدي الطلب على المزيد من مساحة الكتلة إلى ارتفاع التكاليف .

● أدى انتشار النظم البيئية للغة الثانية إلى تفاقم تجزئة السوق، مما زاد من إعاقة تجربة المستخدم ووفورات الحجم.

مع حل هذه المشكلات، يمكن أخيرًا تحقيق إمكانية التوسع وقابلية التشغيل البيني لأنظمة blockchain، والتي كانت راكدة لسنوات.

3. الحل المتاح

الحل المتاح هو الاستفادة من مبدأ المراسلة غير المتزامنة (على غرار ( باستخدام نفس مبادئ توسيع نطاق التطبيقات) لتوسيع نطاق blockchain، والآن هو الوقت المثالي للبناء.

يتكون Avail Trinity من طبقة توفر البيانات الأساسية (DA) وطبقة إمكانية التشغيل البيني Nexus وطبقة شبكة Fusion Security.

● تم تصميم طبقة DA خصيصًا لتوفير البيانات وهي محسنة للغاية. إنها الطبقة الأدنى في blockchain وتتمتع بالإمكانيات اللازمة لبناء البيانات المتقاطعة -قابلية التشغيل البيني للنظام البيئي.الحد الأدنى من الوظائف.

● Nexus، باعتباره مجموعة ZK خفيفة الوزن ولكنها قوية تعمل على Avail، يدعم التجميع المتقاطع والتسوية عبر الأنظمة البيئية.

● يمكن أن يجمع Fusion Security أمان الاقتصاد المشفر للعديد من الرموز المميزة لخدمة شبكة Avail وحمايتها.

تتمثل مهمة Avail في تبسيط تجربة التجميع وتوفير نظام أساسي موحد فعال للمستخدمين والمطورين عبر جميع الأنظمة البيئية المختلفة.

تم تصميم نموذج التكامل الرأسي هذا لحل المشاكل المتزايدة اليوم ومشاكل تجزئة المستخدم، مما يسمح للتجميع بلمس مجال blockchain بأكمله بسلاسة. المستخدمون والسيولة.

تتمثل رؤية Avail في توفير تجربة مستخدم متسقة في نظام بيئي معياري مرن لـ blockchain، بالاعتماد على تجربة Web2 للابتكار في Web3. من خلال الجمع بين التكنولوجيا المتقدمة وخريطة طريق واضحة والتنفيذ السريع، تقوم Avail ببناء أكثر من مجرد منتج، فهي تبشر بمرحلة جديدة في مجال blockchain، مما يمهد الطريق لعصر من قابلية التوسع الأفضل والتفاعل السلس للمستخدم.

4. الخلفية والإلهام

ما الذي يمكننا تعلمه من web2؟

كيف تحقق التطبيقات الموجودة على الإنترنت نطاقًا واسعًا حقًا؟ الخدمات المصغرة غير المتزامنة

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

أمازون عبارة عن مجموعة من الخدمات الصغيرة ذات الصلة والمتخصصة في التجارة الإلكترونية. تدير Visa سلسلة من الخدمات الصغيرة التي تعالج المدفوعات.

● عندما ينقر المستخدم على زر شراء منتج على أمازون، يتم تشغيل اتصال من المتصفح إلى الخدمة المصغرة لمنتج أمازون.

● بعد ذلك سيتم استدعاء خدمة Visa الصغيرة لإرسال صفحة الدفع إلى المستخدم.

● بمجرد قيام المستخدم بملء تفاصيل الدفع، يتم إرسال طلب دفع آخر للتحقق إلى خدمة Visa الصغيرة.

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

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

النقطة المهمة هي أن الإنترنت لا يمكن توسيع نطاقه إلى هذا النطاق الكبير إلا من خلال الخدمات الصغيرة غير المتزامنة. وكذلك الحال بالنسبة لتقنية blockchain.

كيف نحقق ذلك في web3؟

تُعد UPI مثالًا جيدًا للتعلم. إنه أحد أكبر أنظمة الدفع في العالم من حيث حجم المستخدمين وحجم المعاملات. حاليًا، تقوم UPI بمعالجة أكثر من 10 مليار معاملة كل شهر، وهو ما يعد دليلاً على الحجم الهائل للنظام.

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

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

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

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

مثل هذا التعاون مفيد للنظام البيئي. لكن هذا لن يكون ممكنا إلا إذا كانت التكنولوجيا الأساسية تستخدم البدائيات الصحيحة لتمكين التعاون. تمتلك UPI هذه الميزات، وقد قمنا بتصميم Avail لجلب تجربة أنظمة web2 حول العالم إلى web3.

جلب تجربة web2 إلى web3

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

● تعد المنصات مثل Amazon وVisa أمثلة على هذا النموذج، والتي توفر سلسلة من الخدمات الصغيرة المتخصصة للتجارة الإلكترونية ومعالجة الدفع على التوالي.

● يتم توسيع نطاق هذه الخدمات بشكل مستقل لتلبية الطلب، مما يوضح قوة العمليات اللامركزية غير المتزامنة.

● إن نجاح أنظمة مثل UPI (واجهة المدفوعات الموحدة) يسلط الضوء بشكل أكبر على أهمية المعاملة بالمثل المترابطة في توسيع نطاق الأنظمة الكبيرة والمعقدة.

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

الحالة الحالية للنظام البيئي المعياري

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

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

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

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

p>

طبقة DA تعتمد على إثبات الصلاحية كأساس

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

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

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

إن DAS المدعوم بإثبات الصلاحية هو القوة العظمى لـ AvailDA، وهو نقطة الارتكاز التي نبني عليها AvailTrinity.

Avail Trinity

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

● طبقة توفر البيانات الأساسية (DA)

هذه الطبقة عبارة عن طبقة أساسية عالمية يمكن لأي blockchain الاستفادة منها لتعزيز قابلية التوسع والأمان. يتميز تصميم Avail DA البسيط والقوي بالمرونة ويتكيف مع احتياجات كل سلسلة دون فرض قيود أو تحيزات محددة.

● طبقة Nexus لقابلية التشغيل التفاعلي

طبقة Nexus هي تنسيق Avail المكون، الذي يوفر إطارًا غير مسموح به للرسائل الداخلية المجمعة.

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

● طبقة أمان Fusion

يسمح Fusion لسلسلة Avail الأساسية بدمج غير- يتم دمج الرموز المميزة الأصلية مع رموز Avail الأصلية لتأمين نظام Avail الأساسي، مما يتيح طبقة أمان قوية وموثوقة.

سيوفر Fusion Security أمانًا أعلى ومزيدًا من الأدوات المساعدة للرموز المجمعة المبنية على Avail.

سيساعد Fusion أيضًا على جلب المزيد من السيولة من سلاسل الكتل الأخرى إلى النظام البيئي Avail وإغلاقه بعيدًا.

5. الاستفادة من DA

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

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

(1) مبدأ عمل طبقة DA المتاحة

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

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

p>

● يتم التحقق من البيانات المنشورة على كتلة Avail بواسطة شبكة Avail ولكن لا يتم تنفيذها (لأن هذه هي مهمة طبقة التنفيذ).

● يمكن أن يدعم blockchain الخاص بتوفر البيانات في Avail أي شبكة blockchain.

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

● يتم توسيع البيانات المنشورة إلى Avail من خلال ترميز المحو، وبالتالي زيادة تكرار البيانات.

● يستخدم Avail التزام KZG متعدد الحدود للتأكد من أن البيانات تترك آثارًا في رأس كتلة Avail.

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

● تم إنشاء blockchain لإثبات الملكية (NPoS) من Avail باستخدام Polkadot SDK وسيدعم ما يصل إلى 1000 من أدوات التحقق الخارجية.

(2) أخذ عينات توفر البيانات (DAS)

يعد DAS مفهومًا أساسيًا. للتحقق بشكل فعال من البيانات المتاحة للشبكات والمحافظ والمستخدمين الآخرين على Avail blockchain.

باستخدام Avail's LightClient، يمكن للمستخدمين أخذ عينات سريعة من Avail blockchain للتحقق من أدلة الصلاحية التي تثبت توفر البيانات. ويمكن نشر هذه التعليمات البرمجية الفعالة والنظيفة بسهولة عبر منتجات وأجهزة مختلفة، بما في ذلك هواتف المستخدمين ومتصفحاتهم.

p>

8. قابلية التوسع

يدعم Avail قابلية التوسع من خلال عميل Avail Light وكتل أخذ عينات توفر البيانات، والتي يمكن أن تزيد من حجم الكتلة وتدعم المزيد من الكتل مع نمو الطلب.

يرجع ذلك إلى الخصائص الفريدة للعملاء الخفيفين وDAS.

يمكن لعميل Avail light أخذ عينات من مجموعة فرعية من البيانات من الشبكة والتحقق من توفر تلك البيانات. يمكن للعميل الخفيف إنشاء ما يقرب من 100% من ضمان توفر البيانات بسرعة من خلال 8 إلى 30 عينة، مما يوفر حماية أمنية تعادل حماية العقدة الكاملة. عند النسخ المتماثل عبر شبكة عميل خفيفة، تبدأ شبكة العميل الخفيفة نفسها في تكوين نسخة من الحالة الحالية للسلسلة، مما يضيف التكرار إلى الشبكة بأكملها. في النهاية، سيكون لديك نسخة من شبكة Avail مع أدوات التحقق من الصحة وشبكات العملاء الخفيفة.

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

9. الحفاظ على الترتيب

يعد الحفاظ على ترتيب المعاملات مطلبًا أساسيًا لبناء نظام blockchain . مع كل كتلة Avail جديدة، سيكون هناك ترتيب جديد للمعاملات على blockchain.

على الرغم من أن مسؤولية الحفاظ على ترتيب البيانات المنشورة تقع على عاتق مجموعة أدوات التحقق من Avail DA، إلا أن مسؤولية التحقق يتم الاستعانة بمصادر خارجية للمستخدم. من أجل تحديد صحة السلسلة، يجب على المستخدم:

● التحقق من توفر البيانات: وذلك للتحقق من توفر البيانات وفقًا للترتيب المحدد . يمكن للمستخدمين تحقيق ذلك عن طريق إجراء أخذ عينات توفر البيانات (DAS) بناءً على ترتيب تحدده مجموعة أدوات التحقق من التوفر. يحقق Avail نهائية تبلغ حوالي 60 ثانية باستخدام إثباتات الصلاحية في Avail's DA، والذي يمكن القول إنه أسرع ضمان نهائي متاح مع طبقة DA اليوم.

● التنفيذ الذي تم التحقق منه: يتم تحقيق ذلك من خلال التحقق من إثبات التنفيذ الخاص بالمجموعة المجمعة.

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

6. توفر Nexus

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

Avail Nexus عبارة عن مجموعة تجميعية مخصصة لتنسيق ZK استنادًا إلى Avail، بما في ذلك:

●  طبقة تجميع الأدلة والتحقق

● آلية مزاد الفرز/الفتحة

Nexus كما يقدم بانتظام البراهين المجمعة إلى طبقات Ethereum وAvail DA للتحقق منها. يتم التحقق من البراهين المجمعة بواسطة وحدة مخصصة في AvailDA.

الخلفية

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

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

● كيفية إجراء التحقق من الحالة دون أن تصبح عنق الزجاجة؟

● كيف يفهم التجميعي الرسائل أو الأحداث الموجودة في المجموعات الأخرى في النظام البيئي؟ هل يمكن تنفيذ تسليم الرسائل بشكل غير متزامن؟

● Rollup كيف يعرف "أ" الترتيب المتعارف عليه لمجموعة التحديثات B؟

● هل تتغير افتراضات الأمان بين مجموعات مختلفة؟

● كم عدد الجسور المتقاطعة المطلوبة، حتى لو كانت عالمية؟

يهدف Avail Nexus إلى حل هذه المشكلات على نطاق واسع.

التصميم

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

1. ما هي مواصفات السلسلة وترتيبها النهائي؟

2. هل التنفيذ فعال؟

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

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

دعونا نتخيل موقفًا حيث يريد NFT Rollup تأكيد الدفع على  Rollup  يكون الاتصال المتقاطع تقريبًا كما يلي:

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

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

p>

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

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

إثبات التجميع

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

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

p>

قد تتغير تفاصيل التنفيذ، ولكن يمكن تحقيق ذلك عن طريق التحقق من الدليل داخل مثيل Zeth أو استخدام أداة تجميع أدلة أكثر استهدافًا مثل الأدوات التي أنشأتها Nebra) لإجراء التجميع.

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

بالعودة إلى مثال NFT والدفع، يبدو التنفيذ الحالي هكذا.

p>

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

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

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

التحقق من الأمر والتنفيذ

 rollups  على Ethereum اليوم يفترض استخدام Ethereum كـ تكلفة DA. عندما ترتفع رسوم الغاز، فإنهم يدفعون حوالي 1300-1600 دولار أمريكي/ميجابايت أو أكثر. ونتيجة لذلك، نرى العديد من السلاسل تتطلع إلى استخدام Avail كطبقة DA في سلسلتها. يمكن أن يؤدي ذلك إلى تقليل تكاليف التشغيل بنسبة  70-90% اعتمادًا على خيارات البناء وحجم الدفعة. ما زالوا ينشرون البراهين على Ethereum ويستخدمونها كطبقة تسوية. في الواقع، يستخدمون Ethereum فقط كجسر أساسي لهم.

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

سيتم التحقق من المشاركة في Avail Nexus Rollup من خلال Avail Rollup واعتماده. ستصل البراهين التي تم التحقق منها إلى Ethereum عبر Vector Bridge، وهو جسر إثبات إجماعي قائم على ZKP من Avail إلى Ethereum. لا يزال Ethereum قادرًا على التحقق من أدلة التنفيذ المجمعة ولا يتعين عليه الاعتماد على أدوات التحقق من Avail، وهو نفس افتراض Validiums باستثناء DA والنظام.

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

7. الاستفادة من الانصهار

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

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

Fusion Security  هو أمان اقتصادي مشفر إضافي مصمم لتحقيق الرؤية الموحدة لـ Avail.

الرموز الخارجية.

يسمح Fusion بإضافة فئتين جديدتين من الرموز المميزة إلى خزنة Avail's Stacking، مما يعزز اقتصاديات التشفير لأمن النظام البيئي بأكمله:

● العملات المشفرة الناضجة: الرموز المميزة مثل BTC وETH وSOL.

● رموز التراكم الناشئة: الرموز المميزة الجديدة التي تم إنشاؤها على Avail تقتصر على جزء صغير من إجمالي الحصة لبدء فائدتها.

سيعمل هذا النهج على تعزيز أمان الاقتصاد المشفر لشركة Avail تدريجيًا ويمثل بداية الاستفادة من الرموز الخارجية مثل ETH وBTC واحدة من أولى حالات التوصل إلى توافق في الآراء بشأن blockchains مختلفة.

في الوقت الحالي، يتبع نموذج Fusion الذي تم تطويره لـ Avail طريقتين مختلفتين:

: left;">1. وحدة التوقيع المساحي على Avail blockchain: ستدعم هذه الوحدة العديد من الرموز الخارجية من خلال صواني الأصول في عقد Avail.

2. وحدة التوقيع المساحي لتحويل الأصول: سيمكن هذا من تحويل الأصول الخارجية إلى الرموز المميزة الأصلية لـ Avail والحفاظ عليها عند تخطيط تحويل سعر التحويل.

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

الانصهار مستوحى من:

● Eigenlayer، الرائد في إعادة- المستقلة Stake ETH

● Babylon Chain، تقوم بإنشاء خدمة تسمح باستخدام منصة لأمن BTC (Bitcoin) عبر شبكات blockchain المختلفة< /p>

● التناضح، الأمن الشبكي الرائد الذي يسمح لسلسلة واحدة بتأمين البيانات من سلاسل أخرى اقتراض الأمن الاقتصادي

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

8. الرمز المميز

الرمز المميز سيعزز الاقتصاد الدائري داخل الشبكة < /p>

● DA وNexus  و Fusion ستتم حماية طبقات الأمان من خلال تخزين الرمز المميز Avail

● يتم دفع رسوم المعاملات والتجسير بالرمز المميز الأصلي لـ Avail، مما يضمن استدامة الشبكة ذاتيًا وتوفير حوافز متسقة لجميع المشاركين 

سيشكل حاملو الرمز المميز المجتمع الأساسي للعديد من المشاريع التي تتطلع إلى البناء على Avail DA والاستفادة من النظام البيئي Avail .

9. رؤية موحدة

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

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

تبدأ الواجهة الخلفية لمنصة Avail بعد ذلك في العمل من خلال الاستفادة من AvailNexus ودعمه للمراسلة غير المتزامنة. يتواصل النظام مع السلاسل الأخرى في النظام البيئي لتلبية طلبات المستخدمين، مما يضمن تجربة مستخدم web3 سلسة وفعالة وموحدة.