Blockchain (sustantivo): Una máquina de coordinación que permite a los participantes de todo el mundo colaborar a lo largo de un conjunto de reglas comúnmente acordadas sin la intervención de terceros.

Las computadoras están diseñadas para hacer tres cosas: almacenar datos, computar y comunicarse entre sí y con los humanos. Las blockchains añaden una cuarta dimensión: garantías adicionales de que estas tres cosas (almacenamiento, computación y comunicación) sucedan de manera acordada. Estas garantías permiten la cooperación entre extraños sin la necesidad de un tercero de confianza que la facilite (descentralizado).

Estas garantías adicionales pueden ser tanto económicas (teoría del juego de confianza e incentivos/desincentivos) como criptográficas (matemática de confianza), pero la mayoría de las aplicaciones utilizan una combinación de ambas, criptoeconómicas. Esto actúa como un fuerte contraste con el estado actual de sistemas en gran medida basados en la reputación.

Si bien Web3 se describe a menudo como "leer, escribir, poseer", creemos que una mejor noción para la tercera iteración de Internet es "leer, escribir, verificar", dado que el principal beneficio de las blockchains públicas es cálculo garantizadoy una verificación fácil de que estas garantías fueron cumplidas. La propiedad puede ser un subconjunto de la computación garantizada si construimos artefactos digitales que pueden ser comprados, vendidos y controlados. Sin embargo, muchos casos de uso de las blockchains se benefician de la computación garantizada pero no implican directamente la propiedad. Por ejemplo, si tu salud en un juego completamente en cadena es 77/100, ¿posees esa salud o simplemente es ejecutable en cadena de acuerdo con reglas comúnmente acordadas? Nosotros argumentaríamos lo último, peroChris Dixonpodría estar en desacuerdo.

Web3 = Leer, Escribir, Verificar

ZK y Modularidad - Dos Tendencias Que Acelerarán

Las blockchains ofrecen mucho de qué emocionarse, pero el modelo descentralizado también agrega sobrecarga e ineficiencia a través de funciones adicionales como el mensajería P2P y el consenso. Además, la mayoría de las blockchains aún validan transiciones de estado correctas mediante reejecución, lo que significa que cada nodo en la red debe reejecutar transacciones para verificar la corrección de la transición de estado propuesta. Esto es derrochador y contrasta claramente con el modelo centralizado donde solo una entidad ejecuta. Si bien un sistema descentralizado siempre contiene algo de sobrecarga y replicación, el objetivo debería ser acercarse asintóticamente a un punto de referencia centralizado en términos de eficiencia.

Aunque la infraestructura subyacente ha mejorado significativamente en la última década, todavía queda mucho trabajo por hacer antes de que las blockchains puedan manejar una escala a nivel de Internet. Vemos compensaciones a lo largo de dos ejes principales - expresividad y dureza - y creemos que la modularidad permite una experimentación más rápida a lo largo de la frontera de compensación mientras ZK la expande:

• Expresividad - ¿Sobre qué puedes crear garantías? Contiene escalabilidad (costo, latencia, rendimiento, etc.), privacidad (o gestión del flujo de información), programabilidad y composabilidad.
• Dureza: ¿Qué tan sólidas son estas garantías? Contiene seguridad, descentralización y seguridad de usuario y código.

La modularidad es el grado en que los componentes de un sistema pueden separarse y recombinarse. A través de bucles de retroalimentación más rápidos y barreras de entrada más bajas con menos capital requerido (tanto económico como humano), la modularidad permite experimentación más rápida y especialización. La cuestión de modular vs integrado no es binaria, sino más bien un espectro para experimentar y descubrir qué partes tiene sentido desacoplar y cuáles no.

Las Pruebas de Conocimiento Cero, o ZKPs, por otro lado, permiten a una parte (el probador) demostrar a otra parte (el verificador) que saben que algo es cierto, sin revelar ninguna información adicional más allá de su validez. Esto puede aumentar la escalabilidad y eficiencia al evitar la reejecución (pasando de un modelo de ejecución total a verificar, a un modelo de uno ejecuta, todos verifican), así como la expresividad al permitir la privacidad (con limitaciones). Las ZKPs también mejoran la dificultad de las garantías al reemplazar garantías criptoeconómicas más débiles por otras más fuertes, lo que se representa al empujar la frontera de compensación hacia afuera (haciendo referencia al gráfico anterior).

Creemos que tanto la modularidad como la 'ZKficación de todo' son tendencias que seguirán acelerándose. Si bien ambas proporcionan lentes interesantes a través de las cuales explorar el espacio individualmente, estamos particularmente interesados en la intersección de las dos. Las dos preguntas clave en las que estamos interesados son:

1. ¿Qué partes de la pila modular ya han incorporado ZKPs y cuáles están aún por explorar?
2. ¿Qué problemas podrían ser aliviados con ZKPs?

Sin embargo, antes de poder abordar esas preguntas, necesitamos una vista actualizada de cómo se ve la pila modular en 2024.

Pila modular en 2024

La imagen a menudo utilizada del stack modular con cuatro componentes (ejecución, publicación de datos, consenso, liquidación) es útil como un modelo mental simple, pero no sentimos que sea una representación adecuada en este momento, dada la evolución del espacio modular. Un desglose adicional conduce a nuevos componentes que anteriormente se pensaban como parte de una pieza más grande, al mismo tiempo que crea nuevas dependencias y la necesidad de una interoperabilidad segura entre los diferentes componentes (más sobre esto más adelante). Dado el ritmo al que avanza el espacio, puede ser difícil mantenerse actualizado sobre todas las innovaciones en diferentes niveles del stack.

Intentos anteriores de explorar la pila web3 incluyen los realizados por Kyle Samani(Multicoin) - originalmente publicado en2018 y actualizado en 2019. Cubre todo, desde el acceso a Internet descentralizado de última milla (como Helium) para la gestión de claves del usuario final. Si bien los principios detrás de esto podrían ser reciclados, algunas piezas, como la prueba y verificación, están completamente ausentes.

Con esto en mente, hemos intentado crear una representación actualizada de cómo se ve la pila modular en 2024, ampliando la pila modular existente de cuatro partes. Está dividido por componente en lugar de funcionalidad, lo que significa que la red P2P, por ejemplo, está incluida en el consenso en lugar de dividirla como un componente separado, principalmente porque es difícil construir un protocolo en torno a ella.

