Explicación detallada de la arquitectura zkSync y sus similitudes y diferencias con OP-Stack

Autor: xpara, Cuatro pilares; traducción: Jinse Finance xiaozou

Puntos clave:

Matterlabs, la empresa de desarrollo de zkSync, ha estado trabajando en el desarrollo de su exclusivo zkEVM y en la creación de excelentes productos.

Actualmente, la Era zkSync está mostrando un crecimiento, como lo demuestran sus impresionantes métricas e implementaciones de desarrollo en todos los proyectos.

Podemos entender la arquitectura zkSync a través de tres capas clave de zkSync: capa de ejecución, capa de liquidación y capa de disponibilidad de datos.

ZK-Stack (el código base subyacente de zkSync) y OP-Stack pueden tener filosofías similares. Aún así, existen claras diferencias que se pueden ver desde la perspectiva de los desarrolladores de dapp, los desarrolladores principales y los operadores comerciales.

1**, el desarrollo de la historia de zkSync******

1.1 Breve historia de zkSync

El desarrollo de zkSync comenzó en EthCC en 2019. En ese momento, todavía era un pequeño equipo dedicado a desarrollar e implementar conjuntamente Rollup con zkSNARK. Lanzaron una prueba de concepto en enero de 2019 utilizando zkSNARK para operar una cadena lateral en Ethereum. Desde entonces, han hecho de la descentralización un principio fundamental. Se centraron en almacenar todos los datos de las transacciones en Ethereum y elaboraron un modelo multioperador para manejar el modelo de descentralización del clasificador.

En junio de 2020, el equipo logró un progreso significativo con el lanzamiento de la red principal zkSync v1. zkSync v1 es un hito clave en el desarrollo de zkSync y representa la implementación real de su concepto original a mayor escala. Un año después, en junio de 2021, lograron un nuevo avance y lanzaron la red de prueba zkSync 2.0, también conocida como Era.

Para marzo de 2023, la red principal completa de zkSync se lanzó con éxito, lo que marca un gran logro para el equipo. Este desarrollo muestra que la plataforma ha alcanzado un alto nivel de madurez y está lista para una adopción más amplia. Este es el lanzamiento de la primera red principal zkEVM implementada en el ecosistema Ethereum Rollup.

Actualmente, el equipo está trabajando para hacer que zkSync sea de código abierto. Esto permitirá la implementación separada de cadenas de resumen zk desde dentro de un ZK-Stack, lo que permitirá a los equipos lanzar sus propios resumen personalizados. Se espera que pronto se anuncien más detalles sobre este emocionante desarrollo.

*** **** *' *** **

Matterlabs, el equipo de desarrollo detrás de zkSync, ha recaudado importantes fondos para avanzar en su misión. Con su ronda de la Serie C más reciente en noviembre de 2022, su financiación total llegó a $ 458 millones, que incluyeron múltiples rondas y fondos de ecosistemas dedicados, incluido, por ejemplo, un fondo de ecosistema dedicado separado de $ 200 millones, una Serie C de $ 200 millones, una Serie B de $ 50 millones liderado por a16z, y una Serie A de $ 8 millones y una ronda semilla.

· Ronda semilla: en la ronda semilla, Matterlabs recibió $2 millones en financiamiento de PlaceholderVC, Hashed y otros inversionistas. Este estímulo financiero inicial proporcionó la base necesaria para que su trabajo iniciara el proyecto zkSync.

Serie A: luego de su ronda inicial, Matterlabs ha recaudado $ 6 millones adicionales en fondos de la Serie A. Esta nueva entrada de capital proporciona el ímpetu para avanzar en su I+D y acercar a zkSync a su objetivo final.

Serie B: Matterlabs está cobrando impulso ya que lograron recaudar $ 50 millones en una ronda de Serie B liderada principalmente por a16z.

· Serie C: la ronda de financiamiento C de Matterlabs es de $200 millones.

Finalmente, además de las rondas de inversión anteriores, Matterlabs ha lanzado un fondo de ecosistema dedicado de $ 200 millones. Este fondo está dedicado a fomentar el crecimiento y desarrollo del ecosistema zkSync más amplio.

Todos estos recursos brindan a Matterlabs el apoyo financiero necesario para avanzar en la misión de zkSync, acelerar el ritmo de desarrollo y fomentar el crecimiento de un ecosistema más amplio. Con todo, Matterlabs tiene una cantidad considerable de fondos en importantes proyectos de blockchain.

