AO - كمبيوتر فائق التوازي لا يمكنك تخيله

المصدر: PermaDAO

هذا نص مجزأ حول التكنولوجيا ولا يمكن حتى أن يصبح مقالًا. دعونا نتحدث بشكل عرضي عن AO.

محرك الأقراص الثابتة العالمي المشترك

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

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

الآن أصبح AO ممكنًا. عندما صممنا أنا وسام في الأصل بروتوكول MSG (النموذج الأولي لـ AO)، اعتقدت أنه كان كافكا على blockchain. ومع ذلك، لا ينصب التركيز على توفير قائمة انتظار رسائل لا مركزية للتطبيقات، ولكن على استبدال اتصال http في بنية C/S باتصالات رسائل غير موثوقة. إذا كان كل من طلب المستخدم واستجابة الخادم يستخدمان AO. ثم سنقوم بإعادة إنشاء نظام بيئي لامركزي حقيقي للإنترنت على AO، تمامًا كما هو متصور في يوليو 2020.

تتمتع AO بإمكانيات كبيرة لنقل الإنترنت بالكامل إلى Arweave. Arweave لم تعد مكتبة الإسكندرية مقتصرة على التخزين، فهي لا تسجل الماضي فقط. باستخدام AO يمكننا تسجيل قصص اليوم وتوزيع القيمة المستقبلية بطريقة لا مركزية.

الجدل

في الآونة الأخيرة كانت هناك خلافات حول AO، ويرجع ذلك أساسًا إلى مشكلتين:

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

النقاط الرئيسية: نحن نعلم أنه يتم تحميل معاملات UTXO إلى السلسلة بعد التحقق، ولكن بموجب نموذج SCP، بغض النظر عما إذا كانت بيانات جيدة أو سيئة، يتم تحميل جميع البيانات. إلى سلسلة AR، وهذا مشابه لـ UTXO الخاص بـ BTC، وهو فرق كبير جدًا. ولكن ألا يمكن التحقق من التكرار على السلسلة والإنفاق المزدوج على السلسلة؟ يحتاج برنامج SCP فقط إلى تشغيل كافة المعاملات الثلاثية الأبعاد للتحقق منه! إذا كانت معاملة مكررة، فسيتم تجاهلها بواسطة برنامج SCP.

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

2. تتمتع تطبيقات SCP بميزات يمكن التحقق منها، فكيف يحل AO المشكلة التي يمكن التحقق منها؟ هل يحتاج المستخدم إلى تشغيل عقدة كاملة؟

عندما تتم الإجابة على السؤال الأول إلى حد ما، سيعتقد السائل أنه يجب على المستخدم حساب دفتر الأستاذ بأكمله، وهو أمر صعب للغاية. وهذا يتعارض مع المشكلة التي تريد شجرة ميركل الخاصة بـ BTC/ETH حلها، فبموجب فكرة BTC/ETH، تعد ميركل جوهر التحقق، حيث يتم تحميل جذر ميركل إلى السلسلة من خلال إثبات العمل (PoW)، بحيث يمكن التحقق منها. الآن أنت تخبرني أن AO ليس لديه شجرة ميركل؟ لذا فإن الاستنتاج هو أنه لا يمكن التحقق من AO على الإطلاق، ولا يوجد إجماع، وهي عملية احتيال! لذا نعود إلى السؤال 1. بشكل عام، سيطرح السائل أسئلة في حلقة حول هذين السؤالين، ولن يفكر في بنية التصميم ومبادئ AO.

النقاط الرئيسية: لا يحل AO المشكلات التي يمكن التحقق منها، كما أن وظائف AR وAO منفصلة تمامًا! الواقع المعزز يقوم بتخزين غير قابل للتغيير لضمان الأمن وإمكانية التحقق. هناك ميركل هنا وهناك إجماع. الإجماع هو ترتيب البيانات، وليس حالة حساب البيانات. يقوم AO بإجراء العمليات الحسابية فقط على البيانات التسلسلية في AR وينشئ الحالة، ولا يمكن لـ AO تغيير ترتيب بيانات AR، أي أن AO لا يمكنه تغيير الإجماع. يتم التحقق من الحالة المحسوبة من خلال PoW/PoS، وهو نموذج حوسبة متصل بالسلسلة، وهو يختلف تمامًا عن SCP.

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

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

النقاط الرئيسية

