Introducción

El futuro es multicadena. La búsqueda de escalabilidad ha llevado a Ethereum hacia los roll-ups. El cambio hacia cadenas de bloques modulares ha reavivado la atención sobre las cadenas de aplicaciones. Y en el horizonte, escuchamos susurros sobre acumulaciones de aplicaciones específicas, L3 y cadenas soberanas.

Pero esto se ha producido a costa de la fragmentación. Por lo tanto, se lanzó la primera ola de puentes básicos para abordar la necesidad de puentes, pero a menudo tienen una funcionalidad limitada y dependen de firmantes confiables para su seguridad.

¿Cómo será el final de una web3 interconectada? Creemos que todos los puentes evolucionarán hacia protocolos de mensajería entre cadenas o de "Paso arbitrario de mensajes" (AMP) para desbloquear nuevos casos de uso, al permitir que las aplicaciones pasen mensajes arbitrarios desde la cadena de origen a la de destino. También veremos surgir un “panorama de mecanismos de confianza”, donde los constructores harán diversas concesiones en usabilidad, complejidad y seguridad.

Cada solución AMP necesita dos capacidades críticas:

• Verificación: la capacidad de verificar la validez del mensaje de la cadena de origen en la cadena de destino.
• Vivencia: la capacidad de transmitir información desde el origen al destino.

No se puede lograr una verificación 100% sin confianza y los usuarios deben confiar en el código, la teoría de juegos, los humanos (o entidades), o una combinación de estos, dependiendo de si la verificación se realiza dentro o fuera de la cadena.

Dividimos el panorama general de interoperabilidad según el mecanismo de confianza y la arquitectura de integración.

Mecanismo de confianza:

1. Código de confianza/matemáticas: para estas soluciones, existe prueba en cadena y cualquiera puede verificarla. Estas soluciones generalmente dependen de un cliente ligero para validar el consenso de una cadena de origen en una cadena de destino o verificar la validez de una transición de estado para una cadena de origen en una cadena de destino. La verificación a través de clientes ligeros se puede hacer mucho más eficiente a través de pruebas de Conocimiento Cero para comprimir cálculos arbitrariamente largos fuera de línea y proporcionar una verificación simple en cadena para probar los cálculos.
2. Teoría de juegos de confianza: existe un supuesto de confianza adicional cuando el usuario/aplicación tiene que confiar en un tercero o en una red de terceros para la autenticidad de las transacciones. Estos mecanismos pueden hacerse más seguros mediante redes sin permiso junto con teorías de juegos, como incentivos económicos y seguridad optimista.
3. Confíe en los humanos: estas soluciones se basan en la honestidad de la mayoría de los validadores o en la independencia de las entidades que transmiten información diferente. Requieren confianza en terceros además de confiar en el consenso de las dos cadenas que interactúan. Lo único que está en juego aquí es la reputación de las entidades participantes. Si suficientes entidades participantes acuerdan que una transacción es válida, entonces se considera válida.

Es importante señalar que todas las soluciones, hasta cierto punto, requieren confianza tanto en el código como en los humanos. Los piratas informáticos pueden explotar cualquier solución con código defectuoso y cada solución tiene algún elemento humano en la configuración, las actualizaciones o el mantenimiento del código base.

Arquitectura de integración:

1. Modelo punto a punto: es necesario establecer un canal de comunicación dedicado entre cada origen y cada destino.
2. Modelo Hub and Spoke: es necesario establecer un canal de comunicación con un centro central que permita la conectividad con todas las demás cadenas de bloques conectadas a ese centro.

El modelo Punto a Punto es relativamente difícil de escalar ya que se requiere un canal de comunicación por pares para cada cadena de bloques conectada. Desarrollar estos canales puede ser un desafío para blockchains con diferentes consensos y marcos. Sin embargo, los puentes por pares brindan más flexibilidad para personalizar las configuraciones, si es necesario. También es posible un enfoque híbrido, por ejemplo, mediante el uso de un protocolo de comunicación entre cadenas de bloques (IBC) con enrutamiento de múltiples saltos a través de un concentrador, lo que elimina la necesidad de comunicación directa por pares, pero reintroduce más complejidad en seguridad, latencia y costo. consideraciones.

Código de confianza/matemáticas

¿Cómo validan los clientes ligeros el consenso de una cadena de origen sobre una cadena de destino?

