Series zkSync Parte 2/3

Hola comunidad 👋

Desde L2 Español, hemos decidido profundizar en zkSync en una serie de tres partes. En la primera parte, analizamos su arquitectura, mientras que en esta segunda parte, abordaremos otros temas relevantes de zkSync, como la escalabilidad, la seguridad en los puentes y el almacenamiento de datos (DA), entre otros aspectos en zkSync. Aunque muchas de estas nuevas tecnologías se presentarán en zkSync 3.0, es importante discutir su potencial y su impacto en la cadena de bloques.

Esperamos que esta serie de artículos sea de gran ayuda para comprender mejor zkSync y cómo se puede utilizar para mejorar la experiencia de los usuarios y desarrolladores en la cadena de bloques.

🚀️ Hyperscaling

El trilema de blockchain es un concepto fundamental de esta tecnología que se refiere a los tres objetivos claves que cualquier sistema de este tipo debe satisfacer: seguridad, escalabilidad y descentralización. Según este principio, un sistema blockchain de base no puede lograr los tres objetivos de manera simultánea, ya que cualquier mejora en uno de estos aspectos conlleva un compromiso en los otros dos.

Los sistemas Blockchain buscan garantizar la equidad mediante el principio fundamental de "no confíes, verifica". No obstante, para preservar la descentralización, es necesario que los nodos verificadores requieran bajos recursos para su ejecución. La interconexión de estas dos ideas ha dado lugar a la definición ampliamente aceptada de escalabilidad:

• Escalabilidad = procesamiento de un mayor número de transacciones sin comprometer la seguridad ni la descentralización.

Existen diversas formas de mejorar la escalabilidad, como aumentar la eficiencia del verificador o introducir suposiciones de confianza probabilísticas (como se hace en los resúmenes optimistas). Si bien la mayoría de estos enfoques ofrecen un impulso de escalabilidad lineal, un método sobresale por encima del resto: las pruebas sucintas de conocimiento cero (ZKP). Estas pruebas incurren siempre en costos de verificación de aproximadamente O(1), independientemente del número de transacciones procesadas. Gracias a esto, el escalado basado en ZKP, es decir, validiums y (bajo ciertas condiciones) ZK Rollups, puede ser considerado hiperescalable:

• Hiperescalabilidad = procesamiento de un número infinito de transacciones sin comprometer la seguridad ni la descentralización.

Los ZKP ofrecen una solución eficaz para construir una cadena de bloques heterogénea altamente escalable, este enfoque se conoce como "escalado fractal". En este modelo, varias cadenas ZKP diferentes (también llamadas hipercadenas en zkSync) se ejecutan simultáneamente y sus bloques de prueba se agregan en un solo bloque final que se liquida en la capa principal L1. Cada hipercadena se parece a todo el sistema, lo que significa que puede haber un número infinito de hipercadenas adicionales encima (como L3, L4, etc.).

Aunque la escala fractal es necesaria para lograr una mayor escalabilidad, se requiere un componente adicional para alcanzar una hiperescala.

• Hiperpuentes = puentes nativos que permiten transferencias entre dos hipercadenas sin consumir recursos en una tercera.

El escalado fractal siempre puede tener puentes nativos que conectan cadenas a través de capas subyacentes, pero en este caso, la cadena base eventualmente se convertirá en una encrucijada para la mayoría de las transferencias, y se convertirá en el cuello de botella central de la escalabilidad, derrotando la idea misma de la hiperescalabilidad paralela. Como resultado, no será posible garantizar transferencias directas baratas entre usuarios en dos cadenas dadas.

Para lograr una sobrecarga de costo cero en las cadenas subyacentes, cada hipercadena debe implementar hiperpuentes nativos que realmente puedan grabar y acuñar tokens reales y no solo su representación virtual (a diferencia de los puentes convencionales), almacenando compromisos de reclamos de acuñación en el estado Hyperchain. Además, deben confiar en las implementaciones de hiperpuentes en todas las demás hipercadenas, porque si un solo hiperpuente se ve comprometido, la cadena maliciosa podría interferir con el suministro de tokens (por lo tanto, todas las hipercadenas deben implementar exactamente los mismos circuitos).

Se pueden transferir activos de una Hyperchain a otra mediante hiperpuentes con el mismo costo que una transferencia normal. Esto funciona de manera similar a los hipervínculos en las páginas web, que permiten acceder a otras páginas con un solo clic, sin necesidad de navegar a través de múltiples capas.

Además, los contratos inteligentes pueden aprovechar las hipercadenas para enviar activos y mensajes a cualquier hipercadena con garantía de entrega, siempre y cuando la hipercadena de destino esté activa.

