Структура визначає функцію: порівняльний аналіз AO та Nostr

Розширений8/16/2024, 10:16:39 AM
Як визначаються та обробляються повідомлення в мережах AO та Nostr? Яка їхня архітектура мережі для передачі повідомлень та як вони інтегруються з іншими протоколами? Які їхні відповідні ролі, основні застосування та тенденції розвитку? Ця стаття надає глибоке порівняння протоколів AO та Nostr, зосереджуючись на тому, як їхні структурні конструкції впливають на функціональність, з докладним аналізом цих питань.

На перший погляд порівняння АО — системи ультрапаралельних обчислень — та Ностр — децентралізованого соціального протоколу — може здатися незвичайним, оскільки вони, здається, належать до абсолютно різних сфер. Однак обидва можна розглядати як «протоколи передачі повідомлень», що дозволяє зробити порівняння.

Як протоколи, спрямовані на передачу повідомлень, основним компонентом є, звісно ж, саме "повідомлення". Таким чином, як визначаються повідомлення в мережах AO та Nostr? Яка їхня відповідна мережева архітектура для підтримки передачі повідомлень та як вони інтегруються з іншими протоколами? Яка їхня позиція, основні випадки використання та майбутні тенденції?

Ця стаття спрямована на надання детального порівняння протоколів AO та Nostr, вивчення того, як їх структурні конструкції впливають на їх функціональність та надання докладного аналізу цих аспектів.

1. Концепція та характеристики повідомлень

1.1. Повідомлення в АО

У мережі AO повідомлення є фундаментальною одиницею інформації, яка обмінюється між мережевими одиницями (MU, SU, CU) або процесами. Повідомлення сприяють обміну інформацією та координації.

AO призначений як мережа асинхронного зв'язку, що працює на основі обміну повідомленнями. Спочатку для запуску процесів (наприклад, запуску процесу) AO потребує повідомлень, які можуть надходити від зовнішніх користувачів або інших процесів. Крім того, міжпроцесний зв'язок AO є асинхронним, що означає, що надсилання та отримання повідомлень відбуваються незалежно від відправника та отримувача. Це дозволяє надсилаючому процесу продовжувати свою роботу без очікування відповіді чи підтвердження від отримувача, що значно підвищує ефективність паралельних обчислень в AO.

У AO асинхронна природа передачі повідомлень і відсутність потреби в очікуванні роблять його ідеальним для управління завданнями паралельного обчислення великого масштабу. Це дозволяє різним компонентам системи працювати паралельно без довгих чекань відповідей від інших процесів.

Кожне повідомлення в AO слідує стандарту ANS-104 від екосистеми Arweave, протоколу упакування даних. ANS-104 підвищує пропускну здатність даних шляхом серіалізації кількох транзакцій в одну бінарну транзакцію. Цей протокол не лише упаковує дані, але й включає поля, такі як власник, підпис, цільова адреса, мітка та дані. Цей дизайн підтримує великий спектр типів даних, включаючи документи, зображення, аудіо- та відеофайли, ігри, моделі даних, програмний код та голографічні стани. Крім того, він підтримує власність даних та перевірку підпису, забезпечуючи безпеку та цілісність даних.

Ці функції стандарту ANS-104 є важливими для AO, що дозволяє йому підтримувати різноманітні сценарії застосування для різних типів даних. Стандартизований формат повідомлення значно сприяє ефективній міжпроцесорній комунікації та безшовній співпраці, покращуючи ефективність зберігання та обробки на Arweave. Це дозволяє AO ефективно встановлювати шари доступності даних та консенсус даних, вирішуючи його широкі застосування.

1.2. Події в Nostr

В протоколі Nostr повідомлення структуровані як "події" за допомогою формату на основі JSON. Цей формат служить основним об'єктом даних в мережі Nostr.

Широко використовувані структури повідомлень інтегровані в загальний стандарт, який називається протоколом NIPs (Nostr Implementation Possibilities). Ця стандартизація значно поліпшує обробку та управління даними, підвищуючи міжсистемну сумісність та стабільність. За допомогою NIPs користувачі можуть виконувати різноманітні операції та взаємодії в мережі Nostr без стурбувань щодо неузгодженості формату даних.

JSON-структура в Nostr визначає формат події з різними полями, кожне з яких виконує певну функцію. Наприклад:

  • Поле pubkey: Представляє собою публічний ключ відправника події, який використовується для ідентифікації користувача. Цей публічний ключ підписує подію цифрово, забезпечуючи її автентичність та цілісність.
  • kind Field: Вказує на тип події, такий як чатові повідомлення, інформацію про гаманець або дії користувача, такі як рекомендації списків передач або виконання конкретних операцій.
  • Поле вмісту: Містить вміст події, підтримує різні типи даних, такі як записи у соціальних мережах, статті, аудіо та відео. Це поле дозволяє користувачам передавати інформацію, яку вони хочуть поділитися.
  • Поле sig: Зберігає цифровий підпис події, створений відправником за допомогою їх приватного ключа, та перевірений клієнтом отримувача за допомогою відповідного публічного ключа. Цей підпис підтверджує автентичність та цілісність події.

Для детального опису структури даних події звертайтеся доПротокол Nostr ЗмістПротокол Nostr пропонує чітку структуру для надсилання, отримання та підтвердження подій, забезпечуючи безпеку, послідовність та надійність даних.