2**、Estado actual del ecosistema zkSync**

2.1 Estado general

A lo largo de los años, zkSync ha logrado importantes avances en el desarrollo. zkSync v1, ahora zkSync Lite, alcanzó un hito de desarrollo en diciembre de 2020, superando el millón de dólares en valor total bloqueado (TVL). Desde entonces, el TVL del ecosistema zkSync ha crecido exponencialmente. A partir de ahora, el TVL de zkSync ha superado los $ 650 millones, lo que lo convierte en el tercer L2 Rollup más grande en el ecosistema Ethereum.

Para junio de este año, zkSync tenía algunas métricas clave impresionantes. Aunque zkSync fue ligeramente inferior a Arbitrum en junio, ocupó el primer lugar en TPS. Tiene la tasa de crecimiento de TVL más rápida y lidera el pago total de tarifas en el Nivel 1.

Además, la cantidad de billeteras únicas también está aumentando, lo que indica una mayor adopción por parte de los usuarios. Al mismo tiempo, la cantidad de ETH conectada a zkSync también está creciendo.

2.2 Artículos principales

2.2.1 Plata

Argent es una billetera móvil sin custodia para criptomonedas basadas en Ethereum, que brinda una experiencia segura y fácil de usar para administrar activos digitales.

Argent tiene un diseño de modo de seguridad único, incluso si el teléfono móvil del usuario se pierde o es robado, también puede proteger los activos del usuario. El modelo de seguridad incluye características como la autenticación biométrica, la recuperación social y las carteras de contratos inteligentes en cadena. V God, el fundador de Ethereum, también dijo que Argent es una billetera con seguridad de múltiples firmas y funciones de recuperación social.

2.2.2 Cambio de sincronización

SyncSwap es el protocolo DeFi más grande en la Era zkSync. Es un DEX basado en AMM que proporciona varias características importantes en el diseño de AMM. Proporciona un grupo AMM para varios tokens, las propiedades importantes son las siguientes.

Stableswap: el grupo múltiple permite que SyncSwap agregue múltiples modelos de grupo diferentes, cada uno con su propio escenario óptimo, lo que hace que las transacciones sean eficientes. El primer modelo de grupo que se implementará será Stable Pool. En comparación con el Classic Pool de uso general, Stable Pool admite transacciones eficientes de monedas estables, lo que permite a SyncSwap ingresar al mercado de monedas estables a gran escala.

· Enrutador inteligente: sirve como una plataforma de agregación de liquidez que agrega diferentes fondos de liquidez y varios modelos de fondos para ofrecer el mejor precio sin esfuerzo. Proporciona división de rutas y saltos múltiples.

Tarifas dinámicas: SyncSwap ha introducido tarifas dinámicas en su DEX, lo que permite a los usuarios personalizar las tarifas de transacción según las condiciones del mercado y las preferencias de la comunidad. Incluyendo tarifas variables, tarifas específicas, descuentos de tarifas y encomiendas de tarifas. Estas características brindan a los usuarios la flexibilidad y adaptabilidad para optimizar sus estrategias comerciales y mantenerse en sintonía con los mercados y las comunidades en constante cambio.

2.2.3 Tevaera

El ecosistema de juegos de Tevaera aporta una combinación única de aventura y tecnología al mundo de los juegos. Teva Games ofrece juegos en una variedad de géneros, ambientados en entornos naturales y conectados por una historia central de personajes Guardianes. El primer juego multijugador debutará con el lanzamiento de Tevaera 2.0, que ofrece un juego emocionante que incluye actualizaciones con temas criptográficos y múltiples modos de juego.

La infraestructura de juegos en cadena que consta de Teva Core, Teva Chain, Teva Dex y Teva Market mejora aún más el ecosistema.

· Teva Core es un marco de juego multijugador avanzado.

· Teva Chain es una hipercadena de juegos de tercera capa que facilita la transición a juegos de cadena completa.

· Teva DEX contribuye a una economía de juego sostenible a través de la dex de juego automática.

· Teva Market permite la acuñación y el comercio de caracteres NFT únicos.

3**, arquitectura zkSync**

zkSync Era es un protocolo L2 diseñado para resolver el problema de escalabilidad de Ethereum, utilizando una estructura acumulativa de conocimiento cero (ZK). Desarrollada por Matter Labs, es una plataforma zk-rollup enfocada en las necesidades del usuario. La plataforma está diseñada para ser ampliamente compatible con Ethereum Virtual Machine (EVM) en una máquina virtual personalizada, optimizada para pruebas de conocimiento cero.

