HyperspaceAI: Децентралізована революція в штучному інтелекті та блокчейні

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

Уряд США нещодавно видав виконавчий наказ, спрямований на регулювання великих мовних моделей та ширшої сфери штучного інтелекту (AI). Хоча наміри можуть бути спрямовані на підтримання безпеки та національних інтересів, цей документ політики випадково накладає значні обмеження на інновації, з далекосяжними наслідками, що впливають на весь цифровий світ. Оскільки визначення AI розширюється до своїх найширших меж, практично будь-яка онлайн-система рекомендацій – від пошукової системи Google до ресторанних рекомендацій Yelp – потрапляє під дію цих нових правил. Найбільше це впливає на проєкти з відкритим кодом, які стикаються з суворими обмеженнями, особливо ті, що мають моделі з кількістю параметрів понад 10 мільярдів. Це обмежувальне середовище загрожує придушенням менших гравців, одночасно надаючи переваги тим, хто має ресурси для навігації в складному середовищі відповідності вимогам, що є класичним прикладом регуляторного захоплення.

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

У відповідь на ці жорсткі правила ми представляємо "HyperspaceAI", відкритий стандартний протокол, призначений для децентралізованого виконання моделей. Як затяті прихильники децентралізації, ми прагнемо просувати справжні приклади використання бездовірчих протоколів. Поточне регуляторне середовище створює вагомий аргумент, що блокчейни та децентралізовані системи можуть потенційно замінити "ще не встановлені" правила. HyperspaceAI відстоює децентралізацію, забезпечуючи, що потужність AI залишається розподіленою і не концентрується серед обраних. Завдяки HyperspaceAI ми пропонуємо уявлення про майбутнє, де AI демократизований і не обмежений невірними політичними рішеннями.

Як працює HyperspaceAI?

HyperspaceAI побудовано на основі peer-to-peer (P2P) архітектури, яка включає понад 20 000 вузлів. Кожен із цих вузлів завантажує одну з моделей, наприклад, Mistral або Gemma, та бере участь у розподіленій обробці запитів на виконання моделей. Ця система працює подібно до сервісів, таких як Uber, циклічно вибираючи доступні вузли для найкращого виконання запитів.

Кожен вузол має унікальний криптографічний ключ, що забезпечує безпечне спілкування та запобігає таким атакам, як Sybil та Eclipse. Вузли повинні пройти криптографічний пазл для підтвердження своєї ідентичності, що підвищує загальний рівень безпеки мережі.

Hyperspace Protocol Design: Технічні аспекти

Мережа HyperspaceAI використовує децентралізовану систему ідентифікації та перевірки вузлів. Кожен вузол має унікальний NodeAddress, який представляє собою хеш криптографічного ключа. Це дозволяє уникнути ризиків, пов’язаних із Sybil та Eclipse атаками, та забезпечує безпеку системи без потреби у централізованому довіреному органі.

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

Економічна модель та інфраструктура HyperspaceAI

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

Механізм протидії шахрайству та модель викликів

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

1. Вступ

1.1 Розподілені хеш-таблиці

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

1.1.1 Kademlia DHT

Kademlia (Маймунков, Петар і Мазьєр, Давид, 2002) – це протокол розподіленої хеш-таблиці (DHT), що забезпечує децентралізований спосіб зберігання та отримання даних через мережу однорангових вузлів.

• Розподілена хеш-таблиця (DHT): Забезпечує децентралізоване зберігання та отримання даних.
• Метрика XOR: Використовується як міра відстані для ефективної маршрутизації.
• Пошук вузлів: Вузли знаходять один одного на основі їх ідентифікаторів для швидкого отримання даних.
• Списки корзин: Вузли підтримують списки однорангових вузлів у "корзинах" на основі відстані.
• P2P застосування: Основа для багатьох однорангових мереж, включаючи DHT систему BitTorrent.

1.1.2 S/Kademlia

