Переклад оригінальної статті Bootstrapping in Massa Network
Ноди, які здійснюють бутстреппінг в Massa, вже є частиною мережі, тому можуть стежити за станом, відстежуючи блоки, що проходять через мережу, перевіряючи їх і застосовуючи зміни стану, які вони викликають.
Вступ
В той самий час, коли нові ноди приєднуються до мережі, вони повинні отримати абсолютну “поточну” версію стану, що називається “бутстреппінг” (bootstrapping). У деяких блокчейнах, таких як Bitcoin, повним нодам, що приєднуються до мережі, рекомендується завантажувати всі блоки з самого початку (генезису) блокчейну, щоб повторно перевірити всю історію зміни стану. Однак, Massa має потрійну мету – децентралізація/безпека/продуктивність:
- Максимальна децентралізація вимагає, щоб вимоги до апаратного забезпечення нод залишалися узгодженими з типовим персональним комп’ютером, щоб знизити вхідний бар’єр для того, щоб стати тримачем ноди.
- Максимальна безпека вимагає, щоб усі ноди верифікували всі блоки та операції
- Максимальна продуктивність вимагає використання апаратного забезпечення нод на повну потужність (процесор, мережа, пам’ять, сховище)
Це означає, що стан в Massa розвивається майже так само швидко, як типові персональні комп’ютери можуть обробляти блоки, а це означає, що наздоганяння блоків з моменту генезису йде лише трохи швидше, ніж з’являються нові блоки, і зайняло б дуже багато часу. Крім того, Massa націлена на обробку тисяч транзакцій в секунду, а це означає, що вона створює велику кількість даних блоків щосекунди, таким чином, не дозволяючи нодам з цільовим обладнанням зберігати повну історію блоків і роблячи неможливим бутстреппінг з генезису, через те, що старі блоки стираються.
Тому ноди Massa, що приєднуються до мережі, повинні здійснювати бутстреппінг, завантажуючи абсолютний поточний стан.
Зауважте, що ноди можуть відновлюватися після короткочасних відключень, запитуючи відсутні дані в інших нод, як тільки вони повертаються в мережу. Однак, оскільки ноди Massa зберігають лише коротку історію блоків і видаляють старіші, неможливо відновитися після тривалих відключень, оскільки навколишні ноди втратили блоки, необхідні ноді, що відновлюється. У такому випадку потрібен новий бутстреп стану.
Модель безпеки
Приклад бутстрепу в мережі Bitcoin
Для розуміння моделі безпеки бутстрепу нод хорошим початковим прикладом є Bitcoin.
Коли ноди Bitcoin вирішують приєднатися до мережі, вони спочатку завантажують програмне забезпечення ноди з центрального джерела (наприклад, bitcoin.org). Якщо це джерело скомпрометоване, нода може опинитися в іншій мережі та/або може статися крадіжка приватного ключа. Тому Bitcoin вимагає довіри до суб’єкта, який надає програмне забезпечення для нод.
Зауважте, що у випадку, коли ноди не бажають завантажувати повну історію блоків, вони вдаються до довіри до більш свіжого стану “контрольної точки”, закодованого в програмному забезпеченні ноди. Якщо цей стан скомпрометований, інформація ноди про весь реєстр може бути викривлена.
Припускаючи, що програмне забезпечення ноди не пошкоджене, нові ноди, що приєднуються до мережі, потребують початкового списку пірів нод, до яких вони повинні під’єднатися в першу чергу для того, щоб виявити мережу. Цей список жорстко закодований в програмному забезпеченні ноди (див. документацію Bitcoin). Якщо всі піри ноди, вказані в цьому початковому списку, скомпрометовані, нода може опинитися в іншій (не Bitcoin) мережі, навіть якщо програмне забезпечення самої ноди не скомпрометоване. Таким чином, мережа Bitcoin також вимагає довіри принаймні до одного з початкових пірів нод.
Зауважте, що потрапляння в неправильну мережу можна виявити, перевіривши хеші блоків із зовнішнім джерелом. Але для цього потрібно довіряти ще одному джерелу даних.
Приклад бутстреппінгу в Massa
Ситуація з Massa дуже схожа на ситуацію з Bitcoin. Тримачі нод, також повинні довіряти джерелу програмного забезпечення ноди, яке вони завантажують, а також початковому списку пірів ноди.
Подібно до чекпоінтів Bitcoin, бустрапінг нод Massa повинен отримувати поточний стан з довіреного джерела, в ідеалі з того ж джерела, з якого вони завантажили програмне забезпечення ноди, щоб уникнути необхідності довіряти декільком джерелам.
Завантаження стану з ненадійного джерела може призвести до серйозних проблем, таких як викрадення монет. Таким чином, завантаження з ненадійних джерел не повинно заохочуватися, а завантаження інших нод повинно бути доступним для тримачів нод, щоб уникнути розповсюдження “списків завантаження” як способу завантаження за замовчуванням з необізнаних тримачів нод.
Особливості реалізації
Процедура з точки зору ноди Massa, що здійснює бутстреппінг
Ноди Massa, що проходять через процес бутстрепу, починають з’єднання з випадково обраними нодами з числа тих, що перераховані в файлі massa node/base_config/config.toml
(section Bootstrap/bootstrap_list).
Процес бутстрепу використовує окремий порт і протокол, відмінний від звичайного зв’язку Massa.
Для запобігання атакам типу “man-in-the-middle” всі комунікації з обраною нодою бутстрепу аутентифікуються за допомогою відкритого ключа (ідентифікатора ноди) ноди бутстрепу (у файлі config.toml, розділ Bootstrap/bootstrap_list).
Потім нода, що проходять через процес бутстрепу, намагається завантажити поточний стан, а також початковий список пірів з ноди бутстрепу.
Після успішного завершення процесу бустрапу, нода може з’єднуватися з пірами, виявляти решту мережі та обробляти вхідні блоки, щоб підтримувати свій стан в актуальному стані.
У Massa, хеш стану використовується як частина proof-of-stake, що є механізмом захисту від зловмисних бутстреп-нод, які надсилають скомпрометований стан. Він гарантує, що ноди зі зміненим станом в кінцевому підсумку виявляться ізольованими від реальної мережі, тому що їхні алгоритми proof-of-stake відрізняються, що змушує їх відкидати вхідні чесні блоки. Зауважте, однак, що невідповідність PoS може зайняти до 2 циклів, щоб бути виявленою.
У разі невдалого бутстрепу, нода бутстрепу повторює спробу з іншим випадково обраною нодою бутстрепу після деякої затримки.
Процедура з точки зору бутстреппінгу в самій ноді Massa
Ноди Massa можуть здійснювати бутстреп інших нод, з певними обмеженнями, оскільки ця процедура є важкою для бутстреп-ноди.
Система бутстрепу підключається за адресою/портом, визначеним у файлі massa-node/base_config/config.toml
(розділ bootstrap/bind). Сервер бутстрепу ноди можна відключити, видаливши запис bind з конфігураційного файлу.
Massa State має великий розмір (~1 терабайт у найгіршому випадку) і потребує часу для завантаження на ноди бутстреппінгу. Протягом цього часу продовжують з’являтися нові зміни в стані, тому нові зміни, що впливають на вже завантажені частини, повинні надсилатися “на льоту”.
За замовчуванням, ноди Massa дозволяють здійснювати бустстрап з них тільки для білого списку IP-адрес. Цей список знаходиться у файлі massa-node/base_config/bootstrap_whitelist.json. Цей список призначений для запобігання flooding-атак з боку зловмисників, які видають себе за бутстреп-ноду, а також ускладнює завантаження нод з ненадійних джерел. Якщо ви хочете відключити білий список і дозволити будь-кому завантажуватися з вашої ноди, просто видаліть файл bootstrap_whitelist.json і перезавантажте вашу ноду.
Додатковий файл bootstrap_blacklist.json (відсутній за замовчуванням) також може бути створений разом з bootstrap_whitelist.json (і за тим же синтаксисом) для того, щоб явно заборонити певним IP-адресам здійснювати бутстреп з ноди.
Після того, як нода погодилася на бутстреп вхідної ноди, вона додає IP-адресу вхідної ноди до локального кешу, запобігаючи повторному завантаженню цієї IP-адреси протягом часу, визначеного в файлі massa-node/base_config/config.toml (розділ bootstrap/per_ip_min_interval), відмовляючи в наступних з’єднаннях з цієї IP-адреси протягом визначеної в конфігурації затримки. Затримка виключення не продовжується, якщо віддалена IP-адреса намагається встановити нові з’єднання під час затримки виключення. Затримка виключення, однак, застосовується, якщо бутстреп був прийнятий, але не відбувся з будь-якої причини. Це має на меті обмежити навантаження на окремі ноди бутстрепу та розподілити навантаження між нодами бутстрепу.
Кількість нод, що одночасно завантажуються з локальної ноди, обмежена (massa-node/base_config/config.toml
розділ bootstrap/max_simultaneous_bootstraps). Надлишкові спроби відхиляються, але не запускають механізм затримки виключення.
Майбутні оптимізації Massa
Ми плануємо додати можливість завантажувати дані бутстрепу з ненадійних джерел для балансування навантаження, але потім перевіряти хеш отриманого стану з довірених джерел, і тільки в разі невдачі декількох спроб бутстрепу з такого гібридного підходу повертатися до завантаження всього з довірених джерел.
Джерело: Bootstrapping в Massa – документація Massa
✅ПЕРЕГЛЯНЬТЕ ПОВНИЙ ГАЙД ПО ЗАПУСКУ НОДИ MASSA
Приєднуйтесь до нашої української спільноти в telegram: https://t.me/massa_ua
Вебсайт: massa.net
Explorer тестової мережі: test.massa.net
Документація: https://massa.readthedocs.io/
Вихідний код та посібники: github.com/massalabs/massa
Телеграм: t.me/massanetwork
Discord: discord.gg/massa
Twitter: https://twitter.com/MassaLabs
Reddit: reddit.com/r/massa/
YouTube: youtube.com/channel/UChVfdvYpn0eFk4B-T7TGmOg
