Ethereum Beast Mode - Escalando L1 a 10k y más allá | Justin Drake

Ryan:
[0:02] Justin, ¿qué es Ethereum magra al más alto nivel?

Justin o David:
[0:07] Claro. Así que lean Ethereum es la convicción de que podemos utilizar esta tecnología muy poderosa llamada SNARKs, esta criptografía mágica para llevar Ethereum al siguiente nivel, tanto en términos de rendimiento y escala, pero también en términos de seguridad y descentralización. Y yo llamo a lo primero modo bestia y a lo segundo modo fortaleza.

Ryan:
[0:29] Espera, está bien. Modo bestia y modo fortaleza. ¿Qué es el modo bestia y qué es el modo fuerte?

David:
[0:34] Sí. Parte del modo bestia es esta visión de escalar el L1 a un giga de gas por segundo. Yo lo llamo la frontera del giga gas o la era del giga gas, así como aumentar drásticamente la disponibilidad de datos para que podamos hacer un tera gas por segundo en la L2. Así que eso son 10.000 TPS en los L1, 10 millones de TPS en los L2. Y si tuviera que resumirlo en una frase, básicamente se trata de tener suficiente rendimiento para todas las finanzas.

Ryan:
[1:07] Y el modo bestia está en la capa de ejecución, supongo, que definiremos un poco más. Pero ahí es donde el espacio de bloques y las transacciones de gas y toda esa actividad y contratos inteligentes, toda esa actividad ocurre en la capa de ejecución. Es DeFi. DeFi, pagos, sí.

David:
[1:27] Exacto. También incluye la capa de disponibilidad de datos para los L2. Y eso nos da, a grandes rasgos, un amplificador 1.000x en relación con lo que podemos hacer con el L1.

Ryan:
[1:37] De acuerdo. E incluso la capa de disponibilidad de datos para los L2, ¿qué hacen los L2? Ejecución. Se trata de ejecutar en modo bestia. De acuerdo. Modo bestia. ¿Qué es el modo fortaleza?

David:
[1:47] Cuarto modo se trata de tener una seguridad totalmente inflexible. El mejor tiempo de actividad de su clase, la mejor descentralización de su clase, seguridad post-cuántica, asegurándose de que la tubería MEV está limpiamente desacoplada de los validadores, y también tener la mejor finalidad de su clase en cuestión de segundos en comparación con lo que tenemos ahora, que es en cuestión de 10 minutos, de 10 a 20 minutos. La gente ha llamado a esto.

Ryan:
[2:13] Esta es la capa de consenso, ¿verdad? Así que la capa de consenso es el modo fuerte, el modo bestia es la capa de ejecución. Exactamente.

David:
[2:20] Hay un poco de unión en el sentido de que la tecnología que vamos a utilizar para resolver el modo bestia también nos permite resolver el modo fuerte.

David:
[2:29] Y la razón es que los snarks permiten a los validadores verificar pruebas muy, muy pequeñas. Y eso ayuda mucho a la descentralización porque la barrera de entrada para convertirse en validador desde el punto de vista del hardware es extremadamente baja.

Justin o David:
[2:44] Y el modo bestia y el modo fortaleza, siento que son ofensivos y defensivos. Como la ejecución, el modo bestia es, Ethereum está siendo agresivo. Vamos hacia adelante. Estamos empujando hacia adelante el modo bestia. Y el modo fortaleza es lo que Ethereum siempre ha hecho. Y seguimos haciéndolo, que es una especie de lo que llamamos la resistencia de la Tercera Guerra Mundial es como todo en el mundo va a ir mal. Pero Ethereum seguirá produciendo bloques porque es así de resistente. Es la moneda búnker. Así que tenemos como ofensiva defensiva es tal vez como una manera de retratar esto.

David:
[3:18] Exactamente. Y con Snarks, básicamente tenemos permiso para soñar sueños más grandes en el escalado agresivo y el rendimiento.

Justin o David:
[3:27] Vale la pena destacar, Justin, que Ethereum nunca ha hecho realmente el modo bestia antes. Nunca hemos pasado realmente a la ofensiva. Como Ethereum magra es una especie de la primera vez que realmente podemos decir con credibilidad, sí, Ethereum está escalando no marginalmente, sino agresivamente. ¿Es correcto?

David:
[3:50] Quiero decir, yo diría que la disponibilidad de datos en la que hemos estado trabajando durante muchos años es parte del modo bestia para desbloquear los L2. Pero los L1 han permanecido estancados.

Justin o David:
[4:02] En la L1, modo bestia en la L1. Correcto.

David:
[4:04] Así que durante cuatro años, bueno, hace cuatro años, el límite de gas era de 30 millones de gas, y hoy es de 45 millones de gas. Así que en cuatro años, sólo hemos escalado el límite de gas en un 50%, por debajo incluso de la ley de Moore y las mejoras de hardware.

Justin o David:
[4:20] Sí, no es muy bestia.

David:
[4:23] Pero ahora, de nuevo, tenemos permiso para ser extremadamente ambiciosos ahora que la tecnología está alcanzando la madurez.

Ryan:
[4:29] De acuerdo. En los últimos cuatro años, hemos pasado de 30 millones a 45 millones en la capa uno de Ethereum. Sin embargo, según tengo entendido, en los primeros días, tal vez esto sea en 2016, era como 6 millones de límite de gas. Así que pasamos de algo inferior a 30 millones. Y la forma en que logramos que es sólo como la ingeniería en bruto. Pero llamar a esa escala en la L1 de todos modos, modo bestia, no es del todo correcto. Quiero decir, ¿qué hicimos? Esto es como un tres a cinco X, algo así. Y tomó 10 años de la historia de Ethereum. Pero cuando decimos gas y los límites de gas y ese tipo de cosas, lo que estamos hablando es de transacciones por segundo, ¿verdad? O al menos es un proxy para las transacciones por segundo. Nos vamos a referir mucho al tamaño de bloque a lo largo de este episodio. ¿Puedes definir qué es el tamaño de bloque y cómo se relaciona con las transacciones por segundo y el escalado general?

David:
[5:32] Por supuesto. Así que la transacción más simple posible se llama transferencia y consume 21.000 gas. No tienes que recordar este número, pero en promedio, estamos haciendo transacciones más complejas.

David:
[5:44] Por ejemplo, tenemos swaps DEX, y esos consumen 100.000 de gas. Así que si tienes un giga de gas por segundo, es decir, 1.000 millones de gas por segundo, y lo divides por tu transacción media de 100.000 gas, obtienes el 10K TPS. Y continuando con nuestro tema de las potencias de 10, hay aproximadamente 100.000 segundos en un día, y hay aproximadamente 10 mil millones de personas en la Tierra. Y así, si usted fuera a denominar por ser humano, lo que se obtiene es 0,1 transacciones, por ser humano por día, que en mi opinión es un gran comienzo, pero no es suficiente para todas las finanzas, ¿verdad? Como humanos, hacemos más de una transacción financiera cada 10 días.

Ryan:
[6:28] Y también están los robots que vienen en cadena.

David:
[6:31] Absolutamente. Un gran amplificador. Y así lo que espero que podamos lograr en términos de escala en el largo plazo es de 10 millones de transacciones por segundo. Esa es la era TerraGas. Y eso desbloquea un centenar de transacciones por día por humano.

Ryan:
[6:46] De acuerdo, pero así que el giga gas es que la esperanza es lograr eso y el plan en Ethereum magra es lograr que en Ethereum capa uno. ¿Estoy en lo cierto? Y luego los teragas están en el ecosistema de la capa dos de Ethereum comprometiendo, ya sabes, un dato a la capa de disponibilidad de datos a escala de Ethereum. Correcto.

David:
[7:08] Así que TerraGas es el agregado de todos los roll-ups combinados. Y se puede pensar en ello, en términos generales, como si fueran mil copias de la L1, cada una haciendo un giga gas.

Ryan:
[7:19] Bueno. ¿Dónde estamos ahora? Así que si estamos tratando de llegar a giga gas en el L1 y TerraGas en el L2, usted mencionó algunos números de donde Ethereum es. ¿Era el límite de 60 millones de gas? ¿Cuál es el límite de gas actual y a qué distancia estamos?

David:
[7:36] Sí, el límite de gas es muy confuso porque tenemos ranuras de 12 segundos. Hay que redenominar todo hasta el segundo. Pero en L1, estamos a unas 500 veces de ese objetivo. Así que entre dos y tres órdenes de magnitud. Y en gran medida, el principal cuello de botella que tenemos hoy es el validador. Así que nos fijamos como una restricción, como un objetivo, para tener la máxima descentralización. Y no estamos permitiendo a los validadores, o al menos no estamos asumiendo que los validadores tienen un hardware potente. Se están ejecutando en los ordenadores portátiles. El meme ha sido Raspberry Pi, Y mediante la eliminación de este cuello de botella, podemos fácilmente, en mi opinión, obtener un 10x, un 100x. Y con suficiente trabajo, podemos conseguir este 500x que nos lleva a un giga de gas por segundo.

Ryan:
[8:28] De acuerdo. ¿Y cuántos giga gas por segundo es Ethereum en este momento? Así que usted dijo que es sólo porque estamos traduciendo varias cosas. Dijiste... Es dos megagas por segundo. ¿Es cuánto?

David:
[8:39] Dos megagas por segundo.

Ryan:
[8:42] Ok. Así que es dos megagas por segundo en este momento.

Justin o David:
[8:45] Y queremos 1.000 megagasts.

Ryan:
[8:48] Vale, por eso estamos a 500x. Otra forma de traducir eso es que tenemos 20, alrededor de 20 transacciones por segundo, tal vez, para esas transacciones simples en Ethereum. Y queremos ser 10.000. Así que de nuevo, eso es 500x fuera ahora mismo. Eso es lo que el modo bestia está diciendo. Vamos a hacer 500x en la capa 1 de Ethereum, ¿correcto?

David:
[9:08] Esa es mi esperanza. Esa es la visión que estoy tratando de presentar. Y poco a poco cada semana con más y más desarrollos en los ZKVMs, la gente está empezando a creer esta visión de que es realmente posible.

Ryan:
[9:20] Bueno, eso es interesante. Así que vamos a hablar de visión y ejecución a lo largo de este episodio en muchos lugares. Pero en realidad, antes de que lo hagamos, ya que todavía estamos estableciendo el contexto para esto, creo que algunas personas estarán rascándose la cabeza y diciendo, bueno, ¿por qué estás tú, Justin, hablando, y por qué Ethereum en general habla de escalar la L1 en absoluto? Pensaba que el plan era la hoja de ruta centrada en el roll-up donde la capa uno de Ethereum se mantiene bastante lenta. Sí, tal vez se escala un poco como la ley de Moore mejora y como la ingeniería mejora un poco, pero no va a modo bestia, porque el plan de modo bestia, pensé que ya se había definido como la hoja de ruta centrada en roll-up. Y toda la escala en Ethereum ocurre en L2s. Bueno, estás diciendo, no, vamos a seguir escalando el L2, pero también estamos escalando el L1. Y algunas personas se rascarán la cabeza y preguntarán, ¿por qué? ¿Es un cambio? ¿Es un giro?

Ryan:
[10:22] ¿Por qué estamos tratando de escalar la L1 en primer lugar?

David:
[10:25] Yo diría que sí, que es un cambio. Es un giro porque ahora tenemos una tecnología que nos permite escalar preservando la descentralización. Lo primero fue la necesidad de descentralización. Y luego tratamos de hacer lo mejor con ese requisito. Y ese es el statu quo que tenemos. Pero ahora que tenemos una nueva tecnología, podemos empezar a replantearnos el tipo de escala que podemos tener en L1. Así que la primera respuesta es porque podemos. La segunda respuesta es que si queremos que Ethereum L1 sea un centro, es decir, el lugar donde se acuñan los activos, donde se producen los puentes, donde se producen las retiradas forzosas, donde se produce gran parte de la liquidez de alto valor, entonces necesitamos que L1 tenga una cantidad mínima de escala que, Y 0,1 transacciones por humano, se debe pensar que es la mayor densidad de transacciones económicas que puede hacerlo. Todos los demás serán potencialmente excluidos. Así que puedes pensar en ello como transacciones de liquidación, como transacciones de acuñación, como transacciones donde promulgas una escotilla de escape, donde tienes 100.000 dólares atascados en un L2, el secuenciador se ha desconectado o algo así, bueno, puedes simplemente forzar la retirada y estarás dispuesto a pagar los 10 céntimos o lo que sea en L1 con el fin de liberar tus fondos.

Ryan:
[11:51] Así que esas son las dos razones. Volviendo a la primera, porque podemos, esto implica que antes no podíamos y tendremos toda una conversación sobre snarks y esta criptografía mágica que ha surgido, digamos, y se ha endurecido en la última década más o menos. Pero la idea de que estamos escalando el L1 ahora porque podemos significa que antes no podíamos. Casi significa que escalar el L1 habría sido la primera opción si hubiéramos podido. Como, ¿es mejor escalar el L1 que escalar el L2? Y si hubiéramos podido, digamos en 2018, es decir, si Snarks se hubiera liberado entonces, ¿habría sido el camino por defecto en lugar de los L2?

David:
[12:39] Creo que sí. Creo que si hubiéramos sido capaces de escalar, digamos, hace cinco años con ZKVMs, eso es probablemente lo que habríamos hecho, pero no habría sido suficiente. Todavía tendríamos que seguir por el camino de la disponibilidad de datos para desbloquear los millones de transacciones por segundo y que necesitamos para acoger todas las finanzas. Y así, en cierto sentido, hay como una ordenación diferente que habrá sucedido, pero creo que todavía habríamos ido por el camino difícil de trabajar con SNARKs para la ejecución y trabajar con muestreo de disponibilidad de datos para el ancho de banda. Y se puede pensar en estas dos herramientas, SNOX y la disponibilidad de datos como dos caras de la moneda de escalado. Se trata básicamente de ancho de banda y computación, que son los dos recursos primitivos que consumirá una cadena de bloques.

Ryan:
[13:31] Algunas personas todavía estarán confundidas por esa respuesta, Justin, porque dirán, espera, espera un segundo, ¿por qué no pudiste escalar Ethereum en 2018? Y señalarán otras cadenas de capa uno actuales que sí están escalando. Quiero decir, tienes algunos L1s que están diciendo que pueden escalar a 10.000 transacciones por segundo y más allá. Algunos están en el rango de un millón de veces. Creo que Solana está haciendo miles de transacciones por segundo en el pico, por lo menos, y prometen mucho más. Entonces, ¿se trataba de un problema de habilidad? ¿Por qué Ethereum no podía escalar?

David:
[14:09] Sí, es una buena pregunta. Muchos de los L1 de alto rendimiento tienen una descentralización relativamente pobre. Así que en el orden de 100 validadores, Monad, por ejemplo, en términos generales, Ballpark, tienen 100 validadores, Say, 100 validadores, cadena BNB, incluso menos validadores.

David:
[14:32] Y no sólo tienen un pequeño número de validadores, sino también la barrera de entrada para convertirse en un validador es tener un servidor en el centro de datos, porque es necesario almacenar una gran cantidad de estados, es necesario tener una conexión a Internet muy fiable y de alto rendimiento, es necesario tener un montón de memoria RAM, es necesario tener CPUs rápidas. Y ese es el tipo de cosas que son más difíciles de conseguir en casa. Y también es la estrategia que ha adoptado Solana. Así que Solana en promedio es de alrededor de mil transacciones de usuarios por segundo, y tienen menos de mil validadores. Y si nos fijamos en el mapa de donde estos validadores son, es casi en su totalidad en los centros de datos. Y la gran mayoría de ellos, más del 50% de ellos son, creo, en dos centros de datos que son como sólo unas pocas decenas de kilómetros de distancia el uno del otro. En Europa. Así que es muy, muy concentrado. Y eso no es algo que hemos tolerado en Ethereum.