Un cliente/nodo ligero es una pieza de software que se conecta a nodos completos para interactuar con la cadena de bloques. Los clientes ligeros en la cadena de destino normalmente almacenan el historial de encabezados de bloque (secuencialmente) de la cadena de origen, lo cual es suficiente para verificar las transacciones. Los agentes fuera de la cadena, como los retransmisores, monitorean los eventos en la cadena de origen, generan pruebas de inclusión criptográfica y las reenvían junto con los encabezados de los bloques al cliente ligero en la cadena de destino. Los clientes ligeros pueden verificar la transacción mientras almacenan los encabezados de los bloques secuencialmente y cada encabezado de bloque contiene el hash raíz de Merkle que se puede usar para probar el estado. Las características clave de este mecanismo son:

1. Seguridad:

• Además de la confianza en el código, se introduce otra suposición de confianza durante la inicialización del cliente ligero. Cuando alguien crea un nuevo cliente ligero, se inicializa con un encabezado desde una altura específica de la cadena de contraparte. El encabezado proporcionado podría ser incorrecto y el cliente ligero podría ser engañado posteriormente con más encabezados falsos. No se introducen suposiciones de confianza una vez que se ha inicializado el cliente ligero. Sin embargo, esta es una suposición de confianza débil ya que cualquiera puede verificar la inicialización.
• Existe una suposición de vida en el retransmisor, ya que es necesario para transmitir la información.

1. Implementación: Depende de la disponibilidad de soporte para las primitivas criptográficas necesarias para la verificación.

• Si se conecta el mismo tipo de cadena (mismo marco de aplicación y algoritmo de consenso), entonces la implementación del cliente ligero en ambos lados será la misma. Ejemplo: IBC para todas las cadenas basadas en Cosmos SDK.
• Si se conectan dos tipos diferentes de cadenas (diferentes marcos de aplicación o tipos de consenso), la implementación del cliente ligero será diferente. Ejemplo: Composable Finance está trabajando para permitir que las cadenas Cosmos SDK se conecten a través de IBC a Substrate (marco de aplicación del ecosistema Polkadot). Esto requiere un cliente ligero Tendermint en la cadena de sustrato y un cliente ligero robusto agregado a la cadena Cosmos SDK.

1. Desafíos:

• Intensidad de recursos: es costoso ejecutar clientes ligeros por pares en todas las cadenas, ya que las escrituras en blockchains son costosas y no es factible ejecutarlas en cadenas con conjuntos de validadores dinámicos como Ethereum.
• Extensibilidad: se requiere una implementación ligera del cliente para cada combinación de cadenas. Dado que la implementación varía según la arquitectura de la cadena, es difícil escalar y conectar diferentes ecosistemas.
• Explotación de código: los errores en el código pueden generar vulnerabilidades. El exploit de la cadena BNB en octubre de 2022 descubrió una vulnerabilidad de seguridad crítica que afectaba a todas las cadenas habilitadas para IBC.

¿Cómo verifican las pruebas ZK la validez de una transición de estado para la cadena de origen en la cadena de destino?

Ejecutar clientes ligeros por pares en todas las cadenas tiene un costo prohibitivo y no es práctico para todas las cadenas de bloques. Los clientes ligeros en implementaciones como IBC también deben realizar un seguimiento del conjunto de validadores de la cadena de origen, lo que no es práctico para cadenas con conjuntos de validadores dinámicos, como Ethereum. Las pruebas ZK proporcionan una solución para reducir el gas y el tiempo de verificación. En lugar de ejecutar todo el cálculo en la cadena, solo se realiza la verificación de la prueba del cálculo en la cadena y el cálculo real se realiza fuera de la cadena. La verificación de una prueba de cálculo se puede realizar en menos tiempo y con menos gas que volver a ejecutar el cálculo original. Las características clave de este mecanismo son:

1. Seguridad: los zk-SNARK dependen de curvas elípticas para su seguridad y los zk-STARK dependen de funciones hash. Los zk-SNARK pueden requerir o no una configuración confiable. La configuración confiable solo es necesaria inicialmente, lo que se refiere al evento de creación inicial de las claves que se utilizan para crear las pruebas necesarias para la verificación de esas pruebas. Si los secretos del evento de configuración no se destruyen, podrían utilizarse para falsificar transacciones mediante verificaciones falsas. No se introducen suposiciones de confianza una vez realizada la configuración confiable.
2. Implementación: Hoy en día existen diferentes esquemas de prueba ZK como SNARK, STARK, VPD, SNARG y actualmente SNARK es el más adoptado. Las pruebas recursivas ZK son otro desarrollo más reciente que permite dividir el trabajo total de prueba entre varias computadoras en lugar de solo una. Para generar pruebas de validez, se deben implementar las siguientes primitivas centrales:

• verificación del esquema de firma utilizado por los validadores
• inclusión de prueba de las claves públicas del validador en el compromiso del conjunto del validador (que se almacena en la cadena)
• Seguimiento del conjunto de validadores que pueden seguir cambiando con frecuencia.

1. Desafíos:

• Para implementar varios esquemas de firma dentro de un zkSNARK se requiere implementar operaciones aritméticas fuera de campo y operaciones complejas de curvas elípticas. Esto no es fácil de lograr y puede requerir diferentes implementaciones para cada cadena según su marco y consenso.
• Si el tiempo y el esfuerzo de prueba son extremadamente altos, entonces sólo los equipos especializados con hardware especializado podrán hacer lo que conducirá a la centralización. Un mayor tiempo de generación de pruebas también puede provocar latencia.
• Un mayor tiempo y esfuerzo de verificación generará mayores costos en la cadena.

1. Ejemplos: Polymer ZK-IBC de Polymer Labs, Succinct Labs. Polymer está trabajando en IBC habilitado para múltiples saltos para aumentar la conectividad y al mismo tiempo reducir la cantidad de conexiones por pares necesarias.

Teoría de juegos de confianza

Los protocolos de interoperabilidad que se basan en la teoría de juegos se pueden dividir en términos generales en 2 categorías según cómo incentivan el comportamiento honesto de las entidades participantes:

1. Seguridad económica: varios participantes externos (como validadores) llegan a un consenso sobre el estado actualizado de la cadena de origen. Esto es similar a una configuración de firmas múltiples, pero para convertirse en validador, los participantes deben apostar una cierta cantidad de tokens, que pueden reducirse en caso de que se detecte alguna actividad maliciosa. En configuraciones sin permiso, cualquiera puede acumular apuestas y convertirse en validador. También existen recompensas en bloque, que actúan como incentivos económicos, cuando los validadores participantes siguen el protocolo. Para ser honesto, los participantes se ven así incentivados económicamente. Sin embargo, si la cantidad que se puede robar es mucho mayor que la cantidad apostada, entonces los participantes pueden intentar confabularse para robar fondos. Ejemplos: Axelar, Celer IM
2. Seguridad optimista: las soluciones de seguridad optimistas se basan en el supuesto de confianza minoritaria que supone que solo una minoría de los participantes de blockchain son vivos, honestos y siguen las reglas del protocolo. La solución podría requerir que sólo un único participante honesto tenga una garantía. El ejemplo más común es una solución óptima en la que cualquiera puede presentar pruebas de fraude. También existe un incentivo económico, pero es prácticamente posible que incluso un observador honesto se pierda una transacción fraudulenta. Los roll-ups optimistas también aprovechan este enfoque. Ejemplos: Nomad, ChainLink CCIP

• En el caso de Nomad, los observadores pueden demostrar un fraude. Sin embargo, los observadores de Nomad están en la lista blanca al momento de escribir este artículo.
• ChainLink CCIP aprovechará una red antifraude que consistirá en redes Oracle descentralizadas con el único propósito de monitorear actividades maliciosas. La implementación de la red antifraude de CCIP aún está por verse.

Las características clave de estos mecanismos son:

1. Seguridad: para ambos mecanismos, es esencial contar con la participación sin permiso de validadores y observadores para que los mecanismos de la teoría de juegos sean efectivos. Según el mecanismo de seguridad económica, los fondos pueden correr mayor riesgo si la cantidad apostada es menor que la cantidad que se puede robar. Bajo el mecanismo de seguridad optimista, los supuestos de confianza de las minorías para soluciones optimistas pueden explotarse si nadie presenta pruebas de fraude, o si los observadores autorizados se ven comprometidos o eliminados, mientras que los mecanismos de seguridad económica no dependen de la misma forma en la vida para la seguridad.
2. Implementación:

• Cadena intermedia con sus propios validadores: un grupo de validadores externos monitorea la cadena de origen, llega a un consenso sobre la validez de la transacción cada vez que se detecta una llamada y proporciona una certificación sobre la cadena de destino si se llega a un consenso. Por lo general, se requiere que los validadores apuesten una cierta cantidad de tokens que pueden reducirse si se detecta actividad maliciosa. Ejemplos: Red Axelar, Celer IM
• A través de agentes fuera de la cadena: los agentes fuera de la cadena se pueden utilizar para implementar una solución optimista tipo roll-up en la que, durante un período de tiempo predefinido, los agentes fuera de la cadena podrán presentar pruebas de fraude y revertir la transacción. Ejemplo: Nomad depende de agentes independientes fuera de la cadena para transmitir el encabezado y la prueba criptográfica. ChainLink CCIP aprovechará su red Oracle existente para monitorear y certificar transacciones entre cadenas.

1. Desafíos:

• Los supuestos de confianza pueden explotarse para robar fondos si la mayoría de los validadores se confabulan, lo que requiere contramedidas como votación cuadrática y pruebas de fraude.
• Finalidad: Las soluciones AMP optimistas basadas en seguridad introducen complejidad en la finalidad y la vida porque los usuarios y las aplicaciones deben esperar la ventana de fraude.

1. Ventajas:

• Optimización de recursos: este enfoque generalmente no requiere muchos recursos ya que la verificación generalmente no ocurre en la cadena.
• Extensibilidad: este enfoque es más extensible ya que el mecanismo de consenso sigue siendo el mismo para todo tipo de cadenas y puede extenderse fácilmente a cadenas de bloques heterogéneas.

Confía en los humanos

1. Supuesto de honestidad mayoritaria: estas soluciones se basan en una implementación de múltiples firmas donde varias entidades verifican y firman las transacciones. Una vez que se alcanza el umbral mínimo, la transacción se considera válida. La suposición aquí es que la mayoría de las entidades son honestas y si la mayoría de estas entidades firman una transacción en particular, es válida. Lo único que está en juego aquí es la reputación de las entidades participantes. Ejemplos: Multichain (Anycall V6), Wormhole. Aún es posible realizar exploits debido a errores de contratos inteligentes, como lo demuestra el hack de Wormhole a principios de 2022.
2. Independencia: estas soluciones dividen todo el proceso de paso de mensajes en dos partes y dependen de diferentes entidades independientes para gestionar los dos procesos. La suposición aquí es que las dos entidades son independientes entre sí y no están en connivencia. Ejemplo: CapaCero. Los encabezados de los bloques se transmiten a pedido mediante oráculos descentralizados y las pruebas de las transacciones se envían a través de retransmisores. Si el comprobante coincide con los encabezados, la transacción se considera válida. Si bien la comparación de pruebas se basa en códigos/matemáticas, los participantes deben confiar en que las entidades seguirán siendo independientes. Las aplicaciones creadas en LayerZero tienen la opción de elegir su Oracle y Relayer (o alojar su propio Oracle/Relayer), limitando así el riesgo de colusión individual entre Oracle y Relayer. Los usuarios finales deben confiar en que LayerZero, un tercero o la aplicación misma ejecutan Oracle y Relayer de forma independiente y sin intenciones maliciosas.

En ambos enfoques, la reputación de las entidades de terceros participantes desincentiva el comportamiento malicioso. Por lo general, se trata de entidades respetadas dentro de la comunidad de validadores y Oracle y corren el riesgo de sufrir consecuencias para su reputación y un impacto negativo en sus otras actividades comerciales si actúan de manera maliciosa.

Más allá de los supuestos de confianza y el futuro de la interoperabilidad

Al considerar la seguridad y usabilidad de una solución AMP, también debemos tener en cuenta los detalles más allá de los mecanismos básicos. Como se trata de piezas móviles que pueden cambiar con el tiempo, no las incluimos en la comparación general.

