La importancia de la seguridad del protocolo cross-chain y las deficiencias de LayerZero
Los problemas de seguridad de los protocolos cross-chain han recibido mucha atención en los últimos años. En términos de las pérdidas causadas por eventos de seguridad en varias blockchains en los últimos dos años, las pérdidas relacionadas con eventos de seguridad de protocolos cross-chain ocupan el primer lugar. La importancia y urgencia de resolver los problemas de seguridad de los protocolos cross-chain incluso supera las soluciones de escalabilidad de Ethereum. La interoperabilidad entre los protocolos cross-chain es un requisito inherente para la conexión de la ecosistema Web3. Este tipo de protocolos a menudo recibe una enorme financiación, su valor total de valor bloqueado (TVL) y el número de transacciones también están creciendo cada vez más impulsados por la demanda rígida. Sin embargo, debido a que el público no tiene un alto grado de reconocimiento de estos protocolos, es difícil evaluar con precisión su nivel de seguridad.
Veamos primero una arquitectura de diseño de producto típica de cross-chain. En el proceso de comunicación entre Chain A y Chain B, un Relayer ejecuta operaciones específicas, mientras que un Oracle supervisa al Relayer. La ventaja de esta arquitectura es que evita el complejo proceso de un algoritmo de consenso y la validación de múltiples nodos que requeriría una tercera cadena (que generalmente no despliega dApps) en el enfoque tradicional, por lo que puede ofrecer a los usuarios finales una experiencia de "cross-chain rápida". Debido a que la arquitectura es ligera, con poco código, y se puede utilizar directamente Chainlink como Oracle, este tipo de proyectos puede lanzarse rápidamente, pero también es fácil de imitar, con una barrera técnica casi nula.
Sin embargo, esta arquitectura presenta al menos dos problemas:
Simplificar el proceso de validación de decenas de nodos a una única validación de Oracle ha reducido drásticamente el coeficiente de seguridad.
Tras simplificarse a una única validación, se debe suponer que el Relayer y el Oracle son independientes entre sí. Esta suposición de confianza es difícil de mantener de manera permanente, no se ajusta a la filosofía nativa de las criptomonedas y no puede garantizar fundamentalmente que ambos no conspiren para hacer el mal.
Algunos protocolos de cross-chain adoptan este modelo básico. Como una solución de cross-chain "ultra ligera" de tipo de seguridad independiente, solo se encargan de transmitir mensajes y no son responsables de la seguridad de la aplicación, ni tienen la capacidad de asumir dicha responsabilidad.
Incluso permitir que múltiples partes operen como intermediarios no resolverá por completo los problemas mencionados anteriormente. En primer lugar, la descentralización no significa simplemente que el número de operadores aumente o que cualquiera pueda conectarse. La demanda siempre ha sido sin permiso, y hacer que la oferta también sea sin permiso no es un cambio revolucionario, solo es un cambio en el lado del mercado, que no tiene mucho que ver con la seguridad del producto en sí. Los Relayers de ciertos protocolos son esencialmente intermediarios que solo se encargan de retransmitir información, y al igual que los Oráculos, son considerados terceros de confianza. Intentar aumentar la seguridad cross-chain al aumentar el número de entidades de confianza de 1 a 30 es en vano, no solo no cambia las características del producto, sino que también puede generar nuevos problemas.
Si un proyecto de token cross-chain permite modificar los nodos de configuración, entonces es posible que un atacante los reemplace por sus propios nodos, lo que a su vez podría falsificar cualquier mensaje. En términos de resultados, los proyectos que utilizan este protocolo aún pueden enfrentar enormes riesgos de seguridad, y este problema se agrava en escenarios más complejos. En un sistema grande, tan solo un eslabón reemplazado puede desencadenar una reacción en cadena. Algunos protocolos cross-chain no tienen la capacidad de resolver este problema, y si realmente ocurre un incidente de seguridad, es muy probable que desplacen la responsabilidad a aplicaciones externas.
Si un protocolo no puede compartir la seguridad como lo hacen Layer1 o Layer2, entonces no puede ser considerado infraestructura. La infraestructura es "básica" porque puede compartir la seguridad. Si un proyecto se autodenomina infraestructura, debería proporcionar seguridad consistente a todos sus proyectos ecológicos, es decir, todos los proyectos ecológicos comparten la seguridad de esa infraestructura. Por lo tanto, para ser precisos, ciertos protocolos cross-chain no son infraestructura, sino middleware. Los desarrolladores de aplicaciones que acceden a este middleware SDK/API pueden definir libremente sus políticas de seguridad.
Algunos equipos de investigación han señalado que asumir que los propietarios de aplicaciones (o las personas que tienen la clave privada) no actuarán de manera malintencionada es incorrecto. Si un actor malicioso obtiene acceso a la configuración del protocolo cross-chain, podría cambiar los oráculos y los retransmisores de los componentes predeterminados a componentes controlados por ellos, manipulando así los contratos inteligentes que utilizan este mecanismo, lo que lleva al robo de activos de los usuarios.
Además, hay investigaciones que indican que ciertos protocolos de cross-chain tienen vulnerabilidades críticas en sus retransmisores. Aunque actualmente están en estado de firma múltiple, estas vulnerabilidades solo pueden ser explotadas por personal interno o miembros del equipo con identidad conocida, pero aún existe un riesgo potencial. Estas vulnerabilidades podrían permitir el envío de mensajes fraudulentos desde la firma múltiple, o modificar mensajes después de que un oráculo y la firma múltiple firmen mensajes o transacciones, lo que podría resultar en el robo de los fondos de todos los usuarios.
Al rastrear el origen de Bitcoin, podemos ver la idea central propuesta por Satoshi Nakamoto en el libro blanco: un sistema de moneda electrónica completamente peer-to-peer que permite pagos en línea enviados directamente de una parte a otra, sin necesidad de pasar por instituciones financieras. Esta idea enfatiza las características de descentralización y confianza, que se convierten en el objetivo común de todos los desarrolladores de infraestructura posteriores.
Sin embargo, ciertos protocolos cross-chain requieren en su funcionamiento práctico que los roles de Relayer y Oracle no coludan para hacer el mal, al mismo tiempo que exigen que los desarrolladores que construyen aplicaciones utilizando dicho protocolo sean considerados terceros de confianza. Todos los sujetos de confianza que participan en la "multi-firma" son roles privilegiados previamente asignados. Más importante aún, durante todo el proceso cross-chain no se genera ninguna prueba de fraude o prueba de validez, y mucho menos se suben estas pruebas a la cadena y se validan en la cadena. Por lo tanto, estos protocolos en realidad no cumplen con el "consenso de Nakamoto" y no pueden ser considerados como sistemas verdaderamente descentralizados y sin necesidad de confianza.
Al enfrentar problemas de seguridad, la actitud de respuesta de algunos protocolos cross-chain suele ser "negar" y luego "negar" de nuevo. Sin embargo, la historia nos dice que antes de Bitcoin hubo muchos intentos de monedas electrónicas, pero todos fracasaron porque no lograron alcanzar los objetivos de descentralización, resistencia a ataques y valor intrínseco. Lo mismo ocurre con los protocolos cross-chain; sin importar cuán grande sea la escala de financiamiento, cuántos usuarios atraiga o cuán puro sea su "linaje", siempre que el producto no pueda lograr una verdadera seguridad descentralizada, es muy probable que fracase debido a una falta de capacidad de resistencia a ataques.
Construir un protocolo cross-chain verdaderamente descentralizado es un desafío complejo. Algunas soluciones emergentes, como el uso de tecnología de pruebas de conocimiento cero para mejorar los protocolos cross-chain, podrían traer nuevos avances a este campo. Sin embargo, la clave radica en si los desarrolladores del protocolo reconocen los problemas existentes y están dispuestos a tomar las medidas necesarias para mejorar.
Esta página puede contener contenido de terceros, que se proporciona únicamente con fines informativos (sin garantías ni declaraciones) y no debe considerarse como un respaldo por parte de Gate a las opiniones expresadas ni como asesoramiento financiero o profesional. Consulte el Descargo de responsabilidad para obtener más detalles.
21 me gusta
Recompensa
21
5
Compartir
Comentar
0/400
AirdropHunterWang
· 07-11 08:10
El mayor enemigo del cross-chain no son los Hacker, sino el relayer que hace un Rug Pull.
Ver originalesResponder0
MysteriousZhang
· 07-08 09:19
Ah, esto... en realidad es que los intermediarios tienen riesgos, ¿verdad?
Ver originalesResponder0
StableNomad
· 07-08 09:04
sufriendo en puentes desde 2021... misma historia, diferente protocolo, la verdad
Ver originalesResponder0
GasFeeAssassin
· 07-08 09:04
El cross-chain se ha vuelto totalmente ineficaz, ¡puntuación de seguridad negativa!
Ver originalesResponder0
MemeKingNFT
· 07-08 08:59
Ay, ya lo he visto todo, incluso proyectos líderes como LayerZero están llenos de trampas, no es de extrañar que no comprara la caída en su momento.
Análisis de las vulnerabilidades de seguridad del protocolo cross-chain LayerZero y direcciones de mejora
La importancia de la seguridad del protocolo cross-chain y las deficiencias de LayerZero
Los problemas de seguridad de los protocolos cross-chain han recibido mucha atención en los últimos años. En términos de las pérdidas causadas por eventos de seguridad en varias blockchains en los últimos dos años, las pérdidas relacionadas con eventos de seguridad de protocolos cross-chain ocupan el primer lugar. La importancia y urgencia de resolver los problemas de seguridad de los protocolos cross-chain incluso supera las soluciones de escalabilidad de Ethereum. La interoperabilidad entre los protocolos cross-chain es un requisito inherente para la conexión de la ecosistema Web3. Este tipo de protocolos a menudo recibe una enorme financiación, su valor total de valor bloqueado (TVL) y el número de transacciones también están creciendo cada vez más impulsados por la demanda rígida. Sin embargo, debido a que el público no tiene un alto grado de reconocimiento de estos protocolos, es difícil evaluar con precisión su nivel de seguridad.
Veamos primero una arquitectura de diseño de producto típica de cross-chain. En el proceso de comunicación entre Chain A y Chain B, un Relayer ejecuta operaciones específicas, mientras que un Oracle supervisa al Relayer. La ventaja de esta arquitectura es que evita el complejo proceso de un algoritmo de consenso y la validación de múltiples nodos que requeriría una tercera cadena (que generalmente no despliega dApps) en el enfoque tradicional, por lo que puede ofrecer a los usuarios finales una experiencia de "cross-chain rápida". Debido a que la arquitectura es ligera, con poco código, y se puede utilizar directamente Chainlink como Oracle, este tipo de proyectos puede lanzarse rápidamente, pero también es fácil de imitar, con una barrera técnica casi nula.
Sin embargo, esta arquitectura presenta al menos dos problemas:
Simplificar el proceso de validación de decenas de nodos a una única validación de Oracle ha reducido drásticamente el coeficiente de seguridad.
Tras simplificarse a una única validación, se debe suponer que el Relayer y el Oracle son independientes entre sí. Esta suposición de confianza es difícil de mantener de manera permanente, no se ajusta a la filosofía nativa de las criptomonedas y no puede garantizar fundamentalmente que ambos no conspiren para hacer el mal.
Algunos protocolos de cross-chain adoptan este modelo básico. Como una solución de cross-chain "ultra ligera" de tipo de seguridad independiente, solo se encargan de transmitir mensajes y no son responsables de la seguridad de la aplicación, ni tienen la capacidad de asumir dicha responsabilidad.
Incluso permitir que múltiples partes operen como intermediarios no resolverá por completo los problemas mencionados anteriormente. En primer lugar, la descentralización no significa simplemente que el número de operadores aumente o que cualquiera pueda conectarse. La demanda siempre ha sido sin permiso, y hacer que la oferta también sea sin permiso no es un cambio revolucionario, solo es un cambio en el lado del mercado, que no tiene mucho que ver con la seguridad del producto en sí. Los Relayers de ciertos protocolos son esencialmente intermediarios que solo se encargan de retransmitir información, y al igual que los Oráculos, son considerados terceros de confianza. Intentar aumentar la seguridad cross-chain al aumentar el número de entidades de confianza de 1 a 30 es en vano, no solo no cambia las características del producto, sino que también puede generar nuevos problemas.
Si un proyecto de token cross-chain permite modificar los nodos de configuración, entonces es posible que un atacante los reemplace por sus propios nodos, lo que a su vez podría falsificar cualquier mensaje. En términos de resultados, los proyectos que utilizan este protocolo aún pueden enfrentar enormes riesgos de seguridad, y este problema se agrava en escenarios más complejos. En un sistema grande, tan solo un eslabón reemplazado puede desencadenar una reacción en cadena. Algunos protocolos cross-chain no tienen la capacidad de resolver este problema, y si realmente ocurre un incidente de seguridad, es muy probable que desplacen la responsabilidad a aplicaciones externas.
Si un protocolo no puede compartir la seguridad como lo hacen Layer1 o Layer2, entonces no puede ser considerado infraestructura. La infraestructura es "básica" porque puede compartir la seguridad. Si un proyecto se autodenomina infraestructura, debería proporcionar seguridad consistente a todos sus proyectos ecológicos, es decir, todos los proyectos ecológicos comparten la seguridad de esa infraestructura. Por lo tanto, para ser precisos, ciertos protocolos cross-chain no son infraestructura, sino middleware. Los desarrolladores de aplicaciones que acceden a este middleware SDK/API pueden definir libremente sus políticas de seguridad.
Algunos equipos de investigación han señalado que asumir que los propietarios de aplicaciones (o las personas que tienen la clave privada) no actuarán de manera malintencionada es incorrecto. Si un actor malicioso obtiene acceso a la configuración del protocolo cross-chain, podría cambiar los oráculos y los retransmisores de los componentes predeterminados a componentes controlados por ellos, manipulando así los contratos inteligentes que utilizan este mecanismo, lo que lleva al robo de activos de los usuarios.
Además, hay investigaciones que indican que ciertos protocolos de cross-chain tienen vulnerabilidades críticas en sus retransmisores. Aunque actualmente están en estado de firma múltiple, estas vulnerabilidades solo pueden ser explotadas por personal interno o miembros del equipo con identidad conocida, pero aún existe un riesgo potencial. Estas vulnerabilidades podrían permitir el envío de mensajes fraudulentos desde la firma múltiple, o modificar mensajes después de que un oráculo y la firma múltiple firmen mensajes o transacciones, lo que podría resultar en el robo de los fondos de todos los usuarios.
Al rastrear el origen de Bitcoin, podemos ver la idea central propuesta por Satoshi Nakamoto en el libro blanco: un sistema de moneda electrónica completamente peer-to-peer que permite pagos en línea enviados directamente de una parte a otra, sin necesidad de pasar por instituciones financieras. Esta idea enfatiza las características de descentralización y confianza, que se convierten en el objetivo común de todos los desarrolladores de infraestructura posteriores.
Sin embargo, ciertos protocolos cross-chain requieren en su funcionamiento práctico que los roles de Relayer y Oracle no coludan para hacer el mal, al mismo tiempo que exigen que los desarrolladores que construyen aplicaciones utilizando dicho protocolo sean considerados terceros de confianza. Todos los sujetos de confianza que participan en la "multi-firma" son roles privilegiados previamente asignados. Más importante aún, durante todo el proceso cross-chain no se genera ninguna prueba de fraude o prueba de validez, y mucho menos se suben estas pruebas a la cadena y se validan en la cadena. Por lo tanto, estos protocolos en realidad no cumplen con el "consenso de Nakamoto" y no pueden ser considerados como sistemas verdaderamente descentralizados y sin necesidad de confianza.
Al enfrentar problemas de seguridad, la actitud de respuesta de algunos protocolos cross-chain suele ser "negar" y luego "negar" de nuevo. Sin embargo, la historia nos dice que antes de Bitcoin hubo muchos intentos de monedas electrónicas, pero todos fracasaron porque no lograron alcanzar los objetivos de descentralización, resistencia a ataques y valor intrínseco. Lo mismo ocurre con los protocolos cross-chain; sin importar cuán grande sea la escala de financiamiento, cuántos usuarios atraiga o cuán puro sea su "linaje", siempre que el producto no pueda lograr una verdadera seguridad descentralizada, es muy probable que fracase debido a una falta de capacidad de resistencia a ataques.
Construir un protocolo cross-chain verdaderamente descentralizado es un desafío complejo. Algunas soluciones emergentes, como el uso de tecnología de pruebas de conocimiento cero para mejorar los protocolos cross-chain, podrían traer nuevos avances a este campo. Sin embargo, la clave radica en si los desarrolladores del protocolo reconocen los problemas existentes y están dispuestos a tomar las medidas necesarias para mejorar.