HyperChains

¿Qué son las HyperChains en el mundo cripto?

Las HyperChains son redes blockchain personalizables basadas en pruebas de conocimiento cero, construidas con ZK Stack y diseñadas para conectarse a la ZKsync Elastic Network, un ecosistema más amplio.

En pocas palabras, una HyperChain es una blockchain específica para una aplicación o un ecosistema que puede procesar transacciones de forma independiente y, al mismo tiempo, conectarse con otras cadenas compatibles mediante una infraestructura compartida de conocimiento cero.

El término HyperChains se utilizó ampliamente en debates anteriores sobre ZKsync para describir cadenas soberanas basadas en ZK y construidas con ZK Stack.

La documentación oficial actual suele utilizar términos como ZKsync Chains, ZK Chains y Elastic Network, pero la idea fundamental sigue siendo parecida.

La documentación oficial de ZK Stack lo describe como un framework modular para lanzar blockchains interoperables basadas en ZK.

Una HyperChain no es un token, una wallet, un bridge ni una plataforma de trading.

Es un concepto de arquitectura blockchain para crear rollups, validiums, volitions u otros entornos de ejecución basados en ZK e interconectados.

Las HyperChains son importantes porque están diseñadas para resolver a la vez dos grandes problemas del sector cripto.

El primero es la escalabilidad, ya que una blockchain puede congestionarse cuando muchos usuarios y aplicaciones compiten por espacio en los bloques.

El segundo es la fragmentación, porque muchas cadenas independientes pueden dividir a los usuarios, la liquidez, los activos y la atención de los desarrolladores.

HyperChains y ZK Stack

ZK Stack es el conjunto de herramientas que se utiliza para crear HyperChains.

La descripción general oficial de ZK Stack señala que es un framework modular y accesible para desarrolladores que permite personalizar y desplegar blockchains interoperables basadas en ZK.

Esto importa porque una HyperChain no pretende ser una cadena independiente cualquiera, sin estándares compartidos.

La idea es que siga un framework común para poder mantener la compatibilidad con otras cadenas de la misma red.

Los desarrolladores pueden utilizar ZK Stack para personalizar partes importantes de una cadena, como la disponibilidad de datos, la secuenciación, el token de gas, los ajustes de privacidad y el modo de funcionamiento.

Esto distingue a las HyperChains del simple despliegue de un contrato inteligente en una cadena existente.

Un proyecto que lance una HyperChain puede controlar una mayor parte del entorno de ejecución.

Ese control puede abarcar la política de comisiones, el filtrado de transacciones, los permisos de la cadena, los tokens base personalizados y las opciones de disponibilidad de datos.

Al mismo tiempo, la cadena puede beneficiarse de las pruebas ZK y de la interoperabilidad con otras cadenas de ZK Stack.

Esta combinación de personalización y conexión es el principal motivo por el que las HyperChains se convirtieron en una idea importante para escalar.

HyperChains frente a ZKsync Chains

HyperChains y ZKsync Chains son términos estrechamente relacionados.

Los materiales anteriores del ecosistema solían utilizar HyperChains para describir cadenas ZK personalizadas construidas con ZK Stack.

La documentación oficial actual suele referirse a estas cadenas como ZKsync Chains o ZK Chains.

La documentación de ZKsync Chains explica que cualquiera puede desarrollar y desplegar cadenas ZKsync, pero que deben utilizar ZK Stack para que sean de confianza y plenamente interoperables dentro de Elastic Network.

Esto significa que HyperChains debería entenderse como el nombre anterior o popular de la misma línea general de diseño.

Un glosario puede seguir utilizando HyperChains porque muchos usuarios cripto, investigadores y artículos antiguos reconocen ese término.

Sin embargo, quienes busquen información técnica actual también deberían consultar ZKsync Chains, ZK Chains, Elastic Network y ZK Stack.

Este detalle sobre la nomenclatura es importante porque los términos cripto cambian rápidamente a medida que maduran los protocolos.

El concepto no desapareció cuando la documentación empezó a utilizar términos más precisos.

La idea evolucionó hasta convertirse en una red más amplia de cadenas interoperables basadas en ZK.

Por qué son importantes las HyperChains

Las HyperChains son importantes porque pretenden que la escalabilidad de blockchain resulte menos fragmentada para usuarios y desarrolladores.

Muchos ecosistemas cripto tienen cadenas, bridges, tokens de gas y pools de liquidez independientes.

Esto ofrece una mala experiencia de usuario porque puede ser necesario transferir fondos mediante un bridge, cambiar de red, comprar distintos tokens de comisión y hacer un seguimiento manual de los activos en varios lugares.

Las HyperChains están diseñadas para que varias cadenas funcionen más como una única red conectada.

El anuncio oficial de Elastic Chain describe la visión de Elastic Chain como una red creciente de rollups ZK protegida por las matemáticas e interoperable de forma nativa, con una experiencia de usuario uniforme.

Para los usuarios, el objetivo es facilitar el movimiento entre cadenas.

Para los desarrolladores, es ofrecer más libertad para crear entornos de ejecución personalizados sin aislar a los usuarios del resto del ecosistema.

Para las aplicaciones, el objetivo es disponer de espacio en bloques dedicado y, al mismo tiempo, acceder a usuarios y liquidez compartidos.

Para la infraestructura cripto, el objetivo es escalar horizontalmente añadiendo más cadenas, en lugar de concentrar toda la actividad en una sola capa de ejecución.

Cómo funcionan las HyperChains

Las HyperChains combinan la ejecución independiente de cada cadena con una infraestructura compartida de pruebas de conocimiento cero e interoperabilidad entre cadenas.

Cada HyperChain puede procesar sus propias transacciones y mantener su propio estado.

Según su configuración, la cadena puede enviar pruebas de validez o datos de liquidación a Ethereum o a una infraestructura de red compartida.