El funcionamiento de zkSync rollup se puede resumir en las siguientes etapas:

(1) Inicialmente, las transacciones o acciones prioritarias son generadas por los usuarios.

(2) Posteriormente, el operador asume la responsabilidad de procesar la solicitud del usuario. Después de un procesamiento exitoso, el operador crea una operación de acumulación y la incluye en el bloque.

(3) Una vez que se completa el bloque, el operador lo envía al contrato inteligente zkSync en forma de envío de bloque. Vale la pena señalar que el contrato inteligente verifica parte de la lógica que ejecutan ciertos acumuladores.

(4) Finalmente, la prueba del bloqueo se proporciona al contrato inteligente zkSync, y este paso es la verificación del bloqueo. Si el contrato validador considera exitosa la validación, valida el nuevo estado como definitivo. Este es el ciclo de vida operativo del resumen zkSync.

Esta sección profundizará en cómo funciona zkSync, centrándose en tres capas básicas:

(1) Capa de ejecución: La capa de ejecución se refiere al proceso que conduce a cambios o transiciones en el estado de la cadena de bloques. En pocas palabras, es el lugar donde se reciben las transacciones y se aplican al estado anterior.

(2) Capa de liquidación: la capa de liquidación utiliza un sistema de prueba para garantizar que los cambios realizados durante la fase de ejecución reflejen con precisión el estado general del sistema.

(3) Capa de disponibilidad de datos: La capa de disponibilidad de datos es la parte de mantenimiento de registros del sistema. Es donde se almacenan todos los datos de transacciones (entradas), actualizaciones del sistema (salidas) y pruebas. El propósito es garantizar que el estado actual del sistema siempre se pueda recrear desde cero cuando sea necesario.

3.1 Capa de ejecución

3.1.1 Capa de ejecución a nivel de máquina virtual

Se ejecuta en type4 zkEVM, lo que significa que toma código de contrato inteligente escrito en un lenguaje de alto nivel (por ejemplo, Solidity, Vyper) y luego lo compila en un lenguaje compatible con zk-SNARK.

Además, una característica única de zkSync Era es que utiliza un compilador basado en LLVM que eventualmente permitirá a los desarrolladores escribir contratos inteligentes en C++, Rust y otros lenguajes populares.

El marco LLVM es un compilador para crear cadenas de herramientas de lenguaje de contratos inteligentes. Su representación intermedia (IR) de alto nivel permite a los desarrolladores diseñar, implementar y mejorar funciones eficientes específicas del idioma y, al mismo tiempo, aprovechar el amplio ecosistema LLVM.

En la cadena de herramientas establecida, LLVM procesa LLVM IR, introduce optimizaciones completas y, finalmente, pasa el IR optimizado al generador de código back-end de zkEVM.

3.1.2 Descripción general de la capa de ejecución

En zkSync, Core App (aplicación central) juega un papel clave en la gestión de la capa de ejecución.

Su responsabilidad principal es rastrear depósitos u operaciones prioritarias de contratos inteligentes L1. Este mecanismo es fundamental para garantizar la perfecta integración de zkSync con la red Ethereum, ya que todos los cambios iniciados desde la red Ethereum deben monitorearse y reflejarse en el entorno zkSync Layer 2 (L2).

La aplicación principal también es responsable de administrar el grupo de memoria (mempool) que recopila las transacciones entrantes. Esta colección de transacciones luego se coloca en una cola para ser procesada, actuando efectivamente como un área de espera antes de que las transacciones se confirmen y se agreguen a un bloque.

Las responsabilidades de la aplicación principal también incluyen obtener transacciones del mempool, ejecutarlas en una máquina virtual (VM) y ajustar el estado según sea necesario. Esencialmente, el proceso consiste en adquirir transacciones, procesarlas y reflejar los resultados en el sistema.

Después de ejecutar la transacción, la aplicación principal genera un bloque de cadena. Estos bloques consisten en paquetes de transacciones ejecutados y verificados. Luego, la aplicación Core envía estos bloques y pruebas al contrato inteligente L1. Este proceso garantiza que el estado de la cadena L1 Ethereum se mantenga sincronizado con la cadena L2 zkSync.

