Autor: STANFORD BLOCKCHAIN CLUB Compilado por: Cointime: QDD.
introducción
El futuro es multicadena. La búsqueda de la escalabilidad lleva a Ethereum hacia soluciones móviles. El paso a cadenas de bloques modulares ha renovado el interés en las cadenas de aplicaciones. En el horizonte, escuchamos rumores sobre soluciones rodantes para aplicaciones específicas, soluciones de capa 3 y cadenas soberanas. Pero todo esto tiene el costo de la fragmentación, ya que los puentes actuales a menudo tienen una funcionalidad limitada y dependen de partes firmantes confiables para brindar seguridad.
¿Cómo será la forma final de interconexión en Internet 3.0? Creemos que los puentes eventualmente evolucionarán hacia protocolos de mensajería entre cadenas o de paso de mensajes arbitrarios (AMP) para desbloquear nuevos casos de uso, permitiendo que las aplicaciones pasen mensajes arbitrarios entre las cadenas de origen y de destino. También veremos el surgimiento de un “panorama de confianza” en el que los constructores harán diversas concesiones en cuanto a facilidad de uso, complejidad y seguridad.
Cada solución AMP requiere dos capacidades clave:
1. Verificación: Verifique la validez del mensaje de la cadena de origen en la cadena de destino.
2. Supervivencia: la capacidad de transmitir información desde la cadena de origen a la cadena de destino.
Desafortunadamente, la verificación 100% sin confianza no es realista y los usuarios deben confiar en el código, la teoría de juegos, los humanos (o entidades), o una combinación de ellos, dependiendo de si la verificación ocurre dentro o fuera de la cadena.
En este artículo, dividiremos el panorama general de interoperabilidad vertical y horizontalmente según los mecanismos de confianza y la arquitectura de integración utilizados.
Mecanismo de confianza:
1. Código de confianza y matemáticas: para estas soluciones, existen pruebas en cadena que cualquiera puede verificar. Estas soluciones a menudo dependen de clientes ligeros para verificar el consenso de la cadena de origen en la cadena de destino o para verificar la validez de las transiciones de estado de la cadena de origen en la cadena de destino. La verificación en clientes ligeros se puede hacer más eficiente mediante 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: cuando los usuarios/aplicaciones deben confiar en un tercero o en un grupo de terceros para garantizar la autenticidad de una transacción, existen supuestos de confianza adicionales. Estos mecanismos pueden hacerse más seguros mediante redes sin permiso combinadas con la teoría 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 entregan información diferente. Además de confiar en el consenso de dos cadenas interactivas, también se requiere confianza en un tercero. Aquí sólo está en juego la reputación de las entidades participantes. Una transacción se considera válida si suficientes entidades participantes la consideran válida.
Es importante tener en cuenta que todas las soluciones requieren cierto nivel de confianza en el código y los humanos. Los piratas informáticos pueden aprovechar cualquier solución de código defectuosa, y cada solución tiene un determinado elemento humano para configurar, actualizar o mantener la base del código.
Arquitectura integrada:
1. Modelo de igual a igual: es necesario establecer un canal de comunicación dedicado entre cada cadena de origen y cada cadena de destino.
2. Modelo de centro central: es necesario establecer un canal de comunicación con un centro central que pueda conectar todas las demás cadenas de bloques conectadas al centro.
El modelo peer-to-peer es relativamente difícil de escalar porque cada blockchain conectada requiere un par de canales de comunicación. Desarrollar estos canales puede ser un desafío para blockchains con diferentes consensos y marcos. Sin embargo, si se desea, se puede adoptar un enfoque híbrido, como utilizar el Protocolo de comunicación entre cadenas (IBC) para el enrutamiento de múltiples saltos a través de un concentrador central, lo que elimina la necesidad de comunicación directa punto a punto pero introduce más en términos de seguridad, latencia y complejidad.
Código de confianza y matemáticas
Para confiar únicamente en el código/matemáticas para los supuestos de confianza, se puede utilizar un cliente ligero para verificar el consenso de la cadena de origen en la cadena de destino. Un cliente/nodo ligero es una pieza de software que se conecta a un nodo completo para interactuar con la cadena de bloques. Los clientes ligeros en la cadena de destino normalmente almacenan los encabezados de los bloques de la cadena de origen (en orden), lo cual es suficiente para verificar las transacciones. De manera similar, los agentes fuera de la cadena (como los retransmisores) en la cadena de origen monitorean los eventos, generan pruebas criptográficas de inclusión y las reenvían junto con los encabezados de los bloques a los clientes ligeros en la cadena de destino. Dado que los clientes ligeros almacenan los encabezados de los bloques en orden, pueden verificar las transacciones porque cada encabezado de bloque contiene el hash raíz de Merkle utilizado para probar el estado. A continuación se ofrece una descripción general de las características clave de este enfoque:
seguridad
Los supuestos de confianza se introducen durante la inicialización del cliente ligero. Cuando se crea un nuevo cliente ligero, se inicializa con un encabezado de bloque a una altura específica. Sin embargo, los encabezados de bloque proporcionados pueden ser incorrectos, lo que hace posible engañar a los clientes ligeros con encabezados de bloque falsificados. Una vez completada la inicialización del cliente ligero, no se introducen más supuestos de confianza. Sin embargo, vale la pena señalar que este proceso de inicialización se basa en un supuesto de confianza más débil, ya que cualquiera puede verificarlo. Además, la continuidad del repetidor también es una presunción de confianza ya que es el encargado de transmitir la información.
lograr
La implementación del cliente ligero depende de la disponibilidad de las primitivas criptográficas necesarias para la autenticación. Si se conecta al mismo tipo de cadena, es decir, comparten el mismo marco de aplicación y algoritmo de consenso, entonces las implementaciones de cliente ligero de ambas partes serán las mismas. Por ejemplo, todas las cadenas basadas en Cosmos SDK utilizan el protocolo de comunicación entre cadenas de bloques (IBC). Por otro lado, si se conectan dos tipos diferentes de cadenas, como diferentes marcos de aplicación o tipos de consenso, la implementación del cliente ligero será diferente. Un ejemplo es Composable Finance, que está trabajando para conectar la cadena Cosmos SDK al sustrato del ecosistema Polkadot a través de IBC. Esto requiere agregar un cliente ligero Tendermint en la cadena Substrate y un cliente ligero "potente" en la cadena Cosmos SDK. Recientemente, establecieron la primera conexión entre Polkadot y Kusama a través de IBC.
desafío
La intensidad de los recursos es un desafío importante. Ejecutar pares de clientes ligeros en todas las cadenas puede resultar costoso porque las escrituras en la cadena de bloques son costosas. Además, no es posible ejecutar clientes ligeros en cadenas con conjuntos de validadores dinámicos, como Ethereum.
La escalabilidad es otro desafío. Las implementaciones de clientes ligeros varían según la arquitectura de la cadena, lo que dificulta escalar y conectar diferentes ecosistemas.
La explotación del código es un riesgo potencial, ya que los errores en el código pueden generar vulnerabilidades. Un ejemplo es la vulnerabilidad de la cadena BNB en octubre de 2022, que reveló una vulnerabilidad de seguridad crítica que afecta a todas las cadenas habilitadas para IBC [1].
Para abordar el costo y la practicidad de ejecutar pares de clientes ligeros en todas las cadenas, alternativas como las pruebas de conocimiento cero (ZK) brindan una manera de eliminar la confianza en terceros.
Pruebas de conocimiento cero como solución para la confianza de terceros
La prueba ZK se puede utilizar para verificar la validez de la transición de estado en la cadena de origen a la cadena de destino. En lugar de realizar todo el cálculo en la cadena, es mejor realizar solo la verificación del cálculo en la cadena y llevar el proceso de cálculo real fuera de la cadena. Este método es más rápido y menos costoso que volver a ejecutar el cálculo original. Algunos ejemplos incluyen Polymer ZK-IBC de Polymer Labs y Telepathy de Succinct Labs. Polymer está desarrollando IBC con soporte de múltiples saltos para mejorar la conectividad y reducir la cantidad de conexiones por pares necesarias.
Los aspectos clave del mecanismo incluyen:
seguridad
La seguridad de zk-SNARK se basa en curvas elípticas, mientras que zk-STARK se basa en funciones hash. Los zk-SNARK pueden requerir un proceso de configuración confiable donde se crean claves iniciales para las pruebas utilizadas en la verificación. Es fundamental mantener en secreto la clave del evento de configuración de la destrucción para evitar que se realicen transacciones mediante una verificación falsificada. Una vez que se completa la configuración confiable, no se introducen más suposiciones de confianza. Además, los nuevos marcos ZK como Halo y Halo2 eliminan por completo la necesidad de una configuración confiable.
lograr
Existen varios esquemas de prueba ZK, como SNARK, STARK, VPD y SNARG, y el más utilizado actualmente es SNARK. Los diferentes marcos de prueba SNARK, como Groth16, Plonk, Marlin, Halo y Halo2, tienen compensaciones en el tamaño de la prueba, el tiempo de prueba, el tiempo de verificación, los requisitos de memoria y la necesidad de una configuración confiable. También han surgido pruebas recursivas ZK, que permiten distribuir las cargas de trabajo de prueba en varias computadoras en lugar de solo una. Para generar una prueba de validez, se deben implementar las siguientes primitivas centrales: verificar el esquema de firma utilizado por el validador, incluir la prueba de la clave pública del validador en el compromiso del conjunto de validadores almacenado en la cadena y realizar un seguimiento del conjunto de validadores. , que puede Los cambios ocurren con frecuencia.
desafío
La implementación de varios esquemas de firma en zkSNARK requiere implementar operaciones aritméticas fuera del dominio y operaciones de curva elíptica complejas, lo cual no es simple y puede requerir diferentes implementaciones para cada cadena según el marco y el consenso de la cadena. La auditoría de circuitos ZK es una tarea desafiante y propensa a errores. Los desarrolladores deben estar familiarizados con lenguajes de dominios específicos como Circom, Cairo y Noir, o simplemente implementar los circuitos ellos mismos, lo cual puede ser un desafío y una adopción potencialmente lenta. Si el tiempo y el esfuerzo resultan muy elevados, es posible que sólo un equipo dedicado con hardware dedicado pueda manejarlo, lo que puede llevar a la centralización. Los tiempos de generación de pruebas más prolongados también provocan retrasos. Técnicas como la Computación Incremental Verificable (IVC) pueden optimizar los tiempos de prueba, pero muchas de ellas aún se encuentran en la fase de investigación, esperando su implementación. Un mayor tiempo y esfuerzo de verificación aumentarán los costos en cadena.
teoría de juegos de confianza
Los protocolos de interoperabilidad basados en la teoría de juegos se pueden dividir en términos generales en dos categorías según cómo incentivan el comportamiento honesto por parte de las entidades participantes:
La primera categoría es la seguridad económica, donde múltiples actores externos (como los validadores) cooperan para llegar a un consenso sobre el estado actualizado de la cadena de origen. Para convertirse en validador, los participantes deben apostar una cierta cantidad de tokens, que pueden reducirse si se produce una actividad maliciosa. En una configuración sin permiso, cualquiera puede acumular participación y convertirse en validador. Además, los incentivos financieros para que los validadores sigan el protocolo se proporcionan en forma de recompensas en bloque, lo que garantiza un incentivo financiero por un comportamiento honesto. Sin embargo, si la cantidad potencial que se puede robar excede la cantidad apostada, los participantes pueden confabularse para robar fondos. Ejemplos de protocolos que utilizan mecanismos de seguridad económica son Axelar y Celer IM.
La segunda categoría es la seguridad optimista, donde las soluciones se basan en el supuesto de que sólo unos pocos participantes de blockchain son honestos y siguen las reglas del protocolo. En este enfoque, un único participante honesto actúa como garantía. Por ejemplo, la solución óptima permite que cualquiera presente pruebas de fraude. Aunque existe un incentivo financiero, los observadores honestos pueden pasar por alto transacciones fraudulentas. Optimistic Roll-up también utiliza este mecanismo. Nomad y ChainLink CCIP son ejemplos de protocolos que utilizan seguridad optimista. En el caso de Nomad, los observadores pudieron probar el fraude, aunque estaban en la lista blanca al momento de escribir este artículo. ChainLink CCIP planea utilizar una red antifraude compuesta por una red Oracle descentralizada para monitorear la actividad maliciosa, aunque aún no se conoce la implementación de la red antifraude de CCIP.
seguridad
En términos de seguridad, ambos mecanismos dependen de la participación sin permiso de verificadores y observadores para garantizar la validez de la teoría de juegos. En los mecanismos de seguridad económica, los fondos son más vulnerables si el monto comprometido es menor que el monto que potencialmente puede ser robado. Por otro lado, en los mecanismos de seguridad optimistas, la suposición de la confianza de la minoría puede explotarse si nadie presenta pruebas de fraude, o si los observadores autorizados se ven comprometidos o eliminados. En cambio, los mecanismos de seguridad económica dependen menos de la vivacidad para mantener la seguridad.
implementar
En términos de implementación, un enfoque implica una cadena intermedia con sus propios validadores. En esta configuración, un conjunto de validadores externos monitorean la cadena de origen y llegan a un consenso sobre la validez de una transacción cuando se detecta una llamada. Una vez que se alcanza el consenso, proporcionan pruebas sobre la cadena objetivo. Por lo general, se requiere que los validadores apuesten una cierta cantidad de tokens, que pueden reducirse si se detecta actividad maliciosa. Ejemplos de protocolos que utilizan este método de implementación incluyen Axelar Network y Celer IM.
Otro método de implementación implica el uso de servidores proxy fuera de la cadena. Los proxies fuera de la cadena se utilizan para implementar soluciones como la acumulación optimista. Dentro de un período de tiempo predefinido, estos agentes fuera de la cadena pueden presentar pruebas de fraude y revertir transacciones si es necesario. Por ejemplo, Nomad depende de servidores proxy independientes fuera de la cadena para transmitir encabezados y pruebas criptográficas. ChainLink CCIP, por otro lado, planea aprovechar su red Oracle existente para monitorear y certificar transacciones entre cadenas.
Ventajas y desafíos
Teoría de juegos Una ventaja clave de AMP es la optimización de recursos, ya que el proceso de verificación normalmente no ocurre en la cadena, lo que reduce los requisitos de recursos. Además, estos mecanismos son escalables ya que el mecanismo de consenso permanece sin cambios para varios tipos de cadenas y puede extenderse fácilmente a cadenas de bloques heterogéneas.
Estos mecanismos también enfrentan algunos desafíos. Si la mayoría de los validadores se confabulan, los supuestos de confianza pueden explotarse para robar fondos, lo que requiere el uso de contramedidas como la votación cuadrática y pruebas de fraude. Además, las soluciones basadas en una seguridad optimista introducen complejidades en términos de finalidad y vigencia, ya que los usuarios y las aplicaciones deben esperar a que aparezcan ventanas de fraude para garantizar la validez de las transacciones.
confiar en los humanos
Las soluciones que requieren confiar en entidades humanas también se pueden dividir en dos categorías:
1. Seguridad de la reputación: estas soluciones se basan en la implementación de firmas múltiples, donde múltiples entidades verifican y firman transacciones. Una vez que se alcanza el umbral mínimo, la transacción se considera válida. El supuesto 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, entonces es válida. Algunos ejemplos incluyen Multichain (Anycall V6) y Wormhole. Las vulnerabilidades de los contratos inteligentes aún pueden explotarse, como lo demostró el hackeo de Wormhole a principios de 2022.
2. Independencia: estas soluciones dividen todo el proceso de mensajería 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 pueden coludir. LayerZero es un ejemplo. Los encabezados de los bloques pueden transmitirse a pedido mediante oráculos descentralizados, y las pruebas de las transacciones se envían a través de retransmisiones. Si la prueba coincide con el encabezado del bloque, la transacción se considera válida. Si bien demostrar una coincidencia se basa en código/matemáticas, los participantes deben confiar en que estas entidades pueden seguir siendo independientes. Las aplicaciones creadas en LayerZero pueden elegir sus oráculos y retransmisores (o alojar sus propios oráculos/retransmisores), lo que limita el riesgo de que los oráculos/retransmisores individuales se confabulen. Los usuarios finales deben confiar en que LayerZero, terceros o las propias aplicaciones ejecutan oráculos y retransmisiones de forma independiente y no tienen intenciones maliciosas.
En ambos enfoques, la reputación de las entidades de terceros participantes reduce el incentivo para actuar maliciosamente. Por lo general, son entidades respetadas dentro de las comunidades de validadores y oráculos, y si se comportan de manera maliciosa, enfrentan consecuencias para su reputación y un impacto negativo en sus otras actividades comerciales.
Más allá de los supuestos de confianza: consideraciones adicionales para las soluciones AMP
Al considerar la seguridad y usabilidad de una solución AMP, también debemos considerar detalles más allá de la mecánica básica. Dado que se trata de piezas móviles que pueden cambiar con el tiempo, no las incluimos en la comparación general.
integridad del código
Los ataques recientes han aprovechado errores de codificación, destacando la necesidad de auditorías confiables, recompensas por errores e implementaciones diversas para los clientes. Si todos los validadores (en seguridad económica/optimista/reputacional) ejecutan el mismo cliente (el software utilizado para la validación), esto aumentará la dependencia de una única base de código y reducirá la diversidad de clientes. Por ejemplo, Ethereum depende de múltiples clientes de ejecución como geth, nethermind, erigon, besu y akula. Múltiples implementaciones en múltiples idiomas pueden aumentar la diversidad, sin que ningún cliente domine la red, eliminando así posibles puntos únicos de falla. Tener varios clientes también puede ayudar con la vida, si algunos validadores/firmantes/clientes ligeros se cierran debido a vulnerabilidades/ataques en una implementación específica, los demás seguirán estando disponibles.
Configuración y capacidad de actualización
Los usuarios y desarrolladores deben comprender si los validadores/observadores pueden unirse a la red sin permiso; de lo contrario, la entidad autorizada elegida ocultará la confianza. Las actualizaciones de los contratos inteligentes también pueden introducir errores que provoquen ataques o incluso cambiar las suposiciones de confianza. Se pueden implementar diferentes soluciones para mitigar estos riesgos. Por ejemplo, en la instancia actual, la puerta de enlace de Axelar se puede actualizar según la aprobación del 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 la puerta de enlace. Los contratos principales de Wormhole se pueden actualizar y gestionar a través del sistema de gobernanza en cadena de Wormhole. LayerZero se basa en contratos inteligentes inmutables y bibliotecas inmutables para evitar actualizaciones, pero se pueden implementar nuevas bibliotecas, las dApps que usan la configuración predeterminada obtendrán versiones actualizadas, las dApps con versiones configuradas manualmente deberán configurarse en la nueva versión.
Valor máximo extraíble (MEV)
Diferentes blockchains están sincronizadas mediante un reloj común y tienen diferentes tiempos de finalidad. Por lo tanto, el orden y el momento de ejecución en la cadena objetivo pueden variar de una cadena a otra. En un mundo de cadenas cruzadas, una definición clara de MEV es un desafío. Introduce una compensación entre vivacidad y orden de ejecución. Un canal ordenado garantizará la entrega ordenada de mensajes, pero si un mensaje caduca, el canal se cerrará. Es posible que otra aplicación prefiera no tener que ordenar, pero sin afectar la entrega de otros mensajes.
finalidad de la cadena de origen
Idealmente, una solución AMP debería esperar a que la cadena de origen alcance su finalidad antes de transmitir información de estado desde la cadena de origen a una o más cadenas de destino. Esto garantizará que los bloques de la cadena de origen sean casi imposibles de revertir o cambiar. Sin embargo, para brindar la mejor experiencia de usuario, muchas soluciones brindan mensajería instantánea y hacen suposiciones sobre la confianza relacionada con la finalidad. En este caso, si la cadena de origen sufre una reversión estatal después de enviar mensajes y fondos puente, puede haber situaciones en las que los fondos se gasten dos veces. Las soluciones AMP pueden gestionar este riesgo de varias maneras, como utilizando diferentes supuestos de finalidad para diferentes cadenas, compensando la velocidad y la seguridad en función de cuán descentralizada esté la cadena. La conexión mediante soluciones AMP pone un límite a la cantidad de activos que se pueden unir antes de que la cadena de origen llegue a su fin.
Tendencias y perspectivas de futuro
Seguridad personalizable y agregable
Para servir mejor a los diferentes casos de uso, las soluciones AMP están incentivadas para proporcionar más flexibilidad de desarrollo. Axelar introduce un método para actualizar la mensajería y la validación sin cambiar la lógica de la capa de aplicación. HyperLane V2 presenta módulos que permiten a los desarrolladores elegir entre múltiples opciones, incluida la seguridad económica, la seguridad optimista, la seguridad dinámica y la seguridad híbrida. CelerIM proporciona seguridad optimista adicional además de seguridad financiera. Muchas soluciones esperan un número mínimo predefinido de confirmaciones de bloque en la cadena de origen antes de transmitir un 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 requieren cierta discusión. ¿Pueden las aplicaciones configurar su seguridad, hasta qué punto y qué sucede si una aplicación tiene una arquitectura que no es óptima? Es probable que la concienciación de los usuarios sobre los conceptos básicos detrás de la seguridad sea cada vez más importante. En última instancia, prevemos la agregación y abstracción de soluciones AMP, tal vez en forma de alguna combinación o seguridad "agregada".
La madurez del mecanismo de "código de confianza y matemáticas"
En el objetivo final ideal, la confianza de todos los mensajes entre cadenas se minimizaría mediante el uso de pruebas de conocimiento cero. Ya estamos viendo que se produce este cambio, con proyectos como Polymer Labs y Succinct Labs. Multichain también publicó un documento técnico llamado 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 establecer nuevas conexiones a la red Axelar sin permiso. Por ejemplo, una vez que se desarrollan potentes clientes ligeros y pruebas ZK del estado de Ethereum, los desarrolladores pueden integrarlos fácilmente en la red Axelar para reemplazar o mejorar las conexiones existentes. Celer Network ha anunciado una plataforma de prueba de datos entre cadenas ZK llamada Brevis que permite que las dApps y los contratos inteligentes accedan, calculen y utilicen datos arbitrarios en múltiples cadenas de bloques. Celer aprovecha el circuito de cliente ligero ZK para implementar zkBridge, un activo visible para el usuario que une las redes de prueba Ethereum Goerli y BNB Chain. LayerZero habla en su documentación sobre la posibilidad de agregar nuevas bibliotecas de mensajería a prueba de optimización en el futuro. Nuevos proyectos como Lagrange están explorando la posibilidad de agregar múltiples pruebas de múltiples cadenas de origen, mientras que Herodotus hace posible el almacenamiento de pruebas con 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 es difícil de auditar, y el costo actual de verificación y generación de pruebas es subóptimo. Creemos que a largo plazo, para admitir aplicaciones de cadena cruzada altamente escalables en blockchain, muchas soluciones AMP probablemente combinarán entidades humanas confiables con software verificable por las siguientes razones:
1. Mediante auditorías y recompensas de errores, se puede minimizar la posibilidad de explotación del código. Con el tiempo, será más fácil confiar en estos sistemas, ya que su historial sirve como prueba de seguridad.
2. Se reducirá el coste de generar pruebas ZK. Con más investigación y desarrollo en ZKP, ZK recursivos, agregaciones de pruebas, esquemas de plegado y hardware especializado, esperamos que el tiempo y el costo de la generación y verificación de pruebas disminuyan significativamente, lo que lo convierte en un enfoque más rentable.
3. La cadena de bloques será más amigable para ZK. En el futuro, zkEVM podrá proporcionar pruebas concisas de la validez de la ejecución y las soluciones ligeras basadas en clientes podrán verificar fácilmente la ejecución y el consenso de la cadena de origen. En la fase final de Ethereum, también hay planes para "convertir todo a zk-SNARK", incluido el consenso.
Humanidad, Reputación e Identidad
La seguridad de un sistema complejo como una solución AMP no puede encapsularse en un solo marco y requiere una solución de múltiples capas. Por ejemplo, además de los incentivos financieros, Axelar implementa un mecanismo de votación cuadrático para evitar que el poder de voto se concentre en 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 permisos.
en conclusión
Aprovechando el espíritu abierto de Web3, es posible que veamos un futuro en el que coexistan múltiples enfoques. En la práctica, las aplicaciones pueden optar por utilizar múltiples soluciones de interoperabilidad, ya sea de manera redundante o para permitir a los usuarios mezclar y combinar basándose en compensaciones. Las soluciones punto a punto pueden tener prioridad entre las rutas de "alto tráfico", mientras que los modelos de centro y radio pueden dominar en la cola larga de la cadena. En última instancia, dar forma al panorama de la Web3 conectada depende de nosotros como comunidad de usuarios, constructores y contribuyentes.
referencias
https://forum.cosmos.network/t/ibc-security-advisory-dragonberry/7702
https://polymerlabs.medium.com/the-multi-hop-ibc-upgrade-will-take-ibc-to-ethereum-and-beyond-b4bee43523e
https://cointelegraph.com/news/wormhole-hack-illustrates-danger-of-defi-cross-chain-bridges
https://axelar.network/blog/future-proof-interop-path-adaptability-for-cross-chain-dapps
https://ethresear.ch/t/hashi-a-principled-approach-to-bridges/14725
https://twitter.com/MultichainOrg/status/1613830754458533888?s=20&t=MoDGESqOdcjMQDMFQqzTyQ
https://axelar.network/blog/axelar-virtual-machine-future-of-interoperability
https://twitter.com/CelerNetwork/status/1638330932603109379?s=20
https://axelar.network/blog/axelar-implements-quadratic-voting-with-maeve-upgrade