У підсумку, подія в Nostr - це структура даних, яка включає будь-який вміст і підписана користувачами. Ця структура відображає роль, функції та функції Nostr:

  • Публікація, зберігання та отримання інформації: Використання Nostr JSON та NIPs забезпечує ефективний обмін та керування даними, гарантуючи консистентність та інтерпретованість, а також надаючи стабільне та надійне середовище для комунікації.
  • Перевірка з боку клієнта: Структура даних дозволяє здійснювати перевірку з боку клієнта, усуваючи потребу в довірі до ретрансляційних серверів або сторонніх осіб та безпосередньо підтверджуючи автентичність та цілісність подій.
  • Децентралізована, стійка до цензури соціальна мережа: дизайн дозволяє Nostr працювати як децентралізована платформа, де користувачі можуть вільно спілкуватися та обмінюватися інформацією без обмежень у зв'язку з цензурою або підмінюванням даних.

2. Структури мережі, що підтримують передачу повідомлень

2.1. AO: Мережа співпраці MU/SU/CU

Мережа AO складається з трьох модульних блоків: MU, SU та CU, які спільно працюють через повідомлення та процеси. Її мережева архітектура показана на рисунку 2-1.


Рисунок 2-1: Модульні та спільні мережеві блоки, що формують архітектуру мережі AO (Джерело: Біла книга AO)

У АО процес є обчислювальною одиницею. Запуск додатку на АО означає ініціювання одного або кількох процесів, при цьому система розподіляє та планує ресурси, такі як МП, СП, ЦП, віртуальні машини та пам'ять для виконання процесу:

  • MU (Messenger Unit): Відповідальний за відправлення інформації на відповідний SU для обробки, а потім доставляє її до CU для обчислень. Результати повертаються SU, і цей процес постійно повторюється.
  • SU (Scheduler Unit): Керує плануванням та сортуванням повідомлень, завантаженням повідомлень на Arweave.
  • CU (Compute Unit): отримує повідомлення, виконує обчислення та реалізує переходи стану.

Структура та операції мережі AO показують:

  • AO як система передачі повідомлень: Повідомлення є основними елементами у процесах AO, служачи єдиною робочою об'єктами для MU, SU та CU. Весь процес обертається навколо повідомлень, роблячи процес фактично діяльністю запуску колекції повідомлень. Це включає повну послідовність від отримання повідомлень, передачі повідомлень, планування та сортування повідомлень, виконання обчислень (переходи стану повідомлень), до виведення та збереження результатів обчислень. Таким чином, AO - це система передачі повідомлень, яка може бути присвячена побудові застосунків, спрямованих на публікацію інформації, реальний часу спілкування та взаємодії, розповсюдження контенту та інше, такі як децентралізовані соціальні мережі, соціальні медіа та децентралізовані аудіо / відео платформи для вимог / прямого ефіру.
  • AO як Ultra-паралельна обчислювальна мережа: AO працює як модульна мережа, де обчислення виконуються поза ланцюжком, вільно від обмежень консенсусу блоків. Це дозволяє обчислювальним одиницям (вузлам) масштабуватися нескінченно за потребою, значно підвищуючи обчислювальну продуктивність. У середовищі AO може бути запущено довільну кількість обчислювальних завдань (паралельних процесів) одночасно. Ці процеси можуть запускатися незалежно на різних обчислювальних вузлах і завершувати локальну перевірку. Це робить AO розподіленою, перевіреною ультра-паралельною обчислювальною системою.

Навіть якщо кожен обчислювальний процес може працювати незалежно на різних вузлах, вони можуть спілкуватися та співпрацювати через уніфікований формат повідомлення (ANS-104). Цей метод з'єднує незалежно працюючі обчислювальні процеси в єдину мережу.

  • AO як відкрита платформа: У своїй основі AO - це інформаційний протокол, який дозволяє різним додаткам, що працюють на Arweave, спілкуватися між собою. Кожен додаток може надсилати інформацію іншим додаткам через мережу AO, використовуючи AO для композиційних операцій і забезпечуючи обмін інформацією між ланцюгами. Мережа AO працює поза ланцюгом і може безшовно з'єднуватися з додатками Web2. Запускаючи інтерфейс протоколу AO, додатки Web2 можуть брати участь у цій децентралізованій мережі. Ця функція дозволяє AO зв'язувати Web2 та Web3 додатки, сприяючи обміну довіреною інформацією та взаємодії між додатками. Дизайн протоколу зв'язку AO робить його відкритою платформою, пропонуючи розробникам нескінченні можливості.

На завершення, мережева архітектура AO підтримує композиційну, взаємодійну, масштабовану, перевірену, децентралізовану та відкриту обчислювальну платформу. Вона підходить для застосувань, спрямованих на публікацію та взаємодію інформації, а також для тих, що потребують високої обчислювальної продуктивності та складної логіки, таких як машинне навчання, автономні агенти, графічне відтворення, онлайн-ігри та DeFi.

2.2. Nostr: Структура клієнт-реле

Nostr означає «Примітки та Інші Речі, Передані Реле». Мережа складається з двох основних компонентів, як показано на рис. 2-2.


Рисунок 2-2: Структура мережі Nostr

  • Клієнт: Це додаток, що працює на стороні користувача, розроблений для зчитування та запису даних на ретранслюючі сервери. Клієнт використовує відкритий ключ як адресу для користувача, щоб надсилати та отримувати події, тоді як приватний ключ використовується для підпису подій при їх надсиланні. Цей процес підпису доводить, що операцію виконав користувач і запобігає підміні. При отриманні подій клієнт використовує приватний ключ для перевірки підпису, забезпечуючи походження та цілісність події.

Клієнт дозволяє користувачам підключатися до будь-якої кількості реле-серверів, розташованих в різних місцях. Користувачі можуть публікувати інформацію на одному реле і отримувати її з іншого. Це означає, що клієнт (користувач) не повинен покладатися на будь-який конкретний реле-сервер, що ефективно захищає дані та дії користувача.

  • Сервер ретрансляції: Сервер ретрансляції має здатність прослуховувати, захоплювати та зберігати події від підключених клієнтів, а потім пересилати ці події передплатленим клієнтам. Будь-хто може запустити сервер ретрансляції, і декілька таких серверів можуть слугувати альтернативами один одному. Цей дизайн зменшує важливість будь-якого окремого ретранслятора, зменшуючи ризик одиничних точок відмов та посилюючи стійкість до цензури. Крім того, конкуренція між декількома ретрансляторами може сприяти покращенню якості обслуговування, наприклад, наданню більшого обсягу сховища, швидших часів реакції та послуг фільтрації спаму.