Las pruebas de conocimiento cero permiten demostrar que las transiciones de estado se han calculado correctamente sin exigir a Ethereum que vuelva a ejecutar todas las transacciones.

Esta es la ventaja básica de escalabilidad de la tecnología de rollups ZK.

La documentación de ZKsync Era explica que ZKsync Era ejecuta transacciones off-chain, las agrupa en lotes y genera una prueba de validez concisa que se envía a Ethereum.

Las HyperChains amplían esta idea: en lugar de un único rollup, crean una red de numerosas cadenas compatibles basadas en ZK.

En lugar de que una sola cadena atienda a todas las aplicaciones, muchas cadenas pueden funcionar en paralelo.

La interoperabilidad permite después que esas cadenas se comuniquen, transfieran activos y admitan acciones entre cadenas.

Este diseño pretende aumentar la capacidad sin que los usuarios se sientan atrapados en islas aisladas.

HyperChains y las pruebas de conocimiento cero

Las pruebas de conocimiento cero son fundamentales para las HyperChains.

Una prueba de conocimiento cero puede demostrar que un cálculo es válido sin revelar todos los detalles subyacentes y sin obligar a otra cadena a repetir el cálculo completo.

En los sistemas rollup, esto permite procesar muchas transacciones off-chain y demostrar el resultado en una capa de liquidación.

En las HyperChains, las pruebas ZK ayudan a proporcionar seguridad e interoperabilidad entre numerosas cadenas.

Si cada cadena puede demostrar sus transiciones de estado, otras partes de la red pueden verificarlas de forma más eficiente.

Por eso, la visión de Elastic Network suele describir el sistema como protegido por las matemáticas.

La expresión significa que las pruebas de validez, y no solo la confianza social o los operadores de bridges, ayudan a verificar el estado entre cadenas.

Las pruebas ZK no eliminan todos los riesgos.

Siguen dependiendo de circuitos correctos, criptografía sólida, contratos inteligentes seguros, datos disponibles, funcionamiento honesto de la infraestructura necesaria y un comportamiento seguro de los usuarios.

Sin embargo, pueden reducir la necesidad de confiar en un custodio de bridge independiente para cada movimiento entre cadenas.

HyperChains y Elastic Network

Elastic Network es la red más amplia que conecta las cadenas de ZK Stack.

La página oficial Elastic Network Chains enumera varias cadenas del ecosistema ZKsync y señala que los ID de cadena y su disponibilidad pueden cambiar con el tiempo.

Esto es importante porque las HyperChains no consisten únicamente en lanzar una cadena personalizada.

Se trata de crear una red de cadenas que pueda crecer a medida que aumenta la demanda.

El término «elástica» indica que el sistema puede ampliarse añadiendo más cadenas cuando se necesita capacidad adicional.

En lugar de que una cadena se convierta en un cuello de botella, distintas aplicaciones o comunidades pueden operar en sus propias cadenas.

Al mismo tiempo, la interoperabilidad compartida pretende reducir las dificultades para pasar de una a otra.

Esto difiere de un ecosistema donde cada cadena tiene su propio bridge aislado, su propio flujo de wallet y su propia liquidez.

Elastic Network pretende que muchas cadenas se perciban como partes de un entorno más amplio.

Esta es la principal promesa a largo plazo de las HyperChains.

HyperChains y ZKsync Era

ZKsync Era es importante porque fue la primera cadena lanzada con ZK Stack y se convirtió en el primer miembro de Elastic Network.

La documentación oficial de ZKsync Era indica que se trata de un rollup Layer 2 construido con ZK Stack para escalar Ethereum mediante pruebas de conocimiento cero.

En el contexto de las HyperChains, ZKsync Era puede considerarse el primer ejemplo operativo de la arquitectura más amplia.

Muestra cómo la ejecución basada en ZK puede admitir contratos inteligentes, abstracción de cuentas y liquidación alineada con Ethereum.

Otras cadenas de ZK Stack pueden ampliar después la red para atender casos de uso más especializados.

Una cadena de videojuegos, pagos, privacidad, empresa, DeFi o específica para una aplicación puede adoptar distintas compensaciones de diseño.

Estas pueden incluir la disponibilidad de datos, la elección del token de comisión, el modelo de secuenciación y los permisos.

Esta modularidad es uno de los motivos por los que las HyperChains resultan atractivas para quienes desarrollan proyectos.

Pueden construir soluciones para las necesidades de sus aplicaciones sin empezar desde cero con una infraestructura blockchain completamente distinta.

HyperChains e interoperabilidad

La interoperabilidad permite que distintas cadenas se comuniquen y realicen transacciones entre sí.

La documentación oficial de ZKsync Connect explica que la interoperabilidad entre cadenas de ZKsync es posible gracias a contratos inteligentes que verifican transacciones entre cadenas mediante pruebas de Merkle.

Esto permite a las cadenas observar mensajes, enviar activos, ejecutar llamadas, agrupar llamadas remotas y gestionar smart accounts entre cadenas.

Para los usuarios, la interoperabilidad es importante porque puede reducir la necesidad de transferir activos manualmente mediante bridges y cambiar de red.

Para los desarrolladores, es importante porque las aplicaciones pueden utilizar más fácilmente activos o acciones de otras cadenas.

Para la liquidez, es importante porque puede reducir la fragmentación.

En un entorno cripto fragmentado, un token puede tener distintas versiones en diferentes cadenas, cada una con sus propios pools de liquidez.

En un entorno más conectado, los usuarios deberían poder transferir valor e instrucciones entre cadenas con menos fricción.

Las HyperChains están diseñadas para ofrecer esta experiencia conectada.

El objetivo no es únicamente contar con muchas cadenas rápidas, sino con muchas cadenas rápidas que puedan colaborar.

HyperChains y Gateway

Gateway forma parte de la infraestructura que respalda la agregación de pruebas y la interoperabilidad de las cadenas de ZKsync.

