Я заметил примечательную деталь, если посмотреть, как @Dusk связывает повторное открытие моста с самим DuskEVM: официальное сообщение прямо говорит, что мост будет закрыт до тех пор, пока не появятся план и сроки повторного открытия, и при этом продолжается запуск DuskEVM — то есть эти два действия объединены в одно общее решение, а не разделены.
Именно это заставило меня остановиться. Сначала могло казаться, что проблема с мостом — это просто частный операционный сбой, который нужно починить, а затем открыть снова «как было». Но привязка к запуску DuskEVM намекает на другой сценарий: команда, возможно, использует эту возможность, чтобы полностью пересобрать архитектуру custody моста.
Если это так, то это куда более зрелая реакция, чем просто быстро починить и открыть снова, чтобы снизить давление со стороны общественного мнения. Также важно техническое фоновое обстоятельство: двухсторонний мост между исходным DUSK и новым BEP20 начал работать всего за несколько месяцев до инцидента, а односторонний мост для миграции, уже прошедший аудит Zellic, не выявил уязвимостей. Это укрепляет точку зрения, что инцидент — не ошибка проектирования смарт-контракта, а как и сказано в сообщении: проблема находится в управлении операционными кошельками, то есть в слое, выходящем за пределы обычного аудита смарт-контрактов.
Самооспаривание: задержка DuskEVM ради более тщательной проработки части с мостом тоже имеет свою цену — каждое дополнительное промедление означает еще неделю ожидания со стороны сообщества ключевого вехового события в недавнем роадмапе, и терпение рынка не бесконечно.
Я жду, чтобы $DUSK опубликовал(а) новую модель custody для моста — возможно, более распределенный multisig или threshold-signature — вместо простого восстановления ровно той же структуры, что была до инцидента.
#dusk $BTC $ETH
Именно это заставило меня остановиться. Сначала могло казаться, что проблема с мостом — это просто частный операционный сбой, который нужно починить, а затем открыть снова «как было». Но привязка к запуску DuskEVM намекает на другой сценарий: команда, возможно, использует эту возможность, чтобы полностью пересобрать архитектуру custody моста.
Если это так, то это куда более зрелая реакция, чем просто быстро починить и открыть снова, чтобы снизить давление со стороны общественного мнения. Также важно техническое фоновое обстоятельство: двухсторонний мост между исходным DUSK и новым BEP20 начал работать всего за несколько месяцев до инцидента, а односторонний мост для миграции, уже прошедший аудит Zellic, не выявил уязвимостей. Это укрепляет точку зрения, что инцидент — не ошибка проектирования смарт-контракта, а как и сказано в сообщении: проблема находится в управлении операционными кошельками, то есть в слое, выходящем за пределы обычного аудита смарт-контрактов.
Самооспаривание: задержка DuskEVM ради более тщательной проработки части с мостом тоже имеет свою цену — каждое дополнительное промедление означает еще неделю ожидания со стороны сообщества ключевого вехового события в недавнем роадмапе, и терпение рынка не бесконечно.
Я жду, чтобы $DUSK опубликовал(а) новую модель custody для моста — возможно, более распределенный multisig или threshold-signature — вместо простого восстановления ровно той же структуры, что была до инцидента.
#dusk $BTC $ETH