Para admitir una interacción fluida entre las aplicaciones basadas en Ethereum, proporciona una API web3 compatible con Ethereum. Esto hace que zkSync sea más accesible y fácil de usar para desarrolladores y usuarios expertos en el ecosistema Ethereum.

3.2 Capa de liquidación

La capa de liquidación es responsable de garantizar la integridad de las transiciones de estado de zkSync. Este proceso de verificación se realiza en un contrato inteligente implementado en Ethereum. Hay dos contratos importantes en este proceso.

(1) Contrato ejecutor: este contrato obtiene datos de bloque de validadores y pruebas zk de transiciones de estado en zkSync.

(2) Contrato verificador: Este es un contrato lógico que permite que el sistema verifique los datos del bloque y las pruebas zk proporcionadas por el contrato ejecutor.

3.2.1 Contrato ejecutor

La función proveBlocks juega un papel central para garantizar la integridad y seguridad del sistema zkSync. Su principal responsabilidad laboral es verificar las pruebas zk-SNARK de los bloques enviados. He aquí una breve descripción de cómo funciona:

Primero, proveBlocks asegura que los bloques se verifiquen en el orden correcto. Para ello, comprueba si el bloque anterior recibido es el siguiente bloque en la secuencia de la cadena de bloques que debe verificarse.

· A continuación, la función comienza a iterar sobre cada bloque enviado. Comprueba que los valores hash de estos bloques coincidan con el valor esperado en una ubicación particular de la cadena de bloques. Esto asegura que el bloque que se está verificando es de hecho el bloque correcto.

Luego, la función comienza a generar la matriz proofPublicInput, que se convierte en el valor de entrada público para el proceso de verificación de pruebas de zk-SNARK. El número de bloque para cada bloque comprometido está contenido en esta matriz.

Luego, usando la matriz proofPublicInput y algunos parámetros almacenados, la función verificará la prueba zk-SNARK. Es similar a resolver un rompecabezas, todas las piezas deben encajar perfectamente.

· Si se verifica la prueba, la función actualiza el sistema para reflejar que los bloques ahora están verificados. Es como poner una marca junto a un elemento en una lista de verificación.

Finalmente, para cada bloque verificado, la función activa un evento especial llamado BlockVerification. Es como enviar una notificación de que se han verificado el número de bloque, el hash y el compromiso.

En pocas palabras, la función proveBlocks actúa como un guardián vigilante, asegurando que los bloques se verifiquen en el orden correcto, asegurando que las pruebas de zk-SNARK sean precisas y actualizando el estado del sistema en consecuencia. Su objetivo es evitar que se ejecuten bloques no válidos, lo que garantiza la seguridad e integridad generales del sistema zkSync.

3.2.2****Contrato de verificador

El contrato del verificador es el lugar para implementar la lógica de verificación anterior. Actúa como un protector para zkSync al verificar las pruebas de zk-SNARK para verificar los datos comprometidos. El contrato de validación se utiliza para verificar si los datos enviados a zkSync son válidos.

El contrato del verificador almacena la "clave de verificación", que se utiliza para verificar las pruebas de zk-SNARK. Cada vez que zkSync desea realizar una actualización, genera una prueba de zk-SNARK y la envía al contrato de validación a través del contrato de ejecución.

El contrato del validador luego usa la clave de validación para verificar que la prueba sea válida. Si funciona, sabrá que la actualización es legítima sin mirar los datos reales. Si no es válido, la actualización será rechazada.

Al verificar estas pruebas, el contrato del validador garantiza que solo se reciban datos correctos y válidos en zkSync. Esto es fundamental para la seguridad y para evitar actualizaciones de estado no válidas.

3.3 Capa de disponibilidad de datos

La capa de disponibilidad de datos del sistema actúa como un archivo, almacenando toda la información de transacciones (entradas), cambios en el sistema (salidas) y pruebas. zkSync utiliza una interfaz de contrato inteligente para establecer su política de disponibilidad de datos (DA). zkSync planea brindar múltiples opciones de disponibilidad de datos para reducir costos y proteger la privacidad.

3.3.1 zkPortero

zkSync lanzó una solución de disponibilidad de datos fuera de la cadena llamada "zkPorter". La herramienta está diseñada para integrarse con el sistema de acumulación de zkSync, lo que facilita las interacciones entre las acumulaciones y las cuentas de zkPorter. Para garantizar la seguridad de los datos dentro de zkPorter, los "guardianes" (individuos que apuestan tokens zkSync y verifican la disponibilidad de los datos mediante la firma de bloques) están habilitados.

