Escrito por: NIC Lin
Este artículo presentará qué son los puentes entre cadenas, los clasificará y comparará y analizará algunos ataques de puentes entre cadenas famosos.
¿Qué es un puente de cadenas cruzadas?
Un puente entre cadenas es un puente encargado de transmitir "mensajes" entre diferentes cadenas, en cuanto a qué tipo de mensajes es, lo presentaremos a continuación. Ejemplos de puentes entre cadenas incluyen Multichain, Celer, LayerZero, Nomad, Hop, etc.
Las cadenas desconocen la existencia de las demás.
La mayoría de los escenarios familiares de uso de puentes entre cadenas involucran activos entre cadenas como ETH y BTC. Pero, de hecho, los "activos" no pueden cruzar cadenas, porque cada cadena es independiente y no conocen la existencia ni el estado de las demás.
¿En cuanto a de dónde provienen el ETH en Solana o el BTC en ETH? Esas monedas se acuñan mediante puentes entre cadenas y, mientras estos puentes entre cadenas sean seguros, estas monedas acuñadas también lo serán.
Nota: Otros, como USDT o USDC, se acuñan mediante Tether y Circle en diferentes cadenas, mientras que el resto se acuñan mediante puentes entre cadenas.
¿Qué "mensaje" se envía?
Aunque en la superficie los activos están cruzando la cadena, detrás de escena, en realidad son solo "mensajes" que cruzan la cadena. Estos mensajes son como "Bloqueé/quemé activo".
Por ejemplo, cuando Alice quiere "transferir" USDT de la cadena A a la cadena B a través de un puente entre cadenas, lo que realmente sucede detrás de escena es:
El contrato del puente entre cadenas en la cadena A transfiere USDT de Alice y envía un mensaje: "Alice bloqueó 10 USDT conmigo".
El mensaje se lleva al contrato del puente entre cadenas en la cadena B, y el contrato transfiere 10 USDT desde sí mismo a la dirección de Alice en la cadena B.
La cadena cruzada de activos es en realidad una simple transferencia de mensajes, en la que se omiten muchos detalles.
La transmisión de "mensajes" es el núcleo de los puentes entre cadenas. Hoy en día, los activos entre cadenas más comunes son solo uno de los usos. Por ejemplo, la versión V3 de Aave es una plataforma de préstamos hipotecarios que se ejecuta en múltiples redes.
Limitaciones y desafíos
Pero el puente entre cadenas no es tan simple como el ejemplo anterior. Una de las limitaciones más fundamentales de los puentes entre cadenas proviene del hecho de que "las cadenas no saben que existen entre sí", por lo que es necesario " confiar en alguien para entregar el mensaje ". Por lo tanto, el principal desafío del puente entre cadenas es " cómo verificar la validez de un mensaje enviado ".
Nota: "Creer" en el mensajero aquí no significa confiar completamente en él. Los párrafos posteriores presentarán algunos puentes que no requieren confiar en el mensajero. El libertador puede ser una persona buena o mala, pero habrá otras suposiciones sobre los rasgos del libertador.
seguridad
Básicamente la seguridad de un puente entre cadenas depende de:
¿Cuánta confianza necesitas depositar en el mensajero? ¿Existen suposiciones sobre el comportamiento del remitente del mensaje? ¿Se supone que el mensajero sólo puede realizar su trabajo honestamente?
¿Cómo verificar la validez del mensaje?
A continuación, se introducirá la clasificación de los diferentes puentes de cadenas cruzadas.
Clasificación de puentes de cadenas cruzadas.
Los puentes de cadenas cruzadas se pueden dividir básicamente en cuatro tipos:
Retransmisores de confianza
Verificación optimista
Cliente ligero + Retransmisores sin confianza
HTML
(Si tiene otras ideas o comentarios sobre la clasificación, deje un mensaje o escriba una carta para discutirlo).
1. Retransmisores de confianza
Como sugiere el nombre, los Trusted Relayers son mensajeros de mensajes de confianza . Básicamente, después de confiar en el mensajero, no es necesario verificar la validez del mensaje. Siempre que el mensaje sea entregado por el mensajero de confianza, se cree que es válido. Naturalmente, cuando existen supuestos de confianza y centralización, la arquitectura será mucho más simple, el costo será muy bajo y la experiencia del usuario será excelente.
La tecnología de Trusted Relayers no tiene nada de especial o brillante, sólo depende de la composición de estos transmisores de mensajes, que pueden ser únicos o múltiples (como las multifirmas); detrás de cada transmisor de mensajes también puede haber multifirmas. o MPC.
Una cosa que hay que mencionar aquí es que el supuesto de seguridad de Trusted Relayers es Mayoría Honesta, es decir, más de la mitad de los remitentes de mensajes deben ser personas honestas y buenas. Si más de la mitad de los remitentes de mensajes son malos o han sido pirateados, el puente entre cadenas ya no es seguro.
Otra cosa a mencionar es que Layer Zero también pertenece a Trusted Relayers. Incluso si la función del transmisor de mensajes se divide en "Oracle" y "Relayer" en su definición, eso no cambia el hecho de que la seguridad de todo el puente no puede confiar. en estos dos roles Es una mala persona. Sin embargo, la ventaja de Layer Zero en comparación con otros puentes de Trusted Relayers es que cada dApp puede personalizar la seguridad que necesita. Si necesita mucha seguridad, puede establecer un número muy alto de "Oracles" y "Relayers". Otra ventaja es que la seguridad de cada dApp es independiente entre sí y no se afecta entre sí.
Ejemplos: Multichain, Celer, LayerZero, Wormhole, Ronin Bridge, XY
2. Verificación optimista
Al igual que Optimistic Rollup, Optimistic primero acepta el mensaje entregado de manera optimista, pero verificará la validez del mensaje e iniciará un desafío si se determina que no es válido . La ventaja es que el sistema funcionará normalmente la mayor parte del tiempo (porque los malhechores serán desafiados y castigados), y los mensajes son válidos por lo que no hay necesidad de iniciar un desafío, por lo que el costo es muy bajo porque no hay necesidad de verificar el mensaje en la cadena. La desventaja es que debe haber un período de desafío (ventana optimista) para permitir que la persona responsable de la verificación tenga tiempo suficiente para verificar e iniciar un desafío. A continuación, tomaremos Nomad como ejemplo para presentar la operación de Verificación Optimista.
Hay tres roles en Nomad: Actualizador, Retransmisor y Vigilante.
El actualizador promete una garantía y es responsable de garantizar la firma del mensaje, por ejemplo, "Juro por mi garantía que Alice solicita enviar el mensaje XXX de la cadena A a la cadena B".
Relayer es simplemente responsable de enviar el mensaje y la firma del Updater a la cadena de destino (Cadena B)
Watcher es responsable de supervisar a Updater y reaccionar cuando Updater hace el mal.
circunstancias normales
Alice activa el contrato de la cadena A y solicita enviar un mensaje a la cadena B
El actualizador firma el mensaje de Alice
Relayer es responsable de enviar el mensaje y la firma del Updater a la cadena B
Una vez finalizado el período de desafío (ventana optimista), el mensaje entrará en vigor y se completará la cadena cruzada de mensajes.
El actualizador hace el mal
El actualizador firma un mensaje inventado y pide a los socios de Relayer que lo envíen a la cadena B
Después de que Watcher lo descubre, primero va a la cadena B para invalidar el mensaje y luego envía la evidencia (firma del Actualizador) a la cadena A, confiscando la garantía del Actualizador.
El contrato de la cadena A puede verificar claramente si el mensaje firmado por el Actualizador existe, porque el mensaje realmente existirá solo si el usuario envía personalmente la solicitud al contrato. Por lo tanto, cuando un Actualizador firma un mensaje que no existe, esta firma se convertirá en evidencia indefendible para el malvado Actualizador y será utilizada para confiscar la garantía del Actualizador.
La evidencia solo es válida en la cadena fuente del mensaje (cadena A)
La cadena objetivo (cadena B) nunca sabrá quién en la cadena A quiere enviar qué mensaje, por lo que el contrato de la cadena B no tiene forma de saber si el mensaje garantizado por el Actualizador es verdadero.
¿Qué puede hacer la cadena B? La respuesta es que es necesario introducir el Vigilante Permiso. El Vigilante Permiso tiene el derecho de invalidar cualquier mensaje para evitar cualquier daño causado por mensajes falsificados. Pero, por el contrario, también puede invalidar un mensaje normal, por lo que este rol debe tener permiso y debe ser un rol confiable.
Si hay un Vigilante Autorizado jugando e invalidando maliciosamente los mensajes normales, entonces sólo puede confiar en otra capa de confianza, tal vez una Gobernanza o un Administrador de firmas múltiples para intervenir y eliminar al Vigilante malicioso.
Simplemente asuma que al menos un Vigilante está haciendo algo.
El supuesto de seguridad de Trusted Relayer es muy diferente: en comparación con Trusted Relayer, que debe asumir que hay más de la mitad de participantes honestos, Optimistic Verification solo necesita asumir que al menos un Watcher es una buena persona . Esto significa que para derrotar a la Verificación Optimista, debes derrotar (por ejemplo, piratear, sobornar, DoS) a todos los Vigilantes .
Período de desafío de 30 minutos.
A diferencia del período del desafío Optimistic Rollup, que dura hasta siete días, el período del desafío Optimistic Verification es de solo 30 minutos. Esto se debe a que el desafío de la Verificación Optimista no requiere una interacción de ida y vuelta entre el retador y el desafiado, sino que envía directamente una prueba única de vida o muerte: "¿Existe el mensaje firmado por el Actualizador? (Sí /No)".
3. Cliente ligero + Retransmisores sin confianza
Este método de puente entre cadenas permite que la cadena objetivo se convierta en un nodo ligero de la cadena fuente. Puede ejecutar un nodo ligero fuera de la cadena o puede simular un nodo ligero utilizando un contrato en la cadena: cada bloque de la cadena fuente se registra y verifica en el contrato el archivo de encabezado de cada bloque (Block Header). Además de verificar que el contenido del archivo de encabezado sea válido, también es necesario verificar el consenso, es decir, la verificación de PoW o el resultado de la votación de PoS. La verificación de PoW es relativamente simple, pero los resultados de la votación de PoS son mucho más complicados, especialmente con más de 400.000 validadores como Ethereum Beacon Chain. El costo de mantener estas listas en términos de contratos o recuento de votos es muy alto.
Además, el contenido del bloque y el mecanismo de consenso de cada cadena son diferentes, por lo que no es una tarea sencilla soportar una nueva cadena. Además, el costo de verificación será mucho mayor que otros puentes entre cadenas. puentes de cadena principales desventajas. Pero la ventaja es que es muy seguro: no necesita confiar en el retransmisor responsable de traer la información del bloque: verificará el bloqueo y el consenso por sí mismo.
El contrato de Light Client verifica la información del bloque y el consenso de la cadena A presentado por Relayer
Nota: Aunque el Relayer solo está haciendo recados, aún es necesario asumir que hay un Relayer honesto en línea para garantizar que se proporcione la información de bloque correcta para evitar cadenas bifurcadas falsas que socaven la seguridad.
Después de verificar el archivo de encabezado del bloque, lo que queda es verificar que (1) la transacción existe en un determinado bloque, o (2) se emite un evento en un determinado bloque, o (3) una determinada dirección de almacenamiento tiene algún valor. Ejemplo:
(1) Como verificar que Alice transfiera fondos a una determinada dirección en BTC o adjuntar un mensaje determinado a OP_RETURN
(2) Por ejemplo, verifique que el contrato Bridge en ETH haya emitido efectivamente el evento CrossChainMessageRequested (el recibo del evento existirá en el árbol de recibos y la raíz del árbol se registrará en el archivo de encabezado).
(3) Por ejemplo, verificar que efectivamente haya un dato en el almacenamiento del contrato Bridge en Optimism que registre la solicitud entre cadenas para el mensaje solicitado por Alice.
Luego, Alice usa el método (1)(2)(3) para demostrarle al contrato del Cliente ligero que ha iniciado una solicitud entre cadenas.
Una vez que la verificación es exitosa, se puede creer que efectivamente hay una solicitud de mensaje entre cadenas en la cadena de origen.
Ejemplos: Cosmos IBC, cerca del puente Rainbow
Nota: Cosmos IBC transmite mensajes entre diferentes (y limitadas a) cadenas de Cosmos mediante la ejecución de nodos ligeros en lugar de utilizar contratos. Near Rainbow Bridge solo puede transferir entre las cadenas Ethereum, Near y Aurora.
Además de la construcción compleja y los altos costos de verificación, este puente entre cadenas también tiene una desventaja: el tiempo de finalización de cada cadena es diferente. Por ejemplo, los datos provenientes de BTC pueden tener que esperar seis bloques (una hora), y los datos provenientes de BTC pueden tener que esperar seis bloques (una hora). desde ETH es posible que tenga que esperar seis bloques (una hora), que los datos tengan que esperar 12,8 minutos, etc., y la experiencia del usuario será mucho peor.
4.HTLC
HTLC significa Hashed TimeLock Contract (contrato de bloqueo de tiempo hash, lo siguiente asumirá que el lector sabe cómo funciona HTLC).
Nota: HTLC no necesariamente necesita usar Hash para el compromiso y puede usar firma en su lugar.
La ventaja de HTLC es que es muy seguro, pero la desventaja es que la experiencia del usuario es mucho peor que otros puentes entre cadenas, como por ejemplo:
Se necesitan más transacciones para completar la cadena cruzada
Los usuarios deben permanecer en línea hasta que se complete la cadena cruzada
Problema de libre opción, la persona que inicia HTLC es la parte pasiva y la contraparte puede optar por cooperar o no (lo que sea beneficioso para él). Sin embargo, si la contraparte es un comerciante de buena reputación (llamado enrutador), no necesita preocuparse tanto por este problema.
La calidad del servicio de diferentes enrutadores será diferente, lo que dará como resultado una experiencia de usuario inconsistente.
Ejemplos: Connext, Celer V1
Lo anterior es una introducción a los cuatro tipos de puentes de cadenas cruzadas, a continuación analizaremos los ataques que se han producido en cada tipo de puentes de cadenas cruzadas.
Análisis de eventos de ataque
1. Ataque de puente entre cadenas de Trusted Relayers
1) Multicadena, 2021.07, pérdida de ~8 millones
Este valor aleatorio generado aleatoriamente se reutiliza en su biblioteca de la suite MPC, lo que permite restaurar la clave privada. Enlaces relacionados:
https://medium.com/multichainorg/anyswap-multichain-router-v3-exploit-statement-6833f1b7e6fb
2) PolyNetwork, 2021.08, pérdida de ~600 millones
Las vulnerabilidades de los contratos inteligentes permiten a los atacantes obtener acceso a los activos del protocolo. Enlaces relacionados:
https://en.wikipedia.org/wiki/Poly_Network_exploit
https://certik.medium.com/polynetwork-hack-analysis-a86513f2a730
3) Multicadena, 2022.01, pérdida de ~3 millones
Las vulnerabilidades de los contratos inteligentes permiten a los atacantes transferir los tokens envueltos de la víctima (como WETH, WBNB, etc.) a voluntad. Enlaces relacionados:
https://medium.com/multichainorg/action-required-critical-vulnerability-for-six-tokens-6b3cbd22bfc0
https://halborn.com/explained-the-multichain-hack-january-2022/
4) Qubit, 2022.01, pérdida de ~80 millones
Las vulnerabilidades de los contratos inteligentes y la negligencia en el proceso de actualización del contrato permiten a los atacantes retirar directamente todos los activos del protocolo. Enlaces relacionados:
https://certik.medium.com/qubit-bridge-collapse-exploited-to-the-tune-of-80-million-a7ab9068e1a0
5) Agujero de gusano, 2022.02, pérdida de ~300 millones
Las vulnerabilidades de los contratos inteligentes permiten a los atacantes eludir las comprobaciones de permisos y generar nuevos tokens de forma indefinida. Enlaces relacionados:
https://wormholecrypto.medium.com/wormhole-incident-report-02-02-22-ad9b8f21eec6
6) Puente Ronin, 2022.03, pérdida de ~600 millones
Los nodos de los miembros con múltiples firmas (cinco de nueve) quedaron comprometidos. Enlaces relacionados:
https://www.theverge.com/2022/7/6/23196713/axie-infinity-ronin-blockchain-hack-phishing-linkedin-job-offer
7) Horizon Bridge, 2022.06, pérdida de ~100 millones
Se robaron las claves privadas de los miembros multifirma (dos de cinco). Enlaces relacionados:
https://halborn.com/explained-the-harmony-horizon-bridge-hack/
2. Incidente de ataque al puente entre cadenas de verificación optimista
Nomad, 2022.08, ~190 millones de pérdidas
Las vulnerabilidades de los contratos inteligentes y la negligencia en el proceso de actualización del contrato permiten que cualquiera falsifique mensajes entre cadenas para transferir activos. Enlaces relacionados:
https://www.coinbase.com/blog/nomad-bridge-incident-analysis
3. Incidente de ataque al puente entre cadenas de Light Client + Trustless Relayers
Cerca de Rainbow Bridge, 2022.05 y 2022.08, no se perdió ningún fondo
El servicio de vigilancia bloqueó dos intentos de falsificar mensajes entre cadenas. Enlaces relacionados:
https://decrypt.co/108015/nears-rainbow-bridge-blocks-another-attack-costing-hackers-5-ethereum
4. HTMLC no tiene ataques
De hecho, se puede ver que todos los ataques ocurrieron debido a problemas de gestión de seguridad del nodo de Trusted Relayers y problemas de contrato. No hubo ataques exitosos contra Optimistic Verification, Light Client o el protocolo de puente entre cadenas HTLC en sí.
Comparación de puentes de cadenas cruzadas.
A continuación se muestra una comparación de diferentes tecnologías de puentes entre cadenas en términos de "Costo", "Experiencia de usuario (UX)" y "Seguridad". Lo siguiente se presentará directamente en imágenes.
1. Costo
Trusted Relayers: El costo más bajo, porque no se requiere verificación complicada y la información proporcionada por Relayer es directamente confiable.
Verificación optimista: solo es necesario verificar Merkle Proof
Cliente ligero: para verificar la mayoría de las cosas, incluido el consenso, bloquear archivos de encabezado y prueba de transacciones o estado.
HTLC: La verificación es muy simple, pero requerirá múltiples transacciones (Bloquear/Desbloquear) para completarse.
2. Experiencia de usuario (UX)
Trusted Relayers: la mejor experiencia. Relayer se mueve a través de las cadenas lo más rápido posible y los usuarios no necesitan hacer nada.
Verificación optimista: debe esperar el período de desafío (ventana optimista) y es posible que encuentre el Actualizador fuera de línea o una falsificación del Observador.
Cliente ligero: debe esperar hasta la finalidad, diferentes cadenas tendrán diferentes experiencias y hay pocas cadenas compatibles.
HTLC: se requieren múltiples transacciones (bloqueo/desbloqueo), los usuarios deben permanecer en línea y la calidad del servicio de los enrutadores es inconsistente.
3. Seguridad
Retransmisores de confianza: la seguridad más baja, que requiere la suposición de que la mayoría de los miembros con firmas múltiples son honestos, o que DoS deje fuera de línea a un pequeño número de miembros también provocará el cierre del servicio.
Verificación optimista: solo es necesario asumir que al menos un observador es honesto, pero si el actualizador está fuera de línea debido a DoS, aún así provocará que el servicio se detenga.
Cliente ligero: Muy seguro, debes poder atacar el consenso de esas cadenas para causar daño.
HTLC: la función hash más segura debe romperse antes de que pueda causar daño
La diferencia entre Rollup Bridge y Cross-Chain Bridge
Rollup Bridge se refiere al puente nativo entre Rollup y su L1. Debido a que los mensajes se pueden transmitir directamente entre L1 y Rollup, y la validez del mensaje está garantizada mediante prueba de conocimiento cero o prueba de fraude, es mejor que la relación entre L1 y L1. El puente de cadenas transversales entre ellos es mucho más seguro.
Sin embargo, habrá algunos retrasos en el puente nativo de Rollup: ZK Rollup debe esperar a que se genere y cargue la prueba de conocimiento cero en la cadena, y Optimistic Rollup debe esperar hasta el final del período de desafío.
Nota: El retraso ocurre principalmente en los mensajes Rollup -> L1, y L1 -> Los mensajes Rollup son muy rápidos.
Si no quiere esperar, puede utilizar los servicios proporcionados por un tercero: utiliza el puente nativo para transferir dinero al tercero. El tercero le adelanta el dinero primero en L1 y luego espera lentamente. el dinero pasaría por el puente nativo. Para obtener más información sobre Rollup Bridge, consulte la serie de artículos de imToken "Introducción a Rollup Bridge (1): Maker DAI Bridge":
https://medium.com/imtoken/rollup-bridge-%E4%BB%8B%E7%B4%B9-%E4%B8%80-maker-dai-bridge-678c62228eb5
Los requisitos de seguridad para usar cadenas cruzadas son diferentes a los de proporcionar liquidez.
Si simplemente utiliza servicios entre cadenas, como transferir dinero de la cadena A a la cadena B, no necesita preocuparse demasiado. Incluso si el puente es pirateado, siempre y cuando el puente todavía tenga liquidez residual o haya nuevos Si se inyecta liquidez más tarde, la solicitud entre cadenas definitivamente se completará.
Pero si desea proporcionar liquidez a un puente entre cadenas para ganar tarifas de manejo entre cadenas, debe elegir el puente entre cadenas con cuidado. Si la cantidad robada es demasiado grande y la parte del proyecto no puede compensar, definitivamente perderá dinero. Puede elegir un puente entre cadenas con mecanismos de seguridad adicionales. Por ejemplo, Celer y XY establecen un límite para las transferencias entre cadenas (por ejemplo, la transferencia máxima acumulada solo puede ser de 100 millones en una sola vez o dentro de un período de tiempo). ).
De hecho, al igual que utilizar AMM, proporcionar liquidez definitivamente conllevará mayores riesgos que un simple swap.
Nuevas tecnologías o desarrollos recientes
1) Puente de cliente ligero ZK
Como se mencionó anteriormente, aunque el puente entre cadenas de Light Client es seguro, también es muy costoso, y la buena noticia es que la prueba de conocimiento cero puede reducir efectivamente este costo. Pero cabe señalar que la prueba de conocimiento cero sólo puede mejorar la eficiencia, pero no la seguridad. Además, la prueba de conocimiento cero es más complicada y pasará mucho tiempo hasta que ZK Light Client admita suficientes cadenas.
Hay dos nuevos proyectos implementando ZK Light Client:
Laboratorios sucintos
https://blog.succinct.xyz/post/2022/09/20/proof-of-consensus
zkPuente
https://twitter.com/dawnsongtweets/status/1574775694139314176
2) El mundo de las cadenas cruzadas sigue siendo un tesoro de MEV sin explotar.
Las transacciones entre cadenas crean más oportunidades MEV que las transferencias de cadena única
Si las transacciones entre cadenas se combinan con DEX para realizar intercambios, habrá más oportunidades MEV.
Para obtener más información, consulte el discurso y las diapositivas del fundador de Nomad en el MEV Day en ETHamsterdam. Concluyó que el DEX entre cadenas no se puede implementar porque el precio no será competitivo debido al impacto de más oportunidades MEV. Para usar DEX entre cadenas, es mejor simplemente cruzar los activos en cadena primero y luego ir al intercambio DEX usted mismo. .
Enlace original:
https://medium.com/taipei-ethereum-meetup/%E8%B7%A8%E9%8F%88%E6%A9%8B%E6%AF%94%E8%BC%83-4327192f7200
**Este artículo solo representa las opiniones del autor original y no constituye ninguna opinión o recomendación de inversión.
-FIN-
[El propósito de la publicación de artículos es difundir información más valiosa. Los derechos de autor del artículo pertenecen al autor original. Su contenido y opiniones no representan la posición de Unitimes. Todas las imágenes que aparecen en esta plataforma WeChat se recopilan de Internet y los derechos de autor pertenecen al propietario de los derechos de autor. Si el propietario de los derechos de autor cree que su trabajo no es adecuado para que todos lo naveguen o no debe usarse de forma gratuita, agregue WeChat uniforms2018. para contactarnos, y esta plataforma hará las correcciones de inmediato. 】
Simplemente haz clic en " Me gusta " cuando vengas.
