727 FinanceИнцидент отнимает не только активы, но и доверие. Криптовалюта не может так продолжаться; мы должны спасать себя сами.
Автор: Роберт Мао, основатель и генеральный директор ArcBlock
Эта статья разрешена для свободного воспроизведения и распространения любым лицом в надежде, что больше людей увидит этот призыв к отрасли спасти себя.
Криптовалюта не может продолжаться так. Снова и снова массовые кражи уносят не только активы, но и доверие участников ко всей отрасли. Мы должны спасти себя.
29 октября 2026 года в Binance произошёл крупный инцидент безопасности. В своём предварительном объявлении компания оценила, что затронуто около 6,3 млрд долларов активов, из которых примерно 3 млрд долларов затронутых активов были заморожены; расследование первоначально указало на ноутбук инженера DevOps, а впоследствии были обнаружены и другие возможные точки вторжения. Binance также заявила, что не найдено доказательств утечки приватных ключей кошельков. Затронутая сумма не является окончательным чистым убытком, и полная цепочка атаки всё ещё расследуется. [[1]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-binance)
Эта инициатива адресована создателям блокчейн-проектов, таких как Ethereum и Solana, а также Binance, Coinbase, Kraken и всем биржам, кошелькам, протоколам и специалистам по безопасности, готовым участвовать: давайте вместе восстановим основу для защиты активов. Я готов участвовать и надеюсь, что больше людей будут действовать вместе.
Это уже достаточно тяжело. Но меня больше беспокоит, сколько доверия к Crypto уничтожит этот инцидент и сколько атакующих он приведёт к тому, чтобы рассматривать эту отрасль как цель, которую всё ещё стоит продолжать атаковать. Даже если кто-то в конечном итоге понесёт убытки, компенсация не может автоматически восстановить доверие пользователей и не может остановить повторение такого же разрушения.
Binance — лишь точка входа, которая сегодня заставляет нас столкнуться с проблемой. Если отвести взгляд, биржи, мосты, ончейн-протоколы и кошельки давно оставили длинный след ран. Новые сети и продукты продолжают появляться, но старые модели отказов повторяются снова и снова. Мы не можем выпустить объявление, подождать некоторое время, а затем относиться к следующему инциденту как к рутине.
Мы также должны признать, что мошенничество и практика простого создания концепций без принятия ответственности за строительство слишком долго вредили этой отрасли. Команды, серьёзно строящие технологии и инфраструктуру, также должны вместе нести последствия утраченного доверия. К тому времени, когда люди увидят всё Crypto как мошенничество, технологии и исследования, действительно достойные сохранения, могут быть отброшены вместе с ним.
Как основатель ArcBlock и практик в Crypto и Blockchain, я не готов принять такой исход. Я верю, что у этой отрасли есть ценность, достойная защиты, и я также верю, что мы должны взять на себя ответственность за нашу собственную основу безопасности. Если мы продолжим пассивно ждать следующего инцидента, повторяющееся кровотечение может в конечном итоге уничтожить всё, что мы вместе построили.Итак, я хочу выдвинуть эту инициативу: создатели бирж, кошельков и блокчейнов должны совместно перестроить основу контроля над активами и проверки безопасности, чтобы масштаб ущерба от одного вторжения был ограничен. Хронология ниже объясняет, почему изменения необходимы; техническое предложение, следующее за ней, — это работа, которую, я считаю, мы можем начать выполнять.
В 2008 году Сатоши Накамото предложил одноранговую систему электронных денег, пытаясь сделать платежи менее зависимыми от доверенных посредников. [[2]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-bitcoin) Однако крупные инциденты с тех пор неоднократно обнажали проблему повторной концентрации средств, авторизации и программных зависимостей.
Ниже приведён хронологический список репрезентативных инцидентов в таких областях, как централизованные биржи (CEX), децентрализованные биржи (DEX), мосты и кошельки. Это не полная база данных инцидентов и не статистика потерь по годам. Там, где указаны суммы, они относятся к приблизительному валовому воздействию на момент инцидента; кражи, заморозка и последующее восстановление описываются отдельно и не могут суммироваться как постоянные потери.
2008 · Белая книга Bitcoin
Отправная точка
В белой книге Bitcoin была предложена одноранговая платёжная система без финансовых учреждений в качестве посредников.
Источник
2011–2014 · Долгосрочная кража в Mt. Gox
CEX
Mt. Gox понесла долгосрочные потери от кражи и в конечном итоге прекратила деятельность. Позднее обвинительное заключение Министерства юстиции США утверждало, что в период с 2011 по 2014 год было похищено примерно 647 000 BTC. Это была не однодневная атака 2014 года.
Источник
2012 · Bitcoinica и Bitfloor
CEX / кастодиальная инфраструктура
Хостинговая среда Bitcoinica на Linode была скомпрометирована; в том же году нешифрованная резервная копия кошелька Bitfloor стала точкой входа для атаки. Серверы и резервные копии, стоящие за платформой, также являются частью границы безопасности активов.
Источник
2015 · Горячий кошелёк Bitstamp
CEX
Горячий кошелёк Bitstamp был скомпрометирован, и операционная среда впоследствии была перестроена. Официальное разграничение между масштабом инцидента и офлайн-резервами показало, что изоляция может ограничить масштаб подверженности риску.
Источник
2016 · Bitfinex
CEX
Из Bitfinex было похищено примерно 120 000 BTC. Схемы с мультиподписью по-прежнему требуют сквозной независимой авторизации и проверки.
Источник 1 · Источник 2
2016 · The DAO
Ончейн-протокол
Контракт The DAO подвергся атаке повторного входа, и примерно 3,6 млн ETH были переведены в суб-DAO, что впоследствии вызвало форк Ethereum. Легитимный путь исполнения может привести к катастрофическим бизнес-последствиям.
Источник 1 · Источник 2
2017 · Общая библиотека кошельков Parity
Контрактный кошелёк
Общая библиотека кошельков Parity была уничтожена, и примерно 513 000 ETH были заморожены. Даже если средства не переведены, они могут стать непригодными из-за зависимостей от общего кода.
Источник
2018 · Coincheck
CEXВзлом горячего кошелька NEM в Coincheck. Граница между офлайн-резервами, разрешениями горячего кошелька и бизнес-потребностями вновь стала проблемой.
Источник
2019 · Binance
CEX
Binance объявила о выводе 7 000 BTC одной транзакцией. Крупномасштабные оттоки активов должны быть ограничены до подписания.
Источник
2020 · KuCoin
CEX
Инцидент с горячим кошельком KuCoin, значительная часть активов впоследствии была возвращена благодаря многостороннему сотрудничеству. Общая сумма похищенного и итоговый убыток — не одно и то же число.
Источник
2021 · Poly Network
Кросс-чейн протокол
Из Poly Network было выведено активов примерно на 612 млн долларов, которые впоследствии возвращались поэтапно. Кросс-чейн авторизация и контроль активов не могут обеспечиваться только через обычные бизнес-пути.
Источник
2022 · Ronin bridge
Мост
Разрешения валидаторов Ronin были скомпрометированы, выведено 173 600 ETH и 25,5 млн USDC. Ключи нескольких валидаторов также могут попасть в одну и ту же цепочку атаки.
Источник
2022 · Slope wallet
Кошелёк
Инцидент с кошельком Slope в экосистеме Solana. Solana официально заявила, что информация о приватных ключах была случайно передана сервису мониторинга приложений; это не было компрометацией консенсуса Solana.
Источник
2023 · Euler
Кредитный протокол
Из Euler было выведено активов примерно на 197 млн долларов из-за уязвимости протокола, которые впоследствии были возвращены. Сложные комбинации в одной транзакции могут усиливать flaws бизнес-логики.
Источник
2023 · Ledger Connect Kit
Инструмент подключения кошелька
Ledger Connect Kit подвергся атаке на цепочку поставок, вредоносный код попал во фронтенд приложения. Безопасность аппаратного устройства не может заменить проверку содержимого транзакции.
Источник
2024 · DMM Bitcoin
CEX
Из DMM Bitcoin было похищено примерно 308 млн долларов. ФБР и другие ведомства впоследствии раскрыли атаки социальной инженерии, нацеленные на соответствующий персонал и цепочку подписания.
Источник
2024 · Radiant Capital
Кредитный протокол / подписание
Из Radiant Capital было похищено примерно 50 млн долларов, несколько устройств разработчиков были скомпрометированы. Многостороннее подписание всё ещё может коллективно зависеть от загрязнённой информации о транзакции.
Источник
2025 · Bybit / Safe
CEX / фронтенд кошелька
Инцидент с Bybit на примерно 1,5 млрд долларов затронул среду разработки и фронтенд Safe, а подписанты одобрили транзакцию, изменившую логику управления кошельком.
Источник 1 · Источник 2
2025 · Cetus DEX
DEXИнцидент в Cetus на Sui на примерно 223 млн долларов, исследователи указывают на flaw в математической библиотеке. Не-EVM среды также должны проверять свой код и масштаб подверженности активов.
Источник
2026-07 · flaw генератора случайных чисел COLDCARD
Аппаратный кошелёк / генерация seedУязвимость в прошивке ослабила генерацию seed-фраз, что позволило злоумышленникам восстановить соответствующие приватные ключи, пока устройство находилось офлайн. Обновление не может исправить уже сгенерированные слабые seed-фразы; миграция в соответствии с рекомендациями по-прежнему необходима.
Источник
2026-10 · Аппаратный имплант Ledger
Атака на аппаратный кошелёк / цепочку поставок
Ledger подтвердила, что подлинные устройства были модифицированы и распространены через каналы дистрибуции в Юго-Восточной Азии, а имплантированные компоненты похищали recovery-фразы во время инициализации. Производитель заявляет, что его чипы, операционная система и серверы не были скомпрометированы.
Источник
2026 · Мультичейн-инцидент Binance
CEX / мультичейн
Binance первоначально оценила, что затронуто около $6,3 млрд активов, и расследование других возможных точек вторжения продолжается. Одна операционная система может одновременно подвергать риску активы в нескольких сетях.
Источник 1 · Источник 2 · Источник 3
Здесь есть и CEX, и децентрализованные биржи, и кредитные протоколы, и мосты; есть украденные активы и замороженные активы. Атаки происходят на разных уровнях, и методы устранения последствий различаются. Я против того, чтобы сводить всё это к одной фразе «пользователи не смогли защитить свои приватные ключи». Как пользователи могут знать, что среда разработки некоего инструмента, некая общая библиотека или непостижимая авторизация станут точкой входа ко всем их активам?
Распределённые сети уже сделали немало, однако изоляция отказов для контроля над активами далеко не достаточна. Исполнение ончейн добросовестно завершает транзакцию, но не может ответить за нас, почему эта транзакция имеет право перемещать так много.
Вклад Ethereum значителен. Он позволил большему числу людей писать ончейн-приложения и способствовал формированию богатого набора инструментов и опыта разработки. Но сегодня многие новые сети и L2 (сети масштабирования второго уровня) считают совместимость с EVM своей главной целью. EVM — виртуальная машина, исполняющая смарт-контракты Ethereum, — становится широко тиражируемой технической предпосылкой. Совместимость действительно упрощает миграцию приложений; документация таких проектов, как Unichain, прямо указывает повторное использование инструментов Ethereum как ценность эквивалентной среды исполнения. [[3]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-evm)
Я считаю, что отношение к совместимости с EVM как к отраслевому ответу по умолчанию создаёт структурную концентрацию риска. Названий сетей может быть много, валидаторы могут различаться, но разработчики могут раз за разом развёртывать одни и те же контракты, использовать одни и те же привычки авторизации и полагаться на одни и те же программные библиотеки. Ошибки в общих зависимостях не исчезают только потому, что развёртывание происходит в другой сети. Это суждение о техническом пути, а не утверждение, что каждая реализация EVM непременно имеет одну и ту же уязвимость.Именно здесь кроется моя критика Ethereum. Универсальная способность исполнения контрактов напрямую связана с передаваемыми активами, что возлагает огромную ответственность на код приложений и взаимодействие с кошельками. Контракты могут вызывать контракты, авторизации могут сохраняться длительное время, и кажущееся обычным подтверждение может изменить последующий режим управления аккаунтом. Безопасность всё больше зависит от того, правильно ли каждая команда разработчиков понимает эти комбинации, и от того, правильно ли каждый пользователь понимает, что он подписал.
EIP-7702 делает эту проблему предельно ясной. Обычный перевод — это «сколько кому на этот раз»; делегирующая авторизация может означать «с этого момента пусть этот фрагмент кода выполняет операции от имени моего аккаунта». У неё есть цели улучшения пользовательского опыта и уточнения разрешений, но настройка делегирования сама по себе предоставляет широкую исполнительную способность, а детализированные разрешения всё ещё должны быть корректно реализованы делегированным кодом. [[4]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-7702) Препринт «EIP-7702 Phishing Attack» Миньфэна Ци и др. исследует путь постоянного контроля над аккаунтом после побуждения к подписанию таких авторизаций. [[5]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-phishing) По мере роста удобства растёт и ответственность за безопасность; первую нельзя просто переложить на пользователей.
Этот инцидент с Binance охватывает несколько цепочек, и расследование ещё не завершено, поэтому всё влияние нельзя напрямую приписывать EIP-7702 или EVM. Повторный вход, компрометация сервисов подписи и подмена фронтенда — это тоже не одна и та же уязвимость. Но такие разграничения не должны становиться оправданием, чтобы перестать задавать вопросы об архитектуре: почему базовый уровень не сохраняет больше ограничений, которые нельзя легко обойти, в интересах ошибок верхних уровней?
MEV также меня не устраивает. Он обозначает пространство, в котором участники получают дополнительную ценность через включение, исключение и упорядочивание транзакций. Для меня использование силы упорядочивания для сэндвич-атак на пользовательские транзакции и ухудшения результатов их исполнения должно рассматриваться как баг, который нужно исправить, а не упаковываться как функция, которую стоит сохранять только потому, что кто-то может на ней заработать. Документация самого Ethereum также прямо признаёт вред сэндвич-атак для пользователей и риск MEV для стабильности сети. [[6]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-mev) MEV не уникален для Ethereum и также включает различные виды деятельности, такие как арбитраж и ликвидация; в отрасли уже есть исследования по смягчению. Моя критика в том, что стимул поддерживать сеть не может становиться причиной жертвовать условиями транзакций пользователей. Лучшая транзакционная система должна записывать минимальный результат доставки и допустимые комиссии в авторизацию и ограничивать пространство для ордеров использовать незаполненную информацию во вред пользователям.Я всегда ощущал, что влияние Ethereum на Crypto в чём-то похоже на влияние PHP на интернет: он позволил многим людям создавать вещи, но также оставил инженерный долг, на погашение которого потребуется много времени. PHP всё ещё нуждался в исправлении серьёзной уязвимости удалённого выполнения кода в октябре 2026 года. Зрелость и популярность не могут заменить непрерывное укрепление. [[7]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-php) Ценность интернета в том, что языки, фреймворки и облачные сервисы могут развиваться отдельно. Нам также следует позволить различным моделям активов и способам исполнения продолжать развиваться, а не рассматривать «совместимость с одной и той же виртуальной машиной» как пропуск для участия в экосистеме.
Поэтому я призываю экосистемы Bitcoin, Solana и Ripple/XRP Ledger, а также строителей, включая ArcBlock, серьёзно участвовать в создании общей основы безопасности. Участие в стандартах и интероперабельности не требует сначала переделывать себя в Ethereum. Разнообразие должно быть реализовано в методах контроля активов и верификации и быть открытым для публичной проверки. Инциденты Slope и Cetus уже напомнили нам, что не-EVM также не имеет освобождения от безопасности.
Я надеюсь увидеть формирование спецификации безопасности, которую смогут принять различные среды исполнения: одинаковые ограничения активов и требования к верификации могут быть реализованы отдельно EVM и другими путями, а затем гарантии и издержки каждого из них могут быть публично изучены.
1. Пусть базовые средства контроля рисков ограничивают полномочия по распоряжению активами
Крупные кошельки должны иметь возможность устанавливать белые списки получателей, совокупные лимиты расходов и периоды ожидания для новых получателей. Ключевой момент в том, что эти правила не могут быть немедленно отменены тем же повседневным ключом транзакции. Изменение правил требует независимой авторизации и должно оставлять время для мониторинга и отзыва.Существующие смарт-аккаунты уже имеют основу для реализации: например, Safe Guards позволяют добавлять ограничения транзакций сверх мультиподписи. [[8]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-guards) Нам нужно превратить это в более простую для внедрения базовую возможность, охватывающую все пути контроля активов. Если ограничены только прямые переводы, а обходы через неограниченные одобрения, модули или обновления разрешены, защита не сработает. В область проверки также должны входить вопросы, можно ли обновить контракт белого списка и изменились ли разрешения получателя. Activation Lock от Apple даёт бытовую аналогию: он ограничивает повторную активацию украденных устройств и ограничивает калибровку некоторых украденных деталей, чтобы снизить ценность, которую можно извлечь после кражи. [[9]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-apple) Кошельки также стоит проектировать в этом направлении. Если злоумышленник получит ключ, диапазон активов, которые можно обналичить, останется ограниченным, и ожидаемая доходность атаки может снизиться; риски, такие как нарушение работы сервисов, всё равно нужно обрабатывать отдельно.
Это то, что я называю «конституцией» безопасности активов: операционные полномочия могут быть скомпрометированы, но полномочия по изменению границ должны оставаться независимыми. Процессы восстановления также должны быть ограничены, чтобы одна ошибка конфигурации не могла навсегда заблокировать активы.
II. Заставить кошельки нести ответственность за безопасность, а не просто передавать мнемонические слова
У меня есть сильное недовольство современными кошелёчными системами: если продукт просит обычного человека переписать набор слов, требует, чтобы он никогда их не раскрывал, не терял и не был обманом вынужден их сообщить, а затем все последующие сбои относит на ответственность пользователя, я считаю это безответственным дизайном. Самостоятельное хранение должно давать людям контроль, а также должно давать людям пригодные для использования возможности защиты и восстановления. Оно не должно требовать, чтобы каждый пользователь сначала стал экспертом по безопасности. Это также порог, который Crypto должен преодолеть, чтобы достичь большего числа обычных пользователей.Недавние инциденты прямо поставили эту проблему на повестку дня. В октябре 2026 года Ledger подтвердила, что злоумышленники модифицировали подлинные устройства, а затем отправили их обратно на рынок через каналы дистрибуции в Юго-Восточной Азии, при этом внедрённые компоненты похищали seed-фразы для восстановления во время инициализации. Ledger квалифицировала это как атаку на локальную дистрибуцию после того, как устройство покинуло завод, а не как компрометацию его чипа, операционной системы или серверов. [[10]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ledgerimplant) Июльский инцидент с COLDCARD был связан с ослаблением генерации seed-фразы на уровне прошивки: устройству не требовалось удалённое управление, чтобы злоумышленник мог восстановить соответствующие приватные ключи. Обновление прошивки исправляет процесс генерации на будущее, но слабые seed-фразы, которые уже были сгенерированы, всё ещё нуждаются в миграции. [[11]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-coldcard)
Эти два инцидента представляют собой разные типы уязвимостей, однако вместе они показывают: даже если пользователи тщательно переписывают слова и держат устройство офлайн, они не могут проверить случайность и целостность цепочки поставок от имени производителя. Отображение слов для резервного копирования на устройстве служит цели офлайн-восстановления, но оно также приводит к тому, что полный секрет восстановления проходит через путь отображения и резервного копирования, который требует защиты. Безопасность чипа не может заменить проверку всего устройства и процесса поставки.
Целью улучшений должен стать полный жизненный цикл кошелька: как генерируются ключи, как объясняются транзакции, как разделяются разрешения и как работает восстановление после потери устройства. Абстракция аккаунта, то есть возможность для аккаунтов проверять авторизацию через программируемые правила, и пороговое резервное копирование, такое как SLIP-39, уже имеют стандарты и основу для реализации, поэтому нельзя сказать, что никто в отрасли ими не занимается. [[12]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-walletstandards) Но нам нужно превратить эти возможности в проверенные и простые в использовании средства защиты, а не оставлять пользователям самостоятельную сборку сложных схем.
Простое запутывание мнемонических слов недостаточно. Более надёжные направления включают проверенные зашифрованные резервные копии, пороговое восстановление и независимую авторизацию устройств, а также проведение пользователями тренировок по восстановлению до размещения крупных сумм активов. Резервные фрагменты и мультиподпись относятся к разным уровням: первые при восстановлении могут рекомбинироваться в один и тот же секрет, тогда как вторая требует одобрения транзакции несколькими независимыми подписантами. Службы восстановления не должны незаметно становиться новым мастер-ключом, и дополнительный пароль не должен превращаться в ещё одну ловушку, где его потеря означает безвозвратную утрату.Системы личных кошельков и кошельков бирж могут совместно использовать спецификации безопасности для описаний транзакций, запросов на подпись, ограничений активов и процессов восстановления, при этом применяя различные лимиты и политики одобрения. PSBT в Bitcoin уже предоставляет формат для передачи неподписанных транзакций между инструментами, и этот общий интерфейс стоит продолжать развивать. [[13]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-psbt) Общими являются проверяемые требования безопасности; каждой цепочке по-прежнему необходимо уточнять свои собственные правила адаптации. Кошельки должны чётко показывать, что именно передаст эта подпись и какой объём последующих полномочий и кому она предоставит, а независимые политики должны отклонять выходящие за рамки операции; более красивой страницы подтверждения недостаточно.
III. Обеспечить проверяемость при минимально необходимом раскрытии
Доказательство того, что условие выполняется, не должно всегда требовать от пользователей раскрытия всех базовых данных. Выборочное раскрытие, доказательства с нулевым разглашением и аудиторский доступ, предоставляемый по запросу, должны стать обычными опциями в инфраструктуре. Это также связано с безопасностью активов: публичная идентичность и связи между активами могут дать подсказки для целенаправленного обмана; данные, которые не нужны бизнесу, следует раскрывать как можно меньше.
Система проверяемых учётных данных W3C уже имеет технический путь для выборочного раскрытия; однако доказательство подлинности входных данных, действительности учётных данных и порядка отзыва статуса всё ещё требует уточнения. [[14]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-privacy) Применение доказательств с нулевым разглашением (ZK) не скрывает автоматически суммы транзакций и связи; масштабирование доказательств и защита конфиденциальности — это разные цели.
Например, когда бизнесу нужно лишь проверить право на участие, пользователь может предъявить действительное заключение о праве, выданное доверенным учреждением, не раскрывая полные финансовые материалы. Когда необходимо доказать, что скрытое значение удовлетворяет условию, тогда можно использовать соответствующий механизм доказательства. Доверенный источник учётных данных и статус их отзыва по-прежнему необходимо проверять.
Моя инициатива состоит в том, чтобы сначала уточнить, «кому нужно проверять что», а затем спроектировать данные, которые должны быть обнародованы. Тем, кто проверяет право на участие, может понадобиться только заключение о праве; те, кто несёт конкретные аудиторские обязанности, могут получить ограниченные доказательства. Публично проверяемые ограничения должны минимизировать персональную информацию, постоянно раскрываемую всем.
IV. Сделать транзакционные услуги максимально свободными от централизованного храненияСопоставление сделок, поиск маршрутов и расчёт по активам должны проектироваться раздельно. Сервис, предоставляющий точку входа для торговли, должен получать только те разрешения, которые необходимы для завершения текущего расчёта в максимально возможной степени, чтобы в остальное время активы пользователей оставались под их собственным контролем. Существующие протоколы транзакций на основе интентов уже исследовали часть этого пути, и отрасль может продолжить его завершать. [[15]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-routing)
То, с чем соглашаются пользователи, должно представлять собой чёткие условия расчёта, включая то, что оплачивается, что как минимум получается, когда истекает срок и какие комиссии разрешены. После компрометации торгового сервиса атакующий может отказать в обслуживании, но не может произвольно изменять эти условия. Предприятия, которым всё ещё требуется централизованное хранение, также должны разделять резервные и операционные разрешения, а также ограничивать подверженность горячих кошельков и лимиты автоматического пополнения.
IBIT — это биржевой биткоин-продукт iShares, и на рынке торгуются его акции. Его устройство даёт пример частичной изоляции: акции и базовый биткоин учитываются раздельно, а соответствующие приватные ключи для Vault Balance (баланс хранения) размещены в холодном хранилище. Изменения в записи торговли акциями не требуют перемещения базового биткоина при каждой транзакции. [[16]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ibit) Из этого можно извлечь урок — разделение торговых прав и прав распоряжения резервами. Его Trading Balance (баланс торгового сервиса) имеет иное устройство, и само хранение также несёт риски; холодное хранение должно сочетаться с независимой проверкой инструкций и подписей.
Я сравниваю точку входа для торговли с маршрутизатором в надежде, что её можно будет заменить, не наделяя её главным переключателем над активами всех пользователей. Расчёт сложнее пересылки пакетов, и доставка активов и авторизация всё ещё требуют независимой проверки. Сделать сервис некастодиальным, а затем предоставить ему неограниченные права на вывод — значит лишь вернуть централизованный риск.
V. Использовать многоуровневую архитектуру для изоляции сбоев и сохранения заменяемостиНам нужны интерфейсы идентификации и авторизации, политики активов и методы проверки расчётов, которые могут развиваться независимо. Разные цепочки могут сохранять собственные модели исполнения и подключаться через чёткие интерфейсы. Интерфейсы должны указывать гарантии безопасности и их условия, а не просто сообщать, что «вызов успешен». Опыт интернета поддерживает такой подход. В RFC 9518, «Централизация, децентрализация и интернет-стандарты», Марк Ноттингем специально рассматривает ситуации, в которых централизация может быть полезной, а также анализирует власть и риски, которые она приносит. [[17]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-layers) Именно эту позицию стоит перенять: пусть архитектура отвечает на вопросы, какие обязанности можно централизовать, в какой степени и как не дать этой власти расширяться. Сервису можно разрешить централизованно выявлять аномалии, но его право касаться активов должно быть ограничено; пользователи должны иметь возможность переключать сервисы, не теряя собственных политик активов и записей проверки.
Самый важный вопрос приёмки: после компрометации бизнес-сервиса какой независимый слой всё ещё может его отклонить? Если все слои используют один административный ключ, так называемая слоистость — это лишь слоистость на схеме развёртывания.
Эту цель можно рассматривать как пять слоёв ответственности: транзакционный сервис подаёт запросы, кошелёк выражает намерение пользователя, независимая политика ограничивает полномочия по распоряжению активами, компонент проверки проверяет операции и доказательства, а расчётный слой обеспечивает соблюдение ограничений и предоставляет проверяемые записи. Они могут быть реализованы разными командами, и их зависимости и условия отказа также должны описываться отдельно.
Целевая архитектура, продвигаемая в этой статье. Расчётный слой должен обеспечивать соблюдение политики активов; подсказки в кошельке не могут заменить это ограничение. Повседневное подписание, изменение правил и полномочия по восстановлению должны быть изолированы и подвергнуты тестированию на обход.
6. Позвольте пользователям легко проверять собственные активы
Обычные люди не должны хранить и исполнять всю историю всей цепочки, чтобы проверять собственные балансы и квитанции; они также не должны доверять только одному серверу за кошельком. Сатоши Накамото уже предложил SPV, упрощённую проверку платежей, в разделе 8 белой книги. BIP-157 Bitcoin продолжает исследовать возможность клиентов загружать фильтры и находить блоки, относящиеся к ним самим; в Ethereum также есть проекты лёгких клиентов. [[18]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-lightclients) Так что проблема не в том, что об этом никто никогда не думал, а в том, что нам всё ещё нужно встроить возможность проверки с чёткими условиями безопасности в кошельки, которые пользователи используют каждый день.Возьмём для примера цепочку, поддерживающую доказательства состояния аккаунта: при запросе баланса сервер должен возвращать как баланс, так и доказательство. Кошелёк сначала проверяет короткий дайджест блока, то есть заголовок блока, по правилам этой цепочки, а затем проверяет, согласуется ли этот баланс с данными, зафиксированными в дайджесте. Сервер предоставляет ответ, а кошелёк может проверить ответ. SPV в Bitcoin проверяет доказательство включения соответствующих транзакций; его нельзя напрямую скопировать как доказательство баланса. Кошелёк также должен явно отображать, до какого места он синхронизирован и какая информация проверена; при отсутствии доказательств, устаревании данных или конфликте источников он должен предупреждать или останавливать высокорисковые операции, опирающиеся на эту информацию, и ни в коем случае не должен молча откатываться к слепому доверию.
Лёгкая проверка всё ещё имеет условия. Доказать, что транзакция была включена в блок, — это не то же самое, что самостоятельно проверить, что все транзакции в блоке валидны. Разные схемы могут полагаться на честность большинства хешрейта или на доверенную начальную запись, то есть чекпоинт; они также должны защищаться от того, что серверы скрывают данные или изолируют пользователей на устаревшей записи цепочки. Также нужно учитывать, не раскрывает ли сам запрос адреса, важные для пользователя. Полные узлы и производители блоков — это не одна и та же роль; Ethereum сегодня использует валидаторов, а не майнеров для производства блоков.
Что ещё важнее, доказательство того, что «этот перевод действительно произошёл в сети», не может доказать, что «это именно тот перевод, который хотел пользователь». Лёгкие клиенты не могут заменить прежние ограничения активов и проверки подписей. Они позволяют пользователям меньше полагаться на непроверяемый ответ, а политика активов гарантирует, что даже валидная подпись не сможет распоряжаться активами без ограничений. Только выстраивая оба слоя вместе, можно распределить возможность проверки между участниками.
7. Сделать выявление аномалий и проверку безопасности публичной инфраструктурой
Перед транзакцией кто-то должен проверить, соответствует ли операция политике активов и не меняет ли она внезапно историческое поведение. Очевидные аномалии могут запускать паузу или эскалацию проверки; расширение разрешений требует другого независимого пути. ИИ может участвовать в суждении, но не должен получать пропуск, переопределяющий жёсткие правила.
В то же время нам нужно совместно поддерживать кейсы атак, тесты разрешений и инструменты проверки, которые можно запускать повторно. Только делясь спецификациями и сохраняя независимые реализации и независимую проверку, можно уменьшить отказы общего характера. Фонды и биржи уже имеют инвестиции в безопасность, например, инициативу Ethereum Foundation Trillion Dollar Security Initiative. [[19]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-initiative) Следующий вопрос: можно ли превратить эти инвестиции в публичную инфраструктуру, которую смогут перенимать и проверять другие команды.Ни один из этих семи рабочих пунктов не может гарантировать абсолютную безопасность. Они должны обеспечить проверяемые границы: при каких условиях компрометации разрешений какой объём активов подвергается риску в худшем случае, как быстро можно обнаружить аномалии и от кого по-прежнему зависит восстановление.
На этом этапе кто-то может сказать: направление кажется правильным, но отрасль уже развивается столько лет; сколько людей и сколько времени потребует реконструкция? Разве это не всё ещё идеализм?
Если оценивать по прежней модели производства программного обеспечения, это сомнение вполне реалистично. Но к 2026 году, я полагаю, кодирующие агенты и программная инженерия с поддержкой ИИ уже изменили ту строительную мощность, которую мы можем мобилизовать. Под кодирующими агентами здесь понимаются помощники по программированию на основе ИИ, которые могут читать и писать код, вызывать инструменты, запускать тесты и продолжать работу на основе обратной связи в среде разработки. Строители ставят цели, определяют границы безопасности, используют эти инструменты для реализации и проверки систем и несут ответственность за результаты.
Работу, которая ранее требовала больших команд для многократной реализации, адаптации и сопровождения, теперь могут попытаться выполнить небольшие команды с помощью этого нового инженерного подхода. Одна команда отвечает за один слой, поставляет компоненты вокруг чётких интерфейсов, а затем другие команды проверяют и объединяют их. Организация человеческого архитектурного суждения, реализационной способности кодирующих агентов и независимой проверки безопасности — это, на мой взгляд, тот путь строительства, который стоит серьёзно переоценить.
Исследование Anthropic и PNNL даёт конкретный пример: в ограниченной среде моделирования критической инфраструктуры исследователи сообщили, что реконструкция атаки сократилась с возможно нескольких недель до примерно трёх часов. [[20]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-ai) Это не доказывает, что небольшая команда уже может безопасно переписать всю отрасль, но показывает, что ранее дорогостоящая работа по проверке и наступательно-оборонительным действиям может иметь новые условия по затратам.
Один организационный подход, который можно начать уже сейчас, — совместно построить Build in Public AI Factory. Отраслевые эксперты, учёные и практики открыто пишут требования и спецификации приёмки (spec), объясняя, что нужно защищать, какие операции разрешены и какие границы должны сохраняться после компрометации каких разрешений, а затем превращают эти требования в приёмочные тесты. Группы кодирующих агентов берут на себя основную работу по написанию кода, тестированию и отладке; разные команды проверяют проекты и результаты, а люди несут ответственность за суждение и приёмку.Участники могут вносить идеи, машины, вычислительные мощности и квоты на вызов моделей, то есть AI-токены. Компании в сфере AI и облачных вычислений также могут поддерживать это общественное строительство через квоты на модели, вычислительные ресурсы и инструменты. Спецификации, прототипный код, рабочие процессы агентов, тестовые среды и результаты проверки — всё это может стать совместно поддерживаемой инфраструктурой, позволяя следующей команде продолжить работу непосредственно с этого места. Цель — встроить возможности разработки в многоразовые общественные средства и снизить зависимость от времени какого-либо одного человека или какой-либо одной команды.
Злоумышленники тоже используют AI, и у нас больше нет причин оставлять защиту в методах производства прошлого. [[21]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-aiattacks) Но быстрая генерация кода — это лишь отправная точка. Только чётко прописав ограничения, сделав тесты многократно воспроизводимыми, а компонент — проверяемым и заменяемым, можно превратить возможности AI в улучшение инфраструктуры.
Независимые разработчики работают вместе с помощью агентов для написания кода и AI-инструментов. Пространственная мастерская — это метафора общественного строительства. Я особенно хочу адресовать этот призыв тем, кто всё ещё любит строить. «Хакер» здесь означает того, кто готов разобраться, как работает система, готов делиться найденным и готов позволить другим тестировать свою работу. Этот дух когда-то двигал Интернет вперёд, и сегодня он может двигать Crypto вперёд.
Я не верю, что в этой отрасли не хватает умных людей, и не верю, что индустрии Crypto и AI не могут найти ресурсы для поддержки этой работы. Сложнее — организовать вместе таланты, финансирование и устойчивую ответственность. Фонды и дееспособные компании должны быть готовы нести долгосрочные издержки фундаментальной работы, которая не приносит прямого дохода, но приносит пользу всем.
Я надеюсь, что все смогут вместе построить глобально разделяемую криптографическую инфраструктуру. Разные сети и команды могут сотрудничать в рамках общих ограничений безопасности, каждая реализуя свои решения и тестируя чужие, а пользователи могут выбирать и мигрировать. Можно начать с одного компонента, но направление должно быть достаточно масштабным, чтобы вместить совместное строительство всей отрасли. Все участники, включая ArcBlock, должны вносить проверяемую работу.
Нам следует совместно построить такую инфраструктуру, где, даже если какая-то часть скомпрометирована, у активов всё ещё есть границы, другие системы всё ещё могут отвергать ошибки, а у пользователей всё ещё есть пути к восстановлению и выходу. Заимствуя название из «Звёздных войн», это наша «Новая надежда». [[22]](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fn-starwars) Надежда исходит от обычных строителей, готовых действовать, а также от этого момента, когда агенты для написания кода и новые инженерные методы позволяют им взять на себя больше строительной работы.Я хочу пригласить разработчиков таких проектов, как Ethereum, Solana, Bitcoin и XRP Ledger, таких бирж, как Binance, Coinbase и Kraken, а также команды кошельков, протоколов, исследователей безопасности, команды ИИ и облачных вычислений: начните с чётко ограниченного пилота и совместно создайте улучшения, которые другие команды смогут перенять и протестировать.
Перечисленные названия приведены только как примеры, в произвольном порядке. Независимо от размера или выбранного технического пути, вы можете участвовать. Это приглашение также распространяется на разработчиков технических путей, подвергнутых критике в этой статье; совместное повышение безопасности активов стоит того, чтобы преодолеть границы наших экосистем.
Я сам готов участвовать и внести наш существующий опыт в инфраструктуре, программной инженерии и совместной работе с ИИ. Мы всего лишь небольшая команда в отрасли, и наши возможности ограничены. Я надеюсь начать с прототипа и набора воспроизводимых тестов.
Люди с практическим операционным опытом могут предоставить обезличенные сценарии атак, команды кошельков и протоколов могут реализовать защиту, а независимые исследователи могут попытаться её обойти. Каждая команда берёт на себя ту часть, которую может выполнить, совместно тестируя решение и определяя следующий шаг.
Я готов участвовать в оформлении требований к ограничению и восстановлению активов, изложенных в этой статье, в первую публичную спецификацию, а также готов внести соответствующие технические и инженерные практики, чтобы вместе с другими участниками построить публичную AI Factory для этого пилота. Сначала выберем очень конкретную проблему: если повседневный ключ транзакций скомпрометирован, как всё же не дать атакующему опустошить кошелёк за один раз? Запишите допустимый диапазон потерь, полномочия по изменению правил и условия восстановления в приёмочные тесты, затем поручите агентам-разработчикам реализовать прототип, а другой группе агентов и независимым исследователям — искать пути обхода. Серверы данных, возвращающие неверные балансы, и восстановление после потери устройства также можно постепенно добавлять в тесты. Что удалось достичь в прототипе, где он терпит неудачу и какие зависимости остаются, — всё это должно быть публично объяснено, а следующий шаг следует определять на основе доказательств.
Тех, кто готов участвовать, приглашаю публично репостить или цитировать эту инициативу в X и @mave99a и рассказывать о проблеме, которую вы хотите решить, обезличенных случаях атак или ресурсах, которые вы можете предоставить. Я надеюсь, что обсуждение будет проходить публично, чтобы больше разработчиков увидели его и присоединились.
Криптовалюта не может продолжаться так. Те, кто готов работать вместе, давайте действовать сейчас, начиная с одного улучшения, которое можно построить и которое выдержит тестирование.Binance, первоначальное официальное объявление и официальное обновление последующего расследования, 2026-10-30; мультичейн-анализ TRM. Этот черновик был проверен по состоянию на 2026-10-30; статус расследования и возмещения может измениться. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-binance)
Satoshi Nakamoto, Bitcoin: A Peer-to-Peer Electronic Cash System, 2008. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-bitcoin)
Uniswap, Unichain EVM Equivalence. Концентрация риска общих зависимостей — это суждение автора в данной статье, а не вывод указанного документа. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-evm)
Vitalik Buterin, Sam Wilson, Ansgar Dietrichs, lightclient, EIP-7702: Set Code for EOAs, создано 2024-05-07. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-7702)
Minfeng Qi, Qin Wang, Ruiqiang Li, Tianqing Zhu, Shiping Chen, EIP-7702 Phishing Attack, 2025-12-13, препринт arXiv v1; не является идентификацией данного инцидента с Binance. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-phishing)
Ethereum, Maximal extractable value (MEV), механизмы упорядочения, различные типы и негативные эффекты; «должно быть исправлено как баг» — это инженерная позиция автора в отношении поведения, наносящего ущерб пользователям. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-mev)
Официальный архив новостей PHP за 2026 год; обновление CISA от 2026-10-26 списка Known Exploited Vulnerabilities, CVE-2026-109618, CVE-2026-109619. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-php)
Safe, Guards and Modules, описание функциональности и рисков разрешений. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-guards)
Apple, Apple to expand repair options with support for used genuine parts, 2024-04-11; текущее описание поддержки сопряжения деталей. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-apple)Ledger, Ledger's Response to the Hardware Implant Attack, 2026-10, заявление производителя об атаке в цепочке поставок; Joe Grand, исследование обратного проектирования аппаратных имплантов. Не следует представлять непроверенные оценки сетевых потерь как окончательные выводы. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ledgerimplant)
Coinkite, Current COLDCARD Security Status, по состоянию на 2026-10-30, постоянно обновляемая запись об инциденте июля 2026 года и его устранении; обновление и миграция seed-фразы — две разные операции. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-coldcard)
ERC-4337: Account Abstraction Using Alt Mempool; Trezor, SLIP39 FAQs, пороговое восстановление, совместимость и дополнительные риски passphrase. Существующие механизмы — это основа для построения, и они не означают, что каждое развёртывание надёжно. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-walletstandards)BIP-174: формат частично подписанных биткоин-транзакций (Partially Signed Bitcoin Transaction Format), формат обмена для неподписанных транзакций, а не кросс-чейн спецификация общей стратегии активов. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-psbt)
W3C, Verifiable Credentials Overview v1.0, 2026-07-30 Group Note; Ethereum privacy notes. Статус стандартов описанных в обзоре технологий независим в каждом случае. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-privacy)
Документация CoW Protocol, интенты транзакций и механизмы solver; данная статья не предоставляет комплексного подтверждения безопасности для какого-либо конкретного развертывания. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-routing)
iShares, IBIT 2025 Annual Report, PDF страницы 8–10 условия кастодиального хранения и страница 45 раскрытие рисков. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ibit)
Mark Nottingham, RFC 9518: Centralization, Decentralization, and Internet Standards, 2023-12, независимо представленный информационный RFC, не спецификация уровня стандартов. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-layers)
Bitcoin whitepaper Section 8 Simplified Payment Verification; BIP-157: Client Side Block Filtering; Ethereum, Light clients. Различные легкие клиенты имеют различные области проверки и условия доверия. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-lightclients)
Ethereum Foundation, Announcing the Trillion Dollar Security Initiative, 2025-05-14. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-initiative)
Anthropic, AI to defend critical infrastructure, 2026-01-08, исследование в ограниченной среде в сотрудничестве с PNNL. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-ai)
Anthropic, Mapping AI-enabled cyber threats, исследование на реальных образцах злоупотреблений. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-aiattacks)
Lucasfilm, Star Wars: A New Hope (Episode IV), 1977; данная статья заимствует название и образ совместного самоспасения. [↩](https://www.arcblock.io/zh/articles/crypto-security-rebuild/" \l "fnref-starwars)