zkPorter funciona como un protocolo de consenso interno, lo que facilita el rendimiento masivo de transacciones. En comparación, el modo ZK Rollup estándar en zkSync 2.0 es capaz de procesar alrededor de 1000 a 5000 transacciones por segundo (TPS). zkPorter puede gestionar de 20 000 a 100 000 TPS, dependiendo de la complejidad de la transacción.

Una desventaja de usar zkPorter es que los usuarios deben confiar en el mecanismo de consenso interno de zkSync. Esto conduce a una solución de acumulación menos descentralizada. La consideración del usuario es elegir entre zkPorter (menor costo pero menos seguro) o el modo ZK-rollup (mayor seguridad).

Además, zkSync 2.0 facilita la interoperabilidad, lo que permite intercambios fluidos entre cuentas ZK-rollup y zkPorter. La diferencia fundamental entre zkPorter y Starkware Volition es la determinación de la disponibilidad de los datos: en zkPorter, esta decisión se toma por cuenta, mientras que en Volition esta decisión se toma por transacción individual dentro de una cuenta.

4**, pila ZK y pila OP**

Recientemente, Matter Labs anunció el próximo lanzamiento de ZK-Stack. ZK-Stack proporcionará un software similar a OP-Stack para personalizar y operar el resumen.

Las características comunes de OP-Stack y ZK-Stack son las siguientes:

Gratis y de código abierto: Ambos están desarrollados bajo una licencia de código abierto, lo que garantiza el acceso gratuito. Animan a los desarrolladores a contribuir construyendo sobre el software.

Interoperabilidad: el concepto de hipercadena Hyperchain de ZK Stack se puede conectar sin esfuerzo en una red sin confianza con baja latencia y liquidez compartida. Además, OP-Stack prevé un concepto de Superchain para conectar todas las cadenas basadas en OP-Stack.

· Descentralización: para lograr una red y una comunidad más descentralizadas, tanto OP-Stack como ZK-Stack han propuesto claramente un plan de descentralización en la hoja de ruta reciente. Este movimiento no solo aumenta la resiliencia de la red, sino que también garantiza una distribución más justa del poder y el control.

A pesar de las similitudes desde una perspectiva conceptual, existen diferencias desde una perspectiva técnica y comercial. Esta sección profundizará en las diferencias entre las siguientes perspectivas.

(1) desarrolladores de dapps

(2) Desarrolladores principales

(3) Negocios

4.1****Perspectiva del desarrollador de Dapp

4.1.1 Equivalencia EVM

Implementación de EVM de OP-Stack: EVM de OP-Stack se implementa haciendo cambios menores en el geth de Ethereum, lo que hace que el sistema sea casi totalmente compatible con EVM. Por otro lado, ZK-Stack incorpora algunos cambios en los códigos de operación EVM y algunos códigos de operación aún no son compatibles. A pesar de estos cambios, el impacto ha sido mínimo y los proyectos han sido rigurosamente probados y validados en el mundo real.

Sin embargo, ha habido incidentes debido a la equivalencia no EVM de ZK-Stack. Un ejemplo notable es 921 ETH atrapado en un contrato inteligente porque el contrato utiliza la función de transferencia. Este problema ha sido resuelto de manera efectiva.

4.1.2 Abstracción de cuentas nativas

A diferencia de ERC-4337, la arquitectura de ZK-Stack incluye una función de abstracción de cuenta (AA) nativa. En un sistema como ERC-4337, es necesario tener un mempool separado de UserOps para permitir la abstracción de cuentas en la red.

4.1.3 Soporte de privacidad

Mediante el uso de validum, el almacenamiento de los datos en una base de datos confidencial garantiza la privacidad bajo la premisa de que el operador mantiene la confidencialidad de los datos del bloque. Esta característica es especialmente beneficiosa para los usuarios empresariales.

4.2 Perspectiva del desarrollador principal

4.2.1 Operación de infraestructura: OP-Stack es más intuitivo

Operación: tanto zkSync como OP-Stack usan un secuenciador para coordinar transacciones y almacenar datos en Ethereum. Sin embargo, zkSync requiere un probador para funcionar. Esta aplicación de prueba procesa bloques generados por el servidor y los metadatos asociados para construir pruebas de validez de conocimiento cero. Por el contrario, OP-Stack no requiere una infraestructura compleja separada para participar en el juego de desafío de prueba.