ZK En La Pila Modular

Ahora que tenemos una vista actualizada de la pila modular, podemos comenzar a analizar la pregunta real, es decir, qué partes de la pila ZK ya ha penetrado y qué problemas abiertos podrían resolverse introduciendo ZK (ya sea evitando la reejecución o características de privacidad). A continuación se muestra un resumen de nuestros hallazgos, antes de profundizar en cada componente por separado.

1 - Abstracción de Operación de Usuario

Los usuarios actuales de las cadenas de bloques necesitan navegar por múltiples cadenas, billeteras e interfaces, lo cual es engorroso y actúa como fricción para una adopción más amplia. La abstracción de operaciones de usuario es un término general para cualquier intento de abstraer esta complejidad y permitir a los usuarios interactuar con solo una interfaz (por ejemplo, una aplicación o billetera específica), con toda la complejidad ocurriendo en el backend. Algunos ejemplos de abstracciones a nivel de infraestructura incluyen:

• La abstracción de cuenta (AA) permite que los contratos inteligentes realicen transacciones sin necesidad de firmas de usuario para cada operación (“cuenta de cripto programable”). Se puede utilizar para definir quién puede firmar (administración de claves), qué firmar (carga útil tx), cómo firmar (algoritmo de firma) y cuándo firmar (condición de aprobación de la transacción). Combinadas, estas características permiten cosas como el uso del inicio de sesión social para interactuar con dApps, 2FA, recuperación de cuentas y automatización (firma de tx automáticamente). Si bien la discusión a menudo se centra en Ethereum (ERC-4337pasado en la primavera de 2023), muchas otras cadenas ya tienen abstracción de cuenta incorporada y nativa (Aptos, Sui, Cerca, ICP, Starknet, y zkSync).
• La Abstracción de Cadenas permite a los usuarios firmar transacciones en diferentes cadenas mientras solo interactúan con una cuenta (una interfaz, múltiples cadenas). Varios equipos están trabajando en esto, incluyendo Cerca, ICP, y dWalletEstas soluciones aprovechan MPC y firmas en cadena, donde la clave privada de la otra red se divide en varias piezas pequeñas y se comparte entre validadores en la cadena de origen que firman las transacciones entre cadenas. Cuando los usuarios quieren interactuar con otra cadena, un número suficiente de validadores necesita firmar la transacción para satisfacer el cifrado de umbral. Esto mantiene la seguridad, ya que la clave privada nunca se comparte por completo en ningún lugar. Sin embargo, enfrenta el riesgo de colusión de validadores, razón por la cual la seguridad criptoeconómica y la descentralización de validadores de la cadena subyacente siguen siendo muy relevantes.
• Los intents, a un alto nivel, permiten la vinculación de deseos y necesidades del usuario en operaciones que pueden ser ejecutadas por una cadena de bloques. Esto requiere solucionadores de intents: agentes especializados fuera de la cadena encargados de encontrar la mejor solución posible para el intento del usuario. Ya existen varias aplicaciones que utilizan intents especializados, como los agregadores DEX ("mejor precio") y los agregadores de puentes ("puentes más baratos/rápidos"). Redes generales de liquidación de intentsAnoma, Esencial, Suave) apuntar a hacer más fácil para los usuarios expresar intenciones más complicadas y para que los desarrolladores construyan aplicaciones centradas en intenciones. Sin embargo, todavía hay muchas preguntas abiertas, incluyendo cómo formalizar el proceso, cómo sería un lenguaje centrado en intenciones, si siempre existe una solución óptima y si se puede encontrar.

Integraciones ZK existentes

• Autenticación usando AA x ZK: Un ejemplo de esto es Sui’szkInicio, que permite a los usuarios iniciar sesión utilizando credenciales familiares como una dirección de correo electrónico. Utiliza ZKPs para evitar que terceros vinculen una dirección Sui con su identificador OAuth correspondiente.
• Una verificación de firma más eficiente para las carteras AA: Verificar transacciones en contratos AA puede ser significativamente más costoso que aquellas iniciadas por una cuenta tradicional (EOA).Orbitertrata de abordar esto con un servicio de empaquetado que aprovecha ZKPs para verificar la corrección de las firmas de transacción y mantiene el valor de nonce y el saldo de gas de la cuenta AA (a través de un árbol de estado mundial de Merkle). Con la ayuda de la agregación de pruebas y compartiendo el costo de verificación en cadena de manera equitativa entre todos los usuarios, esto puede llevar a ahorros significativos de costos.

Problemas Abiertos Que las ZKPs Podrían Resolver

• Prueba de mejor ejecución o cumplimiento de intenciones: Si bien las intenciones y AA pueden abstraer la complejidad de los usuarios, también pueden actuar como una fuerza centralizadora y requerir que confiemos en actores especializados (solvers) para encontrar caminos de ejecución óptimos. En lugar de simplemente confiar en la buena voluntad del solucionador, las pruebas de conocimiento cero (ZKPs) podrían usarse potencialmente para demostrar que se eligió el camino óptimo para el usuario entre los muestreados por el solucionador.
• Privacidad para liquidación de intenciones: Protocolos como Taigapretende habilitar el liquidación de intenciones completamente protegido para preservar la privacidad de los usuarios, como parte de un movimiento más amplio hacia la adición de privacidad (o al menos confidencialidad) a las redes blockchain. Utiliza ZKPs (Halo2) para ocultar información sensible sobre las transiciones de estado (tipos de aplicación, partes involucradas, etc).
• Recuperación de contraseña para carteras AA: La idea detrásesta propuestaes permitir a los usuarios recuperar sus billeteras si pierden sus claves privadas. Al almacenar un hash (contraseña, nonce) en la billetera del contrato, los usuarios pueden generar un ZKP con la ayuda de su contraseña para verificar que es su cuenta y solicitar un cambio de la clave privada. Un período de confirmación (3 días o más) sirve como salvaguardia contra intentos de acceso no autorizados.

2 - Secuenciación

Las transacciones deben ser ordenadas antes de ser agregadas a un bloque, lo que se puede hacer de muchas maneras: ordenándolas por rentabilidad para el proponente (transacciones más rentables primero), en el orden en que fueron enviadas (primero en entrar, primero en salir), dando prioridad a las transacciones de las mempools privadas, etc.