Ryan:
[15:40] ¿Puedes nombrar la restricción entonces? Parece que Ethereum no tolera algo, no tolera que los validadores funcionen dentro de los centros de datos. Así que hay alguna restricción autoimpuesta en el diseño. Nombre que. ¿Cuál es esa restricción frente a, por qué no podemos simplemente capitular y empezar a ejecutar cosas en centros de datos como algunas de las otras cadenas han comenzado a hacer.

David:
[16:05] Nos preocupamos por las conexiones a Internet en casa y el hardware básico, como un ordenador portátil. Y parte de la razón tiene que ver con la capacidad de respuesta. Hace poco tuvimos una interrupción de AWS, varias cadenas se desconectaron. Eso no es lo que queremos con Ethereum. Pero somos muy paranoicos hasta el punto de que queremos tener un modelo de seguridad donde incluso si todos los operadores de centros de datos en el mundo deciden atacar Ethereum simultáneamente, todavía tiene tiempo de actividad. Y hay aproximadamente, digamos 100 operadores de centros de datos en el mundo. Así que esto no es totalmente descabellado. Y supongo que otra diferencia es que, ya sabes, estamos tratando de tener el mejor tiempo de actividad en su clase, ¿verdad? Hemos tenido 100% de tiempo de actividad desde Génesis. Y parte de eso es no cortar esquinas. Y creo que lo que algunas de estas otras cadenas han hecho es que han estado dispuestos a cortar las esquinas con el fin de obtener un mayor rendimiento.

Justin o David:
[17:08] Cuando hablamos de pasar de hacer un 500X en términos de rendimiento de gas de donde estamos ahora en dos megagas por segundo a mil megagas por segundo, un 500X no es sólo algo que se puede diseñar. La razón por la que estamos haciendo esto hoy es porque Ethereum está pasando por

Justin o David:
[17:28] algo más cercano a una evolución en lugar de como una actualización de ingeniería. Y algunas de las cadenas que acabamos de hablar siempre han sido como la ingeniería en primer lugar. Y ahí es donde algunos de los beneficios de rendimiento ha venido. Como Solana ha sido muy ingeniería pesada y que acaba de producir nodos bien diseñados y clientes de ejecución. Y entonces, ¿dónde está ese software mejor expresado en su mejor forma? Bueno, en un centro de datos, poner las cosas fuertemente ingeniería en un centro de datos. Y ahí es donde muchas de las cadenas de escalado modernas de 2020 a 2025 han obtenido parte de su rendimiento.

Justin o David:
[18:04] Ahora, Ethereum ha sido paciente, pero con el fin de conseguir que 500x, no es realmente una cosa de ingeniería. Es más como una evolución. Se ha abierto un nuevo camino con algunas de las cosas de las que has hablado, Justin, con todo el proceso ZK. Era, donde no es necesariamente sólo la ingeniería, pero en realidad es la criptografía que está abriendo un camino para hacer algo así como un 500x. Y eso siempre ha estado en el bolsillo trasero de Ethereum desde el primer día. Eso siempre ha sido como la estrategia de escalado teórico. Y en los últimos años, creo que usted y la gente en la Fundación Ethereum sería como, está bien, este camino está claro para nosotros, y ahora estamos listos para tomarlo. Ese es mi diagnóstico de los últimos años. ¿Es así?

David:
[18:48] Sí, así es. Realmente, la clave en el registro aquí es sólo la criptografía. Y en términos de los requisitos que tenemos para la criptografía, también son extremadamente altos. Así que una de las cosas que nos importa, por ejemplo, es la diversidad. Esta es una criptografía complicada, y queremos tener el mismo tipo de diversidad que disfrutamos hoy en día en la capa de consenso y en la capa de ejecución con los equipos de consenso y el equipo de ejecución. Así que espero que podamos tener cinco máquinas virtuales ZKE diferentes con fallos no correlacionados. Otro requisito importante para la criptografía se llama prueba en tiempo real. Existe la idea de que cuando se produce un bloque, la prueba de ese bloque debe llegar antes que el siguiente. Así que la latencia debe ser inferior a una ranura Ethereum, que es menos de 12 segundos. Y entonces...

David:
[19:43] Otro requisito que tenemos más allá de la seguridad y la latencia es el consumo de energía. Volviendo al comentario sobre los centros de datos, no queremos que los demostradores estén en centros de datos, porque se introduce un nuevo punto de estrangulamiento. Así que lo que esperamos es tener pruebas en el lugar. Y por in situ, nos referimos a in situ en una casa, en un garaje, en una oficina. Y el número concreto que tenemos en mente es de 10 kilovatios.

David:
[20:20] Así que sólo para darte un orden de magnitud, una tostadora consumirá un kilovatio. Así que es el equivalente a 10 tostadoras. Y también es lo mismo que un cargador doméstico Tesla que consumirá aproximadamente 10 kilovatios. Y así, si podemos tener millones de cargadores domésticos en todo el mundo, entonces es razonable tener este requisito para los demostradores. Y una cosa que vale la pena destacar es que a diferencia del consenso, que requiere que la mitad de los participantes se comporten honestamente, sólo necesitamos un probador honesto para que todo funcione. Así que por eso hay requisitos de hardware muy diferentes en los participantes del consenso. Aquí, queremos tener la menor barrera de entrada posible, piensa, ya sabes, una Raspberry Pi o un ordenador portátil, porque es una suposición de honestidad del 50%. Pero para los probadores, es una de n suposición, y está bien para golpear hacia arriba.

Ryan:
[21:18] Bueno, así que estamos empezando a desempaquetar casi la capa de modo bestia, la capa de ejecución con algunos de esos componentes. Yo personalmente todavía no estoy listo para llegar allí, en realidad. Así que todavía tengo algunas preguntas. Lo que acabas de describir es una pila que nos permite seguir haciendo el blockchain

Ryan:
[21:36] validación o verificación fuera de un centro de datos de una conexión a Internet en casa. Y todavía quiero saber por qué o qué casos de uso son importantes para eso. Usted dijo que parte de esto es acerca de la capacidad de recuperación y el tiempo de actividad. Y, de hecho, Ethereum ha tenido 10 años de tiempo de actividad ininterrumpida. Y eso es fantástico. Pero hay otras propiedades que la descentralización y el tiempo de actividad imbuye. Uno de ellos, muy famoso, con Bitcoin y Ethereum, como usted ha venido y discutido en Bankless, es la propiedad de tener su cryptocurrency ser un almacén de activos de valor. Así que Bitcoin está todavía en la criptografía 1.0. No está haciendo ninguna cosa snarks. Eso no está realmente en la hoja de ruta. Pero ha mantenido un rendimiento muy bajo, muy bajo a través de TPS, pero también muy bajos requisitos de nodo. Así que usted puede ejecutar un nodo Bitcoin desde su casa. No es una cadena de centros de datos.

Ryan:
[22:40] Similar a Ethereum. Pero yo sólo quiero saber por qué. Porque para Bitcoin, son muy claros en el por qué. Es porque Bitcoin es un depósito de valor. Es porque es un oro digital y todo el mundo necesita acceder a él. Ahora, hemos argumentado en Bankless que a 10 transacciones por segundo, parte de ese acceso probablemente tomará la forma de micro estrategia y ETFs. Y usted no será capaz de hacer cosas en DeFi que usted puede si usted está realmente escalando su capa base. No quiero repetirlo. Pero quiero hacer la pregunta de ¿por qué? ¿Qué casos de uso en Ethereum L1 son importantes? Vitalik escribió una entrada en el blog hablando de DeFi lento. ¿Es ese uno de ellos? ¿Es el caso de uso de la tienda de valor? Añadiré otra dimensión. Hemos tenido gente que ha venido al podcast y ha dicho que la hoja de ruta de Ethereum es defectuosa porque se obsesionan con la descentralización. Se obsesionan con tener nodos que puedan funcionar en la casa de alguien. Si se elimina esta obsesión, se podría escalar mucho más rápido y no entienden la razón de la obsesión. Así que lo que los casos de uso es como Ethereum sobre el aprovisionamiento de sí mismo. ¿Qué casos de uso son más propicios para esta descentralización, lo llamaré obsesión, restricción que Ethereum se ha autoimpuesto? ¿Es DeFi? ¿Es un almacén de valor? ¿Qué es?

David:
[24:00] Es reserva de valor. Es dinero. Y puedes verlo empíricamente hablando. Tienes el, dinero número uno, Bitcoin, que es exactamente lo contrario del modo bestia, ¿verdad? Es un pedazo de mierda, ¿verdad? Es como, tienes un...

Ryan:
[24:18] Espera, ¿qué es un pedazo de mierda?

David:
[24:20] ¿Bitcoin el activo? Blockchain, la cadena, perdón. La cadena de bloques en sí.

Justin o David:
[24:25] Que incluso Bitcoiners dirá que el blockchain Bitcoin es un gravamen sobre BTC, el activo. Eso en realidad está alineado con Bitcoin o la filosofía.

David:
[24:33] Y sin embargo, es un activo de $ 2 billones. Y luego tienes algo entre Ethereum, que está tratando de conseguir algo de rendimiento y algo de robustez y neutralidad creíble. Y somos un activo de $ 500 mil millones. Y luego tienes algo que se apoya totalmente en el modo bestia, como Solana, y son un activo de $ 100 mil millones. Y las nuevas cadenas que se apoyan aún más en el modo bestia tienen valoraciones más bajas. Así que creo que el dinero requiere esta prima mimética. Y es que el mercado nos ha dicho empíricamente que la solidez, el modo de pensamiento, el tiempo de actividad, la neutralidad creíble, moverse lentamente, tener estas garantías a largo plazo son cosas que son extremadamente importantes.

Ryan:
[25:27] Tiene sentido para mí que el almacén de valor sería el caso de uso primario para algo como Bitcoin o Ethereum, porque si lo piensas desde la perspectiva del usuario, quieres poner tu valor en un lugar. Usted puede ir a una cueva, ya sabes, durante 10 años y salir y todavía está allí. Eso es almacenamiento de valor. En realidad estás almacenando valor a través del tiempo.

Ryan:
[25:50] Y Bitcoin tipo de ha conseguido este derecho. Pero creo que cuando hablas de reserva de valor, también son instrumentos al portador, ya sabes, por ejemplo, no sé si me interesa el USDC en Ethereum como reserva de valor y ponerlo en Ethereum e ir a una cueva durante 10 años y salir. No sé lo que podría pasar con USDC. Podría, ya sabes, Jeremy Allaire, estoy seguro de que está en manos grises, cualquier ley podría cambiar. Usted sabe, podría de-peg, algo malo podría suceder a USDC. Así que el caso de uso de la reserva de valor está realmente centrado en los cripto activos nativos de Ethereum, principalmente ETH. El Ether es el activo principal para el almacenamiento de valor sobre Ethereum. Así que cuando pienso en los casos de uso tangible, y usted dice tipo de almacén de valor, las cosas que requieren descentralización máxima, es probablemente Ether el activo. Y luego tal vez un puñado de primitivas DeFi. Eso es lo que pienso. Y no son tanto los activos del mundo real, excepto porque actúan como un par comercial para algo como Ether. Así es como yo lo veo. Pero por eso tengo curiosidad por saber cómo lo ves tú,

Ryan:
[27:05] Justin, y cómo lo ve la gente dentro de la Fundación Ethereum. ¿Cuáles son las aplicaciones que van a ser más importantes en la capa uno?

David:
[27:14] Quiero decir, diferentes personas tienen diferentes opiniones dentro de la Fundación Ethereum. Pero yo estaría de acuerdo contigo en que la aplicación más importante de Ethereum es ser dinero. Y de ahí derivan todas las aplicaciones. Si quieres tener préstamos, intercambios, si quieres tener mercados de predicción, todo es en gran medida predictivo.

David:
[27:35] Predicado en tener este dinero fuerte. Y esto es especialmente cierto con estas distribuciones de ley de potencia y situaciones de "el ganador se lo lleva todo". He tratado de argumentar que una sola cadena como Ethereum puede manejar todas las finanzas. En gran medida, la razón por la que tenemos tanta fragmentación en L1 es porque Ethereum no ha crecido lo suficientemente rápido como para absorber toda la innovación. Pero ahora tenemos una hoja de ruta creíble para absorberla en su totalidad. Y si nos fijamos en la prima monetaria, el ganador se lleva la mayor parte. Tienes que convencer de alguna manera a la sociedad de que tu activo es el más legítimo. Y si te fijas en los competidores, por ejemplo, te fijas en los activos sólidos.

David:
[28:30] Eso acaba de ser descalificado por ser dinero, en mi opinión. ¿Verdad? Como el hecho de que tenía 10 interrupciones en un puñado de años sólo lo descalifica inmediatamente. Así que lo más importante es permanecer el tiempo suficiente en el juego y no ser descalificado. Y ahora tenemos estos dos, básicamente, los activos que están compitiendo, Bitcoin y Ether. Y creo que en unos pocos años, Bitcoin será descalificado debido a su blockchain también. No porque falló en modo bestia, sino porque falló en modo fortaleza. No será capaz de asegurarse a sí mismo con la menguante emisión.

Ryan:
[29:11] ¿Una emisión decreciente es una especie de caso de oso para Bitcoin entonces?

David:
[29:15] Sí. Si nos fijamos en las tasas de transacción en este momento, es alrededor de la mitad de todos los ingresos que los mineros hacen. Así que el 99,5% proviene de la emisión. Y sabemos que esa fracción va a cero, estamos teniendo cada cuatro años. Y ahora mismo, Bitcoin está asegurado por tres Bitcoin al día de tasas. Tres Bitcoin por día no es suficiente para asegurar Bitcoin.

Justin o David:
[29:39] Así que hemos hablado de la dicotomía entre el modo bestia y el modo fortaleza. Y ahora quiero nombrar nuestros prejuicios porque yo, Ryan, Justin, todos entramos en cripto, en Ethereum en 2017 y antes. Y eso es realmente cuando el modo de descentralización fuerte era el juego. Y eso es algo así como nuestra generación de cripto. Las nuevas generaciones de cripto realmente valoran el modo bestia mucho más que el modo fortaleza. Creo que cualquiera que haya entrado en cripto 2021 o más tarde probablemente tiene una cantidad desproporcionadamente baja de su cartera de Bitcoin en comparación con las personas que vinieron antes de 2021. Y algo que quiero decir, a pesar de que estábamos hablando de que, sí, toda la idea es el dinero. El modo de fortaleza es tu boleto de entrada para estar dentro de la competencia del dinero. Sin embargo, las preferencias de los usuarios después de 2021-ish realmente ha preferido el modo bestia y la transacción, el volumen de transacciones, las tasas de transacción ha poco a poco, el péndulo se ha desplazado hacia las cadenas que van rápido, las cadenas que hacen el modo bestia.

Ryan:
[30:45] Y así, mientras que- Yo añadiría, David, independientemente de las limitaciones, ¿verdad?

Justin o David:
[30:49] Independientemente de las limitaciones.

Ryan:
[30:50] No validador de origen tipo de restricción.

Justin o David:
[30:52] Sí. Y así que no quiero que hablemos demasiado sobre el modo bestia porque en realidad eso es lo que Ethereum está tratando de hacer en 2025 y más allá es que sentimos que hemos cubierto el modo fuerte y ahora podemos desbloquear el modo bestia. Y el modo bestia tiene mucho valor. Ahí es donde se obtiene la financiación global componible todo en una cadena. Ahí es donde caben toda la humanidad, todas las finanzas, todo en una cadena. Ahí es donde se obtiene la adopción del usuario y todas las grandes cosas que vienen con una cadena de contrato inteligente. Y así, mientras yo estoy en este bando, todos estamos en este bando del tipo de modo fuerte es la cosa genial que los blockchains realmente proporcionan de forma única al mundo. Sin embargo, las preferencias de los usuarios se han ido alejando del modo fortaleza...

Justin o David:
[31:37] modo bestia como blockchains se convierten en la corriente principal adoptada. Y ahora la estrategia de Ethereum es penetrar agresivamente en ese mercado con algunas de las tecnologías y las estrategias de las que vamos a hablar en el resto.

David:
[31:49] De este episodio. Sí. Así que estoy de acuerdo en que Ethereum está tratando de trazar un nuevo territorio para sí mismo con el modo bestia. Pero una cosa que quiero destacar es que si tienes modo bestia sin modo fuerte, es una actividad muy superficial. Y una forma de medir esto es mirar las monedas meme en Solana. Ahí es donde ocurrió gran parte de la actividad. Y, ya sabes, tenemos más de 10 millones de monedas meme en Solana y la capitalización de mercado agregada de todas las monedas meme en Solana es menos de $ 10 mil millones, que es una gota absoluta en el cubo. Así que, sí, había un montón.

Justin o David:
[32:24] ¿Es $ 10 mil millones una gota en el cubo?

David:
[32:26] Así que, ya sabes, en relación con las monedas estables, por ejemplo, como una sola moneda estable en Ethereum L1 Tether es más de $ 100 mil millones. Así que eso es sólo un caso de uso, 10 veces más grande. Usted podría mirar a los préstamos en Avid que es como, también decenas de miles de millones de dólares. Pero también se puede mirar, ya sabes, la capitalización de mercado Ethereum, que es 50 veces mayor. Hay un activo 50 veces más grande que 10 millones de activos combinados. Tal vez vamos a hablar.

Ryan:
[32:53] Más sobre stablecoins más adelante en el episodio cuando, ya sabes, porque tengo esta pregunta pendiente de hasta qué punto, ¿las stablecoins realmente necesitan el modo bestia con garantías de seguridad de descentralización de Ethereum L1? Pero vamos a reservar esa pregunta para más adelante.

Ryan:
[33:08] Y tomemos esto en las secciones que habías expuesto. Así que volviendo a lo que estabas diciendo antes en el episodio, cuando hice la pregunta, ¿qué es lean Ethereum? Dijiste que es Snarks. Esa es la criptografía mágica que hemos desbloqueado. Es el modo bestia, que está escalando Ethereum en el L1 y el L2 desde una perspectiva de transacciones por segundo. Y es el modo fortaleza, que defiende la descentralización, la barrera de entrada más baja posible para que alguien dirija un nodo. Así que vamos a tomar el resto del episodio y entrar en cada una de estas secciones.

Ryan:
[33:43] Snarks. Bien, esto es criptografía mágica. Justin, te tuvimos en un episodio. Creo que este es tal vez el primer episodio que hiciste con Bankless. Esto debe haber sido hace unos cuatro años. Y tenías este principio que se me ha pegado desde entonces, que es básicamente como la verdadera forma de escala blockchain es con la criptografía. Esa es la primera opción. Así es como Bitcoin fue capaz de hacer lo que está haciendo. Y luego, cuando la criptografía falla, vas a la economía y la criptoeconomía. Pero el estándar de oro es que si puedes escalar con criptografía en cualquier tipo de diseño de protocolo o diseño de mecanismo, entonces escalas con criptografía. Tanto Bitcoin como Ethereum se basaron en criptografía que ha sido popular durante un tiempo. No sé, lo llamaré la criptografía que tenía Lindy en la década de 2010, ¿verdad? En eso se ha basado Ethereum hasta ahora. Ahora entra SNARKs. Cuéntanos la historia de la criptografía en la que se basa Ethereum hoy y esta actualización basada en SNARKs. ¿Y en qué consiste esta nueva criptografía?

David:
[34:51] Sí, desde Bitcoin, la criptografía que hemos estado utilizando es extremadamente primitiva. Y son dos piezas diferentes de criptografía. La primera se llama funciones hash. Esa es la cosa a partir de la cual puedes construir bloques y cadenas. Es lo que usas para Merkleizar el estado. Y básicamente, son muchos árboles Merkle. Y luego la otra pieza de la criptografía se llama firmas digitales, o simplemente firmas. Y eso te permite autenticar la propiedad y firmar transacciones.

David:
[35:25] Y hoy en día, mirando hacia atrás en 2025, esto es criptografía de la Edad de Piedra en relación con lo que tenemos hoy. Y estos nuevos snarks primitivos realmente liberan todo un nuevo espacio de diseño para blockchains. Y en particular, nos permiten resolver este dilema, o algunos lo llaman trilema, entre escala y descentralización. Podemos resolver este viejo dilema básicamente haciendo que los validadores verifiquen estas pruebas cortas y que estas pruebas detrás de ellas tengan tanta ejecución como los constructores de bloques y la cadena puedan absorber. Así que si nos fijamos en los dos recursos básicos que tenemos para escalar, el primero es la ejecución. Tenemos reservas para eso. Y el otro son los datos. Y aquí tenemos el muestreo de valor de datos.

David:
[36:31] Ahora, además de querer tener estos dos desbloqueos desde una perspectiva de escalado, también queremos asegurarnos de que la criptografía que tenemos es sostenible a largo plazo. Y lo que eso significa en nuestro contexto es seguridad post-cuántica. Así que hoy, para los datos de muestreo temprano, hemos tomado un pequeño atajo. Pero hemos desplegado la criptografía llamada KZG, que no es post-cuántico seguro. Así que tenemos que tener algún tipo de plan para actualizarlo. Y aquí es donde los SNARKs también ayudan más allá de la escala. También ayudan con la seguridad post-cuántica en la capa de datos.

Ryan:
[37:19] Creo que hace cuatro años, estabas hablando de SNARKs y el término que usaste, de hecho, creo que titulamos el episodio es matemática lunar, ¿verdad? Era una especie de matemática lunar emergente. Y ha estado fuera por un tiempo, sólo para las personas que no son criptógrafos, ¿de acuerdo? Quiero decir, no necesitamos entrar en los detalles de lo que SNARKs son y lo que puede hacer. Creo que para mucha gente que nos escucha, es suficiente para que entiendan, oh, esto es matemática lunar, y se ha utilizado en la práctica durante un tiempo, y es razonablemente seguro. Cuando decimos SNARKs y ZK, porque antes usaste el término ZK EVMs, ¿ZK y SNARKs, son lo mismo? ¿Cómo es que a veces usamos ZK y ahora usamos SNARK? Quizá la gente no entienda las diferencias entre estos términos.

David:
[38:06] Claro, el término técnico es SNARK. La S significa sucinto. Se puede decir que es pequeño. Y luego la parte NARC, argumento no interactivo del conocimiento. Eso es sólo un lenguaje elegante para la prueba. Así que Snark no es más que una pequeña prueba. Ahora, resulta que esta tecnología, los Snarks, también nos dan gratis otra propiedad llamada conocimiento cero, que es relevante en el mundo de la privacidad. Pero no estamos usando esa propiedad para escalar.

Ryan:
[38:40] Entonces, ¿cómo podemos llamarlos ZKEVMs?

David:
[38:42] Es muy confuso.

Ryan:
[38:43] No son privados.

Justin o David:
[38:44] No hacemos un muy buen trabajo de nombrarlo en esta industria.

Ryan:
[38:46] ¿Deberían llamarse Snark EVMs? ¿De verdad?

David:
[38:49] Deberían llamarse EVM Snark, sí.

Ryan:
[38:51] De acuerdo. No vamos a ganar esa pelea hoy. No estamos aquí para jugar a ese juego.

David:
[38:55] Es una pelea perdida.

Ryan:
[38:56] ¿Cuánto tiempo han snarks estado ahí fuera? Así que todas las cadenas de primera generación de hoy, todas las cadenas que tenemos en producción, Bitcoin, Ethereum, todas han estado usando criptografía más primitiva, como dijiste, funciones hash, firmas digitales. Hubo un experimento llamado Zcash. Y la Z, creo, significa conocimiento cero o snarks, ¿verdad? Ellos usan algo de esa tecnología. Y eso ha sido en vivo desde, no sé, 2014, algo así. Zcashers, corrígeme en las fechas aquí. Supongo, ¿qué tan robusta es esta tecnología? ¿Cómo lindy es? ¿Cómo en uso es? ¿Estamos seguros de que estamos listos para el primetime en una cadena que asegura casi un billón de dólares en valor?

David:
[39:36] Correcto. Así que Zcash se lanzó, creo, en 2016, hace nueve años. Y cuando miras hacia atrás, fueron pioneros absolutos, pero también fueron DGens, como DGens criptográficos. Destruyeron la criptografía, que era, ya sabes, era como construir cohetes, ¿verdad? Podría explotar en su cara. Y de hecho, hubo un momento en el tiempo en que explotó, ¿verdad? No sé si te acuerdas, pero hace unos años, Zcash tuvo un fallo crítico por el que cualquiera podía acuñar una cantidad arbitraria de tokens ZEC.

Ryan:
[40:09] Correcto, y debido a que es privado, en realidad no sabemos si eso sucedió o no, si el error fue explotado o no, ¿verdad? No lo sabemos con seguridad.

David:
[40:17] Exacto. Y entonces...

David:
[40:19] Y una de las grandes cosas que tenemos que hacer es resolver el problema de seguridad. Y hay ampliamente dos soluciones que son satisfactorias para Ethereum. La primera es tener diversidad de SNARKs. Así que tienes cinco proveedores SNARK diferentes y aceptas que un bloque sea válido. Por ejemplo, si tres de estos SNARKs devuelven válido, y usted puede seguir adelante de una manera muy similar que tenemos la ejecución y la diversidad de la capa de consenso. La otra forma de avanzar es lo que llamamos verificación formal, donde elegimos un único sistema de prueba, y lo auditamos hasta el punto en que tenemos altas garantías de que hay literalmente cero errores. Es un poco como escribir una prueba matemática de la corrección de toda la implementación de SNARK. Ahora, por desgracia, estamos un poco demasiado pronto para esa verificación formal de extremo a extremo, pero hemos comenzado el trabajo. El año pasado anunciamos un programa de verificación formal de 20 millones de dólares.

David:
[41:26] Que está dirigido por Alex Hicks. Y se están haciendo muchos progresos. Y mi expectativa es que esta década, tal vez en 2029, 2030, tendremos un snark verificado formalmente de extremo a extremo, que tiene cero errores. Ahora, la otra cosa que quiero mencionar es que Zcash tenía un caso de uso extremadamente simple, que es sólo transferencias.

David:
[41:50] Y lo que hicieron es que escribieron los llamados circuitos personalizados. Así que se ensuciaban mucho las manos con estos snarks. Pero el enfoque moderno.

David:
[42:04] Es lo que se llama ZKVMs, que es básicamente una forma de hacer uso de la potencia de los SNARKs sin ser un experto en SNARKs. Así que un desarrollador típico, como un desarrollador de Rust, por ejemplo, puede escribir programas típicos y compilarlos en la ZKVM. Y este es en realidad uno de los requisitos para que la tecnología SNARK sea lo suficientemente madura para la L1. Y la razón es que queremos tomar las implementaciones EVM existentes y compilarlas en la ZKVM. Así, por ejemplo, nuestra EVM, que es la implementación de EVM dentro de ref, que es uno de los clientes de la capa de ejecución, la tomamos y la compilamos a las ZKVM. Podemos tomar EVM1, que es otra implementación, compilar esto, EFREX, hay ZKsync OS, y también hay implementaciones que están escritas Y en Go, por ejemplo, Geth tiene una implementación EVM. Nevermind tiene una implementación en C-sharp. Y queremos tomar tantas de estas implementaciones como sea posible y compilarlas a los KVM. Y esa es una tendencia muy reciente. Es algo que sólo existe desde hace uno o dos años.

Ryan:
[43:19] Pero nos sentimos bien, supongo, confiando en SNARCs como una tecnología central para Ethereum en la capa L1. Quiero decir, no son tan maduros como las funciones hash, que han existido desde ¿cuánto? No sé, como décadas, ¿verdad? 1970s, 1980s, ¿algo así? ¿Las firmas digitales también? Quiero decir, estas son primitivas criptográficas muy endurecidas. ¿Los Snarks tienen cuánto, 15 años?

David:
[43:49] Así que teóricamente hablando, tienen algo así como 30 años. Pero en la práctica, Zcash fue uno de los primeros proyectos en ponerlos en producción. Y eso tiene unos 10 años.

Ryan:
[44:00] Bien. Pero nos sentimos bien acerca de Snarks como una pila de tecnología ahora. Y en general, ¿son los Snarks comúnmente aceptados en los círculos de criptografía profunda como, sí, esto funciona. Las matemáticas se comprueban. No se puede romper.

David:
[44:14] Sí. Pero hay Snarks y Snarks. Así que tenemos todos los requisitos. Tenemos la prueba en tiempo real es un requisito. Tenemos diversidad. Tenemos el aspecto ZKVM. Y también tenemos el requisito de prueba en tiempo real. Y tenemos el requisito de 10 kilovatios para liveness.

Justin o David:
[44:35] Hay una cita de Elon Musk que creo que es relevante aquí que me gusta, que dice, el error más común de un ingeniero inteligente es optimizar una cosa que en su lugar debe ser eliminado. Quiero que tomes esa metáfora como, ¿por qué estamos haciendo esto? Así que estamos hablando de los snarks y las matemáticas detrás de ellos y cómo funcionan. En realidad, vamos a ampliar y hablar de como el por qué, porque esto es en realidad haciendo lo que haría feliz a Elon Musk. Está eliminando todo un componente, que otras cadenas han optado por optimizar. ¿Puede hablar de eso un poco?

David:
[45:06] Por supuesto. Hoy en día, cuando ejecutas un validador, estás ejecutando dos clientes separados. Estás ejecutando un cliente de capa de consenso. Así que en casa, estoy ejecutando uno llamado Lighthouse, y también estás ejecutando un cliente de capa de ejecución. Y lo que estoy ejecutando en casa se llama GEF. Y realmente lo que queremos tratar de hacer es eliminar el cuello de botella a la escalabilidad. Y en este caso, es GEF. Como GEF literalmente en mi computadora no puede procesar un gigahertz por segundo, en parte porque el hardware no es adecuado, pero también el software tampoco es adecuado. Y lo que espero hacer en DevConnect en unos 25 días es apagar mi nodo GIF y eliminar por completo ese cuello de botella. Y en lugar de confiar en que GIF me diga que los bloques son válidos, descargaré pruebas ZKEVM. Y no importa lo grandes que sean los bloques. Desde mi perspectiva, la prueba siempre tiene el mismo tamaño. Esa es la S. Es distinta. Y sí, eso resuena mucho con las citas de Elon, que es que no deberíamos estar optimizando el GIF. Deberíamos eliminarlo por completo.

Ryan:
[46:18] Así que eso nos lleva a, creo, todo este tipo de ejecución magra de comercio. Y para hablar de ello con más detalle. Así que tenemos esta nueva criptografía mágica SNARKs que nos permite escalar Ethereum en general. En particular, vamos a hablar de tal vez escalar el L1 aquí y nos permite hacer eso en la forma restringida que Ethereum siempre ha operado. Y algo de lo que estás hablando, Justin, es reemplazar a Geth, que es tu cliente de ejecución. Así que esta es toda la cosa del modo bestia. Con un cliente ZKEVM. Así que en lugar de usar la antigua forma de hacer un validador, la nueva forma, creo, cambia el papel de un validador de ejecutar cada bloque, ¿verdad? Como cada transacción individual y cada bloque individual en lugar de ejecutar,

Ryan:
[47:17] Verificando que un bloque ha sido, supongo, ejecutado correctamente. ¿Puedes describirlo con más detalle? Porque esta es la parte en la que estamos hablando de modo bestia, estamos hablando de escalar el L1 aquí, estamos hablando de ejecución lean para Ethereum, y una tecnología central aquí es ZKEVMs que cambian lo que los validadores están haciendo. Y se están moviendo de ejecutar todo a sólo verificar las cosas. No sé si intuyo cómo funciona, por qué es posible...

Ryan:
[47:51] y cómo podemos hacerlo preservando la descentralización. ¿Puedes dármela?

David:
[47:55] Por supuesto. El proceso de verificación de un bloque es extremadamente intensivo. Lo primero que hay que hacer es descargar el bloque y eso ya es un cuello de botella, ¿verdad? Si los bloques son demasiado grandes, literalmente no puedes descargarlos. Si estás en una conexión a Internet doméstica. Pero una vez que tienes el bloque, lo que tienes que hacer es cargar la versión más reciente del estado de Ethereum. Y eso es del orden de cien gigabytes. Pero, por supuesto, si aumentáramos drásticamente el límite de gas, podrían ser terabytes, decenas de terabytes. Así que eso es un problema. Y luego, una vez que has cargado el estado, necesitas ir a ejecutar las transacciones. Y para eso, necesitas dos recursos. Necesitas una CPU con muchos núcleos y necesitas mucha RAM. Y además de todo esto, necesitas mantener un mempool y muchas conexiones peer-to-peer.

David:
[48:51] Y también necesitas almacenar el historial, que también puede ser de cientos de gigabytes. Así que toda esta maquinaria loca, simplemente la eliminamos por completo y la verificamos como a prueba de golpes. Es sin estado. No necesitas mantener una copia del estado. No tiene historia. No es necesario mantener una copia de la historia de FM. Es sin RAM en el sentido de que no necesitas gigabytes de RAM. Puede que necesites 100 kilobytes de RAM. No necesitas muchos núcleos, sólo necesitas un núcleo, y podría ser un dispositivo muy débil. Y de hecho, el nuevo meme que espero introducir es el de una Raspberry Pi Pico. Así que el sufijo Pico se refiere a esta pieza de hardware de 8 dólares en relación con la Raspberry Pi normal, que cuesta alrededor de 100 dólares. Y creo que al menos, ya sabes, como un experimento divertido, podríamos tener un validador que se ejecute en una Raspberry Pi Pico.

Ryan:
[49:54] Y si ese es el caso, por supuesto, ya sabes, más gente estará más familiarizada con, digamos, smartphone. Se podría ejecutar en su teléfono inteligente. Se podría ejecutar en su smartwatch, por ejemplo, ¿verdad? Un Raspberry Pi Pico es incluso como mucho más restringido que los entornos. Así que, por supuesto, se podría ejecutar en esas cosas. Ya no es un portátil.

David:
[50:11] Exactamente. Y esto me lleva a otro aspecto del cuarto modo, que es desde la perspectiva de los usuarios. Hoy en día, como usuario, cada vez que consumo el estado de Ethereum, tengo que hacerlo a través de un intermediario que está ejecutando un nodo completo en mi nombre. Y eso podría ser Infura, podría ser Metamask, podría ser Rabbi Wallet, lo que sea. Podría ser Etherscan. Básicamente estoy confiando en estas entidades para que me digan cuál es el estado de Ethereum. ¿Y si en lugar de eso pudiera verificar directamente la exactitud del estado de Ethereum dentro de la pestaña de mi navegador, como en mi teléfono, como dentro de la aplicación, y no cuesta nada, es instantáneo? Bueno, ahora no estoy sujeto a todos los fallos de estos intermediarios. Si, por ejemplo, Infura se cae, bueno, todavía puedo hacer transacciones. Si Infura o Metamask quieren censurar ciertos tipos de aplicaciones, quizás transacciones OFAC, bueno, ahora ya no están en posición de hacer la censura porque no están intermediando tanto. Tal vez Etherscan es hackeado y ahora alguien pone un front-end malicioso y trata de drenar a un montón de gente. Este es el tipo de cosas que deberían ser más difíciles de hacer una vez que los usuarios tengan más soberanía sobre cuál es el estado válido de la cadena.

Ryan:
[51:35] Bueno, así que esta es la razón por SNARX, que es el ZK en ZKEVMs como establecimos, logra tanto el modo bestia, ya que desbloquea un cuello de botella que ha sido la ejecución y nos lleva al potencial de algo así como una capa uno de Ethereum con 10.000 transacciones por segundo. Simultáneamente, logra el modo fortaleza, que es ¿qué es el modo fortaleza? Eso es defensa. Esto es más gente puede ejecutar nodos desde cualquier lugar en el más básico de hardware de consumo. Así que la razón por la que Snarks es tan poderoso es porque es un arma de doble filo y nos permite lograr escala y al mismo tiempo lograr no sólo mantener la descentralización actual de ejecutar un nodo Ethereum, pero como hacerlo aún mejor, haciéndolo de tal manera que se puede ejecutar un nodo Ethereum en un teléfono inteligente o un reloj.

Ryan:
[52:27] De acuerdo, pero lo que hemos hecho en este tipo de configuración ZKEVM y el tipo de nuevo cliente de ejecución del que estás hablando, y algunos de estos no están en desarrollo, hablaremos de lo que eso significa hoy. Pero lo que hemos hecho es algo importante. Así que hemos movido estos validadores de ejecutar cada transacción para verificarlos. Pero alguien está haciendo la ejecución, ¿verdad? ¿Quién está haciendo la ejecución ahora en este mundo? ¿Y por qué está bien tener...?

Ryan:
[52:55] ¿Los validadores sólo verifican en lugar de ejecutar y verificar como lo han estado haciendo? ¿Son los ejecutores ahora un vector de centralización en toda la cadena de suministro de blockchain de Ethereum?

David:
[53:07] Sí, gran pregunta. Así que tenemos un nuevo actor, que se llama el prover. Y el prover es responsable de generar las pruebas. Y hay dos regímenes que vamos a desplegar en producción. El primero es el régimen de pruebas opcionales donde confiamos en el altruismo. Confiamos en varios actores para generar las pruebas de forma gratuita para la red. Y luego confiamos en que los validadores individuales opten por verificar esas pruebas. Ahora, esta es una gran prueba de concepto, pero con el tiempo lo que queremos son pruebas obligatorias. ¿Qué significa eso? Significa que como productor de bloques, es decir, como la entidad que construye el bloque y lo propone, soy responsable de generar todas las pruebas correspondientes. Y si faltan las pruebas, entonces ese bloque no es válido. Simplemente no se incluirá en la cadena canónica. Y ahora tenemos que volver a mirar los incentivos. Ya no estamos confiando en el altruismo. En realidad nos estamos apoyando en la racionalidad. Y la razón es que el productor del bloque está recibiendo honorarios, MEV, y si se perdiera un bloque, también recibiría una penalización por perderse ese bloque.

Ryan:
[54:26] Y cuando dices productor de bloques, ¿productor de bloques y prover son sinónimos en este mundo?

David:
[54:32] No lo son, pero no necesariamente. Podrían agruparse en una sola entidad e integrarse verticalmente. Pero lo que creo que va a ocurrir es que vamos a ver una separación de intereses. Incluso hoy en día, hay una separación de intereses entre el proponente y el constructor. Y lo que espero que ocurra es que el constructor subcontrate la comprobación a comprobadores especializados.

Ryan:
[54:59] Un poco oxidado en esto, ¿de acuerdo? Prover, builder, perdón, proposer, builder, prover, validator. Bien, repasa toda la cadena de suministro de cómo un bloque entra en la cadena de Ethereum hoy en día, y luego lo que este estado futuro va a hacer en el futuro.

David:
[55:17] A parecerse. Así que hoy en día, usted tiene en cada ranura un validador muestreado al azar que se llama el proponente, y se llega a decidir qué bloque va en la cadena.

Ryan:
[55:30] Esa es la cosa. Si ejecutas un validador, lo estás ejecutando en casa.

David:
[55:33] Sí. Pero hay una advertencia importante, y es que se supone que los proponentes no son lo suficientemente sofisticados como para construir los bloques económicamente más valiosos posibles. Así que delegarán en constructores más sofisticados que lo harán en su nombre. Y eso se llama PBS, Separación Proponente-Constructor. Y tenemos algo llamado MevBoost que nos ayuda con esta separación. Lo que espero que ocurra en el futuro es que añadamos otro papel llamado prover y los constructores subcontraten los trabajos de prueba a estos sofisticados provers. Ahora, resulta que el panorama de los constructores está bastante centralizado. Así que es razonable esperar que, en la práctica, estas dos funciones se combinen en al menos un gran subconjunto de bloques.

Ryan:
[56:33] ¿Por qué está bien? ¿Por qué está bien que los constructores y potencialmente los demostradores en el futuro estén centralizados, pero nos tomamos todo este trabajo para asegurarnos de que los validadores puedan funcionar en un smartwatch?

David:
[56:46] Aquí hay algunas respuestas. La primera tiene que ver con la suposición de honestidad. Así que para que el consenso funcione sin problemas, necesitas que el 50% de los participantes en el consenso se comporten honestamente. Y este es un listón extremadamente alto. Es muy, muy difícil de lograr. Así que hoy en día, tenemos 10.000 participantes en el consenso, 10.000 operadores validadores, y tener 5.000 de ellos se comportan honestamente es una tarea difícil, pero lo hemos logrado.

Ryan:
[57:22] Por cierto, 10.000 operadores validadores, estos son operadores validadores independientes, porque algunas personas ven números como en los millones de validadores, pero estás diciendo 10.000 y no entienden por qué estás diciendo 10.000 cuando ven números como un millón de validadores en Ethereum.

David:
[57:39] Sí, déjame explicar eso. Así que durante muchos años, hubo esta restricción de que un validador lógico individual era de 32 ETH, y tenemos de hecho un millón de estas entidades de 32 ETH, lo que sucede a menudo es que hay un solo operador que controla múltiples de esos validadores. Ahora, recientemente, hemos tenido esta actualización llamada MaxEB, donde aumentamos el saldo máximo efectivo a 2000 ETH. Y así lo que estamos empezando a ver es en realidad la consolidación de los validadores. Si un solo operador controla múltiples validadores, ahora pueden aplastarlos juntos en validadores más grandes y más gordos. Y en realidad, si usted es un operador y está escuchando este podcast, le animo a consolidar porque es bueno para usted y también es bueno para la red. Pero si nos fijamos en los operadores individuales, no hay un millón, hay algo más cerca de 10.000.

Ryan:
[58:35] He visto estimaciones como 10.000, algunos dicen que hasta 15.000. Esto está en el mismo ámbito que la siguiente red más descentralizada en cripto, que es Bitcoin. He visto estimaciones para Bitcoin alrededor de 15.000 a 25.000 nodos, algo así. Y eso es lo que estamos manteniendo descentralizado. De todos modos, sólo quería aclarar ese número, pero seguir con el flujo, si se quiere, donde estabas, donde, ya sabes, supongo que la pregunta era, ¿por qué está bien que los constructores de bloques y probadores en el futuro son muy pocos, son estas entidades centralizadas?

David:
[59:08] Una razón que tiene que ver con el hecho de que es una minoría honesta en el lado probador de las cosas. Para que la cadena siga funcionando, sólo hace falta que haya un único comprobador disponible para los constructores. Y nos hemos tomado esto de N extremadamente en serio. Así que N es al menos 100 porque hay al menos 100 operadores de centros de datos entre los que puedes elegir. Pero incluso con eso no estamos satisfechos. Queremos que N sea, órdenes de magnitud más grande. Y esta es la razón por la que vamos con la prueba on-prem donde, ya sabes, los locos como yo podría ejecutar un prover desde casa. Y esto es algo que pretendo hacer.

Ryan:
[59:47] Así que eso significa que todo lo que necesitamos es Justin o algún loco como Justin y todo está bien. Nada está corrupto en la cadena. Ningún bloque inválido llega al otro lado.

David:
[1:00:01] Es un fallback para liveness. Así que lo que sucedería en el peor de los casos si dependiéramos de los centros de datos es que estaríamos funcionando a un giga gas por segundo. Y entonces, de un día para otro, los gobiernos están diciendo, hey, centros de datos, por favor, detengan el proceso de prueba. Y volveríamos a caer a algo mucho más bajo, digamos 100 megagas. Y la razón por la que volveríamos a 100 megagas es porque eso es lo máximo que se podría hacer fuera de la nube. Y eso sería muy malo en términos de proporcionar garantías al mundo porque queremos tener este rendimiento garantizado. Queremos estar arriba solamente, no queremos estar degradando la liveness de la cadena. Así que sólo queremos estar en una posición en la que lo que desplegamos en producción sea algo que podamos garantizar incluso en una situación del tipo de la Tercera Guerra Mundial, lo cual es mucho pedir. Pero es algo que la tecnología es capaz de ofrecer gracias a las recientes innovaciones.

Ryan:
[1:01:03] Que, por supuesto, esa garantía de vida es muy importante para el caso de uso de la tienda de valor, ¿verdad? incluso si el rendimiento de las transacciones cae en estos escenarios extremos. Almacenar valor sigue vivo porque puedes acceder a tu valor en cadena y hacer algo con él. Hablemos un poco más de las pruebas. Dijiste que podrías tener la capacidad de ejecutar demostradores en casa.

David:
[1:01:27] Eso está bien.

Ryan:
[1:01:28] Pero también esperas que la funcionalidad del comprobador esté más centralizada en, supongo, la mayoría de los casos. Según tengo entendido, los evaluadores tienen un perfil de hardware mucho mayor, ¿verdad? Y es algo de hardware especializado porque están haciendo algunos números o están haciendo algunas matemáticas lunares. De todos modos, estás diciendo que sí, pero no. Sí. ¿En qué me equivoco? ¿Cómo se ve esto realmente para ser un prover?

David:
[1:01:54] Sí. Es un hardware inusual en el sentido de que la mayoría de la gente no lo tendrá, pero está hecho de hardware básico, concretamente GPU de juegos. Así que 16 GPUs de juegos, por ejemplo, la 5090 que salió hace poco, es suficiente para probar todo Ethereum en tiempo real. Y tengo la intención de construir básicamente una pequeña plataforma de GPU en casa. Y un montón de entusiastas de la IA están haciendo eso porque es el mismo hardware que se necesita para la IA. Ahora, además de la liveness, que es una de las preguntas que hago mucho en torno a la descentralización de los probadores, la otra consideración muy importante es la resistencia a la censura.

David:
[1:02:37] Especialmente cuando vamos a aumentar el límite de gas. Porque la forma en que hacemos cumplir la resistencia a la censura hoy en día, suponiendo que todos los constructores y toda la tubería MEV está censurando, es confiar en una pequeña minoría altruista de validadores que están dispuestos a forzar la inclusión de transacciones desde el mempool sin pasar por los constructores. Y tenemos esta propuesta llamada Fossil, que básicamente aumenta en aproximadamente 100 veces el rendimiento total de esta inclusión forzada. Hoy en día, tenemos alrededor del 10% de los validadores que están haciendo esto de forma altruista. Pero con Fossil, tendremos 16 validadores en cada ranura. Así que es todas las ranuras en comparación con sólo el 10% de las ranuras. Y dentro de una ranura, habría 16 validadores en lugar de sólo uno. Así que en cierto sentido, es 160 veces más oportunidades para la inclusión forzada.

David:
[1:03:41] Y eso es algo que es importante hacer como requisito previo antes de crecer a límites de gas muy altos.

Ryan:
[1:03:50] Eso significa que los constructores, los probadores, ninguno de estos componentes más centralizados, lo llamaremos centralizados entre comillas, ya sabes, como entidades pueden realmente

Ryan:
[1:03:59] censurar nada en cadena. Así que preservas, y de hecho refuerzas después de Fossil, las garantías de resistencia a la censura de Ethereum. Creo que Fossil está previsto para el año que viene. Sé que todo esto es impreciso, pero fósil probablemente va a suceder antes que algunas de las otras cosas que vamos a hablar hoy. Vale, entonces ZK EVMs, tomas algo como el cliente de ejecución, algo como Geth, y hay muchos clientes de ejecución diferentes. Usted dijo que está ejecutando Geth hoy y se obtiene una versión ZK EVM de un cliente de ejecución Ethereum. Tal vez la mejor manera de encajar estas piezas donde el cliente de ejecución, ya sabes, se convierte en un verificador de la ejecución de cada bloque es hablar de su configuración en casa y lo que está planeando para DevConnect, ¿de acuerdo? Así que según tengo entendido, hay muchos clientes ZKEVM diferentes que están en desarrollo. Supongo que vas a seleccionar uno de ellos. Y luego parece que también vas a dar el paso adicional de ejecutar tus propias pruebas en casa. Así que dinos, ¿cuál es el experimento Justin Drake que va a suceder por DevConnect y luego tal vez vamos a encajar esto en la hoja de ruta más amplia. Pero, ¿qué estás haciendo?

David:
[1:05:19] Correcto. Así que el prover va a tener que esperar a Navidad. Estoy pensando en un regalo de Navidad, que es un clúster de 16 GPU. Pero a corto plazo, en noviembre para DevConnect, espero ejecutar mi validador, como has dicho, descargando ZKEVM Proves. Pero no sería una sola. En realidad sería tantos como pueda tener en mis manos. Y el número que tengo en mente es de cinco.

Ryan:
[1:05:46] ¿Cinco clientes ZKEVM?

David:
[1:05:49] Pruebas, sí. Así que hay estos cinco sistemas de prueba diferentes. Y en cada ranura, habría cinco pruebas correspondientes para cada, bueno, una prueba por cliente. Así que habría un total de cinco. Y estas son pruebas que son muy cortas y muy rápidas de verificar. Tardan, por ejemplo, 10 milisegundos en verificarse. Así que si tienes cinco de ellas, sólo toma 50 milisegundos. No es gran cosa. Así que yo descargaría todos estos. Y si tres de ellos están de acuerdo, entonces esa es mi fuente de la verdad. Y la razón por la que descargo más de una es porque algunas de ellas podrían tener errores en el sentido de que es posible elaborar una prueba para un bloque inválido. Por eso queremos que varios de ellos coincidan. Y algunos de ellos podrían tener lo que yo llamo fallos de integridad o fallos de colisión.

David:
[1:06:43] Así que hay algunas circunstancias en las que el sistema de pruebas simplemente no puede generar una prueba porque hay algún tipo de fallo en el sistema. Por eso yo no exigiría que las cinco pruebas coincidieran. No pasa nada si dos de ellas nunca aparecen, seguiría siendo capaz de seguir adelante. Así que es una nueva forma de pensar sobre la diversidad de clientes, porque hoy en día, la forma en que la diversidad de clientes funciona es que es a través de validadores. Así que usted mira a toda la población de validadores y decir, está bien, el 20% están ejecutando el cliente A, el 20% están ejecutando el cliente B, etcétera. Mientras que aquí, la diversidad es interna a un solo validador. Y eso es posible hacerlo precisamente porque tenemos SNARKs, porque es muy barato ejecutar múltiples máquinas virtuales ZKE. Y esa es una de las razones por las que creo que las ZKVM se van a imponer.

David:
[1:07:38] darnos un paso adelante en la seguridad en relación con lo que tenemos hoy. Así que la razón número uno es que tenemos diversidad de clientes internos frente a los externos a través de los validadores. En segundo lugar, la barrera de entrada para ser un validador va a ser menor, por lo que vamos a tener más descentralización, más seguridad.

David:
[1:07:57] Otro punto es que vamos a eliminar decenas de miles de líneas de código. Así que hoy, estoy ejecutando este cliente de capa de ejecución, y todo lo que realmente necesito es el núcleo del cliente, que es la implementación de EVM. Esa es la lógica, todas las cosas a su alrededor, la gestión de la mempool, la historia, y el estado, y el peer-to-peer de redes, gran parte de ese código sólo puede ser eliminado desde mi perspectiva como un operador validador. Y también hay algo llamado el motor API, que es un poco de una cosa técnica, pero es básicamente el bus de comunicación entre la capa de consenso y la capa de ejecución. Históricamente, ha habido un montón de errores en esa interfaz. Y eso va a desaparecer por completo porque, de nuevo, no estaría ejecutando un cliente de la capa de ejecución. Así que estamos llegando a este punto de minimalismo. Y, de hecho, que alimenta un poco en el meme Ethereum magra donde estamos tratando de ser lo más mínimo todo y cortar toda la grasa para que nos quedamos magra.

Ryan:
[1:09:00] Bueno, sólo para que yo entienda lo que realmente está ejecutando aquí y cómo esto encaja con algunas otras cosas que he visto dentro de Ethereum. Dijiste que estás planeando ejecutar tres sistemas de prueba diferentes, sistemas de prueba ZKEVM. Así que ahora entiendo la capa de ejecución, de nuevo, lo que queremos llegar a modo bestia como ser un cliente como Geth. Digamos que eso es lo que se está ejecutando en la actualidad. Y luego la versión ZKEVM de esto es esto como Reth, que es otro cliente Ethereum, además de uno de estos tres sistemas de prueba, ZKEVM sistemas de prueba que estoy mostrando en la pantalla. Y para aquellos que no están viendo esto, este es un sitio web llamado ethproofs.org. Y en ethproofs.org, se puede ver el progreso de los diferentes sistemas de prueba zkvm encajan esto junto a mí ¿estás ejecutando rath más uno de ellos son como tres de estos digamos sistemas de prueba o estos sistemas de prueba tipo de reemplazar rath como qué es exactamente lo que estamos hablando aquí?

David:
[1:10:03] Sí, gran pregunta. Lo que queremos hacer es preservar la diversidad de las implementaciones de EVM, también conocidas como clientes de la capa de ejecución. Queremos tener ref, pero también otras implementaciones de EVM. Y en términos de los clientes que están más preparados, tenemos uno llamado EFREX, que es un cliente Rust más reciente de la clase Lambda. Tenemos uno llamado EVM1, y tenemos uno llamado zkSyncOS, que ha sido implementado por Matterlabs. Y cada uno de estos cuatro se puede combinar con un sistema de prueba. Así que lo que podría hacer, por ejemplo, es ejecutar Zysk con EVM1. Podría ejecutar Pico con Ref. Podría ejecutar OpenVM con EFREX. Y lo que quiero es intentar tener la mayor diversidad posible, tanto en las implementaciones de AVM de la capa de ejecución como en las de ZKVM.

Ryan:
[1:11:06] Entendido. Bien, una pregunta al margen. Así que la razón por la que tenemos todos estos clientes de ejecución diferentes, y algunos de los que ni siquiera había oído hablar antes, ya sabes, geth es tal vez uno que mucha gente ha oído hablar. Reth es como una implementación Rust de Paradigm. Así que han, ya sabes, endurecido, han diseñado el infierno fuera de él. ¿Es la razón por la que tenemos todas estas implementaciones de clientes diferentes porque Ethereum tiene como una especificación endurecida? Usted sabe, como la mayoría de las otras redes no tienen como más de una implementación de cliente. Me pregunto cómo Ethereum tiene como docenas.

Justin o David:
[1:11:39] Ethereum es la única cadena que tiene una especificación, una única cadena que es como un nivel significativo de adopción que también tiene una especificación.

David:
[1:11:46] Sí, así que lo que la mayoría de las cadenas harán es que tendrán una implementación de referencia sin explicar la especificación. Y si quieres recrear un segundo cliente, tienes que mirar la implementación e intentar copiarla error por error, por así decirlo. Y es un proceso extremadamente difícil. Y, ya sabes, es parte de la razón por la que FireDancer en el ecosistema Solana aún no se ha lanzado, a pesar de que, ya sabes, hace tres, cuatro años que han estado trabajando en ello. Solana simplemente no tiene especificaciones. Y es una situación similar con Bitcoin.

David:
[1:12:20] Por lo tanto, pero, ya sabes, tener una especificación es bueno, pero no es suficiente. También necesitamos tener una cultura que fomente la diversidad y, en última instancia, reconozca el valor que conlleva. Y el valor en gran medida es el tiempo de actividad. En términos históricos, hemos tenido muchos clientes individuales que fallan y son, ya sabes, reemplazados en unas pocas horas, en unos pocos días. Y mientras están siendo reemplazados, los otros clientes actúan efectivamente como fallback. Y otra razón por la que la diversidad es importante, es porque proporciona diversidad en la capa de gobierno. Así que los desarrolladores de Oracle juegan un papel importante en las actualizaciones de Ethereum. Y el hecho de que ningún equipo cliente tenga un peso indebido es algo muy saludable. Y la última razón por la que la diversidad, en mi opinión, es extremadamente importante es porque nos permite tener muchos desarrolladores diferentes, cientos de desarrolladores, todos entendiendo simultáneamente las tripas de Ethereum. Creo que Bankless es muy famoso por su cita de que, ya sabes, lo más alcista para Ethereum es ser entendido. Y creo que cuando dice eso es, ya sabes, desde la perspectiva del usuario, del inversor, del desarrollador de aplicaciones. Pero creo que sigue siendo muy también muy cierto desde la perspectiva de los devs cliente.

Ryan:
[1:13:40] Sí, e impulsa Ethereum en este curso de cualquiera puede construir un cliente en el mundo porque pueden leer la especificación, pueden construir el cliente, tienen las habilidades de desarrollo. Y así, todos estos clientes son una especie de competencia entre sí también en términos de innovación y la adición de nuevas características. Y eso es una cosa hermosa. Bien, entonces tenemos estos, tal vez estos clientes actualizados ZK EVM listo, los clientes de ejecución, los Gets del mundo y tal, a pesar de Geth tal vez no está listo para eso, que nombrar a algunos otros. Y luego tenemos esto, ¿qué está pasando con las pruebas de ETH? Porque esto es algo separado, creo, ¿verdad? ¿O está separado? Tenemos toda una competición aquí para conseguir pruebas en tiempo real por debajo de los 12 segundos, creo.

Ryan:
[1:14:22] Entonces, ¿qué está pasando en las pruebas ETH? ¿Por qué es importante? ¿Y cómo encaja esto en tu configuración doméstica?

David:
[1:14:30] Sí. En las pruebas de ETH, la mayor parte de la atención se centra en las ZKVM. Y les permitimos que elijan su implementación EVM favorita. Y la gran mayoría de estos ZKVM utilizan ref, o EVM, porque es la más apropiada. Con una excepción, que es Airbender de ZK Sync, que utiliza ZK Sync OS, que es su propia implementación del EVM. Ahora, para la demostración, voy a descargar pruebas de EveProofs, y no voy a ser demasiado exigente con la implementación del EVM. Es sobre todo una prueba de conceptos en el lado ZKVM de las cosas. Pero en algún momento, cuando tengamos las pruebas obligatorias, necesitaremos que la comunidad FM llegue a un consenso sobre una lista canónica de ZKVM y los emparejamientos correspondientes con las implementaciones EVM. Y una de las cosas que has dicho, Ryan, es que cuando tenemos diversidad, tenemos la oportunidad de competir. Y creo que este es un aspecto muy saludable aquí, y es que lo más probable es que elijamos las cinco implementaciones de EVM más rápidas, que sean más amigables con los snark para que podamos seguir teniendo esta propiedad llamada comprobación en tiempo real.

David:
[1:15:45] Y GEF históricamente ha sido el líder. Eran literalmente un monopolio. Tenían Génesis. Era la única opción disponible. Y han tenido este reinado durante los últimos 10 años. Y creo que el hecho de que exista esta competencia es un soplo de aire fresco y debería dar lugar a muchas innovaciones.

Ryan:
[1:16:03] Esta competencia específicamente, tal vez la gente, nuestros oyentes han visto los titulares. Si usted está en cripto profundo, ya sabes, en Ethereum, es probable que tenga de algunos de estos equipos de lograr algún tipo de hito. Y creo que lo llaman como probar el EVM en menos de 12 segundos. Y esto parece ser cada vez más rápido. Creo que Sysynct fue un equipo importante para hacer esto al principio. Y son como, tenemos menos de 12 segundos. Y ahora hay otros equipos. Vi a un equipo hace un par de semanas llamado Brevis. Y ahora han alcanzado nuevos hitos aquí. ¿Qué es esta carrera para probar el EVM a cierta velocidad? ¿Y por qué es importante? Y como, ¿estamos allí todavía?

David:
[1:16:47] Sí. La razón por la que es importante es porque abre la esperanza de la frontera del giga gas. Así que literalmente está proporcionando, con toda probabilidad, billones de dólares de creación de valor para el mundo porque vamos a desbloquear el límite del gas. Y desde la perspectiva de los equipos de ZKVM, es una forma de probar esa tecnología y también tener la oportunidad de formar parte de esta lista canónica de, por ejemplo, cinco ZKVM que se incorporarían a cada validador y probador de Ethereum. Y de hecho, cada nodo verificador tendría estos cinco ZKPMs. Ahora mismo, mantengo este rastreador y lista de ZKBMs. Hay alrededor de 35 de ellos que tratan de atender a diversos casos de uso. Pero de los 35, hay una gran competencia. Y ahora los hemos reducido a unos 10 que son candidatos a ser seleccionados como canónicos para la L1.

Ryan:
[1:17:58] ¿Y por qué es importante, la velocidad por debajo de 12 segundos? ¿Y cómo está mejorando tan rápidamente?

David:
[1:18:02] Así que la forma en que Ethereum funciona es que tienes un bloque que se produce, y luego dentro del resto de la ranura, los atestadores que están votando por la punta de la cadena necesitan saber que el bloque es válido. Y así, para mantener esta propiedad de que los validadores están votando por la punta de la cadena, necesitan recibir la prueba de validez antes de que llegue el siguiente bloque. Y el siguiente bloque llega dentro de una ranura, que es de 10 segundos. En la práctica, necesitan proporcionar la prueba antes de 12 segundos. Son 12 segundos menos un pequeño delta porque está todo el tiempo de propagación de la prueba. Así que el número que tenemos en mente es en realidad 10 segundos. Ese es el objetivo. Y queremos que básicamente todos los bloques económicamente relevantes sean demostrables en 10 segundos. Así que existe la noción de "prover killer", que es un bloque construido artificialmente que tarda mucho tiempo en probarse, más de 10 segundos. Pero lo que ocurrirá con las pruebas obligatorias es que no sería racional que los constructores de bloques generaran estos "prover killers" porque se estarían disparando a sí mismos en el pie. Se estarían engañando a sí mismos porque no serían capaces de generar la prueba que llevaría a un lote perdido. Perderían los honorarios y el MEV y también serían penalizados.

Justin o David:
[1:19:28] Ya veo. Así que es un mecanismo defensivo. ¿Podemos hablar de cómo llegar del punto A al punto B? El punto A es donde estamos actualmente en Ethereum sin bloques verificados a donde queremos estar en Ethereum, donde esto es como el equilibrio dominante donde casi todos los bloques están siendo verificados. Y hemos inicializado Ethereum con éxito con esta tecnología de prueba ZK. Históricamente, como Ethereum ha hecho bifurcaciones duras, es cuando hemos hecho las grandes actualizaciones a Ethereum. Nos bifurcamos en prueba de participación. Nos bifurcamos en 4844. Todas las grandes actualizaciones de Ethereum han venido en esta función paso a paso. Al igual que nosotros sólo, hemos bifurcado la actualización.

Justin o David:
[1:20:10] Eso es, como yo lo entiendo, no es cómo esto va a suceder. Esto va a ser diferente. Tal vez usted puede hablar de cómo llegar del punto A al punto B, que es como la integración de toda la magia ZK que hemos hablado en la cadena. ¿Cómo sucede realmente?

David:
[1:20:23] Por supuesto. Así que la hoja de ruta aproximada que tengo es una hoja de ruta de cuatro pasos. La fase cero implica que un subconjunto muy pequeño de validadores, un 1%, opte por verificar pruebas generadas de forma altruista. Por ejemplo, generadas en el contexto de las pruebas ETH, que es, en gran medida, sólo el presupuesto de marketing de muchas de estas pruebas ZKVM. La desventaja de una de las desventajas de la fase cero es que yo, como validador que opte, perderé las recompensas de puntualidad. Así que hay una recompensa especial en Ethereum llamada recompensa de puntualidad, que se da a aquellos que atestiguan inmediatamente un bloque. Y yo la perderé porque atestiguaré unos segundos tarde. Así que esto nos lleva a la fase uno, en la que tenemos el delayed proving o delayed attesting, o también llamado delayed execution, en el que básicamente en vez de tener que atestiguar inmediatamente cuando llega el bloque, tienes más tiempo. Piensa en un intervalo de tiempo para atestiguar. Así que aunque tardes unos segundos en atestiguar, no pasa nada. Recibirás la recompensa de la puntualidad. Y en ese momento, espero que el número de validadores que opten por pasar de aproximadamente 1% a algo más cercano al 10%. ¿Por qué 10%?

Justin o David:
[1:21:44] Porque es cuando empieza a ser incentivado.

David:
[1:21:47] Es compatible con incentivos, exactamente. Sí. Y en realidad, ya sabes, tienes incentivos para hacerlo porque ahora no necesitas comprar un nuevo disco duro cuando el estado crece demasiado y no necesitas actualizar tu ordenador si se muere. O, ya sabes, podría vender mi MacBook que estoy usando para validar y comprar una Raspberry Pi en su lugar, por ejemplo. En cualquier caso, lo que espero que ocurra es que los validadores más débiles, los que trabajan desde casa, opten por este mecanismo. Y los validadores mucho más sofisticados, como los de Coinbase, Binance o Lido, seguirán funcionando de la forma habitual.

Ryan:
[1:22:29] Y optarían porque es una huella de hardware más baja.

David:
[1:22:32] Sí, exactamente. Y a partir de ahí, podemos empezar a aumentar el límite de gas, ¿no? Porque ahora tenemos dos tipos de nodos. Tenemos los que verifican las pruebas. Podemos aumentar el límite de gas para ellos, no hay problema. Y luego tenemos los operadores sofisticados que se ejecutan en hardware más potente que un simple ordenador portátil. Y para ellos, sólo hay un montón de búfer para aumentar el límite de gas. Así que ya en la fase uno, hay una oportunidad de ser más agresivo con el límite de gas. Y luego, en la segunda fase, es donde realmente ocurre la magia, que son las pruebas obligatorias, en las que exigimos al productor de bloques que genere las pruebas y se espera que todo el mundo funcione con ZKEVM.

Ryan:
[1:23:17] ¿Es un hard fork?

David:
[1:23:20] Sí, pero es un hard fork que sólo cambia la regla de elección del fork. Así que es un hard fork muy mínimo que dice que cuando atestigües, sólo debes atestiguar después de verificar que las pruebas existen y son válidas. Así que no es un hard fork difícil. En realidad es uno bastante simple. Y luego está la fase tres, que es la final. Pero aquí tienes que proyectarte, ya sabes, tal vez cinco años en el futuro, que es lo que llamamos pruebas consagradas, donde en lugar de tener una diversidad de cinco ZKVMs, sólo elegimos uno y lo verificamos formalmente de extremo a extremo. Así que tenemos una gran convicción de que hay literalmente cero errores en ese verificador consagrado. Y eso desbloquea todo tipo de cosas, simplifica el diseño en primer lugar, pero desbloquea cosas como validiums nativos, que es, supongo, tal vez un tema para otro día.

Justin o David:
[1:24:16] Bueno, así que cinco años, y eso es después de cinco años de sólo como pruebas de batalla de la tecnología, porque creo que más o menos esperar errores en el camino durante estas fases.

Justin o David:
[1:24:28] Y sólo tenemos que jugar whack-a-mole por un tiempo, cinco años antes de que nos sentimos que es lo suficientemente batalla probado para que sea realmente una parte formal de la capa Ethereum uno para desbloquear realmente toda la magia que los snarks nos dan.

David:
[1:24:44] Exactamente. Estamos asumiendo que cada EKVM individual está roto, pero en conjunto, como grupo, es seguro. Y esta fase dos, en la que tenemos pruebas obligatorias, puedes pensar que está semi-consagrada, en la que tenemos, en cierto sentido, una lista consagrada de múltiples ZKVM, pero no hay una en la que estemos poniendo todos los huevos en la cesta.

Justin o David:
[1:25:07] Así que la forma teórica en que esto funciona es que los nodos más débiles, los nodos más lentos, los individuos, ya sabes, verificando Ethereum a través de Starlink en su autocaravana en algún parque, parque nacional en algún lugar fuera de la red. Estas personas, los nodos más lentos de todo el grupo son los primeros en actualizarse al sistema y pasan de ser los más lentos a los más rápidos. Ellos como que se adelantan a todos. Y a medida que la tecnología se vuelve más robusta, más lista, más reforzada, más eficiente, comienza a marchar hacia arriba en la cadena del siguiente nodo más lento, el siguiente nodo más lento, hasta que estamos en una especie de nodo medio. Y entonces lo que empieza a quedar de los antiguos clientes de ejecución de legado, los nodos de Ethereum, son los nodos del centro de datos, los nodos de Coinbase, los nodos de Kraken, los nodos de Binance, la gente con infraestructura pesada, pesada con una huella muy grande que son como de la distribución de nodos de Ethereum son los que sólo pasan a estar en el centro de datos. Y son como los últimos en irse porque tienen la mayor cantidad de búfer, la mayor cantidad de ancho de banda. Y luego, en algún momento, van a cambiar también porque en realidad sólo se bifurcan en el protocolo Ethereum. todos. Ese es el plan.

David:
[1:26:20] Exactamente correcto.

Ryan:
[1:26:21] ¿Podemos hablar de esto y cómo esto encaja con la idea? Hay una entrada de blog no hace mucho tiempo de Donkrad que hablaba de la idea de un aumento de 3x para Ethereum en términos de límite de gas cada año. Y quiero mostrar tal vez una diapositiva. No sé de dónde vino esto. En realidad, esto parece obra de Justin Drake. Así que apuesto a que es de una de sus presentaciones, que tipo de va a través de esto. Y en este momento, después de, creo que hacemos dos aumentos de límite de gas para Ethereum este año, ¿o fue sólo uno?

David:
[1:26:58] Hemos hecho dos. Pasamos de 30 a 36 y de 36 a 45.

Ryan:
[1:27:02] Así es. Bien. De 36 a 45. De acuerdo. Y la idea detrás del post de Donkrat, creo, era una especie de compromiso social, hoja de ruta apilando manos para la comunidad Ethereum para intentar escalar Ethereum 3x en términos de transacciones por segundo y límite de gas cada año. De acuerdo. Y así, si estuviéramos en camino para 2025, a finales de este año, estaríamos en 100 megagas. Parece que vamos a estar tal vez dijiste 45 o tal vez lleguemos a 60 o algo así.

David:
[1:27:39] Sí, así que con Fusaka, que llegará en diciembre, podremos aumentar el límite de gas. Me han dicho que 60 es seguro y tal vez podamos llegar a un poco más, 80, tal vez 100, no lo sé, pero sí, cuando hice esas diapositivas, que fue hace unos meses.

David:
[1:27:57] Tomas estaba tratando de establecer dentro de la Fundación FIM el objetivo de llegar a un mega límite de gas a finales de este año y tratando de mantener este ritmo de 3x que Bankrat sugirió originalmente en su EIP 7938.

David:
[1:28:13] Ahora, 3x por año, creo, es una especie de punto dulce entre factible y ambicioso. Es bastante más rápido que la ley de Moore, pero no es completamente imposible. Y la propuesta de Dankrat era tener este 3x por año durante un período de cuatro años. Y lo más importante, es algo que sucedería automáticamente. Así que hoy en día, la forma en que hacemos los aumentos de límite de gas es extremadamente laborioso. Lo que necesitamos es que los operadores individuales y los clientes de la capa de consenso establezcan nuevos valores por defecto o que los operadores cambien la configuración por defecto para que suba el límite de gas. Así que es justo en la capa social, extremadamente caro y requiere mucha coordinación. Lo que Dankrat sugirió en su lugar es que en cada bloque, el límite de gas aumente un poquito, sólo uno o dos gases. Así, una vez que hayamos pasado por la coordinación social de hacerlo una vez, ocurrirá automáticamente. Y mi sugerencia concreta es aumentar de cuatro a seis años, porque después de seis años de multiplicar por tres cada año, se obtienen las 500 veces que necesitamos para llegar a un gigahercio por segundo.

Ryan:
[1:29:39] Bueno, y vamos a hablar de eso un poco más y engranar que con el tipo de idea Ethereum magra. La razón por la que hemos sido reticentes a pisar el acelerador en el límite de gas y el rendimiento ha sido que empezaría a aumentar los requisitos para los validadores y expulsaría quizás a nuestros validadores domésticos de la red y llevaría a Ethereum más a los centros de datos. Y ahí no es donde queremos estar. Ahora, supongo que el rescate o la plataforma de aterrizaje de un Ethereum esbelto es, a medida que aumentamos el límite de gas, tal vez 3 veces cada año, los nodos validadores caseros, los nodos no centro de datos en Ethereum, entonces pueden migrar a un ZK EVM y ejecutar eso en un Raspberry Pi o smartphone o hardware muy barato. Así que antes de tener una solución ZK EVM, esos validadores habrían desaparecido para siempre, básicamente. Y estaríamos más centralizados, con menos validadores, más centrados en los datos. Pero como tienen una ZKEVM, a medida que sube la marea, pueden ser de los primeros en saltar a la frontera de una ZKEVM. Así que esto ha abierto el campo de juego para permitir que Ethereum considere aumentar el límite de gas de forma más regular y tal vez hasta 3 veces cada año. ¿Es esa a grandes rasgos la historia?

David:
[1:31:08] Sí, eso es. De acuerdo.

Ryan:
[1:31:10] Y luego otra pregunta que tengo en la maleza aquí, hay límite de gas y luego hay rendimiento en estos dos lados. Lo que estamos aumentando es el límite de gas. ¿Es correcto? Y nuestro límite de gas en este momento es diferente de la mega gas que estamos haciendo en realidad. Usted dijo que estamos en dos mega gas por segundo, creo que antes en el episodio, pero luego tenemos un límite de gas de lo que, 45?

David:
[1:31:32] Sí. Así que déjame explicar las matemáticas. Hay como dos complicaciones. La primera es que tenemos 12 ranuras de segundo. Así que son 45 millones divididos por 12. Y luego hay otra complicación, que es con EAP-1559, tenemos un objetivo y un límite donde el objetivo es el doble de bajo. Así que tienes que dividir por otro 2x. Así que si tomas 45, lo divides por 12, y luego lo divides por 2, así es como obtienes tus 2 megagas por segundo. Es un poco desafortunado porque, ya sabes, en cierto sentido, el límite de gas es artificial porque depende de la duración de la ranura. Y tenemos la intención de reducir la duración de la ranura, por ejemplo, de 12 segundos a seis segundos. Así que mi modelo mental preferido es pensar en términos de gas por segundo, que se acerca bastante al concepto de TPS.

Ryan:
[1:32:27] Esas fases, cero, uno, dos, fase final, tres. Ha dicho que llegar a la tercera podría llevar cinco años. ¿Tienes una idea de la línea de tiempo? Supongo que la fase cero técnicamente comienza, ya sabes, contigo quizás entre los primeros en utilizar este hardware. En aproximadamente un mes o así el próximo mes. ¿Cuál es el calendario para el resto?

David:
[1:32:49] Sí. Así que 2025 para la fase cero y luego un año para cada otra fase. Así que fase uno, 2026, fase dos, 2027, fase tres, 2028, por ejemplo. Creo que es un calendario razonable.

Ryan:
[1:33:01] De acuerdo. Los ZKEVM nos permiten aumentar el tamaño de los bloques, nos permiten escalar el rendimiento. Las pruebas en tiempo real son algo de lo que ya hemos hablado. Estamos por debajo de los 12 segundos. Los tiempos de bloque en Ethereum son de 12 segundos en este momento. ¿Es parte del modo bestia bajar eso a seis y por debajo de seis y hasta dónde podemos empujar eso y cómo encaja eso en el tipo de zk evms básicamente tenemos que esperar hasta que los probadores zk evm sean lo suficientemente rápidos como para llevarnos con seguridad por debajo de seis segundos y luego podemos bajar el tiempo real como la producción de espacio de bloque a algo así como seis como ¿cuáles son las ventajas y desventajas de las restricciones allí?

David:
[1:33:42] Sí. Resulta que la propuesta de reducir la duración de la ranura compite en cierto modo con los ZKVM porque vamos a tener en general menos latencia para hacer las pruebas y va a dificultar las cosas. Pero sigo pensando que incluso si redujéramos la duración de la ranura a seis segundos, podríamos conseguirlo sin problemas. Solo retrasaría las cosas unos meses, tal vez seis. Así que es una decisión que debe tomar la comunidad. ¿Queremos reducir la duración de las franjas horarias a costa de retrasar las ZKBN seis meses? Supongo que está por encima de mi nivel salarial tomar esa decisión en concreto. Pero si estamos dispuestos a proyectarnos varios años en el futuro, por ejemplo, 2029, espero que podamos ir más allá de los seis segundos. En la charla sobre la cadena de vigas de hace menos de un año, intentaba anunciar cuatro segundos. Y hace poco, tuvimos este taller en Cambridge con un grupo de investigadores, y realmente se nos ocurrió una nueva idea que podría desbloquear ranuras rápidas, incluso más rápidas, potencialmente ranuras de dos segundos. Así que no quiero prometer demasiado, pero creo que vamos a ser capaces de ir...

David:
[1:35:02] por debajo de seis segundos en el contexto de consenso magra, que es un cambio de marca de la cadena de vigas.

Ryan:
[1:35:10] De acuerdo. Así que supongo que en ambos casos, si estamos aumentando los límites de gas y haciendo los bloques más grandes, haciendo que alberguen más transacciones, o si estamos disminuyendo los tiempos de ranura, todo es hacia el mismo objetivo de llegar a giga gas, ¿verdad? Ambos tipos de números aumentan nuestro giga. ¿Es eso incorrecto?

