Executive Summary Виконавчий резюме Nothing we create exists outside the patterns nature has already explored. Ця стаття стверджує, що в нашому прагненні освоїти і контролювати складні системи ми нехтуємо природними конструкціями, які пропонують справжню силу: адаптивність, виникаючий порядок і самоорганізацію. Ми розглядаємо, як підходи, орієнтовані на контроль, обмежують розподілені системи, і пропонуємо перехід до децентралізованих, самоорганізованих шаблонів, натхнених природою. Ми досліджуємо, як механізми контролю обмежують сьогоднішні розподілені системи, і як прийняття менш централізованої філософії може розблокувати їх повний потенціал. Оскільки системи зростають у складності і масштабі, контролі, які ми вбудовуємо в них, стають все більш стійкими, створюючи тертя і боротьбу за владу. Ми бачимо це в розподілених системах і в зростанні великих мовних моделей, які часто працюють як чорні скриньки. Ця стаття розглядає проекти і протоколи, багато з яких вже використовуються, які можуть відкрити нову епоху менш обмежених, більш потужних систем. Ми охоплюємо еволюцію розподілених систем, постійне пошук контролю, концепцію самоорганізації та те, як ми можемо її використовувати. Щоб прийняти цю виникаючу силу, ми повинні відмовитися від контролю і змінити наше мислення. Introduction Введення Не так давно було нормально уявити собі обчислення без хмари, центрів даних або навіть інтернету. Розглянемо телефонну книгу: Жовті сторінки, каталог тисяч адрес і номерів для місцевого бізнесу. Щоб зв'язатися з бізнесом, ми просто звернулися до телефонної книжки і зателефонували службі, яку ми шукали. Це не далеко від того, чим став Інтернет, і що Google все ще є сьогодні: величезний індекс веб-сторінок для нас, щоб шукати і навігувати. Обидва є формами розподілених систем, ні повністю централізованих, ні дійсно децентралізованих. У централізованій моделі всі важливі завдання, обробка, зберігання та прийняття рішень, обробляються одним комп'ютером або сервером. Повертаючись до нашої аналогії телефонної книги: уявіть, що в бібліотеці знаходиться тільки одна копія. Кожен, хто потребує інформації, повинен йти в чергу, і на зайнятий день очікування зростає довго. Це централізована система. Це може працювати, якщо тільки одна вулиця ділиться книгою, але масштабувати її на ціле місто або країну, і пляшковий бар'єр стає очевидним. [1] Наприклад [1] Наприклад Аналогічно, раннє програмне забезпечення могло працювати на одному сервері або масштабуватися вертикально, додаючи більше обчислювальної техніки, але по мірі збільшення запитів і користувачів централізація стає обмеженням. Відповідь на цю проблему – розподіл. У розподілі ми поширюємо телефонні книги. Але ми не даємо кожній людині свою власну, так само, як Google не виділяє кожному домогосподарству свій власний сервер для управління. Натомість, кожен поштовий код отримує копію, зменшуючи кількість користувачів, які конкурують за доступ. Сьогодні вона часто асоціюється з криптовалютами, такими як Біткойн, і в той час як блокчейн і розумні контракти залежать від децентралізованих протоколів, концепція надовго передує їм. [2] Наприклад [2] Наприклад Щоб розширити аналогію, уявіть, що телефонна книга вже не існує в друкованому вигляді, а в спільних знаннях мешканців міста. Кожен поштовий код містить іншу версію. З часом версії можуть збігатися, але через різні канали спілкування. Щоб знайти адресу, ви б попросили сусіда, який може направити вас до іншого, хто має інформацію. Децентралізовані вузли всередині кластеру створюють локальні карти інформації, такі як реєстри послуг, які вони діляться один з одним. Ця стаття стверджує, що через необхідність і еволюцію, наші системи тепер міцно сидять в розподіленому таборі, але ми все ще дотримуємося централізованого мислення. Щоб ілюструвати цей перехід, ми звертаємося до архітектур, які домінують в сучасних системах. Відмова від відповідальності: Ця біла книга є навмисною думкою. Складні теми підсумовуються і спрощуються, щоб забезпечити більш широке оповідання для обговорення. Дизайн системи по своїй суті відтінкований; ця стаття приймає тематичний, а не глибокий інженерний підхід, визнаючи, що дрібниці і механіка систем не можуть бути повністю захоплені або скорочені до суми їхніх частин. Відмова від відповідальності: Ця біла книга є навмисною думкою. Складні теми підсумовуються і спрощуються, щоб забезпечити більш широке оповідання для обговорення. Дизайн системи по своїй суті відтінкований; ця стаття приймає тематичний, а не глибокий інженерний підхід, визнаючи, що дрібниці і механіка систем не можуть бути повністю захоплені або скорочені до суми їхніх частин. Пошук контролю Ці високоскладні системи покладаються на багато рухомих частин і алгоритмів, щоб залишатися доступними, толерантними до помилок і масштабованими. проте, ці ідеї не нові; багато протоколів і методів, що використовуються сьогодні, датуються десятиліттями, від електричних мереж до формальної теорії одночасної валюти. [3] Наприклад [3] Наприклад На практиці масштабування приймає дві форми: вертикальне і горизонтальне. Вертикальне масштабування означає додавання більшої кількості обчислень, ядер процесорів, оперативної пам'яті та зберігання до однієї машини, збільшуючи її потужність під навантаженням. Горизонтальне масштабування, на відміну від цього, вводить іншу складність: як координувати багато окремих машин (серверів), щоб вони працювали як одна служба, утворюючи кластер. Одним з основних принципів розподілених систем є теорема CAP. CAP (Consistency, Availability, and Partition Tolerance) — теорія, що система може гарантувати не більше двох з трьох, що змушує архітекторів робити компроміси з дизайном. [4] Наприклад [4] Наприклад Наприклад, система може вибрати сильну послідовність і толерантність розділів, пріоритетуючи точні, ретельно розділені дані по вузлах за рахунок наявності. Алгоритми консенсусу вирішують проблему послідовності, дозволяючи координацію між горизонтально масштабованими вузлами в кластері. Більшість алгоритмів приймають динаміку «лідер / послідовник» (історично «майстер / раб»): один вузол діє як лідер, координуючи і відтворюючи інформацію іншим. [5] Наприклад [5] Наприклад Наприклад, в розподіленій базі даних всі написи проходять через лідера, який потім поширює їх до послідовників. Якщо лідер зазнає невдачі, інший вузол може взяти на себе, зберігаючи послідовність. . . Розробка даних-інтенсивних додатків [6] [6] Наприклад Ці підходи добре працюють для своїх цілей, дозволяючи можливості далеко за межами простого горизонтального масштабування. Проте, вони вкорінені в людському інстинкті, щоб зберегти контроль. Навіть мова, яку ми використовуємо, «Майстер / раб», «Лідер / Наслідник», «Первинний / Репліка», «Батько / Дитина», «Робочий», відображає ієрархічне мислення. У той час як ієрархія має своє місце, ця стаття стверджує, що наше наполегливе пошук контролю все більше збігається з траєкторією технологій і систем, які ми будуємо. У консенсусі ми бачимо це у відкритті послуг: як вузли в кластері знаходять один одного? , забезпечують централізовану конфігурацію та синхронізацію, що дозволяє вузлам виявляти один одного, але тільки покладаючись на центральний орган. [ 7 ] [ 7 ] З більш широкого погляду, ми бачимо елементи контролю через оркестрацію.Платформи, такі як Kubernetes, рамка для стійкого запуску розподілених систем, обробки завдань, таких як масштабування, перезавантаження та шаблони розгортання , забезпечують централізований спосіб управління та розгортання складних розподілених мікрослужб. [8] Історія [8] Історія Багато організацій приймають гібридні моделі для балансу місцевої гнучкості з центральним наглядом У той же час, використання таких послуг часто створює більш тонку форму централізації: замок продавця. [9] [ 9 ] Оскільки системи стають все більшими і складнішими, багато технічних проблем все ще вирішуються за допомогою централізованих принципів. Якби масштабуваність і теорема РПП не були обмеженнями, централізовані системи, ймовірно, залишалися б оптимальним вибором, забезпечуючи доступність, послідовність і толерантність без компромісів. [ 10 ] [ 10 ] З розвитком технологій і появою нових випадків використання наші системи та інфраструктура також повинні розвиватися.Телефонні мережі та Інтернет є прикладами широкомасштабних, високопродуктивних комунікаційних мереж, хребта розподілу.Але в останні роки з'явилися нові класи мереж, де комунікація не є єдиною метою: сенсорні мережі, системи peer-to-peer (P2P), мобільні ад-hoc мережі та соціальні мережі. P2P-мережі особливо помітні як самоорганізуючі системи, що дозволяє використовувати такі випадки, як дрон-сварми і мульти-агент AI. [ 11 ] [ 11 ] Щоб розблокувати їх, ми повинні відпустити контроль і дозволити системам самоорганізуватися. Таємниці природи Не випадково, що коли ми обговорюємо децентралізовані системи, особливо самоорганізацію, велика частина мови випливає з природи. Навпаки, терміни для централізованих систем часто відображають людські ієрархії. Багато природних і біологічних систем демонструють складну децентралізацію. Найголовніше, вони самоорганізуються і працюють колективно до спільних цілей. Розглянемо звар, простий, але потужний приклад того, як природна поведінка перетворюється на дизайн систем. Звар інтелект - це форма штучного інтелекту, натхненний колективною поведінкою організмів, таких як бджоли, мурахи, птахи і риби. . [ 12 ] [ 12 ] Зображіть стадо птахів: тисячі літають поблизу, утворюючи рідкі форми, які змінюються кожну секунду. Жоден птах не знає колективної форми або кінцевого напрямку. Кожен зосереджується тільки на своїх найближчих сусідах, підтримуючи відстань, дзеркальні рухи. Кожен птах робить це, і разом з ним, карлик рухається як вода в небі в ідеальному гармонії. Для нас, він виглядає цілеспрямованим і хореографікованим; для птахів, вони просто спілкуються зі своїми найближчими сусідами. Стадо просто спілкується і реагує. Для птахів спільна мета - вижити від хижаків; для мурашок - це знайти найкоротший шлях до ї Сварм інтелект має широке застосування, в ланцюжку поставок і логістики, маршрутизації мережі, фінансів і торгівлі, а також штучний інтелект. Один приклад - Колоніальна оптимізація (ACO), натхненний тим, як мурахи шукають їжу. Коли колонія нова, мурахи рухаються випадково, оскільки немає керівних феромонів існує і всі шляхи однаково ймовірні. Кожна мураха залишає феромони уздовж свого маршруту, поступово направляючи інших до оптимальних шляхів. [ 13 ] [ 13 ] Наприклад, логістичні компанії можуть використовувати розвідувальний інтелект, щоб імітувати автопарки транспортних засобів і виявити оптимальні маршрути. Симуляція може поєднувати дані прямого трафіку з відомими депозитами або складами. З часом, взаємодії на основі звар може принести ефективні стратегії маршрутування. Чи можна досягти подібних результатів більш безпосередньо і ефективно, так що робить інтелект звар відрізняється? [24] І [24] І Різниця полягає в самоорганізації і виникаючому порядку. За допомогою звичайного алгоритму, керування декількома транспортними засобами просто розподіляє робоче навантаження: кожен слідує тій же логіці, виробляючи подібні результати. Будь-яка відмінність в кінцевому підсумку вирішується нами, центральним постачальником рішень. На відміну від цього, зварний інтелект дозволяє транспортним засобам діяти як вузли в мережі, спілкуватися з сусідами, будувати місцеві знання і сприяти колективному розуміння кластеру. Немає центральної влади; флот реагує і адаптується через взаємодію. Виникаючий порядок виникає з цього зв'язку. Тема, до якої ми повернемося пізніше. Система мультиагентів Мережі зв'язку і протоколи глибоко вкорінені в природних системах. Форма мереж, в якій дерева використовують хімічну сигналізацію і симбіотичні відносини з мікроорганізмами для обміну життєво важливою інформацією. Кожне дерево діє як вузол у більшому кластері, лісі.Через величезні кореневі системи і грибкові мережі (микоризальні гриби), сигнали подорожують між деревами, що дозволяє їм попереджати про хвороби, посилати сигнали страждання або навіть обмінюватися поживними речовинами. . Дерево комунікації [ 15 ] [ 16 ] [ 15 ] [ 16 ] Природа показує, що децентралізовані системи з виникаючим порядком покладаються на складні мережі та складні комунікаційні протоколи.На їх основі лежить обмін інформацією, ключовий засіб самоорганізації кластерів. Деякі з найбільш перспективних застосувань цих проектів лежать в штучному інтелекту. AI вже відтворює певні природні поведінки: він може розпізнавати закономірності, реагувати на події та адаптуватися. проте, більшість AI залишається вкоріненими в централізації. Ця залежність різко контрастує з децентралізованими, саморегулюючими системами природи.Питання тоді стає: як AI може працювати децентралізованим чином? [ 17 ] [ 17 ] мультиагент-системи Проте основні концепції варто розглянути: реалізації MAS безпосередньо залежать від принципів, обговорюваних тут, і їх випадки використання ілюструють аргументи цієї статті. З огляду на швидке зростання штучного інтелекту і його глибоку інтеграцію в сучасні технології, на краще чи гірше, неможливо обговорити майбутнє систем, не згадуючи штучного інтелекту. Більшість підприємницьких розгортань, однак, залишаються закріпленими в архітектурі одного агента, системах, де один генералізований агент повинен обробляти кожен запит, покликання інструментів та політику. Навіть коли робоче навантаження розподіляється, централізований шар оркестрації все ще керує процесом через реєстри, сховища, зберігання та класифікатори. [ 18 ] [ 18 ] За визначенням, такі архітектури можуть кваліфікуватися як мультиагентні системи. Але, як показано в логістичному прикладі, розподіл не дорівнює самоорганізації. MAS підкреслює напругу між центральним контролем і виникаючою поведінкою: дотримання централізованих принципів обмежує їх потенціал для еволюції в дійсно потужні системи. Ця напруга також пояснює, чому MAS визначаються багатьма різними і часто суперечливими способами. Для цієї статті ми визначаємо справжню MAS як децентралізовану, автономну мережу інтелектуальних агентів, що працюють в рамках самоорганізуючої структури, розробляючи нові ролі та порядок для виконання еволюційних завдань або безперервних цілей. В ідеальному вигляді система не вимагала б від нас вказати завдання. Натомість навколишнє середовище, інструменти та поведінка агентів дозволили б цілям виникати природно. Уявіть флот безпілотників, призначених для боротьби з вогнем. Їхні можливості можуть включати тепловий зображення, механізми гасіння та термічну стійкість. У MAS безпілотники могли колективно вирішити придушити горячу машину, самоорганізуючись навколо своїх можливо Ключем до таких систем є здатність агентів обробляти місцеву інформацію і реагувати один на одного. Природа знову дає приклад: слизові форми. Кожна клітина слідує простим вбудованим правилам: рухатися вперед, уникати шкоди, спілкуватися з сусідами. Через ці місцеві взаємодії клітини генерують виникаючу інтелігенцію для всього організму, демонструючи складні поведінки вирішення проблем. . [19] Історія [19] Історія Для MAS це означає, що колекція автономних агентів може взаємодіяти в середовищі, щоб вирішити проблеми, які жоден один агент не міг вирішити самостійно. Сьогодні MAS залишається в ранньому віці, в основному налаштованих, високоцільових систем, побудованих для вузьких доменів. Як і з штучним загальним інтелектом, існує дебати про те, чи ми коли-небудь досягнемо загального MAS, здатного адаптуватися до будь-якого завдання. Виклик полягає в притаманній складності децентралізованих, самоорганізованих систем: питання пам'яті, зберігання, контексту, самонавчання та міркування. Подолання цих бар'єрів дозволить агентам діяти автономно, ділитися знаннями та вчитися колективно. Уявіть команду агентів, що вирішують завдання, яке вже вирішив один агент. Якщо ці знання були поділені, ціла група могла б отримати вигоду, уникаючи подвійних зусиль та оптимізуючи продуктивність. [ 20 ] [ 20 ] Розширені міркування надалі ілюструють, як можуть функціонувати самоорганізовані системи. Коли агенти роздумують один з одним, виникають нові динаміки: можуть формуватися нові ролі, створюватися підмережі, і можуть бути виявлені оптимальні стратегії. Один з прикладів - протокол «Контрактна мережа», в якому група агентів утворює коаліцію і бере участь у конкурсному процесі для завдання або підзадачі. Завдяки повторним раундам коаліція удосконалює свій підхід, колективно сприяючи досягненню мети і досягненню децентралізованого порядку. [21] [21] Історія MAS ілюструє найбільший потенціал децентралізації. Їх складнощі та взаємодії агентів формуються і стають можливими шляхом імітації дизайнів, які ми бачимо в природі. Протоколи, такі як контрактна мережа, і репліка peer-to-peer, імітують складні мережі природи і забезпечують механізми для справжньої самоорганізації в децентралізованих системах. Складні мережі без центральної влади пропонують більшу гнучкість і можуть підняти системну архітектуру. Вони розблокують нові випадки використання, розширюють технологічний ландшафт і можуть відкрити нову епоху штучного інтелекту. Дивлячись як на природні, так і на комп'ютерні системи, виникає чітка закономірність: в децентралізованих мережах комунікація є фундаментом. Спілкування є основою самоорганізованих систем. Сингулярні об'єкти, будь то клітини, тварини, агенти або вузли, повинні спілкуватися без центрального нагляду. Недостатньо реагувати на місцеві події; вони також повинні поділитися ними. Протоколи забезпечують «правила дороги» для цих каналів спілкування. Протокол GOSIP Госпіт відіграє життєво важливу роль в людському суспільстві. Для кращого або гіршого, він поширює інформацію з дивовижною швидкістю. Навіть без сучасних технологій, чутки серед друзів, скандали в місті, або новини в місті завжди поширювалися швидко, підштовхнені словом до рота між індивідами. Це швидке поширення інформації аналогічно тому, як віруси, або історично, чуми, поширюються по популяціях. [22] Наприклад [22] Наприклад Протоколи Gossip імітують цю закономірність в розподілених системах, дозволяючи вузлам в кластері діяти децентралізовано, ділившись місцевими знаннями зі своїми сусідами. На практиці один вузол випадково вибирає інший, щоб обмінюватися інформацією з ним. Вони порівнюють нещодавність своїх даних і узгоджуються з останньою версією. Кожен потім вибирає нових однолітків, і цикл повторюється, дозволяючи інформації розповсюджуватися експоненційно через кластер. Цей процес дозволяє кластеру створювати консенсус щодо стану через вузли. При достатній кількості раундів всі вузли збігаються на узгодженому стані.Це контрастує з сильною послідовністю, яка вимагає негайної згоди через централізовані принципи, такі як структури лідерів / послідовників. Можлива послідовність В кінцевому підсумку, послідовні системи пропонують більш високу доступність, більшу толерантність розділів і меншу затримку, нагадують теорему CAP. Сильно послідовні системи, на відміну від цього, гарантують негайну послідовність для записів і гарантують, що всі читання повертаються до останнього стану. У критичних системах може знадобитися сильна послідовність. Але для високоскладових розподілених систем вона вводить пляшки централізованого управління. Щоб ефективно масштабувати, ми повинні прийняти протоколи peer-to-peer, а щоб реалізувати їхню повну користь, прийняти їх повністю. [23] з них [23] з них Розглянемо розподілену базу даних. Коли таблиця росте занадто великою для однієї машини, вона розділяється на менші фрагменти і зберігається по вузлах у кластері. Якщо фрагмент стає занадто великим, додається інший вузол. Цей налаштування розповсюджується, але не децентралізований або самоорганізується. Для узгодженості така система може використовувати модель консенсусу, як Raft , використовуючи структуру лідера / послідовників для реплікації даних. [ 24 ] [ 24 ] Виникають дві ключові проблеми: що відбувається, якщо вузол розривається або відключається, і як вузли виявляють місця розташування розділів? У моделі, орієнтованій на контроль, ми вирішуємо це за допомогою сервісного реєстру, такого як Apache Zookeeper. Вузли запитують реєстр, щоб знайти власників розділів, а реєстр періодично перевіряє здоров'я вузлів за допомогою пінг, інформуючи інших, якщо вузол недоступний. Хоча ефективний, цей підхід додає напругу мережі, створює залежність, зменшує автономію, і збільшує ризик перешкод або каскадних збоїв. Саме тут світиться протокол чуток, особливо в системах, що належить до хмари. З гаслами, кожен вузол може поділитися своїм станом безпосередньо з іншими. Кожен вузол, таким чином, підтримує свій власний місцевий реєстр послуг, постійно оновлюється через гасла. Якщо четвертий вузол приєднується до кластеру і присвоюється новий розділ, він оголошує себе одноліткам. Це знання поширюється, і незабаром всі вузоли знають, де знаходиться кожен розділ. Так само, якщо вузол не в змозі зв'язатися з однолітками, він поширює підозру про невдачу, дозволяючи кластеру адаптуватися. Так само, як дерева сигналізують про біду в лісах, вузоли самоорганізуються в топологію самоздоровлення. [ 25 ] [ 25 ] Цей приклад підкреслює критичний вибір: чи прийняти децентралізацію за рахунок контролю.У деяких випадках, однак, немає вибору; шахраї протоколи можуть бути єдиним життєздатним варіантом, особливо в околицях краю або мережах без центрального вузла. [ 26 ] [ 26 ] Багато широко використовуваних платформ покладаються на чутки, як вбудовані, так і на основі хмари. Amazon's DynamoDB використовує чутки для відстеження стану розділів. Netflix's Eureka забезпечує відкриття послуг, що підтримуються чутками. Redis, популярний магазин ключових цінностей в пам'яті, використовує чутки для поширення інформації про кластери. Крім того, існує багато реалізацій з відкритим кодом. , високопродуктивний протокол, розроблений для вбудовування децентралізованого, врешті-решт, узгодженого стану в додатки. Гоферброк [ 27 ] [ 27 ] Важливо, що протокол чуток являє собою зміну в наших системних дизайнах, який відволікає контроль від централізованого мислення, все ще вбудованого у велику частину нашої інфраструктури. Висновок Зрештою, вибір перед нами простий, але глибокий: продовжувати зміцнювати контроль і ієрархію в системи, які їм протистоїть, або прийняти природні закономірності децентралізації, комунікації та самоорганізації, які завжди ґрунтувалися на найбільш стійких мережах, будь то біологічні, соціальні або цифрові. Майбутнє належить системам, які розвиваються, адаптуються і координуються, не пов'язані жодною точкою влади. Відпускаючи наш інстинкт централізації, ми відкриваємо двері до архітектур, які не просто розширюються, а живі. Для розподіленого обчислення це означає протоколи, такі як чутки, які сприяють виникненню над оркестрацією, співпраці над командуванням. Для штучного інтелекту це вказує на мультиагентні системи, здатні до самоорганізації та обміну знаннями.А для нас, як системних дизайнерів, це вимагає зміни думки: від будівництва машин, які підкоряються, до культивування екосистем, які адаптуються. Якщо ми настільки сміливі, щоб звільнити нашу прихильність централізованому контролю, ми можемо опинитися не на межі технологій, а на початку абсолютно нової епохи, коли наші системи, як і сама природа, самопідтримуються, самоорганізуються і безмежно здатні до зростання. Референції [1] Наприклад Centralized vs Distributed System - GeeksforGeeks Централізована проти розподіленої системи - GeeksforGeeks [2] Наприклад Blockchain History: The Evolution of Decentralized Technology - LayerK Blog Історія блокчейна: еволюція децентралізованих технологій - блог LayerK [3] Наприклад [2502.20468] Будівництво теорії розподілених систем: робота Ненсі Лінч і співробітників [2502.20468] Будівництво теорії розподілених систем: робота Ненсі Лінч і співробітників [4] Наприклад What Is the CAP Theorem? | IBM Що таке теорема CAP? - IBM [5] Наприклад Consensus Algorithms in Distributed Systems | Baeldung on Computer Science Алгоритми консенсусу в розподілених системах, Baeldung на комп'ютерній науці [6] Наприклад Дизайн інтенсивних додатків для даних [книга] Дизайн інтенсивних додатків для даних [книга] [ 7 ] Apache ZooKeeper Створення Apache ZooKeeper [8] Історія https://kubernetes.io/docs/concepts/overview/ https://kubernetes.io/docs/concepts/overview/ [ 9 ] Breaking the chains of big data: How distributed architecture unlocks agility | CIO Розрив ланцюгів великих даних: як розподілена архітектура розблокує гнучкість [ 10 ] [1805.01786] To Centralize or Not to Centralize: A Tale of Swarm Coordination [1805.01786] Централізувати чи не централізувати: казка про координацію звар [ 11 ] Госип-альгоритми .pdf Госип-альгоритми .pdf [ 12 ] Swarm Intelligence — Франкі Т Swarm Intelligence — Франкі Т [ 13 ] Swarm Intelligence: the Intersection of Nature and AI Swarm Intelligence: перехрестя природи та AI [24] І https://en.wikipedia.org/wiki/Dijkstra's_algorithm https://en.wikipedia.org/wiki/Dijkstra's_algorithm [ 15 ] Шпигунський ліс: як спілкуються дерева і майбутнє дерев, орієнтованих на штучний інтелект Шпигунський ліс: як спілкуються дерева і майбутнє дерев, орієнтованих на штучний інтелект [ 16 ] https://scientificorigin.com/do-trees-talk-to-each-other-the-hidden-language-of-forests https://scientificorigin.com/do-trees-talk-to-each-other-the-hidden-language-of-forests [ 17 ] https://medium.com/@kamil.sedzimir/how-ai-and-holochain-can-transform-decentralized-human-systems-based-on-nature-cbd59bea2177 https://medium.com/@kamil.sedzimir/how-ai-and-holochain-can-transform-decentralized-human-systems-based-on-nature-cbd59bea2177 [ 18 ] https://devblogs.microsoft.com/blog/designing-multi-agent-intelligence https://devblogs.microsoft.com/blog/designing-multi-agent-intelligence [19] Історія https://www.researchgate.net/publication/383294907_Biological_Inspiration_for_AI_Analogies_Between_Slime_Mold_Behavior_and_Decentralized_Artificial_Intelligence_Systems https://www.researchgate.net/publication/383294907_Biological_Inspiration_for_AI_Analogies_Between_Slime_Mold_Behavior_and_Decentralized_Artificial_Intelligence_Systems [ 20 ] https://arxiv.org/pdf/2402.03578 https://arxiv.org/pdf/2402.03578 [21] Історія Analysis of contract net in multi-agent systems - ScienceDirect Аналіз контрактної мережі в мультиагентних системах - ScienceDirect [22] Наприклад Протоколу Протоколу.pdf Протоколу Протоколу.pdf [23] з них Strong vs. Eventual Consistency in System Design - GeeksforGeeks Сильна проти можливої послідовності в системному дизайні - GeeksforGeeks [ 24 ] Алгоритм консенсусу Алгоритм консенсусу [ 25 ] Облачна симуляційна рамка для протоколу ганьби: моделювання та аналіз мережевої динаміки - PMC Облачна симуляційна рамка для протоколу ганьби: моделювання та аналіз мережевої динаміки - PMC [ 26 ] «[27] 2110.14609 GitHub - kristianJW54/GoferBroke: GoferBroke - це легкий, розширений інструмент, розроблений для створення розподілених кластерів за допомогою протоколу антиентропії через власний бінарний TCP. 2110.14609 GitHub - kristianJW54/GoferBroke: GoferBroke - це легкий, розширений інструмент, розроблений для створення розподілених кластерів за допомогою протоколу антиентропії через власний бінарний TCP.
