AO можна розуміти як мережу безкінечного шардування та безкінечного масштабування. Кожен процес є шардуванням.
Написав: 0xmiddle
Перегляд: Сенді
Джерело: Контент-гільдія - Інвестиційний дослідження
!
AO не є типовим блокчейном в традиційному розумінні. Його незвичайний та нетиповий дизайн часто призводить до плутанини серед дослідників, що щойно познайомилися з AO, особливо коли вони намагаються вписати його в рамки традиційної архітектури блокчейну.
-
Не PoS, не PoW, що саме означає ‘голографічна консенсус’ вказана АО? Який механізм консенсусу?
-
Без хеш-цепочки, і навіть без блоків, як AO забезпечує незмінність даних?
-
Як AO гарантує узгодженість загального стану без центральної координації?
-
Немає механізму зайвого обчислення, хто гарантує надійність обчислень? Що робити, якщо виникла помилка в обчисленнях?
-
Немає загальної безпеки, як забезпечити взаємодію процесів?
Я буду використовувати 3 точки зору, щоб допомогти вам зрозуміти AO на інтуїтивному рівні за допомогою вже відомих у блоці ланцюга понять, переходячи від відомого до невідомого і зробити невідоме відомим.
Погляд на Шардинг
Після освіти на громадських ланцюжках, таких як Ethereum 2.0, Polkadot, Near тощо, ви, напевно, знайомі з терміном “Шардинг”.
Концепція шардингу: У блокчейні шардинг - це рішення, яке поліпшує масштабованість мережі шляхом розбиття її на окремі шардинги. Кожен шардинг здійснює незалежну перевірку та обробку транзакцій, генерує власний блок, тим самим підвищуючи загальну ефективність мережі. У шардингу можлива синхронна взаємодія, між шардингами - асинхронна взаємодія за допомогою певного протоколу зв’язку.
Polkadot - це типова архітектура Шардингу. У Polkadot кожен паралельний ланцюг є Шардингом, паралельні ланцюги самостійно збирають і упаковують свої блоки, а потім через мережу ретрансляції випадковим чином призначається група перевіряючих для перевірки. Паралельні ланцюги взаємодіють за допомогою уніфікованого формату повідомлень XCM для досягнення міжоперабельності.
Найкращий Шардинг AO
З точки зору Шардингу, AO можна розуміти як найкрайніший варіант «Шардингу»: кожен процес є окремим Шардингом. Уявіть, що станеться, якщо кожний розумний контракт Ethereum буде запущений на окремому Шардингу? Так, це AO. Кожен процес є незалежним, виклики між процесами здійснюються за допомогою приводу повідомлень асинхронним способом.
Перспектива модульності
Але ми виявили ключовий момент - в дизайні Polkadot є «проміжний ланцюг», так само як і в ETH2.0 є «ланцюг маяка», їх роль полягає в тому, щоб бути єдиним рівнем згоди, який надає спільну безпеку. Єдиною рівнем згоди повинен бути відповідальним за надання прямої або опосередкованої перевірки всім Шардингам та повідомленням між Шардингами. Але здається, що у AO немає цієї компоненти, тоді як був розроблений рівень згоди AO?
Консенсусний рівень AO фактично є Arweave. З модулярної точки зору AO можна розглядати як L2 Arweave, використовуючи Arweave як L1 Rollup, всі журнали всіх повідомлень, що виникають під час роботи мережі AO, будуть завантажені в Arweave для постійного зберігання. Іншими словами, на Arweave є незмінний запис про роботу мережі AO. Тоді ви можете запитати, Arweave є децентралізованою сховище, яке не має великих обчислювальних можливостей. Як Arweave перевіряє дані, які завантажує мережа AO?
Відповідь: Arweave не перевіряє, а сама мережа AO має механізм оптимістичного арбітражу. Arweave не відмовляється від даних повідомлень, які надходять від AO мережі, кожне повідомлення містить ідентифікатор процесу відправника, підпис CU (обчислювальної одиниці), яка його виконує, а також підпис SU (сортувальної одиниці), яка його сортує. У разі суперечок можна спиратися на незмінні записи повідомлень на Arweave, залучаючи більше вузлів для повторного обчислення задля створення правильної розгалуженості, відкидаючи неправильну розгалуженість та штрафуючи CU або SU, які зробили помилки, в правильній розгалуженості. Тут важливо зауважити, що MU відповідає лише за збір потенційних повідомлень від процесу, передачу їх до SU, є безпідставним та не потребує застави або штрафування.
AO дуже схожий на оптимістичний ролап з Arweave в якості L1, за винятком того, що процес виклику перевірки не відбувається на L1, а відбувається в самій мережі AO.
Проте тут все ще є питання, неможливо чекати на включення кожного повідомлення в Arweave перед підтвердженням, фактично час формування остаточної визначеності Arweave перевищує півгодини. Тому AO сам має шар м’якого консенсусу, як у випадку Rollups Ethereum, більшість угод не будуть чекати на підтвердження L1, але будуть зараховані.
AO в Process фактично самостійно визначає міцність перевірки.
Як отримувач повідомлення, Process повинен вирішити, чи слід чекати, поки Arweave підтвердить повідомлення, чи обробити його відразу після підтвердження на рівні програмного забезпечення. Навіть на етапі підтвердження на рівні програмного забезпечення, Process може вжити гнучку стратегію, може бути оброблено після підтвердження однієї CU або після підтвердження декількох CU з подальшою перевіркою, рівень зайвості також визначається Process.
У практичному застосуванні міцність перевірки часто пов’язана з сумою угоди, наприклад
- Невеликі угоди обробляються за стратегією швидкої перевірки, після підтвердження одного пункту
- Середні угоди обробляються залежно від конкретної суми з використанням стратегії багатоточкового підтвердження з різним рівнем надійності.
- Для крупных сделок используется осторожная стратегия проверки, обработка происходит после подтверждения в сети Arweave.
Це те, що AO називає «голографічною згодою» + «гнучкою перевіркою», шляхом розриву зв’язку між «перевіркою можливості підтвердження» та самою дією підтвердження AO вживає повністю відмінні від традиційного підходу блокчейну до питання консенсусу, відповідальність за перевірку повідомлень не лежить у самій мережі, а у процесі отримувача або, можна сказати, у розробнику програмного забезпечення.
Саме завдяки такій моделі консенсусу AO може використовувати модель без центру, без обмежень зі шкалюванням, з так званим «екстремальним Шардингом».
Звичайно, гнучка перевірка призвела до того, що різна сила перевірки процесів може призвести до розриву ланцюга довіри в складних взаємодіях, в окремих етапах довгого ланцюга викликів може спричинити невдачу або помилку в загальній транзакції, насправді, на етапі тестування мережі AO такі проблеми вже були виявлені. Я вважаю, що AO має встановити стандарт мінімальної сили перевірки для всіх завдань перевірки, і ми чекаємо з нетерпінням, які нові дизайни будуть в AO на офіційній мережі, яка незабаром запуститься.
Ресурсна перспектива
У традиційній системі блокчейн ресурси абстрагуються як “простір блоків”, який можна розуміти як колекцію ресурсів зберігання, обчислення та передачі, які надають вузли, і органічно поєднуються через ланцюжок блоків, щоб забезпечити носій для роботи додатків на ланцюжку. Простір блоків - це обмежений ресурс, у традиційному блокчейні різні додатки повинні боротися за простір блоків і оплачувати його, а вузли заробляють на цьому.
У AO немає поняття блоку, тому природно немає й поняття “простору блоків”. Проте, подібно до розумних контрактів на інших ланцюгах, кожен процес на AO, коли він працює, також потребує ресурсів. Він потребує вузлів для тимчасового зберігання транзакцій та даних про стан, а також для витрачання обчислювальних ресурсів вузлів для виконання обчислювальних завдань. Повідомлення, які він відправляє, потрібно передавати MU та SU до відповідного процесу.
У AO вузлі розділяються на три типи: CU (обчислювальний блок), MU (блок повідомлень) та SU (блок сортування), причому CU є ядром, що несе обчислювальні завдання. MU та SU несуть завдання зв’язку. Коли процес потребує взаємодії з іншими процесами, він генерує повідомлення, зберігає його в вихідній черзі, CU, який виконує цей процес, підписує це повідомлення, MU вилучає це повідомлення з вихідної черги та передає його SU. SU надає повідомленню унікальний номер та завантажує його в постійне сховище Arweave. Потім MU передає повідомлення у вхідну чергу цільового процесу, завершуючи доставку повідомлення. MU можна розглядати як збирача та доставник повідомлень, а SU - як сортувальника та завантажувача повідомлень.
Що стосується ресурсів зберігання, MU в мережі AO потрібно лише зберігати тимчасові дані, необхідні для обчислень, і викидати їх після завершення обчислень. Відповідальність за постійне зберігання лежить на Arweave, хоча Arweave не може масштабуватися горизонтально, проте максимальна продуктивність його зберігання дуже висока, і потреби мережі AO в зберіганні в наближеному майбутньому ще не зможуть досягти максимальної продуктивності Arweave.
Ми виявили, що обчислювальні ресурси, ресурси передачі та ресурси зберігання в мережі AO є роз’єднаними. Окрім єдиної системи зберігання, яку надає Arweave, обчислювальні ресурси та ресурси передачі можуть бути масштабовані горизонтально окремо, без обмежень.
З кожним доданим вузлом CU з більшою продуктивністю до мережі, мережа матиме більше обчислювальної потужності та зможе підтримувати більше процесів; Аналогічно, з кожним доданим вузлом MU та SU з більшою продуктивністю до мережі, ефективність передачі у мережі буде швидшою. Це означає, що «простір блоків» в AO може безперервно створюватися. Для додатків можна придбати послуги громадських вузлів CU, MU та SU на відкритому ринку, або повністю використовувати власні приватні вузли для обслуговування власних додатків. Якщо додаток розширює свою діяльність, його продуктивність можна покращити шляхом розширення власних вузлів, як це роблять веб-додатки Web2. Це неможливо у традиційній блокчейні.
На рівні ціноутворення ресурсів AO може гнучко регулювати їх за допомогою пропозиції та попиту, що дозволяє ресурсам розширюватися та звужуватися відповідно до потреб. Це регулювання дуже чутливе, приєднання та виходження вузлів може відбуватися дуже швидко. Повернемося до Ethereum, і ми побачимо, що при різкому зростанні потреби в ресурсах нам доводиться терпіти високі витрати на газ, оскільки Ethereum не може покращити свою продуктивність шляхом збільшення кількості вузлів.
Підсумки
Ми розпочинаємо з поняття, якими володіють більшість дослідників криптографії, таких як «Шардинг», «модульність», «Rollup», «блокчейн-простір» та інших, та переходимо до принципів та механізмів AO, щоб допомогти розуміти, як AO здійснює майже необмежене масштабування через революційні інновації.
Тепер, коли ми знову поглянемо на деякі початкові питання, чи ви все ще розумієте?
1. Не PoS, не PoW, що саме означає “голографічна згода”, про яку говорить АО, яка механіка згоди?
Механізм згоди AO насправді є дизайном, що наближений до Op Rollup. На рівні твердої згоди він залежить від Arweave, на рівні програмної згоди кожен процес може самостійно вирішувати силу перевірки та кількість вузлів CU, що займаються зайвими обчисленнями.
- Без ланцюжка хешів, навіть без блоків, як AO забезпечує незмінність даних?
Дані DA, завантажені на Arweave, є незмінними і забезпечують підтвердження обчислень і передач на AO. Сам по собі AO не обмежує об’єм обробки за одиницю часу, тому блок не потрібний. У Arweave є структури, такі як “хеш-ланцюжок” та “блоки”, що забезпечують незмінність даних.
- Без центрального координатора, як AO забезпечує узгодженість стану всієї системи?
Кожен процес є окремим “Шардинг”, який самостійно керує своїми угодами та станом, процес взаємодіє за допомогою повідомлень. Тому не потрібна глобальна консистентність стану. Постійне зберігання Arweave забезпечує глобальну перевірку та здатність до історичного відстеження, разом з оптимістичними методами виклику, що можна використовувати для вирішення суперечок.
4. Відсутність механізму зайвого обчислення, хто гарантує надійність обчислень? Що робити, якщо виникла помилка в обчисленнях?
AO не має глобального примусового механізму зайвого обчислення, кожен процес може самостійно вирішити, як перевірити надійність кожного отриманого повідомлення. Якщо виникла помилка в обчисленні, її можна виявити і виправити у формі оптимістичного виклику.
5. Немає загальної безпеки, як забезпечити взаємодію процесів?
Process потребує самостійного керування кредитними операціями з кожним взаємодіючим процесом і може використовувати різний рівень перевірки для процесів різного рівня безпеки. Для складних взаємодій ланцюжків викликів, щоб уникнути високих витрат на виправлення, пов’язаних з порушенням довіри у ланцюжку, AO може мати мінімальні вимоги до рівня перевірки.