La documentación oficial de ZKsync Chains describe Gateway como un centro de agregación de pruebas y una infraestructura fundamental para la interoperabilidad entre cadenas de ZKsync.

La agregación de pruebas es importante porque verificar muchas pruebas por separado en Ethereum puede resultar caro.

Al agregar pruebas, la red puede reducir la sobrecarga de verificación y admitir más cadenas de forma eficiente.

Esto es importante para las HyperChains, porque una red con muchas cadenas necesita una forma escalable de liquidar y verificar la actividad.

Si cada cadena tuviera que liquidar completamente sus operaciones por separado, sin agregación compartida, los costes y la complejidad podrían crecer rápidamente.

Gateway está diseñado para facilitar una comunicación más rápida entre cadenas y reducir los costes relacionados con las pruebas.

Sin embargo, los usuarios deben tener en cuenta que las funciones de interoperabilidad pueden desplegarse por fases.

Algunas funciones pueden estar activas, otras disponibles en pruebas locales y otras depender de futuras actualizaciones del protocolo.

Es importante consultar la documentación actual antes de desarrollar o transferir fondos por una ruta concreta entre cadenas.

HyperChains y disponibilidad de datos

La disponibilidad de datos es una de las decisiones de diseño más importantes para las HyperChains.

Significa que los datos necesarios para reconstruir y verificar el estado de la cadena están disponibles para los usuarios, validadores u otros participantes que los necesiten.

La documentación oficial de ZKsync Chains explica que la disponibilidad de datos afecta a la seguridad, la privacidad, la velocidad de las transacciones y el coste.

Una HyperChain puede elegir un modo similar al de los rollups ZK, en el que los cambios de estado se publican en Ethereum.

Esto ofrece propiedades más sólidas de seguridad heredada y resistencia a la censura, pero puede resultar más caro.

Una HyperChain también puede utilizar una disponibilidad de datos similar a la de un validium, en la que los datos se controlan fuera de Ethereum.

Esto puede reducir los costes y mejorar la privacidad, pero introduce supuestos adicionales sobre la disponibilidad de los datos.

Si los datos necesarios dejan de estar disponibles, es posible que los usuarios no puedan reconstruir el estado o retirar sus activos de forma segura por las vías habituales.

Por eso, los usuarios no deberían suponer que todas las HyperChains tienen el mismo perfil de seguridad.

La elección de disponibilidad de datos modifica el modelo de riesgo.

HyperChains como rollups, validiums y volitions

Las HyperChains pueden configurarse con distintos modos de funcionamiento.

Un rollup ZK publica suficientes datos en Ethereum para que los usuarios puedan verificar y recuperar el estado utilizando Ethereum como capa de disponibilidad de datos.

Un validium mantiene los datos fuera de Ethereum, pero sigue utilizando pruebas de validez para verificar la corrección de las transiciones de estado.

Un modelo volition puede permitir distintas opciones de disponibilidad de datos para diferentes transacciones o cuentas.

El anuncio de Elastic Chain describe la red como un ecosistema que incluye ZK Chains, como rollups, validiums y volitions.

Estos términos son importantes porque definen las compensaciones entre confianza y coste de una HyperChain.

El modo rollup puede ser más caro, pero ofrece una mayor disponibilidad de datos desde el punto de vista de la seguridad.

El modo validium puede ser más barato y privado, pero depende más de la disponibilidad de datos off-chain.

El modo volition ofrece flexibilidad, pero añade complejidad.

Los usuarios y desarrolladores deberían comprobar el modo concreto antes de dar por hecho que una HyperChain es segura, barata, privada o resistente a la censura.

HyperChains y los tokens base personalizados

Las HyperChains pueden admitir tokens base personalizados para pagar las comisiones de las transacciones.

La documentación oficial de ZKsync Chains explica que ZK Stack admite tokens ERC-20 como tokens base para pagar las comisiones de la cadena, en lugar de utilizar únicamente ETH.

Esto puede resultar útil para una cadena específica de una aplicación que quiera tener su propio modelo económico.

Por ejemplo, una cadena comunitaria podría querer que los usuarios paguen las comisiones con su token del ecosistema.

Una cadena centrada en pagos podría preferir que las comisiones se pagasen con un activo de valor estable.

Una cadena de videojuegos podría abstraer o patrocinar las comisiones para que los usuarios no tengan que preocuparse por el gas.

Los tokens base personalizados pueden mejorar la experiencia de usuario, pero también conllevan riesgos.

Si el token de comisión pierde liquidez o se vuelve volátil, la experiencia de usuario de la cadena puede deteriorarse.

Si el token tiene una economía débil, el diseño de las comisiones puede volverse inestable.

Los desarrolladores deberían elegir un token base según las necesidades reales de los usuarios, no únicamente por motivos de marca.

HyperChains y secuenciadores

Un secuenciador ordena las transacciones antes de que se demuestren y liquiden.

Las HyperChains pueden utilizar distintos modelos de secuenciación en función de sus necesidades.

La documentación de ZKsync Chains enumera opciones como la secuenciación centralizada o descentralizada, las colas prioritarias y los protocolos de secuenciación externos.

Un secuenciador centralizado puede ofrecer confirmaciones rápidas y una operación sencilla.

También puede generar supuestos de confianza, ya que un único operador tiene un control considerable sobre el orden y la disponibilidad.

Un secuenciador descentralizado puede reducir la confianza depositada en un operador, pero quizá añada latencia y complejidad operativa.

Una cola prioritaria puede ayudar a proteger a los usuarios frente a la censura al permitir que las transacciones se envíen por una vía alternativa.

La secuenciación es importante porque el orden de las transacciones influye en la experiencia del usuario, el riesgo de MEV, la resistencia a la censura y la equidad de las aplicaciones.

