Безопасность кросс-чейн протоколов всегда была в центре внимания отрасли. В последние годы убытки от инцидентов безопасности кросс-чейн протоколов достигли огромных масштабов, и их важность даже превысила важность решений по масштабированию Ethereum. Взаимодействие кросс-чейн протоколов является внутренней необходимостью для сетевой структуры Web3, но общество недостаточно осведомлено о уровнях безопасности этих протоколов.
Некоторый известный кросс-чейн протокол использует упрощенный архитектурный дизайн. Его коммуникационный процесс выполняется релеем, а оракул осуществляет надзор за релеем. Этот дизайн избегает традиционной проверки консенсуса третьей цепи, предоставляя пользователям быстрый кросс-чейн опыт. Однако в этой архитектуре как минимум существуют две проблемы:
Упрощение многоузловой проверки до проверки единого оракула значительно снизило коэффициент безопасности.
Предположим, что ретрансляторы и оракулы независимы, это предположение о доверии трудно поддерживать в долгосрочной перспективе и недостаточно крипто-нативно.
Данный протокол, являясь "суперлегким" кросс-чейн решением, отвечает лишь за передачу сообщений и не может нести ответственность за безопасность приложений. Даже если открыть права реле, позволяя большему количеству участников запускать, это не сможет принципиально решить вышеуказанные проблемы. Увеличение числа доверенных субъектов не повышает безопасность кросс-чейн, а наоборот, может вызвать новые проблемы.
Если проект кросс-чейн токенов, использующий этот Протокол, позволяет изменять конфигурационные узлы, злоумышленник может заменить их на свои узлы и подделать любые сообщения. Этот риск становится более серьезным в сложных сценариях. Сам Протокол трудно решить эту проблему, и в случае возникновения инцидента безопасности ответственность может быть перекладываться на внешние приложения.
Этот Протокол больше похож на посредника, чем на инфраструктуру. Инфраструктура должна обеспечивать единообразную безопасность для всех экосистемных проектов, но этот Протокол не может этого сделать. Разработчики приложений, использующие его SDK/API, могут настраивать свои стратегии безопасности, но это не эквивалентно совместной безопасности.
Некоторые команды безопасности указывают, что предположение о том, что владельцы приложений не будут злоупотреблять, неверно. Если злоумышленник получит доступ к конфигурации, он может изменить оракулы и ретрансляторы на контролируемые компоненты, что приведет к краже активов пользователей. Другая команда обнаружила два ключевых уязвимости в ретрансляторах протокола, которые могут привести к отправке мошеннических сообщений и изменению сообщений.
Обратясь к белой книге Биткойна, мы можем выделить основные характеристики "консенсуса Сатоши Накамото": децентрализация и отсутствие доверия. Протоколы кросс-чейн по своей сути должны быть одноранговыми системами, не требующими надежных третьих сторон. Кросс-чейн протоколы, не соответствующие этому консенсусу, могут рассматриваться как псевдо-децентрализованные протоколы.
Данный Протокол требует, чтобы ретрансляторы и оракулы не сговаривались на зло, а также требует от пользователей доверять разработчикам приложений, использующим данный Протокол. В процессе кросс-чейн не генерируются доказательства мошенничества или доказательства действительности, и тем более эти доказательства не верифицируются в блокчейне. Таким образом, данный Протокол не удовлетворяет "консенсусу Сатоши" и не может считаться децентрализованной и не требующей доверия системой.
При столкновении с вопросами о безопасности данное Протокол обычно отвечает отрицательно. Однако, независимо от масштаба финансирования или объема трафика, если продукт не сможет обеспечить по-настоящему децентрализованную безопасность, он может потерпеть неудачу из-за недостаточной устойчивости к атакам.
Создание действительно децентрализованного кросс-чейн протокола по-прежнему является важной задачей, с которой сталкивается отрасль. Некоторые новые технологии, такие как доказательства с нулевым разглашением, могут предложить новые идеи для решения этой проблемы.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
15 Лайков
Награда
15
7
Поделиться
комментарий
0/400
SerumSquirter
· 07-05 18:07
Кто еще осмелится на это, честно говоря.
Посмотреть ОригиналОтветить0
MetaMaskVictim
· 07-04 18:33
Еще один аппарат для разыгрывания людей как лохов
Посмотреть ОригиналОтветить0
ser_ngmi
· 07-03 03:23
кросс-чейн снова начал действовать? Шутом оказалась сторона Протокола
Посмотреть ОригиналОтветить0
GhostAddressMiner
· 07-03 03:23
в блокчейне уже проявилась аномальная модель миграции, ждем и смотрим на представление
Обсуждение безопасности кросс-чейн протокола: важность децентрализации и отсутствия доверия
Безопасность кросс-чейн протоколов всегда была в центре внимания отрасли. В последние годы убытки от инцидентов безопасности кросс-чейн протоколов достигли огромных масштабов, и их важность даже превысила важность решений по масштабированию Ethereum. Взаимодействие кросс-чейн протоколов является внутренней необходимостью для сетевой структуры Web3, но общество недостаточно осведомлено о уровнях безопасности этих протоколов.
Некоторый известный кросс-чейн протокол использует упрощенный архитектурный дизайн. Его коммуникационный процесс выполняется релеем, а оракул осуществляет надзор за релеем. Этот дизайн избегает традиционной проверки консенсуса третьей цепи, предоставляя пользователям быстрый кросс-чейн опыт. Однако в этой архитектуре как минимум существуют две проблемы:
Данный протокол, являясь "суперлегким" кросс-чейн решением, отвечает лишь за передачу сообщений и не может нести ответственность за безопасность приложений. Даже если открыть права реле, позволяя большему количеству участников запускать, это не сможет принципиально решить вышеуказанные проблемы. Увеличение числа доверенных субъектов не повышает безопасность кросс-чейн, а наоборот, может вызвать новые проблемы.
Если проект кросс-чейн токенов, использующий этот Протокол, позволяет изменять конфигурационные узлы, злоумышленник может заменить их на свои узлы и подделать любые сообщения. Этот риск становится более серьезным в сложных сценариях. Сам Протокол трудно решить эту проблему, и в случае возникновения инцидента безопасности ответственность может быть перекладываться на внешние приложения.
Этот Протокол больше похож на посредника, чем на инфраструктуру. Инфраструктура должна обеспечивать единообразную безопасность для всех экосистемных проектов, но этот Протокол не может этого сделать. Разработчики приложений, использующие его SDK/API, могут настраивать свои стратегии безопасности, но это не эквивалентно совместной безопасности.
Некоторые команды безопасности указывают, что предположение о том, что владельцы приложений не будут злоупотреблять, неверно. Если злоумышленник получит доступ к конфигурации, он может изменить оракулы и ретрансляторы на контролируемые компоненты, что приведет к краже активов пользователей. Другая команда обнаружила два ключевых уязвимости в ретрансляторах протокола, которые могут привести к отправке мошеннических сообщений и изменению сообщений.
Обратясь к белой книге Биткойна, мы можем выделить основные характеристики "консенсуса Сатоши Накамото": децентрализация и отсутствие доверия. Протоколы кросс-чейн по своей сути должны быть одноранговыми системами, не требующими надежных третьих сторон. Кросс-чейн протоколы, не соответствующие этому консенсусу, могут рассматриваться как псевдо-децентрализованные протоколы.
Данный Протокол требует, чтобы ретрансляторы и оракулы не сговаривались на зло, а также требует от пользователей доверять разработчикам приложений, использующим данный Протокол. В процессе кросс-чейн не генерируются доказательства мошенничества или доказательства действительности, и тем более эти доказательства не верифицируются в блокчейне. Таким образом, данный Протокол не удовлетворяет "консенсусу Сатоши" и не может считаться децентрализованной и не требующей доверия системой.
При столкновении с вопросами о безопасности данное Протокол обычно отвечает отрицательно. Однако, независимо от масштаба финансирования или объема трафика, если продукт не сможет обеспечить по-настоящему децентрализованную безопасность, он может потерпеть неудачу из-за недостаточной устойчивости к атакам.
Создание действительно децентрализованного кросс-чейн протокола по-прежнему является важной задачей, с которой сталкивается отрасль. Некоторые новые технологии, такие как доказательства с нулевым разглашением, могут предложить новые идеи для решения этой проблемы.