Важность безопасности кросс-чейн протоколов и недостатки LayerZero
Проблемы безопасности кросс-чейн протоколов в последние годы вызывают большое внимание. Судя по сумме убытков от инцидентов безопасности, произошедших на различных блокчейнах за последние два года, убытки, связанные с кросс-чейн протоколами, занимают первое место. Важность и срочность решения проблем безопасности кросс-чейн протоколов даже превышает необходимость в масштабировании Ethereum. Взаимодействие между кросс-чейн протоколами является внутренним требованием для соединения экосистемы Web3 в сеть. Такие протоколы обычно получают огромные инвестиции, их общая заблокированная стоимость (TVL) и количество транзакций также растет под давлением жесткого спроса. Однако, из-за низкой осведомленности общественности о этих протоколах, трудно точно оценить их уровень безопасности.
Давайте сначала рассмотрим типичную архитектуру проектирования кросс-чейн продукта. В процессе общения между Chain A и Chain B конкретные операции выполняет Relayer, а Oracle контролирует Relayer. Преимущества такой архитектуры заключаются в том, что она избегает сложного процесса, связанного с необходимостью третьей цепи (которая обычно не разворачивает dApp) для выполнения алгоритма консенсуса и проверки множеством узлов, что позволяет конечным пользователям получать опыт "быстрого кросс-чейн". Благодаря легкости архитектуры, небольшому объему кода и возможности прямого использования готового Chainlink в качестве Oracle, такие проекты легко быстро развернуть, но одновременно они также легко поддаются копированию, и технологический порог почти равен нулю.
Однако, в этой архитектуре как минимум есть две проблемы:
Упрощение процесса верификации десятков узлов до единой проверки Oracle значительно снижает уровень безопасности.
После упрощения до единой валидации необходимо предположить, что Relayer и Oracle независимы друг от друга. Эта предпосылка доверия трудно поддерживается на постоянной основе, не соответствует изначальной концепции криптовалюты и не может в корне гарантировать, что они не объединятся для злых намерений.
Некоторые кросс-чейн протоколы используют эту основную модель. В качестве независимого типа безопасности "ультралегкие" кросс-чейн решения отвечают только за передачу сообщений и не несут ответственности за безопасность приложений, а также не имеют возможности взять на себя такую ответственность.
Даже если разрешить нескольким сторонам запускать ретрансляторы, это не сможет полностью решить вышеуказанные проблемы. Во-первых, децентрализация не означает лишь увеличение числа операторов или доступ для всех. Сторона спроса всегда была без разрешений, и превращение стороны предложения в безразрешенную не является революционным изменением, это всего лишь изменение на стороне рынка, которое не имеет большого отношения к безопасности самого продукта. Ретрансляторы некоторых протоколов по существу просто отвечают за пересылку информации и, как и оракулы, являются доверенными третьими сторонами. Попытка повысить безопасность кросс-чейна, увеличив число доверенных субъектов с 1 до 30, является тщетной, это не изменяет характеристики продукта и может вызвать новые проблемы.
Если проект кросс-чейн токена позволяет изменять конфигурацию узлов, то существует возможность, что злоумышленник заменит их на свои собственные узлы, что приведет к подделке любых сообщений. Судя по результатам, проекты, использующие этот Протокол, все еще могут столкнуться с огромными угрозами безопасности, и эта проблема будет усугубляться в более сложных сценариях. В огромной системе, если хотя бы один элемент будет заменен, это может вызвать цепную реакцию. Некоторые кросс-чейн Протоколы сами по себе не обладают способностью решать эту проблему, и если действительно произойдет инцидент безопасности, скорее всего, они переложат ответственность на внешние приложения.
Если какой-либо Протокол не может делиться безопасностью как Layer1 или Layer2, то его нельзя считать инфраструктурой. Инфраструктура называется "базовой", потому что она может делиться безопасностью. Если какой-либо проект заявляет, что он является инфраструктурой, то он должен предоставлять консистентную безопасность для всех своих экосистемных проектов, как и другие инфраструктуры, то есть все экосистемные проекты должны делить безопасность этой инфраструктуры. Поэтому, точно говоря, некоторые кросс-чейн Протоколы не являются инфраструктурой, а промежуточным ПО. Разработчики приложений, использующие этот промежуточный SDK/API, действительно могут свободно определять свои стратегии безопасности.
Некоторые исследовательские группы указывали, что предположение о том, что владелец приложения (или лицо, обладающее приватным ключом) не будет злоупотреблять, является неверным. Если злоумышленник получит доступ к конфигурации кросс-чейн протокола, он может изменить оракулы и реле с компонентов по умолчанию на контролируемые им компоненты, что приведет к манипуляции смарт-контрактами, использующими этот механизм, и к краже активов пользователей.
Кроме того, исследования показывают, что некоторые кросс-чейн протоколы имеют критические уязвимости в реле. Хотя они в настоящее время находятся в состоянии мультиподписей, эти уязвимости могут быть использованы только внутренними лицами или членами команды с известной личностью, но все же существует потенциальный риск. Эти уязвимости могут позволить отправлять мошеннические сообщения из мультиподписей или изменять сообщения после подписания сообщений или транзакций оракулами и мультиподписями, что может привести к кражам средств всех пользователей.
Вернувшись к истокам Биткойна, мы можем увидеть основную идею, предложенную Сатоши Накамото в его белой книге: полностью децентрализованная система электронных денег, позволяющая онлайн-платежи непосредственно от одной стороны к другой без участия финансовых учреждений. Эта идея подчеркивает характеристики децентрализации и отсутствия доверия, что также стало общей целью всех разработчиков инфраструктуры в будущем.
Тем не менее, некоторые кросс-чейн протоколы в реальной работе требуют, чтобы роли Relayer и Oracle не сговаривались на зло, одновременно требуя, чтобы пользователи, использующие этот протокол для разработки приложений, рассматривались как надежные третьи лица. Участвующие в "мультиподписи" доверенные субъекты заранее назначены как привилегированные роли. Более того, в процессе кросс-чейн не было создано никаких доказательств мошенничества или доказательств действительности, не говоря уже о том, чтобы эти доказательства были записаны в блокчейн и проверены в сети. Таким образом, эти протоколы на самом деле не соответствуют "консенсусу Сатоши" и не могут быть названы по-настоящему децентрализованными и не требующими доверия системами.
При столкновении с вопросами безопасности, ответ некоторых кросс-чейн протоколов часто заключается в "отрицании" и снова "отрицании". Однако история показывает, что до биткойна было много попыток создать электронные деньги, но все они потерпели неудачу, поскольку не достигли целей децентрализации, устойчивости к атакам и внутренней ценности. Кросс-чейн протоколы также подвержены этому: независимо от того, насколько велик объем финансирования, насколько высок трафик пользователей или насколько "чистая" их "родословная", если продукт не может обеспечить настоящую безопасность децентрализованной сети, он с большой вероятностью потерпит неудачу из-за недостаточной устойчивости к атакам.
Создание действительно децентрализованного кросс-чейн протокола является сложной задачей. Некоторые новые решения, такие как использование технологий нулевых знаний для усовершенствования кросс-чейн протоколов, могут принести новые прорывы в этой области. Однако ключевым моментом является осознание разработчиками протокола существующих проблем и готовность принять необходимые меры для улучшения.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
Анализ уязвимостей безопасности протокола кросс-чейн LayerZero и направления для улучшения
Важность безопасности кросс-чейн протоколов и недостатки LayerZero
Проблемы безопасности кросс-чейн протоколов в последние годы вызывают большое внимание. Судя по сумме убытков от инцидентов безопасности, произошедших на различных блокчейнах за последние два года, убытки, связанные с кросс-чейн протоколами, занимают первое место. Важность и срочность решения проблем безопасности кросс-чейн протоколов даже превышает необходимость в масштабировании Ethereum. Взаимодействие между кросс-чейн протоколами является внутренним требованием для соединения экосистемы Web3 в сеть. Такие протоколы обычно получают огромные инвестиции, их общая заблокированная стоимость (TVL) и количество транзакций также растет под давлением жесткого спроса. Однако, из-за низкой осведомленности общественности о этих протоколах, трудно точно оценить их уровень безопасности.
Давайте сначала рассмотрим типичную архитектуру проектирования кросс-чейн продукта. В процессе общения между Chain A и Chain B конкретные операции выполняет Relayer, а Oracle контролирует Relayer. Преимущества такой архитектуры заключаются в том, что она избегает сложного процесса, связанного с необходимостью третьей цепи (которая обычно не разворачивает dApp) для выполнения алгоритма консенсуса и проверки множеством узлов, что позволяет конечным пользователям получать опыт "быстрого кросс-чейн". Благодаря легкости архитектуры, небольшому объему кода и возможности прямого использования готового Chainlink в качестве Oracle, такие проекты легко быстро развернуть, но одновременно они также легко поддаются копированию, и технологический порог почти равен нулю.
Однако, в этой архитектуре как минимум есть две проблемы:
Упрощение процесса верификации десятков узлов до единой проверки Oracle значительно снижает уровень безопасности.
После упрощения до единой валидации необходимо предположить, что Relayer и Oracle независимы друг от друга. Эта предпосылка доверия трудно поддерживается на постоянной основе, не соответствует изначальной концепции криптовалюты и не может в корне гарантировать, что они не объединятся для злых намерений.
Некоторые кросс-чейн протоколы используют эту основную модель. В качестве независимого типа безопасности "ультралегкие" кросс-чейн решения отвечают только за передачу сообщений и не несут ответственности за безопасность приложений, а также не имеют возможности взять на себя такую ответственность.
Даже если разрешить нескольким сторонам запускать ретрансляторы, это не сможет полностью решить вышеуказанные проблемы. Во-первых, децентрализация не означает лишь увеличение числа операторов или доступ для всех. Сторона спроса всегда была без разрешений, и превращение стороны предложения в безразрешенную не является революционным изменением, это всего лишь изменение на стороне рынка, которое не имеет большого отношения к безопасности самого продукта. Ретрансляторы некоторых протоколов по существу просто отвечают за пересылку информации и, как и оракулы, являются доверенными третьими сторонами. Попытка повысить безопасность кросс-чейна, увеличив число доверенных субъектов с 1 до 30, является тщетной, это не изменяет характеристики продукта и может вызвать новые проблемы.
Если проект кросс-чейн токена позволяет изменять конфигурацию узлов, то существует возможность, что злоумышленник заменит их на свои собственные узлы, что приведет к подделке любых сообщений. Судя по результатам, проекты, использующие этот Протокол, все еще могут столкнуться с огромными угрозами безопасности, и эта проблема будет усугубляться в более сложных сценариях. В огромной системе, если хотя бы один элемент будет заменен, это может вызвать цепную реакцию. Некоторые кросс-чейн Протоколы сами по себе не обладают способностью решать эту проблему, и если действительно произойдет инцидент безопасности, скорее всего, они переложат ответственность на внешние приложения.
Если какой-либо Протокол не может делиться безопасностью как Layer1 или Layer2, то его нельзя считать инфраструктурой. Инфраструктура называется "базовой", потому что она может делиться безопасностью. Если какой-либо проект заявляет, что он является инфраструктурой, то он должен предоставлять консистентную безопасность для всех своих экосистемных проектов, как и другие инфраструктуры, то есть все экосистемные проекты должны делить безопасность этой инфраструктуры. Поэтому, точно говоря, некоторые кросс-чейн Протоколы не являются инфраструктурой, а промежуточным ПО. Разработчики приложений, использующие этот промежуточный SDK/API, действительно могут свободно определять свои стратегии безопасности.
Некоторые исследовательские группы указывали, что предположение о том, что владелец приложения (или лицо, обладающее приватным ключом) не будет злоупотреблять, является неверным. Если злоумышленник получит доступ к конфигурации кросс-чейн протокола, он может изменить оракулы и реле с компонентов по умолчанию на контролируемые им компоненты, что приведет к манипуляции смарт-контрактами, использующими этот механизм, и к краже активов пользователей.
Кроме того, исследования показывают, что некоторые кросс-чейн протоколы имеют критические уязвимости в реле. Хотя они в настоящее время находятся в состоянии мультиподписей, эти уязвимости могут быть использованы только внутренними лицами или членами команды с известной личностью, но все же существует потенциальный риск. Эти уязвимости могут позволить отправлять мошеннические сообщения из мультиподписей или изменять сообщения после подписания сообщений или транзакций оракулами и мультиподписями, что может привести к кражам средств всех пользователей.
Вернувшись к истокам Биткойна, мы можем увидеть основную идею, предложенную Сатоши Накамото в его белой книге: полностью децентрализованная система электронных денег, позволяющая онлайн-платежи непосредственно от одной стороны к другой без участия финансовых учреждений. Эта идея подчеркивает характеристики децентрализации и отсутствия доверия, что также стало общей целью всех разработчиков инфраструктуры в будущем.
Тем не менее, некоторые кросс-чейн протоколы в реальной работе требуют, чтобы роли Relayer и Oracle не сговаривались на зло, одновременно требуя, чтобы пользователи, использующие этот протокол для разработки приложений, рассматривались как надежные третьи лица. Участвующие в "мультиподписи" доверенные субъекты заранее назначены как привилегированные роли. Более того, в процессе кросс-чейн не было создано никаких доказательств мошенничества или доказательств действительности, не говоря уже о том, чтобы эти доказательства были записаны в блокчейн и проверены в сети. Таким образом, эти протоколы на самом деле не соответствуют "консенсусу Сатоши" и не могут быть названы по-настоящему децентрализованными и не требующими доверия системами.
При столкновении с вопросами безопасности, ответ некоторых кросс-чейн протоколов часто заключается в "отрицании" и снова "отрицании". Однако история показывает, что до биткойна было много попыток создать электронные деньги, но все они потерпели неудачу, поскольку не достигли целей децентрализации, устойчивости к атакам и внутренней ценности. Кросс-чейн протоколы также подвержены этому: независимо от того, насколько велик объем финансирования, насколько высок трафик пользователей или насколько "чистая" их "родословная", если продукт не может обеспечить настоящую безопасность децентрализованной сети, он с большой вероятностью потерпит неудачу из-за недостаточной устойчивости к атакам.
Создание действительно децентрализованного кросс-чейн протокола является сложной задачей. Некоторые новые решения, такие как использование технологий нулевых знаний для усовершенствования кросс-чейн протоколов, могут принести новые прорывы в этой области. Однако ключевым моментом является осознание разработчиками протокола существующих проблем и готовность принять необходимые меры для улучшения.