S/Kademlia (Баумгарт, Інгмар і Мієс, Себастьян, 2007) – це розширення протоколу Kademlia, розроблене для забезпечення підвищеної безпеки.

• Підвищена безпека: Спеціально розроблений для покращення стійкості Kademlia до атак Sybil та Eclipse.
• Генерація ID вузла: Включає криптографічні головоломки для ускладнення генерації ID.
• Інфраструктура відкритих ключів: Кожен вузол має пару публічного та приватного ключів, що ускладнює підробку ідентичності.
• Пошук вузлів: Забезпечує взаємодію вузлів з надійними одноранговими вузлами, використовуючи підписані повідомлення.
• Механізм оновлення: Регулярно змінює ID вузлів для протидії довготривалим атакам Sybil.
• Оновлення корзин: Зобов'язує регулярне оновлення корзин для захисту від атак Eclipse.

1.1.3 Suzaku та Kirin

Наше дослідження було вражене досягненнями у розподілених двосторонніх зв'язаних списках і розподіленій хеш-таблиці Suzaku (DHT) у відношенні стійкості до змін у мережі (CHURN). Особливо виділяється здатність забезпечувати живучість без необхідності блокування, зберігаючи при цьому цілісність і узгодженість DHT.

• Новітня структура мережі з порядком ключів, оптимізована для ефективних запитів по діапазону.
• На відміну від Chord# (Стоїка, Іон та ін.), Suzaku має двосторонню таблицю пальців, що дозволяє досягти максимум [log2 n] − 1 переходів при пошуку після конвергенції.
• Алгоритми Suzaku обробляють вставку та видалення вузлів, зберігаючи сильну продуктивність пошуку навіть під час змін у мережі.

1.2 Рівновага обміну обчисленнями

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

Обираючи шлях, подібний до BitTorrent, ми цитуємо Брама Коена (Cohen, Bram, 2003): "Стимул створює стійкість".

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

Існує потенційна можливість дослідити рівновагу, засновану на взаємності, подібно до стратегії "око за око" у BitTorrent. Альтернативно, ми розглядаємо рамкову структуру, в якій обчислювальні ресурси надаються за легітимною вартістю, динамічно визначеною мережею. Цей підхід потребує складного моделювання та прогнозного аналізу, що відповідає обчислювальним характеристикам HyperspaceAI.

2. Дизайн Протоколу Hyperspace

Модель передбачає асинхронну розподілену систему. В цій системі вузли з'єднані через сервери спільноти Hyperspace (HCS). Визнано, що ця мережа може мати певні неефективності: вона може не доставляти повідомлення, затримувати їх, дублювати або навіть перерозподіляти.

2.1 Ідентифікація

Суб'єкти в системі, надалі звані вузлами, унікально розпізнаються за ідентифікатором, який називається NodeAddress. Цей NodeAddress не просто представляє публічний ключ вузла; скоріше, він представляє криптографічний хеш такого публічного ключа. Причина прийняття криптографічного хешу замість необробленого публічного ключа полягає в конкретних питаннях безпеки, притаманних децентралізованим системам, особливо у зменшенні ризику атак Sybil і Eclipse, особливо коли система працює без централізованого довіреного органу.

2.1.1 Призначення адрес

Використання криптографічної головоломки, особливо механізму Proof of Work (PoW), служить для зміцнення мережі проти згаданих атак. Однак використання таких криптопазлів для підтвердження ідентичності є суперечливим питанням в академічному середовищі. Наприклад, Кастро та інші у своєму класичному дослідженні 2002 року (Castro, Miguel and Druschel, Peter and Ganesh, Ayalvadi and Rowstron, Antony and Wallach, Dan S., 2002) виступали проти використання криптопазлів для верифікації ідентичності. Їхні сумніви виникали з двох основних причин: по-перше, через нездатність криптопазлів повністю усунути ризик атаки, і по-друге, через обчислювальні витрати, які вони створюють. У цьому контексті "витрати" стосуються обчислювальної вартості вирішення криптопазла. Для оптимальної функціональності ці витрати повинні бути керованими для найменш продуктивного, легітимного вузла. Водночас, складність головоломки повинна бути досить високою, щоб стримувати або суттєво сповільнювати зловмисника, який має високі обчислювальні ресурси.

