Обсуждение безопасности и децентрализации кросс-чейн протоколов
Проблемы безопасности кросс-чейн протоколов в последние годы привлекают большое внимание. Судя по потерям, вызванным событиями безопасности на различных блокчейнах за последние два года, убытки от инцидентов, связанных с кросс-чейн протоколами, занимают первое место. Важность и срочность решения проблем безопасности кросс-чейн протоколов превышает даже решение проблемы масштабируемости Ethereum. Взаимодействие между кросс-чейн протоколами является внутренним требованием взаимосвязанности Web3. Обычно такие протоколы имеют огромные объемы финансирования, общая заблокированная стоимость (TVL) и объемы торговли постоянно растут под давлением жесткого спроса. Однако из-за низкого уровня осведомленности общественности о этих кросс-чейн протоколах сложно точно оценить их уровень безопасности.
Давайте сначала рассмотрим типичную архитектуру проектирования кросс-чейн продукта. В процессе коммуникации между Chain A и Chain B конкретные операции выполняются Relayer, а Oracle отвечает за мониторинг Relayer. Одним из преимуществ такой архитектуры является то, что она избегает необходимости в третьей цепи (которая обычно не развертывает dApp) для завершения процесса алгоритма консенсуса и верификации десятков узлов, тем самым обеспечивая конечным пользователям опыт «быстрого кросс-чейн». Благодаря легковесной архитектуре, небольшому объему кода и тому, что Oracle может напрямую использовать готовые сервисы, такие как Chainlink, такие проекты легко быстро запускать, но в то же время они также легко могут быть скопированы, и порог технологий ниже.
Однако эта архитектура имеет по крайней мере две проблемы:
Упрощение процесса валидации для десятков узлов в единую валидацию Oracle значительно снижает уровень безопасности.
После упрощения до единой проверки необходимо предположить, что Relayer и Oracle являются независимыми друг от друга. Однако это предположение о доверии не может оставаться верным навсегда, недостаток достаточных характеристик Децентрализации не может в корне гарантировать, что они не будут сговариваться на зло.
Некоторые могут спросить, если открыть Relayer и позволить большему количеству участников запускать ретрансляторы, сможет ли это решить вышеупомянутую проблему? На самом деле, просто увеличение числа операторов не равно Децентрализация. Позволить любому подключаться к системе - это всего лишь реализация без разрешений (Permissionless), это изменение на стороне рынка, которое не имеет большого отношения к безопасности самого продукта. Relayer по сути является лишь посредником, ответственным за передачу информации, и, как и Oracle, относится к доверенным третьим сторонам. Попытка повысить безопасность кросс-чейн, увеличивая количество доверенных субъектов, является тщетной; это не только не изменяет основные характеристики продукта, но также может вызвать новые проблемы.
Если проект кросс-чейн токенов позволяет изменять используемую конфигурацию узлов, злоумышленник может заменить узлы на контролируемые им, что позволит подделывать любые сообщения. Эта угроза безопасности может привести к более серьезным последствиям в более сложных сценариях. В огромной системе, если хотя бы один элемент будет заменен, это может вызвать цепную реакцию. А некоторые кросс-чейн протоколы сами по себе не обладают способностью решать подобные проблемы, и если действительно произойдет инцидент с безопасностью, ответственность, скорее всего, будет возложена на внешние приложения.
Что касается проектов, которые заявляют, что они являются инфраструктурой, если они не могут предоставить совместимую безопасность, как Layer 1 или Layer 2, то такая позиция "инфраструктуры" заслуживает обсуждения. Настоящая инфраструктура "основная", потому что она может обеспечить единое обеспечение безопасности для всей экосистемы. Поэтому более точным определением для некоторых кросс-чейн протоколов может быть промежуточное ПО (Middleware), а не инфраструктура.
Некоторые команды безопасности указали на потенциальные уязвимости в некоторых кросс-чейн протоколах. Например, если злонамеренный деятель получит доступ к конфигурации протокола, он может изменить оракулы и реле на компоненты, которые он контролирует, обманув смарт-контракт и приведя к краже активов пользователей. Также исследования показали, что реле некоторых протоколов имеют критические уязвимости, хотя в настоящее время они защищены многофакторной подписью, их все равно могут использовать внутренние лица или члены команды с известной идентичностью.
При оценке кросс-чейн протоколов мы должны вернуться к истокам и обратиться к основным идеям, изложенным в белой книге Биткойна. Основная характеристика консенсуса Сатоши Накамото заключается в устранении доверенных третьих сторон, обеспечении недоверия (Trustless) и децентрализации (Децентрализация). Кросс-чейн коммуникационный протокол по своей сути должен быть, как Биткойн, пиринговой системой, позволяющей одной стороне напрямую отправлять информацию от Chain A к другой стороне Chain B без необходимости обращаться к каким-либо доверенным посредникам.
Обладающий Децентрализация и бездоверительными характеристиками "консенсус Сатоши" стал общей целью для всех разработчиков инфраструктуры в дальнейшем. Кросс-чейн Протоколы, не соответствующие этому консенсусу, вряд ли могут считаться настоящими Децентрализация кросс-чейн Протоколами, и не следует легко использовать такие высокие термины, как "Децентрализация" и "бездоверительный", чтобы описывать характеристики своего продукта.
Настоящий протокол кросс-чейн децентрализации должен уметь генерировать доказательства мошенничества или доказательства действительности на протяжении всего процесса кросс-чейн и загружать эти доказательства в блокчейн для проверки. Только так можно действительно достичь децентрализации и отсутствия доверия.
Для тех, кто утверждает, что использует инновационные технологии (такие как нулевые доказательства) для улучшения кросс-чейн протоколов, ключевым моментом является то, осознают ли они действительно свои существующие проблемы. Только признав проблемы, можно действительно продвигать технологический прогресс и строить более безопасную и более децентрализованную кросс-чейн экосистему.
Посмотреть Оригинал
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
12 Лайков
Награда
12
3
Поделиться
комментарий
0/400
ForkThisDAO
· 17ч назад
资金又要被 падение до нуля
Посмотреть ОригиналОтветить0
MetaMaximalist
· 21ч назад
лmao еще один день, еще один мостовой взлом... когда же эти плебеи научатся правильной архитектуре безопасности?
Безопасность кросс-чейн Протоколов и глубокие размышления о Децентрализации
Обсуждение безопасности и децентрализации кросс-чейн протоколов
Проблемы безопасности кросс-чейн протоколов в последние годы привлекают большое внимание. Судя по потерям, вызванным событиями безопасности на различных блокчейнах за последние два года, убытки от инцидентов, связанных с кросс-чейн протоколами, занимают первое место. Важность и срочность решения проблем безопасности кросс-чейн протоколов превышает даже решение проблемы масштабируемости Ethereum. Взаимодействие между кросс-чейн протоколами является внутренним требованием взаимосвязанности Web3. Обычно такие протоколы имеют огромные объемы финансирования, общая заблокированная стоимость (TVL) и объемы торговли постоянно растут под давлением жесткого спроса. Однако из-за низкого уровня осведомленности общественности о этих кросс-чейн протоколах сложно точно оценить их уровень безопасности.
Давайте сначала рассмотрим типичную архитектуру проектирования кросс-чейн продукта. В процессе коммуникации между Chain A и Chain B конкретные операции выполняются Relayer, а Oracle отвечает за мониторинг Relayer. Одним из преимуществ такой архитектуры является то, что она избегает необходимости в третьей цепи (которая обычно не развертывает dApp) для завершения процесса алгоритма консенсуса и верификации десятков узлов, тем самым обеспечивая конечным пользователям опыт «быстрого кросс-чейн». Благодаря легковесной архитектуре, небольшому объему кода и тому, что Oracle может напрямую использовать готовые сервисы, такие как Chainlink, такие проекты легко быстро запускать, но в то же время они также легко могут быть скопированы, и порог технологий ниже.
Однако эта архитектура имеет по крайней мере две проблемы:
Упрощение процесса валидации для десятков узлов в единую валидацию Oracle значительно снижает уровень безопасности.
После упрощения до единой проверки необходимо предположить, что Relayer и Oracle являются независимыми друг от друга. Однако это предположение о доверии не может оставаться верным навсегда, недостаток достаточных характеристик Децентрализации не может в корне гарантировать, что они не будут сговариваться на зло.
Некоторые могут спросить, если открыть Relayer и позволить большему количеству участников запускать ретрансляторы, сможет ли это решить вышеупомянутую проблему? На самом деле, просто увеличение числа операторов не равно Децентрализация. Позволить любому подключаться к системе - это всего лишь реализация без разрешений (Permissionless), это изменение на стороне рынка, которое не имеет большого отношения к безопасности самого продукта. Relayer по сути является лишь посредником, ответственным за передачу информации, и, как и Oracle, относится к доверенным третьим сторонам. Попытка повысить безопасность кросс-чейн, увеличивая количество доверенных субъектов, является тщетной; это не только не изменяет основные характеристики продукта, но также может вызвать новые проблемы.
Если проект кросс-чейн токенов позволяет изменять используемую конфигурацию узлов, злоумышленник может заменить узлы на контролируемые им, что позволит подделывать любые сообщения. Эта угроза безопасности может привести к более серьезным последствиям в более сложных сценариях. В огромной системе, если хотя бы один элемент будет заменен, это может вызвать цепную реакцию. А некоторые кросс-чейн протоколы сами по себе не обладают способностью решать подобные проблемы, и если действительно произойдет инцидент с безопасностью, ответственность, скорее всего, будет возложена на внешние приложения.
Что касается проектов, которые заявляют, что они являются инфраструктурой, если они не могут предоставить совместимую безопасность, как Layer 1 или Layer 2, то такая позиция "инфраструктуры" заслуживает обсуждения. Настоящая инфраструктура "основная", потому что она может обеспечить единое обеспечение безопасности для всей экосистемы. Поэтому более точным определением для некоторых кросс-чейн протоколов может быть промежуточное ПО (Middleware), а не инфраструктура.
Некоторые команды безопасности указали на потенциальные уязвимости в некоторых кросс-чейн протоколах. Например, если злонамеренный деятель получит доступ к конфигурации протокола, он может изменить оракулы и реле на компоненты, которые он контролирует, обманув смарт-контракт и приведя к краже активов пользователей. Также исследования показали, что реле некоторых протоколов имеют критические уязвимости, хотя в настоящее время они защищены многофакторной подписью, их все равно могут использовать внутренние лица или члены команды с известной идентичностью.
При оценке кросс-чейн протоколов мы должны вернуться к истокам и обратиться к основным идеям, изложенным в белой книге Биткойна. Основная характеристика консенсуса Сатоши Накамото заключается в устранении доверенных третьих сторон, обеспечении недоверия (Trustless) и децентрализации (Децентрализация). Кросс-чейн коммуникационный протокол по своей сути должен быть, как Биткойн, пиринговой системой, позволяющей одной стороне напрямую отправлять информацию от Chain A к другой стороне Chain B без необходимости обращаться к каким-либо доверенным посредникам.
Обладающий Децентрализация и бездоверительными характеристиками "консенсус Сатоши" стал общей целью для всех разработчиков инфраструктуры в дальнейшем. Кросс-чейн Протоколы, не соответствующие этому консенсусу, вряд ли могут считаться настоящими Децентрализация кросс-чейн Протоколами, и не следует легко использовать такие высокие термины, как "Децентрализация" и "бездоверительный", чтобы описывать характеристики своего продукта.
Настоящий протокол кросс-чейн децентрализации должен уметь генерировать доказательства мошенничества или доказательства действительности на протяжении всего процесса кросс-чейн и загружать эти доказательства в блокчейн для проверки. Только так можно действительно достичь децентрализации и отсутствия доверия.
Для тех, кто утверждает, что использует инновационные технологии (такие как нулевые доказательства) для улучшения кросс-чейн протоколов, ключевым моментом является то, осознают ли они действительно свои существующие проблемы. Только признав проблемы, можно действительно продвигать технологический прогресс и строить более безопасную и более децентрализованную кросс-чейн экосистему.