Otra pregunta es quién realiza los pedidos de las transacciones. En un mundo modular, múltiples partes diferentes pueden hacer esto, incluido el secuenciador de rollup (centralizado o descentralizado), la secuenciación L1 (basada en rollups) y una red de secuenciación compartida (red descentralizada de secuenciadores utilizada por múltiples rollups). Todos ellos tienen diferentes suposiciones de confianza y capacidades para escalar. En la práctica, la ordenación real de transacciones y su agrupación en un bloque también puede ser realizada fuera del protocolo por actores especializados (blockbuilders).

Integraciones existentes de ZK

• Verificando la codificación correcta del mempool: Radioes una red de secuenciación compartida que tiene un mempool encriptado con Encriptación de Retraso Verificable Práctica (PVDE). Los usuarios generan una ZKP que se utiliza para demostrar que resolver los rompecabezas de bloqueo de tiempo conducirá a la descifrado correcto de transacciones válidas, es decir, que la transacción incluye una firma y un nonce válidos y que el remitente tiene suficiente saldo para pagar la tarifa de transacción.

Problemas Abiertos Que las ZKPs Podrían Resolver

• Reglas de secuenciación verificables (VSR): Sometiendo al proponente/ordenador a conjunto de reglas sobre el orden de ejecucióncon garantías adicionales de que se sigan estas reglas. La verificación puede realizarse a través de ZKPs o pruebas de fraude, de las cuales estas últimas requieren un bono económico suficientemente grande que se reduce si el proponente/ordenador se comporta mal.

3 - Ejecución (Escalado de Escrituras)

La capa de ejecución contiene la lógica de cómo se actualiza el estado y es donde se ejecutan los contratos inteligentes. Además de devolver una salida de la computación, zkVMs también permiten demostrar que las transiciones de estado se realizaron correctamente. Esto permite a otros participantes de la red verificar la ejecución correcta solo verificando la prueba, en lugar de tener que volver a ejecutar las transacciones.

Además de una verificación más rápida y eficiente, otro beneficio de la ejecución comprobable es permitir una computación más compleja, ya que no te encuentras con los problemas típicos de gas y recursos limitados en cadena con la computación fuera de cadena. Esto abre la puerta a aplicaciones completamente nuevas que son computacionalmente más intensas para ejecutar en blockchains y aprovechar la computación garantizada.

Integraciones ZK existentes

• zkEVM rollups: Un tipo especial de zkVM optimizado para ser compatible con Ethereum y demostrar el entorno de ejecución de EVM. Sin embargo, cuanto más cercana sea la compatibilidad con Ethereum, mayor será el compromiso en el rendimiento. Varios zkEVMs se lanzaron en 2023, incluyendo Polygon zkEVM, Era zkSync, Desplazarse, y Linea. Recientemente, Polygon anunció su tipo 1 probador zkEVM, que permite demostrar bloques mainnet de Ethereum por $0.20-$0.50 por bloque (con futuras optimizaciones para reducir aún más los costos).RiscZero también tiene una soluciónque permite probar bloques de Ethereum pero a un costo más alto con la limitada referencia disponible.
• zkVMs alternativos: Algunos protocolos están tomando un camino alternativo y optimizando el rendimiento/comprobaciónStarknet, Zorp) o amigabilidad para desarrolladores, en lugar de tratar de ser maximalmente compatible con Ethereum. Ejemplos de esto último incluyen protocolos zkWASM (Fluido, Delphinus Labs) y zkMOVE (M2yzkmove).
• zkVMs centrados en la privacidad: En este caso, las ZKP se utilizan para dos cosas: evitar la reejecución y lograr privacidad. Si bien la privacidad que se puede lograr solo con ZKP es limitada (solo estado privado personal), los protocolos próximos agregan mucha expresividad y programabilidad a las soluciones existentes. Ejemplos incluyen Aleo’s snarkVM, AztecaAVM, y de Polygon’sMidenVM.
• ZK-coprocesadores: permite la computación fuera de la cadena en los datos de la cadena (pero sin estado). Se utilizan pruebas de conocimiento cero para demostrar la ejecución correcta, lo que permite un asentamiento más rápido que los co-procesadores optimistas, pero existe un compromiso en costos. Dado el costo y/o la dificultad de generar ZKPs, estamos viendo algunas versiones híbridas, como Brevis coChain, que permite a los desarrolladores elegir entre el modo ZK u optimista (compromiso entre el coste y la dificultad de las garantías).

Problemas abiertos que las ZKPs podrían resolver

• zkVM consagrado: La mayoría de las capas base (L1s) todavía utilizan la reejecución para verificar las transiciones de estado correctas. Consagrar un zkVM a la capa base evitaría esto, ya que los validadores podrían verificar la prueba en su lugar. Esto mejorarían la eficiencia operativa. La mayoría de las miradas están puestas en Ethereum con un zkEVM consagrado, pero muchos otros ecosistemas también dependen de la reejecución.
• zkSVM: Mientras que el SVM se usa principalmente dentro de Solana L1 hoy en día, equipos como Eclipse están tratando de aprovechar el SVM para rollups que se liquidan en Ethereum. Eclipse también planea usar Risc Zero para pruebas de fraude ZKpara posibles desafíos de transiciones de estados en el SVM. Sin embargo, un zkSVM completo aún no ha sido explorado, probablemente debido a la complejidad del problema y al hecho de que el SVM está optimizado para otras cosas que no sea la demostrabilidad.

4 - Consulta de datos (lecturas escalables)

La consulta de datos, o la lectura de datos desde la cadena de bloques, es una parte esencial de la mayoría de las aplicaciones. Si bien gran parte de la discusión y los esfuerzos de los últimos años se han centrado en escalar las escrituras (ejecución), escalar las lecturas es aún más importante debido al desequilibrio entre las dos (especialmente en un entorno descentralizado). La relación entre lectura/escritura difiere entre las cadenas de bloques, pero un punto de datos es Estimación de Sigque más del 96% de todas las llamadas a los nodos en Solana eran llamadas de lectura (según 2 años de datos empíricos) - una proporción de lectura/escritura de 24:1.

El escalado de lecturas incluye tanto obtener más rendimiento (más lecturas por segundo) con clientes validadores dedicados (como Sig en Solana) como habilitar consultas más complejas (combinando lecturas con cálculos), por ejemplo con la ayuda de co-procesadores.

