CZ: Обозреватели блоков должны отфильтровывать спам-транзакции для снижения риска "отравления" адресов

14 мар. 2026 г.

CZ: Обозреватели блоков должны отфильтровывать спам-транзакции для снижения риска "отравления" адресов

"Отравление" адресов (также известное как "отравление" истории транзакций) незаметно стало одной из самых настойчивых угроз на уровне пользовательского интерфейса в сетях Ethereum и других EVM-совместимых сетях. Злоумышленникам не нужно взламывать криптографию или использовать уязвимости смарт-контрактов; они эксплуатируют человеческие привычки — особенно склонность копировать адрес из истории недавних транзакций, проверив лишь первые и последние несколько символов. Для наглядного описания того, как эти мошеннические схемы работают на практике, ознакомьтесь с объяснением Etherscan об атаках "отравления" адресов. (info.etherscan.com)

К началу 2026 года масштабы этих кампаний трудно игнорировать. Исследование CyLab Университета Карнеги-Меллона (основанное на многолетних данных из блокчейна) задокументировало сотни миллионов попыток "отравления" и подчеркнуло, что коренная причина кроется в юзабилити: длинные шестнадцатеричные адреса, усечение в интерфейсах и небезопасное копирование и вставка. (cylab.cmu.edu)

На этом фоне CZ недавно возобновил дискуссию вокруг простой идеи: прежде всего перестать показывать очевидные спам-переводы. Хотя большая часть общественного обсуждения сосредоточена на приложениях-кошельках, тот же принцип UX применим и к обозревателям блоков — поскольку именно в обозревателях пользователи, группы поддержки, аналитики и даже пользовательские интерфейсы кошельков часто "читают" историю транзакций.

Почему "отравление" адресов продолжает работать

Большинство атак "отравления" адресов следует повторяемому шаблону:

Мошенник создает адрес, похожий на настоящий (часто совпадающий с началом и концом реального адреса контрагента).
Он отправляет "пылевой" перевод (минимальная сумма, иногда даже событие токена, похожее на перевод), чтобы "загрязнить" историю жертвы.
Позже жертва копирует не тот адрес из истории и отправляет реальный платеж злоумышленнику.

Etherscan отмечает, что эти атаки не ограничиваются каким-либо одним интерфейсом; они могут появляться в обозревателях, кошельках и других фронтендах Web3. (info.etherscan.com)

Аргумент CZ: фильтрация спама — это исправление UX, а не изменение протокола

Основной аргумент CZ прост: если интерфейс может распознать шаблон "отравления" (или известный адрес "отравителя"), он должен предупредить или заблокировать, а если транзакция фактически является бесполезным спамом, она должна быть скрыта по умолчанию, чтобы снизить вероятность ошибки при копировании и вставке. Отчеты, обсуждающие его комментарии, выделяют два практических направления:

Обнаружение и блокировка известных адресов "отравителей" ("запрос к блокчейну" плюс анализ угроз)
Не отображать транзакции-спам с незначительной стоимостью в списках истории (financefeeds.com)

Именно здесь обозреватели блоков становятся частью решения: многие кошельки и инструменты для управления портфелем зависят от API обозревателей и лент активности, аналогичных обозревательским. Если обозреватели представляют спам-переводы с тем же визуальным весом, что и реальные платежи, они непреднамеренно усиливают "UI-след" злоумышленника.

Обозреватели блоков уже фильтровали спам — это не ново

Индустрия уже экспериментировала с "элементами управления видимостью" на уровне обозревателей. Например, BlockBeats ранее сообщал, что Etherscan обновил свой вид по умолчанию, чтобы не отображать токены без стоимости в ответ на мошеннические схемы, позволяя при этом пользователям повторно включить видимость в настройках. (theblockbeats.info)

Это важный прецедент: фильтрация на уровне UI не меняет истину в блокчейне. Она меняет то, что выделяется, что сворачивается, и что требует дополнительного клика — именно то трение, которое может предотвратить дорогостоящие ошибки.

Сложная часть: фильтрация без ущерба для законных сценариев использования

Критики агрессивной фильтрации часто поднимают обоснованную обеспокоенность: что, если "маленькие переводы" являются законными?