• Integridad del código: varios ataques en el pasado reciente han aprovechado errores en el código que requieren auditorías confiables, recompensas por errores bien planificadas e implementaciones de múltiples clientes. Si todos los validadores (en seguridad económica/optimista/reputacional) ejecutan el mismo cliente (software para verificación), aumenta la dependencia de una única base de código y reduce la diversidad de clientes. Ethereum, por ejemplo, depende de múltiples clientes de ejecución como geth, nethermind, erigon, besu, akula. Es probable que múltiples implementaciones en una variedad de lenguajes aumenten la diversidad sin que ningún cliente domine la red, eliminando así un posible punto único de falla. Tener varios clientes también podría ayudar con la vida útil si una minoría de validadores/firmantes/clientes ligeros falla debido a vulnerabilidades/errores en una implementación en particular.
• Configuración y capacidad de actualización: los usuarios y desarrolladores deben saber si los validadores/observadores pueden unirse a la red sin permiso; de lo contrario, la confianza queda oculta por la selección de entidades autorizadas. Las actualizaciones de los contratos inteligentes también pueden introducir errores que pueden provocar vulnerabilidades o incluso cambiar potencialmente los supuestos de confianza. Se pueden implementar diferentes soluciones para mitigar estos riesgos. Por ejemplo, en la instancia actual, las puertas de enlace de Axelar se pueden actualizar sujetas a la aprobación de un comité fuera de línea (umbral de 4/8); sin embargo, en un futuro próximo, Axelar planea exigir que todos los validadores aprueben colectivamente cualquier actualización de las puertas de enlace. Los contratos principales de Wormhole se pueden actualizar y se gestionan a través del sistema de gobernanza en cadena de Wormhole. LayerZero se basa en contratos inteligentes inmutables y bibliotecas inmutables para evitar actualizaciones; sin embargo, puede impulsar una nueva biblioteca, y las dapps con configuraciones predeterminadas obtendrían la versión actualizada, y las dapps con su versión configurada manualmente necesitarían configurarla en la nueva. .
• MEV: Diferentes blockchains no se sincronizan a través de un reloj común y tienen tiempos diferentes hasta su finalidad. Como resultado, el orden y el tiempo de ejecución en la cadena de destino pueden variar entre cadenas. Es difícil definir claramente MEV en un mundo de cadenas cruzadas. Introduce un equilibrio entre vivacidad y orden de ejecución. Un canal ordenado garantizará la entrega ordenada de mensajes, pero el canal se cerrará si un mensaje se agota. Otra aplicación podría preferir un escenario en el que no sea necesario realizar pedidos pero la entrega de otros mensajes no se vea afectada.

Tendencias y perspectivas de futuro:

• Seguridad personalizable y aditiva: para servir mejor a diversos casos de uso, las soluciones AMP están incentivadas a ofrecer más flexibilidad a los desarrolladores. Axelar introdujo un enfoque para la capacidad de actualización del paso y verificación de mensajes, sin ningún cambio en la lógica de la capa de aplicación. HyperLane V2 introdujo módulos que permiten a los desarrolladores elegir entre múltiples opciones, como seguridad económica, seguridad optimista, seguridad dinámica y seguridad híbrida. CelerIM ofrece seguridad optimista adicional junto con seguridad económica. Muchas soluciones esperan un número mínimo predefinido de confirmaciones de bloque en la cadena de origen antes de transmitir el mensaje. LayerZero permite a los desarrolladores actualizar estos parámetros. Esperamos que algunas soluciones AMP sigan ofreciendo más flexibilidad, pero estas opciones de diseño merecen cierta discusión. ¿Deberían las aplicaciones poder configurar su seguridad, en qué medida y qué sucede si las aplicaciones adoptan una arquitectura de diseño deficiente? La concienciación de los usuarios sobre los conceptos básicos detrás de la seguridad puede llegar a ser cada vez más importante. En última instancia, prevemos la agregación y abstracción de soluciones AMP, tal vez en alguna forma de combinación o seguridad "aditiva".
• Crecimiento y maduración de los mecanismos de “código de confianza/matemáticas”: en un final ideal, se minimizará la confianza en todos los mensajes entre cadenas mediante el uso de pruebas de conocimiento cero (ZK) para verificar mensajes y estados. Ya estamos presenciando este cambio con el surgimiento de proyectos como Polymer Labs y Succinct Labs. Multichain también publicó recientemente un documento técnico de zkRouter para permitir la interoperabilidad a través de pruebas ZK. Con la máquina virtual Axelar recientemente anunciada , los desarrolladores pueden aprovechar el amplificador Interchain para configurar sin permiso nuevas conexiones a la red Axelar. Por ejemplo, una vez que se desarrollan clientes ligeros robustos y pruebas ZK para el estado de Ethereum, un desarrollador puede integrarlos fácilmente en la red Axelar para reemplazar o mejorar una conexión existente. LayerZero en su documentación habla de la posibilidad de agregar nuevas bibliotecas de mensajería de prueba optimizadas en el futuro. Proyectos más nuevos como Lagrange están explorando la agregación de múltiples pruebas de múltiples cadenas de origen y Herodotus está haciendo factibles las pruebas de almacenamiento a través de pruebas ZK. Sin embargo, esta transición llevará tiempo ya que este enfoque es difícil de escalar entre cadenas de bloques que dependen de diferentes mecanismos y marcos de consenso. ZK es una tecnología relativamente nueva y compleja que resulta difícil de auditar y, actualmente, la verificación y generación de pruebas no es rentable. Creemos que, a largo plazo, para admitir aplicaciones entre cadenas altamente escalables en la cadena de bloques, es probable que muchas soluciones AMP complementen a personas y entidades confiables con software verificable porque:
• La posibilidad de explotación del código se puede minimizar mediante auditorías y recompensas por errores. Con el paso del tiempo será más fácil confiar en estos sistemas ya que su historia servirá como prueba de su seguridad.
• El coste de generar pruebas ZK disminuirá. Con más I+D en ZKP, ZK recursivo, agregación de pruebas y hardware especializado, esperamos que el tiempo y el costo de la generación y verificación de pruebas se reduzcan significativamente, lo que lo convierte en un enfoque más rentable.
• Las cadenas de bloques serán más compatibles con zk. En el futuro, los zkEVM podrán proporcionar una prueba de validez de ejecución sucinta, y las soluciones ligeras basadas en clientes podrán verificar fácilmente tanto la ejecución como el consenso de una cadena de origen en la cadena de destino. En el final de Ethereum, también hay planes para "zk-SNARK todo", incluido el consenso.
• Prueba de humanidad/reputación/identidad: la seguridad de sistemas complejos como las soluciones AMP no se puede encapsular en un marco único y justifica múltiples capas de soluciones. Por ejemplo, junto con los incentivos económicos, Axelar ha implementado la votación cuadrática para evitar la concentración del poder de voto entre un subconjunto de nodos y promover la descentralización. Otras pruebas de humanidad, reputación e identidad también pueden complementar los mecanismos de configuración y permiso.

