Vitalik Buterin revela un gran desafío para el futuro de Ethereum y cómo resolverlo

El cofundador de Ethereum, Vitalik Buterin, compartió su reflexión sobre un aspecto "poco discutido, pero sin embargo muy importante" del ecosistema de Ethereum en una publicación de blog reciente este fin de semana.

La publicación titulada "¿Cómo interactuará la filosofía multicliente de Ethereum con los ZK-EVM?" se centró en los desafíos técnicos, las compensaciones y las posibles soluciones para crear un ecosistema multicliente para ZK-EVM.

El problema multicliente con Zk-EVMs

Vitalik cree que los ZK-EVM evolucionarán para convertirse en una parte esencial del proceso de verificación y seguridad de capa 1 de Ethereum en el futuro. La tecnología Zero Knowledge (ZK) permite a los desarrolladores probar la autenticidad de una transacción o mensaje sin revelar ninguna información adicional. Por lo tanto, permite que una parte convenza a otra de que un mensaje es verdadero sin revelar ningún conocimiento más allá de la validez del mensaje.

Sin embargo, la naturaleza de aplicación de la privacidad de la tecnología ZK podría interrumpir el panorama más amplio de EVM, ya que los clientes de Ethereum difieren sutilmente en la implementación de las reglas del protocolo, según el cofundador de Ethereum.

Los protocolos de capa 2 en los paquetes acumulativos de ZK han utilizado con éxito las pruebas de ZK y ayudaron a escalar Ethereum al agrupar varias transacciones en una sola prueba. Sin embargo, a medida que los ZK-EVM evolucionan para verificar la ejecución en Mainnet, "los ZK-EVM se convierten de facto en un tercer tipo de cliente Ethereum, tan importante para la seguridad de la red como lo son hoy los clientes de ejecución y los clientes de consenso".

Ver ZK-EVM como un tercer tipo de cliente de Ethereum plantea la siguiente pregunta de Vitalik:

"¿Cómo haríamos realmente un ecosistema "multicliente" para que ZK pruebe la exactitud de los bloques de Ethereum?"

A medida que el ecosistema escala, Vitalik quiere mantener los beneficios de la "filosofía multicliente" al mismo tiempo que aprovecha las capacidades de ZK-EVM para mejorar la escalabilidad, la seguridad y la descentralización de la red Ethereum.

Los principales desafíos técnicos de usar la tecnología ZK con múltiples clientes se relacionan con la latencia y la ineficiencia de los datos, según Vitalik. Además, los clientes individuales de Ethereum manejan las pruebas de conocimiento cero de manera diferente debido a las interpretaciones específicas de las reglas del protocolo o las implementaciones de ZK-EVM.

Soluciones multicliente ZK-EVM

A pesar de estos desafíos, Vitalik cree que crear un ecosistema ZK-EVM multicliente abierto es factible y beneficioso para la seguridad y la descentralización de Ethereum.

A continuación se muestra una representación visual de los diversos clientes utilizados en las capas de consenso y ejecución del ecosistema Ethereum.

Vitalik argumentó que tener varios clientes aumenta la seguridad y la descentralización de la red al reducir el riesgo de un solo error catastrófico en una implementación, lo que podría provocar una falla en toda la red. Además, una filosofía multicliente ayuda a prevenir la concentración de poder dentro de un equipo u organización de desarrollo, promoviendo la descentralización política.

Vitalik presentó tres posibles soluciones al problema, como se muestra a continuación.

1. “ZK-EVM único: abandone el paradigma multicliente y elija un único ZK-EVM que usamos para verificar bloques.
2. Múltiples ZK-EVM cerrados: acuerde y consagre en consenso un conjunto específico de múltiples ZK-EVM, y tenga una regla de protocolo de capa de consenso de que un bloque necesita pruebas de más de la mitad de los ZK-EVM en ese conjunto para ser considerado válido .
3. Open multi ZK-EVM: diferentes clientes tienen diferentes implementaciones de ZK-EVM, y cada cliente espera una prueba que sea compatible con su propia implementación antes de aceptar un bloque como válido”.

En el contexto de ZK-EVM, Vitalik apoya la idea de un ecosistema abierto de ZK-EVM multicliente. Diferentes clientes tienen diferentes implementaciones de ZK-EVM, y cada cliente espera una prueba compatible con la suya antes de aceptar un bloque como válido.

"Para mí, (3) parece ideal, al menos hasta que nuestra tecnología mejore hasta el punto en que podamos probar formalmente que todas las implementaciones de ZK-EVM son equivalentes entre sí..."

Sin embargo, una vez que la tecnología haya mejorado hasta el punto en que las implementaciones de ZK-EVM estén algo estandarizadas, Vitalik argumentó que la solución será elegir la opción más eficiente. Él cree que los "desafíos [para la opción 3] parecen menores que los desafíos de las otras dos opciones, al menos por ahora".

Vitalik también asintió al rápido avance reciente en IA, afirmando que el progreso en IA podría "sobrecargar" el desarrollo de las implementaciones de prueba de ZK-EVM.

“En el futuro a más largo plazo, por supuesto que podría pasar cualquier cosa. Quizás la IA sobrecargue la verificación formal hasta el punto en que pueda demostrar fácilmente que las implementaciones de ZK-EVM son equivalentes e identificar todos los errores que causan diferencias entre ellas”.