Otro ángulo es descentralizar los métodos de consulta de datos. Hoy en día, la mayoría de las solicitudes de consulta de datos en blockchains son facilitadas por terceros de confianza (basados en reputación), como nodos RPC (Infura) y indexadores (Dune). Ejemplos de opciones más descentralizadas incluyen El Gráfico y operadores a prueba de almacenamiento (que también son verificables). También existen varios intentos de crear una red RPC descentralizada, como Infura DIN o Red Lava(además del RPC descentralizado, Lava tiene como objetivo ofrecer más adelante servicios adicionales de acceso a datos).

Integraciones ZK existentes

• Pruebas de almacenamiento: Permite consultar tanto datos históricos como actuales de blockchains sin necesidad de usar terceros de confianza. Se utilizan ZKPs para la compresión y para demostrar que se ha recuperado la información correcta. Ejemplos de proyectos que se están desarrollando en este espacio incluyen Axioma, Brevis, Herodoto, y Lagrange.

Problemas abiertos que las ZKP podrían resolver

• Consulta eficiente del estado privado: Los proyectos de privacidad a menudo utilizan una variación del modelo UTXO, que permite mejores características de privacidad que el modelo de cuenta pero a expensas de la facilidad de uso para los desarrolladores. El modelo privado de UTXO también puede llevar a problemas de sincronización - algo Zcash ha luchado condesde 2022 después de experimentar un aumento significativo en el volumen de transacciones protegidas. Las carteras deben sincronizarse con la cadena antes de poder gastar fondos, por lo que este es un desafío bastante fundamental para el funcionamiento de la red. Anticipándose a este problema,Aztec recientemente publicó una solicitud de propuestaspara ideas sobre el descubrimiento de notas pero aún no se ha encontrado una solución clara.

5 - Demostrando

Con cada vez más aplicaciones que incorporan ZKPs, la prueba y verificación se están convirtiendo rápidamente en una parte esencial del stack modular. Sin embargo, hoy en día, la infraestructura de pruebas sigue siendo en su mayoría permisiva y centralizada, con muchas aplicaciones dependiendo de un único probador.

Mientras que la solución centralizada es menos compleja, descentralizar la arquitectura de prueba y dividirla en un componente separado en la pila modular trae varios beneficios. Un beneficio clave se presenta en forma de garantías de vivacidad que son cruciales para aplicaciones que dependen de la generación frecuente de pruebas. Los usuarios también se benefician de una mayor resistencia a la censura y de tarifas más bajas impulsadas por la competencia y el reparto de la carga de trabajo entre múltiples probadores.

Creemos que las redes de demostradores de propósito general (muchas aplicaciones, muchos demostradores) son superiores a las redes de demostradores de una sola aplicación (una aplicación, muchos demostradores) debido a una mayor utilización del hardware existente y menos complejidad para los demostradores. Una mayor utilización también beneficia a los usuarios en términos de tarifas más bajas, ya que los demostradores no necesitan ser compensados por la redundancia a través de tarifas más altas (aún necesitan cubrir costos fijos).

Figment Capitalproporcionó una buena visión general del estado actual de la cadena de suministro de pruebas, que consta tanto de la generación de pruebas como de la agregación de pruebas (que en sí misma es generación de pruebas, pero simplemente tomando dos pruebas como entrada en lugar de la traza de ejecución).

Fuente: Capital de Figment

Integraciones ZK existentes

• STARK con envoltura SNARK: los probadores de STARK son rápidos y no requieren una configuración confiable, pero la desventaja es que producen pruebas grandes que son prohibitivamente caras de verificar en Ethereum L1. Envolver el STARK en un SNARK como paso final hace que sea significativamente más barato verificar en Ethereum. Por otro lado, esto agrega complejidad, y la seguridad de estos 'sistemas de prueba compuestos' no ha sido estudiada en profundidad. Ejemplos de implementaciones existentes incluyen Polygon zkEVM, Boojum en la era zkSync, y RISC Zero.
• Redes de prueba descentralizadas de propósito general: Integrar más aplicaciones en una red de prueba descentralizada la hace más eficiente para los probadores (mayor utilización de hardware) y más barata para los usuarios (no necesitan pagar por la redundancia de hardware). Los proyectos en este campo incluyen GevulotySucinto.

Problemas abiertos que las ZKP podrían resolver

• Pruebas de Fraude ZK: En soluciones optimistas, cualquiera puede desafiar la transición de estado y crear una prueba de fraude durante el período de desafío. Sin embargo, verificar la prueba de fraude sigue siendo bastante engorroso ya que se realiza mediante reejecución. Las pruebas de fraude ZK tienen como objetivo resolver este problema creando una prueba de la transición de estado que está siendo desafiada, lo que permite una verificación más eficiente (sin necesidad de reejecución) y posiblemente una liquidación más rápida. Esto está siendo trabajado por al menos Optimismo(en colaboración con O1 Labs y RiscZero), yAltLayer x RiscZero.
• Una agregación de pruebas más eficiente: Una gran característica de las pruebas de conocimiento nulo es que puedes agregar varias pruebas en una sola prueba, sin aumentar significativamente los costos de verificación. Esto permite amortizar el costo de verificación en varias pruebas o aplicaciones. La agregación de pruebas también está demostrando, pero la entrada son dos pruebas en lugar de una traza de ejecución. Ejemplos de proyectos en este espacio incluyen NEBRAyGevulot.

Fuente: Figment Capital

6 - Publicación de datos (Disponibilidad)

La publicación de datos (DP) garantiza que los datos estén disponibles y sean fácilmente recuperables durante un corto período (1-2 semanas). Esto es crucial tanto para la seguridad (los rollups optimistas requieren datos de entrada para verificar la ejecución correcta mediante la reejecución durante el período de desafío, 1-2 semanas) como para la vitalidad (incluso si un sistema utiliza pruebas de validez, es posible que se necesiten datos de transacciones subyacentes para demostrar la propiedad de activos para las salidas de emergencia, transacciones forzadas o para verificar que las entradas coincidan con las salidas). Los usuarios (como los puentes zk y los rollups) enfrentan un pago único, que cubre el costo de almacenar transacciones y estado durante un corto período hasta que se elimine. Las redes de publicación de datos no están diseñadas para el almacenamiento de datos a largo plazo (en su lugar, consulte la siguiente sección para posibles soluciones).