📄️ Contratos del sistema

Para mantener los circuitos ZK tan simples como sea posible y permitir extensiones sencillas, una gran parte de la lógica de zkSync se trasladó a los llamados "contratos del sistema" . Un conjunto de contratos que tienen privilegios especiales y sirven a propósitos especiales, por ejemplo, el despliegue de los contratos, asegurándose de que el usuario paga sólo una vez por la publicación de los datos de llamada de los contratos, etc.

El código de los contratos del sistema no se hará público hasta que se haya sometido a pruebas exhaustivas.

🌀️🌉️ ZK Rollups y puentes actuales

Antes de seguir con zkSync y la HyperScaling deberemos profundar sobre los puentes y los mecanismos comunes, puede revisar Slush, una propuesta de escalado Fractal.

El sector de los puentes con algún grado de confianza está saturado de empresas como Hop, Celer, deBridge o Connext. Primero clasificaremos a grandes rasgos los mecanismos de estos proyectos y descubriremos que existe un trilemma.

La primera opción de puenteo consistiría en encaminar los fondos desde el rollup de origen hasta el L1 y luego hasta el rollup de destino. Esta opción no es fiable, pero si todo el mundo la utilizara sobrecargaría L1, por lo que siempre será cara. Sin embargo, los costes pueden aliviarse si reúnes fondos con otras personas, si vas al mismo destino. Esto es el enrutamiento compartido, así es como la red Hop hace de puente. Cuando se va desde L3 o a mayor profundidad, los distintos fondos pueden agruparse aún más en L2, sin embargo, esta agrupación sólo puede utilizarse para aplicaciones que tengan una gran base de usuarios tanto en el rollup emisor como en el receptor.

Otra posibilidad es pasar directamente de una capa a otra (por ejemplo, Connext). Aunque son sustancialmente más rápidos y baratos que pasar por L1, estos sistemas sólo intercambian los fondos de una cadena por los de otra, lo que significa que tiene que haber algún otro mecanismo que compense el movimiento neto de fondos entre las capas. Esto conlleva costes adicionales, pero lo más importante es que este método depende en realidad de otras soluciones (como el enrutamiento agrupado).

Hay otra forma de pasar directamente de una capa a otra, una autoridad que quema y acuña los tokens puenteados en cada capa (como Wormhole). Esta autoridad normalmente toma la forma de una cadena de bloques más pequeña, y existen riesgos de seguridad al tener que confiar en estas cadenas de bloques pequeñas. Los inconvenientes de estos sistemas son obvios.

Tenemos un trilema: los sistemas no satisfacen las tres propiedades requeridas:

• No requerir de confianza.

• No tocar L1.

• Tener transferencias reales, no solo intercambio.

La razón de esto es que si tenemos transferencias reales y no intercambios, entonces los fondos deben quemarse en una capa y acuñarse en otra. Esta acuñación solo puede ocurrir si la quema ya ha ocurrido. La confirmación de que se produjo la quema requiere confianza en alguna autoridad o un mensaje transmitido desde L1, ya que las dos capas solo están conectadas a través de L1 sin confianza. Esto hace que sea difícil satisfacer simultáneamente los tres requisitos de un sistema de puente de confianza, aquí entra en juego la propuesta de escalado fractal y zkSync con las Hyperchain.

🔗️ Hyperchain

Las hipercadenas son instancias similares a fractales de zkEVM que se ejecutan en paralelo y con el acuerdo común en la red principal de L1.

Cualquier persona puede desarrollar e implementar hipercadenas sin permiso. Sin embargo, para seguir siendo confiable y totalmente interoperable, cada Hyperchain debe funcionar exactamente con el mismo motor zkEVM que la instancia principal de zkSync L2. Todos los circuitos ZKP seguirán siendo 100 % idénticos, lo que permitirá que las hipercadenas hereden por completo su seguridad de L1, sin importar quién los implemente. Esto garantiza cero suposiciones de confianza/seguridad adicionales.

🔧 Las hipercadenas se implementarán siguiendo el enfoque modular

Proporcionarán un marco SDK de hipercadenas similar a los de Cosmos o Substrate, donde los desarrolladores pueden elegir individualmente diferentes componentes de sus cadenas de bloques o implementar los suyos propios (excepto el núcleo zkEVM).

La Basechain es la principal instancia de Hyperchain de zkSync Era (la instancia L2). Sirve como capa de cálculo predeterminada para contratos inteligentes genéricos y como capa de liquidación para todas las demás hipercadenas (L3 y superiores).

Basechain no es especial de ninguna manera en particular, excepto que asienta sus bloques directamente en L1.