Al evaluar una HyperChain, los usuarios deberían preguntarse quién opera el secuenciador y qué mecanismos alternativos existen si falla o censura transacciones.

HyperChains y appchains

Las HyperChains suelen describirse como una infraestructura de tipo appchain.

Una appchain es una blockchain diseñada para una aplicación, comunidad, modelo de negocio o ecosistema concreto, en lugar de atender a todos los casos de uso posibles.

Las appchains pueden ser útiles porque las aplicaciones con mucha demanda pueden necesitar capacidad de procesamiento dedicada, comisiones personalizadas, ajustes especiales de privacidad o participación controlada.

Una cadena de propósito general puede congestionarse cuando muchas aplicaciones no relacionadas compiten por los recursos.

Una HyperChain puede proporcionar a una aplicación su propio espacio en bloques y, al mismo tiempo, mantenerla conectada a una red más amplia.

Esto puede ser útil para videojuegos, aplicaciones financieras, sistemas de identidad, programas de fidelización, redes empresariales, plataformas sociales y entornos con transacciones frecuentes.

Sin embargo, las appchains también implican responsabilidades.

El equipo debe gestionar las operaciones de la cadena, la estrategia de liquidez, la supervisión de seguridad, las actualizaciones, los socios de infraestructura y la atención al usuario.

Una HyperChain proporciona más control a quienes desarrollan el proyecto, pero un mayor control implica más riesgo operativo.

Lanzar una cadena no es lo mismo que desplegar un contrato inteligente sencillo.

HyperChains y liquidez compartida

La liquidez compartida es una de las principales promesas de las HyperChains.

En un entorno multicadena fragmentado, la liquidez puede repartirse entre muchos bridges, pools, activos envueltos y bases de usuarios distintas.

Esto puede encarecer los swaps, complicar los bridges y dificultar la incorporación de nuevos usuarios.

La descripción general de ZK Stack afirma que todas las cadenas ZKsync del ecosistema comparten usuarios y liquidez.

Esto no significa que todos los activos tengan automáticamente una liquidez elevada en todas las cadenas.

Significa que la arquitectura está diseñada para facilitar el movimiento y el uso de la liquidez frente a los sistemas de cadenas aisladas.

La interoperabilidad, la liquidación compartida, la agregación de pruebas y la mensajería a nivel de red pretenden reducir la fragmentación de la liquidez.

Para los usuarios de DeFi, esto podría facilitar el acceso a activos en varias cadenas.

Para los desarrolladores de aplicaciones, podría reducir la necesidad de crear liquidez desde cero en una cadena completamente aislada.

Para el ecosistema, la liquidez compartida puede ofrecer una experiencia de usuario más unificada.

HyperChains y abstracción de cuentas

La abstracción de cuentas es una parte importante de la experiencia de usuario de ZKsync.

Permite que las smart accounts ofrezcan funciones que las cuentas externas convencionales quizá no admitan de forma predeterminada.

En un entorno de HyperChains, la abstracción de cuentas puede ayudar a los usuarios a interactuar entre cadenas con menos pasos manuales.

Por ejemplo, las smart accounts pueden admitir paymasters, transacciones patrocinadas, claves de sesión, recuperación social, transacciones agrupadas o lógica de firma personalizada.

Esto es importante porque el uso de criptomonedas entre cadenas suele ser demasiado complejo para los usuarios convencionales.

Es posible que los usuarios no quieran entender todos los tokens de gas, rutas de bridge o cambios de red.

La abstracción de cuentas puede hacer que las interacciones se parezcan más al uso de una sola aplicación que a la gestión de muchas redes.

Sin embargo, la abstracción de cuentas también añade riesgos relacionados con los contratos inteligentes.

Si la lógica de la cuenta, las reglas del paymaster o los permisos de la wallet tienen fallos, los usuarios pueden sufrir pérdidas o transacciones fallidas.

El buen diseño de las wallets y las auditorías de seguridad siguen siendo esenciales.

HyperChains y bridges

Los bridges son un aspecto importante del diseño de HyperChains porque históricamente las transferencias de activos entre cadenas han entrañado riesgos en el sector cripto.

Los bridges tradicionales suelen exigir que los usuarios confíen en operadores, proveedores de liquidez, validadores o sistemas externos de mensajería.

Las HyperChains pretenden reducir los supuestos de confianza en los bridges mediante interoperabilidad basada en ZK e infraestructura de protocolo compartida.

La documentación de ZKsync Connect explica que la interoperabilidad puede admitir transferencias de activos y llamadas entre cadenas mediante la verificación de mensajes con pruebas.

Esto puede integrar mejor la actividad entre cadenas que el uso de bridges de terceros sin conexión con el ecosistema.

Aun así, los usuarios no deberían suponer que todas las transferencias entre cadenas carecen de riesgo.

Entre los riesgos posibles figuran los errores en contratos inteligentes, los retrasos de los relayers, la selección de una cadena equivocada, la disponibilidad por fases de las funciones, los problemas de disponibilidad de datos y los errores al firmar.

Antes de mover cantidades importantes, los usuarios deberían comprobar que la ruta esté admitida y probarla con una transferencia pequeña.

La seguridad entre cadenas mejora cuando el diseño del bridge minimiza la confianza necesaria, pero sigue siendo preciso actuar con cuidado.

HyperChains y liquidación en Ethereum

La liquidación en Ethereum es un importante ancla de seguridad para muchas cadenas basadas en ZK.

La documentación de ZKsync Era explica que se envían pruebas de validez a Ethereum para verificar los cambios de estado y proporcionar finalidad.

Según el diseño de la cadena, Ethereum puede actuar como capa compartida de liquidación y verificación para las HyperChains.

Esto significa que los usuarios pueden beneficiarse de la seguridad de Ethereum sin ejecutar directamente en Ethereum todas las transacciones.

La cadena ejecuta las transacciones off-chain o en un entorno de ejecución independiente y después envía pruebas o compromisos para su liquidación.