Celestia fue la primera capa de DP alternativa en lanzar su red principal (31 de octubre), pero pronto habrá muchas alternativas para elegir como Disponible, EigenDA, y Cerca de DAse espera que todos se lancen durante 2024. Además, EIP 4844 de Ethereummejorar la publicación de datos escalados en Ethereum (además de crear un mercado de tarifas separado para el almacenamiento de bloques) y preparar el escenario para la fragmentación completa de dank. DP también se está expandiendo a otros ecosistemas - un ejemplo es @nubit_org/riema-secures-angel-investment-for-launching-the-first-bitcoin-native-data-availability-layer-49ccf0487380">Nubit, que tiene como objetivo construir Native DP en Bitcoin.

Muchas soluciones de DP también ofrecen servicios más allá de la mera publicación de datos, incluida la seguridad compartida para rollups soberanos (como Celestia y Disponible) o una interoperabilidad más fluida entre rollups (como Avail'sNexus). También hay proyectos (DomiconyGravedad Cero) que ofrecen tanto la publicación de datos como el almacenamiento a largo plazo, lo cual es una propuesta convincente. Esto también es un ejemplo de volver a agrupar dos componentes en la pila modular, algo que probablemente veremos más en el futuro (experimentación tanto con una mayor desagregación como con una reagrupación).

Integraciones ZK existentes

• Demostrando la corrección del código de borrado: El código de borrado aporta un cierto nivel de redundancia para que los datos originales sean recuperables incluso si parte de los datos codificados no está disponible. También es un requisito previo para DAS, donde los nodos ligeros solo muestrean una pequeña parte del bloque para asegurar de forma probabilística que los datos están allí. Si un proponente malintencionado codifica los datos de forma incorrecta, los datos originales podrían no ser recuperables incluso si los nodos ligeros muestrean suficientes fragmentos únicos. Demostrar la corrección del código de borrado se puede hacer mediante pruebas de validez (ZKPs) o pruebas de fraude, siendo estas últimas afectadas por la latencia relacionada con el período de desafío. Todas las demás soluciones excepto Celestia están trabajando en utilizar pruebas de validez.
• Clientes ligeros ZK alimentando puentes de datos: Los rollups que utilizan capas de publicación de datos externas aún necesitan comunicarse con la capa de liquidación para verificar que los datos se han publicado correctamente. Para esto sirven los puentes de certificación de datos. El uso de ZKPs hace que la verificación de las firmas de consenso de la cadena de origen sea más eficiente en Ethereum. Ambos de Avail'sVectorX) y Celestia’s (BlobstreamX) los puentes de certificación de datos están impulsados ​​por clientes ligeros ZK construidos junto con Succinct.

Problemas Abiertos Que KZPs Podrían Resolver

• Celestia incorporando pruebas de validez para la codificación de borrado correcta: Celestia es actualmente una excepción entre las redes de publicación de datos ya queutiliza pruebas de fraude para la codificación de borrado correcta. Si un proponente de bloque malintencionado codifica incorrectamente los datos, cualquier otro nodo completo puede generar una prueba de fraude y desafiar esto. Si bien este enfoque es algo más simple de implementar, también introduce latencia (el bloque solo es definitivo después de la ventana de prueba de fraude) y requiere que los nodos ligeros confíen en un nodo completo honesto para generar la prueba de fraude (no pueden verificarla por sí mismos). Sin embargo, Celestia está explorandocombinando su actual codificación Reed-Solomon con un ZKP para demostrar una codificación correcta, lo que reduciría significativamente la finalidad. La última discusión sobre este tema se puede encontrar aquícon grabaciones de grupos de trabajo anteriores (además de intentos más generales de agregar ZKPs a la capa base de Celestia).
• ZK-proving DAS: Ha habido algunas exploraciones sobreDisponibilidad de datos de demostración ZK, donde los nodos ligeros simplemente verificarían la raíz de Merkle y una ZKP, en lugar de tener que hacer el muestreo habitual descargando pequeños fragmentos de datos. Esto reduciría aún más los requisitos para los nodos ligeros, pero parece que el desarrollo se ha estancado.

7 - Almacenamiento a largo plazo (Estado)

Almacenar datos históricos es importante principalmente para fines de sincronización y para atender solicitudes de datos. Sin embargo, no es factible que cada nodo completo almacene todos los datos y la mayoría de los nodos completos eliminan datos antiguos para mantener los requisitos de hardware razonables. En su lugar, confiamos en partes especializadas (nodos de archivo e indexadores) para almacenar todos los datos históricos y ponerlos a disposición a solicitud de los usuarios.

También hay proveedores de almacenamiento descentralizado, como FilecoinoArweave, que ofrecen soluciones de almacenamiento descentralizado a largo plazo a un precio razonable. Si bien la mayoría de las blockchains no tienen un proceso formal de almacenamiento de archivos (simplemente confían en que alguien lo almacene), los protocolos de almacenamiento descentralizado son buenos candidatos para almacenar información histórica y agregar algo de redundancia (al menos X nodos almacenan los datos) a través de los incentivos incorporados en la red de almacenamiento.

Integraciones ZK existentes

• Prueba de almacenamiento: Los proveedores de almacenamiento a largo plazo necesitan generar ZKPs regularmente para demostrar que han almacenado todos los datos que afirman. Un ejemplo de esto es Prueba de espacio-tiempo de Filecoin (PoSt), donde los proveedores de almacenamiento ganan recompensas por bloque cada vez que responden con éxito a un desafío de PoSt.

Problemas abiertos que las ZKP podrían resolver

• Demostrando la procedencia de los datos y la autorización para ver datos sensibles: Con dos partes no confiables que desean intercambiar datos sensibles, ZKPs podrían usarse para demostrar que una parte tiene las credenciales requeridas para ver los datos sin tener que cargar documentos reales o divulgar contraseñas y detalles de inicio de sesión.

8 - Consenso

Dado que las cadenas de bloques son sistemas P2P distribuidos, no hay un tercero de confianza que determine la verdad global. En cambio, los nodos de la red se ponen de acuerdo sobre cuál es la verdad actual (qué bloque es el correcto) a través de un mecanismo llamado consenso. Los métodos de consenso basados en PoS se pueden clasificar en BFT (donde el quórum bizantino tolerante a fallas de validadores decide el estado final) o basados en cadena (donde el estado final se decide retrospectivamente por la regla de elección de bifurcación). Si bien la mayoría de las implementaciones de consenso PoS existentes están basadas en BFT, Cardanoes un ejemplo de implementación de la cadena más larga. También hay un creciente interés en mecanismos de consenso basados en DAG como Narwhal-Bullshark que se implementa en algunas variaciones en Aleo, Aptos y Sui.

El consenso es una parte crucial de muchos componentes diferentes de la pila modular, incluido el secuenciador compartido, la prueba descentralizada y las redes de publicación de datos basadas en blockchain (no basadas en comités como EigenDA).

Integraciones ZK existentes

• Staking en redes de privacidad basadas en ZK: Las redes de privacidad basadas en PoS plantean un desafío, ya que los titulares de los tokens de staking deben elegir entre la privacidad y participar en el consenso (y recibir recompensas por staking).Penumbra tiene como objetivo resolver estoal eliminar las recompensas por participación, en lugar de eso, trata las participaciones desvinculadas y vinculadas como activos separados. Este método mantiene privadas las delegaciones individuales, mientras que el monto total vinculado a cada validador sigue siendo público.
• Gobierno privado: Lograr votaciones anónimas ha sido durante mucho tiempo un desafío en la criptografía, con proyectos como Votación Privada de Nounstratando de impulsar esto hacia adelante. Lo mismo también se aplica a la gobernanza, donde se está trabajando en la votación anónima sobre propuestas, al menos por Penumbra. En este caso, las Pruebas de Conocimiento Cero se pueden usar para demostrar que uno tiene derecho a votar (por ejemplo, a través de la propiedad de tokens) y que se cumplen ciertos criterios de votación (por ejemplo, no ha votado previamente).

Problemas abiertos que las ZKPs podrían resolver

• Elección de líder privado: Actualmente, Ethereum elige a los próximos 32 proponentes de bloques al comienzo de cada época y los resultados de esta elección son públicos. Esto impone el riesgo de que una parte maliciosa lance un ataque DoS contra cada proponente secuencialmente para intentar deshabilitar Ethereum. En un intento de abordar este problema, Batidoraes una propuesta para un protocolo de preservación de la privacidad para elegir proponentes de bloques en Ethereum. Los ZKP son utilizados por los validadores para demostrar que el barajado y la aleatorización se realizaron de manera honesta. También existen otros enfoques para lograr un objetivo similar, algunos de los cuales se tratan en esteentrada de blog de a16z.
• Agregación de firmas: El uso de ZKP para agregar firmas podría reducir significativamente la sobrecarga de comunicación y cálculo de la verificación de firmas (verifique una prueba agregada en lugar de cada firma individual). Esto es algo que ya se ha aprovechado en los clientes ligeros de ZK, pero que también podría ampliarse al consenso.

9 - Liquidación

El asentamiento es similar al tribunal de justicia más alto, la fuente final de verdad donde se verifican la corrección de las transiciones de estado y se resuelven disputas. Una transacción se considera final en el momento en que es irreversible (o en el caso de la finalidad probabilística, en el punto en el que sería suficientemente difícil revertirla). El tiempo de finalización depende de la capa de asentamiento subyacente utilizada, que a su vez depende de la regla de finalidad específica utilizada y del tiempo de bloque.

La lentitud de la finalidad es particularmente un problema en la comunicación entre rollups, donde los rollups necesitan esperar la confirmación de Ethereum antes de poder aprobar una transacción (7 días para rollups optimistas, 12 minutos y tiempo de demostración para rollups de validez). Esto conduce a una mala experiencia del usuario. Hay múltiples esfuerzos para resolver este problema utilizando pre-confirmaciones con un cierto nivel de seguridad. Ejemplos incluyen soluciones específicas del ecosistema (Gate.ioPolygon AggLayerozkSync HyperBridge) y soluciones de propósito general como Capa de Finalidad Rápida de Nearque tiene como objetivo conectar múltiples ecosistemas rollup diferentes aprovechando la seguridad económica de EigenLayer. También existe la opción de puentes de rollup nativos aprovechando EigenLayerpara confirmaciones suaves para evitar esperar la plena finalidad.

Integraciones ZK existentes

• Liquidación más rápida con resúmenes de validez: A diferencia de los resúmenes optimistas, los resúmenes de validez no requieren un período de impugnación, ya que se basan en ZKP para demostrar la transición de estado correcta, independientemente de si alguien impugna o no (resúmenes pesimistas). Esto hace que la liquidación en la capa base sea mucho más rápida (12 minutos frente a 7 días en Ethereum) y evita la reejecución.

10 - Seguridad

La seguridad está relacionada con la solidez de las garantías y es una parte crucial de la propuesta de valor de las blockchains. Sin embargo, el arranque de la seguridad criptoeconómica es difícil, ya que aumenta las barreras de entrada y actúa como fricción para la innovación en aquellas aplicaciones que la necesitan (diversos middleware y L1 alternativos).

La idea de seguridad compartida es utilizar la seguridad económica existente de las redes PoS y someterla a un riesgo adicional de penalización (condiciones de castigo), en lugar de que cada componente intente arrancar el suyo propio. Ha habido algunos intentos anteriores de hacer lo mismo en redes PoW.minería combinada.)), pero los incentivos desalineados facilitaron que los mineros se confabularan y explotaran un protocolo (más difícil castigar el mal comportamiento a medida que el trabajo ocurre en el mundo físico, es decir, la minería utilizando potencia de cálculo). La seguridad PoS es más flexible para ser utilizada por otros protocolos, ya que tiene incentivos tanto positivos (rendimiento de staking) como negativos (slashing).

