Hechos clave:
-
Los ZK se diferencian en la prioridad que dan a la compatibilidad y a la eficiencia.
-
Todos utilizan la tecnología ZK-SNARK para comprobar transacciones en Ethereum.
El cocreador de Ethereum Vitalik Buterin detalló en su blog personal los diferentes tipos de ZK-EVM (técnica de comprobación de conocimiento cero para la máquina virtual de Ethereum que se utiliza para ejecutar contratos inteligentes) y sus características. La principal diferencia entre los diferentes proyectos ZK es el balance que cada uno hace entre practicidad y velocidad, asegura el desarrollador.
Más allá de sus particularidades, todos los ZK comparten una meta, dice Buterin. Esta es la de «usar la tecnología ZK-SNARK para hacer comprobaciones criptográficas de ejecuciones de transacciones en Ethereum», ya sea en la cadena principal en sí misma o en segundas capas, a través de rollups de conocimiento cero (ZK). Estos son un tipo de solución de escalabilidad que agrupa transacciones para luego acuñarlas todas juntas en la capa principal.
A continuación, enumeraremos los diferentes tipos de proyectos ZK que diferenció el desarrollador ruso-canadiense. Además, se incluirán los principales pros y contras de cada uno.
ZK de tipo 1
El primer tipo de ZK-EVM que señala Vitalik Buterin es aquel «totalmente equivalente» con Ethereum. Estos «no cambian ninguna parte del sistema» para hacerlo más sencillo.
Su principal ventaja es la compatibilidad, y los proyectos de este tipo son necesarios «para hacer Ethereum más escalable». Según el experto ruso-canadiense, los ZK de tipo 1 son ideales para los rollups porque les permiten usar una gran cantidad de infraestructura.
En cuanto a las desventajas de estos proyectos ZK, la más importante es el tiempo y la demanda de recursos para la comprobación de transacciones. Esto se debe, explica, a que pretenden replicar exactamente la red de Ethereum, y por eso no hay forma de «mitigar esas ineficiencias».
ZK de tipo 2
El segundo tipo de ZK es aquel «totalmente equivalente a la EVM de Ethereum». Es decir que, si bien no es totalmente compatible con Ethereum, sí lo es con los contratos inteligentes creados en esta red.
Se diferencian con la capa principal de la red en la estructura de los bloques, entre otros datos técnicos. Básicamente, hacen pequeñas modificaciones a Ethereum para que las aplicaciones sean capaces de confirmar transacciones de manera más sencilla.
El punto débil que Buterin detecta en estos ZK es que no eliminan la lentitud para la confirmación de operaciones en la EVM, así como tampoco «su ineficiencia y hostilidad».
Hay una clase de ZK «intermedio» (o 2.5, como lo llama Vitalik Buterin) que también es equivalente con la EVM, a excepción de los costos de gas). Estos tienen la ventaja de mejorar los tiempos de confirmación, pero reducen la compatibilidad y pueden «romper algunas aplicaciones», explica.
ZK de tipo 3
El tercer tipo de ZK que describe el líder etherean es uno «parcialmente equivalente con la EVM». Estos ZK hacen «unos pocos sacrificios» para mejorar los tiempos de comprobación y las posibilidades de desarrollo.
La desventaja de estos proyectos ZK, de los cuales Polygon es un exponente, es que su compatibilidad con las aplicaciones es menor. Esto sucede porque muchas utilizan recursos (como precompiles) que los ZK de tipo 3 remueven.
En última instancia, Buterin afirma que ningún equipo desarrollador de ZK-EVM pretende crear un proyecto de tipo 3, sino que se trata de una etapa de transición hasta que logran completar su paso hacia el tipo 2.5. Sin embargo, en el futuro varios ZK de tipo 1 y 2 podrían volverse de tipo 3 «voluntariamente» para optimizar su funcionamiento en cuanto a demoras y costos, aclara.
ZK de tipo 4
Esta última categoría engloba a aquellos ZK que son equivalentes a Ethereum en su lenguaje de alto nivel. Estos ZK «toman el código fuente de los contratos inteligentes escrito en un lenguaje de alto nivel, como Solidity o Vyper, y lo pasan a un lenguaje explícitamente diseñado para ser compatible con ZK-SNARK».
El resultado positivo de este proceso es que se logran tiempos de comprobación muy rápidos. Tal eficiencia se consigue omitiendo ciertos pasos de la comprobación ZK de diferentes pasos de la ejecución en la EVM y comenzando «directamente con el código de alto nivel». Este es un gran paso hacia la reducción de costos y la descentralización, afirma Buterin.
Sus desventajas, en tanto, tienen que ver con la incompatibilidad de ciertas aplicaciones por diferencias en sus contratos inteligentes, mayor dificultad en el uso de ciertos bytecodes en la EVM y menos opciones en cuanto a «debugging» o corrección de fallas. En síntesis, la compatibilidad se reduce significativamente.
El futuro de los ZK
Para finalizar su artículo, Buterin asegura que ningún ZK es mejor ni peor que los de otros tipos. Son diferentes, explica, y todo tiene que ver con el balance que se mencionó antes.
Asimismo, es posible que un proyecto ZK comience siendo de baja numeración (con más compatibilidad pero menos eficiente) y con el tiempo se vuelva uno de alta numeración (más eficiente pero menos compatible). «Personalmente, mi deseo es que todos se vuelvan de tipo 1 algún día, mediante una combinación de mejoras en los ZK-EVM y en Ethereum en sí misma», concluye el desarrollador, aclarando además que «tomará tiempo llegar a ese futuro».
