يمكن تفسير AO على أنه شبكة لا متناهية المشاركة والتوسع. كل عملية هي مشاركة.
كتبت بواسطة: 0xmiddle
مراجعة: Sandy
المصدر: اتحاد المحتوى - الاستثمار
!
AO ليست بمعنى تقليدي للبلوكشين. إنها تصميم غير تقليدي ومعارض للمألوف، مما يجعل الباحثين الذين يبدأون للتو في فهم AO يشعرون بالحيرة في بعض الأحيان، خاصةً عندما يحاول الباحثون تحديد AO ضمن هيكل بلوكشين تقليدي:
-
بعيدا عن PoS و PoW، ما هو نوع آلية الاتفاق التي يشير إليها AO باسم “التوافق الهولوغرافي”؟
-
بدون سلسلة هاش ، ولا حتى بلوك ، كيف يضمن AO عدم قابلية تغيير البيانات؟
-
بدون محور تنسيقي، كيف يضمن AO توافق الحالة العامة؟
-
لا توجد آلية للحوسبة الزائدة ، فمن سيضمن موثوقية الحسابات؟ ماذا لو حدث خطأ في الحساب؟
-
كيفية ضمان توافقية التشغيل بين العمليات في حالة عدم وجود أمان مشترك؟
سأساعدك من خلال ثلاثة منظورات، باستخدام مفاهيم مألوفة في تكنولوجيا البلوكتشين، لتساعدك على الانتقال من المعروف إلى المجهول وتحويل المجهول إلى المعروف، وفهم AO على مستوى عاطفي.
مشاركة视角
بعد التعلم حول سلاسل الكتل العامة مثل إثيريوم 2.0 وبولكا ونير، يجب أن يكون الجميع على دراية بـ “مشاركة”.
مفهوم المشاركة: في سلسلة الكتل، المشاركة هي حلاً لزيادة قابلية التوسع في الشبكة، من خلال تقسيم الشبكة إلى عدة مشاركات، حيث يتم التحقق ومعالجة المعاملات بشكل مستقل في كل مشاركة وإنشاء كتلتها الخاصة، وبالتالي يتم تعزيز كفاءة الشبكة الكلية. يمكن تحقيق التوافق المتزامن داخل المشاركة، بينما يتم تحقيق التوافق الغير متزامن بين المشاركات من خلال بروتوكولات الاتصال المعينة.
Polkadot هو نموذج مشاركة الأكثر تمثيلاً. في Polkadot ، كل سلسلة متوازية هي حصة ، حيث تجمع كل سلسلة متوازية وتعبئة سلسلة الكتل الخاصة بها بشكل مستقل ، ويتم تعيين مجموعة صغيرة من المحققين عشوائيًا من قبل سلسلة الوسيط للتحقق. تتفاهم السلاسل المتوازية باستخدام تنسيق رسائل XCM الموحد لتحقيق التشغيل المتبادل.
AO的极致مشاركة
من منظور المشاركة ، يمكن فهم AO كـ ‘مشاركة’ متطرفة: كل عملية هي مشاركة. تخيل ، ماذا سيحدث إذا كان كل عقد ذكي في Ethereum يعمل على مشاركة منفصلة؟ نعم ، هذا هو AO. كل عملية مستقلة ، والاستدعاء بين العمليات يعتمد على الرسائل المدفوعة ، بطريقة تجريبية تمامًا.
وجهة نظر متعددة الوحدات
ولكن اكتشفنا شيئًا حاسمًا في تصميم Polkadot ، وهو وجود “سلسلة وسيطة” ، وفي ETH2.0 أيضًا هناك “سلسلة بيانات” ، ودورها هو أن تكون طبقة الإجماع الموحدة التي توفر الأمان المشترك. تتحمل طبقة الإجماع الموحدة مسؤولية توفير خدمات التحقق المباشرة أو غير المباشرة لكل المشاركات والرسائل بين المشاركات. ويبدو أن AO ليس لديها هذا المكون ، فكيف يتم تصميم طبقة الإجماع في AO؟
طبقة الاتفاق في AO هي في الواقع Arweave. من وجهة نظر تعدادية المكونات، يمكن فهم AO على أنها L2 لـ Arweave، حيث أنها Rollup L1 لـ Arweave، سيتم تحميل سجلات جميع الرسائل التي تم إنشاؤها خلال عملية تشغيل شبكة AO على Arweave التخزين الدائم، وبمعنى آخر، هناك سجل لا يمكن تغييره لتشغيل شبكة AO على Arweave. قد تسأل، كون Arweave هي منصة تخزين لامركزية ولا تتمتع بقدر كبير من القدرة الحسابية. كيف يتم التحقق من البيانات التي يتم تحميلها من شبكة AO إلى Arweave؟
الإجابة هي: لا يتحقق Arweave ، ولكن شبكة AO تحتوي على آلية تحكيم متفائلة. Arweave لا ترفض بيانات الرسائل القادمة من شبكة AO ، وسيحمل كل رسالة معرف العملية الخاص بها ، وتوقيع CU (وحدة الحساب) التي تشغلها ، وسيحمل أيضًا توقيع SU (وحدة الترتيب) المُرتبط به. عند حدوث خلاف ، يمكن الاعتماد على سجلات الرسائل الغير قابلة للتغيير على Arweave ، وإدخال مزيد من العقد لإعادة الحساب ، لإنشاء فروع صحيحة ، والتخلص من الفروع الخاطئة الأصلية ، وفرض غرامات على CU أو SU المخطئة في الفروع الصحيحة. هنا يجب أن نلاحظ أن MU مسؤولة فقط عن جمع رسائل العمليات المعلقة ، وتقديمها لـ SU ، وهي غير موثوقة ، ولا تتطلب وديعة ، ولا تتضمن فرض غرامات.
AO يبدو كشبكة Optimistic Rollup التي تعتمد على Arweave ك L1، إلا أن عملية التحقق من التحديات لا تحدث على L1 بل تحدث داخل شبكة AO ذاتها.
ولكن هناك مشكلة هنا، حيث لا يمكن أن تنتظر كل رسالة حتى تُسجل في Arweave ثم تتأكد، في الواقع يستغرق تشكيل الثبات النهائي لـ Arweave وقتًا يزيد عن نصف ساعة. لذلك سيكون لدى AO طبقة توافقية ناعمة خاصة به، تمامًا مثل Rollups لـ Ethereum لديها طبقة توافقية ناعمة خاصة بها، حيث لن تنتظر معظم المعاملات التأكيد على L1، بل ستُسجل مباشرة.
عملية AO في الواقع هي التحقق من قوة الاستدلال الذاتي.
يجب على العملية التي تعمل كجهة استقبال للرسائل أن تقرر ما إذا كانت ستنتظر تأكيدًا من أرويف قبل معالجة الرسالة أو معالجتها بمجرد التحقق من الإجماع الناعم ، وحتى في مرحلة التحقق من الإجماع الناعم ، يمكن للعملية أن تتبع استراتيجية مرنة ، ويمكن أن يكون التحقق من قبل وحدة الأشكال المتعددة الفردية الوحيدة قبل المعالجة ، أو يمكن أن يتم التحقق من قبل وحدات الأشكال المتعددة المتعددة ، والتحقق المتبادل ، وتحديد درجة الزيادة المطلوبة هو أيضًا من اختيار العملية.
في التطبيق العملي، يكون تأكيد القوة غالبًا مرتبطًا بمبلغ المعاملات، على سبيل المثال
- الصفقات ذات القيمة المنخفضة تستخدم استراتيجية التحقق السريعة وتتم معالجتها بعد التأكيد الفردي
- تداول متوسط الحجم، استنادًا إلى الحجم المحدد، يتم اتباع استراتيجية معالجة متعددة النقاط بدرجات تكرار مختلفة
- إذا كانت هناك معاملة ذات قيمة كبيرة ، فسيتم اتباع استراتيجية التحقق الحذرة ، وسيتم معالجتها بعد التأكد من شبكة Arweave.
هذا هو ما يسمى بنمط ‘التوافق الكلي’ + ‘التحقق المرن’ التي ذكرها AO، من خلال فصل ‘التوثيق القابل للتحقق’ عن ‘عملية التحقق’ نفسها، اتخذ AO نهجًا تمامًا مختلفًا عن الممارسات التقليدية لسلسلة الكتل، حيث يكون مسؤول التحقق من الرسائل ليس في الشبكة نفسها، وإنما في جهة الاستقبال أو في مطور التطبيقات.
بفضل اعتماد هذا النموذج المشترك، يصبح من الممكن لشركة AO اعتماد نموذج غير محوري وغير محدود لـ “المشاركة المتقصدة”.
بالطبع، أدى التحقق المرن إلى قوة تحقق مختلفة للعمليات، وفي التفاعل المعقد، قد يؤدي إلى انقطاع سلسلة الثقة، حيث أن فشل جزئي في سلسلة الاتصال الطويلة قد يؤدي إلى فشل المعاملة بأكملها أو الخطأ، في الواقع، في مرحلة شبكة AO للاختبار، تم كشف مثل هذه المشاكل بالفعل. أعتقد أن AO يجب أن تحدد معيار قوة التحقق الأدنى لجميع مهام التحقق، دعونا نرى ما الجديد الذي سيقدمه AO في الشبكة الرسمية القادمة.
وجهة نظر الموارد
في النظام النقدي التقليدي لسلسلة الكتل، يتم تجريد الموارد على أنها “مساحة الكتل”، ويمكن فهم مساحة الكتل على أنها مجموعة من الموارد التخزينية والحسابية ونقل البيانات التي يقدمها العقد، وترتبط عضويًا من خلال سلسلة الكتل على السلسلة لتوفير وسيلة لتشغيل التطبيقات على السلسلة. مساحة الكتل هي مورد محدود، وفي سلسلة الكتل التقليدية، تحتاج التطبيقات المختلفة إلى منافسة مساحة الكتل ودفع رسوم لها، ويحقق العقد من خلال هذه الرسوم الربح.
لا توجد مفهوم للكتل في AO، وبالتالي لا يوجد مفهوم ‘مساحة الكتل’. ومثل العقود الذكية الأخرى على السلسلة، كل عملية على AO تستهلك موارد أثناء التشغيل، حيث تحتاج العقود الذكية إلى عقدات لتخزين المعاملات والبيانات الحالية مؤقتًا، وتحتاج أيضًا إلى استهلاك موارد الحوسبة من العقدات لأداء المهام الحسابية، وتحتاج الرسائل التي ترسلها إلى نقل MU وSU إلى العملية المستهدفة.
في AO ، تنقسم العقد إلى ثلاثة أنواع ، CU (وحدة الحساب) ، MU (وحدة الرسالة) ، SU (وحدة الترتيب) ، حيث أن CU هو النواة التي تحمل مهمة الحساب. MU و SU يحملان مهمة الاتصال. عندما يحتاج process ما إلى تفاعل مع process آخر ، سيتم إنشاء رسالة وتخزينها في طابور الصادر ، ثم سيقوم CU الذي يشغل هذا process بتوقيع تلك الرسالة ، وسيقوم MU بسحب الرسالة من طابور الصادر وتقديمها إلى SU ، حيث يمنح SU الرسالة رقم تسلسلي فريد ويقوم بتحميلها إلى تخزين Arweave الدائم. ثم يمر MU بالرسالة إلى طابور الوارد ل process الهدف ، وبذلك يكتمل تسليم الرسالة. يمكن فهم MU كجامع وموصل للرسائل ، وSU كمرتب ومحمل للرسائل.
فيما يتعلق بموارد التخزين، يحتاج MU في شبكة AO فقط إلى تخزين البيانات المؤقتة اللازمة للحسابات، ويمكن التخلص منها بمجرد اكتمال الحسابات. يتولى Arweave التخزين الدائم، وعلى الرغم من عدم قدرة Arweave على التوسع الأفقي، إلا أن سقف أدائه في التخزين مرتفع للغاية، ومتطلبات التخزين في شبكة AO، لا يمكن في الوقت الراهن أن تصل إلى سقف أداء Arweave.
لقد اكتشفنا أن موارد الحساب وموارد النقل وموارد التخزين في شبكة AO مفصولة عن بعضها البعض. بالإضافة إلى الموارد الاستباقية المتاحة من قِبل Arweave، يمكن توسيع موارد الحساب وموارد النقل بشكل مستقل دون أي قيود.
كلما انضمت عقد CU عالية الأداء إلى الشبكة ، زادت قوة الحوسبة للشبكة ، ويمكن دعم المزيد من العمليات. وبالمثل ، كلما انضم المزيد والمزيد من عقد MU و SU عالية الأداء إلى الشبكة ، زادت سرعة كفاءة نقل الشبكة. بمعنى آخر ، يمكن إنشاء “مساحة الكتلة” في AO مرارا وتكرارا. بالنسبة للتطبيقات ، يمكنك إما شراء خدمات عقدة CU و MU و SU العامة في السوق المفتوحة ، أو يمكنك تشغيل العقد الخاصة لخدمة تطبيقاتك الخاصة. إذا توسعت أعمال تطبيقك، يمكنك تحسين الأداء عن طريق توسيع نطاق العقد الخاصة بك، تماما كما تفعل تطبيقات Web2. هذا أمر لا يمكن تصوره على سلاسل الكتل التقليدية.
على مستوى تسعير الموارد، يمكن لـ AO تعديلها بمرونة من خلال التوازن بين العرض والطلب، مما يجعل توفير الموارد قابلاً للتوسع وفقًا للاحتياجات. يكون هذا التعديل حساسًا للغاية، حيث يمكن للعقد الانضمام والخروج بسرعة كبيرة. إذا نظرنا مرة أخرى إلى إيثريوم، سنجد أنه عندما يرتفع الطلب على الموارد بشكل حاد، فليس لدينا خيار سوى تحمل رسوم الغاز المرتفعة، لأن إيثريوم لا يمكنه زيادة أداءه من خلال زيادة عدد العقد.
تلخيص
من خلال الاستفادة من المفاهيم التي يعرفها معظم الباحثين في تشفير المعلومات ، مثل “مشاركة” و “تعدد الوحدات” و “Rollup” و “مساحة الكتلة” وغيرها ، يتم التركيز على مبادئ وآليات AO لمساعدة الجميع على فهم كيف يقوم AO بالتوسع بشكل لا محدود تقريبًا من خلال الابتكار الثوري.
الآن عند النظر إلى بعض الأسئلة الأولية، هل فهمتها بالفعل؟
1. غير PoS، غير PoW ، ما هو نوع آلية التوافق المستحسن المعروف باسم `` الاتفاق الهولوغرافي ‘’ الذي يتحدث عنه AO؟
آلية الاتفاق في AO هي في الواقع تصميم يقترب من Op Rollup. على مستوى الاتفاق الصلب ، يعتمد على Arweave ، وعلى مستوى الاتفاق الناعم ، يمكن لكل عملية أن تقرر بشكل مستقل قوة التحقق وتقرر بشكل مستقل كم عدد من وحدات CU للحساب الزائد.
- بدون سلسلة تجزئة ، أو حتى كتلة ، كيف تضمن AO أن البيانات غير قابلة للتغيير؟ **
بيانات DA التي تم تحميلها إلى Arweave غير قابلة للتغيير ، مما يوفر إمكانية التحقق لجميع الحسابات والتحويلات على AO. لا يتعين على AO نفسها الحد من قدرة المعالجة لكل وحدة زمنية ، لذلك ليست هناك حاجة لتعيين الكتل. “سلاسل التجزئة” و “الكتل” هي هياكل تستخدم لضمان أن البيانات غير قابلة للتغيير ، وسلاسل Arweave بها.
3. بدون محور تنسيق مركزي، كيف يمكن لـ AO ضمان توافق حالة النظام الكلي؟
كل عملية هي “مشاركة” مستقلة، تدير المعاملات والحالة بشكل مستقل، وتتفاعل العمليات بطريقة تعتمد على الرسائل. لذلك لا يلزم توافق الحالة العالمية. يوفر تخزين Arweave الدائم قدرة التحقق العالمية والقدرة على التتبع التاريخي، بالاعتماد على آلية التحدي المتفائلة، ويمكن استخدامها لحل النزاعات.
4. لا يوجد آلية حوسبة زائدة، فمن يضمن موثوقية الحسابات؟ ماذا يحدث إذا حدث خطأ في الحسابات؟
AO لا توجد آلية حاسوبية للتكرار الزائد على المستوى العالمي، حيث يمكن لكل عملية أن تقرر بمفرده كيفية التحقق من موثوقية كل رسالة تم إرسالها إليها. وإذا حدثت أخطاء في الحساب، يمكن اكتشافها وتصحيحها عن طريق تحدي متفائل.
5. لا يوجد أمان في المشاركة ، فكيف يتم ضمان التشغيل المتبادل بين العمليات؟
يجب على Process أن يدير الائتمان الخاص بكل عملية يتفاعل معها بنفسه، ويمكن تطبيق مستويات التحقق المختلفة على عمليات ذات مستويات أمان مختلفة. بالنسبة لعمليات التفاعل المعقدة في سلسلة الاستدعاءات، قد يكون لدى AO متطلبات بشأن أدنى مستوى لقوة التحقق لتجنب تكاليف تصحيح عالية نتيجة لانقطاع سلسلة الثقة.
