المؤلف: 0xmiddle
يمكن فهم AO على أنها شبكة ذات تقسيم غير محدود وتوسع غير محدود. كل عملية عبارة عن قطعة.
AO ليس blockchain بالمعنى التقليدي. يمكن أن يؤدي تصميمه غير التقليدي وغير البديهي بسهولة إلى إرباك الباحثين الذين تعلموا للتو عن AO في نقاط معينة، خاصة عندما يحاول الباحثون تأطير AO باستخدام بنية blockchain التقليدية:
1. غير PoS، غير PoW، أي نوع من آلية الإجماع هو "الإجماع المجسم" الذي ذكره AO؟
2. بدون سلسلة تجزئة أو حتى كتلة، كيف يضمن AO أن البيانات غير قابلة للتغيير؟
3. بدون مركز تنسيق، كيف يمكن لـ AO ضمان اتساق الحالة العالمية؟
4. بدون آلية حسابية زائدة، من سيضمن موثوقية الحسابات؟ ماذا علي أن أفعل إذا قمت بخطأ في الحساب؟
5. بدون أمان مشترك، كيف يمكن ضمان إمكانية التشغيل البيني بين العمليات؟
سأستخدم 3 وجهات نظر ومفاهيم يعرفها الجميع بالفعل في blockchain لمساعدة الجميع على الانتقال من المعلوم إلى المجهول، وتحويل المجهول إلى المجهول معروف، فهم AO على المستوى الإدراكي.
منظور المشاركة
بعد إصدار Ethereum 2.0، يجب على الجميع التلويح أن تكون على دراية بتعليم السلاسل العامة مثل Card وNear و"Sharding".
مفهوم التقسيم:في blockchain، يعد التقسيم حلاً لتحسين قابلية توسيع الشبكة عن طريق تقسيم الشبكة إلى أجزاء متعددة، حيث يقوم كل جزء بالتحقق من صحة المعاملات ومعالجتها بشكل مستقل وإنشاء الكتل الخاصة به، وبالتالي زيادة كفاءة الشبكة بشكل عام. يمكن تحقيق التشغيل البيني المتزامن داخل الأجزاء، ويمكن تحقيق التشغيل البيني غير المتزامن بين الأجزاء من خلال بروتوكولات اتصال معينة.
Polkadot هي بنية التجزئة الأكثر شيوعًا. في Polkadot، كل سلسلة مظلة عبارة عن قطعة، وتقوم سلسلة Parachain بشكل مستقل بجمع وتعبئة blockchain الخاص بها، ويتم تعيين مجموعة من المدققين بشكل عشوائي بواسطة سلسلة الترحيل للتحقق. يتم استخدام تنسيق رسالة XCM الموحد للتواصل بين السلاسل المتوازية لتحقيق إمكانية التشغيل البيني.
التقطيع النهائي لـ AO
استخدام التقطيع من منظور، يمكن فهم AO على أنه "تقسيم" نهائي: كل عملية عبارة عن جزء. تخيل كيف سيكون الأمر لو كان كل عقد ذكي في إيثريوم يعمل على جزء منفصل؟ نعم، هذا هو آو. كل عملية مستقلة، والمكالمات بين العمليات تعتمد على الرسائل ويتم تنفيذها بطريقة غير متزامنة تمامًا.
المنظور المعياري
لكننا وجدنا مفتاحًا، في في تصميم Polkadot، هناك "سلسلة ترحيل"، وهناك أيضًا "سلسلة منارة" في ETH2.0، وتتمثل مهمتها في العمل كطبقة إجماع موحدة لتوفير الأمان المشترك. طبقة الإجماع الموحدة مسؤولة عن توفير خدمات التحقق المباشرة أو غير المباشرة لجميع الأجزاء ونقل الرسائل بين الأجزاء. يبدو أن AO لا يحتوي على هذا المكون، فكيف يتم تصميم طبقة الإجماع في AO؟
طبقة الإجماع الخاصة بـ AO هي في الواقع Arweave. من منظور معياري، يمكن فهم AO على أنه L2 لـ Arweave، مع Arweave كمجموعة L1. سيتم تحميل سجلات جميع الرسائل التي تم إنشاؤها أثناء تشغيل شبكة AO إلى Arweave للتخزين الدائم، أي على Arweave. يوجد سجل ثابت لتشغيل شبكة AO. لذا قد تتساءل، Arweave عبارة عن منصة تخزين لا مركزية ولا تتمتع بقدرة حاسوبية كبيرة. كيف تتحقق Arweave من البيانات التي تم تحميلها من شبكة AO؟
الإجابة هي: لم يتم التحقق من Arweave، سيكون لدى شبكة AO نفسها آلية تحكيم متفائلة. يقبل Arweave جميع بيانات الرسائل التي تم تحميلها من شبكة AO، وستحمل كل رسالة معرف العملية الخاص بمرسلها، وتوقيع CU (وحدة الحوسبة) التي تقوم بتشغيلها، وتوقيع SU (وحدة الفرز) التي تقوم بفرزها . عند حدوث نزاع، يمكنك الاعتماد على سجلات الرسائل غير القابلة للتغيير في Arweave لتقديم المزيد من العقد لإعادة التشغيل لإنشاء تفرع صحيح، وتجاهل التفرع الخطأ الأصلي، ومعاقبة CU الخاطئ في التفرع الصحيح أو الإيداع لـ SU. وتجدر الإشارة هنا إلى أن MU مسؤولة فقط عن جمع الرسائل الصادرة من العملية وتمريرها إلى SU، وهي غير موثوقة ولا تتطلب أي إيداع ولا تنطوي على عقوبات.
AO مشابه جدًا لـ Optimistic Rollup مع Arweave كـ L1، فيما عدا أن عملية تحدي التحقق لا تحدث على L1، ولكن في شبكة AO نفسها.
ومع ذلك، لا تزال هناك مشكلة هنا، فمن المستحيل انتظار تضمين كل رسالة في Arweave قبل تأكيدها، في الواقع، الوقت النهائي للتكوين Arweave يستغرق أكثر من نصف ساعة. لذلك، سيكون لدى AO طبقة إجماع ناعمة خاصة بها، تمامًا كما تمتلك مجموعة Ethereum طبقة إجماع ناعمة خاصة بها، ولن تنتظر معظم المعاملات تأكيد L1 قبل أن تتم إضافتها.
تحدد العملية في AO قوة التحقق بشكل مستقل.
باعتبارها متلقي الرسالة، تحتاج العملية إلى تحديد ما إذا كانت ستنتظر تأكيد Arweave قبل معالجة الرسالة، أو معالجة الرسالة بعد التأكيد بواسطة طبقة الإجماع الناعمة، حتى لو كان في عملية تأكيد طبقة الإجماع الناعمة، يمكن للعملية أيضًا اعتماد إستراتيجية مرنة، ويمكن معالجتها مباشرة بعد التأكيد بواسطة CU واحدة، أو يمكن تأكيدها بشكل متكرر من خلال CUs متعددة والتحقق منها بشكل متقاطع قبل المعالجة تحددها العملية.
في التطبيقات العملية، غالبًا ما ترتبط قوة التحقق بمبلغ المعاملة، على سبيل المثال
صغيرة بالنسبة للمعاملات متوسطة المبلغ، نعتمد استراتيجية تحقق سريعة ونقوم بمعالجتها بعد تأكيد النقطة الواحدة
بالنسبة للمعاملات متوسطة الحجم، نعتمد متعددة تأكيد النقاط والمعالجة اللاحقة بدرجات مختلفة من التكرار وفقًا للمبلغ المحدد للاستراتيجية
بالنسبة للمعاملات كبيرة الحجم، اتبع استراتيجية تحقق حذرة وقم بمعالجتها بعد التأكيد من قبل شبكة Arweave
وهذا ما يسميه AO "الإجماع المجسم" +" نموذج "التحقق المرن"، من خلال فصل سلوكيات "التحقق" و"التحقق" نفسها، يتبنى AO نهجًا مختلفًا تمامًا لقضايا الإجماع عن سلاسل الكتل التقليدية. لا تقع مسؤولية التحقق من الرسالة على عاتق الشبكة نفسها، ولكن على عاتق المتلقي العملية نفسها، أو بالأحرى مطور التطبيق.
وبسبب اعتماد مثل هذا النموذج المتفق عليه على وجه التحديد، أصبح AO قادرًا على اعتماد نموذج توسع لا نهائي وخالي من المحور من "التقسيم الشديد".
بالطبع، يؤدي التحقق المرن إلى نقاط قوة مختلفة للتحقق من العمليات المختلفة، وفي التشغيل البيني المعقد، قد يؤدي ذلك إلى انقطاع سلسلة الثقة وسلسلة اتصال أطول سيؤدي فشل الروابط الفردية إلى فشل أو خطأ المعاملة الإجمالية. في الواقع، تم الكشف عن مثل هذه المشكلات خلال مرحلة اختبار الشبكة. أعتقد أن AO يجب أن تضع حدًا أدنى لمعايير كثافة التحقق لجميع مهام التحقق، فلننتظر ونرى التصميم الجديد الذي ستوفره AO في شبكتها الرسمية القادمة.
منظور الموارد
في أنظمة blockchain التقليدية، تكون الموارد يمكن فهم مساحة الكتلة على أنها مجموعة من موارد التخزين والحوسبة والنقل التي توفرها العقد، ويتم دمجها عضويًا مع الكتل الموجودة على السلسلة لتوفير ناقل لتشغيل التطبيقات الموجودة على السلسلة. تعد مساحة الكتلة موردًا محدودًا في سلاسل الكتل التقليدية، تحتاج التطبيقات المختلفة إلى التنافس على مساحة الكتلة ودفع ثمنها، وتحقق العقد أرباحًا من خلال هذا الدفع.
لا يوجد مفهوم للكتل في AO، وبطبيعة الحال لا يوجد مفهوم "مساحة الكتلة". ولكن مثل العقود الذكية في السلاسل الأخرى، تحتاج كل عملية على AO أيضًا إلى استهلاك الموارد عند التشغيل، وتتطلب من العقد تخزين المعاملات وبيانات الحالة مؤقتًا، وتتطلب أيضًا من العقد استهلاك موارد الحوسبة لأداء مهام الحوسبة الخاصة بها يتطلب نقل MU وSU إلى العملية المستهدفة.
في AO، يتم تقسيم العقد إلى ثلاث فئات، CU (وحدة الحوسبة)، MU (وحدة الرسائل)، وSU (وحدة التسلسل)، حيث CU هي وحدة الحوسبة. تحمل MU وSU مهام الاتصال. عندما تحتاج العملية إلى التفاعل مع العمليات الأخرى، سيتم إنشاء رسالة وتخزينها في قائمة الانتظار الصادرة، وستقوم وحدة التحكم التي تقوم بتشغيل العملية باستخراج الرسالة من قائمة الانتظار الصادرة وإرسالها إلى SU قم بتعيين رقم تسلسلي فريد للرسالة وتحميلها إلى Arweave للتخزين الدائم. يقوم MU بعد ذلك بتسليم الرسالة إلى قائمة الانتظار الواردة للعملية المستهدفة، ويتم إكمال تسليم الرسالة. يمكن فهم MU على أنها جامع الرسائل ومسلمها، ويمكن فهم SU على أنها مُسلسِل الرسائل وتحميلها.
أما بالنسبة لموارد التخزين، فإن الوحدة الرئيسية في شبكة AO تحتاج فقط إلى تخزين البيانات المؤقتة المطلوبة للحساب، والتي يمكن التخلص منها بعد اكتمال الحساب. Arweave هو المسؤول عن التخزين الدائم، على الرغم من أنه لا يمكن توسيع Arweave أفقيًا، إلا أن سقف أداء التخزين الخاص به مرتفع للغاية.
وجدنا أن موارد الحوسبة وموارد النقل وموارد التخزين في شبكة AO كلها منفصلة بالإضافة إلى موارد التخزين الموحدة التي توفرها Arweave الموارد ونقل الموارد يمكن توسيعها أفقيا دون أي قيود.
كلما انضمت عقد CU أكثر وأعلى أداءً إلى الشبكة، ستتمتع الشبكة بقدرة حوسبة أعلى ويمكنها دعم المزيد من عمليات المعالجة بالمثل، كلما زاد الأداء تنضم عقدتي MU وSU إلى الشبكة، مما يؤدي إلى زيادة كفاءة نقل الشبكة. بمعنى آخر، يمكن إنشاء "مساحة الكتلة" في AO بشكل مستمر. بالنسبة للتطبيقات، يمكنك إما شراء خدمات العقد CU أو MU أو SU العامة في السوق المفتوحة، أو يمكنك تشغيل العقد الخاصة بك لخدمة تطبيقاتك الخاصة. إذا توسعت أعمال التطبيق، فيمكنه تحسين الأداء تمامًا من خلال توسيع العقد الخاصة به، تمامًا كما تفعل تطبيقات Web2. وهذا أمر لا يمكن تصوره على سلاسل الكتل التقليدية.
على مستوى تسعير الموارد، يمكن تعديل AO بمرونة من خلال العرض والطلب، مما يسمح بتوسيع عرض الموارد والتعاقد وفقًا للطلب. سيكون هذا التعديل حساسًا للغاية، ويمكن إضافة العقد والخروج منها بسرعة كبيرة. إذا نظرنا إلى الإيثريوم، فسنجد أنه عندما يرتفع الطلب على الموارد بشكل حاد، ليس أمام الجميع خيار سوى تحمل رسوم الغاز المرتفعة، لأن الإيثريوم لا يمكنه تحسين أدائه من خلال توسيع عدد العقد.
الملخص
أعلاه، لقد اجتزنا معظم أبحاث التشفير ابدأ بالمفاهيم المألوفة للقراء، مثل "التقسيم"، و"النموذجية"، و"التجميع"، و"مساحة الكتلة"، وما إلى ذلك، وقم بتقسيمها إلى مبادئ وآليات AO لمساعدة الجميع على فهم كيفية استخدام AO للابتكار المدمر يمكن توسيعها إلى ما لا نهاية تقريبا.
الآن بالنظر إلى الأسئلة القليلة الأولى، هل تفهمها؟
1. غير PoS، غير PoW، ما نوع آلية الإجماع التي ذكرها AO "الإجماع المجسم"؟
إن آلية الإجماع الخاصة بـ AO هي في الواقع تصميم قريب من Op Rollup. على مستوى الإجماع الصعب، يتم الاعتماد على Arweave. على مستوى الإجماع البسيط، يمكن لكل عملية أن تقرر بشكل مستقل كثافة التحقق وعدد عقد CU التي تقوم بإجراء حسابات زائدة عن الحاجة.
2. بدون سلسلة تجزئة أو حتى كتلة، كيف يضمن AO أن البيانات غير قابلة للتغيير؟
بيانات DA التي تم تحميلها إلى Arweave غير قابلة للتغيير، مما يوفر إمكانية التحقق لجميع الحسابات وعمليات النقل على AO. لا يحتاج AO نفسه إلى الحد من سعة المعالجة لكل وحدة زمنية، لذلك ليست هناك حاجة لتعيين الكتل. "سلسلة التجزئة" و"الكتلة"، هذه الهياكل المستخدمة لضمان ثبات البيانات، متوفرة في سلسلة Arweave.
3. بدون مركز تنسيق، كيف يمكن لـ AO ضمان اتساق الحالة العالمية؟
كل عملية عبارة عن "جزء" مستقل يدير معاملاته وحالته بشكل مستقل. لذلك ليس مطلوبا اتساق الدولة العالمية. يوفر التخزين الدائم لـ Arweave إمكانية التحقق العالمي والتتبع التاريخي، بالإضافة إلى آلية التحدي المتفائلة، والتي يمكن استخدامها لحل النزاعات.
4. بدون آلية حسابية زائدة، من سيضمن موثوقية الحسابات؟ ماذا علي أن أفعل إذا قمت بخطأ في الحساب؟
ليس لدى AO آلية حسابية زائدة مفروضة عالميًا. يمكن لكل عملية أن تقرر بنفسها كيفية التحقق من موثوقية كل رسالة مرسلة. إذا حدث خطأ في الحساب، فمن الممكن اكتشافه وتصحيحه في شكل تحدي متفائل.
5. بدون الأمان المشترك، كيف يمكن ضمان إمكانية التشغيل البيني بين العمليات؟
تحتاج العملية إلى إدارة اعتماد كل عملية تتفاعل معها، ويمكنها استخدام مستويات مختلفة من قوة التحقق للعمليات ذات مستويات الأمان المختلفة. بالنسبة لعمليات التشغيل البيني مع سلاسل الاتصال المعقدة نسبيًا، ومن أجل تجنب ارتفاع تكاليف تصحيح الأخطاء الناتجة عن سلسلة ثقة معطلة، قد يكون لدى AO حد أدنى من متطلبات قوة التحقق. ص>