Esto puede reducir los costes de transacción y mantener una conexión más sólida con la seguridad de Ethereum que una cadena completamente independiente.

Sin embargo, la seguridad de la liquidación depende de la configuración concreta.

Un rollup ZK, un validium y un volition no comparten los mismos supuestos.

Los usuarios deberían comprobar si los datos de las transacciones se publican en Ethereum, se almacenan en otro lugar o se gestionan mediante otro sistema de disponibilidad.

La expresión «liquidado en Ethereum» debe entenderse teniendo en cuenta sus detalles técnicos, no como una garantía general de seguridad.

HyperChains y personalización para desarrolladores

La posibilidad de personalización es uno de los principales motivos para crear una HyperChain.

La documentación de ZKsync Chains afirma que estas cadenas son modulares y permiten a los desarrolladores elegir distintos componentes blockchain, manteniendo unos estándares básicos de seguridad e interoperabilidad.

La personalización puede incluir la secuenciación, la disponibilidad de datos, el token de comisión, el diseño de privacidad, los filtros de transacciones, los permisos y la lógica específica de la aplicación.

Un desarrollador puede crear una cadena para un videojuego que priorice las comisiones bajas y las interacciones rápidas.

Una aplicación financiera puede dar prioridad a los controles de cumplimiento, una finalidad predecible y las funciones de privacidad.

Una aplicación social puede priorizar la recuperación de cuentas, las transacciones patrocinadas y las publicaciones de bajo coste.

Una aplicación de alto rendimiento puede priorizar la capacidad de ejecución dedicada.

Estas opciones permiten a las aplicaciones evitar las limitaciones de un enfoque único para una cadena de propósito general.

La contrapartida es una mayor complejidad.

Las personalizaciones deben explicarse con claridad para que los usuarios entiendan el modelo de riesgo.

HyperChains y experiencia de usuario

Las HyperChains están diseñadas para mejorar la experiencia de usuario reduciendo la sensación de fragmentación entre cadenas.

La documentación de ZKsync Connect indica que la interoperabilidad puede abstraer las complejas interacciones entre cadenas, de modo que los usuarios no tengan que transferir fondos manualmente si ya disponen de ellos en una cadena de Elastic Network.

Esto es importante porque muchos usuarios tienen dificultades con los tokens de gas, los bridges, los activos envueltos y los cambios de red.

Una experiencia mejor podría permitir que los usuarios se centraran en la acción que quieren realizar.

Por ejemplo, un usuario podría querer intercambiar, acuñar, pagar, reclamar, jugar, prestar o votar sin tener que aprender todos los pasos técnicos de varias cadenas.

Las HyperChains pretenden facilitar estas acciones conectando las cadenas a nivel de protocolo.

Sin embargo, una buena experiencia de usuario depende de la compatibilidad de las wallets, el diseño de las aplicaciones, la fiabilidad de los relayers, la claridad de las solicitudes de transacción y la seguridad de las opciones predeterminadas.

La arquitectura de la cadena proporciona la base, pero las herramientas orientadas al usuario también son importantes.

Una HyperChain técnicamente avanzada puede seguir confundiendo a los usuarios si las wallets y las aplicaciones no explican bien las acciones.

HyperChains y supuestos de seguridad

Los supuestos de seguridad de las HyperChains pueden variar según su configuración.

Una HyperChain similar a un rollup que utilice Ethereum para la disponibilidad de datos tiene riesgos distintos de los de una HyperChain similar a un validium que mantenga los datos off-chain.

Una cadena con un secuenciador centralizado tiene supuestos de disponibilidad y resistencia a la censura distintos de los de una con secuenciación descentralizada.

Una cadena con tokens base personalizados tiene supuestos económicos distintos de los de una cadena que utilice ETH.

Una cadena con funciones de privacidad puede tener supuestos distintos sobre auditabilidad y acceso a los datos.

Los usuarios no deberían considerar que todas las HyperChains tienen el mismo nivel de seguridad por pertenecer a la misma familia de redes.

Deberían revisar el modo de disponibilidad de datos, el modelo de secuenciador, el diseño del bridge, los controles de actualización, las auditorías de contratos y el equipo encargado de operar la cadena.

Los desarrolladores deberían comunicar claramente estas decisiones de diseño.

En los sistemas blockchain modulares, la seguridad no se resume en una única etiqueta.

Depende de la combinación de muchas decisiones.

HyperChains y validiums

Los validiums son una configuración importante de las HyperChains porque pueden reducir los costes y mejorar la privacidad al mantener los datos fuera de Ethereum.

La documentación de ZKsync Chains explica que los validiums pueden ser útiles para aplicaciones empresariales que necesitan auditabilidad y confidencialidad, pero que la disponibilidad de datos controlada puede implicar el riesgo de que los activos queden bloqueados si los datos dejan de estar disponibles.

Esta es una compensación fundamental.

Las pruebas de validez pueden demostrar que las transiciones de estado son correctas, pero los usuarios siguen necesitando datos suficientes para conocer y reconstruir su propio estado.

Si falla la disponibilidad de los datos, los usuarios pueden tener dificultades para retirar sus activos o demostrar sus saldos.

Los validiums pueden ser adecuados para aplicaciones en las que reducir costes o proteger la privacidad es más importante que disponer de todos los datos en Ethereum.

Pueden ser menos adecuados para quienes quieran las mayores garantías posibles de retirada sin necesidad de confiar en terceros.

No hay una respuesta válida para todos los casos.

El mejor diseño depende de las necesidades de la aplicación y de la tolerancia al riesgo de los usuarios.

Quienes desarrollen HyperChains deberían explicar con transparencia esta compensación.

HyperChains y rollups

Las HyperChains basadas en rollups ZK publican en Ethereum datos suficientes para que los usuarios puedan verificar y recuperar el estado conforme al modelo rollup.