Сервери ретрансляції можуть вибирати, чи зберігати всі чи частину контенту користувача відповідно до своїх потреб та вирішувати тривалість зберігання даних. Це надає більшу гнучкість у позиціонуванні реле та комерційній діяльності. В той же час реле не потрібно спілкуватися одне з одним, що усуває проблеми узгодження та потребу у синхронізації даних. Замість цього синхронізація даних здійснюється за допомогою відправлення та отримання подій між клієнтами, що фундаментально відрізняється від вузлів блокчейну.

Ця архітектура не лише підвищує гнучкість та ефективність системи, але також ефективно вирішує різноманітні використання та вимоги.

У підсумку, легка структура клієнта-реле Nostr підвищує гнучкість та ефективність системи. Вона підтримує децентралізовану, цензуростійку та перевірену систему публікації інформації, що відповідає потребам у вільному слові, гладкій комунікації, безпеці та конфіденційності даних. Цей дизайн ефективно вирішує недоліки централізованих соціальних мереж, роблячи Nostr популярним вибором для розробників децентралізованих соціальних додатків, таких як Damus, YakiHonne, Iris та інші.

3. Інтеграція з іншими протоколами

3.1 AO + Arweave: Децентралізований світовий комп'ютер

AO функціонує вгорі Arweave, безшовно інтегруючись з ним, як показано на рисунку 3-1.


Рисунок 3-1: Безшовна інтеграція AO з Arweave (Джерело: Біла книга AO)

Це представляє собою застосування парадигми зберігання консенсусу (SCP). Ця нова парадигма ефективно роз'єднує зберігання (консенсус) від обчислення, полегшуючи виконання обчислень поза ланцюжком поруч з консенсусом у ланцюжку. Переваги цього підходу є значними:

  • Високопродуктивні обчислення: завдяки обчисленням розумних контрактів, які відбуваються поза ланцюжком, АО уникне обмежень угоди блоку на ланцюжку. Це значно підвищує обчислювальну продуктивність, роблячи високопродуктивні обчислення реальністю.
  • Ультра-Паралельне Обчислення: Вузли можуть незалежно виконувати паралельні завдання та здійснювати локальні перевірки без необхідності синхронізації всіх вузлів та завершення зайвих обчислень, як це бачимо в традиційних архітектурах EVM. Ця можливість дозволяє AO досягати ультра-паралельного обчислення.
  • Пристосовуваний Обчислення: Arweave пропонує постійне зберігання всіх інструкцій, проміжних станів та результатів обчислень, функціонуючи як шар доступності даних та консенсусу AO. Виконання кожного додатка складно пов'язане з даними, збереженими на Arweave, що дозволяє настроювати його відповідно до конкретних потреб місцевих вузлів. Цей рівень гнучкості перевершує традиційну модель EVM, де вузли повинні виконувати попередньо визначені операції одночасно для забезпечення мережевої консистентності.

В суті, AO підвищує Arweave з ультра-паралельними обчислювальними можливостями, тоді як Arweave забезпечує AO зберіганням як згоди. Разом вони створюють децентралізований світовий комп'ютер, відкриваючи двері до обширних інновацій в децентралізованому просторі.

3.2 Nostr + Lightning: Створення децентралізованих інформаційних та вартісних мереж

Nostr, розроблений fiatjaf, природно підтримує мережу Lightning завдяки участі fiatjaf у його розробці. Мережа Lightning, другорядне рішення для Bitcoin, розширює функціональність блокчейну поза ланцюгом через канали. Це ефективно вирішує проблеми повільності транзакцій Bitcoin, обмеженої пропускної здатності та високих витрат на транзакції, дозволяючи часті та недорогі мікроплатежі.

Пряме застосування інтеграції Nostr та Lightning Network полягає в реалізації "запів" в соціальних додатках. Широко використовуваний клієнт Nostr, Damus, включає платежі через Bitcoin Lightning Network, що дозволяє користувачам легко здійснювати одноразовий платіж за ретрансляцію Lightning Network, вводячи публічний ключ Nostr. Після оплати користувачі отримують рахунок Lightning Network. Для детального огляду відвідайте:https://nostr.how/zh/zaps.

Щодо емісії активів, протокол Taproot Assets (TAP) рівня один Bitcoin сумісний з мережею Lightning, що дозволяє інтегрувати активи Taproot та найменшу одиницю Bitcoin, Сатоші, в екосистему Nostr. Це сприяє миттєвим та вигідним передачам активів через мережу Lightning, збагачуючи різноманіття активів Nostr та розширюючи можливості для соціальних мереж, платежів та додатків DeFi.

Крім того, члени спільноти CKB запропонували протокол зв'язування Nostr, використовуючи технологію RGB ++ для досягнення ізоморфного зв'язування подій Nostr з CKB CELLS. Це дозволяє користувачам створювати та розповсюджувати власні активи в мережі Nostr, ефективно вирішуючи проблеми місцевих платежів у соціальних мережах.

Ключовим є синергія між Nostr та Lightning Network, яка відкриває нову бізнес-модель для децентралізованих додатків, відому як Value for Value (V4V).

Концепція V4V стверджує, що монетизація не-складної інформації є складним завданням. Традиційна онлайн-монетизація часто ґрунтується на рекламі, яка залежить від централізованого моніторингу та аналізу поведінки користувачів. V4V надає альтернативу, дозволяючи вільний потік інформації та вартості без посередників чи обмежень. Цей підхід не лише пропонує новий спосіб монетизації цифрового контенту, але й вводить нові методи для створення контенту та передачі вартості.