В 2025–2026 годах этот вопрос становится более актуальным, поскольку индустрия движется к:

Снижению комиссий и увеличению пропускной способности на L2 и высокопроизводительных блокчейнах
Ончейн-автоматизации (боты, хранители, решатели намерений)
ИИ-агентам, которые могут полагаться на микроплатежи или высокочастотное урегулирование

CZ признал вариант компромисса: если будущее включает микротранзакции между ИИ, общая фильтрация только по стоимости может скрыть реальную активность — однако те же возможности ИИ могут быть использованы для более точной классификации спама, когда это будущее наступит (т.е. более "умное" обнаружение, а не простые пороговые значения).

Разумный компромисс для обозревателей:

Скрывать по умолчанию "вероятно спам", а не "низкую стоимость"
Предоставить переключатель "Показать скрытую активность" одним кликом
Предлагать объясняемые метки (почему что-то было скрыто: 0-стоимость, поддельный шаблон токена, известный кластер "отравления", высокий балл сходства и т. д.)
Сохранять представление необработанных журналов/событий для продвинутых пользователей и аудиторов

Это сохраняет прозрачность, защищая при этом большинство пользователей от наиболее распространенного сценария неудачи: копирования неправильного адреса из "загрязненной" ленты.

Что обозреватели и кошельки должны делать (практический чек-лист)

1) Прекратить усекать адреса по умолчанию в контекстах высокого риска

Если интерфейс должен усекать, он должен поддерживать "нажмите, чтобы развернуть", подсвечивать различия и отображать стабильные визуальные подсказки (иконки, теги имен, метки контактов).

2) Добавить "предупреждения о сходстве" при отправке

Самый безопасный момент для вмешательства — перед подписанием. Если пункт назначения очень похож на недавно использованный адрес (но не идентичен), UI должен потребовать явного подтверждения.

3) Относить видимость спама к настройкам безопасности

"Скрыть подозрительный спам" должно быть включено по умолчанию, с понятными элементами управления для просмотра скрытых элементов.

4) Использовать чек-суммы везде, где возможно

Для адресов в стиле Ethereum, смешанное кодирование чек-сумм EIP-55 помогает обнаруживать опечатки и снижает определенные классы ошибок копирования. См. спецификацию ERC-55 (EIP-55). (eips-wg.github.io)

5) Вести локальную адресную книгу (и поощрять списки разрешенных адресов)

Сохраненная запись контакта труднее "отравить", чем "то, что появляется последним в истории".

Что пользователи могут сделать сегодня, чтобы снизить риск "отравления" адресов

Даже если обозреватели и кошельки улучшат фильтрацию, пользователи должны предполагать, что попытки "отравления" будут продолжаться — потому что отправка "пыли" дешева, а злоумышленники работают в больших масштабах. Вот привычки, которые существенно снижают риск:

Никогда не копируйте адрес получателя из истории транзакций, если вы его полностью не проверили.
Для крупных переводов сначала отправьте небольшую тестовую транзакцию.
Предпочитайте доверенные источники адресов (вашу собственную адресную книгу, проверенных контрагентов, QR-коды из аутентифицированного канала).
Сравните вручную больше, чем первые/последние 4 символа — проверьте и средний сегмент.
Используйте рабочий процесс подписания, который заставляет вас проверять полный адрес на доверенном дисплее.

Последний пункт — это то, где аппаратный кошелек существенно меняет профиль риска.

Где OneKey вписывается в эту модель безопасности

"Отравление" адресов — это, по сути, проблема обмана на уровне пользовательского интерфейса, поэтому самая надежная защита — это отделить "то, что вы видите на потенциально скомпрометированном экране", от "того, что вы подтверждаете на доверенном экране".

Аппаратный кошелек, такой как OneKey, помогает, храня приватные ключи офлайн и требуя подтверждения транзакций на устройстве — таким образом, когда ваш браузер, dApp или история транзакций "загрязнены" спам-переводами, у вас все еще есть возможность проверить адрес получателя и сумму на экране аппаратного кошелька перед подписанием.

Если вы часто взаимодействуете с DeFi, отправляете стейблкоины или управляете операционными кошельками, сочетание: