Una forma poco discutida, pero sin embargo muy importante, en la que Ethereum mantiene su seguridad y descentralización es su filosofía multicliente. Ethereum no tiene intencionadamente un "cliente de referencia" que todo el mundo ejecute por defecto: en su lugar, hay una especificación gestionada de forma colaborativa (hoy en día escrita en Python, muy legible por humanos pero muy lenta) y hay varios equipos que realizan implementaciones de la especificación (también llamados "clientes"), que es lo que los usuarios realmente ejecutan.

Cada nodo de Ethereum ejecuta un cliente de consenso y un cliente de ejecución. A día de hoy, ningún cliente de consenso o ejecución representa más de 2/3 de la red. Si un cliente con menos de 1/3 de participación en su categoría tiene un error, la red simplemente continuaría normalmente. Si un cliente con entre 1/3 y 2/3 de participación en su categoría (por ejemplo, Prysm, Lighthouse o Geth) tiene un error, la cadena seguiría añadiendo bloques, pero dejaría de finalizar bloques, dando tiempo a que los desarrolladores intervinieran.

Una transición importante poco discutida, pero sin embargo muy importante, en la forma en que se valida la cadena Ethereum es el aumento de las ZK-EVM. Los SNARK que prueban la ejecución de EVM ya han estado en desarrollo durante años, y la tecnología está siendo utilizada activamente por protocolos de capa 2 llamados ZK rollups. Algunos de estos resúmenes de ZK están activos en la red principal hoy en día, y pronto habrá más. Pero a largo plazo, los ZK-EVM no van a ser solo para rollups; también queremos usarlos para verificar la ejecución en la capa 1 (ver también: The Verge).

Una vez que eso sucede, los ZK-EVM se convierten de facto en un tercer tipo de cliente de Ethereum, tan importante para la seguridad de la red como lo son hoy los clientes de ejecución y los clientes de consenso. Y esto, naturalmente, plantea una pregunta: ¿cómo interactuarán los ZK-EVM con la filosofía multicliente? Una de las partes difíciles ya está hecha: ya tenemos múltiples implementaciones de ZK-EVM que se están desarrollando activamente. Pero quedan otras partes difíciles: ¿cómo haríamos realmente un ecosistema "multicliente" para que ZK demuestre la corrección de los bloques de Ethereum? Esta pregunta abre algunos desafíos técnicos interesantes y, por supuesto, la pregunta inminente de si las compensaciones valen la pena o no.

¿Cuál fue la motivación original de la filosofía multicliente de Ethereum?

La filosofía multicliente de Ethereum es un tipo de descentralización, y al igual que <a href="https://medium.com/@VitalikButerin/the-meaning-of-decentralization-a0c92b76a274">descentralización en general, uno puede centrarse en los beneficios técnicos de la descentralización arquitectónica o en los beneficios sociales de la descentralización política. En última instancia, la filosofía multicliente fue motivada por ambos y sirve a ambos.

Argumentos a favor de la descentralización técnica

El principal beneficio de la descentralización técnica es simple: reduce el riesgo de que un error en una pieza de software conduzca a un colapso catastrófico de toda la red. Una situación histórica que ejemplifica este riesgo es el error de desbordamiento de Bitcoin de 2010. En ese momento, el código del cliente de Bitcoin no comprobaba que la suma de los resultados de una transacción no se desbordara (se envolvía a cero sumando por encima del entero máximo de 2⁶⁴−1), por lo que alguien hizo una transacción que hizo exactamente eso, dándose a sí mismo miles de millones de bitcoins. El error se descubrió en cuestión de horas, y se apresuró a solucionarlo y se implementó rápidamente en toda la red, pero si hubiera habido un ecosistema maduro en ese momento, esas monedas habrían sido aceptadas por exchanges, puentes y otras estructuras, y los atacantes podrían haberse salido con la suya con mucho dinero. Si hubiera habido cinco clientes diferentes de Bitcoin, habría sido muy poco probable que todos tuvieran el mismo error, por lo que habría habido una división inmediata, y el lado de la división que tenía errores probablemente habría perdido.

Hay una compensación en el uso del enfoque multicliente para minimizar el riesgo de errores catastróficos: en su lugar, se obtienen errores de error de consenso. Es decir, si tienes dos clientes, existe el riesgo de que los clientes tengan interpretaciones sutilmente diferentes de alguna regla del protocolo, y aunque ambas interpretaciones son razonables y no permiten robar dinero, el desacuerdo haría que la cadena se partiera por la mitad. Una división seria de ese tipo ocurrió una vez en la historia de Ethereum (ha habido otras divisiones mucho más pequeñas en las que partes muy pequeñas de la red que ejecutaban versiones antiguas del código se bifurcaron). Los defensores del enfoque de un solo cliente señalan los fallos de consenso como una razón para no tener múltiples implementaciones: si solo hay un cliente, ese cliente no estará en desacuerdo consigo mismo. Su modelo de cómo el número de clientes se traduce en riesgo podría ser algo así:

Yo, por supuesto, no estoy de acuerdo con este análisis. El quid de mi desacuerdo es que (i) los errores catastróficos al estilo de 2010 también importan, y (ii) en realidad nunca tienes un solo cliente. Este último punto se hace más obvio con la bifurcación de Bitcoin de 2013: se produjo una división de la cadena debido a un desacuerdo entre dos versiones diferentes del cliente de Bitcoin, una de las cuales resultó tener un límite accidental e indocumentado en el número de objetos que podían modificarse en un solo bloque. Por lo tanto, un cliente en teoría es a menudo dos clientes en la práctica, y cinco clientes en teoría pueden ser seis o siete clientes en la práctica, por lo que deberíamos dar el paso e ir al lado correcto de la curva de riesgo, y tener al menos algunos clientes diferentes.

Argumentos a favor de la descentralización política

Los desarrolladores de clientes monopólicos están en una posición con mucho poder político. Si un desarrollador cliente propone un cambio y los usuarios no están de acuerdo, teóricamente podrían negarse a descargar la versión actualizada o crear una bifurcación sin ella, pero en la práctica a menudo es difícil para los usuarios hacerlo. ¿Qué sucede si un cambio de protocolo desagradable se incluye con una actualización de seguridad necesaria? ¿Qué pasa si el equipo principal amenaza con renunciar si no se sale con la suya? O, más dócilmente, ¿qué pasa si el equipo del cliente monopólico termina siendo el único grupo con la mayor experiencia en protocolo, dejando al resto del ecosistema en una mala posición para juzgar los argumentos técnicos que presenta el equipo del cliente, dejando al equipo del cliente con mucho espacio para impulsar sus propios objetivos y valores particulares? que podría no coincidir con la comunidad en general?

La preocupación por la política de protocolos, particularmente en el contexto de las guerras de OP_RETURN de Bitcoin de 2013-14 , donde algunos participantes estaban abiertamente a favor de discriminar contra usos particulares de la cadena, fue un factor que contribuyó significativamente a la adopción temprana de Ethereum de una filosofía multicliente, que tenía como objetivo dificultar que un pequeño grupo tomara ese tipo de decisiones. Las preocupaciones específicas del ecosistema Ethereum, es decir, evitar la concentración de poder dentro de la propia Fundación Ethereum, proporcionaron un mayor apoyo en esta dirección. En 2018, se tomó la decisión de que la Fundación no hiciera intencionalmente una implementación del protocolo PoS de Ethereum (es decir, lo que ahora se llama un "cliente de consenso"), dejando esa tarea completamente a equipos externos.

¿Cómo entrarán los ZK-EVM en la capa 1 en el futuro?

Hoy en día, los ZK-EVM se utilizan en rollups. Esto aumenta la escala al permitir que la costosa ejecución de EVM ocurra solo unas pocas veces fuera de la cadena, y todos los demás simplemente verifican los SNARK publicados en la cadena que demuestran que la ejecución de EVM se calculó correctamente. También permite que algunos datos (en particular las firmas) no se incluyan en la cadena, lo que ahorra en costos de gas. Esto nos brinda muchos beneficios de escalabilidad, y la combinación de computación escalable con ZK-EVM y datos escalables con <a href="https://hackmd.io/@vbuterin/sharding_proposal#ELI5-data-availability-sampling">muestreo de disponibilidad de datos podría permitirnos escalar muy lejos.

Sin embargo, la red Ethereum hoy en día también tiene un problema diferente, uno que ninguna cantidad de escalado de capa 2 puede resolver por sí misma: la capa 1 es difícil de verificar, hasta el punto de que no muchos usuarios ejecutan su propio nodo. En cambio, la mayoría de los usuarios simplemente confían en proveedores externos. Los clientes ligeros como Helios y Succinct están tomando medidas para resolver el problema, pero un cliente ligero está lejos de ser un nodo totalmente verificador: un cliente ligero simplemente verifica las firmas de un subconjunto aleatorio de validadores llamado comité de sincronización, y no verifica que la cadena realmente siga las reglas del protocolo. Para llevarnos a un mundo en el que los usuarios puedan verificar que la cadena sigue las reglas, tendríamos que hacer algo diferente.

Opción 1: constreñir la capa 1, forzar que casi toda la actividad se mueva a la capa 2

Con el tiempo, podríamos reducir el objetivo de gas por bloque de la capa 1 de 15 millones a 1 millón, lo suficiente como para que un bloque contenga un solo SNARK y algunas operaciones de depósito y retiro, pero no mucho más, y por lo tanto obligar a casi toda la actividad del usuario a moverse a los protocolos de capa 2. Un diseño de este tipo aún podría admitir muchos rollups que se comprometen en cada bloque: podríamos usar protocolos de agregación fuera de la cadena ejecutados por constructores personalizados para reunir SNARK de múltiples protocolos de capa 2 y combinarlos en un solo SNARK. En un mundo así, la única función de la capa 1 sería ser un centro de intercambio de información para los protocolos de la capa 2, verificando sus pruebas y, ocasionalmente, facilitando grandes transferencias de fondos entre ellos.

Este enfoque podría funcionar, pero tiene varias debilidades importantes:

• Es incompatible de facto con versiones anteriores, en el sentido de que muchas aplicaciones existentes basadas en L1 se vuelven económicamente inviables. Los fondos de los usuarios de hasta cientos o miles de dólares podrían quedarse atascados a medida que las tarifas se vuelven tan altas que exceden el costo de vaciar esas cuentas. Esto podría abordarse permitiendo que los usuarios firmen mensajes para optar por una migración masiva dentro del protocolo a una L2 de su elección (consulte algunas ideas de implementación temprana aquí), pero esto agrega complejidad a la transición, y hacerla lo suficientemente barata requeriría algún tipo de SNARK en la capa 1 de todos modos. Por lo general, soy un fanático de romper la compatibilidad con versiones anteriores cuando se trata de <a href="https://hackmd.io/@vbuterin/selfdestruct">cosas como el código de operación SELFDESTRUCT, pero en este caso la compensación parece mucho menos favorable.
• Es posible que aún no haga que la verificación sea lo suficientemente barata. Idealmente, el protocolo Ethereum debería ser fácil de verificar no solo en computadoras portátiles, sino también dentro de teléfonos, extensiones de navegador e incluso dentro de otras cadenas. Sincronizar la cadena por primera vez, o después de mucho tiempo sin conexión, también debería ser fácil. Un nodo portátil podría verificar 1 millón de gas en ~20 ms, pero incluso eso implica 54 segundos para sincronizarse después de un día sin conexión (suponiendo que <a href="https://notes.ethereum.org/@vbuterin/single_slot_finality">single La finalidad de la ranura aumenta los tiempos de ranura a 32 segundos), y para teléfonos o extensiones de navegador tomaría unos pocos cientos de milisegundos por bloque y aún podría ser un consumo de batería no despreciable. Estos números son manejables, pero no son ideales.
• Incluso en un ecosistema de L2 primero, hay beneficios de que L1 sea al menos algo asequible. Los Validiums pueden beneficiarse de un modelo de seguridad más sólido si los usuarios pueden retirar sus fondos si notan que los nuevos datos estatales ya no están disponibles. El arbitraje se vuelve más eficiente, especialmente para los tokens más pequeños, si el tamaño mínimo de una transferencia directa entre L2 económicamente viable es menor.

Por lo tanto, parece más razonable tratar de encontrar una manera de usar ZK-SNARKs para verificar la capa 1 en sí.

Opción 2: SNARK-verificar la capa 1

Se puede utilizar un ZK-EVM de tipo 1 (totalmente equivalente a Ethereum) para verificar la ejecución de EVM de un bloque de Ethereum (capa 1). Podríamos escribir más código SNARK para verificar también el lado de consenso de un bloque. Este sería un problema de ingeniería desafiante: hoy en día, los ZK-EVM tardan minutos u horas en verificar los bloques de Ethereum, y generar pruebas en tiempo real requeriría una o más de (i) mejoras en el propio Ethereum para eliminar los componentes hostiles a SNARK, (ii) grandes ganancias de eficiencia con hardware especializado y (iii) mejoras arquitectónicas con mucha más paralelización. Sin embargo, no hay ninguna razón tecnológica fundamental por la que no se pueda hacer, por lo que espero que, aunque lleve muchos años, se haga.

Aquí es donde vemos la intersección con el paradigma multicliente: si usamos ZK-EVM para verificar la capa 1, ¿qué ZK-EVM usamos?

Veo tres opciones:

1. Single ZK-EVM: abandonamos el paradigma multicliente, y elegimos un único ZK-EVM que utilizamos para verificar bloques.
2. ZK-EVM múltiples cerradas: acordar y consagrar en consenso un conjunto específico de múltiples ZK-EVM, y tener 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. Abrir múltiples 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.

Para mí, (3) parece ideal, al menos hasta que nuestra tecnología mejore hasta el punto en que podamos demostrar formalmente que todas las implementaciones de ZK-EVM son equivalentes entre sí, momento en el que podemos elegir la que sea más eficiente. (1) sacrificaría los beneficios del paradigma multicliente, y (2) cerraría la posibilidad de desarrollar nuevos clientes y conduciría a un ecosistema más centralizado. (3) tiene desafíos, pero esos desafíos parecen más pequeños que los desafíos de las otras dos opciones, al menos por ahora.

La implementación de (3) no sería demasiado difícil: uno podría tener una subred p2p para cada tipo de prueba, y un cliente que use un tipo de prueba escucharía en la subred correspondiente y esperaría hasta recibir una prueba que su verificador reconozca como válida.

Los dos desafíos principales de (3) son probablemente los siguientes:

• El reto de la latencia: un atacante malintencionado podría publicar un bloque tarde, junto con una prueba válida para un cliente. Siendo realistas, se necesitaría mucho tiempo (incluso si, por ejemplo, 15 segundos) se necesitaría mucho tiempo para generar pruebas válidas para otros clientes. Este tiempo sería lo suficientemente largo como para crear potencialmente una bifurcación temporal e interrumpir la cadena durante algunas ranuras.
• Ineficiencia de los datos: una de las ventajas de los ZK-SNARK es que los datos que sólo son relevantes para la verificación (a veces denominados "datos testigo") podrían eliminarse de un bloque. Por ejemplo, una vez que haya verificado una firma, no necesita mantener la firma en un bloque, solo puede almacenar un solo bit que diga que la firma es válida, junto con una sola prueba en el bloque que confirme que existen todas las firmas válidas. Sin embargo, si queremos que sea posible generar pruebas de varios tipos para un bloque, las firmas originales tendrían que estar realmente publicadas.

El desafío de la latencia podría abordarse teniendo cuidado al diseñar el protocolo de finalidad de una sola ranura. Es probable que los protocolos de finalidad de una sola ranura requieran más de dos rondas de consenso por ranura, por lo que se podría requerir que la primera ronda incluya el bloque y solo se requiera que los nodos verifiquen las pruebas antes de firmar en la tercera ronda (o final). Esto garantiza que siempre haya una ventana de tiempo significativa disponible entre la fecha límite para publicar un bloque y el momento en que se espera que las pruebas estén disponibles.

La cuestión de la eficiencia de los datos tendría que abordarse mediante la creación de un protocolo separado para agregar los datos relacionados con la verificación. Para las firmas, podríamos usar la agregación BLS, que ERC-4337 ya admite. Otra categoría importante de datos relacionados con la verificación son los ZK-SNARK utilizados para la privacidad. Afortunadamente, estos a menudo tienden a tener sus propios protocolos de agregación.

También vale la pena mencionar que la verificación de SNARK de la capa 1 tiene un beneficio importante: el hecho de que la ejecución de EVM en cadena ya no necesite ser verificada por todos los nodos permite aumentar en gran medida la cantidad de ejecución de EVM que tiene lugar. Esto podría suceder aumentando en gran medida el límite de gas de la capa 1, o introduciendo rollups consagrados, o ambos.

Conclusiones

Hacer que un ecosistema ZK-EVM multicliente abierto funcione bien requerirá mucho trabajo. Pero la buena noticia es que gran parte de este trabajo está sucediendo o sucederá de todos modos:

• Ya tenemos varias implementaciones sólidas de ZK-EVM. Estas implementaciones aún no son de tipo 1 (totalmente equivalentes a Ethereum), pero muchas de ellas se están moviendo activamente en esa dirección.
• El trabajo en clientes ligeros como Helios y Succinct puede eventualmente convertirse en una verificación SNARK más completa del lado del consenso PoS de la cadena Ethereum.
• Es probable que los clientes comiencen a experimentar con ZK-EVM para probar la ejecución de bloques de Ethereum por su cuenta, especialmente una vez que tengamos clientes sin estado y no haya necesidad técnica de volver a ejecutar directamente cada bloque para mantener el estado. Probablemente obtendremos una transición lenta y gradual de los clientes que verifican los bloques de Ethereum volviéndolos a ejecutar a la mayoría de los clientes que verifican los bloques de Ethereum comprobando las pruebas de SNARK.
• Es probable que los ecosistemas ERC-4337 y PBS comiencen a trabajar con tecnologías de agregación como BLS y agregación de prueba muy pronto, con el fin de ahorrar en costos de gas. En cuanto a la agregación de BLS, ya se ha comenzado a trabajar.

Con estas tecnologías implementadas, el futuro se ve muy bien. Los bloques de Ethereum serían más pequeños que en la actualidad, cualquiera podría ejecutar un nodo de verificación completa en su computadora portátil o incluso en su teléfono o dentro de una extensión del navegador, y todo esto sucedería mientras se preservan los beneficios de la filosofía multicliente de Ethereum.

En el futuro a largo plazo, por supuesto, cualquier cosa podría suceder. Tal vez la IA sobrecargue la verificación formal hasta el punto en que pueda demostrar fácilmente la equivalencia de las implementaciones de ZK-EVM e identificar todos los errores que causan diferencias entre ellas. Un proyecto de este tipo puede incluso ser algo en lo que podría ser práctico empezar a trabajar ahora. Si ese enfoque oficial basado en la verificación tiene éxito, será necesario establecer diferentes mecanismos para garantizar la continuación de la descentralización política del protocolo; Quizás en ese momento, el protocolo se consideraría "completo" y las normas de inmutabilidad serían más fuertes. Pero incluso si ese es el futuro a largo plazo, el mundo abierto de ZK-EVM multicliente parece un trampolín natural que es probable que suceda de todos modos.

A corto plazo, este sigue siendo un largo viaje. Las ZK-EVM están aquí, pero el hecho de que las ZK-EVM sean realmente viables en la capa 1 requeriría que se convirtieran en tipo 1 y que se demostraran lo suficientemente rápido como para que pueda suceder en tiempo real. Con suficiente paralelización, esto es factible, pero aún así será mucho trabajo llegar allí. Los cambios de consenso, como el aumento del costo del gas de KECCAK, SHA256 y otras precompilaciones de funciones hash, también serán una parte importante del panorama. Dicho esto, los primeros pasos de la transición pueden ocurrir antes de lo que esperamos: una vez que cambiemos a los árboles Verkle y a los clientes apátridas, los clientes podrían comenzar a usar gradualmente ZK-EVM, y una transición a un mundo "abierto multi-ZK-EVM" podría comenzar a suceder por sí sola.

Renuncia:

1. Este artículo es una reimpresión de [vitalik], Todos los derechos de autor pertenecen al autor original [vitalik]. Si hay objeciones a esta reimpresión, comuníquese con el equipo de Gate Learn y ellos lo manejarán de inmediato.
2. Descargo de responsabilidad: Los puntos de vista y opiniones 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.