Ключові висновки

1. Solana використовує одноранговий протокол переговорів на основі алгоритму Plumtree, що дозволяє децентралізованому зв’язку між вузлами ефективно поширювати зміни стану в мережі, не покладаючись на центральне джерело.
2. Кожні 0,1 секунди вузли Solana обмінюються повідомленнями «push» і «pull», забезпечуючи безперервний і актуальний обмін інформацією для підтримки швидкого розповсюдження даних і синхронізації в мережі.
3. Протокол пліток складається з чотирьох основних типів повідомлень — Push, Pull, Prune і Ping/Pong, які допомагають розповсюджувати дані, запитувати відсутню інформацію, керувати з’єднаннями вузлів і перевіряти життєздатність вузлів.
4. Дані пліток зберігаються в кластерному реплікованому сховищі даних (CrdsTable), яке постійно оновлюється поступовими оновленнями стану мережі, забезпечуючи доступність даних і синхронізацію між вузлами.
5. Архівна система Solana використовує «вузли сховища» для зберігання історії транзакцій, при цьому останні дані (1-2 епохи) зберігаються валідаторами, тоді як повна історія транзакцій зберігається в архівах Ledger або екземплярах Google Bigtable для легкого доступу RPC та інших учасників.

Плітки

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

У програмі Solana для реалізації протоколу пліток використовується неформальний метод зв’язку з підходом до трансляції дерева, сильно змодельованим на основі алгоритму Plumtree. Це дозволяє поширювати зміни стану, не покладаючись на центральне головне джерело. Він діє як панель керування для Solana, оскільки допомагає валідаторам і вузлам RPC знати, які адреси та порти відкриті для зв’язку. Solana Gossip працює з іншими основними компонентами, такими як валідатори, протокол турбіни, вузли архіву, підтвердження історії тощо. Валідатори та RPC обмінюються підписаними об’єктами даних кожні 0,1 секунди через UDP за допомогою gossip, гарантуючи доступність інформації по всій мережі. Кожне пліткове повідомлення має бути на рівні або нижче максимальної одиниці передачі (MTU) 1280 байт, відомої як «структура пакета» в кодовій базі.

Протокол gossip служить центральним механізмом для вузлів для ефективного керування зв’язком кластера шляхом постійного обміну підписаними об’єктами даних, такими як контактна інформація, висота бухгалтерської книги та голоси. Кожні 0,1 секунди вузли обмінюються повідомленнями «push» і «pull», де push-повідомлення можуть пересилатися, і обидва типи можуть ініціювати відповіді, що сприяє швидкому розповсюдженню даних у мережі. Працюючи через добре відомий порт або діапазон портів UDP/IP, протокол переговорів дозволяє вузлам рекламувати свої кінцеві точки переговорів (адреси сокетів) один одному після завантаження кластера. Цей децентралізований високочастотний граф зв’язку забезпечує синхронізацію та стійкість вузлів Solana, підтримуючи масштабованість і продуктивність блокчейну.

У протоколі пліток Solana чотири типи повідомлень полегшують зв’язок між кластерами: Push-повідомлення, найчастіші, розподіляють дані вибраній групі «push-пірів». Пул-повідомлення разом із відповідями на них періодично надсилаються, щоб отримати будь-яку відсутню інформацію шляхом запиту та доставки непоширених даних. Повідомлення «Вирізати» дозволяють вузлам за потреби обрізати свої активні з’єднання. Нарешті, повідомлення Ping і Pong служать для перевірки життєздатності, де ping пропонує відповідь Pong для підтвердження робочого статусу однорангового вузла.

Дані пліток зберігаються в сховищі реплікованих даних кластера (CrdsTable). Ця структура даних постійно оновлюється повідомленнями протоколу пліток. Ці повідомлення містять записи пліток, які по суті є поступовими оновленнями CrdsTable.

Архів

Solana відрізняється від інших блокчейнів тим, що не вимагає повної історії транзакцій для визначення поточного стану облікового запису. Його модель облікового запису гарантує, що стан будь-якого заданого слота відомий, дозволяючи валідаторам зберігати поточний стан без необхідності обробки всіх історичних блоків. RPC і валідатори зазвичай не зберігають всю історію реєстру; замість цього вони зберігають лише 1 або 2 епохи (2-4 дні) даних транзакцій, яких достатньо для перевірки останнього блоку.

Архівними даними керують «вузли сховища», якими керують професійні постачальники послуг RPC, Фонд Solana та інші учасники екосистеми, щоб забезпечити доступ до історії транзакцій. Ці вузли сховищ часто підтримують або Ledger Archive, який зберігає необроблені знімки книги та AccountsDB для повторного відтворення з нуля, або екземпляр Google Bigtable, який зберігає дані блоку, починаючи з блоку генезису, у форматі, придатному для запитів RPC.

Висновок

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