Los protocolos que se construyen en torno a la premisa de la seguridad compartida incluyen:

• EigenLayer tiene como objetivo aprovechar la seguridad existente de Ethereum para asegurar una amplia gama de aplicaciones. El whitepaper se lanzó a principios de 2023, y EigenLayer se encuentra actualmente en mainnet alpha, con la expectativa de lanzar el mainnet completo más adelante este año.
• Cosmos lanzó su Seguridad Interchain (ICS) en mayo de 2023, que permite el Cosmos Hub - una de las cadenas más grandes en Cosmos y respaldada por ~$2.4bn de ATOM apostados- arrendar su seguridad a las cadenas de consumidores. Al utilizar el mismo conjunto de validadores que alimenta el Cosmos Hub para validar bloques también en la cadena de consumidores, tiene como objetivo reducir la barrera para lanzar nuevas cadenas en la parte superior de la pila de Cosmos. Actualmente, sin embargo, solo dos cadenas de consumidores están activas (Neutrón y Stride).
• Babilonia está tratando de permitir que BTC se utilice también para la seguridad compartida. Para contrarrestar los problemas relacionados con la minería combinada (difícil de castigar el mal comportamiento), está construyendo una capa virtual de PoS donde los usuarios pueden bloquear BTC en un contrato de participación en Bitcoin (sin puentes). Dado que Bitcoin no tiene una capa de contrato inteligente, las reglas de reducción de los contratos de participación se expresan en términos de transacciones UTXO escritas en el script de Bitcoin.
• Reinvertir en otras redes incluye Pulpoen Near y Picasso en Solana. Polkadot Paracadenastambién aprovecha el concepto de seguridad compartida.