David:
[1:35:28] No, no, no. Reducir la duración de la ranura no cambia el rendimiento. Así que si redujéramos... No cambia el rendimiento. Si, por ejemplo, pasáramos de 12 segundos a 6 segundos, reduciríamos el límite de gas en 2 veces.

Ryan:
[1:35:42] Correcto, está bien. Es al revés. Sí, claro.

David:
[1:35:46] Vale.

Ryan:
[1:35:46] Sí. Por eso estas dos cosas están reñidas.

David:
[1:35:50] Quiero decir, sobre el papel, la reducción de la duración de la ranura es en realidad neutral porque en el momento de la bifurcación, la duración de la ranura se reduce en un factor de dos, el límite de gas se reduce en un factor de dos, y estos se cancelan. Pero en términos de ingeniería para obtener pruebas en tiempo real, sí, están un poco en desacuerdo porque cada segundo de tiempo de prover que tenemos es realmente muy valioso. Y esto significa que los equipos de ZKVM tendrán que trabajar mucho más duro para exprimir las cosas. A su debido tiempo.

Justin o David:
[1:36:22] Cuando esta tecnología esté completamente madura, ¿no habremos eliminado la restricción de tiempo de todos modos? Sí. Así que, digamos, más de cinco años, como ahora, estamos realmente hablando de cómo podemos integrar esto tan pronto como sea posible. Y eso es cuando como un segundo realmente importa en términos de tiempo de bloque. Pero en el futuro, un segundo no importa en absoluto, ¿verdad? ¿Puedes hablar de eso? Sí.

David:
[1:36:43] Y en el final del juego, lo que estoy imaginando es que tenemos CPUs SNOC que generan la prueba mientras están haciendo el cálculo. Así que tenemos una CPU típica que funciona, digamos, a tres gigahercios. No sólo estaría haciendo el cálculo a tres gigahercios, sino que estaría produciendo una prueba al mismo tiempo que hace el cálculo. Y se puede pensar en un núcleo de CPU, por ejemplo, el núcleo RISC-V como un milímetro cuadrado de silicio en la matriz. Así que no consume mucho espacio. Y hoy en día podemos construir fácilmente chips con, digamos, cien milímetros cuadrados de superficie. Así que puedes imaginarte que en el futuro compres tu CPU, es un chip bastante grande, 100 milímetros cuadrados. El 1% de él se utiliza para hacer el cálculo en bruto y el 99% para hacer las pruebas en tiempo real. Pero aquí no nos referimos en tiempo real con el tiempo Ethereum, que es una ranura. Nos referimos en términos de tiempo de CPU, que es como nanosegundos. Justin o David

Justin o David:
[1:37:49] Sí. Interesante.

Ryan:
[1:37:50] La única pieza de la configuración de su casa, Sólo quiero entender. Así que vas a estar en un primer momento, se está ejecutando una especie de tipo ZKEVM configuración, como hemos discutido. Ejecutar probadores en casa, está bien, ese es tu regalo de Navidad, te dan estas GPUs, ya sabes, Santa ha sido bueno contigo, has sido un buen chico, supongo, lo que sea esto. Pero se necesita algo de potencia, algo de energía para ejecutar los probadores en casa. Y según tengo entendido, algunos de los equipos están trabajando para hacer que sea más eficiente. Así que, ¿puedes hablarnos de si quisieras llegar al extremo de ejecutar tu propio prover en casa, cuál es la energía requerida? Esto es básicamente la electricidad de tu casa requerida hoy. Y luego, ¿qué se necesita para avanzar y asegurarse de que tenemos al menos un cierto nivel de descentralización de esta red prover?

David:
[1:38:44] Sí, absolutamente. Los 10 kilovatios que he mencionado son como 10 tostadoras. También es un cargador de coche eléctrico. También es como un horno eléctrico muy potente o un potente calentador de agua para la ducha. Así que esto es algo que se ha instalado y no es necesario comprar una casa nueva, supongo, con el fin de dibujar 10 kilovatios. Ahora, las GPUs de las que estamos hablando, estas GPUs de juegos, consumen unos cientos de vatios cada una, como el máximo consumo de energía nominal es algo así como 500 vatios, que es medio kilovatio. Y lo que tengo en mente en términos del tamaño del clúster son 16 GPUs. Así que 16 por 500 vatios, son 8 kilovatios. Y luego tienes que tener un buffer para las máquinas anfitrionas y la refrigeración, porque vas a necesitar ventiladores o lo que sea para hacer circular el aire, y eso también va a consumir electricidad. Así que lo que pretendo hacer para Navidad es comprar un clúster de 16 GPUs, conectarlas a mi casa y a mi conexión a Internet, y básicamente producir un bloque, una prueba para cada bloque de Ethereum en tiempo real.

David:
[1:39:57] Ahora, si me hubieras preguntado hace dos meses, ¿cuándo sería capaz de hacer esta demostración? Te habría dicho que quizá dentro de seis meses. Pero el ritmo de Snarks es tan increíble que hoy basta con 16 GPU.

David:
[1:40:13] Así que ya hemos alcanzado el requisito que nos habíamos fijado de 10 kilovatios. Y tenemos varios equipos que lo han conseguido. Has mencionado a Pico. Y ayer mismo, otro equipo, el equipo Zysk, básicamente lo consiguió. Es decir, técnicamente utilizaron 24 GPU, pero se acercan mucho a las 16. Y tenemos varios equipos más. Por ejemplo, el equipo AirBender, y espero que el equipo Succinct también llegue a las 16 GPU. Así que el 22 de noviembre, en DevConnect, veremos cuántos equipos han alcanzado este hito de las 16 GPU. Y espero que sean al menos dos, con suerte tres, y puede que cuatro. Y si quieres participar en esta demostración en tiempo real, puedes apuntarte al EveProofsDay. Así que eso es EveProofs.Day. Por desgracia, el lugar que tenemos está limitado a unos pocos cientos de personas. Y nuestra lista de espera se acerca a las 300 personas en este momento. Pero inscríbete de todas formas, porque iremos sacando más entradas.

Ryan:
[1:41:23] ¿Es que 10 kilovatios va a ser, básicamente, va a bajar? Así que una vez que reciba su regalo de Navidad, a la derecha, usted va a estar funcionando estos probadores, sus facturas de servicios públicos de electricidad se va a disparar, ¿verdad? Así que es como ejecutar un cargador de Tesla 24-7, básicamente. Así que vas a estar pagando un poco más. ¿Va a ser sólo el costo de ejecutar un prover? o podemos bajarlo de 10 tostadoras a una tostadora?

David:
[1:41:47] Sí, esa es una gran pregunta. Aquí hay dos aspectos. El primero es que a medida que mejoren los ZKVM y se necesiten cada vez menos GPU, será una oportunidad para aumentar el límite de gas. Así que lo que queremos hacer es seguir aumentando el límite de gas para estar siempre en los 10 kilovatios. Así que nos quedamos en 10 kilovatios. Y así es como llegamos a un giga de gas por segundo. La otra cosa que quiero mencionar es que, ya sabes, esta loca fase altruista no es realmente representativa de lo que sucederá eventualmente, que es que, realmente no necesitamos que los fallbacks estén probando cada bloque todo el tiempo. Sólo necesitamos que se activen cuando haya un problema. Así que si todos los proveedores de la nube de repente se desconectan, bien, ahora los constructores de bloques pueden usarme como comprobador, pero sólo me activaré en, ya sabes, uno de cada 10.000 bloques en los que sea necesario. La mayor parte del tiempo, no consumiré más electricidad que la suficiente para estar conectado a Internet. Y así se puede pensar en ello como una especie de ejército de reserva que sólo se activa cuando sea necesario.

Ryan:
[1:43:03] Me gusta esa analogía. Me gusta mucho. Antes de poner en marcha tus propios demostradores, ¿quién va a hacer las pruebas? Por cierto, en toda esta configuración, ¿se incentiva a los demostradores? ¿Reciben una parte de las recompensas por bloque? ¿Qué ganan con ello?

David:
[1:43:20] Sí. En última instancia, los demostradores están incentivados por las tasas y MEV, y van a ser pagados por los constructores de bloques. Ahora bien, una cosa que creo que vale la pena hacer con los ojos bien abiertos es que las tasas van a venir en última instancia de los usuarios. Y así, los usuarios van a tener que pagar más por sus transacciones. Y específicamente, van a tener que pagar una cuota de transacción,

David:
[1:43:45] que va a cubrir el costo de probar. Pero la buena noticia es que el coste de la prueba para una transacción típica es una centésima de céntimo. Así que para la mayoría de las aplicaciones, ni siquiera se dará cuenta de que hay una tasa adicional de prueba que se está añadiendo. Lo que espero que ocurra es que el MEV sea mucho mayor y que la tasa por disponibilidad de datos también lo sea. Y, por supuesto, a medida que mejoren los ZKVM, pasaremos de una centésima de céntimo por transacción a una milésima de céntimo. En definitiva, así es como funcionan los incentivos.

Ryan:
[1:44:26] Sólo tarifas de transacción y MEV, sin recompensas de consenso, sin recompensas de emisión.

David:
[1:44:31] Así que una cosa que podemos hacer como diseñadores de mecanismos es en lugar de apoyarnos en las recompensas, que creo que son totalmente innecesarias porque tenemos las tasas y tenemos el MEV, podemos apoyarnos en las penalizaciones. Así que podemos tener una configuración en la que si por cualquier razón no generas las pruebas y estás actuando maliciosamente, entonces te penalizan. Y el número que tengo en mente es un ETH. Así que pierdes un slot de Ethereum, boom, te penalizan con una ETH porque eso nunca debería pasar, especialmente en un contexto en el que tenemos esta mejora llamada APS, attested-proposer separation, en la que eliminamos al proponente de la ecuación y sólo tenemos entidades sofisticadas, los constructores y los probers. Y estos básicamente deberían tener un tiempo de actividad extremadamente alto. Y, ya sabes, hay una externalidad negativa en la pérdida de bloques de Ethereum, ¿verdad? Significa que en cierto sentido, Ethereum como que se salta un latido del corazón y eso no es bueno. Y así, poner un precio a la falta de una ranura, creo que es saludable. Y es algo que podemos hacer una vez que tengamos esta actualización APS. Porque hoy en día hacemos esta suposición de que un montón de validadores son, ya sabes, que se ejecutan en las conexiones a Internet en casa. y de vez en cuando mi ISP simplemente se estropea y yo no tengo Internet y no queremos ser, tener esta penalización de un ETH sólo porque estás fuera de línea y tienes mala suerte. Pero para los constructores y probadores, sí, podemos darles una bofetada con un ETH, no hay problema.

Ryan:
[1:45:59] Wow. Muy bien. Así que ese es el modo bestia para escalar Ethereum, la capa uno. Tengo que confesar, Justin, que no lo había entendido hasta esta conversación que acabamos de tener. Ahora lo entiendo mucho más. Tantas otras cosas que no tocamos y ya estamos en casi dos horas. Así que no podemos abarcarlo todo aquí. Pero muy rápidamente, cuando introdujiste el modo bestia, también dijiste que no es sólo en cinco años, ¿verdad? Esto podría suceder en cinco años, por ejemplo, y se ampliará. No es sólo Big Bang después de cinco años. Eso es algo que estamos en 10.000 transacciones por segundo. Pero este plan potencialmente nos lleva a un giga de gas, 10.000 transacciones por segundo en Ethereum capa uno para 2030. De acuerdo. También estamos escalando simultáneamente la disponibilidad de datos a través de la configuración dank sharding que tenemos ahora para que los L2 puedan llegar a teragas por segundo. ¿Tiene eso algo que ver con CKEVM y todo lo que hemos estado hablando? ¿O está sucediendo en paralelo? Y cada vez que podemos, ampliamos la vía rápida, la disponibilidad de estado y el espacio de blobs para los L2.

David:
[1:47:08] Está ocurriendo en paralelo. Pero quiero destacar una cosa que une estos dos mundos, que se llama rollups nativos. Un rollup nativo es aquel que tiene la misma ejecución que el L1, pero en L2. Y una de las grandes ventajas de los rollups nativos es que no tienes que preocuparte de los bugs en tu snark prover o en tu juego a prueba de fallos. No tienes que preocuparte por mantener la equivalencia con la L1, que es algo que evoluciona con cada bifurcación dura y cada EIP. Y tal vez lo más importante es que no tienes que tener un consejo de seguridad para hacer frente a estos errores y con este mantenimiento.

David:
[1:47:53] Y lo sorprendente de la tecnología, que es ZKVMs, es que para los L2s, podemos eliminar efectivamente el límite de gas por completo. El cuello de botella es sólo la disponibilidad de datos. Y la razón es que los L2, pueden generar pruebas para sus transacciones fuera de la cadena usando probadores muy potentes. No tienen el requisito de 10 kilovatios. Pueden tener comprobadores mucho más grandes si quieren. Y entonces lo único que traen a la cadena es esta pequeña prueba que los validadores pueden verificar. Y esa es la próxima generación de roll-ups. Y somos muy, muy afortunados de contar con Luca Dono de L2Beat, que es un gran creyente en esta idea y está defendiendo el proceso EIP y todo el trabajo técnico para desplegar esto en mainnet.

Ryan:
[1:48:53] ¿Cuándo sucederá eso en toda esta línea de tiempo en la que hablamos de, ya sabes, las fases de cero a tres de conseguir EVMs ZK ahí fuera?

David:
[1:49:00] Así que una realidad de Ethereum es que tenemos este proceso de gobierno llamado ACD y tenemos un número muy limitado de oportunidades para hacer bifurcaciones duras. Históricamente, hemos tenido un hard fork al año. Estamos tratando de duplicar esto a un hard fork cada seis meses. Pero incluso dentro de un hard fork, no hay mucho que puedas hacer. Y resulta que muchos desarrolladores diferentes quieren muchas cosas diferentes. Y así hay 10, 20, tal vez 30 propuestas diferentes compitiendo. Y en cualquier hard fork, sólo se puede despejar la cola como tres, cuatro, tal vez cinco, cinco a la vez. Y eso conduce a todo tipo de externalidades. externalidades, una de ellas es que es muy difícil predecir lo que va a pasar por el proceso de muerte de Oracle. Y otra externalidad es que sólo conduce a, mucha frustración. Puedes pensar en ACD como si fuera una especie de picadora de carne o de alma en la que hay desarrolladores entusiastas y entusiasmados que llegan y salen frustrados y hastiados porque su EIP no ha sido seleccionado durante mucho tiempo.

David:
[1:50:14] Un ejemplo podría ser Fossil, ¿verdad? Fossil es algo que tenemos el EIP, toda la investigación se ha hecho. Se ha hecho mucho trabajo de campo, y sin embargo todavía no se ha incluido. Se ha discutido su inclusión en Fusaka. Se ha debatido su inclusión en Glamsterdam, y ahora se presiona y se presiona y se presiona. Así que es difícil predecir algunas de estas cosas. Y esto es en realidad parte de la razón por la que estoy tan entusiasmado con Lean Consensus, porque Lean Consensus es una optimización de lotes de gobierno en el que durante un período prolongado de tiempo, sólo estamos haciendo pura I + D. Y así podemos tener esto realmente...

David:
[1:51:00] I+D emocionante y de ritmo rápido. Y luego lo que proponemos a ACD es algo que es significativamente mejor que lo que tenemos actualmente, digamos 10 veces mejor. Y tardará mucho tiempo en pasar por el ACD, pero cuando pase..,

David:
[1:51:17] estaremos agrupando, digamos 100 EIPs que anteriormente estarían desagregados. Y así, en lugar de tener el futuro a largo plazo, el juego final de Ethereum, si se quiere, repartido en décadas de pequeñas actualizaciones incrementales, tenemos la oportunidad de agrupar algo, actualizaciones más grandes en un plazo de cuatro años más o menos.