Рішення V4V додають значну вартість до соціальних додатків на основі Nostr, подкастів та платформ прямого ефіру, таких як:

  • YakiHonne: Децентралізований протокол взаємодії з медіа, що інтегрує Nostr з мережею Lightning, використовуючи SATS для чайових. Щорічні платежі перевищили 90 мільйонів SATS.
  • Nostrwatch.live: Децентралізована платформа для прямого ефіру, яка працює на Nostr та мережі Lightning, встановлюючи "Вартість за вартість" обмін у дві сторони. Стрімери отримують платежі SATs в реальному часі від глядачів, і стрім припиняється, якщо платежі припиняються. Це відрізняється від традиційних моделей передоплати, усуваючи потребу в підписці або передоплаті.
  • Podverse: Додаток для подкастінгу 2.0, який інтегрується з Alby, використовуючи мережу Lightning для надсилання boostagrams (повідомлення з пожертвами) та платежів SAT для подкастів. Додаток стрімить сатоші до прослуховуваного подкасту на основі часу прослуховування за хвилину.

Інтеграція Nostr-Lightning трансформує Nostr з децентралізованої інформаційної мережі в ту, яка поєднує в собі інформацію та цінність. Цей зсув не тільки забезпечує індивідуальну свободу слова, але й гарантує безпеку особистих активів, роблячи її засобом обміну цінностями. Ця еволюція відкриває нові можливості для масштабованих та споживчих застосувань, що потенційно можуть запропонувати життєздатний шлях до широкого прийняття Web3.

4. Висновок: Структура визначає функцію

Ця стаття проаналізувала і порівняла протоколи AO та Nostr з погляду структури даних та мережевої структури, дотримуючись принципу "структура визначає функцію". Ми дослідили основні функції та сценарії застосування кожного протоколу:

З погляду структури даних: AO та Nostr обидва служать протоколами передачі інформації, що підтримують різноманітні типи даних для публікації, комунікації та поширення. Вони дозволяють створення децентралізованих соціальних мереж та медіа-застосунків з такими функціями, як децентралізація, опір цензурі, перевірка підпису та захист конфіденційності.

Проте є ключові відмінності. Фокус Nostr спрямований на додатки, спеціально розроблені для передачі інформації, яка є лише підмножиною більш широких функціональних та застосункових можливостей AO. AO підкреслює ультра-паралельне обчислення, охоплюючи ширший і глибший спектр застосунків.

З погляду структури мережі: мережева структура AO є модульною, співпрацюючою та масштабованою, що дозволяє процесам працювати незалежно на різних вузлах та виконувати локальну перевірку. Ці характеристики створюють основу для ультра-паралельних обчислень.

AO's безшовна інтеграція з Arweave, заснована на парадигмі SCP, подолує трилему технології блокчейну. Вона масштабує зберігання та обчислювальні ресурси за потребою та використовує постійні, захищені власністю дані Arweave для обміну інформацією між процесами та співпраці. Внаслідок цього AO може побудувати глобальну, високопродуктивну, ультра-паралельну обчислювальну мережу, що сприяє інноваціям як у веб-програмах 3, так і у веб-програмах 2.

Наприклад, AO підтримує застосунки машинного навчання, які потребують великих мовних моделей (LLM) та інтенсивного обчислення; застосунки AgentFi з складною бізнес-логікою, попередньо визначеними потребами та різноманітними автономними стратегіями; ContentFi для управління авторськими правами та монетизації контенту; та децентралізовані застосунки, які потребують міжланцюжкової комунікації, передачі активів, обміну даними та взаємодії з розумними контрактами.

Навпаки, структура мережі Nostr, яка складається головним чином з компонентів Клієнт-Реле та структур даних Подій з системами публічних та приватних ключів, створює легку інформаційну мережу. У поєднанні з Lightning вона інтегрує характеристики децентралізованої інформаційної та вартісної мережі, роблячи її ідеальною для масштабованих застосунків для споживачів.

З позиції протоколу: Незважаючи на те, що обидва протоколи AO та Nostr є протоколами передачі повідомлень, їх фокус та позиціонування розходяться. AO спрямований на створення основної інфраструктури для "децентралізованого комп'ютера", спрямовуючись на нижні шари, але надаючи широкі можливості застосування та захоплюючи більш широку вартість.

Навпаки, Nostr спочатку був розроблений як легкий децентралізований соціальний протокол, зосереджений на соціальних застосунках.

У підсумку, AO та Nostr пропонують відмінні особливості та переваги в структурі даних, мережевій структурі та функціоналі протоколу, кожен з власною позицією та сферами застосування. Їх унікальні характеристики проявляться в їх відповідних розвиткових траєкторіях.

Посилання

  1. Чи є AO вбивцею Ethereum і як воно буде впливати на нову блокчейн-повість?
  2. AO Protocol: Децентралізований, бездозвільний суперкомп'ютер
  3. Протокол Nostr
  4. Протокол зв'язку Nostr
  5. Value4Value
  6. Децентралізований соціальний протокол Nostr та його інноваційні застосування

Відмова від відповідальності:

  1. Ця стаття перепечатана з [web3caff]. Усі авторські права належать оригінальному автору [Танцювальна зміна]. Якщо є заперечення до цього повторення, будь ласка, зв'яжіться з Gate Learnкоманда, і вони оперативно займуться цим.
  2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно тими автора і не становлять жодних інвестиційних порад.
  3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіатування перекладених статей заборонені.

Структура визначає функцію: порівняльний аналіз AO та Nostr

