Недавно Sui громадський ланцюг також зіткнувся з тимчасовою проблемою зупинки блоків, після двох з половиною годин зупинки блоків Sui офіційно опублікував звіт про цю подію. Проте Sui, який пропагує високопродуктивний громадський ланцюг, після зупинки блоків також нагадує про минулі роки Solana. Порівнявши їх, хоча мова програмування і архітектура дуже різні, обидва пропагують високопродуктивний громадський ланцюг, але також критикуються за недостатню Децентралізація.
Чому один код управління заторами спричинив крах всіх валідаторів
У звіті зазначено, що 21 листопада 2024 року о 1:15-3:45 за тихоокеанським часом SUI Основна мережа зазнала повного зупину. Всі валідатори потрапили в краховий цикл, що призвело до того, що вся мережа не могла обробляти жодні транзакції. Цей випадок підкреслює, що при підвищенні продуктивності високопродуктивних громадських мереж, стабільність все ще потребує високого рівня уваги.
Згідно з офіційним заявою, причиною цієї зупинки є те, що в коді контролю за заторами мережі SUI спрацював фрагмент 'assert!', що спричинив збій валідаторів. Зокрема, мережевий збій виникає, коли виконуються наступні умови:
Активуйте режим обмеження загального бюджету газу з обмеженням TotalGasBudgetWithCap.
Отримано транзакцію з такими ознаками: змінний спільний об'єкт як вхід, без будь-яких інструкцій MoveCall.
Коли така угода входить до мережі, всі валідатори одночасно зламуються, мережа перестає працювати.
Що таке контроль над заторами?
Sui Об'єктно-орієнтована архітектура основної мережі дозволяє багато операцій одночасно, що є способом досягнення високої продуктивності. Однак якщо потрібно записати багато операцій у спільний об'єкт, вони все ще повинні виконуватися послідовно, та швидкість обробки таких операцій обмежена. Щоб уникнути заторів, спричинених спільними об'єктами, Sui вводить механізм управління заторами для обмеження швидкості операцій з одним спільним об'єктом. Додатково автор додає: раніше Фонд Sui під час офлайн зустрічі для читання спільно з XueDAO зазначив, що їхня логіка полягає в тому, щоб об'єднати операції, які мають причинно-наслідкові зв'язки, і виконати їх разом.
А недавно Sui оновила систему контролю за заторами, введено режим TotalGasBudgetWithCap для більш точної оцінки складності транзакцій. Однак у коді цього режиму виявлено уразливість, яка призвела до цього інциденту. Команда Sui заявила, що вжила заходів після виявлення цієї проблеми, і випустила оновлення версій Основна мережа v1.37.4 і Тестова мережа v1.38.1 з виправленнями коду (PR #20365). Громада валідаторів проявила високу ефективність реагування, усього за 15 хвилин після випуску виправлень мережа була відновлена.
Typus протокол: зупинка блоків SUI абсолютно відрізняється від Solana
Зупинка блоків Sui заставляє людей асоціювати її з Solana та навіть TON цього року. Керіє, CGO Typus протоколу Децентралізованих фінансів на Sui, також поділився думками команди у Twitter. Він чітко зазначив, що це цілком відмінно від зупинки блоків на Solana. Проблема Solana полягає в тому, що перевантаження мережі призводить до аварійної зупинки системи, що потребує значних змін в структурі. Це також означає, що проблему Solana короткостроково важко вирішити фундаментально. У випадку з Sui, це чітко технічна проблема, яка не впливає на базову інфраструктуру системи.
Kyrie заявив, що проблема цього збою полягала в переповненні значень при обчисленні Вартість транзакції. Щоб пояснити це просто, це схоже на те, що на дисплеї калькулятора не вистачає розрядів, тому коли число стає занадто великим, воно повертається до нуля для повторного обчислення. В цих умовах система потрапляє в безкінечний цикл, що в кінцевому підсумку призводить до зупинки всієї мережі.
Коли обчислення системи перевищують діапазон, який може бути збережений, в оригінальному дизайні неправильне обчислення було викликано перевищенням діапазону, що призводило до постійних повторюваних операцій системою. Після виправлення в PR #20365 було встановлено правильний верхній діапазон обчислення, що уникне такої ситуації. Він також зауважив, що ключовою проблемою в цьому випадку є логіка програмного забезпечення, яке обчислює Вартість транзакції, а не Механізм консенсусу SUI або дизайн системи. Це пояснює, чому виправлення можливо було так швидко та безпосередньо.
Franklin Templeton та SUI оголосили про партнерство
Незадовго до кінцевого терміну надійшла важлива звістка: наступного дня після зупинки блоків, Sui Foundation оголосила про співпрацю з Franklin Templeton. У заяві Franklin Templeton згадується Deepbook, Karrier One та ika, трипротоколи та інфраструктура. Однак, з огляду на діяльність Franklin Templeton у сфері блокчейну, можна очікувати поєднання Sui, орієнтованої на об'єкти, найбільш безпечної громадської ланки та RWA.
Ця стаття SUI вперше зупинилася після запуску: розробники стверджують, що проблем немає, наступного дня Franklin Templeton оголосив про співпрацю, найраніше з'явилася на Ланцюгові новини ABMedia.
SUI перший раз зупинився після запуску: розробники стверджують, що проблем немає, наступного дня Franklin Templeton оголосив про співпрацю
Недавно Sui громадський ланцюг також зіткнувся з тимчасовою проблемою зупинки блоків, після двох з половиною годин зупинки блоків Sui офіційно опублікував звіт про цю подію. Проте Sui, який пропагує високопродуктивний громадський ланцюг, після зупинки блоків також нагадує про минулі роки Solana. Порівнявши їх, хоча мова програмування і архітектура дуже різні, обидва пропагують високопродуктивний громадський ланцюг, але також критикуються за недостатню Децентралізація.
Чому один код управління заторами спричинив крах всіх валідаторів
У звіті зазначено, що 21 листопада 2024 року о 1:15-3:45 за тихоокеанським часом SUI Основна мережа зазнала повного зупину. Всі валідатори потрапили в краховий цикл, що призвело до того, що вся мережа не могла обробляти жодні транзакції. Цей випадок підкреслює, що при підвищенні продуктивності високопродуктивних громадських мереж, стабільність все ще потребує високого рівня уваги.
Згідно з офіційним заявою, причиною цієї зупинки є те, що в коді контролю за заторами мережі SUI спрацював фрагмент 'assert!', що спричинив збій валідаторів. Зокрема, мережевий збій виникає, коли виконуються наступні умови:
Активуйте режим обмеження загального бюджету газу з обмеженням TotalGasBudgetWithCap.
Отримано транзакцію з такими ознаками: змінний спільний об'єкт як вхід, без будь-яких інструкцій MoveCall.
Коли така угода входить до мережі, всі валідатори одночасно зламуються, мережа перестає працювати.
Що таке контроль над заторами?
Sui Об'єктно-орієнтована архітектура основної мережі дозволяє багато операцій одночасно, що є способом досягнення високої продуктивності. Однак якщо потрібно записати багато операцій у спільний об'єкт, вони все ще повинні виконуватися послідовно, та швидкість обробки таких операцій обмежена. Щоб уникнути заторів, спричинених спільними об'єктами, Sui вводить механізм управління заторами для обмеження швидкості операцій з одним спільним об'єктом. Додатково автор додає: раніше Фонд Sui під час офлайн зустрічі для читання спільно з XueDAO зазначив, що їхня логіка полягає в тому, щоб об'єднати операції, які мають причинно-наслідкові зв'язки, і виконати їх разом.
А недавно Sui оновила систему контролю за заторами, введено режим TotalGasBudgetWithCap для більш точної оцінки складності транзакцій. Однак у коді цього режиму виявлено уразливість, яка призвела до цього інциденту. Команда Sui заявила, що вжила заходів після виявлення цієї проблеми, і випустила оновлення версій Основна мережа v1.37.4 і Тестова мережа v1.38.1 з виправленнями коду (PR #20365). Громада валідаторів проявила високу ефективність реагування, усього за 15 хвилин після випуску виправлень мережа була відновлена.
Typus протокол: зупинка блоків SUI абсолютно відрізняється від Solana
Зупинка блоків Sui заставляє людей асоціювати її з Solana та навіть TON цього року. Керіє, CGO Typus протоколу Децентралізованих фінансів на Sui, також поділився думками команди у Twitter. Він чітко зазначив, що це цілком відмінно від зупинки блоків на Solana. Проблема Solana полягає в тому, що перевантаження мережі призводить до аварійної зупинки системи, що потребує значних змін в структурі. Це також означає, що проблему Solana короткостроково важко вирішити фундаментально. У випадку з Sui, це чітко технічна проблема, яка не впливає на базову інфраструктуру системи.
Kyrie заявив, що проблема цього збою полягала в переповненні значень при обчисленні Вартість транзакції. Щоб пояснити це просто, це схоже на те, що на дисплеї калькулятора не вистачає розрядів, тому коли число стає занадто великим, воно повертається до нуля для повторного обчислення. В цих умовах система потрапляє в безкінечний цикл, що в кінцевому підсумку призводить до зупинки всієї мережі.
Коли обчислення системи перевищують діапазон, який може бути збережений, в оригінальному дизайні неправильне обчислення було викликано перевищенням діапазону, що призводило до постійних повторюваних операцій системою. Після виправлення в PR #20365 було встановлено правильний верхній діапазон обчислення, що уникне такої ситуації. Він також зауважив, що ключовою проблемою в цьому випадку є логіка програмного забезпечення, яке обчислює Вартість транзакції, а не Механізм консенсусу SUI або дизайн системи. Це пояснює, чому виправлення можливо було так швидко та безпосередньо.
Franklin Templeton та SUI оголосили про партнерство
Незадовго до кінцевого терміну надійшла важлива звістка: наступного дня після зупинки блоків, Sui Foundation оголосила про співпрацю з Franklin Templeton. У заяві Franklin Templeton згадується Deepbook, Karrier One та ika, трипротоколи та інфраструктура. Однак, з огляду на діяльність Franklin Templeton у сфері блокчейну, можна очікувати поєднання Sui, орієнтованої на об'єкти, найбільш безпечної громадської ланки та RWA.
Ця стаття SUI вперше зупинилася після запуску: розробники стверджують, що проблем немає, наступного дня Franklin Templeton оголосив про співпрацю, найраніше з'явилася на Ланцюгові новини ABMedia.