#THORChain #Bitget安全事件 Может ли в экстренной ситуации быть остановлена вся сеть, — и почему нельзя просто заблокировать кошелёк, который якобы содержит украденные средства? Этот вопрос звучит как риторический, но на деле он смешивает два совершенно разных вида власти. Новое заявление THORChain сегодня как раз стоит прочитать, чтобы увидеть эту границу.
Сначала расставим таймлайн по местам. 27 сентября THORChain официально подчеркнула, что сеть не требует разрешений и рассчитана на устойчивость к цензуре. 28 сентября в 14:36 (по пекинскому времени) она пояснила дальше: экстренное отключение сети — это механизм безопасности протокола и не означает выборочную заморозку какого-то адреса или отдельной операции обмена. В качестве примера официально приводят старый случай с атакой на пул ликвидности в мае этого года: хотя тогда и было применено аварийное приостановление, адрес атакующего не был включён в чёрный список. Речь идёт об историческом событии, и его нельзя ошибочно истолковать как то, что сегодня сеть снова остановлена из‑за инцидента на Bitget.
Это также можно найти в технической документации: узлы могут с помощью аварийных параметров приостановить транзакции всей сети или приостановить обмены, связанные с конкретной цепочкой. Это все — общий рубильник, расширяющий влияние. А «сделать так, чтобы конкретный кошелёк не мог выполнить обмен» требует другой системы — распознавания адресов, исполнения правил и процедур управления (governance). Уметь делать первое логически не доказывает автоматически, что уже есть второе. И наоборот: текущий дизайн не даёт возможности для такой адресной блокировки, но это не означает, что в будущем правила навсегда не могут быть изменены через управление.
Моё мнение: фокус этой дискуссии должен сместиться с вопроса «есть ли возможность нажать кнопку паузы» на вопрос «следует ли наделять узлы правом адресной блокировки». Первое можно использовать, чтобы выиграть время для расследования, когда протокол оказывается в опасности целиком, но тогда останавливаются все обычные пользователи. Второе кажется более точным, но тогда нужно отвечать на вопросы: кто подаёт список, какой порог доказательств должен быть достигнут, как исправляются ошибки, и что делать, если мнения разных узлов не совпадают. Без этих процедур точечная блокировка может превратиться в недоступную для аудита произвольную блокировку.
На данный момент это разъяснение THORChain не даёт плана адресной блокировки в отношении украденных активов на Bitget и не подтверждает конкретное количество средств, которые прошли через эту сеть. Поэтому нельзя напрямую выдавать оценки on-chain слежки из соцсетей за официально подтверждённую сумму. Далее я посмотрю, появятся ли официальные предложения по управлению, проверяемые доказательства адресов и чёткий механизм апелляции. Если все три условия будут выполнены и фактическое исполнение произойдёт, тогда оценку нынешней ситуации «сеть можно только остановить, но нельзя адресно обработать» придётся обновить.
Если доказательства будут достаточно однозначными, вы бы поддержали предоставление узлам полномочий на ограниченную по времени адресную блокировку? Какой, по-вашему, должен быть уровень порога одобрения, чтобы средства обычных пользователей не оказывались под риском из‑за возможных ошибок в вынесении решения?
Сначала расставим таймлайн по местам. 27 сентября THORChain официально подчеркнула, что сеть не требует разрешений и рассчитана на устойчивость к цензуре. 28 сентября в 14:36 (по пекинскому времени) она пояснила дальше: экстренное отключение сети — это механизм безопасности протокола и не означает выборочную заморозку какого-то адреса или отдельной операции обмена. В качестве примера официально приводят старый случай с атакой на пул ликвидности в мае этого года: хотя тогда и было применено аварийное приостановление, адрес атакующего не был включён в чёрный список. Речь идёт об историческом событии, и его нельзя ошибочно истолковать как то, что сегодня сеть снова остановлена из‑за инцидента на Bitget.
Это также можно найти в технической документации: узлы могут с помощью аварийных параметров приостановить транзакции всей сети или приостановить обмены, связанные с конкретной цепочкой. Это все — общий рубильник, расширяющий влияние. А «сделать так, чтобы конкретный кошелёк не мог выполнить обмен» требует другой системы — распознавания адресов, исполнения правил и процедур управления (governance). Уметь делать первое логически не доказывает автоматически, что уже есть второе. И наоборот: текущий дизайн не даёт возможности для такой адресной блокировки, но это не означает, что в будущем правила навсегда не могут быть изменены через управление.
Моё мнение: фокус этой дискуссии должен сместиться с вопроса «есть ли возможность нажать кнопку паузы» на вопрос «следует ли наделять узлы правом адресной блокировки». Первое можно использовать, чтобы выиграть время для расследования, когда протокол оказывается в опасности целиком, но тогда останавливаются все обычные пользователи. Второе кажется более точным, но тогда нужно отвечать на вопросы: кто подаёт список, какой порог доказательств должен быть достигнут, как исправляются ошибки, и что делать, если мнения разных узлов не совпадают. Без этих процедур точечная блокировка может превратиться в недоступную для аудита произвольную блокировку.
На данный момент это разъяснение THORChain не даёт плана адресной блокировки в отношении украденных активов на Bitget и не подтверждает конкретное количество средств, которые прошли через эту сеть. Поэтому нельзя напрямую выдавать оценки on-chain слежки из соцсетей за официально подтверждённую сумму. Далее я посмотрю, появятся ли официальные предложения по управлению, проверяемые доказательства адресов и чёткий механизм апелляции. Если все три условия будут выполнены и фактическое исполнение произойдёт, тогда оценку нынешней ситуации «сеть можно только остановить, но нельзя адресно обработать» придётся обновить.
Если доказательства будут достаточно однозначными, вы бы поддержали предоставление узлам полномочий на ограниченную по времени адресную блокировку? Какой, по-вашему, должен быть уровень порога одобрения, чтобы средства обычных пользователей не оказывались под риском из‑за возможных ошибок в вынесении решения?