🔌️ Interoperabilidad L1/L2

Si bien la mayor parte de la ejecución ocurrirá en L2, algunos casos de uso requieren interoperabilidad con la cadena L1. Los principales casos de uso son la construcción de puentes complejos, el mantenimiento de contratos inteligentes de gobernanza en una cadena que rigen los contratos en otras cadenas, etc.

Además, la resistencia a la censura L2 se deriva de la cadena subyacente, por lo que la capacidad de enviar mensajes desde Ethereum a zkSync es una parte importante del mecanismo de resistencia a la censura llamado cola de prioridad .

El envío de transacciones de Ethereum a zkSync se realiza a través del contrato inteligente de zkSync, permite al remitente solicitar transacciones directamente desde L1. Permitiendo así el paso sin permiso de cualquier dato de Ethereum a zkSync.

• Cola de prioridad: el objetivo de la cola de prioridad es proporcionar una forma resistente a la censura de interactuar con zkSync en caso de que el operador se vuelva malicioso o no esté disponible.

• Proceso de despliegue: el proceso de la lógica de cuenta es muy similar al de despliegue de un contrato inteligente. Para proteger los contratos inteligentes que no quieren ser tratados como una cuenta, se debe utilizar un método diferente del contrato del sistema de despliegue para hacerlo. En lugar de utilizar create/create2, se deben utilizar los métodos createAccount/create2Account del contrato del sistema deployer.

Para proteger el sistema de posibles ataques de denegación de servicio (DoS), es necesario establecer ciertas limitaciones en el proceso de verificación. Estas limitaciones incluyen que la lógica de la cuenta solo pueda acceder a las ranuras que pertenecen a esa cuenta, lo cual se extiende más allá de los espacios ubicados en la dirección del usuario. Además, la lógica de la cuenta no puede usar variables de contexto como "block.number". Otra restricción importante es que la cuenta debe incrementar su "nonce" en 1, lo cual se hace para preservar la resistencia a la colisión de hash de transacciones. Es importante mencionar que esta limitación podría eliminarse en el futuro para permitir casos de uso más genéricos, como por ejemplo, en protocolos de privacidad.

📊️ Data Availability

A continuación presentamos un ejemplo de cómo cada Hyperchain puede administrar su política de disponibilidad de datos (DA) mediante una interfaz de contrato inteligente. Los usuarios pueden elegir entre varias opciones o incluso aplicar lógicas más complejas. Por ejemplo, una combinación de zkPorter y Validium puede requerir tanto un quórum de firmas de los tutores como un número de firmas del comité de disponibilidad de datos. En la imagen que mostramos a continuación, se puede observar cómo se estructura la DA y cómo se integra en el ecosistema zkSync.

🌀️ ZK Rollup

Los valores de cada ranura de almacenamiento modificada al final del bloque deben publicarse como datos de llamada en L1. Tenga en cuenta que los cambios repetidos (o cambios de ida y vuelta que dan como resultado una diferencia neta) no se publican. Significa que si un bloque contiene 100 intercambios ETH/DAI en el mismo DEX, los costos de publicación de datos se amortizarán parcialmente en todos esos intercambios. Una Hyperchain que funciona en este modo hereda estrictamente las propiedades de seguridad total y resistencia a la censura de Ethereum. La implementación de zkRollup en modo de salida estará disponible desde el día 1. Para propagar los datos de llamadas a L1, se agregarán a la cadena base. Tenga en cuenta que si la prueba ZK de Hyperchain es potencialmente grande en tamaño y/o computacionalmente pesada para verificar, solo incurre en costos L2 y no en costos de publicación.

• ZK Rollup (solo entradas): esta política requerirá la publicación de entradas de transacciones completas en lugar de actualizaciones de almacenamiento finales. La reconstrucción del estado sin confianza y los costos de DA en este caso serán 100% idénticos a los paquetes acumulativos optimistas (pero con todos los beneficios de un ZK Rollup, por supuesto, incluida una mejor seguridad y salidas más rápidas). La implementación de esta opción se deriva fácilmente de la implementación del ZK Rollup normal. Se puede explorar mediante cadenas específicas de la aplicación donde las entradas de tx son cortas pero pueden generar muchos cambios en los datos (por ejemplo, realizar simulaciones financieras).