Esto puede ofrecer mejores propiedades de seguridad y resistencia a la censura porque Ethereum actúa como capa de disponibilidad de datos.

La desventaja es el coste.

Publicar datos en Ethereum puede ser más caro que utilizar disponibilidad de datos off-chain.

Las HyperChains de tipo rollup pueden ser más apropiadas para DeFi de alto valor, gobernanza, liquidación y aplicaciones en las que las garantías de retirada de los usuarios sean fundamentales.

Pueden resultar menos eficientes en costes para interacciones de poco valor y gran volumen, como algunos videojuegos o acciones en redes sociales.

ZK Stack permite a los desarrolladores elegir políticas de disponibilidad de datos según el caso de uso.

Esta modularidad resulta útil, pero también significa que los usuarios deben consultar la documentación de la cadena.

Una HyperChain puede utilizar tecnología ZK y tener un perfil de seguridad distinto del de otras cadenas basadas en ZK.

El modo rollup suele ser la opción más conservadora cuando es importante disponer de datos públicos y sólidos.

HyperChains y privacidad

La privacidad puede ser un motivo para lanzar una HyperChain.

Algunas aplicaciones pueden preferir que no todos los detalles de las transacciones o acciones de los usuarios sean plenamente visibles para el público.

Los casos de uso empresariales, los sistemas de identidad, los pagos privados y los flujos de trabajo regulados pueden requerir divulgación selectiva o gestión confidencial de datos.

La documentación de ZKsync Chains aborda opciones de privacidad como el modo validium y los protocolos especializados en privacidad.

La privacidad mejora la usabilidad de algunas aplicaciones, pero añade complejidad al diseño.

Los usuarios deben entender quién puede ver los datos, quién controla su disponibilidad, cómo se realizan las auditorías y qué ocurre si se restringe el acceso.

Una HyperChain centrada en la privacidad debería explicar si esta se aplica al usuario, al operador o a la aplicación, o si solo afecta a la interfaz.

También debería explicar cómo pueden retirar los usuarios sus activos o demostrar sus saldos si algo sale mal.

La privacidad es valiosa, pero las afirmaciones imprecisas al respecto entrañan riesgos.

Un buen diseño de HyperChain debería dejar claros los supuestos de privacidad.

HyperChains y gobernanza

La gobernanza es importante porque las HyperChains pueden necesitar actualizaciones, cambios de parámetros, respuestas de emergencia y coordinación del protocolo.

La documentación de ZKsync Chains señala que una gobernanza unificada puede ayudar al ecosistema a coordinar actualizaciones o responder a vulnerabilidades.

La gobernanza puede incluir decisiones a nivel de protocolo, de ecosistema o de una cadena concreta.

Una HyperChain puede tener operadores, una comunidad, titulares de tokens, una fundación o un proceso de gobernanza propios.

Los usuarios deberían preguntar quién puede actualizar los contratos, cambiar los secuenciadores, modificar las comisiones, pausar componentes o alterar los ajustes de disponibilidad de datos.

La gobernanza puede ser útil cuando hay que corregir rápidamente un error.

También puede generar riesgos de centralización si un grupo pequeño controla los cambios fundamentales.

Los bloqueos temporales, las propuestas públicas, los controles multifirma, las auditorías y unas políticas de actualización claras pueden reducir los riesgos de gobernanza.

Una cadena no está totalmente libre de confianza si determinados actores pueden cambiar discretamente reglas importantes.

La gobernanza de las HyperChains debería ser visible y comprensible.

HyperChains frente a redes Layer 2 de propósito general

Una red Layer 2 de propósito general está diseñada para admitir muchas aplicaciones distintas en una misma capa de ejecución compartida.

Una HyperChain también puede ser de propósito general, pero suele describirse como una cadena personalizada o específica para una aplicación.

La diferencia está en el control y la especialización.

Una red de propósito general ofrece a los desarrolladores un entorno listo para usar, con usuarios y liquidez existentes.

Una HyperChain ofrece a los desarrolladores más control sobre la configuración, la economía y la experiencia de usuario.

Ese control puede ser valioso para aplicaciones a gran escala o proyectos con necesidades especiales.

Sin embargo, lanzar una HyperChain también exige más responsabilidad operativa.

Los equipos deben ocuparse de la infraestructura, la supervisión, las actualizaciones, la disponibilidad de datos, las rutas de bridge, las wallets, la seguridad y la atención al usuario.

Para muchos proyectos, desplegar un contrato inteligente en una cadena existente puede ser más sencillo.

Para proyectos que necesiten capacidad de procesamiento dedicada o reglas personalizadas, una HyperChain puede ser más adecuada.

La elección depende de la escala y los requisitos de la aplicación.

HyperChains frente a contratos inteligentes específicos para aplicaciones

Un contrato inteligente específico de una aplicación se ejecuta en una blockchain existente.

Una HyperChain es un entorno blockchain independiente que puede alojar contratos, cuentas y transacciones con su propia configuración.

Desplegar un contrato inteligente es más sencillo y suele facilitar la integración con los usuarios existentes.

Una HyperChain ofrece más control, pero también requiere más infraestructura.

Por ejemplo, una colección NFT sencilla quizá no necesite su propia HyperChain.

Un videojuego de gran volumen con millones de pequeñas transacciones podría beneficiarse de un espacio en bloques dedicado y un diseño personalizado de comisiones.

Un flujo de trabajo empresarial regulado puede necesitar permisos o funciones de privacidad difíciles de implementar de forma limpia en una cadena compartida completamente pública.

Un protocolo DeFi puede elegir una cadena existente si la composabilidad síncrona es más importante que una ejecución personalizada.

La pregunta fundamental es si las necesidades de la aplicación justifican tener una cadena completa.

Las HyperChains son potentes, pero no deberían utilizarse únicamente porque lanzar una cadena parezca impresionante.

