Запуск Shardeum: революційне досягнення
У понеділок, 27 січня 2024 року, у світі web3 сталася революційна подія, яку можна порівняти з історичним подвигом космічного корабля, який ідеально повернувся на свій стартовий майданчик після своєї першої випробувальної місії. У цьому надзвичайному сценарії Shardeum не тільки зіткнувся з важкими випробуваннями, але й вийшов переможцем, завдяки своїй відмовостійкості мережі, що стало першим випадком, коли шард-мережа могла самовідновлюватися в сфері технології розподіленого реєстру.
Подібно до того, як подорож космічним кораблем передбачає ретельне планування, точне проектування та безперебійне виконання складних маневрів, відновлення бетанету Сфінкса Шардеума, який зазнав критичної катастрофи, вимагало рівного рівня технологічної майстерності та інновацій. Здатність зберігати всі дані в мережі, особливо в тій, яка працює за допомогою динамічного сегментування стану, є новаторською.
Розпочинаючи це дослідження, ми не лише відзначаємо знакову посадку Shardeum, але й визнаємо це переломним моментом в еволюції технології web3 — стрибком, який може змінити межі стійкості ІТ-мережі та цілісності даних.
Перша мережа Shard для незалежного відновлення та збереження даних
Динамічне обслуговування та відновлення шардової мережі, такої як Shardeum, включає ряд складних технічних проблем, які відрізняють її від традиційних мереж блокчейнів, таких як Bitcoin або Ethereum. У динамічно вираженому шардовому середовищі з автоматичним масштабуванням безперервний перерозподіл і балансування вузлів і ресурсів у різних сегментах має вирішальне значення для оптимізації продуктивності та масштабованості. Ці постійні зміни в архітектурі мережі значно ускладнюють підтримку узгодженості даних, забезпечення стабільності мережі та полегшення ефективного відновлення після збоїв.
Важливість цього виклику підкреслюється при порівнянні реакції Shardeum на коливання вузлів з біткойнами. Мережа Bitcoin підтримує функціональність навіть з невеликою кількістю вузлів, оскільки кожен активний вузол має повний стан і історію транзакцій. Навпаки, кожен активний вузол на Shardeum не має повного стану та історії транзакцій через мережу сегментів Shardeum, і кожен валідатор має лише частину загального стану. Наслідком цього сегментування є те, що всі вузли валідатора стають дуже легкими. Таким чином, це створює безліч інженерних можливостей і викликів. Якщо вузол вийде з ладу, як ми гарантуємо збереження всіх даних? Шардеум має два основних способи.
По-перше, Shardeum використовує динамічне шардування стану, де весь адресний простір розділено (або розділено) відповідно до кількості активних вузлів. Кожен вузол відповідає за призначений йому розділ разом із певним радіусом (R) навколо нього та додатковими розділами (E), що прилягають до нього, забезпечуючи динамічну адаптивність і надійну надлишковість даних у рамках мережі. Таким чином, навіть якщо вузол вийде з ладу, безперервність мережі все ще є, і дані не втрачаються.
По-друге, Shardeum використовує вузли архіву для зберігання повного стану всієї мережі. Це досягається шляхом потокової передачі активними вузлами частково збереженого стану в архіватор для збирання. Завдяки цим двом факторам і оптимізації дизайну, відновлення таких мереж має бути розроблено по-новому, щоб усе ще сприяти корисним функціям, таким як автомасштабування та лінійне масштабування.
Розуміння збоїв
Тепер, коли ми розуміємо основи динамічного шардингу стану та те, що вузли архіватора певним чином задіяні, давайте детальніше розберемо деякі додаткові компоненти та пояснимо їх. Щоб зрозуміти збій і відновлення Shardeum betanet, ми повинні спочатку трохи зрозуміти наступне:
Вузол архіватора
Виявлення відсутніх архіваторів
Режим мережі
Режим відновлення
Розуміння основ кожного з них є важливим, перш ніж ми зануримося в пов’язані з цим помилки, тому давайте подивимося!
Архівний вузол: Inter Stellar Storage
У Shardeum вузли-архіватори, також звані архіваторами, виступають як дуже важлива категорія вузлів, завданням яких є зберігання всіх записів стану та історії мережі. На відміну від активних вузлів, архіватори не беруть участі в процесі консенсусу; Його основна функція полягає в комплексному архівуванні всіх мережевих даних, включаючи транзакції та квитанції. Внесок вузла архіватора має вирішальне значення для підтримки цілісності мережі та забезпечення її безперебійної роботи, тим самим підтверджуючи статус Shardeum як сильної, повної та надійної мережі. Оскільки архіватори є невід’ємною частиною мережі, Shardeum повинен мати протоколи для виявлення архіваторів (та валідаторів), які не відповідають.
Виявлення втраченого архіву: представлено технологію прибульців
Shardeum має протокол під назвою «протокол виявлення втрачених вузлів», який визначає, коли активний вузол стає непрацездатним —«це призначено лише для активних вузлів». Однак Shardeum також має протокол для архіваторів, який робить щось подібне, називається виявленням відсутніх архіваторів. Виявлення відсутності архіватора — це спеціальний протокол, призначений для обробки рідкісних випадків, коли один або кілька архіваторів стають непрацездатними та позначаються як відсутні. Оскільки вузли архівування мають вирішальне значення для підтримки цілісності та доступності історичних даних у мережі, тому критично важливо, щоб у разі, якщо вони не реагують або не працюють, ці критичні події можна було зафіксувати, щоб пом’якшити наступні наслідки. Хоча відсутній архіватор не спричиняє цей конкретний збій, це відбувається через взаємодію між протоколом виявлення відсутнього архіватора та певним режимом мережі. Тепер давайте подивимося, які мережеві режими є в Shardeum.
Режим мережі на Shardeum: NASA не потрібне
Головною інновацією в Shardeum, яка підтримується базовим протоколом Shardus, є структура мережевого режиму. Ці режими виходять за рамки базових робочих умов, реалізуючи складну координацію різних дій вузлів, методів синхронізації даних і систем управління транзакціями. Така конфігурація мережі відіграє важливу роль у підтримці операційної цілісності мережі, особливо в сценаріях, що характеризуються втратою вузлів і даних —«оскільки Shardeum є сегментованою мережею.
На простішому рівні найкращий спосіб зрозуміти мережевий режим у Shardeum — це добре закодований план на випадок непередбачених ситуацій, який забезпечує безперервність роботи всієї мережі — навіть за малоймовірних умов, таких як збої мережі або погіршення роботи всієї мережі. Ця попередньо запрограмована операційна стійкість і відмовостійкість гарантують, що Shardeum завжди буде живим — неважливо, з якими труднощами стикається мережа.
Хоча розуміння помилок не вимагає розуміння кожного аспекту структури мережевого режиму, корисно знати основи. Суть структури мережевого режиму полягає в об’єднанні кількох різних фаз мережі: встановлення, обробки, безпеки, відновлення, перезапуску, відновлення та збою. Ці режими ретельно створені для вирішення різних мережевих ситуацій і надзвичайних ситуацій. Однак у цій статті ми розглядаємо режим відновлення.
Режим відновлення зворотного проектування: Розуелл знову
Режим відновлення є одним із 7 згаданих вище режимів мережі. Режим відновлення запускається, коли кількість активних мережевих вузлів падає нижче попередньо визначеного критичного порогу (на даний момент налаштовано на 75% або нижче). Цей поріг можна регулювати відповідно до вимог мережі. У цьому режимі мережа призупиняє обробку транзакцій програми та синхронізацію даних програми. Ця стратегія розроблена для сприяння розширенню мережі шляхом безперебійної циклічної зміни неактивних вузлів у рамках ротації вузлів, таким чином повертаючи кількість активних вузлів до оптимального рівня, в ідеалі вище 100%.
У режимі відновлення мережева архітектура Shardeum дозволяє поступове оновлення вузла, обмежене зростанням на 20% за цикл (кожен цикл становить приблизно 60 секунд). Цей контрольований темп зростання має вирішальне значення для підтримки стабільності мережі та забезпечення плавної інтеграції нових вузлів. Швидке збільшення кількості вузлів, наприклад стрибок на 50%, потенційно може дестабілізувати мережу та ускладнити процес інтеграції.
Кожен щойно доданий вузол вимагає мережевих ресурсів для синхронізації та інтеграції. Обмежуючи оновлення 20% за цикл, мережа гарантує, що її інфраструктура може адекватно підтримувати додавання нових вузлів без напруги. Цей підхід не тільки підтримує стабільність мережі, але й мінімізує ризик неузгодженості даних або помилок під час процесу синхронізації, таким чином зберігаючи цілісність даних ланцюжка циклу.
Основні причини збоїв: Event Horizon
Важливо зазначити, що є дві різні помилки. Помилка бібліотеки Neon — яка спричиняла випадкові збої валідаторів і помилка в протоколі виявлення відсутнього архіватора — який не приймав порожній список валідаторів. Хоча саме помилка протоколу виявлення відсутнього архіватора спричиняє збій поточної версії Betanet, я хотів би запросити вас спочатку обговорити помилку неонової бібліотеки.
У версії Sphinx 1.9.1 ми інтегрували оновлення бібліотеки, яка використовує зв’язувач Neon для зв’язку функцій Rust і TypeScript, оскільки Shardeum в основному побудовано на TypeScript. Neon відомий своїм інноваційним, хоча й експериментальним, підходом, який часто розширює межі звичайних практик розробки програмного забезпечення. Ця інтеграція спрямована на покращення сумісності між цими двома мовами, забезпечуючи більш ефективне та пряме спілкування в рамках нашої архітектури програмного забезпечення. Однак це спричиняє помилку, через яку вузли випадково виключаються з мережі.
По-друге, у нещодавньому інциденті, який спричинив збій betanet на Shardeum, першопричиною було визначено критичну аномалію, що походить від взаємодії між двома різними підсистемами, згаданими вище: відсутнім механізмом виявлення архіватора та протоколом режиму відновлення мережі.
Цей короткий збій був викликаний одночасною активацією цих двох механізмів, сценарій, який ніколи раніше не зустрічався та не перевірявся. Процес втраченого архіву запускається разом із модом відновлення мережі та через помилку в режимі втраченого архіву, який не приймає порожній список активних вузлів. Це призводить до збою мережі.
Хроніки відновлення: від системного шоку до зіркового пробудження
Отже, що насправді сталося і коли? Хронологічна шкала подій, пов’язаних із збоєм мережі та його вирішенням, така:
Уразливості та початкове оновлення: у мережі є вразливість, позначена процесом linting 1.9.1 у бібліотеці npm (neon). Для вирішення цієї проблеми реалізовано вдосконалення. Однак це вдосконалення ненавмисно викликало виняток, який не було відтворено під час локального тестування.
Періодичні винятки бібліотеки, що спричиняють збої в роботі валідатора: бібліотека, neon, відчуває спорадичні винятки, які спричиняють періодичні збої в роботі валідатора. Незважаючи на те, що мережевий дизайн забезпечує стійкість за рахунок повторного заповнення цих валідаторів, і, на жаль, одночасний час відмови кількох валідаторів запускає режим відновлення мережі.
Запуск режиму відновлення мережі: у режимі відновлення мережі протокол має очистити та відновити список активних вузлів. Основною причиною збою мережі стала одночасна помилка у відсутній системі файлів, яка не містила порожній список валідаторів.
Розв’язання та відновлення мережі: збій було виправлено, і мережу успішно відновлено за допомогою даних, що зберігаються в архіваторі. Це перший випадок в історії, коли збій шардової мережі рівня 1 було успішно відновлено, і всі дані в мережі збереглися недоторканими. Цього ніколи не робили в жодній мережі, не кажучи вже про мережу з динамічним сегментуванням стану. Це досягнення знаменує успішну «ракетну посадку» з точки зору відновлення мережі.
Завершені виправлення: початкові виправлення були впроваджені для вирішення проблем бібліотеки, але в рамках постійних зусиль покращити стабільність мережі було випущено версію 1.9.5. У цьому оновленні представлено єдине, але важливе виправлення помилки, яке вирішує інший випадок збою зв’язування неонів, виявляючи та виправляючи конкретну вразливість без необхідності оновлення всієї мережі. Спочатку користувачі, які працюють на версії 1.9.4, мають можливість залишитися на поточній версії або вибрати оновлення до 1.9.5, виходячи з їхньої оцінки продуктивності мережі та параметрів стабільності. Однак зрештою було вирішено, що з метою покращення стабільності мережі та вирішення постійних проблем, пов’язаних із зв’язуванням неону, мінімальну версію, необхідну для валідатора, слід збільшити до 1.9.5. Це оновлення має на меті систематичне виключення валідаторів, що працюють на версії 1.9.4, які були визначені як уразливі до збоїв через вищезгадані ускладнення зв’язування неону. Це необхідно для того, щоб переконатися, що неонову помилку було повністю видалено та повністю виправлено.
Тепер, коли ми знаємо про хронологію та про те, як відбувалися основні події, давайте поглянемо на те, що сталося, щоб мережу можна було швидко відновити.
Летить до одужання
Гнучке відновлення
Відновлення мережі складається з багатьох частин, але однією з головних є режим відновлення Shardeum. Як було сказано раніше, режим відновлення запускається, коли кількість активних мережевих вузлів падає нижче попередньо визначеного критичного порогу, і це дозволяє швидко, контрольовано та ефективно розвивати мережу безпечним способом для відновлення мережі. Важливо підкреслити, що без технологічної винахідливості дизайнерів і розробників мережевого режиму —«Shardeum» не зміг би так легко відновитися після збою, а також продемонструвати свою інноваційну майстерність.
Крім того, технологічна команда Shardeum доклала значних зусиль, розпочавши негайні дії. Початковий крок включав ретельний аналіз, щоб визначити першопричину збою , яка була виявлена в аномалії у взаємодії між виявленням відсутніх архівів у мережі та системою режиму відновлення. Розуміючи складність проблеми, команда швидко запровадила багатогранний підхід для усунення безпосередніх наслідків і основних вразливостей.
Змішана відповідь від технологічної групи Shardeum
Технічно відповідь була неоднозначною: спочатку команда ізолювала уражені компоненти, щоб запобігти подальшій деградації тканин. Водночас вони застосували патч, щоб виправити помилку у відсутній системі файлів, гарантуючи, що вона може обробляти порожній список валідатора — критичну помилку, яка спричинила збій мережі. Щоб відновити повну працездатність мережі, дані, що зберігаються в архіві, потім активуються та використовуються для реконструкції стану мережі до збою, гарантуючи, що жодні дані не будуть втрачені під час процесу.
Що стосується логістики, команда координує роботу в різних часових поясах і дисциплінах, використовуючи хмарні інструменти для співпраці та моніторингу в реальному часі. Ці скоординовані зусилля не тільки сприяють швидкій розробці та впровадженню виправлень, але й гарантують узгодженість усіх членів команди щодо процесу відновлення та наступних кроків.
Цей інцидент став суворим тестом протоколів керування збоями Shardeum і підкреслив важливість гнучкого та інноваційного реагування на несподівані виклики. Це підкреслює прагнення команди підтримувати стійку та безпечну мережу, готову долати складні технічні перешкоди, коли вони виникають.
Інновації щодо безпечної та космічної посадки
Підсумовуючи, успішне відновлення шард-мережі Shardeum знаменує значний зсув у мережевих технологіях, знаменуючи віху з далекосяжними наслідками для галузі. Хоча наразі маловідомі інновації, такі як мережевий режим, з часом встановлять нові галузеві стандарти в web3.
Я давно вірив, що ключові інновації Shardeum дуже ймовірно вплинуть на майбутні технологічні розробки, надихаючи на інновації та нове покоління технології бухгалтерської книги. Будучи безпосереднім свідком першого в історії відновлення мережі Shardeum, я знав, що це стане каталізатором для переоцінки галузевих стандартів, що потенційно призведе до прийняття більш суворих протоколів і методологій у проектуванні та архітектурі мережі.
Ця подія не тільки продемонструвала технічну майстерність та інновації команди Shardeum, але й ознаменувала початок ери, коли децентралізовані мережі стають більш надійними, адаптованими та здатними вирішувати непередбачені проблеми, коли справа доходить до планування аварійного відновлення. Зрештою, технологія Shardeum стане провісником нової ери децентралізації.