• ZK Rollup (autohospedado): en este modo, los usuarios alojan ellos mismos los datos de todas las cuentas que poseen. Para hacer cumplir esto, se requieren firmas de confirmación del usuario para realizar cualquier cambio, lo que significa que no puede enviar fondos directamente a otro usuario. En su lugar, quemará los fondos y creará una prueba de esta quema, que puede proporcionar a su destinatario a través de un canal fuera de la cadena. El destinatario luego los canjeará en su cuenta. Esto puede parecer complicado, pero es fácil construir una interfaz de usuario agradable que abstraiga la UX, haciéndola prácticamente indistinguible del envío y la recepción de fondos en Ethereum (canjeará automáticamente todos los activos recibidos en el momento en que el usuario intente gastar los fondos, sin necesidad de clics adicionales). Pero aquí viene un milagro: un ZK Rollup autohospedado puede estar satisfecho con tan solo 5 bytes por interacción de usuario, que incluye un lote de muchas transacciones arbitrarias. Esto hace que el Ethereum fragmentado sea infinitamente escalable para cualquier propósito práctico en el modo zkRollup (es decir, 100 % seguro y resistente a la censura). Esta es una forma de incorporar a cada persona en la Tierra a Ethereum sin comprometer la seguridad. Una gran ventaja de este enfoque es que es totalmente compatible con nuestra implementación zkEVM, pero aún así puede ofrecer privacidad a los usuarios. La implementación no es trivial, por lo que esperamos que sea la última entre todas las demás opciones.

🛡️ zkPorter

Ya tienen una red de prueba de zkPorter guardian en funcionamiento. Esperan que zkPorter sea popular entre los usuarios dispuestos a asumir mayores riesgos de seguridad a cambio de transacciones realmente económicas, hasta que se implemente Danksharding. Los desarrolladores de Hyperchain podrán aprovechar el DA desde la implementación principal de zkPorter de zkSync o iniciar su propia red de guardianes (lo que podría ser interesante para las grandes comunidades en línea existentes, como Reddit o Twitter).

🕵️‍♂️ Validium

Hay casos de uso en los que el uso de validium está totalmente justificado, por ejemplo, cadenas empresariales que requieren auditabilidad y privacidad (dado que la disponibilidad de datos en tales casos está controlada por una parte central, es trivial mantener la privacidad de una Hipercadena de este tipo simplemente reteniendo datos). Dado que validium es esencialmente un caso más simple de zkPorter, los desarrolladores pueden implementar fácilmente Hyperchains en función de esta política.

🌳 Particiones lógicas de estado

Cada Hyperchain tiene la capacidad de crear una o varias particiones lógicas que, aunque forman parte del mismo estado, se ubican en diferentes subárboles y aplican políticas de disponibilidad de datos distintas. Desde la perspectiva del usuario, estas particiones se perciben como instancias separadas de Hyperchain, con su propio ID de cadena, conexión de billetera, explorador de bloques, etc. No obstante, estas particiones pueden interoperar de forma sincrónica, lo que permite realizar transacciones atómicas entre ellas y desbloquea múltiples casos de uso como:

• Leer el estado de otra partición de forma transparente.

• Utilizar préstamos flash entre particiones.

Un ejemplo destacado de esta interoperabilidad se logra mediante una combinación de zkRollup + zkPorter, que será parte de la Basechain de zkSync.

🔒 Privacidad

Existen varias maneras en que las hipercadenas pueden mejorar la privacidad y la confidencialidad de los datos.

• Validium: para una Hyperchain que se ejecuta en el modo validium, la privacidad del mundo exterior se logra de forma inmediata siempre que el operador mantenga en secreto los datos del bloque. Esta podría ser una opción interesante para usuarios empresariales.

• Protocolos de privacidad: para implementar la privacidad a nivel de usuario, se requiere un protocolo L3 especializado. Los proyectos como Aztec o Tornado se pueden implementar directamente en la cadena base (aprovechando la abstracción de cuentas y la verificación recursiva ZKP económica en zkSync), o pueden optar por Hyperchains independientes de propósito especial para una mayor flexibilidad.

🫂 Agradecimientos

Hemos llegado al final de la segunda parte de nuestra serie sobre zkSync, donde exploramos el futuro de la escalabilidad de esta solución. En la tercera y última edición, nos enfocaremos en el desarrollo con zkSync Era y nos gustaría invitarte a participar en una Dapp muy especial que hemos preparado para todos. Esperamos que “nos escribas tus mensajes”... Mantente atento para más información en breve.

También pueden consultar nuestra Biblioteca de Layer 2 en Español para tener una información más detallada o ir directamente en este caso a zkSync Era.

🎉 ¡Gracias por leer hasta el final! Si está interesado en continuar aprendiendo y colaborando con nosotros, le invitamos a unirse a la vibrante comunidad de Telegram L2 en Español y a seguirnos en nuestro Twitter L2 en Español. Allí encontrará una gran cantidad de información sobre Layer 2 y el ecosistema de Blockchain en general. ¡Te Esperamos!