Integraciones ZK existentes

• Mezcla entre ZK y seguridad económica: Si bien las garantías de seguridad basadas en ZK pueden ser más sólidas, demostrar aún resulta prohibitivamente caro para algunas aplicaciones y generar la prueba lleva demasiado tiempo. Un ejemplo de esto es Brevis coChain, que es un coprocesador que obtiene su seguridad económica de los revalidadores de ETH y garantiza la optimización del cálculo de manera optimista (con pruebas de fraude ZK). Las dApps pueden elegir entre el modo puro-ZK o el modo de coChain, dependiendo de sus necesidades específicas en cuanto a seguridad y compensaciones de costos.

11 - Interoperabilidad

La interoperabilidad segura y eficiente sigue siendo un gran problema en un mundo multi-chain, ejemplificado por el $2.8bn perdidos en hacks de puentes. En sistemas modulares, la interoperabilidad se vuelve aún más importante. No solo estás comunicándote entre otras cadenas, sino que las blockchains modulares también requieren que diferentes componentes se comuniquen entre sí (como la capa de DA y de liquidación). Por lo tanto, ya no es factible simplemente ejecutar un nodo completo o verificar una única prueba de consenso como en las blockchains integradas. Esto agrega más piezas móviles a la ecuación.

La interoperabilidad incluye tanto el puente de tokens como el paso de mensajes más general a través de blockchains. Hay varias opciones diferentes que hacen diferentes compensaciones en cuanto a seguridad, latencia y costo. Optimizar los tres es muy difícil, lo que generalmente requiere sacrificar al menos uno. Además, diferentes estándares entre cadenas hacen que las implementaciones en nuevas cadenas sean más difíciles.

Aunque todavía carecemos de una definición clara de los diferentes tipos de clientes livianos (o nodos), esta publicación de Dino (co-fundador de Fluent & Modular Media) da una buena introducción. La mayoría de los clientes ligeros hoy solo verifican el consenso, pero idealmente tendríamos clientes ligeros que puedan verificar la ejecución y DA también para reducir las suposiciones de confianza. Esto permitiría acercarse a la seguridad de un nodo completo, sin los altos requisitos de hardware.

Integraciones ZK existentes

• Clientes ligeros de ZK (verificación de consenso): La mayoría de los clientes ligeros actuales permiten verificar el consenso de la otra cadena, ya sea el conjunto completo de validadores (si es lo suficientemente pequeño) o un subconjunto de los validadores totales (como comité de sincronización de Ethereum). Se utilizan ZKP para que la verificación sea más rápida y económica, ya que el esquema de firma utilizado en la cadena de origen podría no ser compatible de forma nativa en la cadena de destino. Si bien se espera que la importancia de los clientes ligeros de ZK en los puentes aumente, las fricciones actuales para una adopción más amplia incluyen el costo de la prueba y verificación, junto con la implementación de clientes ligeros de ZK para cada nueva cadena. Ejemplos de protocolos en este espacio incluyen Poliedros, puentes de certificación de datos de Avail y Celestia, y zkIBC por Electron Labs.
• Pruebas de almacenamiento: Como se mencionó anteriormente, las pruebas de almacenamiento permiten consultar tanto datos históricos como actuales de blockchains sin necesidad de utilizar terceros de confianza. Esto también es relevante para la interoperabilidad, ya que podrían utilizarse para la comunicación entre cadenas. Por ejemplo, un usuario podría demostrar que tiene tokens en una cadena y utilizarlos para gobernanza en otra cadena (sin necesidad de puente). También hay intentos de utilizar pruebas de almacenamiento para puentes, como esta solución desarrollada por LambdaClass.
• ZK Oracles: Los oráculos actúan como intermediarios y conectan datos del mundo real a la cadena de bloques. Los oráculos ZK mejoran los modelos de oráculos basados en reputación actuales al permitir demostrar el origen y la integridad de los datos, junto con cualquier cálculo realizado sobre esos datos.

Problemas abiertos que las ZKP podrían resolver

• Clientes completos de luz: en lugar de confiar ciegamente en el conjunto de validadores de la otra cadena, los clientes completos de luz también verifican la ejecución correcta y DA. Esto reduce las suposiciones de confianza y se acerca a un nodo completo, manteniendo aún bajos los requisitos de hardware (permitiendo que más personas ejecuten clientes ligeros). Sin embargo, verificar cualquier cosa que no sea el consenso sigue siendo prohibitivamente costoso en la mayoría de las cadenas, especialmente en Ethereum. Además, los clientes ligeros solo permiten la verificación de información (la mitad del problema), es decir, pueden identificar que la información es falsa, pero aún necesita haber un mecanismo adicional para que hagan algo al respecto.
• Capas de Agregación: AggLayer de Polygontiene como objetivo permitir la interoperabilidad fluida entre L2s dentro del ecosistema mediante el aprovechamiento de pruebas agregadas y un contrato puente unificado. La prueba agregada permite una verificación más eficiente y segura, garantizando que los estados y paquetes de cadenas dependientes sean consistentes y asegurando que un estado de rollup no se pueda liquidar en Ethereum si se basa en un estado no válido de otra cadena.HyperChains de zkSyncyAvail Nexusestán tomando un enfoque similar.

¿Cuándo ha comido ZK la pila modular?

Suponiendo que podemos alcanzar un estado en el que la generación de ZKPs se vuelva muy rápida (casi a la velocidad de la luz) e increíblemente barata (casi gratuita), ¿cómo sería el escenario final? En otras palabras, ¿cuándo habrá ZK comido el stack modular?

En términos generales, creemos que dos cosas serían ciertas en este estado del mundo:

1. Se elimina toda reejecución innecesaria: Al pasar a un modelo de ejecución 1/N (en lugar de N/N con reejecución), reducimos significativamente la redundancia general de la red y permitimos un uso más eficiente del hardware subyacente. Aunque queda algo de sobrecarga, esto ayudaría a que las blockchains se acerquen asintóticamente a los sistemas centralizados en términos de eficiencia computacional.
2. La mayoría de las aplicaciones dependen de garantías criptográficas habilitadas para ZK en lugar de la seguridad económica: cuando el costo y el tiempo para generar pruebas ya no son una consideración relevante, creemos que la mayoría de las aplicaciones dependerán de los ZKPs para garantías más sólidas. Esto también requiere algunas mejoras en la facilidad de uso y la amigabilidad para los desarrolladores para construir aplicaciones ZK, pero estos son todos problemas en los que varios equipos están trabajando.

Una tercera condición estaría relacionada con la privacidad (o gestión del flujo de información), pero es más complicado. ZKPs se pueden utilizar para algunas aplicaciones de privacidad con demostración en el lado del cliente, que es lo que plataformas como Aleo, Aztec o Polygon Miden están construyendo, pero lograr privacidad a gran escala para todos los casos de uso potenciales depende también del progreso de MPC y FHE, un tema potencial para una futura publicación en el blog.

Riesgos para nuestra tesis

¿Y si estamos equivocados y el futuro no es ni modular ni ZK’fied? Algunos riesgos potenciales para nuestra tesis incluyen:

La modularidad aumenta la complejidad

Tanto los usuarios como los desarrolladores sufren por el creciente número de cadenas. Los usuarios necesitan gestionar fondos en varias cadenas (y potencialmente en varias carteras). Los desarrolladores de aplicaciones, por otro lado, tienen menos estabilidad y previsibilidad dada la evolución del espacio, lo que dificulta decidir en qué cadena construir. También necesitan pensar en la fragmentación del estado y la liquidez. Esto es especialmente cierto ahora, ya que todavía estamos experimentando en la frontera de qué componentes tienen sentido para desacoplar y cuáles se volverán a acoplar. Creemos que la abstracción de la operación del usuario, así como soluciones de interoperabilidad seguras y eficientes, son partes cruciales para resolver este problema.

¿ZK alguna vez será lo suficientemente eficiente?

No hay manera de evitar el hecho de que la generación de pruebas lleva demasiado tiempo y el costo tanto de la prueba como de la verificación sigue siendo demasiado alto hoy en día. Soluciones competidoras como los entornos de ejecución confiables/TEEs (privacidad) o soluciones de seguridad optimistas/criptoeconómicas (costo) todavía tienen más sentido para muchas aplicaciones hoy en día.

Se está realizando mucho trabajo en cuanto a la optimización de software y la aceleración de hardware para ZKPs. La agregación de pruebas ayudará a reducir aún más los costos de verificación al distribuir el costo entre múltiples partes diferentes (menor costo/usuario). También existe la posibilidad de adaptar la capa base para que esté más optimizada para la verificación de ZKPs. Un desafío en cuanto a la aceleración de hardware para ZKPs es el rápido desarrollo de sistemas de prueba. Esto hace que sea difícil crear hardware especializado (ASIC) ya que corren el riesgo de volverse obsoletos rápidamente si/cuando los estándares de los sistemas subyacentes de prueba evolucionan.

Ingonyama ha intentado crear algunos puntos de referencia para el rendimiento del probador a través de una métrica comparable llamada puntuación ZK. Se basa en el costo de la ejecución de la computación (OPEX) y sigue MMOPS/WATT, donde MMOPS significa operaciones de multiplicación modular por segundo. Para obtener más información sobre el tema, recomendamos blogs de @Cysic/BJQcpVbXn?ref=blog.succinct.xyz">Cysic and@ingonyama/revisiting-paradigms-hardware-acceleration-for-zero-knowledge-proofs-5dffacdc24b4">Ingonyama, as well as this talk by Wei Dai.

¿Es útil la privacidad limitada que las pruebas de conocimiento cero (ZKPs) pueden proporcionar?

Las pruebas de conocimiento nulo solo se pueden utilizar para lograr privacidad para el estado personal, no para el estado compartido donde varias partes necesitan calcular en datos encriptados (como un Uniswap privado). FHE y MPC también son necesarios para una privacidad total, pero es necesario mejorar muchas órdenes de magnitud en cuanto a coste y rendimiento antes de que sean opciones viables para un uso a mayor escala. Dicho esto, las pruebas de conocimiento nulo siguen siendo útiles para ciertos casos de uso que no requieren un estado compartido privado, como soluciones de identidad o pagos. No todos los problemas necesitan ser resueltos con la misma herramienta.

Resumen

Entonces, ¿dónde nos deja esto? Si bien estamos progresando cada día, queda mucho trabajo por hacer. Los problemas más apremiantes por resolver son cómo el valor y la información pueden fluir de manera segura entre diferentes componentes modulares sin sacrificar velocidad o costo, así como abstraerlo todo del consumidor final para que no tengan que preocuparse por la conexión entre diferentes cadenas, cambiar billeteras, etc.

Si bien actualmente estamos en gran medida en la fase experimental, las cosas deberían estabilizarse con el tiempo a medida que descubrimos dónde en el espectro se encuentran los compromisos óptimos para cada caso de uso. A su vez, esto dará lugar a que los estándares (informales o formales) emerjan y brinden más estabilidad a los constructores sobre estas cadenas.

Hoy en día todavía hay muchos casos de uso que recurren a la seguridad criptoeconómica por defecto debido al costo y complejidad de generar ZKPs, y algunos que requieren una combinación de los dos. Sin embargo, esta participación debería disminuir con el tiempo a medida que diseñamos sistemas de demostración más eficientes y hardware especializado para reducir el costo y la latencia de la demostración y verificación. Con cada reducción exponencial en costo y velocidad, se desbloquean nuevos casos de uso.

Si bien este artículo se centró específicamente en ZKPs, también estamos cada vez más interesados en cómo las soluciones criptográficas modernas (ZKPs, MPC, FHE y TEE) terminarán jugando juntas, algo que ya estamos viendo.

¡Gracias por leer!

Descargo de responsabilidad：

1. Este artículo es una reimpresión de [equilibrio]. Todos los derechos de autor pertenecen al autor original [ Hannes Huitula]. Si hay objeciones a esta reimpresión, por favor contacta al Gate Learnequipo y lo resolverá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.