Ventajas de las HyperChains

La primera ventaja de las HyperChains es la escalabilidad mediante la ejecución paralela en numerosas cadenas.

La segunda es la personalización, ya que los desarrolladores pueden adaptar la cadena a un caso de uso concreto.

La tercera es la interoperabilidad, porque las cadenas compatibles pueden comunicarse mediante una infraestructura compartida.

La cuarta es la posibilidad de compartir liquidez en Elastic Network.

La quinta es la liquidación alineada con Ethereum para las cadenas que utilizan Ethereum como referencia de verificación.

La sexta es la reducción de los costes de transacción gracias a la ejecución off-chain y la agregación de pruebas.

La séptima es la mejora de la experiencia de usuario mediante la abstracción de cuentas, la mensajería entre cadenas y una menor necesidad de transferir activos manualmente.

La octava es la flexibilidad de disponibilidad de datos para aplicaciones con distintas necesidades de seguridad, privacidad y coste.

Estas ventajas son mayores cuando la cadena está bien diseñada, documentada y operada.

Incluso con un framework avanzado, una HyperChain mal gestionada puede entrañar riesgos para los usuarios.

Riesgos de las HyperChains

El primer riesgo es el de configuración.

La disponibilidad de datos, la secuenciación, el token base, la gobernanza y los ajustes del bridge pueden afectar a la seguridad de los usuarios.

El segundo riesgo es el de los contratos inteligentes.

Los bridges, routers, contratos de cuentas, paymasters y contratos de aplicaciones pueden contener errores.

El tercer riesgo es el de disponibilidad de datos.

Las configuraciones similares a validiums pueden impedir el acceso de los usuarios si los datos necesarios dejan de estar disponibles.

El cuarto riesgo es el del secuenciador.

Un secuenciador centralizado puede censurar, retrasar o reordenar transacciones hasta que se utilicen las vías alternativas.

El quinto riesgo es el del despliegue gradual de la interoperabilidad.

Algunas funciones entre cadenas pueden estar activas, mientras que otras aún pueden ser limitadas, experimentales o estar pendientes de actualizaciones.

El sexto riesgo es el de liquidez.

Una HyperChain nueva puede no disponer de inmediato de liquidez profunda, aplicaciones fiables o compatibilidad amplia con wallets.

El séptimo riesgo es el de gobernanza.

Los contratos actualizables o los controles administrativos con amplios privilegios pueden modificar el perfil de riesgo de la cadena.

Cómo evaluar una HyperChain

El primer paso es confirmar si la cadena está construida con el ZK Stack oficial y conectada a Elastic Network.

El segundo es comprobar el modo de disponibilidad de datos de la cadena.

El tercero es averiguar si se trata de un rollup, un validium, un volition u otra configuración.

El cuarto es revisar quién opera el secuenciador.

El quinto es comprobar si la cadena utiliza ETH o un token base personalizado para las comisiones.

El sexto es revisar los contratos de bridge, la compatibilidad con Gateway y el estado de la interoperabilidad.

El séptimo es inspeccionar la gobernanza y los permisos de actualización.

El octavo es comprobar la compatibilidad con wallets y exploradores, la fiabilidad de RPC y la disponibilidad de aplicaciones.

El noveno es revisar las auditorías, el historial de incidentes y la transparencia operativa.

El décimo es probar la cadena con cantidades pequeñas antes de transferir un valor importante.

Malentendidos habituales sobre las HyperChains

Un malentendido habitual es pensar que las HyperChains son un token.

Las HyperChains no son un token, sino un concepto de arquitectura blockchain.

Otro malentendido es pensar que todas las HyperChains ofrecen el mismo nivel de seguridad.

La seguridad depende de la configuración, la disponibilidad de datos, la secuenciación, la gobernanza y la seguridad de los contratos.

Un tercer malentendido es creer que las pruebas ZK eliminan todos los supuestos de confianza.

Las pruebas ZK son potentes, pero los usuarios siguen dependiendo de que la implementación sea correcta, los datos estén disponibles, los contratos sean seguros y la infraestructura funcione de forma fiable.

Un cuarto malentendido es creer que las cadenas personalizadas resuelven automáticamente los problemas de liquidez.

La interoperabilidad puede facilitar el movimiento de la liquidez, pero la liquidez real sigue dependiendo de los usuarios, los activos, los creadores de mercado, las aplicaciones y los incentivos.

Un quinto malentendido es pensar que las HyperChains solo sirven para DeFi.

Pueden utilizarse para DeFi, videojuegos, pagos, identidad, aplicaciones sociales, flujos de trabajo empresariales y otros casos de uso de blockchain.

Buenas prácticas para usuarios

Antes de transferir fondos, los usuarios deberían comprobar que la HyperChain aparezca en listados o documentación oficiales.

Deberían verificar las rutas de los bridges y evitar enlaces aleatorios de redes sociales.

Deberían conocer el modo de disponibilidad de datos de la cadena antes de dar por hecho que ofrece la seguridad de Ethereum.

Deberían mantener suficientes tokens de comisión para la cadena que estén utilizando.

Deberían leer con atención las solicitudes de la wallet, sobre todo en transacciones entre cadenas.

Antes de realizar transferencias grandes, deberían probar con cantidades pequeñas.

Deberían comprobar que las aplicaciones sean compatibles con la cadena y el activo concretos que quieren utilizar.

Deberían supervisar el estado de los bridges y la red durante las actualizaciones.

No deberían suponer que una interfaz fluida implica que no haya riesgos.

Los sistemas entre cadenas pueden ocultar complejidad, pero no pueden eliminarla por completo.

Buenas prácticas para desarrolladores

Los desarrolladores deberían elegir una HyperChain únicamente cuando las necesidades de la aplicación justifiquen disponer de una infraestructura de cadena dedicada.

