Безопасные риски кросс-чейн протокола и важность децентрализации
В последние годы, с развитием технологий блокчейн, важность кросс-чейн протоколов становится все более очевидной. Однако за этими, на первый взгляд, простыми дизайнами протоколов скрываются многочисленные угрозы безопасности. Судя по данным за последние два года, убытки, вызванные кросс-чейн протоколами, занимают первое место среди различных событий безопасности блокчейна, их важность даже превышает важность решений по масштабированию эфириума.
Взаимодействие между кросс-чейн протоколами является основной потребностью экосистемы Web3. Несмотря на то, что такие проекты часто получают огромные инвестиции, и их общий объем заблокированных средств (TVL) и объем торгов продолжают расти, общество все еще недостаточно осведомлено о уровне их безопасности.
В качестве примера возьмем известный кросс-чейн Протокол, его архитектура использует Relayer для выполнения межцепочечных коммуникаций, а Oracle отвечает за надзор. Хотя этот дизайн упрощает традиционный процесс верификации кросс-чейн и предоставляет пользователям опыт "быстрого кросс-чейна", он также имеет очевидные риски безопасности.
Во-первых, упрощение многосетевой верификации до единой проверки Oracle значительно снижает уровень безопасности. Во-вторых, такой дизайн должен предполагать, что Relayer и Oracle полностью независимы, но это предположение о доверии трудно поддерживать в долгосрочной перспективе, оно не соответствует врожденным характеристикам криптовалюты и не может в корне предотвратить сговор между ними.
Некоторые могут считать, что открытие доступа к Relayer и разрешение большему числу участников управлять релеерами может решить вышеупомянутые проблемы. Однако этот подход лишь увеличивает количество доверенных субъектов с 1 до нескольких и не меняет суть характеристик продукта. Напротив, это может вызвать новые проблемы.
Если какой-либо проект кросс-чейн токенов, использующий данный протокол, позволяет изменять конфигурационные узлы, злоумышленник может заменить их на узлы, которые он контролирует, и, таким образом, подделать произвольные сообщения. Этот тип уязвимости может привести к более серьезным цепным реакциям в сложных сценариях.
Стоит отметить, что некоторые проекты, которые называют себя "инфраструктурными", на самом деле не могут обеспечить единый уровень безопасности для всех проектов в своей экосистеме. Точно говоря, такие проекты больше похожи на промежуточное ПО (Middleware), а не на настоящую инфраструктуру (Infrastructure).
Обратясь к белой книге Биткойна, мы можем увидеть, что основной принцип консенсуса Сатоши Накамото заключается в достижении бездоверительности (Trustless) и децентрализации (Decentralized). Это стало целью, к которой стремятся все разработчики инфраструктуры в дальнейшем. Кросс-чейн-протоколы, которые не соответствуют этому консенсусу, по своей сути являются псевдодецентрализованными.
Настоящий децентрализованный кросс-чейн протокол должен обеспечивать систему «точка-точка», не полагаясь на каких-либо доверенных третьих лиц. Однако некоторые протоколы в своем дизайне все же требуют от пользователей доверия к определенным ролям, которые могут сговориться для совершения злодеяний, а также доверия к разработчикам, создающим приложения с использованием этого протокола. Более того, на протяжении всего кросс-чейн процесса эти протоколы не генерируют никаких доказательств мошенничества или доказательств действительности, не говоря уже о том, чтобы записывать эти доказательства в блокчейн и проверять их.
В ответ на сомнения по поводу безопасности некоторые проекты часто принимают отрицательную позицию. Однако история учит нас, что только действительно реализованные системы с децентрализацией, имеющие сильные противоударные способности и внутреннюю ценность, могут существовать долго. Для кросс-чейн протоколов, независимо от размера финансирования или количества пользователей, если не удастся достичь настоящей децентрализованной безопасности, они в конечном итоге могут потерпеть неудачу из-за недостаточной устойчивости к атакам.
Создание действительно децентрализованного кросс-чейн протокола по-прежнему является огромным вызовом, требующим постоянных исследований и инноваций со стороны отрасли. Только следуя основной идее Сатоши Накамото, можно разработать действительно безопасные и надежные кросс-чейн решения.
На этой странице может содержаться сторонний контент, который предоставляется исключительно в информационных целях (не в качестве заявлений/гарантий) и не должен рассматриваться как поддержка взглядов компании Gate или как финансовый или профессиональный совет. Подробности смотрите в разделе «Отказ от ответственности» .
17 Лайков
Награда
17
6
Репост
Поделиться
комментарий
0/400
AirdropHunter9000
· 08-13 02:52
Не плачь, когда всё потеряно.
Посмотреть ОригиналОтветить0
ContractFreelancer
· 08-12 20:51
кросс-чейн到底靠不靠谱
Посмотреть ОригиналОтветить0
FrogInTheWell
· 08-10 13:21
Ладно, деньги уже потеряны, смотреть на это тревожно.
Посмотреть ОригиналОтветить0
TxFailed
· 08-10 13:19
psa: эти мостовые эксплойты становятся дорогими... узнал это на собственном опыте, честно говоря
Глубокий анализ угроз безопасности кросс-чейн протоколов: важность и вызовы децентрализации
Безопасные риски кросс-чейн протокола и важность децентрализации
В последние годы, с развитием технологий блокчейн, важность кросс-чейн протоколов становится все более очевидной. Однако за этими, на первый взгляд, простыми дизайнами протоколов скрываются многочисленные угрозы безопасности. Судя по данным за последние два года, убытки, вызванные кросс-чейн протоколами, занимают первое место среди различных событий безопасности блокчейна, их важность даже превышает важность решений по масштабированию эфириума.
Взаимодействие между кросс-чейн протоколами является основной потребностью экосистемы Web3. Несмотря на то, что такие проекты часто получают огромные инвестиции, и их общий объем заблокированных средств (TVL) и объем торгов продолжают расти, общество все еще недостаточно осведомлено о уровне их безопасности.
В качестве примера возьмем известный кросс-чейн Протокол, его архитектура использует Relayer для выполнения межцепочечных коммуникаций, а Oracle отвечает за надзор. Хотя этот дизайн упрощает традиционный процесс верификации кросс-чейн и предоставляет пользователям опыт "быстрого кросс-чейна", он также имеет очевидные риски безопасности.
Во-первых, упрощение многосетевой верификации до единой проверки Oracle значительно снижает уровень безопасности. Во-вторых, такой дизайн должен предполагать, что Relayer и Oracle полностью независимы, но это предположение о доверии трудно поддерживать в долгосрочной перспективе, оно не соответствует врожденным характеристикам криптовалюты и не может в корне предотвратить сговор между ними.
Некоторые могут считать, что открытие доступа к Relayer и разрешение большему числу участников управлять релеерами может решить вышеупомянутые проблемы. Однако этот подход лишь увеличивает количество доверенных субъектов с 1 до нескольких и не меняет суть характеристик продукта. Напротив, это может вызвать новые проблемы.
Если какой-либо проект кросс-чейн токенов, использующий данный протокол, позволяет изменять конфигурационные узлы, злоумышленник может заменить их на узлы, которые он контролирует, и, таким образом, подделать произвольные сообщения. Этот тип уязвимости может привести к более серьезным цепным реакциям в сложных сценариях.
Стоит отметить, что некоторые проекты, которые называют себя "инфраструктурными", на самом деле не могут обеспечить единый уровень безопасности для всех проектов в своей экосистеме. Точно говоря, такие проекты больше похожи на промежуточное ПО (Middleware), а не на настоящую инфраструктуру (Infrastructure).
Обратясь к белой книге Биткойна, мы можем увидеть, что основной принцип консенсуса Сатоши Накамото заключается в достижении бездоверительности (Trustless) и децентрализации (Decentralized). Это стало целью, к которой стремятся все разработчики инфраструктуры в дальнейшем. Кросс-чейн-протоколы, которые не соответствуют этому консенсусу, по своей сути являются псевдодецентрализованными.
Настоящий децентрализованный кросс-чейн протокол должен обеспечивать систему «точка-точка», не полагаясь на каких-либо доверенных третьих лиц. Однако некоторые протоколы в своем дизайне все же требуют от пользователей доверия к определенным ролям, которые могут сговориться для совершения злодеяний, а также доверия к разработчикам, создающим приложения с использованием этого протокола. Более того, на протяжении всего кросс-чейн процесса эти протоколы не генерируют никаких доказательств мошенничества или доказательств действительности, не говоря уже о том, чтобы записывать эти доказательства в блокчейн и проверять их.
В ответ на сомнения по поводу безопасности некоторые проекты часто принимают отрицательную позицию. Однако история учит нас, что только действительно реализованные системы с децентрализацией, имеющие сильные противоударные способности и внутреннюю ценность, могут существовать долго. Для кросс-чейн протоколов, независимо от размера финансирования или количества пользователей, если не удастся достичь настоящей децентрализованной безопасности, они в конечном итоге могут потерпеть неудачу из-за недостаточной устойчивости к атакам.
Создание действительно децентрализованного кросс-чейн протокола по-прежнему является огромным вызовом, требующим постоянных исследований и инноваций со стороны отрасли. Только следуя основной идее Сатоши Накамото, можно разработать действительно безопасные и надежные кросс-чейн решения.