Розширений8/16/2024, 10:16:39 AM
Як визначаються та обробляються повідомлення в мережах AO та Nostr? Яка їхня архітектура мережі для передачі повідомлень та як вони інтегруються з іншими протоколами? Які їхні відповідні ролі, основні застосування та тенденції розвитку? Ця стаття надає глибоке порівняння протоколів AO та Nostr, зосереджуючись на тому, як їхні структурні конструкції впливають на функціональність, з докладним аналізом цих питань.

На перший погляд порівняння АО — системи ультрапаралельних обчислень — та Ностр — децентралізованого соціального протоколу — може здатися незвичайним, оскільки вони, здається, належать до абсолютно різних сфер. Однак обидва можна розглядати як «протоколи передачі повідомлень», що дозволяє зробити порівняння.

Як протоколи, спрямовані на передачу повідомлень, основним компонентом є, звісно ж, саме "повідомлення". Таким чином, як визначаються повідомлення в мережах AO та Nostr? Яка їхня відповідна мережева архітектура для підтримки передачі повідомлень та як вони інтегруються з іншими протоколами? Яка їхня позиція, основні випадки використання та майбутні тенденції?

Ця стаття спрямована на надання детального порівняння протоколів AO та Nostr, вивчення того, як їх структурні конструкції впливають на їх функціональність та надання докладного аналізу цих аспектів.

1. Концепція та характеристики повідомлень

1.1. Повідомлення в АО

У мережі AO повідомлення є фундаментальною одиницею інформації, яка обмінюється між мережевими одиницями (MU, SU, CU) або процесами. Повідомлення сприяють обміну інформацією та координації.

AO призначений як мережа асинхронного зв'язку, що працює на основі обміну повідомленнями. Спочатку для запуску процесів (наприклад, запуску процесу) AO потребує повідомлень, які можуть надходити від зовнішніх користувачів або інших процесів. Крім того, міжпроцесний зв'язок AO є асинхронним, що означає, що надсилання та отримання повідомлень відбуваються незалежно від відправника та отримувача. Це дозволяє надсилаючому процесу продовжувати свою роботу без очікування відповіді чи підтвердження від отримувача, що значно підвищує ефективність паралельних обчислень в AO.

У AO асинхронна природа передачі повідомлень і відсутність потреби в очікуванні роблять його ідеальним для управління завданнями паралельного обчислення великого масштабу. Це дозволяє різним компонентам системи працювати паралельно без довгих чекань відповідей від інших процесів.

Кожне повідомлення в AO слідує стандарту ANS-104 від екосистеми Arweave, протоколу упакування даних. ANS-104 підвищує пропускну здатність даних шляхом серіалізації кількох транзакцій в одну бінарну транзакцію. Цей протокол не лише упаковує дані, але й включає поля, такі як власник, підпис, цільова адреса, мітка та дані. Цей дизайн підтримує великий спектр типів даних, включаючи документи, зображення, аудіо- та відеофайли, ігри, моделі даних, програмний код та голографічні стани. Крім того, він підтримує власність даних та перевірку підпису, забезпечуючи безпеку та цілісність даних.

Ці функції стандарту ANS-104 є важливими для AO, що дозволяє йому підтримувати різноманітні сценарії застосування для різних типів даних. Стандартизований формат повідомлення значно сприяє ефективній міжпроцесорній комунікації та безшовній співпраці, покращуючи ефективність зберігання та обробки на Arweave. Це дозволяє AO ефективно встановлювати шари доступності даних та консенсус даних, вирішуючи його широкі застосування.

1.2. Події в Nostr

В протоколі Nostr повідомлення структуровані як "події" за допомогою формату на основі JSON. Цей формат служить основним об'єктом даних в мережі Nostr.

Широко використовувані структури повідомлень інтегровані в загальний стандарт, який називається протоколом NIPs (Nostr Implementation Possibilities). Ця стандартизація значно поліпшує обробку та управління даними, підвищуючи міжсистемну сумісність та стабільність. За допомогою NIPs користувачі можуть виконувати різноманітні операції та взаємодії в мережі Nostr без стурбувань щодо неузгодженості формату даних.

JSON-структура в Nostr визначає формат події з різними полями, кожне з яких виконує певну функцію. Наприклад:

  • Поле pubkey: Представляє собою публічний ключ відправника події, який використовується для ідентифікації користувача. Цей публічний ключ підписує подію цифрово, забезпечуючи її автентичність та цілісність.
  • kind Field: Вказує на тип події, такий як чатові повідомлення, інформацію про гаманець або дії користувача, такі як рекомендації списків передач або виконання конкретних операцій.
  • Поле вмісту: Містить вміст події, підтримує різні типи даних, такі як записи у соціальних мережах, статті, аудіо та відео. Це поле дозволяє користувачам передавати інформацію, яку вони хочуть поділитися.
  • Поле sig: Зберігає цифровий підпис події, створений відправником за допомогою їх приватного ключа, та перевірений клієнтом отримувача за допомогою відповідного публічного ключа. Цей підпис підтверджує автентичність та цілісність події.

Для детального опису структури даних події звертайтеся доПротокол Nostr ЗмістПротокол Nostr пропонує чітку структуру для надсилання, отримання та підтвердження подій, забезпечуючи безпеку, послідовність та надійність даних.

У підсумку, подія в Nostr - це структура даних, яка включає будь-який вміст і підписана користувачами. Ця структура відображає роль, функції та функції Nostr:

  • Публікація, зберігання та отримання інформації: Використання Nostr JSON та NIPs забезпечує ефективний обмін та керування даними, гарантуючи консистентність та інтерпретованість, а також надаючи стабільне та надійне середовище для комунікації.
  • Перевірка з боку клієнта: Структура даних дозволяє здійснювати перевірку з боку клієнта, усуваючи потребу в довірі до ретрансляційних серверів або сторонніх осіб та безпосередньо підтверджуючи автентичність та цілісність подій.
  • Децентралізована, стійка до цензури соціальна мережа: дизайн дозволяє Nostr працювати як децентралізована платформа, де користувачі можуть вільно спілкуватися та обмінюватися інформацією без обмежень у зв'язку з цензурою або підмінюванням даних.