4.2.2 Alternativas de VM: ZK-Stack tiene más potencial para proporcionar varias opciones

zkSync se ejecuta con el compilador LLVM, que se traduce en código de bytes zkEVM, lo que muestra el potencial para crear entornos de ejecución utilizando otros lenguajes, como C++.

4.2.3 Disponibilidad de datos: ZK-Stack ofrece múltiples opciones

La capa de disponibilidad de datos de OP-Stack se basa principalmente en Ethereum, donde se almacena toda la información de transacciones y las raíces del estado de salida. Esto conduce a un alto costo de operación de la cadena OP-Stack. Sin embargo, ha habido intentos de compensar este costo almacenando datos de transacciones en Celestia DA.

ZK-Stack está investigando y desarrollando intensamente alternativas a las soluciones de disponibilidad de datos como zkPorter. Este enfoque permite a los usuarios determinar su propia disponibilidad de datos en función de su preferencia por mayor seguridad o menor costo. Además, las empresas que deseen mantener la privacidad de los datos pueden emplear soluciones como Validium que admiten el almacenamiento de datos que no se ve comprometido.

4.3 Perspectiva Comercial: Costos y Beneficios

Hoy en día, lanzar acumulaciones independientes es una opción viable, especialmente porque el software de código abierto como ZK-Stack y OP-Stack se desarrolla y mantiene públicamente. Además, las plataformas Rollup-as-a-Service (RaaS) como Caldera y Conduit simplifican enormemente el proceso.

Más allá de la perspectiva del desarrollador, es fundamental evaluar de manera realista los costos y beneficios potenciales asociados con las operaciones de consolidación. Sin embargo, pronosticar estos montos puede ser complicado debido a varias variables.

A medida que se realizan mejoras importantes en el código base de manera regular, como se vio en la reciente actualización de Optimism's Bedrock, los costos asociados con la ejecución de resúmenes están disminuyendo rápidamente. Esta dinámica dificulta la estimación precisa de costos y beneficios. Además, los costos específicos asociados con los servidores y la infraestructura no son muy conocidos, ya que una sola entidad suele administrar todo el paquete acumulativo. Finalmente, las fluctuaciones en el precio del token subyacente (como zkSync y ETH de Optimism) agregan otra capa de incertidumbre, ya que los costos pueden fluctuar según el sentimiento del mercado.

Algunos de los principales costos y beneficios son los siguientes:

4.3.1 Costo

· Costo de liberación de L1: el costo de almacenar transacciones, estado de raíces y datos de prueba. Por lo general, un resumen optimista es más costoso de emitir porque requiere almacenar datos de transacciones sin procesar para la validación. Algunos resúmenes publican diferencias de estado en lugar de datos de estado completo para evitar costos adicionales.

· Costo de funcionamiento del clasificador L2.

Costo de prueba: para zk, es el costo de generación y verificación de prueba; para prueba de fraude, es el costo de impugnación de prueba.

4.3.2 Beneficios

· Tarifas de transacción L2

Posiblemente MEV, pero para evitar problemas de centralización, la mayoría de los clasificadores L2 conocidos no extraen MEV.

5. Conclusión

Matterlabs ha estado trabajando en el desarrollo de zkEVM y ha logrado avances significativos. Aunque no es completamente compatible con EVM (Type4 EVM), explotar LLVM parece tener un gran potencial. La próxima fase de los planes de Matterlabs es lanzar ZK-Stack, una base de código que permitirá a los desarrolladores aprovechar su sólida base de código para crear sus propios paquetes acumulativos. La herramienta promete claras ventajas sobre OP-Stack, especialmente en términos de protección de la privacidad y escalabilidad.

Sin embargo, ambos proyectos aún se encuentran en sus primeras etapas y queda mucho trabajo por hacer. Una evaluación exhaustiva de la estructura de costos y beneficios asociada con la implementación es fundamental. Además, un desafío importante radica en cultivar un ecosistema de desarrolladores en torno a estas dos bases de código. El análisis detallado y la planificación estratégica son esenciales para garantizar el desarrollo sostenible de la plataforma y sus tecnologías asociadas.

Espero que ambos proyectos prosperen y que la construcción de código abierto y las hojas de ruta compartidas se conviertan en la norma en el espacio web3.