Bool Network: La solución definitiva de puentes entre cadenas protegidos por Dynamic Hidden Committee (DHC), que introduce la interoperabilidad en el ecosistema de Bitcoin
¿Es posible eliminar los riesgos de colusión y mejorar la seguridad de los puentes entre cadenas sin sacrificar su rendimiento, escalabilidad o aplicabilidad general?
Problemas de seguridad con puentes entre cadenas
Con el desarrollo de un panorama omnichain, los puentes cross-chain se han convertido en una infraestructura crucial en el campo de la Web3. A pesar del estado siempre cambiante de las cadenas públicas, la necesidad de comunicación entre cadenas sigue siendo constante. Para los desarrolladores de dApps, es esencial ampliar su ámbito de negocio a más cadenas y evolucionar de una dApp de una sola cadena a una multicadena. Para los desarrolladores de cadenas públicas, unir Bitcoin y Ethereum para traer activos y atracción a sus propios ecosistemas es una motivación común. Para los usuarios de Web3, el deseo de descentralizar sus activos y moverlos a través de diferentes cadenas sin depender de exchanges centralizados está muy extendido.
Sin embargo, los puentes entre cadenas, como los “camiones de efectivo” entre cadenas, a menudo son el objetivo de los piratas informáticos. En los últimos dos años, casi todos los principales proyectos de puentes entre cadenas han sufrido brechas de seguridad. Entre los diversos tipos de incidentes de seguridad de las criptomonedas, las pérdidas por incidentes de puentes entre cadenas son las más altas, acercándose a los USD 2 mil millones. Por lo tanto, es urgentemente necesario abordar los problemas de seguridad de los puentes entre cadenas y agregar protección a los camiones de efectivo “descapotables”.
Cómo romper el punto muerto
En general, los puentes entre cadenas son susceptibles a dos categorías distintas de incidentes de seguridad. El primero se refiere a las vulnerabilidades del código de los contratos inteligentes, en particular la ausencia de verificación en los contratos de tokens, lo que permite a los actores maliciosos depositar tokens falsificados que pasan desapercibidos. Un control de acceso insuficiente es otro aspecto crítico que puede llevar a la manipulación de la lista de validadores registrada. La segunda categoría abarca el fraude perpetrado por nodos de validación que actúan en connivencia entre sí, el acceso ilícito a claves privadas y la posterior malversación de fondos de cuentas de bloqueo de puentes entre cadenas. Además, los malhechores también pueden ejercer la opción de acuñar monedas falsas para explotar LP y obtener ganancias mal habidas.
La razón principal de lo primero es que la biblioteca de código estándar para construir puentes entre cadenas aún no está madura. Sin embargo, se espera que la acumulación de expansión de la industria conduzca a una reducción gradual de estos problemas. La causa principal de esto último son los defectos inherentes a nivel de diseño de los puentes entre cadenas.
Esencialmente, los puentes entre cadenas abordan el desafío de cómo se puede propagar la información sobre los eventos en una cadena a cadenas remotas desconectadas. El problema puede bifurcarse en dos aspectos críticos, a saber, la transmisión y la verificación. Si bien los eventos entre cadenas pueden ser transmitidos por cualquier persona, la pregunta pertinente sigue siendo ¿cómo la cadena de destino/destino puede validar que tales eventos realmente han ocurrido en la cadena de origen?
Figura 1. Un diagrama intuitivo para comunicaciones entre cadenas
Se pueden categorizar tres tipos de puentes entre cadenas según su mecanismo de verificación: Verificación nativa, Verificación local y Verificación externa.
- La verificación nativa se refiere a la verificación impulsada por el consenso realizada por todos los validadores en la cadena de destino de eventos de la cadena de origen, lograda típicamente mediante el despliegue de un cliente liviano de la cadena de origen en la cadena de destino. Este cliente mantiene y actualiza constantemente el encabezado de los bloques de la cadena de origen, lo que permite la verificación simplificada de pagos (SPV) de eventos en la cadena de origen.
- La verificación local se refiere a la validación directa de transacciones por parte de contrapartes, también conocida como validación peer-to-peer. Un paradigma típico se basa en swaps atómicos utilizando un timelock hash. Dado que los intereses económicos de las dos partes involucradas en la transacción son adversarios, la colusión no es posible.
- La validación externa se refiere a la introducción de un conjunto de testigos externos responsables de verificar mensajes entre cadenas. El conjunto de testigos externos alcanza consenso en las firmas de los eventos entre cadenas, y tras la verificación de la firma por parte de la cadena de destino, el evento se considera confiable.
El gasto elevado asociado con la verificación nativa puede atribuirse en gran medida a dos factores. En primer lugar, el gasto asociado con la verificación en cadena es considerablemente alto, ya que involucrar a un cliente liviano para ejecutar en cadena y realizar SPV de eventos es muy intensivo en recursos. En segundo lugar, el costo de desarrollo para admitir nuevas cadenas puede ser bastante alto, ya que cada compatibilidad con una nueva cadena requiere el desarrollo de al menos un par de clientes livianos. Afortunadamente, con la llegada de la tecnología ZK (Zero-Knowledge), ahora existen soluciones disponibles que mejoran la verificación nativa, mitigando efectivamente los gastos mencionados anteriormente. Sin embargo, incluso con estas optimizaciones, la verificación en cadena requiere al menos una prueba ZK para ser verificada, lo que equivale a un gasto de aproximadamente 500k Gwei, un costo que no es proporcional a la verificación externa que solo requiere una verificación de firma (21k Gwei). En consecuencia, la verificación nativa no tiene una ventaja competitiva en términos de precios para los puentes entre cadenas y no puede lograr verdaderamente un estado “totalmente conectado”.
La implementación de la validación local fue una vez adoptada por prominentes proyectos de Web3, incluidos Celer y Connext. Sin embargo, estos proyectos han alterado su infraestructura y abandonado la validación local como su estrategia preferida. Este cambio ha sido motivado por el hecho de que la validación local presenta una experiencia de transacción inadecuada. A pesar de los extensos esfuerzos de optimización, el usuario aún debe realizar múltiples pasos operativos (como iniciar la transacción y desbloquear el timelock hash), lo que contradice el ideal perfecto de transacciones en blockchain. Además, existe el problema de inactividad de la contraparte o intención maliciosa que puede resultar en fondos congelados para el usuario. Además, la validación local está restringida a intercambios de activos entre cadenas y no es compatible con transacciones de mensajes entre cadenas.
La utilización de la verificación externa en los puentes entre cadenas ofrece numerosas ventajas, como un bajo costo de implementación y mantenimiento, un mínimo sobrecosto entre cadenas, flexibilidad para operar en múltiples y heterogéneas cadenas, y soporte para varios esquemas de mensajería entre cadenas. La mayoría de las iniciativas de puentes entre cadenas actualmente emplean la verificación externa como su solución adoptada. Sin embargo, la integración de la verificación externa introduce nuevas suposiciones de confianza y riesgos adicionales de colusión. La mayoría de los puentes entre cadenas que implementan verificación externa aplican MPC (Multi-Party Computation) para dividir claves privadas de manera que cada nodo de verificación externa tenga una parte única de la clave privada. En comparación con el enfoque MultiSig (Multi-Signature) ordinario, MPC posee una mayor generalidad (sin requisitos para el esquema de firma de la cadena), menores gastos de verificación (solo una firma para verificar en la cadena de destino) y una transferencia de autoridad de firma más conveniente (solo la necesidad de una parte renovada sin cambiar la dirección), entre otras ventajas. A pesar de estos beneficios, la naturaleza centralizada de la verificación externa permanece sin cambios y el riesgo de colusión aún existe.
Entonces, ¿qué tipo de solución entre cadenas se puede emplear para mitigar los riesgos de colusión y mejorar la seguridad de los puentes entre cadenas, sin comprometer su rendimiento, escalabilidad y generalidad?
Propuesta de solución para Bool Network
LayerBase Labs, un equipo de investigación con una larga historia de exploración exhaustiva en el ámbito de las cadenas cruzadas que se remonta a casi cuatro años, ha anunciado el lanzamiento de su último protocolo de puente entre cadenas, Bool Network. En iteraciones anteriores, el equipo había lanzado una serie de productos mínimos viables que nunca han sido ampliamente promocionados. Aprovechando el mecanismo de Comité Oculto Dinámico (DHC), el último producto del equipo se considera una solución completa y sofisticada que ahora está lista para su uso público. Este desarrollo marca un hito crucial en el viaje continuo de LayerBase Labs para avanzar en la tecnología entre cadenas dentro de la industria de las criptomonedas.
La solución entre cadenas ofrecida por Bool Network incorpora técnicas criptográficas de vanguardia, a saber, Prueba de Conocimiento Cero (ZK) y Ambientes de Ejecución Confiados (TEE), que aprovechan la Computación Multi-Partidaria (MPC) para establecer conjuntos de validadores en constante evolución y desconocidos, es decir, DHCs. Esta innovación evita efectivamente los intentos de colusión maliciosa, asegurando una seguridad óptima en el campo entre cadenas.
Para elucidar la noción del “Comité Oculto Dinámico“ en Bool Network, proporcionaremos un ejemplo ilustrativo.
Imaginemos una situación en la que eres un comandante de un ejército que supervisa la custodia segura de 50 graneros con la ayuda de 1000 soldados. ¿Cómo desplegarías a tus soldados?
En caso de que todos los graneros sean igualmente significativos, la táctica óptima sería dividir los 1000 soldados en 50 grupos, cada uno compuesto por 20 soldados, para proteger cada granero.
Sin embargo, este enfoque entraña un peligro. Si más de la mitad de los soldados en un equipo coluden, pueden causar la pérdida de su granero designado y, por lo tanto, poner en peligro la misión general. En otras palabras, si 11 soldados en un equipo conspiran, pueden traicionar su autoridad y tomar el control del granero.
Esto impulsa la implementación de una contra medida para disuadir la conspiración y evitar que los graneros sean comprometidos. La solución es aplicar el concepto de “Comité Oculto Dinámico”.
- Dinámico: Requiere la reformación y reasignación dinámica de soldados en diferentes equipos cada día. Esto permite que cada soldado proteja un granero de manera distinta y trabaje junto a diferentes compañeros de equipo cada día.
- Oculto: La visión de cada soldado está oscurecida y no se les informa qué granero están protegiendo ni quiénes son sus compañeros de equipo.
Los soldados conspiradores no podrían coludir cohesionadamente debido a su ignorancia sobre con quién planear. Incluso si hay conspiradores premeditados, no podrían controlar a otros miembros del equipo ni determinar si los otros participantes pertenecen al mismo equipo.
Consecuentemente, las posibilidades de que los conspiradores coordinen con la mayoría de los 1000 soldados se vuelven prácticamente imposibles, haciendo que la conspiración no sea viable. Al adoptar lo “Dinámico” y “Oculto”, la credibilidad de cada equipo será proporcional a la confiabilidad total de todo el ejército.
Estas estrategias son la esencia de la solución entre cadenas de Bool Network.
TEE — Cegando a cada soldado
Bool Network exige que los nodos en la red utilicen dispositivos con TEE para verificar eventos entre cadenas. Bool Network es un sistema sin permisos y cualquier entidad que posea un dispositivo TEE puede convertirse en un nodo de verificación apostando el token nativo de la red, $BOOL.
TEE significa Ambiente de Ejecución Confiado, que es un entorno de cómputo aislado que se ejecuta en un dispositivo dado, separado del sistema operativo principal, similar a un Enclave. Este aislamiento está impuesto por hardware y la ejecución de programas dentro del TEE está oculta de la percepción e intervención externa, lo que hace que los ataques de piratería sean inviables.
El TEE puede ejecutar aplicaciones altamente seguras, como autenticación biométrica y gestión de pagos seguros. En nuestra vida diaria, el TEE es ubicuo, como se ejemplifica con la verificación de huellas dactilares en dispositivos móviles. Esto asegura que otras aplicaciones en el dispositivo móvil no puedan acceder a la información de la huella dactilar.
Durante la verificación de eventos entre cadenas, los nodos de verificación externos deben participar en un proceso de firma de consenso, lo que significa que las claves privadas deben exponerse a la red, haciéndolas altamente susceptibles a ataques de piratería. Los ataques a los puentes oficiales de Axie Infinity — Ronin Bridge en marzo de 2022 y al puente oficial de la cadena pública Harmony — Horizen Bridge en junio de 2022 fueron causados por piratas informáticos que obtuvieron acceso a las claves privadas del nodo del puente. El uso de TEE para almacenar partes de claves privadas y ejecutar firmas de consenso mejorará significativamente la seguridad, previniendo el robo de claves privadas. Además, Bool Network exige que todas las comunicaciones entre nodos TEE estén completamente encriptadas, lo que hace imposible que los piratas informáticos intercepten cualquier información de comunicación entre nodos.
Ring VRF — Rotación aleatoria para los soldados
Bool Network está diseñada como una herramienta para construir puentes entre cadenas que admiten la creación de puentes específicos de aplicaciones de terceros en la plataforma. Cuando un tercero crea un puente entre cadenas en Bool Network, necesita crear Comités Ocultos Dinámicos (DHC). Si el tercero planea crear un puente entre cadenas que admita 10 cadenas, por ejemplo, debe crear 10 DHC, siendo cada DHC responsable de verificar todos los mensajes entre cadenas enviados a esa cadena.
A medida que aumenta el número de puentes entre cadenas creados en la plataforma, el número de DHC podría aumentar a miles o incluso decenas de miles. Además, los terceros pueden establecer el umbral de firma para los DHC. Los umbrales de firma comunes incluyen 5-de-9, 13-de-19 y 15-de-21.
Es importante tener en cuenta que los miembros de cada DHC no son fijos y están en constante evolución. Los miembros de DHC cooperan para realizar una tarea como llevar a cabo firmas de umbrales MPC usando sus identificaciones temporales, que están representadas por una prueba ZK generada por el protocolo Ring VRF propuesto por Bool Network basado en tecnología ZK. Esto asegura que los miembros de DHC siempre permanezcan anónimos tanto externa como internamente.
En el mismo período, los nodos TEE de diferentes DHC pueden superponerse, y algunos nodos TEE pueden quedar inactivos sin servir a ningún DHC. Estos escenarios están permitidos, pero el protocolo Ring VRF garantiza que cada nodo TEE tenga una oportunidad igual de ser seleccionado de manera probabilística.
Figura 2. Comités Ocultos Dinámicos (DHC) en Bool Network
En esencia, Bool Network ha establecido una caja negra impenetrable mediante el uso de su mecanismo de Comité Oculto Dinámico. Cuando un nodo TEE está en funcionamiento, nadie, incluido el operador del nodo, otros nodos o atacantes externos, puede determinar el estado operativo del nodo, su posición en un DHC específico, qué otros nodos están en el mismo DHC, qué comunicaciones de consenso han ocurrido o qué mensajes se han firmado. Esto es lo que anteriormente se denominaba “desconocible” y “inconsciente”. Dado este contexto, mientras Bool Network en sí sea segura, cada miembro del comité también será seguro. Para que un atacante asegure una alta probabilidad de éxito, debe controlar la mayoría de los nodos en la red de Bool. Sin embargo, debido a que el programa ejecutado en el TEE es a prueba de manipulaciones, los atacantes solo pueden causar fallas en la red y no pueden robar activos en la red.
Cómo evaluar una solución entre cadenas
Aunque la seguridad es el problema más urgente que se debe abordar para los puentes entre cadenas, no es el único criterio para evaluarlos. Crear un nuevo problema al intentar resolver uno existente no constituye una solución genuina.
LayerBase Labs ha estado investigando durante mucho tiempo diversas soluciones de escalado basadas en clientes livianos, incluido el esquema ZK Client. El ZK Client opera sobre el principio fundamental de expandir las capacidades de los clientes livianos mediante el uso de ZK. Esto implica mover la validación de encabezados de bloques y SPV de eventos de la cadena de origen fuera de la cadena, creando una prueba ZK que se enviará a la cadena de destino. Con la única necesidad de validar la prueba ZK, esta solución es suficientemente segura. Sin embargo, su consumo de gas en cadena sigue siendo alto y tanto sus circuitos ZK fuera de cadena como sus clientes livianos en cadena son técnicamente complicados de construir, lo que puede resultar en vulnerabilidades a nivel de código, comprometiendo así la seguridad de los puentes entre cadenas. Además, para evitar la necesidad de que cada cadena despliegue clientes livianos para todas las demás cadenas, esta solución a menudo requiere la introducción de una cadena de retransmisión (ver Figura 3), lo que aumenta la latencia de la transmisión de mensajes entre cadenas al dividir el proceso en dos pasos.
Figura 3. Comparación de la complejidad de desarrollo entre la solución de cliente liviano y la solución de cadena de retransmisión
Actualmente, hay muchos defensores en la industria de la tecnología ZK Client, incluso afirmando que ZK Client es la solución definitiva para los puentes entre cadenas. Nos gustaría enfatizar que la tecnología no es para presumir ni para perseguir tendencias, sino para resolver verdaderamente problemas. Los problemas creados por ZK Client superan con creces los problemas que resuelve.
También hemos estudiado la llamada solución de Ultralight Client de LayerZero, en la que LayerZero ejecuta el cliente liviano fuera de la cadena a través de oráculos para reducir los gastos de gas en cadena. Sin embargo, cuando la responsabilidad de verificación se transfiere de la verificación en la cadena de destino a oráculos fuera de la cadena, ya no es un modelo de verificación nativa sino uno externo, que tiene hipótesis de seguridad para los oráculos fuera de la cadena. En cuanto a la premisa de seguridad de que “Relayer y Oracle son mutuamente independientes” afirmada por LayerZero Labs, simplemente no existe en la realidad, como lo demuestran los experimentos de ataque de L2BEAT Labs.
También notamos la solución de verificación optimista adoptada por Nomad y Celer. Al agregar un rol de desafiante a la verificación externa, la seguridad de m-de-n puede aumentarse con éxito a 1-de-n. Aunque esta solución está bien concebida, su costo es un retraso de aproximadamente 30 minutos, lo que limita su alcance de aplicación.
También encontramos esclarecedor el diseño de Avalanche Bridge. Utiliza nodos TEE como validadores externos para verificar eventos entre cadenas y logra una experiencia entre cadenas eficiente y rentable con un diseño de contrato mínimo. Sin embargo, también vemos que Avalanche Bridge no puede evitar que los nodos TEE internos conspiran ataques, aunque puede almacenar claves privadas de forma segura y evitar ataques externos.
Finalmente, proponemos la solución de Comité Oculto Dinámico para Bool Network. Desde una perspectiva de seguridad, puede evitar los ataques externos de piratas informáticos mientras previene la conspiración interna. En términos de rendimiento y experiencia, la experiencia entre cadenas de Bool Network no sacrifica nada sobre la base de puentes verificados externamente, permaneciendo en el mismo nivel.
Al evaluar un puente entre cadenas, creemos que debe evaluarse de manera integral basándose en el triángulo imposible convencional, ampliado en seis aspectos: Costo, Velocidad, Seguridad, Vitalidad, Generalidad y Escalabilidad.
Costo: El costo de las transacciones entre cadenas radica principalmente en el costo de gas de la cadena. El costo de verificar un mensaje entre cadenas en Bool Network es solo equivalente a una única verificación de firma en cadena, lo que está en línea con los puentes verificados externamente.
Velocidad: Evaluamos únicamente la latencia del puente entre cadenas en sí, sin considerar el problema de la finalidad de las propias cadenas. En este sentido, como no hay cálculos redundantes dentro y fuera de la cadena, y no hay diseño de cadena de retransmisión (que puede causar una verificación redundante de segundo orden), la velocidad entre cadenas de Bool Network también puede alcanzar el nivel definitivo.
Seguridad: Hemos explorado completamente cómo Bool Network puede lograr resistencia a los ataques externos y prevención de conspiraciones internas en los párrafos anteriores.
Vitalidad: Simplemente se refiere a no experimentar bloqueos. Bool Network equipará a cada DHC con uno o más DHC de respaldo al momento de la creación para evitar problemas de disponibilidad causados por más de la mitad de los nodos TEE desconectados en un solo DHC.
Generalidad: Requiere soporte no solo para activos sino también para la transmisión de mensajes arbitrarios entre redes heterogéneas, lo que Bool Network también satisface.
Escalabilidad: ¿Cuánto tiempo tarda un puente entre cadenas en admitir una nueva cadena heterogénea? Bool Network solo necesita desplegar un conjunto de contratos simples para admitir una nueva cadena (que puede completarse en un mes de desarrollo por una sola persona), y ahora hemos completado el soporte para todas las blockchains principales. Además, Bool Network no está limitado por la complejidad de Turing de la cadena y puede admitir cadenas no Turing completas como Bitcoin sin agregar nuevas suposiciones de seguridad.
Se puede resumir que Bool Network es el guerrero HEXAGON entre los puentes entre cadenas.
Figura 4. Hexágono imposible para puentes entre cadenas
Vale la pena mencionar que el documento teórico sobre Bool Network se ha publicado en el principal diario de criptografía IEEE TIFS (enlace: https://ieeexplore.ieee.org/document/9903072), lo que significa el reconocimiento de la solución de Bool Network en la comunidad de criptografía.
Figura 5. El artículo teórico sobre Bool Network ha sido publicado en IEEE Transactions on Information Forensics and Security (TIFS)
Direcciones futuras de desarrollo
Bool Network actualmente proporciona una plataforma de construcción de puentes entre cadenas seguros, lo que permite a cualquier tercero crear aplicaciones omni-cadena basadas en Bool Network. Se convertirá en la infraestructura subyacente más robusta para abrazar la era omni-cadena de Web3.
Mirando desde una perspectiva diferente, Bool Network esencialmente establece un esquema de firma descentralizado que puede verificar tanto mensajes dentro de la cadena como fuera de ella. Esto significa que Bool Network se convertirá en un oráculo de cadena completo seguro y confiable. Además, la red de Ambiente de Ejecución Confiado (TEE) descentralizada construida por Bool Network puede proporcionar servicios de computación de privacidad en el futuro.
Figura 6. La pila de protocolos para Bool Network
Acerca de Bool Network
Bool Network es un protocolo de interoperabilidad entre cadenas sin permisos, totalmente confiable y altamente escalable basado en la computación de múltiples partes (MPC), la prueba de conocimiento cero (ZKP) y el entorno de ejecución confiable (TEE). Propone un esquema de firma descentralizado para facilitar la transmisión de mensajes arbitrarios y las transferencias de activos digitales a través de redes heterogéneas.
Síguenos en las redes sociales:
Website: https://bool.network/
Twitter: https://twitter.com/bool_official
GitHub: https://github.com/boolnetwork
Discord: https://discord.com/invite/DVd4q9qq7a
Telegram: https://t.me/BoolCommunity