2. Структури мережі, що підтримують передачу повідомлень

2.1. AO: Мережа співпраці MU/SU/CU

Мережа AO складається з трьох модульних блоків: MU, SU та CU, які спільно працюють через повідомлення та процеси. Її мережева архітектура показана на рисунку 2-1.


Рисунок 2-1: Модульні та спільні мережеві блоки, що формують архітектуру мережі AO (Джерело: Біла книга AO)

У АО процес є обчислювальною одиницею. Запуск додатку на АО означає ініціювання одного або кількох процесів, при цьому система розподіляє та планує ресурси, такі як МП, СП, ЦП, віртуальні машини та пам'ять для виконання процесу:

  • MU (Messenger Unit): Відповідальний за відправлення інформації на відповідний SU для обробки, а потім доставляє її до CU для обчислень. Результати повертаються SU, і цей процес постійно повторюється.
  • SU (Scheduler Unit): Керує плануванням та сортуванням повідомлень, завантаженням повідомлень на Arweave.
  • CU (Compute Unit): отримує повідомлення, виконує обчислення та реалізує переходи стану.

Структура та операції мережі AO показують:

  • AO як система передачі повідомлень: Повідомлення є основними елементами у процесах AO, служачи єдиною робочою об'єктами для MU, SU та CU. Весь процес обертається навколо повідомлень, роблячи процес фактично діяльністю запуску колекції повідомлень. Це включає повну послідовність від отримання повідомлень, передачі повідомлень, планування та сортування повідомлень, виконання обчислень (переходи стану повідомлень), до виведення та збереження результатів обчислень. Таким чином, AO - це система передачі повідомлень, яка може бути присвячена побудові застосунків, спрямованих на публікацію інформації, реальний часу спілкування та взаємодії, розповсюдження контенту та інше, такі як децентралізовані соціальні мережі, соціальні медіа та децентралізовані аудіо / відео платформи для вимог / прямого ефіру.
  • AO як Ultra-паралельна обчислювальна мережа: AO працює як модульна мережа, де обчислення виконуються поза ланцюжком, вільно від обмежень консенсусу блоків. Це дозволяє обчислювальним одиницям (вузлам) масштабуватися нескінченно за потребою, значно підвищуючи обчислювальну продуктивність. У середовищі AO може бути запущено довільну кількість обчислювальних завдань (паралельних процесів) одночасно. Ці процеси можуть запускатися незалежно на різних обчислювальних вузлах і завершувати локальну перевірку. Це робить AO розподіленою, перевіреною ультра-паралельною обчислювальною системою.

Навіть якщо кожен обчислювальний процес може працювати незалежно на різних вузлах, вони можуть спілкуватися та співпрацювати через уніфікований формат повідомлення (ANS-104). Цей метод з'єднує незалежно працюючі обчислювальні процеси в єдину мережу.

  • AO як відкрита платформа: У своїй основі AO - це інформаційний протокол, який дозволяє різним додаткам, що працюють на Arweave, спілкуватися між собою. Кожен додаток може надсилати інформацію іншим додаткам через мережу AO, використовуючи AO для композиційних операцій і забезпечуючи обмін інформацією між ланцюгами. Мережа AO працює поза ланцюгом і може безшовно з'єднуватися з додатками Web2. Запускаючи інтерфейс протоколу AO, додатки Web2 можуть брати участь у цій децентралізованій мережі. Ця функція дозволяє AO зв'язувати Web2 та Web3 додатки, сприяючи обміну довіреною інформацією та взаємодії між додатками. Дизайн протоколу зв'язку AO робить його відкритою платформою, пропонуючи розробникам нескінченні можливості.

На завершення, мережева архітектура AO підтримує композиційну, взаємодійну, масштабовану, перевірену, децентралізовану та відкриту обчислювальну платформу. Вона підходить для застосувань, спрямованих на публікацію та взаємодію інформації, а також для тих, що потребують високої обчислювальної продуктивності та складної логіки, таких як машинне навчання, автономні агенти, графічне відтворення, онлайн-ігри та DeFi.

2.2. Nostr: Структура клієнт-реле

Nostr означає «Примітки та Інші Речі, Передані Реле». Мережа складається з двох основних компонентів, як показано на рис. 2-2.


Рисунок 2-2: Структура мережі Nostr

  • Клієнт: Це додаток, що працює на стороні користувача, розроблений для зчитування та запису даних на ретранслюючі сервери. Клієнт використовує відкритий ключ як адресу для користувача, щоб надсилати та отримувати події, тоді як приватний ключ використовується для підпису подій при їх надсиланні. Цей процес підпису доводить, що операцію виконав користувач і запобігає підміні. При отриманні подій клієнт використовує приватний ключ для перевірки підпису, забезпечуючи походження та цілісність події.

Клієнт дозволяє користувачам підключатися до будь-якої кількості реле-серверів, розташованих в різних місцях. Користувачі можуть публікувати інформацію на одному реле і отримувати її з іншого. Це означає, що клієнт (користувач) не повинен покладатися на будь-який конкретний реле-сервер, що ефективно захищає дані та дії користувача.

  • Сервер ретрансляції: Сервер ретрансляції має здатність прослуховувати, захоплювати та зберігати події від підключених клієнтів, а потім пересилати ці події передплатленим клієнтам. Будь-хто може запустити сервер ретрансляції, і декілька таких серверів можуть слугувати альтернативами один одному. Цей дизайн зменшує важливість будь-якого окремого ретранслятора, зменшуючи ризик одиничних точок відмов та посилюючи стійкість до цензури. Крім того, конкуренція між декількома ретрансляторами може сприяти покращенню якості обслуговування, наприклад, наданню більшого обсягу сховища, швидших часів реакції та послуг фільтрації спаму.