Малюнок 1: Статична криптографічна головоломка для генерації адреси вузла

У даній фігурі ілюструється процес створення статичної адреси вузла за допомогою криптографічної головоломки. Це є частиною механізму Proof of Work (PoW), що використовується для підтвердження ідентичності вузла в децентралізованій мережі HyperspaceAI. Процес генерації адреси включає рішення криптографічної задачі, яка забезпечує, що нові вузли можуть бути додані в мережу лише після успішного виконання цього завдання. Це допомагає захистити мережу від атак типу Sybil, де зловмисник намагається створити велику кількість псевдовузлів для контролю мережі.

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

2.1.2 Підписування повідомлень

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

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

• Сильний підпис: На відміну від слабкого підпису, сильний варіант підписує весь вміст повідомлення, забезпечуючи цілісність повідомлення та посилюючи захист від потенційних атак типу "людина посередині". Щоб запобігти атакам повторного відтворення, у RPC-повідомлення вбудовуються випадкові числа (nonces).

2.2 Модель

Ми аналізуємо систему з фіксованим набором n вузлів, позначених i ∈ [n], де [n] = {1, . . . , n}. Підмножина F ⊆ [n] містить до f = |F| вузлів, які демонструють байзантинські відмови, тоді як інші вважаються правильними. Ці байзантинські вузли часто вважаються під контролем зловмисника, який має доступ до всіх внутрішніх станів цих реплік, включаючи їх криптографічні ключі та будь-які попередні дані.

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

• Якщо вузли отримують однаковий результат після k надлишкових інференцій, цей результат правильний з імовірністю 1 − f ^k
• Якщо вузли отримують різні результати, вони можуть претендувати на частину застави від одного з двох вузлів

2.2.1 Пороговий підпис

Усі репліки мають уніфікований публічний ключ. Кожен з n вузлів зберігає унікальний приватний ключ. i-й вузол додає частковий підпис ρ_i ← tsigni(m) до заданого повідомлення m.

Часткові підписи, представлені як {ρ_i} з i ∈ I і |I| = k, де кожен ρ_i ← tsigni(m), можуть бути агреговані для отримання цифрового підпису σ ← tcombine(m, ρ_i) для m. Будь-яка репліка може автентифікувати цей підпис, використовуючи публічний ключ через функцію tverify. Необхідною умовою є те, що якщо ρ_i ← tsigni(m) для кожного i ∈ I (з |I| = k), і σ ← tcombine(m, ρ_i), тоді tverify(m, σ) підтверджує правдивість підпису.

2.2.2 Хеш-функції

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

2.2.3 Сервера спільноти Hyperspace та вузли інференції Hyperspace

У екосистемі сервера спільноти Hyperspace (HCS) відіграють роль оркестраторів, оракулів і секвенсерів у рамках протоколу.

Вузли інференції Hyperspace (HIN) у цьому контексті встановлюють з'єднання з HCS, вибираючи їх на основі вибору оператора вузла. Вони повідомляють про свої обчислювальні можливості та діапазон моделей, які вони можуть виконувати. Процес ініціації включає відправку joinmessage, який включає адресу відправника. Це повідомлення підписується слабким підписом, щоб запобігти підробці та гарантувати, що його не можна помилково пов'язати з іншою ідентичністю вузла (див. 2.1.2). Під час перевірки підпису HCS перевіряє криптографічну головоломку, пов'язану з вузлом інференції (HIN), підтверджуючи її дійсність. Потім вузол HCS повідомляє HIN про динамічну складність c2 криптографічної головоломки, як описано в розділі 2.1.1. Ця головоломка служить ідентичністю HIN підсистеми HCS.