En el espíritu de apertura de Web3, probablemente veremos un futuro plural donde coexistirán múltiples enfoques. De hecho, las aplicaciones pueden optar por utilizar múltiples soluciones de interoperabilidad, ya sea de forma redundante o permitir que los usuarios mezclen y combinen con la divulgación de compensaciones. Las soluciones punto a punto pueden tener prioridad entre rutas de “alto tráfico”, mientras que los modelos de centro y radio pueden dominar la larga cola de las cadenas. Al final, depende de nosotros, el colectivo de usuarios, constructores y contribuyentes, dar forma a la topografía de la web interconectada3.

Nos gustaría agradecer a Bo Du y Peter Kim de Polymer Labs, Galen Moore de Axelar Network, Uma Roy de Succinct Labs, Max Glassman y Ryan Zarick de LayerZero por revisar y brindar sus valiosos comentarios.

Lista de referencias:

• Axelar: https://docs.axelar.dev/
• CelerIM: https://im-docs.celer.network/developer/celer-im-overview
• ChainLink CCIP: https://blog.chain.link/introduciendo-the-cross-chain-interoperability-protocol-ccip/
• debridge: https://docs.debridge.finance/
• CIB: https://tutorials.cosmos.network/academy/3-ibc/
• CapaZero: https://layerzero.gitbook.io/docs/
• Multicadena: https://docs.multichain.org/getting-started/introduction
• Nómada: https://docs.nomad.xyz/nomad-101/introduction
• Laboratorios de polímeros: https://polymerlabs.medium.com/
• Laboratorios sucintos: https://blog.succinct.xyz/
• Agujero de gusano: https://docs.wormhole.com/wormhole/

Lista de lectura adicional:

• Navegando por puentes de mensajería arbitraria: un marco de comparación: https://blog.li.fi/navigating-arbitrary-messaging-bridges-a-comparison-framework-8720f302e2aa
• Marco de riesgos de L2Bridge: https://gov.l2beat.com/t/l2bridge-risk-framework/31
• Horacio en el puente: https://maven11.substack.com/p/horatius-at-the-bridge

Descargo de responsabilidad:

1. Este artículo se reimprime de [medio]. Todos los derechos de autor pertenecen al autor original [LongHash Ventures]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: los puntos de vista y opiniones expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas están a cargo del equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.