TL;DR

• =nil; es un zkRollup fragmentado - un nuevo concepto L2 para la escalabilidad dinámica y segura de Ethereum a través de una ejecución de transacciones paralelas a nivel de protocolo en fragmentos.
• Equipado con zkSharding, =nil; ofrece escalabilidad horizontal sin comprometer los beneficios de una sola capa de ejecución, es decir, liquidez unificada y seguridad económica.
• =nil; proporciona aplicaciones plena composabilidad con Ethereum a través de un acceso transparente y verificable a los datos de Ethereum.
• =nil; introduce un zkEVM de Tipo-1 compilado con zkLLVM.
• La generación rápida de pruebas está garantizada por la competencia en el mercado abierto a través del Mercado de Pruebas =nil; - un mercado de generación de pruebas sin permisos.

Introducción a zkSharding

Hoy, las soluciones de capa 2 compensan la escalabilidad por la fragmentación del estado. Introducimos un diseño de capa 2 (L2), =nil;, que empuja los límites de la escalabilidad de Ethereum sin comprometer los beneficios de un entorno de ejecución unificado. La solución combina un mecanismo de fragmentación dinámica con acceso comprobable a los datos de Ethereum, asegurado por tecnologías de conocimiento cero. Los elementos clave incluyen:

• zkRollup con Fragmentación: El núcleo de =nil; es un protocolo de fragmentación comprobable, que permite escalabilidad horizontal sin comprometer la seguridad o eficiencia. Este enfoque aborda algunas de las limitaciones actuales de la escalabilidad vertical (L3, L4, etc.), en particular la fragmentación de datos y liquidez.
• Acceso directo a los datos de Ethereum: La capacidad de llamar a los datos originales de Ethereum desde aplicaciones de L2 nos permite reutilizar aplicaciones ya desplegadas. El acceso directo a los datos de L1 desde L2 garantiza un entorno más unificado y sin fisuras.

A través de zkSharding =nil; se beneficia de las ventajas de los diseños monolíticos y modulares, incluyendo:

• Escalabilidad

  • No hay limitaciones de escalabilidad ya que la ejecución es paralela. Se estima que la capacidad de procesamiento sea de alrededor de 60k transferencias ERC-20 por segundo con aproximadamente 400 nodos.
  • La generación de pruebas competitivas a través del Mercado de Pruebas proporciona la finalidad L1 más rápida y los costos de generación de pruebas más baratos.

• Entorno de Ejecución Unificado

  • El entorno de ejecución unificado garantiza que no haya fragmentación de seguridad/liquidez ya que cada fragmento es parte de todo el clúster.
  • Reducción de la necesidad de migrar liquidez desde Ethereum, ya que =nil; proporciona acceso transparente a sus datos para aplicaciones mediante el cumplimiento de que cada validador mantenga un estado completo de Ethereum como parte de la implementación, lo que permite a las aplicaciones acceder a los datos directamente desde zkEVM de =nil;.

• Seguridad

  • Transiciones de estado aseguradas por zkEVM compiladas a través de zkLLVM. Proporciona seguridad auditiva (por ejemplo, seguridad de restricciones) ya que el código es fácilmente inspeccionable, ya que los circuitos zkEVM se compilan a partir de una implementación de EVM utilizada en producción en un lenguaje de alto nivel y no escrita manualmente.
  • Descentralizado desde el primer día gracias a la generación descentralizada de pruebas habilitada por =nil; Proof Market.

• Funcionalidad

  • Un zkEVM de Tipo-1, totalmente equivalente en bytecode EVM compilado a través de zkLLVM.
  • Un entorno adaptado para aplicaciones que tienen altas demandas relacionadas con el tiempo, la memoria y la complejidad algorítmica al impulsar una consistencia de fragmentación única e introducir una colocación de aplicaciones por fragmento reforzada para reducir la latencia. Ejemplos incluyen intercambios descentralizados, mercados de prueba, secuenciadores/constructores descentralizados, aplicaciones de estado compartido (también conocidas como mundos autónomos, etc.).

Escalado componible dinámico

En el nivel inferior, el estado de =nil; se divide en el fragmento primario y varios fragmentos secundarios. El papel del fragmento principal es sincronizar y consolidar datos de los fragmentos secundarios. Utiliza Ethereum tanto como su Capa de Disponibilidad de Datos como verificador de pruebas de transición de estado, similar a las operaciones típicas de zkRollups.

Las fragmentaciones secundarias funcionan como "trabajadores", ejecutando transacciones de usuarios. Estas fragmentaciones mantienen liquidez y datos unificados a través de un protocolo de mensajería entre fragmentaciones, eliminando cualquier fragmentación entre ellas.

Cada fragmento es supervisado por un comité de validadores. Hay una rotación periódica de estos validadores entre fragmentos. Además, las actualizaciones del estado de un fragmento se verifican en el fragmento principal utilizando zkEVM.

Para ilustrar el flujo de transacciones desde la iniciación por parte de un usuario hasta la confirmación en Ethereum, considere los siguientes pasos:

• El usuario firma una transacción (tx) y la despacha a la red.
• Los validadores en el fragmento S, donde se encuentra la billetera del usuario, colocan tx en el mempool.
• Estos validadores luego crean un nuevo bloque B(1/S)
• El hash de B(1/S) se registra en el fragmento principal dentro del bloque B(1/M)
• Una prueba de transición de estado para B(1/S) es producida y verificada por la fragmentación principal en el bloque B(2/M)
• Una prueba de transición de estado para B(2/M) se envía a Ethereum para su verificación y se combina con los datos necesarios para garantizar la disponibilidad de datos.
• Una vez que este proceso se complete, tx logra confirmación por Ethereum.

Este esquema asume que la transacción del usuario no activa el protocolo de mensajería entre fragmentos. Sin embargo, en este caso, el flujo de la transacción sigue siendo el mismo con la diferencia de que la transacción del usuario puede desencadenar la creación de nuevas transacciones en otros fragmentos.

Con todas las cuentas distribuidas entre fragmentos, esto podría parecer similar al problema de fragmentación de datos encontrado en el enfoque de rollups específicos de la aplicación. Sin embargo, la diferencia clave radica en cómo se maneja la comunicación entre fragmentos: está integrada directamente en el protocolo general, en lugar de ser administrada por puentes externos separados.

Para garantizar la seguridad de cada fragmento secundario, su comité validador está obligado a demostrar sus transiciones de estado al primario para asegurar que no ha habido fraude dentro de un grupo de validadores más pequeño. Cada comité de validadores de fragmentos tiene tareas adicionales más allá del mantenimiento del fragmento. Los validadores son responsables de rastrear tipos específicos de eventos, es decir, mensajes entre fragmentos, dentro de los “fragmentos cercanos”. Los fragmentos cercanos se determinan en función de la distancia de Hamming en los identificadores de fragmentos.

zkEVM a través de zkLLVM: Tipo-1 Seguro, Auditable y Eficiente zkEVM

=nil;s zkEVM es un zkEVM de Tipo-1 compilado con zkLLVM. Para entender las diferencias entre los zkEVMs más tradicionales y el zkEVM de =nil;, necesitamos hablar de las limitaciones asociadas con el proceso de definición de circuitos que subyace a los zkEVMs. El circuito zkEVM es una parte crítica, responsable de que una prueba de transición de estado se considere correcta, generalmente se define con algún zkDSL personalizado o simplemente una biblioteca. Esta forma de definir circuitos trae problemas relacionados con:

• Seguridad: Problemasdebido al tamaño de un circuito y la replicación manual de la lógica de EVM.
• Auditabilidad: Limitadaauditabilidadyinspectabilitydebido a la complejidad y falta de explicitud de los zkDSLs utilizados.
• Capacidad de actualización: Complejidad de mantenimiento y actualización debido a los requisitos de definición de restricciones manuales. En caso de que ocurra algún cambio en EVM, la mayoría de los circuitos zkEVM requerirían ser re-hechos y re-auditados desde cero.
• Compatibilidad: La complejidad de la implementación del circuito zkEVM compatible con el bytecode real (también conocido como Tipo-1) a menudo resulta en limitaciones para las aplicaciones debido a las diferencias en el comportamiento de zkEVM y el comportamiento real de EVM.

=nil; zkEVM está abordando de manera efectiva todos estos desafíos al ser:

• Seguro: Un circuito debe generarse automáticamente a partir del mismo código de alto nivel utilizado en los nodos Ethereum en funcionamiento real para garantizar que no haya diferencias de algoritmo presentes.
• Auditable: Un circuito debe estar representado en un lenguaje de programación de alto nivel (también conocido como C++ o Rust) que debería estar escrito de manera que sea fácilmente legible por un desarrollador promedio.
• Actualizable: Un circuito debe definirse de tal manera que cualquier cambio dentro del EVM pueda traducirse/finalizarse fácilmente a un circuito zkEVM que pruebe/defina exactamente el mismo comportamiento. No debería surgir la necesidad de una recompilación completa o una reauditoría completa a partir de dicha actualización.
• Bytecode Compatible (también conocido como Tipo-1): La compilación de circuitos desde lenguajes de alto nivel aporta una compatibilidad total con el bytecode y el comportamiento del EVM, lo que reduce drásticamente el tiempo de comercialización de las aplicaciones EVM y el tiempo/ esfuerzo de desarrollo necesario para lograr dicha compatibilidad.

zkEVM compilado a través de zkLLVM es seguro por diseño, aprovechando evmone para garantizar completa consistencia con el EVM utilizado en producción de Ethereum. El zkLLVM (C++ o Rust) compila automáticamente hasta el circuito, lo que elimina errores humanos del proceso de definición del circuito.

Además, debido a que =nil; zkEVM se compila a través de zkLLVM, es naturalmente más flexible (y, por lo tanto, más a prueba de futuro) que los circuitos definidos manualmente, ya que es fácilmente ajustable y la generación de circuitos es automática. También es más auditable, lo que significa que su seguridad no tiene un costo que incluya las últimas EIP agregadas a Ethereum.

zkRollup con la seguridad y disponibilidad de datos de Ethereum

Como el fragmento principal y los fragmentos secundarios son diferentes en cuanto a sus tareas dedicadas - los fragmentos secundarios se centran en el procesamiento de transacciones mientras que el fragmento principal se centra en la sincronización de datos - tienen enfoques diferentes para la disponibilidad de datos (DA), lo que ayuda a recuperar datos de estado en situaciones de emergencia. Esto significa:

• El shard principal emplea Ethereum como su DA.
• Las fragmentaciones secundarias tienen la opción de usar Ethereum o optar por no tener un DA distinto.

Esta disposición se establece mediante el lanzamiento de dos tipos de fragmentos al inicio: aquellos con una solución DA externa separada y aquellos sin ella. En fases posteriores, solo se pueden fusionar fragmentos de la misma categoría DA. Esto significa que durante su creación, cada cuenta debe ser asignada a una categoría DA específica.

Además, este marco se puede ampliar para incluir otros tipos de DA.

Acceso transparente a los datos de Ethereum

Uno de nuestros objetivos principales es optimizar la composabilidad de la aplicación y evitar la fragmentación de la liquidez, por lo que naturalmente el enfoque de zkSharding sería incompleto sin acceso sin confianza al estado de Ethereum. Esto significa que =nil; ofrece una composabilidad completa e integración transparente con Ethereum a través del módulo Data Provider.

El proveedor de datos opera de forma independiente al almacenamiento de datos del fragmento, sincroniza su información con una base de datos externa e inyecta la huella digital de Ethereum del último estado de la base de datos monitoreada (representada por el hash de bloque de Ethereum) en el bloque del fragmento. El estado más reciente de esta base de datos recibe validación del módulo de confirmación, que utiliza un zkBridge con la prueba de consenso Casper FFG de Ethereum.

¿Qué sigue:

=nil; y zkSharding son una culminación de productos que =nil; Foundation ha desarrollado en los últimos 4 años. Su objetivo es ser la primera solución componible, escalable y universal de capa 2 de Ethereum zkRollup. ¡Estamos emocionados de compartir más detalles de implementación en los próximos meses. Asegúrese de seguir nuestro Twitter para mantenerse actualizado con nuestro progreso!

Para los técnicamente inclinados, hemos desarrolladoun manual separado y completoque profundiza en los detalles de =nil; y zkFragmentación. Esta introducción es tu puerta de entrada para entender las complejidades detrás de este enfoque, equipado con todos los detalles técnicos y preliminares que necesitas.

Sumérgete en nuestro manual técnico ahora y únete a la conversación sobre Discord y Telegram¡Vamos a explorar juntos las posibilidades ilimitadas de zkSharding!

Descargo de responsabilidad：

1. Este artículo es reimpreso de [ nil.foundation]. Todos los derechos de autor pertenecen al autor original [nil.foundation]. Si hay objeciones a esta reimpresión, por favor contacte alAprender Gateequipo, y lo manejarán rápidamente.
2. Descargo de responsabilidad: Las opiniones y puntos de vista expresados en este artículo son únicamente los del autor y no constituyen ningún consejo de inversión.
3. Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.