Сервери ретрансляції можуть вибирати, чи зберігати всі чи частину контенту користувача відповідно до своїх потреб та вирішувати тривалість зберігання даних. Це надає більшу гнучкість у позиціонуванні реле та комерційній діяльності. В той же час реле не потрібно спілкуватися одне з одним, що усуває проблеми узгодження та потребу у синхронізації даних. Замість цього синхронізація даних здійснюється за допомогою відправлення та отримання подій між клієнтами, що фундаментально відрізняється від вузлів блокчейну.

Ця архітектура не лише підвищує гнучкість та ефективність системи, але також ефективно вирішує різноманітні використання та вимоги.

У підсумку, легка структура клієнта-реле Nostr підвищує гнучкість та ефективність системи. Вона підтримує децентралізовану, цензуростійку та перевірену систему публікації інформації, що відповідає потребам у вільному слові, гладкій комунікації, безпеці та конфіденційності даних. Цей дизайн ефективно вирішує недоліки централізованих соціальних мереж, роблячи Nostr популярним вибором для розробників децентралізованих соціальних додатків, таких як Damus, YakiHonne, Iris та інші.

3. Інтеграція з іншими протоколами

3.1 AO + Arweave: Децентралізований світовий комп'ютер

AO функціонує вгорі Arweave, безшовно інтегруючись з ним, як показано на рисунку 3-1.


Рисунок 3-1: Безшовна інтеграція AO з Arweave (Джерело: Біла книга AO)

Це представляє собою застосування парадигми зберігання консенсусу (SCP). Ця нова парадигма ефективно роз'єднує зберігання (консенсус) від обчислення, полегшуючи виконання обчислень поза ланцюжком поруч з консенсусом у ланцюжку. Переваги цього підходу є значними:

  • Високопродуктивні обчислення: завдяки обчисленням розумних контрактів, які відбуваються поза ланцюжком, АО уникне обмежень угоди блоку на ланцюжку. Це значно підвищує обчислювальну продуктивність, роблячи високопродуктивні обчислення реальністю.
  • Ультра-Паралельне Обчислення: Вузли можуть незалежно виконувати паралельні завдання та здійснювати локальні перевірки без необхідності синхронізації всіх вузлів та завершення зайвих обчислень, як це бачимо в традиційних архітектурах EVM. Ця можливість дозволяє AO досягати ультра-паралельного обчислення.
  • Пристосовуваний Обчислення: Arweave пропонує постійне зберігання всіх інструкцій, проміжних станів та результатів обчислень, функціонуючи як шар доступності даних та консенсусу AO. Виконання кожного додатка складно пов'язане з даними, збереженими на Arweave, що дозволяє настроювати його відповідно до конкретних потреб місцевих вузлів. Цей рівень гнучкості перевершує традиційну модель EVM, де вузли повинні виконувати попередньо визначені операції одночасно для забезпечення мережевої консистентності.

В суті, AO підвищує Arweave з ультра-паралельними обчислювальними можливостями, тоді як Arweave забезпечує AO зберіганням як згоди. Разом вони створюють децентралізований світовий комп'ютер, відкриваючи двері до обширних інновацій в децентралізованому просторі.

3.2 Nostr + Lightning: Створення децентралізованих інформаційних та вартісних мереж

Nostr, розроблений fiatjaf, природно підтримує мережу Lightning завдяки участі fiatjaf у його розробці. Мережа Lightning, другорядне рішення для Bitcoin, розширює функціональність блокчейну поза ланцюгом через канали. Це ефективно вирішує проблеми повільності транзакцій Bitcoin, обмеженої пропускної здатності та високих витрат на транзакції, дозволяючи часті та недорогі мікроплатежі.

Пряме застосування інтеграції Nostr та Lightning Network полягає в реалізації "запів" в соціальних додатках. Широко використовуваний клієнт Nostr, Damus, включає платежі через Bitcoin Lightning Network, що дозволяє користувачам легко здійснювати одноразовий платіж за ретрансляцію Lightning Network, вводячи публічний ключ Nostr. Після оплати користувачі отримують рахунок Lightning Network. Для детального огляду відвідайте:https://nostr.how/zh/zaps.

Щодо емісії активів, протокол Taproot Assets (TAP) рівня один Bitcoin сумісний з мережею Lightning, що дозволяє інтегрувати активи Taproot та найменшу одиницю Bitcoin, Сатоші, в екосистему Nostr. Це сприяє миттєвим та вигідним передачам активів через мережу Lightning, збагачуючи різноманіття активів Nostr та розширюючи можливості для соціальних мереж, платежів та додатків DeFi.

Крім того, члени спільноти CKB запропонували протокол зв'язування Nostr, використовуючи технологію RGB ++ для досягнення ізоморфного зв'язування подій Nostr з CKB CELLS. Це дозволяє користувачам створювати та розповсюджувати власні активи в мережі Nostr, ефективно вирішуючи проблеми місцевих платежів у соціальних мережах.

Ключовим є синергія між Nostr та Lightning Network, яка відкриває нову бізнес-модель для децентралізованих додатків, відому як Value for Value (V4V).

Концепція V4V стверджує, що монетизація не-складної інформації є складним завданням. Традиційна онлайн-монетизація часто ґрунтується на рекламі, яка залежить від централізованого моніторингу та аналізу поведінки користувачів. V4V надає альтернативу, дозволяючи вільний потік інформації та вартості без посередників чи обмежень. Цей підхід не лише пропонує новий спосіб монетизації цифрового контенту, але й вводить нові методи для створення контенту та передачі вартості.