Після цього вузли інференції Hyperspace здійснюють вторинне спілкування, registrymessage, з вузлом HCS. Це повідомлення детально описує заявлені характеристики вузла інференції та моделі AI, які він готовий підтримувати та виконувати.

Після цієї реєстрації вузол HCS видає виклик на укріплення інференції (inference fortification challenge) для вузла інференції (HIN). Цей виклик подається у формі пазла-запиту, природу якого визначає вузол HCS. Потім HIN повинен завершити пазл і надати результати інференції через виклик verify-inference.

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

2.2.4 Докази шахрайства

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

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

2.2.5 Модель викликів

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

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

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

У нейронній мережі прямого поширення кожен нейрон отримує суму вхідних ваг, помножених на значення попередніх нейронів, застосовує функцію активації і зберігає її як своє значення. Значення нейрона зазвичай завжди зберігається в оперативній пам'яті (RAM), і тому може бути частиною стану Меркле.

Візьміть типову нейронну мережу з 10 мільйонами нейронів, і припустимо, що вони мають певний порядок. Викликаний вузол повинен подати корінь стану нейронів по мільйону за раз, що призведе до 10 коренів Меркле. Викликаний вузол обчислює локально корені стану та подає перший, який є неправильним, як виклик. Має бути неправильний, оскільки останній неправильний.

Викликаний вузол надсилає корінь стану 1 мільйона нейронів, викликаних пакетами по 100 тисяч. Викликаний вузол повторює ту ж процедуру, доки не залишиться один нейрон. Ми також матимемо правильний стан нейронів, які передують йому в корені, безпосередньо перед цим. Процес займе 7 ітерацій.

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

Це просто для отримання переваг від паралелізму. Інакше ми могли б просто виконати розрахунок ваг послідовно та викликати їх послідовно.

2.2.6 Припущення

• Матриця ваг зберігається таким чином, що дозволяє її парсинг (для оптимізації процесу обчислення).
• Виконання є детермінованим.
• Функції активації можуть бути зрозумілі середовищем виконання.

2.3 Економіка

У згаданих вище механізмах усі складові суб'єкти прагнуть діяти чесно через внутрішню економічну структуру та механізм стимулювання. Як правило, нові блокчейн-екосистеми вводять різні токени для забезпечення цієї криптоекономічної захищеності. Тим не менш, ці нові токени спочатку можуть мати труднощі з накопиченням необхідного обсягу та розподілу, що перешкоджає безпечному фундаменту екосистеми. Цю проблему успішно вирішила EigenLayer, яка розробила рамкову структуру для використання криптоекономічних засобів захисту Ethereum, залучивши валідаторів Ethereum. Протокол HyperspaceAI приймає цю структуру і використовує операторів EigenLayer для посилення безпеки в мережі HyperspaceAI.

Висновок

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

3. Література

• Baumgart, Ingmar and Mies, Sebastian (2007). S/kademlia: A practicable approach towards secure key-based routing, IEEE.
• Castro, Miguel and Druschel, Peter and Ganesh, Ayalvadi and Rowstron, Antony and Wallach, Dan S. (2002). Secure routing for structured peer-to-peer overlay networks.
• Cohen, Bram (2003). Incentives build robustness in BitTorrent, Berkeley, CA, USA.
• Maymounkov, Petar and Mazières, David (2002). Kademlia: A Peer-to-Peer Information System Based on the XOR Metric, Springer Berlin Heidelberg.
• Stoica, Ion and Morris, Robert and Liben-Nowell, David and Karger, David R. and Kaashoek, M. Frans and Dabek, Frank and Balakrishnan, Hari (2003). Chord: a scalable peer-to-peer lookup protocol for internet applications.
• Hyperspace: A Peer-to-Peer Artificial Intelligence Network HyperspaceAI (gutenberg@hyperspace.us)

https://x.com/hyperspaceai

https://github.com/hyperspaceai