Чому важлива архітектура блокчейну: $50M Пробудження через отруєння адреси

Найгірший кошмар користувача криптовалюти нещодавно став реальністю, коли майже $50 мільйонів USDT зникли за лічені секунди. Винуватцем не був збій протоколу або експлуатація смарт-контракту, а досить простий вектор атаки, який використав перетин недоліків у дизайні гаманця та людської психології. Ця подія слугує важливим нагадуванням, що безпека — це не лише захист на рівні протоколу, а й розуміння того, як різні моделі блокчейну протистоять певним шаблонам атак.

Розуміння Address Poisoning: Пасивна атака, яка працює

Атака, про яку йдеться, класифікується експертами з безпеки як пасивна атака — зловмисник не зламуює системи силою, а маніпулює поведінкою користувача за допомогою хитро розміщених пасток. Ось як це сталося:

Жертва, з приблизно $50 мільйонами USDT, щойно знятих, дотримувалася стандартної практики безпеки, спершу виконавши невеликий тестовий переказ. За кілька хвилин був ініційований основний переказ. Однак зловмисник уже підготував сцену, створивши адресу гаманця, майже ідентичну тієї, яку часто використовувала жертва, і заповнив її невеликою транзакцією USDT.

Ця мала транзакція виконувала стратегічну роль: вона створила отруєну історію у інтерфейсі гаманця користувача. Коли копіювали адреси з історії транзакцій — поширена практика, яку заохочують більшість UX гаманців — користувач випадково взяв фальшиву адресу шахрая замість цільової. Один клік — і $50 мільйонів зникли.

Що зробило цю атаку особливо руйнівною, так це її залежність від пасивної маніпуляції, а не активного зламу. Зловмисник не зламав паролі і не перехоплював повідомлення; він просто використав те, як інтерфейси гаманців пропонують підказки адрес, повертаючи поведінку користувача проти нього.

Архітектура блокчейну та безпека: UTXO проти моделі рахунків

Чарльз Госсінсон, засновник Cardano, підкреслив важливу архітектурну різницю, яка безпосередньо впливає на цю вразливість. Він стверджує, що такі великі втрати значно важче досягти у моделях на основі UTXO, які використовують Bitcoin і Cardano, порівняно з системами на основі рахунків, як Ethereum і сумісні з EVM мережі.

Основна різниця:

У моделях на основі рахунків (Ethereum) адреси функціонують як постійні рахунки з поточними балансами. Гаманці регулярно пропонують копіювати адреси з історії транзакцій. Ця конструкція створює ідеальне середовище для атак Address Poisoning — користувачі формують звичку копіювати з історії, що робить їх вразливими до пасивних атак, які використовують ці передбачувані поведінки.

У UTXO моделях (Bitcoin, Cardano) кожна транзакція споживає старі виходи і створює нові. Тут немає постійного “рахунку” для підтримки, і відповідно — немає й історії адрес, яку можна отруїти візуально. Архітектурна різниця усуває основну поверхню атаки, яку мають системи на основі рахунків.

Госсінсон наголосив, що це не недолік протоколу або вразливість коду — це системний дизайн, де людська поведінка зустрічається з архітектурними припущеннями. Користувачі не роблять помилки у вакуумі; вони раціонально реагують на інтерфейси гаманців, розроблені навколо постійності рахунків.

Реакція галузі та подальші кроки

Криптовалютна спільнота почала реагувати на ці вразливості. Ведучі провайдери гаманців випустили оновлення безпеки, підкреслюючи небезпеки звички копіювати адреси, і перепроектували екрани перевірки адрес, щоб зменшити вразливість до атак Address Poisoning.

Ці реакції підкреслюють важливий принцип: безпека вимагає залучення на кількох рівнях. Архітектура протоколу важлива, безумовно, але так само важливий дизайн гаманця, освіта користувачів і поведінкові шаблони. Втрата $50 мільйонів могла бути запобігною — не завдяки кращій криптографії, а завдяки кращому UX-дизайну та обізнаності користувачів.

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

Для окремих користувачів урок очевидний: ніколи не копіюйте адреси з історії транзакцій безпосередньо; завжди незалежно перевіряйте адреси отримувачів кількома способами. Для галузі в цілому цей інцидент є підтвердженням того, що питання безпеки мають охоплювати все — від протоколу до найменших UX-рішень.