Цей інцидент є перемогою капіталу, а не користувачів, і це є відступом у розвитку індустрії.
Біткоїн зліва, Суй справа, кожен трясіння у децентралізованій індустрії приносить сильнішу віру в Біткоїн.
Світ потребує не лише кращої глобальної фінансової інфраструктури, але завжди буде група людей, яким потрібен вільний простір.
Колись консорціумні ланцюги були популярнішими за публічні ланцюги, оскільки вони відповідали регуляторним потребам тієї ери. Сьогодні зниження популярності консорціумних ланцюгів насправді означає, що просте дотримання цієї вимоги не відображає реальні потреби користувачів. З втратою регульованих користувачів, яка потреба в регуляторних інструментах?
22 травня 2025 року Cetus, найбільша децентралізована біржа (DEX) в екосистемі публічної ланцюга Sui, зазнала хакерської атаки, що призвело до моментального падіння ліквідності, обвалу цін на кілька торгових пар та збитків, які перевищили 220 мільйонів доларів.
На момент публікації графік виглядає так:
Щодо принципів подій, індустрія вже опублікувала кілька заяв. Тут ми лише надаємо огляд основних принципів:
З точки зору процесу атаки:
Зловмисник спочатку позичив приблизно 10,024,321.28 haSUI, використовуючи флеш-кредит, що миттєво спричинило падіння ціни в торговому пулі.
99.90%. Ця масивна продажна заявка призвела до зниження ціни цільового пулу з приблизно 1.8956×10^19 до 1.8425×10^19, практично очистивши його.
Потім зловмисник створив ліквідність на Cetus у дуже вузькому діапазоні (нижня межа Тіка 300000, верхня межа 300200, з шириною діапазону лише 1.00496621%). Такий вузький діапазон посилює вплив наступних помилок у розрахунках на необхідну кількість токенів.
Основний принцип атаки:
У функції get_delta_a, що використовується Cetus для розрахунку необхідної кількості токенів, є вразливість переповнення цілого числа. Зловмисник навмисно стверджує, що додає величезну ліквідність (приблизно 10^37 одиниць), але насправді вносить лише 1 токен до контракту.
Через неправильну умову виявлення переповнення функції checked_shlw, контракт зазнав обрізання старших бітів під час обчислень зліва, що призвело до серйозного недооцінювання необхідної кількості haSUI, внаслідок чого було отримано величезну кількість ліквідності за надзвичайно низькою ціною.
Технічно, вищезгадана вразливість виникає внаслідок того, що Cetus використовує неправильні маски та умови судження в смарт-контракті Move, що дозволяє будь-якому значенню менше ніж 0xffffffffffffffff << 192 уникнути виявлення; більш того, дані високого порядку обрізаються після зсуву вліво на 64 біти, що змушує систему вірити, що вона отримала значну ліквідність з лише невеликою кількістю зібраних токенів.
Після інциденту виникло дві офіційні операції: "Заморозити" проти "Відновити", які є двома фазами:
Сама мережа Sui має спеціальний механізм списку заперечень, який дозволив заморозити кошти цього хакера. Більш того, токен стандарту Sui також має модель "регульованого токена", яка включає вбудовану функцію заморожування.
Ця надзвичайна заморозка використовує цю характеристику: вузли-валідатори швидко додали адреси, пов'язані з вкраденими коштами, у свої локальні файли конфігурації. Теоретично, кожен оператор вузла може змінити TransactionDenyConfig, щоб оновити чорний список, але для забезпечення узгодженості мережі Фонд Суй, як оригінальний видавець конфігурації, координував дії централізовано.
Фонд спочатку офіційно випустив оновлення конфігурації, що містить адресу хакера, і валідатори синхронізувалися відповідно до стандартної конфігурації, тимчасово "закривши" кошти хакера в ланцюгу. Насправді, за цим стоять високі централізовані фактори.
Щоб врятувати жертв від заморожених коштів, команда Sui швидко запустила патч механізму білого списку.
Це для операції з переказу коштів назад у майбутньому. Ви можете попередньо створити законні транзакції та зареєструвати їх у білому списку. Навіть якщо адреса фонду все ще в чорному списку, її все ще можна примусово виконати.
Ця нова функція transaction_allow_list_skip_all_checks дозволяє конкретним транзакціям бути попередньо доданими до "списку винятків", що дає змогу цим транзакціям пропускати всі перевірки безпеки, включаючи підписи, дозволи, чорні списки тощо.
Важливо зазначити, що патч білої списки не захоплює активи хакера безпосередньо; він лише надає певним транзакціям можливість обійти замороження, тоді як фактичний переказ активів все ще вимагає законного підпису або додаткових модулів системного дозволу для завершення.
Насправді, основні рішення для заморожування в галузі часто відбуваються на рівні токен-контракту і контролюються мультипідписами від випускника.
Використовуючи USDT, випущений компанією Tether, як приклад, його контракт має вбудовану функцію чорного списку, що дозволяє випусковій компанії заморожувати адреси, які не відповідають вимогам, запобігаючи їх передачі USDT. Ця схема вимагає мультипідпису для ініціювання запиту на замороження в блокчейні, і вона виконується лише після досягнення консенсусу за мультипідписом, таким чином, існує затримка в виконанні.
Механізм заморожування Tether є ефективним, але статистика показує, що процес мультипідпису часто має "вікна можливостей", що залишає простір для злочинців, щоб скористатися цим.
На відміну від цього, заморожування Sui відбувається на рівні базового протоколу, яке здійснюється колективно вузлами-валидаторами, з швидкістю, що значно перевищує швидкість звичайних викликів контрактів.
У цій моделі швидке виконання означає, що управління цими вузлами-валидаторами є високоуніфікованим.
Ще більш вражаюче, Sui не лише заморозила активи хакера, але й планує реалізувати ончейн-оновлення, щоб "повернути" вкрадені кошти.
27 травня Cetus запропонував план голосування для спільноти щодо оновлення протоколу та відправлення заморожених коштів до мультипідписного гаманця зберігання. Фонд Sui негайно розпочав голосування з управління в ланцюзі.
29 травня було оголошено результати голосування, згідно з якими приблизно 90,9% вагових валідаторів підтримали пропозицію. Представники Sui оголосили, що після затвердження пропозиції "всі кошти, заморожені на двох рахунках Хакера, будуть повернуті до мультипідписного гаманця без необхідності підписів Хакера."
Не потрібно підпису хакера, яка унікальна особливість, у блокчейн-індустрії ніколи не було такого методу ремонту.
З офіційного PR Sui на GitHub зрозуміло, що протокол запровадив механізм адресного псевдонімування. Оновлення включає: попереднє визначення правил псевдонімів у ProtocolConfig, що дозволяє певним дозволеним транзакціям вважати дійсні підписи такими, що надіслані з акаунтів хакерів.
Зокрема, список хешів транзакцій порятунку, які мають бути виконані, прив'язаний до цільової адреси (тобто адреси Хакера). Будь-який виконавець, який підписує та публікує ці фіксовані резюме транзакцій, вважається таким, що ініціював транзакцію як дійсний власник адреси Хакера. Для цих конкретних транзакцій система вузлів-валидаторів обійде перевірку зі списку заборон.
З точки зору коду, Sui додав наступну перевірку в логіку валідації транзакцій: коли транзакція перехоплюється чорним списком, система ітерується по її підписантам, щоб перевірити, чи є protocol_config.is_tx_allowed_via_aliasing(sender, signer, tx_digest) істинним.
Доки є підписувач, який відповідає правилу псевдоніму, транзакція, позначена як дозволена для проходження, ігноруватиме попередні помилки перехоплення та продовжить упаковуватись і виконуватись нормально.
Інцидент з Cetus, з моєї особистої точки зору, може швидко забутися, але ця модель не буде забута, оскільки вона підриває основи галузі і руйнує традиційний консенсус незмінності в блокчейні під одним реєстром.
У дизайні блокчейну контракти є законом, а код - арбітром.
Проте в цьому інциденті код не спрацював, втрутилася система управління, і влада переважила, сформувавши модель "поведінки голосування, що adjudicate результати коду."
Причина в тому, що пряме присвоєння транзакцій Sui різко контрастує з тим, як основні блокчейни вирішують проблеми з хакерами.
Історично:
Це той самий шаблон жорсткого форку, повертаючи реєстр до того, як виникла проблема, після чого користувачі все ще можуть вирішити, яку систему реєстру продовжити використовувати.
На відміну від жорсткого форку DAO, Sui не обрала розділити ланцюг, а натомість точно націлилася на цю подію через оновлення протоколу та конфігураційні псевдоніми. Завдяки цьому Sui підтримує безперервність ланцюга та зберігає більшість правил консенсусу незмінними, водночас вказуючи на те, що підлягаючий протокол може бути використаний для реалізації цілеспрямованих "рятувальних операцій."
Проблема в тому, що історично "відкат на основі форків" є справою вибору користувача; "корекції на основі протоколу" Sui є рішеннями, прийнятими від імені ланцюга.
У довгостроковій перспективі це означає, що ідея "Не ваші ключі, не ваші монети" підривається в мережі Sui: навіть якщо користувачі мають повні приватні ключі, мережа все ще може запобігти переміщенню активів і перенаправити активи через колективні зміни протоколу.
Якщо це стане прецедентом для блокчейну в реагуванні на великі інциденти безпеки в майбутньому, або навіть буде вважатися практикою, до якої можна буде знову звертатися.
"Коли ланцюг може порушити правила справедливості, це встановлює прецедент для порушення будь-якого правила."
Якщо відбудеться успішний «громадський збір коштів», наступного разу це може бути операція в «моральній сірій зоні».
Що тоді станеться?
Зломщик дійсно викрав гроші користувача, тож чи може групове голосування забрати його гроші?
Чи базується голосування на тому, хто має більше грошей (pos), чи на тому, хто має більше людей? Якщо переможе той, хто має більше грошей, тоді остаточний виробник у творах Лю Цисіня незабаром з'явиться. Якщо переможе той, хто має більше людей, тоді хаотична натовп також дасть про себе знати.
У традиційних системах дуже звично, що незаконні прибутки не підлягають захисту, а замороження та переказ є звичайними операціями традиційних банків.
Але з технічно-теоретичної точки зору це не може бути досягнуто, хіба це не є коренем розвитку індустрії блокчейн?
Палка промислової відповідності постійно ферментується. Сьогодні вона може заморожувати та змінювати баланси рахунків для хакерів, а завтра може здійснювати довільні зміни через геополітичні фактори та фактори конфлікту. Якщо ланцюг стане регіональним інструментом.
Вартість цієї індустрії також була суттєво знижена, в кращому випадку це просто ще одна версія менш корисної фінансової системи.
Це також причина, чому автор є стійким у цій галузі: "Блокчейн цінний не тому, що його не можна заморозити, а тому, що він не змінюється для вас, навіть якщо ви його ненавидите."
Колись консорціумні блокчейни були більш популярними, ніж публічні блокчейни, оскільки вони відповідали регуляторним вимогам тієї епохи. Сьогодні зменшення популярності консорціумів насправді означає, що просте дотримання цих вимог не відображає справжніх потреб користувачів. Користувачі, які загублені через регуляції, ставлять питання про те, які регуляторні інструменти потрібні.
З точки зору розвитку галузі
"Ефективна централізація"—чи є це необхідним етапом у розвитку блокчейну? Якщо остатня мета децентралізації полягає в захисті інтересів користувачів, чи можемо ми терпіти централізацію як перехідний засіб?
Термін "демократія" в контексті управління в блокчейні насправді є вагомим за токенами. Тож, якщо хакер володіє великою кількістю SUI (або одного дня DAO буде зламано, і хакер контролює права голосу), чи можуть вони також "легально проголосувати за своє виправдання"?
Врешті-решт, цінність блокчейну полягає не в тому, чи можна його заморозити, а в виборі не робити цього, навіть коли група має можливість заморозити.
Майбутнє блокчейну визначається не його технічною архітектурою, а набором переконань, які він обирає підтримувати.
Цей інцидент є перемогою капіталу, а не користувачів, і це є відступом у розвитку індустрії.
Біткоїн зліва, Суй справа, кожен трясіння у децентралізованій індустрії приносить сильнішу віру в Біткоїн.
Світ потребує не лише кращої глобальної фінансової інфраструктури, але завжди буде група людей, яким потрібен вільний простір.
Колись консорціумні ланцюги були популярнішими за публічні ланцюги, оскільки вони відповідали регуляторним потребам тієї ери. Сьогодні зниження популярності консорціумних ланцюгів насправді означає, що просте дотримання цієї вимоги не відображає реальні потреби користувачів. З втратою регульованих користувачів, яка потреба в регуляторних інструментах?
22 травня 2025 року Cetus, найбільша децентралізована біржа (DEX) в екосистемі публічної ланцюга Sui, зазнала хакерської атаки, що призвело до моментального падіння ліквідності, обвалу цін на кілька торгових пар та збитків, які перевищили 220 мільйонів доларів.
На момент публікації графік виглядає так:
Щодо принципів подій, індустрія вже опублікувала кілька заяв. Тут ми лише надаємо огляд основних принципів:
З точки зору процесу атаки:
Зловмисник спочатку позичив приблизно 10,024,321.28 haSUI, використовуючи флеш-кредит, що миттєво спричинило падіння ціни в торговому пулі.
99.90%. Ця масивна продажна заявка призвела до зниження ціни цільового пулу з приблизно 1.8956×10^19 до 1.8425×10^19, практично очистивши його.
Потім зловмисник створив ліквідність на Cetus у дуже вузькому діапазоні (нижня межа Тіка 300000, верхня межа 300200, з шириною діапазону лише 1.00496621%). Такий вузький діапазон посилює вплив наступних помилок у розрахунках на необхідну кількість токенів.
Основний принцип атаки:
У функції get_delta_a, що використовується Cetus для розрахунку необхідної кількості токенів, є вразливість переповнення цілого числа. Зловмисник навмисно стверджує, що додає величезну ліквідність (приблизно 10^37 одиниць), але насправді вносить лише 1 токен до контракту.
Через неправильну умову виявлення переповнення функції checked_shlw, контракт зазнав обрізання старших бітів під час обчислень зліва, що призвело до серйозного недооцінювання необхідної кількості haSUI, внаслідок чого було отримано величезну кількість ліквідності за надзвичайно низькою ціною.
Технічно, вищезгадана вразливість виникає внаслідок того, що Cetus використовує неправильні маски та умови судження в смарт-контракті Move, що дозволяє будь-якому значенню менше ніж 0xffffffffffffffff << 192 уникнути виявлення; більш того, дані високого порядку обрізаються після зсуву вліво на 64 біти, що змушує систему вірити, що вона отримала значну ліквідність з лише невеликою кількістю зібраних токенів.
Після інциденту виникло дві офіційні операції: "Заморозити" проти "Відновити", які є двома фазами:
Сама мережа Sui має спеціальний механізм списку заперечень, який дозволив заморозити кошти цього хакера. Більш того, токен стандарту Sui також має модель "регульованого токена", яка включає вбудовану функцію заморожування.
Ця надзвичайна заморозка використовує цю характеристику: вузли-валідатори швидко додали адреси, пов'язані з вкраденими коштами, у свої локальні файли конфігурації. Теоретично, кожен оператор вузла може змінити TransactionDenyConfig, щоб оновити чорний список, але для забезпечення узгодженості мережі Фонд Суй, як оригінальний видавець конфігурації, координував дії централізовано.
Фонд спочатку офіційно випустив оновлення конфігурації, що містить адресу хакера, і валідатори синхронізувалися відповідно до стандартної конфігурації, тимчасово "закривши" кошти хакера в ланцюгу. Насправді, за цим стоять високі централізовані фактори.
Щоб врятувати жертв від заморожених коштів, команда Sui швидко запустила патч механізму білого списку.
Це для операції з переказу коштів назад у майбутньому. Ви можете попередньо створити законні транзакції та зареєструвати їх у білому списку. Навіть якщо адреса фонду все ще в чорному списку, її все ще можна примусово виконати.
Ця нова функція transaction_allow_list_skip_all_checks дозволяє конкретним транзакціям бути попередньо доданими до "списку винятків", що дає змогу цим транзакціям пропускати всі перевірки безпеки, включаючи підписи, дозволи, чорні списки тощо.
Важливо зазначити, що патч білої списки не захоплює активи хакера безпосередньо; він лише надає певним транзакціям можливість обійти замороження, тоді як фактичний переказ активів все ще вимагає законного підпису або додаткових модулів системного дозволу для завершення.
Насправді, основні рішення для заморожування в галузі часто відбуваються на рівні токен-контракту і контролюються мультипідписами від випускника.
Використовуючи USDT, випущений компанією Tether, як приклад, його контракт має вбудовану функцію чорного списку, що дозволяє випусковій компанії заморожувати адреси, які не відповідають вимогам, запобігаючи їх передачі USDT. Ця схема вимагає мультипідпису для ініціювання запиту на замороження в блокчейні, і вона виконується лише після досягнення консенсусу за мультипідписом, таким чином, існує затримка в виконанні.
Механізм заморожування Tether є ефективним, але статистика показує, що процес мультипідпису часто має "вікна можливостей", що залишає простір для злочинців, щоб скористатися цим.
На відміну від цього, заморожування Sui відбувається на рівні базового протоколу, яке здійснюється колективно вузлами-валидаторами, з швидкістю, що значно перевищує швидкість звичайних викликів контрактів.
У цій моделі швидке виконання означає, що управління цими вузлами-валидаторами є високоуніфікованим.
Ще більш вражаюче, Sui не лише заморозила активи хакера, але й планує реалізувати ончейн-оновлення, щоб "повернути" вкрадені кошти.
27 травня Cetus запропонував план голосування для спільноти щодо оновлення протоколу та відправлення заморожених коштів до мультипідписного гаманця зберігання. Фонд Sui негайно розпочав голосування з управління в ланцюзі.
29 травня було оголошено результати голосування, згідно з якими приблизно 90,9% вагових валідаторів підтримали пропозицію. Представники Sui оголосили, що після затвердження пропозиції "всі кошти, заморожені на двох рахунках Хакера, будуть повернуті до мультипідписного гаманця без необхідності підписів Хакера."
Не потрібно підпису хакера, яка унікальна особливість, у блокчейн-індустрії ніколи не було такого методу ремонту.
З офіційного PR Sui на GitHub зрозуміло, що протокол запровадив механізм адресного псевдонімування. Оновлення включає: попереднє визначення правил псевдонімів у ProtocolConfig, що дозволяє певним дозволеним транзакціям вважати дійсні підписи такими, що надіслані з акаунтів хакерів.
Зокрема, список хешів транзакцій порятунку, які мають бути виконані, прив'язаний до цільової адреси (тобто адреси Хакера). Будь-який виконавець, який підписує та публікує ці фіксовані резюме транзакцій, вважається таким, що ініціював транзакцію як дійсний власник адреси Хакера. Для цих конкретних транзакцій система вузлів-валидаторів обійде перевірку зі списку заборон.
З точки зору коду, Sui додав наступну перевірку в логіку валідації транзакцій: коли транзакція перехоплюється чорним списком, система ітерується по її підписантам, щоб перевірити, чи є protocol_config.is_tx_allowed_via_aliasing(sender, signer, tx_digest) істинним.
Доки є підписувач, який відповідає правилу псевдоніму, транзакція, позначена як дозволена для проходження, ігноруватиме попередні помилки перехоплення та продовжить упаковуватись і виконуватись нормально.
Інцидент з Cetus, з моєї особистої точки зору, може швидко забутися, але ця модель не буде забута, оскільки вона підриває основи галузі і руйнує традиційний консенсус незмінності в блокчейні під одним реєстром.
У дизайні блокчейну контракти є законом, а код - арбітром.
Проте в цьому інциденті код не спрацював, втрутилася система управління, і влада переважила, сформувавши модель "поведінки голосування, що adjudicate результати коду."
Причина в тому, що пряме присвоєння транзакцій Sui різко контрастує з тим, як основні блокчейни вирішують проблеми з хакерами.
Історично:
Це той самий шаблон жорсткого форку, повертаючи реєстр до того, як виникла проблема, після чого користувачі все ще можуть вирішити, яку систему реєстру продовжити використовувати.
На відміну від жорсткого форку DAO, Sui не обрала розділити ланцюг, а натомість точно націлилася на цю подію через оновлення протоколу та конфігураційні псевдоніми. Завдяки цьому Sui підтримує безперервність ланцюга та зберігає більшість правил консенсусу незмінними, водночас вказуючи на те, що підлягаючий протокол може бути використаний для реалізації цілеспрямованих "рятувальних операцій."
Проблема в тому, що історично "відкат на основі форків" є справою вибору користувача; "корекції на основі протоколу" Sui є рішеннями, прийнятими від імені ланцюга.
У довгостроковій перспективі це означає, що ідея "Не ваші ключі, не ваші монети" підривається в мережі Sui: навіть якщо користувачі мають повні приватні ключі, мережа все ще може запобігти переміщенню активів і перенаправити активи через колективні зміни протоколу.
Якщо це стане прецедентом для блокчейну в реагуванні на великі інциденти безпеки в майбутньому, або навіть буде вважатися практикою, до якої можна буде знову звертатися.
"Коли ланцюг може порушити правила справедливості, це встановлює прецедент для порушення будь-якого правила."
Якщо відбудеться успішний «громадський збір коштів», наступного разу це може бути операція в «моральній сірій зоні».
Що тоді станеться?
Зломщик дійсно викрав гроші користувача, тож чи може групове голосування забрати його гроші?
Чи базується голосування на тому, хто має більше грошей (pos), чи на тому, хто має більше людей? Якщо переможе той, хто має більше грошей, тоді остаточний виробник у творах Лю Цисіня незабаром з'явиться. Якщо переможе той, хто має більше людей, тоді хаотична натовп також дасть про себе знати.
У традиційних системах дуже звично, що незаконні прибутки не підлягають захисту, а замороження та переказ є звичайними операціями традиційних банків.
Але з технічно-теоретичної точки зору це не може бути досягнуто, хіба це не є коренем розвитку індустрії блокчейн?
Палка промислової відповідності постійно ферментується. Сьогодні вона може заморожувати та змінювати баланси рахунків для хакерів, а завтра може здійснювати довільні зміни через геополітичні фактори та фактори конфлікту. Якщо ланцюг стане регіональним інструментом.
Вартість цієї індустрії також була суттєво знижена, в кращому випадку це просто ще одна версія менш корисної фінансової системи.
Це також причина, чому автор є стійким у цій галузі: "Блокчейн цінний не тому, що його не можна заморозити, а тому, що він не змінюється для вас, навіть якщо ви його ненавидите."
Колись консорціумні блокчейни були більш популярними, ніж публічні блокчейни, оскільки вони відповідали регуляторним вимогам тієї епохи. Сьогодні зменшення популярності консорціумів насправді означає, що просте дотримання цих вимог не відображає справжніх потреб користувачів. Користувачі, які загублені через регуляції, ставлять питання про те, які регуляторні інструменти потрібні.
З точки зору розвитку галузі
"Ефективна централізація"—чи є це необхідним етапом у розвитку блокчейну? Якщо остатня мета децентралізації полягає в захисті інтересів користувачів, чи можемо ми терпіти централізацію як перехідний засіб?
Термін "демократія" в контексті управління в блокчейні насправді є вагомим за токенами. Тож, якщо хакер володіє великою кількістю SUI (або одного дня DAO буде зламано, і хакер контролює права голосу), чи можуть вони також "легально проголосувати за своє виправдання"?
Врешті-решт, цінність блокчейну полягає не в тому, чи можна його заморозити, а в виборі не робити цього, навіть коли група має можливість заморозити.
Майбутнє блокчейну визначається не його технічною архітектурою, а набором переконань, які він обирає підтримувати.