Безопасностные вызовы кросс-чейн протокола и ограничения LayerZero
В экосистеме Web3 важность кросс-чейн протоколов становится всё более очевидной. Однако произошедшие в последние годы инциденты с безопасностью показывают, что эти протоколы представляют собой потенциально огромные риски. Фактически, убытки, вызванные кросс-чейн протоколами, занимают первое место среди различных инцидентов безопасности блокчейна, и их важность даже превосходит решения по масштабированию Ethereum.
Некоторые кросс-чейн протоколы имеют на вид простую конструкцию, но это не означает, что они являются отличными или безопасными решениями. В качестве примера можно привести известный кросс-чейн протокол, который, хотя и имеет простую архитектуру, обладает очевидными угрозами безопасности.
Основная структура данного протокола такова: связь между Chain A и Chain B осуществляется Relayer, а Oracle отвечает за надзор за Relayer. Хотя такой дизайн избегает сложного процесса консенсуса, требующего третьей цепи, и предоставляет пользователям быстрый кросс-чейн опыт, он также несет в себе серьезные риски безопасности.
Во-первых, упрощение многоузловой валидации до единого валидации Oracle значительно снижает коэффициент безопасности. Во-вторых, такой дизайн должен предполагать, что Relayer и Oracle полностью независимы, что в реальности трудно гарантировать на постоянной основе, существует риск сговора.
Некоторые могут считать, что увеличение количества Relayer может повысить безопасность. Однако такой подход не решает проблему в корне. Увеличение числа участников не равно децентрализации и не может изменить основные характеристики продукта.
Более того, если проект, использующий данный Протокол, позволяет изменять конфигурационные узлы, злоумышленник может заменить их на узлы, находящиеся под его контролем, что приведет к подделке сообщений. Этот риск будет более серьезным в сложных сценариях, и сам Протокол не имеет возможности решить эту проблему.
Некоторые исследовательские группы по безопасности указали на потенциальные уязвимости данного Протокола. Например, если владелец приложения или держатель приватного ключа ведут себя недобросовестно, это может привести к краже активов пользователей. Кроме того, исследования выявили критическую уязвимость в ретрансляторах данного Протокола, которую могут использовать внутренние лица или члены команды с известной личностью.
Настоящий децентрализованный кросс-чейн протокол должен следовать основной концепции "консенсуса Сатоши Накамото", то есть исключить доверенные третьи стороны и добиться настоящей недоверенности и децентрализации. Однако некоторые кросс-чейн протоколы, которые утверждают, что они децентрализованные, на самом деле не соответствуют этим стандартам. Они могут требовать от пользователей доверия к нескольким ролям, которые не будут сговариваться на зло, или рассматривать разработчиков приложений как доверенные третьи стороны.
Создание настоящего кросс-чейн протокола является сложной задачей. Это требует не только избегания введения доверенных третьих сторон на этапе проектирования, но также должно быть в состоянии генерировать доказательства мошенничества или доказательства действительности и загружать эти доказательства в блокчейн для проверки. Только так можно действительно достичь децентрализации и недоверия.
При оценке кросс-чейн протоколов мы не должны быть введены в заблуждение поверхностным простым дизайном или огромным финансированием. Настоящие безопасные и децентрализованные кросс-чейн решения требуют более глубоких усилий в техническом дизайне и реализации, возможно, с использованием таких передовых технологий, как нулевые знания, для повышения безопасности и уровня децентрализации.
В будущем только те протоколы, которые смогут обеспечить настоящую децентрализованную безопасность, смогут выделиться на фоне жесткой конкуренции и предоставить надежную кросс-чейн инфраструктуру для экосистемы Web3.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
12 Лайков
Награда
12
6
Поделиться
комментарий
0/400
DefiVeteran
· 7ч назад
layer0 не работает, кросс-чейн меня задушит..
Посмотреть ОригиналОтветить0
ForumMiningMaster
· 7ч назад
Сразу же произошло падение, потерял все.
Посмотреть ОригиналОтветить0
ZenMiner
· 7ч назад
Простота ≠ безопасность. Я видел так много ужасных случаев.
Посмотреть ОригиналОтветить0
wrekt_but_learning
· 7ч назад
Давно думал, что LayerZero ненадежен... ждал, когда это произойдет.
Посмотреть ОригиналОтветить0
PrivacyMaximalist
· 7ч назад
кросс-чейн риск действительно слишком велик who dare who die
Посмотреть ОригиналОтветить0
AirdropGrandpa
· 8ч назад
Упрощение не всегда хорошо, эту ответственность придется нести несколько лет.
Безопасность LayerZero и вызовы децентрализации кросс-чейн протоколов
Безопасностные вызовы кросс-чейн протокола и ограничения LayerZero
В экосистеме Web3 важность кросс-чейн протоколов становится всё более очевидной. Однако произошедшие в последние годы инциденты с безопасностью показывают, что эти протоколы представляют собой потенциально огромные риски. Фактически, убытки, вызванные кросс-чейн протоколами, занимают первое место среди различных инцидентов безопасности блокчейна, и их важность даже превосходит решения по масштабированию Ethereum.
Некоторые кросс-чейн протоколы имеют на вид простую конструкцию, но это не означает, что они являются отличными или безопасными решениями. В качестве примера можно привести известный кросс-чейн протокол, который, хотя и имеет простую архитектуру, обладает очевидными угрозами безопасности.
Основная структура данного протокола такова: связь между Chain A и Chain B осуществляется Relayer, а Oracle отвечает за надзор за Relayer. Хотя такой дизайн избегает сложного процесса консенсуса, требующего третьей цепи, и предоставляет пользователям быстрый кросс-чейн опыт, он также несет в себе серьезные риски безопасности.
Во-первых, упрощение многоузловой валидации до единого валидации Oracle значительно снижает коэффициент безопасности. Во-вторых, такой дизайн должен предполагать, что Relayer и Oracle полностью независимы, что в реальности трудно гарантировать на постоянной основе, существует риск сговора.
Некоторые могут считать, что увеличение количества Relayer может повысить безопасность. Однако такой подход не решает проблему в корне. Увеличение числа участников не равно децентрализации и не может изменить основные характеристики продукта.
Более того, если проект, использующий данный Протокол, позволяет изменять конфигурационные узлы, злоумышленник может заменить их на узлы, находящиеся под его контролем, что приведет к подделке сообщений. Этот риск будет более серьезным в сложных сценариях, и сам Протокол не имеет возможности решить эту проблему.
Некоторые исследовательские группы по безопасности указали на потенциальные уязвимости данного Протокола. Например, если владелец приложения или держатель приватного ключа ведут себя недобросовестно, это может привести к краже активов пользователей. Кроме того, исследования выявили критическую уязвимость в ретрансляторах данного Протокола, которую могут использовать внутренние лица или члены команды с известной личностью.
Настоящий децентрализованный кросс-чейн протокол должен следовать основной концепции "консенсуса Сатоши Накамото", то есть исключить доверенные третьи стороны и добиться настоящей недоверенности и децентрализации. Однако некоторые кросс-чейн протоколы, которые утверждают, что они децентрализованные, на самом деле не соответствуют этим стандартам. Они могут требовать от пользователей доверия к нескольким ролям, которые не будут сговариваться на зло, или рассматривать разработчиков приложений как доверенные третьи стороны.
Создание настоящего кросс-чейн протокола является сложной задачей. Это требует не только избегания введения доверенных третьих сторон на этапе проектирования, но также должно быть в состоянии генерировать доказательства мошенничества или доказательства действительности и загружать эти доказательства в блокчейн для проверки. Только так можно действительно достичь децентрализации и недоверия.
При оценке кросс-чейн протоколов мы не должны быть введены в заблуждение поверхностным простым дизайном или огромным финансированием. Настоящие безопасные и децентрализованные кросс-чейн решения требуют более глубоких усилий в техническом дизайне и реализации, возможно, с использованием таких передовых технологий, как нулевые знания, для повышения безопасности и уровня децентрализации.
В будущем только те протоколы, которые смогут обеспечить настоящую децентрализованную безопасность, смогут выделиться на фоне жесткой конкуренции и предоставить надежную кросс-чейн инфраструктуру для экосистемы Web3.