La cadena múltiple es la tendencia de desarrollo futuro, y la búsqueda de la escalabilidad ha llevado a Ethereum a la construcción de la tecnología Rollup. En el cambio a cadenas de bloques modulares, una vez más se ha prestado atención a Lisk. Y en un futuro no muy lejano, escucharemos rumores sobre acumulaciones específicas de aplicaciones, L3 y cadenas soberanas. Pero todo esto tendrá el costo de la fragmentación, y los puentes de cadena cruzada actuales a menudo tienen una funcionalidad limitada y dependen de firmantes confiables para la seguridad.
Entonces, ¿cómo será finalmente el Web3 conectado? Creemos que los puentes de cadena cruzada eventualmente evolucionarán hacia mensajes de cadena cruzada o protocolos de "Mensajería arbitraria" (AMP) para desbloquear nuevos escenarios de aplicaciones, permitiendo que las aplicaciones pasen mensajes arbitrarios entre la cadena de origen y la cadena de destino. También seremos testigos del surgimiento de un "panorama de mecanismo de confianza", en el que los constructores harán varias concesiones entre usabilidad, complejidad y seguridad.
Cada solución AMP necesita implementar dos funciones clave:
Verificación: capacidad de verificar la validez de los mensajes de la cadena de origen en la cadena de destino
Liveness: la capacidad de pasar información de la cadena de origen a la cadena de destino
Desafortunadamente, la verificación 100% sin confianza no es realista, los usuarios deben elegir confiar en el código, la teoría del juego, los humanos (o entidades) o una combinación de estos, dependiendo de si la verificación es dentro o fuera de la cadena.
En este documento, dividimos verticalmente el dominio de interoperabilidad general en mecanismos basados en la confianza y arquitecturas basadas en la integración.
Mecanismo de confianza:
Confíe en el código y las matemáticas: para estas soluciones, existe una prueba en cadena que cualquiera puede verificar. Estas soluciones generalmente se basan en clientes ligeros para verificar el consenso de la cadena de origen en la cadena de destino o verificar la validez de la transición de estado de la cadena de origen en la cadena de destino. La verificación a través de clientes ligeros puede mejorar la eficiencia a través de pruebas de conocimiento cero, comprimiendo cálculos arbitrariamente largos para realizarlos fuera de línea, al tiempo que proporciona una verificación simple en cadena para probar los resultados de los cálculos.
Teoría del juego de confianza: cuando un usuario/aplicación necesita confiar en un tercero o en una red de terceros para garantizar la autenticidad de una transacción, se involucran suposiciones de confianza adicionales. La seguridad de estos mecanismos se puede mejorar empleando redes sin permiso y teoría de juegos como incentivos económicos y seguridad optimista.
Confianza en los humanos: estas soluciones se basan en la honestidad o la independencia de una mayoría de validadores, que comunican información diferente. Además de confiar en el consenso de las dos cadenas interactivas, también debe confiar en un tercero. En este caso, el único riesgo es la reputación de las entidades participantes. Una transacción se considera válida si suficientes entidades participantes están de acuerdo en que es válida.
Vale la pena señalar que todas las soluciones requieren confianza en el código y en los humanos hasta cierto punto. Cualquier solución con código defectuoso puede ser explotada por piratas informáticos, y cada solución tiene algún elemento humano en la configuración, las actualizaciones o el mantenimiento de la base del código.
Arquitectura integrada:
Modelo punto a punto: se debe establecer un canal de comunicación dedicado entre cada cadena de origen y cadena de destino.
Modelo de concentrador central: se debe establecer un canal de comunicación con el concentrador central para lograr la interconexión con todas las demás cadenas de bloques conectadas al concentrador.
El modelo peer-to-peer es relativamente difícil de escalar porque cada cadena de bloques conectada requiere un canal de comunicación emparejado. El desarrollo de estos canales puede ser un desafío para las cadenas de bloques con diferentes consensos y marcos. Sin embargo, los puentes emparejados ofrecen más flexibilidad para personalizar la configuración si se desea. Los enfoques híbridos también son posibles, como el enrutamiento de múltiples saltos a través de retransmisiones que utilizan el protocolo Inter-Blockchain Communication (IBC), que elimina la necesidad de una comunicación directa entre pares, pero presenta más complejidades en términos de seguridad, latencia y costo.
Código de confianza y matemáticas
Para confiar solo en el código/matemáticas para las suposiciones de confianza, se pueden usar clientes ligeros para verificar el consenso de la cadena de origen en la cadena de destino. Los clientes/nodos ligeros son software que se conectan a nodos completos para interactuar con la cadena de bloques. Los clientes ligeros en la cadena de destino suelen almacenar un historial (en orden) de los encabezados de bloque de la cadena de origen, que es suficiente para verificar las transacciones. Un proxy fuera de la cadena (como un repetidor) supervisa los eventos en la cadena de origen, genera pruebas criptográficas de inclusión y las reenvía junto con los encabezados de los bloques a los clientes ligeros de la cadena de destino. Dado que los clientes ligeros almacenan encabezados de bloque secuencialmente, cada uno con un hash raíz de Merkle que se puede usar para probar el estado, pueden verificar transacciones. Aquí hay una descripción general de las principales características de este enfoque:
seguridad
Los supuestos de confianza se introducen durante la inicialización de los clientes ligeros. Al crear un nuevo cliente ligero, se inicializará en un encabezado de bloque desde una altura específica en la otra cadena. Sin embargo, existe la posibilidad de que los encabezados de bloque proporcionados sean incorrectos, lo que permite engañar a los clientes ligeros con encabezados de bloque falsificados. Una vez que se inicializa un cliente ligero, no se introducen más suposiciones de confianza. Sin embargo, vale la pena señalar que este proceso de inicialización se basa en una suposición de confianza débil, ya que cualquiera puede verificarlo. Además, existe una suposición de vitalidad para la transmisión continua de información del relé.
implementar
La implementación de clientes ligeros depende de la disponibilidad de las primitivas criptográficas requeridas para la autenticación. Si se conecta el mismo tipo de cadenas, lo que significa que comparten el mismo marco de aplicación y algoritmo de consenso, las implementaciones de clientes ligeros en ambos extremos serán las mismas. Por ejemplo, todas las cadenas basadas en SDK de Cosmos usan el protocolo Inter-Blockchain Communication (IBC). Por otro lado, las implementaciones como los clientes ligeros dependen del soporte de las primitivas criptográficas requeridas para la autenticación. Si se conecta el mismo tipo de cadenas, es decir, comparten el mismo marco de aplicación y el mismo algoritmo de consenso, entonces las implementaciones de clientes ligeros en ambos lados serán las mismas. Por ejemplo, el protocolo Inter-Blockchain Communication (IBC) se usa para todas las cadenas basadas en Cosmos SDK. 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 marco de aplicación Substrate del ecosistema Polkadot a través de IBC. Esto requiere un cliente ligero Tendermint en la cadena Substrate y un cliente ligero "fornido" 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 ser costoso porque las escrituras en la cadena de bloques son costosas. Además, el uso intensivo de recursos con verificadores dinámicos es un desafío importante. Puede ser costoso ejecutar clientes ligeros emparejados en todas las cadenas porque las escrituras en la cadena de bloques son costosas. Además, para cadenas con conjuntos de validadores dinámicos (como Ethereum), no es factible ejecutar clientes ligeros.
La escalabilidad es otro desafío. La implementación de clientes ligeros varía según la arquitectura de la cadena, lo que dificulta escalar y conectar diferentes ecosistemas.
Las vulnerabilidades del código son un riesgo potencial porque los errores en el código pueden generar vulnerabilidades. Por ejemplo, la violación de la cadena BNB de octubre de 2022 reveló una falla de seguridad crítica que afectaba a todas las cadenas habilitadas para IBC.
Para abordar el costo y la practicidad de ejecutar clientes ligeros por pares en todas las cadenas, se pueden emplear soluciones alternativas como las pruebas de conocimiento cero (ZK) para eliminar la necesidad de confianza de terceros.
Pruebas de conocimiento cero como solución para la confianza de terceros
Las pruebas de conocimiento cero se pueden utilizar para verificar la validez de las transiciones de estado de la cadena de origen en la cadena de destino. En comparación con la realización de todo el cálculo en la cadena, las pruebas ZK solo realizan la parte de verificación del cálculo en la cadena, mientras que el cálculo real ocurre fuera de la cadena. Este enfoque permite una verificación más rápida y eficiente que volver a ejecutar el cálculo original. Algunos ejemplos incluyen Polymer Labs'; Polymer ZK-IBC; y Succinct Labs'; Telepatía. Polymer está desarrollando IBC de múltiples saltos para mejorar la conectividad y reducir la cantidad de conexiones emparejadas requeridas.
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 una configuración confiable, incluida la creación de claves iniciales utilizadas para generar pruebas utilizadas en la verificación. La clave es destruir el secreto del evento de configuración para evitar que las transacciones sean autenticadas por falsificación. Una vez que se completa la configuración de confianza, no se introducen más suposiciones de confianza. Además, los marcos ZK más nuevos (como Halo y Halo; 2;) eliminan por completo la necesidad de una configuración confiable.
implementar
Hay una variedad de esquemas de prueba ZK, como SNARK, STARK, VPD y SNARG, y SNARK es actualmente el más utilizado. Diferentes marcos de prueba de SNARK, como Groth;16, Plonk, Marlin, Halo y Halo;2; ofrecen compensaciones en términos de tamaño de prueba, tiempo de prueba, tiempo de verificación, requisitos de memoria y requisitos de configuración de confianza. También surgieron pruebas ZK recursivas, lo que permite que la carga de trabajo de la prueba se distribuya en varias computadoras en lugar de una sola. Para generar pruebas de validez, se deben implementar las siguientes funciones básicas: verificar el esquema de firma utilizado por un validador, almacenar pruebas de la clave pública del validador en el compromiso del conjunto de validadores almacenado en la cadena y rastrear el conjunto de validadores, que puede cambiar con frecuencia.
desafío
La implementación de varios esquemas de firma en zkSNARK requiere la implementación de operaciones aritméticas y de curvas elípticas complejas fuera del dominio, lo cual no es trivial y puede requerir diferentes implementaciones según el marco y el consenso de las diferentes cadenas. La auditoría de circuitos ZK es una tarea desafiante y propensa a errores. Los desarrolladores deben estar familiarizados con lenguajes específicos de dominio, como Circom, Cairo y Noir, o implementar circuitos directamente, los cuales pueden ser un desafío y pueden ralentizar la adopción. Si el tiempo y el esfuerzo resultan ser muy altos, es posible que solo los equipos dedicados y el hardware dedicado lo manejen, lo que podría conducir a la centralización. Los tiempos de generación de prueba más largos también causan retrasos. Técnicas como la computación incrementalmente 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. Los tiempos de verificación y las cargas de trabajo más largos aumentarán los costos en cadena.
Teoría del juego de confianza
Los protocolos de interoperabilidad basados en la teoría de juegos se pueden dividir a grandes rasgos en dos categorías, según cómo incentivan el comportamiento honesto de las entidades participantes:
La primera categoría es un mecanismo de seguridad económica en el que múltiples actores externos (como validadores) cooperan para llegar a un consenso para determinar el estado actualizado de la cadena fuente. Para convertirse en un validador, los participantes deben apostar una cierta cantidad de tokens, que pueden reducirse en caso de actividad maliciosa. En una configuración sin permiso, cualquiera puede acumular apuestas y convertirse en validador. Además, se brindan incentivos económicos, como recompensas en bloque, a los validadores que siguen el protocolo para garantizar incentivos económicos por un comportamiento honesto. Sin embargo, si la cantidad potencial robada excede la cantidad apostada, los participantes pueden coludirse para robar fondos. Ejemplos de protocolos que utilizan mecanismos de seguridad económicos incluyen: Axelar y Celer IM.
La segunda categoría son los mecanismos de seguridad optimistas, donde la solución se basa en la suposición de que solo un pequeño número de participantes de la cadena de bloques son honestos y obedecen las reglas del protocolo. En este enfoque, un participante honesto actúa como garantía. Por ejemplo, una solución óptima permite que cualquier persona presente pruebas de fraude. Aunque existe un incentivo financiero, un observador honesto puede pasar por alto una transacción fraudulenta. Los paquetes acumulativos optimistas también utilizan este mecanismo. Nomad y ChainLink CCIP son ejemplos de protocolos que utilizan mecanismos de seguridad optimistas. En el caso de Nomad, los observadores pudieron probar el fraude, aunque están en la lista blanca al momento de escribir este artículo. ChainLink CCIP planea utilizar una red antifraude que consiste en una red distribuida de oráculos para detectar actividades maliciosas, aunque se desconoce la implementación de la red antifraude de CCIP.
seguridad
En términos de seguridad, ambos mecanismos se basan en la participación sin permiso de verificadores y observadores para garantizar la validez de la teoría del juego. En un mecanismo de seguridad económica, los fondos son más vulnerables si la cantidad apostada es inferior a la cantidad que podría robarse. Por otro lado, en los mecanismos de seguridad optimistas, la suposición de confianza minoritaria puede explotarse si nadie presenta una prueba de fraude, o si los observadores de permisos se ven comprometidos o eliminados. Por el contrario, los mecanismos de seguridad económica dependen menos de la vitalidad 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 grupo de validadores externos monitorea la cadena de origen y llega a un consenso sobre la validez de una transacción cuando se detecta una invocación. Una vez que se alcanza el consenso, proporcionan pruebas en la cadena de destino. 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 usan este método de implementación incluyen Axelar Network y Celer IM.
Otro método de implementación implica el uso de proxies fuera de la cadena. Los proxies fuera de la cadena se utilizan para implementar soluciones optimistas similares a Rollups. Dentro de una ventana de tiempo predefinida, estos proxies fuera de la cadena pueden enviar pruebas de fraude y revertir transacciones si es necesario. Por ejemplo, Nomad se basa en proxies independientes fuera de la cadena para transmitir encabezados y pruebas criptográficas. Por otro lado, ChainLink CCIP planea aprovechar su red existente de oráculos para monitorear y dar fe de las transacciones entre cadenas.
Fortalezas y Desafíos
Una ventaja clave de las soluciones AMP de teoría de juegos es la optimización de recursos, ya que el proceso de verificación suele estar fuera de la cadena, lo que reduce los requisitos de recursos. Además, estos mecanismos son escalables ya que el mecanismo de consenso sigue siendo el mismo para varios tipos de cadenas y se puede extender fácilmente a cadenas de bloques heterogéneas.
También hay varios desafíos asociados con estos mecanismos. Si la mayoría de los validadores se confabulan, las suposiciones de confianza pueden explotarse para robar fondos, lo que requiere contramedidas como la votación cuadrática y las pruebas de fraude. Además, las soluciones basadas en la seguridad optimista introducen complejidades en términos de finalidad y vitalidad, ya que los usuarios y las aplicaciones deben esperar ventanas fraudulentas para garantizar la validez de las transacciones.
Confía en los humanos
Las soluciones que requieren confianza en las entidades humanas también se pueden dividir en dos categorías:
Seguridad de reputación: estas soluciones se basan en implementaciones de firmas múltiples, donde varias entidades verifican y firman 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, entonces esa transacción es válida. Lo único que está en riesgo aquí es la reputación de las entidades involucradas. Algunos ejemplos incluyen; Multichain (Anycall V;6;) y Wormhole. Las vulnerabilidades aún pueden existir debido a las vulnerabilidades de los contratos inteligentes, como lo demostró el hackeo de Wormhole a principios de 2022.
Independencia: estas soluciones dividen todo el proceso de mensajería en dos partes y dependen de diferentes entidades independientes para administrar los dos procesos. La suposición aquí es que estas dos entidades son independientes entre sí y no pueden coludirse. LayerZero es un ejemplo. Los encabezados de bloque se transmiten bajo demanda a través de oráculos distribuidos y las pruebas de transacción se envían a través de repetidores. Si la prueba coincide con el encabezado, la transacción se considera válida. Si bien probar una coincidencia se basa en código/matemáticas, los participantes deben confiar en que estas entidades se mantienen independientes y no tienen intenciones maliciosas. Las aplicaciones creadas en ;LayerZero; pueden elegir sus oráculos y retransmisiones (o alojar sus propios oráculos/retransmisiones), lo que limita el riesgo de oráculos/retransmisiones individuales. Los usuarios finales deben confiar en que LayerZero, terceros o la propia aplicación ejecutan oráculos y retransmisiones de forma independiente, sin malas intenciones.
En ambos enfoques, la reputación de las entidades de terceros participantes disuade el comportamiento malicioso. Suelen ser entidades muy respetadas en la comunidad de validadores y oráculos, y si se comportan maliciosamente, corren el riesgo de dañar su reputación y tener un impacto negativo en otras actividades comerciales.
Consideraciones adicionales para soluciones AMP
Al considerar la seguridad y la facilidad de uso de una solución AMP, también debemos tener en cuenta los detalles más allá de la mecánica básica. Dado que estos son componentes que pueden cambiar con el tiempo, no los incluimos en la comparación general.
integridad del código
Hacks recientes han explotado errores de código, destacando la necesidad de una auditoría robusta, recompensas de errores e implementaciones de clientes diversas. Si todos los verificadores (en seguridad económica/optimista/de reputación) ejecutan el mismo cliente (software para verificación), aumenta la dependencia de un solo código base y reduce la diversidad de clientes. Por ejemplo, Ethereum depende de varios clientes de ejecución como geth, netermind, erigon, besu, akula. Múltiples implementaciones en varios idiomas pueden aumentar la diversidad, sin que un solo cliente domine la red, lo que elimina un posible punto único de falla. Tener varios clientes también puede ayudar a mantener la actividad en caso de que un pequeño número de validadores/firmantes/clientes ligeros falle debido a un error/ataque en una implementación en particular.
Configuración y capacidad de actualización
Los usuarios y desarrolladores necesitan saber si los validadores/observadores pueden unirse a la red sin permiso, de lo contrario, las entidades que elijan el permiso ocultarán la confianza. Las actualizaciones de los contratos inteligentes también pueden introducir vulnerabilidades que pueden provocar ataques y posiblemente incluso cambiar los supuestos 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, pero requiere la aprobación del comité fuera de línea (umbral de 4/8); sin embargo, en un futuro cercano, Axelar planea requerir que todos los validadores aprueben colectivamente cualquier actualización de la puerta de enlace. Los contratos principales de Wormhole se pueden actualizar y administrar a través del sistema de gobierno en cadena de Wormhole. LayerZero se basa en contratos inteligentes inmutables y bibliotecas inmutables para evitar cualquier actualización, pero se pueden enviar nuevas bibliotecas, las dapps que establecen la configuración predeterminada obtendrán versiones más nuevas, las dapps que configuran manualmente la versión deben configurarla en la nueva versión.
Valor Máximo Extraíble (MEV)
Las diferentes cadenas de bloques no están sincronizadas por un reloj común y tienen diferentes tiempos de finalización. Por lo tanto, el orden de ejecución y el tiempo en la cadena de destino pueden variar de una cadena a otra. En un mundo de cadenas cruzadas, MEV es difícil de definir claramente. Introduce una compensación entre la vitalidad y el orden de ejecución. Un canal ordenado garantizará la entrega de mensajes en orden, pero si se agota el tiempo de espera de un mensaje, el canal se cerrará. Otra aplicación puede preferir no realizar pedidos, pero la entrega de otros mensajes no se ve afectada.
certeza de la cadena de origen
Idealmente, las soluciones de AMP deberían esperar a que la cadena de origen llegue a su fin antes de transmitir la información de estado de la cadena de origen a una o más cadenas de destino. Esto asegurará que los bloques en la cadena de origen difícilmente puedan revertirse o cambiarse. Sin embargo, muchas soluciones brindan mensajería instantánea y hacen suposiciones de confianza sobre la finalidad para brindar la mejor experiencia de usuario. En este caso, si la cadena de origen sufre una reversión de estado después de que se entrega el mensaje y se pasa el activo del puente, puede dar lugar a situaciones como el gasto doble de los fondos del puente. Las soluciones de AMP pueden gestionar este riesgo de varias maneras, por ejemplo, estableciendo diferentes suposiciones de finalidad para diferentes cadenas dependiendo de cuán descentralizada esté la cadena, o haciendo concesiones entre velocidad y seguridad. Los puentes que utilizan soluciones AMP pueden establecer límites en la cantidad de activos puenteados antes de que la cadena de origen llegue a su fin.
Tendencias y perspectivas de futuro Seguridad personalizable y acoplable
Para atender mejor los diversos casos de uso, las soluciones AMP tienen incentivos para brindar más flexibilidad a los desarrolladores. Axelar presenta un método para permitir la escalabilidad de 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, como seguridad económica, seguridad optimista, seguridad dinámica y seguridad híbrida. CelerIM proporciona seguridad optimista adicional además de la seguridad económica. Muchas soluciones esperan un número mínimo predefinido de confirmaciones de bloque en la cadena de origen antes de entregar un mensaje. LayerZero permite a los desarrolladores actualizar estos parámetros. Esperamos que algunas soluciones de AMP continúen ofreciendo más flexibilidad, pero estas opciones de diseño requieren cierta discusión. ¿Deberían las aplicaciones ser capaces de configurar su seguridad, en qué medida y qué sucede si las aplicaciones están diseñadas con un diseño subóptimo? Es probable que la conciencia del usuario sobre los conceptos fundamentales detrás de la seguridad sea cada vez más importante. En última instancia, prevemos la agregación y la abstracción de las soluciones AMP, posiblemente en forma de alguna forma de composición o seguridad "complementaria".
La madurez del mecanismo “Trust Code and Math”
En una etapa final ideal, todos los mensajes entre cadenas se minimizarán mediante el uso de pruebas de conocimiento cero (ZK). Hemos visto surgir proyectos similares como Polymer Labs y Succinct Labs. Multichain también publicó un libro blanco de zkRouter sobre interoperabilidad a través de pruebas ZK. Con la máquina virtual Axelar recientemente anunciada, los desarrolladores pueden aprovechar el amplificador intercadena para establecer nuevas conexiones a la red Axelar sin permiso. Por ejemplo, una vez que se desarrollan fuertes clientes ligeros y pruebas ZK para el estado de Ethereum, los desarrolladores pueden integrarlos fácilmente en la red Axelar para reemplazar o mejorar las conexiones existentes. Celer Network anunció Brevis, una plataforma de prueba de datos de cadena cruzada ZK que permite que dApps y contratos inteligentes accedan, calculen y utilicen datos arbitrarios en múltiples cadenas de bloques. Celer implementó un activo zkBridge orientado al usuario utilizando el circuito de cliente ligero ZK para la cadena cruzada entre la red de prueba Ethereum Goerli y la red de prueba BNB Chain. LayerZero analiza en su documentación la posibilidad de agregar nuevas bibliotecas de mensajes 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 fuentes, 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 se basan en diferentes marcos y mecanismos de consenso.
ZK es una tecnología relativamente nueva y compleja que es difícil de auditar, y los costos actuales de verificación y generación de pruebas no son óptimos. Creemos que, a largo plazo, para admitir aplicaciones de cadenas cruzadas altamente escalables en cadenas de bloques, muchas soluciones de AMP probablemente combinarán software verificable con personas y entidades confiables porque:
A través de la auditoría y las recompensas por errores, se puede minimizar la posibilidad de explotación del código. Con el tiempo, será más fácil confiar en estos sistemas a medida que su historial se convierta en prueba de su seguridad.
Se reducirá el costo de generar pruebas ZK. Con más investigación y desarrollo en ZKP, ZKP recursivos, agregación de pruebas, esquemas de plegado y hardware especializado, esperamos que el costo de tiempo de generación y verificación de pruebas disminuya sustancialmente, lo que lo convierte en un enfoque más rentable.
La cadena de bloques apoyará más a ZK. En el futuro, zkEVM podrá proporcionar pruebas sucintas 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 fuente. En la etapa final de Ethereum, también está previsto "zk-SNARK todo", incluido el mecanismo de consenso.
Credenciales humanas, reputación e identidad
La seguridad de un sistema complejo como una solución AMP no se puede encapsular en un solo marco y requiere una solución de varias capas. Por ejemplo, además de los incentivos económicos, Axelar implementa un mecanismo de votación cuadrático para evitar la concentración del poder de voto entre un subconjunto de nodos y promover la descentralización. Otras pruebas humanas, reputaciones e identidades también pueden complementar los mecanismos de configuración y permisos.
en conclusión
En el espíritu abierto de Web3, podemos ver un futuro pluralista donde coexisten múltiples enfoques. De hecho, una aplicación puede optar por utilizar múltiples soluciones de interoperabilidad, ya sea de forma redundante o para que el usuario elija una combinación basada en compensaciones. Entre las rutas de "alto tráfico", se pueden priorizar las soluciones punto a punto, mientras que los modelos hub-and-spoke pueden dominar la cola larga de la cadena. En última instancia, nosotros, como comunidad de usuarios, constructores y colaboradores, daremos forma a la forma básica de Web3 Internet.
Enlace original
Ver originales
El contenido es solo de referencia, no una solicitud u oferta. No se proporciona asesoramiento fiscal, legal ni de inversión. Consulte el Descargo de responsabilidad para obtener más información sobre los riesgos.
¿Cómo resuelve el problema de la confianza en la interoperabilidad una interpretación profunda de los protocolos de mensajería arbitrarios?
Autor original: Shi Khai Wei, Raghav Agarwal
Compilación original: Kxp, BlockBeats
Introducción
La cadena múltiple es la tendencia de desarrollo futuro, y la búsqueda de la escalabilidad ha llevado a Ethereum a la construcción de la tecnología Rollup. En el cambio a cadenas de bloques modulares, una vez más se ha prestado atención a Lisk. Y en un futuro no muy lejano, escucharemos rumores sobre acumulaciones específicas de aplicaciones, L3 y cadenas soberanas. Pero todo esto tendrá el costo de la fragmentación, y los puentes de cadena cruzada actuales a menudo tienen una funcionalidad limitada y dependen de firmantes confiables para la seguridad.
Entonces, ¿cómo será finalmente el Web3 conectado? Creemos que los puentes de cadena cruzada eventualmente evolucionarán hacia mensajes de cadena cruzada o protocolos de "Mensajería arbitraria" (AMP) para desbloquear nuevos escenarios de aplicaciones, permitiendo que las aplicaciones pasen mensajes arbitrarios entre la cadena de origen y la cadena de destino. También seremos testigos del surgimiento de un "panorama de mecanismo de confianza", en el que los constructores harán varias concesiones entre usabilidad, complejidad y seguridad.
Cada solución AMP necesita implementar dos funciones clave:
Desafortunadamente, la verificación 100% sin confianza no es realista, los usuarios deben elegir confiar en el código, la teoría del juego, los humanos (o entidades) o una combinación de estos, dependiendo de si la verificación es dentro o fuera de la cadena.
En este documento, dividimos verticalmente el dominio de interoperabilidad general en mecanismos basados en la confianza y arquitecturas basadas en la integración.
Mecanismo de confianza:
Confíe en el código y las matemáticas: para estas soluciones, existe una prueba en cadena que cualquiera puede verificar. Estas soluciones generalmente se basan en clientes ligeros para verificar el consenso de la cadena de origen en la cadena de destino o verificar la validez de la transición de estado de la cadena de origen en la cadena de destino. La verificación a través de clientes ligeros puede mejorar la eficiencia a través de pruebas de conocimiento cero, comprimiendo cálculos arbitrariamente largos para realizarlos fuera de línea, al tiempo que proporciona una verificación simple en cadena para probar los resultados de los cálculos.
Teoría del juego de confianza: cuando un usuario/aplicación necesita confiar en un tercero o en una red de terceros para garantizar la autenticidad de una transacción, se involucran suposiciones de confianza adicionales. La seguridad de estos mecanismos se puede mejorar empleando redes sin permiso y teoría de juegos como incentivos económicos y seguridad optimista.
Confianza en los humanos: estas soluciones se basan en la honestidad o la independencia de una mayoría de validadores, que comunican información diferente. Además de confiar en el consenso de las dos cadenas interactivas, también debe confiar en un tercero. En este caso, el único riesgo es la reputación de las entidades participantes. Una transacción se considera válida si suficientes entidades participantes están de acuerdo en que es válida.
Vale la pena señalar que todas las soluciones requieren confianza en el código y en los humanos hasta cierto punto. Cualquier solución con código defectuoso puede ser explotada por piratas informáticos, y cada solución tiene algún elemento humano en la configuración, las actualizaciones o el mantenimiento de la base del código.
Arquitectura integrada:
Modelo punto a punto: se debe establecer un canal de comunicación dedicado entre cada cadena de origen y cadena de destino.
Modelo de concentrador central: se debe establecer un canal de comunicación con el concentrador central para lograr la interconexión con todas las demás cadenas de bloques conectadas al concentrador.
El modelo peer-to-peer es relativamente difícil de escalar porque cada cadena de bloques conectada requiere un canal de comunicación emparejado. El desarrollo de estos canales puede ser un desafío para las cadenas de bloques con diferentes consensos y marcos. Sin embargo, los puentes emparejados ofrecen más flexibilidad para personalizar la configuración si se desea. Los enfoques híbridos también son posibles, como el enrutamiento de múltiples saltos a través de retransmisiones que utilizan el protocolo Inter-Blockchain Communication (IBC), que elimina la necesidad de una comunicación directa entre pares, pero presenta más complejidades en términos de seguridad, latencia y costo.
Código de confianza y matemáticas
Para confiar solo en el código/matemáticas para las suposiciones de confianza, se pueden usar clientes ligeros para verificar el consenso de la cadena de origen en la cadena de destino. Los clientes/nodos ligeros son software que se conectan a nodos completos para interactuar con la cadena de bloques. Los clientes ligeros en la cadena de destino suelen almacenar un historial (en orden) de los encabezados de bloque de la cadena de origen, que es suficiente para verificar las transacciones. Un proxy fuera de la cadena (como un repetidor) supervisa los eventos en la cadena de origen, genera pruebas criptográficas de inclusión y las reenvía junto con los encabezados de los bloques a los clientes ligeros de la cadena de destino. Dado que los clientes ligeros almacenan encabezados de bloque secuencialmente, cada uno con un hash raíz de Merkle que se puede usar para probar el estado, pueden verificar transacciones. Aquí hay una descripción general de las principales características de este enfoque:
seguridad
Los supuestos de confianza se introducen durante la inicialización de los clientes ligeros. Al crear un nuevo cliente ligero, se inicializará en un encabezado de bloque desde una altura específica en la otra cadena. Sin embargo, existe la posibilidad de que los encabezados de bloque proporcionados sean incorrectos, lo que permite engañar a los clientes ligeros con encabezados de bloque falsificados. Una vez que se inicializa un cliente ligero, no se introducen más suposiciones de confianza. Sin embargo, vale la pena señalar que este proceso de inicialización se basa en una suposición de confianza débil, ya que cualquiera puede verificarlo. Además, existe una suposición de vitalidad para la transmisión continua de información del relé.
implementar
La implementación de clientes ligeros depende de la disponibilidad de las primitivas criptográficas requeridas para la autenticación. Si se conecta el mismo tipo de cadenas, lo que significa que comparten el mismo marco de aplicación y algoritmo de consenso, las implementaciones de clientes ligeros en ambos extremos serán las mismas. Por ejemplo, todas las cadenas basadas en SDK de Cosmos usan el protocolo Inter-Blockchain Communication (IBC). Por otro lado, las implementaciones como los clientes ligeros dependen del soporte de las primitivas criptográficas requeridas para la autenticación. Si se conecta el mismo tipo de cadenas, es decir, comparten el mismo marco de aplicación y el mismo algoritmo de consenso, entonces las implementaciones de clientes ligeros en ambos lados serán las mismas. Por ejemplo, el protocolo Inter-Blockchain Communication (IBC) se usa para todas las cadenas basadas en Cosmos SDK. 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 marco de aplicación Substrate del ecosistema Polkadot a través de IBC. Esto requiere un cliente ligero Tendermint en la cadena Substrate y un cliente ligero "fornido" 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 ser costoso porque las escrituras en la cadena de bloques son costosas. Además, el uso intensivo de recursos con verificadores dinámicos es un desafío importante. Puede ser costoso ejecutar clientes ligeros emparejados en todas las cadenas porque las escrituras en la cadena de bloques son costosas. Además, para cadenas con conjuntos de validadores dinámicos (como Ethereum), no es factible ejecutar clientes ligeros.
La escalabilidad es otro desafío. La implementación de clientes ligeros varía según la arquitectura de la cadena, lo que dificulta escalar y conectar diferentes ecosistemas.
Las vulnerabilidades del código son un riesgo potencial porque los errores en el código pueden generar vulnerabilidades. Por ejemplo, la violación de la cadena BNB de octubre de 2022 reveló una falla de seguridad crítica que afectaba a todas las cadenas habilitadas para IBC.
Para abordar el costo y la practicidad de ejecutar clientes ligeros por pares en todas las cadenas, se pueden emplear soluciones alternativas como las pruebas de conocimiento cero (ZK) para eliminar la necesidad de confianza de terceros.
Pruebas de conocimiento cero como solución para la confianza de terceros
Las pruebas de conocimiento cero se pueden utilizar para verificar la validez de las transiciones de estado de la cadena de origen en la cadena de destino. En comparación con la realización de todo el cálculo en la cadena, las pruebas ZK solo realizan la parte de verificación del cálculo en la cadena, mientras que el cálculo real ocurre fuera de la cadena. Este enfoque permite una verificación más rápida y eficiente que volver a ejecutar el cálculo original. Algunos ejemplos incluyen Polymer Labs'; Polymer ZK-IBC; y Succinct Labs'; Telepatía. Polymer está desarrollando IBC de múltiples saltos para mejorar la conectividad y reducir la cantidad de conexiones emparejadas requeridas.
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 una configuración confiable, incluida la creación de claves iniciales utilizadas para generar pruebas utilizadas en la verificación. La clave es destruir el secreto del evento de configuración para evitar que las transacciones sean autenticadas por falsificación. Una vez que se completa la configuración de confianza, no se introducen más suposiciones de confianza. Además, los marcos ZK más nuevos (como Halo y Halo; 2;) eliminan por completo la necesidad de una configuración confiable.
implementar
Hay una variedad de esquemas de prueba ZK, como SNARK, STARK, VPD y SNARG, y SNARK es actualmente el más utilizado. Diferentes marcos de prueba de SNARK, como Groth;16, Plonk, Marlin, Halo y Halo;2; ofrecen compensaciones en términos de tamaño de prueba, tiempo de prueba, tiempo de verificación, requisitos de memoria y requisitos de configuración de confianza. También surgieron pruebas ZK recursivas, lo que permite que la carga de trabajo de la prueba se distribuya en varias computadoras en lugar de una sola. Para generar pruebas de validez, se deben implementar las siguientes funciones básicas: verificar el esquema de firma utilizado por un validador, almacenar pruebas de la clave pública del validador en el compromiso del conjunto de validadores almacenado en la cadena y rastrear el conjunto de validadores, que puede cambiar con frecuencia.
desafío
La implementación de varios esquemas de firma en zkSNARK requiere la implementación de operaciones aritméticas y de curvas elípticas complejas fuera del dominio, lo cual no es trivial y puede requerir diferentes implementaciones según el marco y el consenso de las diferentes cadenas. La auditoría de circuitos ZK es una tarea desafiante y propensa a errores. Los desarrolladores deben estar familiarizados con lenguajes específicos de dominio, como Circom, Cairo y Noir, o implementar circuitos directamente, los cuales pueden ser un desafío y pueden ralentizar la adopción. Si el tiempo y el esfuerzo resultan ser muy altos, es posible que solo los equipos dedicados y el hardware dedicado lo manejen, lo que podría conducir a la centralización. Los tiempos de generación de prueba más largos también causan retrasos. Técnicas como la computación incrementalmente 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. Los tiempos de verificación y las cargas de trabajo más largos aumentarán los costos en cadena.
Teoría del juego de confianza
Los protocolos de interoperabilidad basados en la teoría de juegos se pueden dividir a grandes rasgos en dos categorías, según cómo incentivan el comportamiento honesto de las entidades participantes:
La primera categoría es un mecanismo de seguridad económica en el que múltiples actores externos (como validadores) cooperan para llegar a un consenso para determinar el estado actualizado de la cadena fuente. Para convertirse en un validador, los participantes deben apostar una cierta cantidad de tokens, que pueden reducirse en caso de actividad maliciosa. En una configuración sin permiso, cualquiera puede acumular apuestas y convertirse en validador. Además, se brindan incentivos económicos, como recompensas en bloque, a los validadores que siguen el protocolo para garantizar incentivos económicos por un comportamiento honesto. Sin embargo, si la cantidad potencial robada excede la cantidad apostada, los participantes pueden coludirse para robar fondos. Ejemplos de protocolos que utilizan mecanismos de seguridad económicos incluyen: Axelar y Celer IM.
La segunda categoría son los mecanismos de seguridad optimistas, donde la solución se basa en la suposición de que solo un pequeño número de participantes de la cadena de bloques son honestos y obedecen las reglas del protocolo. En este enfoque, un participante honesto actúa como garantía. Por ejemplo, una solución óptima permite que cualquier persona presente pruebas de fraude. Aunque existe un incentivo financiero, un observador honesto puede pasar por alto una transacción fraudulenta. Los paquetes acumulativos optimistas también utilizan este mecanismo. Nomad y ChainLink CCIP son ejemplos de protocolos que utilizan mecanismos de seguridad optimistas. En el caso de Nomad, los observadores pudieron probar el fraude, aunque están en la lista blanca al momento de escribir este artículo. ChainLink CCIP planea utilizar una red antifraude que consiste en una red distribuida de oráculos para detectar actividades maliciosas, aunque se desconoce la implementación de la red antifraude de CCIP.
seguridad
En términos de seguridad, ambos mecanismos se basan en la participación sin permiso de verificadores y observadores para garantizar la validez de la teoría del juego. En un mecanismo de seguridad económica, los fondos son más vulnerables si la cantidad apostada es inferior a la cantidad que podría robarse. Por otro lado, en los mecanismos de seguridad optimistas, la suposición de confianza minoritaria puede explotarse si nadie presenta una prueba de fraude, o si los observadores de permisos se ven comprometidos o eliminados. Por el contrario, los mecanismos de seguridad económica dependen menos de la vitalidad 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 grupo de validadores externos monitorea la cadena de origen y llega a un consenso sobre la validez de una transacción cuando se detecta una invocación. Una vez que se alcanza el consenso, proporcionan pruebas en la cadena de destino. 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 usan este método de implementación incluyen Axelar Network y Celer IM.
Otro método de implementación implica el uso de proxies fuera de la cadena. Los proxies fuera de la cadena se utilizan para implementar soluciones optimistas similares a Rollups. Dentro de una ventana de tiempo predefinida, estos proxies fuera de la cadena pueden enviar pruebas de fraude y revertir transacciones si es necesario. Por ejemplo, Nomad se basa en proxies independientes fuera de la cadena para transmitir encabezados y pruebas criptográficas. Por otro lado, ChainLink CCIP planea aprovechar su red existente de oráculos para monitorear y dar fe de las transacciones entre cadenas.
Fortalezas y Desafíos
Una ventaja clave de las soluciones AMP de teoría de juegos es la optimización de recursos, ya que el proceso de verificación suele estar fuera de la cadena, lo que reduce los requisitos de recursos. Además, estos mecanismos son escalables ya que el mecanismo de consenso sigue siendo el mismo para varios tipos de cadenas y se puede extender fácilmente a cadenas de bloques heterogéneas.
También hay varios desafíos asociados con estos mecanismos. Si la mayoría de los validadores se confabulan, las suposiciones de confianza pueden explotarse para robar fondos, lo que requiere contramedidas como la votación cuadrática y las pruebas de fraude. Además, las soluciones basadas en la seguridad optimista introducen complejidades en términos de finalidad y vitalidad, ya que los usuarios y las aplicaciones deben esperar ventanas fraudulentas para garantizar la validez de las transacciones.
Confía en los humanos
Las soluciones que requieren confianza en las entidades humanas también se pueden dividir en dos categorías:
Seguridad de reputación: estas soluciones se basan en implementaciones de firmas múltiples, donde varias entidades verifican y firman 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, entonces esa transacción es válida. Lo único que está en riesgo aquí es la reputación de las entidades involucradas. Algunos ejemplos incluyen; Multichain (Anycall V;6;) y Wormhole. Las vulnerabilidades aún pueden existir debido a las vulnerabilidades de los contratos inteligentes, como lo demostró el hackeo de Wormhole a principios de 2022.
Independencia: estas soluciones dividen todo el proceso de mensajería en dos partes y dependen de diferentes entidades independientes para administrar los dos procesos. La suposición aquí es que estas dos entidades son independientes entre sí y no pueden coludirse. LayerZero es un ejemplo. Los encabezados de bloque se transmiten bajo demanda a través de oráculos distribuidos y las pruebas de transacción se envían a través de repetidores. Si la prueba coincide con el encabezado, la transacción se considera válida. Si bien probar una coincidencia se basa en código/matemáticas, los participantes deben confiar en que estas entidades se mantienen independientes y no tienen intenciones maliciosas. Las aplicaciones creadas en ;LayerZero; pueden elegir sus oráculos y retransmisiones (o alojar sus propios oráculos/retransmisiones), lo que limita el riesgo de oráculos/retransmisiones individuales. Los usuarios finales deben confiar en que LayerZero, terceros o la propia aplicación ejecutan oráculos y retransmisiones de forma independiente, sin malas intenciones.
En ambos enfoques, la reputación de las entidades de terceros participantes disuade el comportamiento malicioso. Suelen ser entidades muy respetadas en la comunidad de validadores y oráculos, y si se comportan maliciosamente, corren el riesgo de dañar su reputación y tener un impacto negativo en otras actividades comerciales.
Consideraciones adicionales para soluciones AMP
Al considerar la seguridad y la facilidad de uso de una solución AMP, también debemos tener en cuenta los detalles más allá de la mecánica básica. Dado que estos son componentes que pueden cambiar con el tiempo, no los incluimos en la comparación general.
integridad del código
Hacks recientes han explotado errores de código, destacando la necesidad de una auditoría robusta, recompensas de errores e implementaciones de clientes diversas. Si todos los verificadores (en seguridad económica/optimista/de reputación) ejecutan el mismo cliente (software para verificación), aumenta la dependencia de un solo código base y reduce la diversidad de clientes. Por ejemplo, Ethereum depende de varios clientes de ejecución como geth, netermind, erigon, besu, akula. Múltiples implementaciones en varios idiomas pueden aumentar la diversidad, sin que un solo cliente domine la red, lo que elimina un posible punto único de falla. Tener varios clientes también puede ayudar a mantener la actividad en caso de que un pequeño número de validadores/firmantes/clientes ligeros falle debido a un error/ataque en una implementación en particular.
Configuración y capacidad de actualización
Los usuarios y desarrolladores necesitan saber si los validadores/observadores pueden unirse a la red sin permiso, de lo contrario, las entidades que elijan el permiso ocultarán la confianza. Las actualizaciones de los contratos inteligentes también pueden introducir vulnerabilidades que pueden provocar ataques y posiblemente incluso cambiar los supuestos 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, pero requiere la aprobación del comité fuera de línea (umbral de 4/8); sin embargo, en un futuro cercano, Axelar planea requerir que todos los validadores aprueben colectivamente cualquier actualización de la puerta de enlace. Los contratos principales de Wormhole se pueden actualizar y administrar a través del sistema de gobierno en cadena de Wormhole. LayerZero se basa en contratos inteligentes inmutables y bibliotecas inmutables para evitar cualquier actualización, pero se pueden enviar nuevas bibliotecas, las dapps que establecen la configuración predeterminada obtendrán versiones más nuevas, las dapps que configuran manualmente la versión deben configurarla en la nueva versión.
Valor Máximo Extraíble (MEV)
Las diferentes cadenas de bloques no están sincronizadas por un reloj común y tienen diferentes tiempos de finalización. Por lo tanto, el orden de ejecución y el tiempo en la cadena de destino pueden variar de una cadena a otra. En un mundo de cadenas cruzadas, MEV es difícil de definir claramente. Introduce una compensación entre la vitalidad y el orden de ejecución. Un canal ordenado garantizará la entrega de mensajes en orden, pero si se agota el tiempo de espera de un mensaje, el canal se cerrará. Otra aplicación puede preferir no realizar pedidos, pero la entrega de otros mensajes no se ve afectada.
certeza de la cadena de origen
Idealmente, las soluciones de AMP deberían esperar a que la cadena de origen llegue a su fin antes de transmitir la información de estado de la cadena de origen a una o más cadenas de destino. Esto asegurará que los bloques en la cadena de origen difícilmente puedan revertirse o cambiarse. Sin embargo, muchas soluciones brindan mensajería instantánea y hacen suposiciones de confianza sobre la finalidad para brindar la mejor experiencia de usuario. En este caso, si la cadena de origen sufre una reversión de estado después de que se entrega el mensaje y se pasa el activo del puente, puede dar lugar a situaciones como el gasto doble de los fondos del puente. Las soluciones de AMP pueden gestionar este riesgo de varias maneras, por ejemplo, estableciendo diferentes suposiciones de finalidad para diferentes cadenas dependiendo de cuán descentralizada esté la cadena, o haciendo concesiones entre velocidad y seguridad. Los puentes que utilizan soluciones AMP pueden establecer límites en la cantidad de activos puenteados antes de que la cadena de origen llegue a su fin.
Tendencias y perspectivas de futuro Seguridad personalizable y acoplable
Para atender mejor los diversos casos de uso, las soluciones AMP tienen incentivos para brindar más flexibilidad a los desarrolladores. Axelar presenta un método para permitir la escalabilidad de 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, como seguridad económica, seguridad optimista, seguridad dinámica y seguridad híbrida. CelerIM proporciona seguridad optimista adicional además de la seguridad económica. Muchas soluciones esperan un número mínimo predefinido de confirmaciones de bloque en la cadena de origen antes de entregar un mensaje. LayerZero permite a los desarrolladores actualizar estos parámetros. Esperamos que algunas soluciones de AMP continúen ofreciendo más flexibilidad, pero estas opciones de diseño requieren cierta discusión. ¿Deberían las aplicaciones ser capaces de configurar su seguridad, en qué medida y qué sucede si las aplicaciones están diseñadas con un diseño subóptimo? Es probable que la conciencia del usuario sobre los conceptos fundamentales detrás de la seguridad sea cada vez más importante. En última instancia, prevemos la agregación y la abstracción de las soluciones AMP, posiblemente en forma de alguna forma de composición o seguridad "complementaria".
La madurez del mecanismo “Trust Code and Math”
En una etapa final ideal, todos los mensajes entre cadenas se minimizarán mediante el uso de pruebas de conocimiento cero (ZK). Hemos visto surgir proyectos similares como Polymer Labs y Succinct Labs. Multichain también publicó un libro blanco de zkRouter sobre interoperabilidad a través de pruebas ZK. Con la máquina virtual Axelar recientemente anunciada, los desarrolladores pueden aprovechar el amplificador intercadena para establecer nuevas conexiones a la red Axelar sin permiso. Por ejemplo, una vez que se desarrollan fuertes clientes ligeros y pruebas ZK para el estado de Ethereum, los desarrolladores pueden integrarlos fácilmente en la red Axelar para reemplazar o mejorar las conexiones existentes. Celer Network anunció Brevis, una plataforma de prueba de datos de cadena cruzada ZK que permite que dApps y contratos inteligentes accedan, calculen y utilicen datos arbitrarios en múltiples cadenas de bloques. Celer implementó un activo zkBridge orientado al usuario utilizando el circuito de cliente ligero ZK para la cadena cruzada entre la red de prueba Ethereum Goerli y la red de prueba BNB Chain. LayerZero analiza en su documentación la posibilidad de agregar nuevas bibliotecas de mensajes 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 fuentes, 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 se basan en diferentes marcos y mecanismos de consenso.
ZK es una tecnología relativamente nueva y compleja que es difícil de auditar, y los costos actuales de verificación y generación de pruebas no son óptimos. Creemos que, a largo plazo, para admitir aplicaciones de cadenas cruzadas altamente escalables en cadenas de bloques, muchas soluciones de AMP probablemente combinarán software verificable con personas y entidades confiables porque:
A través de la auditoría y las recompensas por errores, se puede minimizar la posibilidad de explotación del código. Con el tiempo, será más fácil confiar en estos sistemas a medida que su historial se convierta en prueba de su seguridad.
Se reducirá el costo de generar pruebas ZK. Con más investigación y desarrollo en ZKP, ZKP recursivos, agregación de pruebas, esquemas de plegado y hardware especializado, esperamos que el costo de tiempo de generación y verificación de pruebas disminuya sustancialmente, lo que lo convierte en un enfoque más rentable.
La cadena de bloques apoyará más a ZK. En el futuro, zkEVM podrá proporcionar pruebas sucintas 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 fuente. En la etapa final de Ethereum, también está previsto "zk-SNARK todo", incluido el mecanismo de consenso.
Credenciales humanas, reputación e identidad
La seguridad de un sistema complejo como una solución AMP no se puede encapsular en un solo marco y requiere una solución de varias capas. Por ejemplo, además de los incentivos económicos, Axelar implementa un mecanismo de votación cuadrático para evitar la concentración del poder de voto entre un subconjunto de nodos y promover la descentralización. Otras pruebas humanas, reputaciones e identidades también pueden complementar los mecanismos de configuración y permisos.
en conclusión
En el espíritu abierto de Web3, podemos ver un futuro pluralista donde coexisten múltiples enfoques. De hecho, una aplicación puede optar por utilizar múltiples soluciones de interoperabilidad, ya sea de forma redundante o para que el usuario elija una combinación basada en compensaciones. Entre las rutas de "alto tráfico", se pueden priorizar las soluciones punto a punto, mientras que los modelos hub-and-spoke pueden dominar la cola larga de la cadena. En última instancia, nosotros, como comunidad de usuarios, constructores y colaboradores, daremos forma a la forma básica de Web3 Internet.
Enlace original