لا يؤدي AO إلى إجماع حول كيفية تنفيذ الشرطة المائلة و عمل النعناع؟ الأمر بسيط جدًا، AO هو تطبيق SCP، في هذا الوقت، يتم ربط كل من حالة الاستعلام وأحداث حالة الإرجاع بـ Arweave، سيقوم برنامج AO SCP بتحميل هذين الحدثين (الاستعلام والإرجاع) وحساب النعناع من هذين الحدثين. ونتائج مائلة.

يسهل فهم هذا الجزء إذا نظرت إلى الكود مباشرةً:

https://github .com/outprog/ slash-demo/blob/main/vm/vm_test.go

الاستنتاج

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

للحصول على ممارسات محددة، راجع Sam's X:

https://twitter. كوم /samecwilliams/status/1764023657058148718 .

ألا يوجد أوراكل؟ كلهم عرافون!

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

infura.io:https://www.infura.io/

ملاحظة:

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

• في شبكة AO/SCP، يجب توقيع طلب المستخدم، ويجب أيضًا توقيع الحالة التي ترجعها العقدة، ويتم تخزين جميع السجلات في Arweave لتكوين نموذج "البيانات الثلاثية الأبعاد"، مما يضمن الموثوقية. لا يحتاج المستخدمون إلى تشغيل أي عقد للحصول على حالة موثوق بها. في وضع AO/SCP، يتم تحميل جميع المعلومات الموجودة على الشبكة، بما في ذلك الاستعلام عن معلومات الطلب وإرجاعها (لا يتم تحميل طلبات http). AO يحل مشكلة الميل الأخير من انعدام الثقة.

في الممارسة الهندسية، يكسر AO/SCP مفهوم السلسلة/خارج السلسلة ويدمج الحوسبة الموثوقة والأوراكل في نظام موحد. النظام لامركزي ويكسر الحدود بين Web2 وWeb3. AO/SCP والحوسبة المتسلسلة هما نموذجان مختلفان تمامًا. يمكن اعتبار هذا النظام بمثابة حاسوب عالمي يتكون بالكامل من النبوءات، والوحيات التي تقدمهاالكشوف هي حقائق موضوعية لا يمكن التلاعب بها.

التحقق المرن

لا أعرف عندما يصبح الإجماع مسألة ثنائية. فإما أن يكون هناك إجماع أو لا يوجد إجماع. ألا يوجد إجماع وسط؟

ينعكس هذا الفهم في صناعة blockchain. فإما أن يكون إلهاً أو يكون حثالة. تمامًا مثل المعتقدات الدينية، إما أن الماء أو النار غير متوافقين.

لكن AO يوفر بنية إجماع مختلفة تمامًا - توفر ثبات Arweave ونموذج SCP أساسًا متينًا للإجماع، وهو "قابلية التحقق" التي ذكرناها مرارًا وتكرارًا، ولكن ما هي تكلفة التحقق من جانب التطبيق أن هذا الإجماع مرن.

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

توجد وحدة حوسبة CU1، حيث يتم تشغيل عمليتين P1 وP2، ويشار إليهما بـ CU1(P1, P2).

يوجد الآن: CU1(P1, P2) وCU2(P3, P4) وCU3(P1) وCU4(P1).

هدف الحوسبة: يطلب P3 في CU2 من P1 توفير معلومات حوسبة موثوقة.

وضع الثقة الفردي

1. يقدم الكود الموجود في P3 طلب حساب إلى P1.

2. يرسل برنامج جدولة SU طلب P3 إلى CU4(P1) لإجراء الحساب.

3. يستجيب CU4(P1) لنتيجة الحساب ويعيد P3.

في هذا الوقت، يثق P3 تمامًا في نتائج حساب P1 في CU4 ويواصل العملية.

وضع الثقة المتعددة

1. في P3 يصدر الكود طلب حساب إلى P1، ويطلب P3 من SU تخصيص وحدات حسابية متعددة.

2. تقوم SU بتعيين طلب P3 إلى CU1(P1) وCU3(P1) وCU4(P1).

3. CU1(P1)، CU3(P1)، CU4(P1) تستجيب لنتائج الحساب.

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

وضع الثقة هو مجرد وضع تطوير في AO. يمكن للمطورين تطوير قواعد الحكم بناءً على متطلبات الثقة. يمكن لبرنامج P3 أن يتطلب 100 وحدة حسابية لإجراء العمليات الحسابية، ويتطلب أن تكون نتائج الحساب لـ 100 وحدة متسقة تمامًا. كل هذا يتوقف على كيفية قيام المطور بتنفيذ الكود في P3.

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