Проблемы безопасности кросс-чейн протоколов и важность истинной Децентрализации

В последние годы кросс-чейн протоколы играют все более важную роль в экосистеме блокчейн. Однако эти протоколы также сталкиваются с серьезными проблемами безопасности. Согласно данным за последние два года, убытки, вызванные инцидентами безопасности кросс-чейн протоколов, занимают первое место среди всех типов инцидентов безопасности блокчейн, и их важность и актуальность даже превосходят решения по масштабированию Ethereum.

Взаимодействие между кросс-чейн протоколами является внутренним требованием сетевого взаимодействия Web3. Такие протоколы обычно могут привлекать огромные инвестиции, их общая заблокированная стоимость (TVL) и объемы торгов продолжают расти. Однако общественность не имеет высокой степени различия в уровнях безопасности этих протоколов, что затрудняет точную оценку их рисков.

Давайте сначала проанализируем типичную архитектуру кросс-чейн связи. В этой архитектуре связь между Chain A и Chain B выполняется Relayer, в то время как Oracle отвечает за надзор за Relayer. Преимущество такого дизайна заключается в том, что он избегает сложности традиционных методов, требующих третьей цепи (обычно не развертывающей dApp) для завершения алгоритма консенсуса и многонодовой валидации, тем самым предоставляя пользователям опыт "быстрого кросс-чейн". Благодаря легковесной архитектуре, небольшому объему кода и возможности использования готовых решений Oracle (таких как Chainlink), такие проекты легко быстро выходят на рынок, но в то же время их легко имитировать, а технический барьер довольно низок.

Однако такая архитектура имеет по меньшей мере две основные проблемы:

1. Упрощение многосетевого подтверждения до единого верификатора Oracle значительно снизило коэффициент безопасности.
2. Упрощенная верификационная модель должна предполагать, что Relayer и Oracle независимы, но такая предпосылка доверия трудно поддерживается на постоянной основе, не соответствует крипто-родной идее и не может в корне предотвратить сговор обеих сторон.

Некоторые кросс-чейн решения используют эту "ультралегкую" модель. В качестве независимого типа безопасности легкие кросс-чейн решения отвечают только за передачу сообщений и не несут ответственности за безопасность приложений, а также не обладают возможностью нести такую ответственность.

Некоторые могут задаться вопросом, сможет ли открытие Relayer, позволяющее большему числу участников управлять ретрансляторами, решить вышеуказанные проблемы? Однако простое увеличение числа операторов не равно децентрализации. Децентрализация не только означает увеличение числа участников или открытость доступа, это всего лишь изменения на рынке, которые не имеют большого значения для безопасности самого продукта. В некоторых решениях Relayer по сути является просто посредником, ответственным за пересылку информации, аналогично Oracle, оба относятся к доверенным третьим сторонам. Попытка повысить безопасность кросс-чейн, увеличивая количество доверенных субъектов, бесполезна, это не только не изменит основные характеристики продукта, но и может привести к новым проблемам.

Если кросс-чейн проект позволяет изменять конфигурацию своих узлов, злоумышленник может заменить их на узлы, контролируемые им, что приведет к подделке любых сообщений. В этом случае проекты, использующие данный протокол, могут столкнуться с огромными рисками безопасности, особенно в сложных сценариях. В огромной системе, как только какой-либо элемент будет заменен, это может вызвать цепную реакцию. Некоторые кросс-чейн протоколы сами по себе могут не решить эту проблему, и в случае возникновения инцидента безопасности они могут переложить ответственность на внешние приложения.

Если проект, который называет себя "инфраструктурой", не может предоставить безопасность, как Layer 1 или Layer 2, то его нельзя по-настоящему назвать инфраструктурой. Инфраструктура называется "базовой", потому что она обеспечивает согласованную безопасность для всей экосистемы. Поэтому некоторые кросс-чейн протоколы могут быть точнее описаны как промежуточное ПО (Middleware), а не как инфраструктура (Infrastructure).

Некоторые команды безопасности указали на потенциальные риски определенных кросс-чейн протоколов. Например, исследования показывают, что если владелец приложения (или человек, обладающий приватным ключом) получит доступ к конфигурации протокола, он может изменить оракулы и реле на компоненты, находящиеся под его контролем, тем самым манипулируя кросс-чейн транзакциями. Кроме того, у некоторых реле протоколов могут быть ключевые уязвимости, хотя в настоящее время они могут быть защищены многофакторной подписью, все же существует риск их эксплуатации внутренними сотрудниками или членами команды с известной личностью.

При оценке кросс-чейн протоколов мы должны вернуться к истокам технологии блокчейн. Основная идея, изложенная в белой книге Биткойна «Биткойн: система электронных денег с пиринговой сетью», а именно децентрализация и отсутствие необходимости в доверии, стала целевой целью для всех последующих разработчиков инфраструктуры. Кросс-чейн протоколы, которые не соответствуют этим характеристикам, возможно, трудно назвать настоящими децентрализованными кросс-чейн протоколами.

Настоящий децентрализованный кросс-чейн протокол должен обеспечивать прямую точка-точка связь без необходимости полагаться на каких-либо доверенных третьих лиц. Он должен обладать устойчивостью к атакам и быть в состоянии генерировать проверяемые доказательства мошенничества или доказательства действительности. Эти доказательства должны быть способны быть записаны в блокчейн и проверены в цепочке для обеспечения безопасности и надежности системы.

Создание действительно децентрализованного кросс-чейн протокола является сложной задачей. Некоторые инновационные подходы, такие как использование технологий нулевых знаний, могут предложить новые идеи для решения этих проблем. Однако ключевым моментом является то, что команда разработчиков протокола должна признать существующие проблемы безопасности и активно искать пути улучшения, а не просто отрицать наличие проблем.

В условиях постоянного развития технологий блокчейн нам необходимо более осторожно и ответственно оценивать и проектировать кросс-чейн протоколы. Только достигнув настоящей децентрализации и бездоверительных характеристик, мы сможем создать безопасную, надежную и обладающую долгосрочной ценностью кросс-чейн инфраструктуру, способствующую здоровому развитию всей экосистемы блокчейн.