Рішення V4V додають значну вартість до соціальних додатків на основі Nostr, подкастів та платформ прямого ефіру, таких як:

  • YakiHonne: Децентралізований протокол взаємодії з медіа, що інтегрує Nostr з мережею Lightning, використовуючи SATS для чайових. Щорічні платежі перевищили 90 мільйонів SATS.
  • Nostrwatch.live: Децентралізована платформа для прямого ефіру, яка працює на Nostr та мережі Lightning, встановлюючи "Вартість за вартість" обмін у дві сторони. Стрімери отримують платежі SATs в реальному часі від глядачів, і стрім припиняється, якщо платежі припиняються. Це відрізняється від традиційних моделей передоплати, усуваючи потребу в підписці або передоплаті.
  • Podverse: Додаток для подкастінгу 2.0, який інтегрується з Alby, використовуючи мережу Lightning для надсилання boostagrams (повідомлення з пожертвами) та платежів SAT для подкастів. Додаток стрімить сатоші до прослуховуваного подкасту на основі часу прослуховування за хвилину.

Інтеграція Nostr-Lightning трансформує Nostr з децентралізованої інформаційної мережі в ту, яка поєднує в собі інформацію та цінність. Цей зсув не тільки забезпечує індивідуальну свободу слова, але й гарантує безпеку особистих активів, роблячи її засобом обміну цінностями. Ця еволюція відкриває нові можливості для масштабованих та споживчих застосувань, що потенційно можуть запропонувати життєздатний шлях до широкого прийняття Web3.

4. Висновок: Структура визначає функцію

Ця стаття проаналізувала і порівняла протоколи AO та Nostr з погляду структури даних та мережевої структури, дотримуючись принципу "структура визначає функцію". Ми дослідили основні функції та сценарії застосування кожного протоколу:

З погляду структури даних: AO та Nostr обидва служать протоколами передачі інформації, що підтримують різноманітні типи даних для публікації, комунікації та поширення. Вони дозволяють створення децентралізованих соціальних мереж та медіа-застосунків з такими функціями, як децентралізація, опір цензурі, перевірка підпису та захист конфіденційності.

Проте є ключові відмінності. Фокус Nostr спрямований на додатки, спеціально розроблені для передачі інформації, яка є лише підмножиною більш широких функціональних та застосункових можливостей AO. AO підкреслює ультра-паралельне обчислення, охоплюючи ширший і глибший спектр застосунків.

З погляду структури мережі: мережева структура AO є модульною, співпрацюючою та масштабованою, що дозволяє процесам працювати незалежно на різних вузлах та виконувати локальну перевірку. Ці характеристики створюють основу для ультра-паралельних обчислень.

AO's безшовна інтеграція з Arweave, заснована на парадигмі SCP, подолує трилему технології блокчейну. Вона масштабує зберігання та обчислювальні ресурси за потребою та використовує постійні, захищені власністю дані Arweave для обміну інформацією між процесами та співпраці. Внаслідок цього AO може побудувати глобальну, високопродуктивну, ультра-паралельну обчислювальну мережу, що сприяє інноваціям як у веб-програмах 3, так і у веб-програмах 2.

Наприклад, AO підтримує застосунки машинного навчання, які потребують великих мовних моделей (LLM) та інтенсивного обчислення; застосунки AgentFi з складною бізнес-логікою, попередньо визначеними потребами та різноманітними автономними стратегіями; ContentFi для управління авторськими правами та монетизації контенту; та децентралізовані застосунки, які потребують міжланцюжкової комунікації, передачі активів, обміну даними та взаємодії з розумними контрактами.

Навпаки, структура мережі Nostr, яка складається головним чином з компонентів Клієнт-Реле та структур даних Подій з системами публічних та приватних ключів, створює легку інформаційну мережу. У поєднанні з Lightning вона інтегрує характеристики децентралізованої інформаційної та вартісної мережі, роблячи її ідеальною для масштабованих застосунків для споживачів.

З позиції протоколу: Незважаючи на те, що обидва протоколи AO та Nostr є протоколами передачі повідомлень, їх фокус та позиціонування розходяться. AO спрямований на створення основної інфраструктури для "децентралізованого комп'ютера", спрямовуючись на нижні шари, але надаючи широкі можливості застосування та захоплюючи більш широку вартість.

Навпаки, Nostr спочатку був розроблений як легкий децентралізований соціальний протокол, зосереджений на соціальних застосунках.

У підсумку, AO та Nostr пропонують відмінні особливості та переваги в структурі даних, мережевій структурі та функціоналі протоколу, кожен з власною позицією та сферами застосування. Їх унікальні характеристики проявляться в їх відповідних розвиткових траєкторіях.

Посилання

  1. Чи є AO вбивцею Ethereum і як воно буде впливати на нову блокчейн-повість?
  2. AO Protocol: Децентралізований, бездозвільний суперкомп'ютер
  3. Протокол Nostr
  4. Протокол зв'язку Nostr
  5. Value4Value
  6. Децентралізований соціальний протокол Nostr та його інноваційні застосування

Відмова від відповідальності:

  1. Ця стаття перепечатана з [web3caff]. Усі авторські права належать оригінальному автору [Танцювальна зміна]. Якщо є заперечення до цього повторення, будь ласка, зв'яжіться з Gate Learnкоманда, і вони оперативно займуться цим.
  2. Відповідальність за відмову: Погляди та думки, висловлені в цій статті, є виключно тими автора і не становлять жодних інвестиційних порад.
  3. Переклади статті на інші мови виконуються командою Gate Learn. Якщо не зазначено інше, копіювання, поширення або плагіатування перекладених статей заборонені.
Bắt đầu giao dịch
Đăng ký và giao dịch để nhận phần thưởng USDTEST trị giá
$100
$5500