Deberían documentar claramente los supuestos de disponibilidad de datos, el funcionamiento del secuenciador, los controles de actualización y el comportamiento de los bridges.

Deberían utilizar los recursos oficiales de ZK Stack y mantener las dependencias actualizadas.

Deberían probar los flujos de interoperabilidad antes del despliegue en mainnet.

Deberían diseñar reglas seguras para la abstracción de cuentas y los paymasters.

Deberían evitar personalizaciones innecesarias que dificulten las auditorías de la cadena.

Deberían realizar revisiones de seguridad de los contratos de la cadena, los contratos de aplicaciones, los flujos de bridge y los controles administrativos.

Antes del lanzamiento, deberían preparar procedimientos de supervisión, respuesta ante incidentes y actualización.

Deberían explicar de forma sencilla y visible los riesgos para los usuarios.

Una HyperChain es infraestructura, por lo que su lanzamiento debería tratarse como un trabajo de seguridad de infraestructura.

Preguntas frecuentes

¿Qué son las HyperChains?

Las HyperChains son redes blockchain personalizables basadas en ZK, construidas con ZK Stack y diseñadas para interoperar dentro de ZKsync Elastic Network.

¿Son las HyperChains lo mismo que ZKsync Chains?

HyperChains es un término anterior o popular, mientras que la documentación oficial actual suele utilizar ZKsync Chains o ZK Chains.

¿Son las HyperChains una criptomoneda?

No. Las HyperChains no son una criptomoneda: describen un tipo de infraestructura blockchain, no una moneda o un token concretos.

¿Qué es ZK Stack?

ZK Stack es un framework modular para construir blockchains personalizables e interoperables basadas en ZK.

¿Qué es Elastic Network?

Elastic Network es el ecosistema más amplio de ZKsync, formado por ZK Chains interconectadas y diseñadas para compartir usuarios, liquidez e infraestructura de interoperabilidad.

¿Las HyperChains utilizan pruebas de conocimiento cero?

Sí. Las HyperChains utilizan tecnología de pruebas de conocimiento cero para verificar las transiciones de estado y facilitar una liquidación escalable y la interoperabilidad.

¿Puede cualquiera lanzar una HyperChain?

La documentación de ZKsync indica que cualquiera puede desarrollar y desplegar cadenas ZKsync, pero que para una interoperabilidad plenamente fiable dentro de Elastic Network es necesario utilizar ZK Stack.

¿Todas las HyperChains ofrecen el mismo nivel de seguridad?

No. Cada HyperChain puede tener supuestos de seguridad distintos en función de la disponibilidad de datos, la secuenciación, la gobernanza, el diseño de los bridges y el modo de funcionamiento.

¿Qué diferencia hay entre una HyperChain rollup y una HyperChain validium?

Una HyperChain rollup publica datos en Ethereum para ofrecer una mayor disponibilidad de datos, mientras que una HyperChain validium puede mantenerlos fuera de Ethereum para reducir costes o mejorar la privacidad, a cambio de introducir supuestos adicionales sobre la disponibilidad de los datos.

¿Por qué crear una HyperChain?

Un proyecto puede crear una HyperChain para disponer de espacio en bloques dedicado, comisiones personalizadas, opciones propias de disponibilidad de datos o privacidad y rendimiento específico para una aplicación, sin desconectarse de una red más amplia.

¿Qué riesgos deberían comprobar los usuarios antes de utilizar una HyperChain?

Deberían comprobar el modo de disponibilidad de datos, el modelo del secuenciador, la ruta del bridge, los permisos de gobernanza, las auditorías, la liquidez, la compatibilidad con wallets y el estado actual de la interoperabilidad.

¿Las HyperChains solucionan por completo la fragmentación de blockchain?

No. Las HyperChains pretenden reducir la fragmentación mediante la interoperabilidad y una infraestructura compartida, pero la liquidez, la compatibilidad con wallets, el diseño de aplicaciones y la formación de los usuarios siguen siendo importantes.

Conclusión

Las HyperChains son un concepto importante de escalabilidad cripto relacionado con ZK Stack, ZKsync Chains y Elastic Network.

Representan la idea de aumentar la capacidad de blockchain añadiendo numerosas cadenas personalizables basadas en ZK, en lugar de obligar a todos los usuarios y aplicaciones a utilizar una sola capa de ejecución.

Una HyperChain puede especializarse en una aplicación, comunidad, caso de uso empresarial o ecosistema concretos y, al mismo tiempo, conectarse con otras cadenas compatibles.

Este diseño pretende combinar personalización, escalabilidad, interoperabilidad y seguridad alineada con Ethereum.

La principal ventaja de las HyperChains es que pueden reducir la disyuntiva entre disponer de espacio en bloques dedicado y acceder a una red compartida.

Los desarrolladores pueden diseñar una cadena según sus necesidades mientras que los usuarios pueden beneficiarse de unas transferencias entre cadenas más fluidas.

Sin embargo, las HyperChains no están automáticamente libres de riesgos.

El perfil de riesgo concreto depende de la disponibilidad de datos, el diseño del secuenciador, la infraestructura de bridges, la agregación de pruebas, la gobernanza, los contratos inteligentes y la liquidez.

Los usuarios no deberían dar por hecho que todas las HyperChains tienen el mismo nivel de seguridad por utilizar tecnología ZK.

Los desarrolladores deberían documentar claramente la configuración de la cadena y evitar ocultar supuestos importantes tras una marca sencilla.

El ecosistema actual ha evolucionado hacia términos como ZKsync Chains, ZK Chains y Elastic Network, pero HyperChains sigue siendo una entrada útil del glosario para entender la visión original.

Para los usuarios cripto, la conclusión principal es sencilla.

Las HyperChains son cadenas personalizables basadas en ZK, diseñadas para ampliar el uso de blockchain y mantener las cadenas conectadas mediante una infraestructura de interoperabilidad compartida.