Ryan:
[1:51:41] Sobre todo hemos estado hablando de la capa de ejecución magra porque esa era la gran parte que no entendía. Y esa es la gran parte, ir al modo bestia y escalar la capa uno. Hemos hablado un poco sobre el consenso magra, creo, y el tipo de modo de fortaleza desde la perspectiva de todo esto se puede ejecutar desde un teléfono inteligente o un smartwatch. Pero, ¿hay otras piezas en el consenso magra? Porque esta es otra capa de la pila Ethereum que usted quiere asegurarse de que la gente entienda hoy. Porque cuando dices "lean Ethereum", estás hablando de la capa de ejecución "lean" y de escalar ese modo bestia. Y también estás hablando de lean consensus. La pieza consenso magra, creo que es tal vez menos sexy, pero tal vez en cierto modo es más importante? Y usted acaba de aludir a una de las formas en que la mayoría de nosotros los usuarios no ven por qué es importante. ¿Qué más hay en la pieza de consenso magra que no hemos cubierto? ¿Y por qué es importante?

David:
[1:52:39] Así Ethereum magra es en realidad tres iniciativas diferentes. Dentro de L1, tienes tres capas, la capa de consenso, la capa de datos y la capa de ejecución. Y es.

David:
[1:52:52] Ahora, ni siquiera hemos tocado la capa de datos aparte de decir que tiene que ser post-cuántica segura. Pero sí, hay mucho que hacer en la capa de consenso. Los titulares son, uno, reemplazar las firmas agregadas BLS con un equivalente post-cuántico. Dos, tener una finalidad mucho más rápida. Así, en lugar de tardar dos épocas, que son 64 slots, puede tardar sólo dos o tres slots. Otra gran mejora es reducir significativamente la duración de la ranura. Y luego la mejora final es al igual que ZKE VMs, podemos snarkify la totalidad de la capa de consenso para que los dispositivos realmente débiles, las pestañas del navegador, los teléfonos pueden verificar plenamente no sólo la parte de ejecución de Ethereum, sino también la capa de consenso. Y así, cuando estamos construyendo puentes, por ejemplo, entre L1s, que es el mismo tipo de tecnología que se utilizaría también. Y luego lo que usted aludió a esta oportunidad de hacer las cosas de manera diferente en términos de gobierno. Así que hemos estado haciendo las pequeñas actualizaciones incrementales. Hemos estado acumulando 10 años de deuda técnica. Es una oportunidad para refrescar y.

David:
[1:54:16] Parte de la razón por la que estoy entusiasmado con Ethereum no es porque hemos tenido 10 años de tiempo de actividad, sino porque vamos a tener otros 100 años de tiempo de actividad. Y en los próximos 100 años, vamos a aumentar nuestro valor total asegurado a cientos de billones en relación con lo que tenemos hoy, que es sólo $ 1 billón de valor total asegurado. Y creo que el proceso de desarrollo de Oracle tal como está estructurado hoy es un poco la cola que menea al perro, ¿verdad? Los 10 años de historia, esa es la cola. Hemos acumulado mucha deuda técnica y el perro son los próximos 100 años. Y creo que de lo que se trata Lean Consensus es de reequilibrarlo un poco para que los próximos 100 años donde, ya sabes, todas las finanzas se construirán en la parte superior de Ethereum, que la visión tenga la oportunidad de materializarse. Y eso va a requerir algunos grandes cambios en L1. Y así, en cierto sentido, Lean Ethereum es una invitación a ser audaces, a ser ambiciosos, y a pensar en los próximos 100 años más que en los últimos 10 años.

Ryan:
[1:55:20] Justin, ya que terminamos esto, tal vez esta es una buena oportunidad para hacer otra pregunta. Y como pienso en el contexto de toda esta discusión donde veo Ethereum va, es realmente acerca de la actualización de la red Ethereum a Snarks. Así Ethereum, como Bitcoin, se basa originalmente en la criptografía como 1.0, blockchain criptografía 1.0. Snarks es criptografía 2.0. Y ahora estamos aplicando Snarks y haciendo, creo que has utilizado los términos, que yo no entendía bien en ese momento, snarkifying toda la pila. Eso es lo que es. Eso es lo que lean Ethereum es en realidad. Es actualizar toda la pila a la criptografía 2.0, la generación snarks de la criptografía. Y algunas redes podrían seguir esos pasos, otras no. Es difícil decir lo que hará Bitcoin, pero probablemente se osificará y seguirá con la criptografía 1.0 durante mucho tiempo.

Ryan:
[1:56:15] Supongo que el contexto de esto es, ¿seremos capaces de hacer esto lo suficientemente rápido? Hablabas antes de la picadora de carne ACD y de cómo Ethereum es tan grande, con tantas piezas en movimiento, que puede resultar difícil o incluso frustrante para los desarrolladores porque se preguntan por qué no puede ser más rápido. ¿Y somos capaces de escalar lo suficientemente rápido como para vencer a los competidores centralizados, en particular los competidores con algunos equipos de ingeniería de profundidad? Y creo que parte de lo que tal vez esta pregunta está reaccionando a que teníamos uno de los autores de la escala original Ethereum EIP propuesta,

Ryan:
[1:56:51] Dankrad, recientemente abandonó el EF para, usted podría llamarlos un competidor de Ethereum, tal vez eso es simplificar las cosas. Ciertamente van a contribuir de nuevo al ecosistema Ethereum también, la forma de la EVM y otras cosas. Pero esta es una nueva empresa, recientemente recaudó $ 5 mil millones en financiación. Así que tienen bolsillos profundos. Se llama Tempo. Trabajan con Stripe y han invertido en Stripe. Así que claramente tienen acceso a TradFi y stablecoins y todas estas cosas. Y parece ser el caso de que van a ser la aplicación de algunos de esta hoja de ruta utilizando RETH. Quiero decir, es un equipo paradigmático, ¿verdad? Van a ser la velocidad de ejecución de algunos de esta hoja de ruta. Y tal vez eso ayude a Ethereum de alguna manera, pero también tal vez de alguna manera compita contra Ethereum. Y desde una perspectiva de talento, sin duda Donkrad ha hecho mucho por Ethereum, obviamente. Pero, ¿se está produciendo un sueño de cerebros con algunas de estas cadenas corporativas más centralizadas? ¿Y estás preocupado por eso? Estás hablando en términos de cientos de años, pero ¿tendremos el talento para sostenerlo? ¿Vamos lo suficientemente rápido para vencer a algunos de estos competidores y poner en práctica esta visión?

David:
[1:57:59] Sí, creo que sólo alejándonos, ha habido una fuga de cerebros. Es real, es significativa, pero en realidad no es en la dirección que uno espera. Ha habido una fuga masiva de cerebros hacia Ethereum. Y sí, hemos perdido una rata húmeda, pero creo que hemos ganado 10 ratas húmedas. Así que desde que di mi charla BeamChain hace menos de un año, ha habido docenas de personas que han llegado a bordo de la Fundación Ethereum o han estado trabajando externamente a través de todo tipo de equipos de consenso magras. Y la cantidad de talento que ha llegado en los últimos meses es absolutamente alucinante. Si nos fijamos en lo que Dankrat estaba haciendo, estaba haciendo criptografía aplicada hardcore en el contexto de Danksharding. Y ahora hay varios criptógrafos aplicados con los que trabajo diaria y semanalmente, incluidos Tomar y Emil.

David:
[1:59:08] Giacomo y Angus, Y como todas estas personas son de muy alto calibre, como al menos tan bueno como Dankrad. Al igual que ellos no tienen la reputación porque no han estado en esto durante, ya sabes, siete años. Pero en términos de talento en bruto, creo que lo tenemos. Y estas son las personas, de nuevo, que no estaban en mi radar, incluso hace unos meses. Y luego en el lado de la coordinación de las cosas, hemos traído, ya sabes, Will, que me sigue impresionando cada día. Tenemos Ladislaus, tenemos Sophia, y también hay personas que no están haciendo ni la criptografía hardcore o la coordinación. Por ejemplo, Felipe se encarga de las especificaciones, Raúl ayuda con las redes peer-to-peer, Kev se encarga de los ZKBM y Farah trabaja en las pruebas de EVE. Y cuando te alejas, muchas de estas personas... Ya sabes, vinieron a Ethereum. Así, por ejemplo, Will y Farah vinieron de Bitcoin.

David:
[2:00:13] Kev y Sophia, lo siento, no Kev, Camille, que es uno de los coordinadores de uno de los equipos de consenso y Sophia, vinieron de Polkadot. Tenemos a Kev que vino de Azteca. Tenemos Raúl, que vino de Filecoin, Tomar, que vino de Kakarot, y el ecosistema StockNet, y Angus, que vino de Polygon. Ya te haces una idea. Hay mucha más fuga de cerebros entrantes que salientes. Ahora, en términos de la razón de esta fuga de cerebros, creo que tiene que ver con las cosas que los competidores como Tempo simplemente no tienen. ¿No es así? Vitalik tiene esta famosa cita que mil millones de dólares no va a comprar un alma como blockchain. Y tenemos comunidad, tenemos visión, ideología, y también tenemos esta tecnología increíble. Y mencionaste que, ya sabes, crees que Tempo podría dar el salto y utilizar ZKVMs. No estoy conteniendo la respiración en esto. Sabes, mi suposición básica es que van a tener un número muy pequeño de validadores funcionando en centros de datos. Y de hecho, le pregunté a Ancrad, ¿cuántos validadores crees que tendrá Tempo en el lanzamiento? Y espero recordar esto correctamente, pero creo que su respuesta fue cuatro, como cuatro validadores.

David:
[2:01:41] Y, ya sabes, como la comunidad es muy diferente también. Como una cosa que fue muy dura para mí fue, ya sabes, cuando Dankrad se fue, ya sabes, hubo una efusión masiva de agradecimiento por todo el trabajo que Dankrad había hecho y su enorme contribución a Dank Shardang. Y luego nos fijamos en el lado de Stripe de las cosas y, ya sabes, es como muy triste que Patrick, ya sabes, el fundador de Stripe tipo de hizo este tweet a su medio millón de seguidores diciendo, hey, bienvenido Dankrat. Y su tweet tuvo como tres retweets.

David:
[2:02:22] No hay comunidad en Tempo. Hay muy poca alma. Y estoy seguro de que Dankrad tiene todo tipo de razones para dejar el ecosistema Ethereum. Pero el hecho es que hay una fuga masiva de cerebros hacia Ethereum. Y supongo que otra cosa que vale la pena mencionar es que creo que hay una posibilidad razonablemente alta, llámalo como un porcentaje de dos dígitos, de que tempo sea en realidad de alguna manera parte del ecosistema Ethereum, incluso si hoy no están dispuestos a reconocerlo explícitamente. En mi opinión, los incentivos serán tales que todos los L1 querrán convertirse en L2 para poder aprovechar los efectos de red que ofrece Ethereum. Ayer mismo, de hecho, o antes de ayer, Ethereum superó los 100.000 millones de dólares de Tether en L1. Y si quieres hacer pagos, necesitas tener acceso a monedas estables. Y hay muchos efectos de red alrededor de las monedas estables en Ethereum. Así que no me sorprendería que dentro de un par de años, Tempo anuncie que se está convirtiendo en L2 y Dankrat vuelva al ecosistema Ethereum.

Ryan:
[2:03:34] ¿Tienes alguna idea de por qué no ha habido más L2s? Algunas de estas cadenas corporativas, ¿por qué van con L1s en lugar de L2s? No es sólo Tempo. Si fuera sólo Tempo, quizá lo dirías, pero Circle va en esa dirección, también Plasma, algo así como la fundación de Tether. Ha habido muchos nuevos L1. Y el punto de vista de Ethereum siempre ha sido el que tú has dicho, es decir, ¿por qué ser un L1 cuando puedes ser un L2? Es más barato, mejores efectos de red. ¿Por qué no se ha confirmado todavía?

David:
[2:04:00] Sí, quiero decir, hemos visto esta prima L1. Y creo que, ya sabes, parte de la razón es que existe este nuevo espacio de diseño, que ha sido inexplorado. Y así la gente está tal vez valorando lo desconocido, como un gran potencial. No sé, esto es sólo una especulación. Creo que Tempo, como usted ha mencionado, han recaudado $ 500 millones en una valoración de $ 5 mil millones. Creo que han hecho un excelente trabajo en la agricultura de la prima L1. Y ahora que han asegurado sus 500 millones de dólares, creo que podría pivotar con seguridad a hacer lo correcto incentivo alineado cosa, que es aprovechar la máxima cantidad de efectos de red. Ciertamente recomiendo que conserven parte de su tesorería y digamos al menos un 1% para hacer un pivote de emergencia a una L2 si no tienen éxito como L1.

Ryan:
[2:04:59] Justin Drake, esto ha sido fantástico. Lean Ethereum. ¿Cuáles son los próximos pasos? DevConnect y vas a dar una presentación, creo.

Justin o David:
[2:05:08] DevDisconnect del nodo Geth.

David:
[2:05:11] Sí.

Ryan:
[2:05:12] Hablar de los próximos pasos y lo que la gente puede hacer para tipo de mantenerse al tanto y participar.

David:
[2:05:16] Sí. Espero que DevConnect sea un momento revelador en el que, como comunidad, todos estemos de acuerdo en que queremos seguir el camino de ZKVM. Hay algunos, supongo, estranguladores que todavía no están totalmente convencidos, pero creo que lo que está pasando ahora es que no estamos de acuerdo en los plazos en lugar de los fundamentos. Así que creo que los más escépticos te dirán que las ZKVM son algo para 2029 o 2030. Pero creo que lo que está sucediendo es que con el tiempo, más y más gente se está volviendo alcista en las líneas de tiempo. Y una, supongo, historia divertida aquí es que Kev, que lidera el equipo ZKABM, históricamente, al menos hace un año, era, supongo.

David:
[2:06:11] Escéptico sobre ZKABMs. Ya sabes, había un montón de preguntas abiertas en su mente. Y ha sido realmente hermoso ver su pensamiento evolucionar, ya sabes, semana a semana, ya que ha sido capaz de marcar todas las incógnitas y riesgos que había tenido en su mente. Y creo que, ya sabes, Kev es todavía como, no totalmente convencido de las líneas de tiempo exacto. Pero si la tecnología sigue avanzando en la forma en que ha progresado en los últimos 12 meses, entonces creo que los plazos sólo puede reducirse de aquí en adelante. Lo que quiero destacar es que habrá un punto de inflexión en el que la tecnología ZKVM alcanzará la paridad con el rendimiento y la calidad de L1. Y a partir de ese punto, lo que espero que ocurra es que las ZKVM dejen de ser el cuello de botella, lo que significa que la tecnología ZKVM mejorará más rápido que las 3 veces al año, que es, creo, lo más rápido que podemos esperar actualizar la L1. Y así la carga volverá a los ingenieros matemáticos tradicionales no lunares para optimizar las bases de datos y las redes y otras cosas que no sean criptografía.

Ryan:
[2:07:27] Vamos a terminar aquí. Justin Drake, muchas gracias por estar con nosotros.

David:
[2:07:31] Por supuesto. Gracias por contar conmigo.

Ryan:
[2:07:32] Bankless Nation, tengo que hacerte saber, por supuesto, crypto es arriesgado. Podrías perder lo que has invertido, pero nos dirigimos hacia el oeste, esta es la frontera, no es para todo el mundo, pero nos alegramos de que estés con nosotros en el viaje sin bancos, muchas gracias.