Discusión sobre la seguridad y la Descentralización de los protocolos cross-chain
Los problemas de seguridad de los protocolos cross-chain han recibido una atención considerable en los últimos años. A partir 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 la urgencia de resolver los problemas de seguridad de los protocolos cross-chain incluso superan las soluciones de escalado de Ethereum. La interoperabilidad entre los protocolos cross-chain es una necesidad intrínseca para la conectividad de Web3. Este tipo de protocolos generalmente tienen un gran tamaño de financiamiento, con un valor total bloqueado de (TVL) y un volumen de transacciones que sigue creciendo bajo la presión de la demanda rígida. Sin embargo, debido a la baja conciencia pública sobre estos protocolos cross-chain, es difícil evaluar con precisión su nivel de seguridad.
Veamos primero una arquitectura típica de diseño de productos cross-chain. En el proceso de comunicación entre Chain A y Chain B, el Relayer ejecuta operaciones concretas, mientras que el Oracle se encarga de supervisar al Relayer. Una ventaja de esta arquitectura es que evita la necesidad de una tercera cadena (que generalmente no despliega dApps) para completar el algoritmo de consenso y el proceso de validación de decenas de nodos, lo que puede proporcionar a los usuarios finales una experiencia de "rápido cross-chain". Debido a que la arquitectura es ligera, tiene poco código y el Oracle puede usar servicios existentes como Chainlink, este tipo de proyectos puede lanzarse rápidamente, pero también son fácilmente imitables y tienen una barrera técnica baja.
Sin embargo, esta arquitectura presenta al menos dos problemas:
Simplificar el proceso de verificación de decenas de nodos en una única verificación de Oracle, reduciendo significativamente el coeficiente de seguridad.
Al simplificarse a una única verificación, se debe asumir que el Relayer y el Oracle son independientes entre sí. Sin embargo, esta suposición de confianza no puede mantenerse para siempre, ya que carece de suficientes características de Descentralización, lo que no garantiza fundamentalmente que ambos no conspiren para hacer el mal.
Alguien podría preguntar, si se abre el Relayer y se permite que más participantes ejecuten intermediarios, ¿podría esto resolver los problemas mencionados anteriormente? En realidad, simplemente aumentar la cantidad de operadores no equivale a Descentralización. Permitir que cualquiera acceda al sistema solo logra un entorno sin permisos (Permissionless), lo cual es un cambio en el lado del mercado que no está muy relacionado con la seguridad del producto en sí. El Relayer es esencialmente un intermediario responsable de retransmitir información, al igual que un Oracle, ambos son considerados terceros de confianza. Intentar mejorar la seguridad cross-chain aumentando la cantidad de entidades de confianza es en vano, ya que no solo no cambia las características esenciales del producto, sino que también puede dar lugar a nuevos problemas.
Si un proyecto de token cross-chain permite modificar la configuración de nodos que utiliza, un atacante podría reemplazarlos por nodos que controla, falsificando así cualquier mensaje. Este riesgo de seguridad podría tener consecuencias más graves en escenarios más complejos. En un sistema grande, tan pronto como se reemplaza un eslabón, podría desencadenar una reacción en cadena. Y ciertos protocolos cross-chain no tienen la capacidad de resolver este tipo de problemas, si realmente ocurre un incidente de seguridad, la responsabilidad probablemente será trasladada a aplicaciones externas.
Para los proyectos que afirman ser infraestructura, si no pueden proporcionar seguridad compartida como Layer 1 o Layer 2, entonces esta posición de "infraestructura" es discutible. La verdadera infraestructura es "básica" porque puede ofrecer una garantía de seguridad consistente para todo el ecosistema. Por lo tanto, la ubicación más precisa de ciertos protocolos cross-chain podría ser middleware, en lugar de infraestructura.
Algunos equipos de seguridad han señalado que ciertos protocolos de cross-chain presentan vulnerabilidades potenciales. Por ejemplo, si un actor malicioso obtiene acceso a la configuración del protocolo, podría cambiar los oráculos y los retransmisores por componentes que controle, engañando así al contrato inteligente y provocando el robo de activos de los usuarios. También se ha descubierto que algunos retransmisores de ciertos protocolos tienen vulnerabilidades críticas, aunque actualmente están protegidos por múltiples firmas, aún podrían ser explotados por personal interno o miembros del equipo con identidad conocida.
Al evaluar el protocolo cross-chain, debemos regresar a la esencia y referirnos a los principios fundamentales propuestos en el libro blanco de Bitcoin. La característica central del consenso de Satoshi Nakamoto es eliminar a los terceros de confianza, logrando la Descentralización y la confianza (Trustless). El protocolo de comunicación cross-chain debería ser, en esencia, como Bitcoin, un sistema punto a punto que permite a una parte enviar directamente desde la Cadena A a la otra parte de la Cadena B, sin necesidad de pasar por ningún intermediario de confianza.
La "consenso de Satoshi" que posee características de Descentralización y confianza ha llegado a ser el objetivo común de todos los desarrolladores de infraestructura posteriores. Es difícil calificar a un protocolo cross-chain que no cumpla con este consenso como un verdadero protocolo cross-chain Descentralizado, y no debería utilizarse fácilmente términos avanzados como "Descentralización" o "confianza" para describir las características de su producto.
Un verdadero protocolo de descentralización cross-chain debería ser capaz de generar pruebas de fraude o pruebas de validez durante todo el proceso cross-chain y verificar estas pruebas en la cadena. Solo así se puede lograr una verdadera descentralización y desconfianza.
Para aquellos que afirman utilizar tecnologías innovadoras (como las pruebas de cero conocimiento) para actualizar los protocolos cross-chain, la clave radica en si realmente reconocen los problemas que enfrentan. Solo al enfrentar los problemas se puede impulsar verdaderamente el progreso tecnológico y construir un ecosistema cross-chain más seguro y más descentralizado.
Ver originales
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.
12 me gusta
Recompensa
12
3
Compartir
Comentar
0/400
ForkThisDAO
· hace14h
Los fondos van a caer a cero
Ver originalesResponder0
MetaMaximalist
· hace18h
jajaja otro día otro hackeo de puente... ¿cuándo aprenderán estos plebeyos sobre la arquitectura de seguridad adecuada?
Ver originalesResponder0
FlatTax
· hace18h
¿Perder tanto de forma segura? Es una lección del pasado.
Reflexiones profundas sobre la seguridad de los protocolos cross-chain y la descentralización
Discusión sobre la seguridad y la Descentralización de los protocolos cross-chain
Los problemas de seguridad de los protocolos cross-chain han recibido una atención considerable en los últimos años. A partir 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 la urgencia de resolver los problemas de seguridad de los protocolos cross-chain incluso superan las soluciones de escalado de Ethereum. La interoperabilidad entre los protocolos cross-chain es una necesidad intrínseca para la conectividad de Web3. Este tipo de protocolos generalmente tienen un gran tamaño de financiamiento, con un valor total bloqueado de (TVL) y un volumen de transacciones que sigue creciendo bajo la presión de la demanda rígida. Sin embargo, debido a la baja conciencia pública sobre estos protocolos cross-chain, es difícil evaluar con precisión su nivel de seguridad.
Veamos primero una arquitectura típica de diseño de productos cross-chain. En el proceso de comunicación entre Chain A y Chain B, el Relayer ejecuta operaciones concretas, mientras que el Oracle se encarga de supervisar al Relayer. Una ventaja de esta arquitectura es que evita la necesidad de una tercera cadena (que generalmente no despliega dApps) para completar el algoritmo de consenso y el proceso de validación de decenas de nodos, lo que puede proporcionar a los usuarios finales una experiencia de "rápido cross-chain". Debido a que la arquitectura es ligera, tiene poco código y el Oracle puede usar servicios existentes como Chainlink, este tipo de proyectos puede lanzarse rápidamente, pero también son fácilmente imitables y tienen una barrera técnica baja.
Sin embargo, esta arquitectura presenta al menos dos problemas:
Simplificar el proceso de verificación de decenas de nodos en una única verificación de Oracle, reduciendo significativamente el coeficiente de seguridad.
Al simplificarse a una única verificación, se debe asumir que el Relayer y el Oracle son independientes entre sí. Sin embargo, esta suposición de confianza no puede mantenerse para siempre, ya que carece de suficientes características de Descentralización, lo que no garantiza fundamentalmente que ambos no conspiren para hacer el mal.
Alguien podría preguntar, si se abre el Relayer y se permite que más participantes ejecuten intermediarios, ¿podría esto resolver los problemas mencionados anteriormente? En realidad, simplemente aumentar la cantidad de operadores no equivale a Descentralización. Permitir que cualquiera acceda al sistema solo logra un entorno sin permisos (Permissionless), lo cual es un cambio en el lado del mercado que no está muy relacionado con la seguridad del producto en sí. El Relayer es esencialmente un intermediario responsable de retransmitir información, al igual que un Oracle, ambos son considerados terceros de confianza. Intentar mejorar la seguridad cross-chain aumentando la cantidad de entidades de confianza es en vano, ya que no solo no cambia las características esenciales del producto, sino que también puede dar lugar a nuevos problemas.
Si un proyecto de token cross-chain permite modificar la configuración de nodos que utiliza, un atacante podría reemplazarlos por nodos que controla, falsificando así cualquier mensaje. Este riesgo de seguridad podría tener consecuencias más graves en escenarios más complejos. En un sistema grande, tan pronto como se reemplaza un eslabón, podría desencadenar una reacción en cadena. Y ciertos protocolos cross-chain no tienen la capacidad de resolver este tipo de problemas, si realmente ocurre un incidente de seguridad, la responsabilidad probablemente será trasladada a aplicaciones externas.
Para los proyectos que afirman ser infraestructura, si no pueden proporcionar seguridad compartida como Layer 1 o Layer 2, entonces esta posición de "infraestructura" es discutible. La verdadera infraestructura es "básica" porque puede ofrecer una garantía de seguridad consistente para todo el ecosistema. Por lo tanto, la ubicación más precisa de ciertos protocolos cross-chain podría ser middleware, en lugar de infraestructura.
Algunos equipos de seguridad han señalado que ciertos protocolos de cross-chain presentan vulnerabilidades potenciales. Por ejemplo, si un actor malicioso obtiene acceso a la configuración del protocolo, podría cambiar los oráculos y los retransmisores por componentes que controle, engañando así al contrato inteligente y provocando el robo de activos de los usuarios. También se ha descubierto que algunos retransmisores de ciertos protocolos tienen vulnerabilidades críticas, aunque actualmente están protegidos por múltiples firmas, aún podrían ser explotados por personal interno o miembros del equipo con identidad conocida.
Al evaluar el protocolo cross-chain, debemos regresar a la esencia y referirnos a los principios fundamentales propuestos en el libro blanco de Bitcoin. La característica central del consenso de Satoshi Nakamoto es eliminar a los terceros de confianza, logrando la Descentralización y la confianza (Trustless). El protocolo de comunicación cross-chain debería ser, en esencia, como Bitcoin, un sistema punto a punto que permite a una parte enviar directamente desde la Cadena A a la otra parte de la Cadena B, sin necesidad de pasar por ningún intermediario de confianza.
La "consenso de Satoshi" que posee características de Descentralización y confianza ha llegado a ser el objetivo común de todos los desarrolladores de infraestructura posteriores. Es difícil calificar a un protocolo cross-chain que no cumpla con este consenso como un verdadero protocolo cross-chain Descentralizado, y no debería utilizarse fácilmente términos avanzados como "Descentralización" o "confianza" para describir las características de su producto.
Un verdadero protocolo de descentralización cross-chain debería ser capaz de generar pruebas de fraude o pruebas de validez durante todo el proceso cross-chain y verificar estas pruebas en la cadena. Solo así se puede lograr una verdadera descentralización y desconfianza.
Para aquellos que afirman utilizar tecnologías innovadoras (como las pruebas de cero conocimiento) para actualizar los protocolos cross-chain, la clave radica en si realmente reconocen los problemas que enfrentan. Solo al enfrentar los problemas se puede impulsar verdaderamente el progreso tecnológico y construir un ecosistema cross-chain más seguro y más descentralizado.