El futuro de las actualizaciones de Ethereum, después de la fusión [Parte 2]

La mayor actualización de Ethereum, el paso a un mecanismo de consenso de prueba de participación, está a la vuelta de la esquina. Pero si bien Merge debería agregar seguridad y sostenibilidad, no incluye fragmentación, el método largamente esperado para escalar la red. 

In Parte I de nuestra conversación con el investigador de la Fundación Ethereum (EF) Danny Ryan, quien ayudó a coordinar el proceso de actualización, discutimos lo que Merge está diseñado para brindar en términos de seguridad y estabilidad.

En la Parte II, Ryan habla sobre las actualizaciones que los usuarios pueden esperar en el futuro, incluido el danksharding, el Ethereum sin estado y las actualizaciones de seguridad que se enfrentan al aumento del valor extraíble de los mineros (MEV). También explica cómo este esfuerzo de años dio como resultado nuevos métodos para investigar y probar futuras actualizaciones.

---

Coordinación en una red descentralizada

FUTURO: Usted aludió a la posibilidad de que los mineros se bifurquen y continúen tratando de usar la cadena anterior. Pero en su mayor parte, este proceso ha hecho que todos participen. ¿Cuál es su papel en eso como investigador de la Fundación Ethereum? ¿Cómo se coordina un movimiento tan masivo?

DANNY RIAN: Empecé a involucrarme en cosas de prueba de participación alrededor de 2017, e incluso entonces parecía una conclusión inevitable. Eso fue hace cinco años. Y la comunidad de Ethereum ha estado muy dispuesta a no estancarse y hacerlo bien, y construir un protocolo que no solo funcione hoy sino que funcione, con suerte, durante 100 años o más. 

Por lo tanto, al principio de su ethos, cuando existía la corazonada de que la prueba de participación se podía hacer de manera segura y mejor que la prueba de trabajo, la gente estaba muy entusiasmada con eso. Y para cuando llegue el 2016, 2017, la gente no solo estará emocionada, sino que también ansioso para que suceda. Parece que está muy arraigado en el espíritu de la comunidad de Ethereum que esto vaya a suceder.

Hay temas más sensibles. Hay conclusiones menos obvias donde EF, el equipo de investigación y los clientes que están fuera de EF están tratando de encontrar soluciones a los problemas y mantener las cosas en movimiento. A veces, las soluciones se encuentran en una zona un poco más gris: ¿es esta la solución correcta? ¿Lo hacemos ahora? ¿Lo hacemos más tarde? Eso termina siendo difícil, y EF intenta ayudar a coordinar esos métodos, ayudar a hacer algo de I + D para ayudar a examinar soluciones, ayudar a facilitar las conversaciones para decidir sobre los plazos, las prioridades y los pedidos. 

Pero al final del día, en la mayoría de los elementos, la agenda de EF es ayudar a que el protocolo sea más sostenible, seguro y escalable mientras se descentraliza, y no enviar una característica particular sobre la otra. Entonces, mucho de lo que nos enfocamos cuando se trata tanto del trabajo técnico como de la coordinación social es facilitar buena información, buena investigación y buen diálogo para que los muchos participantes involucrados en I+D, la ingeniería y la comunidad puedan seguir las cosas se mueven y llegan a decisiones.

En los últimos cinco años, se han agregado muchas más voces a la comunidad y, después de la fusión, teóricamente se volverá más descentralizada. ¿Qué piensa sobre el futuro proceso de actualización? ¿Es posible que busquemos algún tipo de DAO de capa uno para coordinar las actualizaciones?

Según tengo entendido, la comunidad de Ethereum no está interesada en la votación en cadena, ni en ningún tipo de votación y actualización plutocrática, y ese protocolo es el que los usuarios deciden ejecutar. En general, hay un amplio consenso. A veces hay divisiones, por ejemplo, Ethereum vs. Ethereum clásico. Pero al final del día es su derecho y el derecho de la comunidad y los derechos de los usuarios averiguar qué software quieren ejecutar. En general, estamos de acuerdo porque la gente está tratando de mejorar Ethereum, y no hay mucho conflicto en algunas de las cosas principales allí. 

Así que no espero un mecanismo técnico formal. Espero que el proceso continúe creciendo, cambiando y evolucionando en este tipo de gobierno flexible, donde hay investigadores, hay desarrolladores, hay miembros de la comunidad, hay dapps y cosas así. 

Diría que, y creo que usted se refirió a eso, hay más y más personas en la mesa, y cada vez es más difícil tomar decisiones y enviar cosas. Personalmente creo que esa es una característica. Creo que tanto desde el punto de vista de la confiabilidad para las aplicaciones y los usuarios, como para evitar la captura a largo plazo, probablemente sea importante que gran parte del protocolo Ethereum se osifique. Entonces, aunque es cada vez más difícil estar en la vorágine de la gobernabilidad y tratar de enviar, y a veces se siente como si estuviera tratando de correr con un chaleco con peso y pesas en los tobillos y ahora tengo pesas en las muñecas, yo Creo que tenemos algunas cosas clave que hacer en los próximos años. Pero creo que va a ser cada vez más difícil hacer las cosas. Y creo que eso es algo bueno.

Vitalik lo llama “velocidad de escape funcional.” Llevemos a Ethereum a un lugar donde tenga suficiente escala y funcionalidad para que pueda extenderse y utilizarse en una multitud infinita de formas en la siguiente capa de la pila. Haga que el EVM tenga una funcionalidad mínima suficiente, que haya suficiente disponibilidad de datos para manejar cantidades masivas de escala, y luego las aplicaciones pueden extenderlo en contratos inteligentes. La capa dos puede experimentar con nuevas máquinas virtuales dentro de sus construcciones de capa dos; puedes escalar Ethereum y así sucesivamente.

Creo que va a ser cada vez más difícil hacer las cosas. Y creo que eso es algo bueno.

Horquillas de sombra

Una de las cosas que surgieron de este proceso de prueba específico fueron las bifurcaciones de sombra, el proceso de copiar datos reales de Ethereum a una red de prueba para simular un entorno de prueba de red principal. ¿Eso siempre estuvo en el plan? ¿Y cómo cree que eso podría cambiar el proceso de I+D para futuras actualizaciones?

Deberíamos haber estado haciendo shadow forks durante los últimos cuatro años. Son grandiosos; son realmente geniales Básicamente, tomo una cantidad de nodos que controlamos, llámelos como 10, 20, 30, y piensan que se acerca una bifurcación, por lo que están en la red principal o en una de estas redes de prueba y luego en alguna condición de bifurcación, como la altura del bloque, ellos todos dicen: "Está bien, estamos en la nueva red". Y se bifurcan y luego pasan el rato en su propia realidad, pero tienen el estado del tamaño de la red principal.

Y durante un tiempo, puede canalizar transacciones desde la red principal a esta realidad bifurcada para obtener una cantidad razonable de lo que parece actividad orgánica del usuario, lo cual es realmente bueno. Nos permite probar lo que terminaron siendo procesos altamente orgánicos que son difíciles de simular. Y eso ha sido genial. Igual [Jayanthi] y otros que trabajan en el equipo de DevOps en EF han estado orquestando esto y aprendimos mucho de ellos. Creo que si le preguntas a alguien, diría: "Bueno, sí, hubiera sido genial si estuviéramos haciendo esto hace tres años, hace cuatro años en cada actualización".

Pero diré otra cosa. Lo he estado diciendo [desde] hace un año y ahora estamos en la cola larga en seguridad y pruebas: realmente está golpeando esto, asegurándose de que todos los casos extremos sean correctos, asegurándose de que cuando llegue, suceda — le damos una oportunidad y funciona. Y resulta que, por la forma en que el software está construido con clientes de capa de ejecución de consenso, hay mucho que construir en términos de pruebas. Horquillas de sombra es uno de ellos. Utilizando otros entornos de simulación que pueden probar estas dos cosas juntas, como Kurtosis, Antítesis, Y otros. 

Hay algunas otras cosas que tenemos que hacer, como volver a cablear Colmena, que es nuestro marco de prueba de compilación nocturna de integración, para que pueda manejar estos dos tipos de clientes y para que pueda escribir pruebas en las que ocurren diferentes complejidades en ambos lados del pasillo. Todo eso tenía que pasar. Primero, los marcos tenían que ser desarrollados o modificados. Luego hubo que escribir muchas de las pruebas. Entonces, lo bueno de Merge es que realmente hemos mejorado las herramientas en nuestro cinturón de herramientas para poder probar las actualizaciones de tal manera que la próxima actualización consistirá mucho más en escribir las pruebas en lugar de pensar en cómo probarlo y escribir los marcos para probarlo. 

¿Qué hay después de la prueba de participación?

Dado que esto ha estado sucediendo durante mucho tiempo, inicialmente la fragmentación iba a ser lo primero. Pero los desarrollos del ecosistema significaron que primero podía pasar a la prueba de participación. ¿Hubo otros desarrollos del ecosistema que surgieron durante este proceso que podrían cambiar su enfoque hacia futuras actualizaciones?

En primer lugar, probablemente haya una serie de razones por las que se priorizó el cambio de prueba de participación. Una era dejar de pagar de más por la seguridad con prueba de trabajo. Y la otra era que la escala comenzaba a llegar a través de estas construcciones de capa dos. Entonces, tal vez si tiene una escala de 10-100x proveniente de eso, puede concentrarse en esta otra cosa y terminar el trabajo y unificar estos dos sistemas dispares: la cadena de balizas y la red principal actual. 

Hay algunas otras cosas que han afectado la forma en que pensamos acerca de los plazos y las prioridades. Mencioné anteriormente que todo el mundo de los MEV ha dado un vuelco a algunas cosas. Hay centralización y otras preocupaciones de seguridad que surgen cuando comienza a pensar en dónde podría ir MEV. Y ha habido mucha investigación durante los últimos 12 meses sobre cómo mitigar algunas de estas preocupaciones con modificaciones de capa uno. Según el análisis de las amenazas provenientes del mundo MEV, eso podría priorizar ciertas características de seguridad y adiciones de seguridad a L1 sobre otra cosa que tal vez se esperaba que fuera la prioridad. 

Creo que algo que es interesante es la hoja de ruta de fragmentación y la construcción esperada actual, que se llama danksharding, el nombre de Dankrad [Feist], nuestro investigador de la EF. Toda la construcción en realidad se simplifica cuando se supone que existen estos actores MEV altamente incentivados. Algunos de estos actores externos no solo han alterado la forma en que pensamos sobre la seguridad, sino que también alteran la forma en que podemos pensar sobre la construcción de estos protocolos. Si asume que MEV existe, si asume que estos actores altamente incentivados están dispuestos a hacer ciertas cosas debido a MEV, entonces, de repente, tiene a este tercero participante en el consenso al que tal vez puede descargar cosas, que en muchos sentidos se puede simplificar. Entonces, no solo surgen cosas malas, sino que también se abren nuevos tipos de diseños.

Realmente hemos mejorado las herramientas en nuestro cinturón de herramientas para poder probar las actualizaciones de tal manera que la próxima actualización consistirá mucho más en escribir las pruebas en lugar de pensar en cómo probarlas.

¿Se sigue discutiendo e investigando activamente el Ethereum apátrida? 

Sí. El estado, todas las cuentas, contratos, saldos y demás, ese es el estado de Ethereum. Dado dónde se encuentra en la cadena de bloques, hay un estado de realidad. Esa cosa crece con el tiempo, crece linealmente. Y si aumenta el límite de gas, crece aún más rápido. Así que esto es una preocupación. Si crece más rápido que la memoria y el espacio en el disco duro de las máquinas de consumo, entonces tiene problemas para poder ejecutar nodos en computadoras domésticas y hardware de consumo, lo que tiene problemas de seguridad y centralización. Además, si hablas con algunos de los OBTENER miembros del equipo [cliente], el hecho de que el estado siga creciendo significa que tienen que seguir optimizando las cosas. Así que es difícil.

Ethereum sin estado y cosas en esa dirección de investigación son una solución potencial para esto, donde para ejecutar un bloque en realidad no necesito todo el estado; hay una especie de entrada oculta al ejecutar la función de un bloque. Necesito el estado previo, necesito el bloque y luego obtengo el estado posterior para saber si el bloque es válido. Mientras que con Ethereum sin estado, los requisitos del estado (las cuentas y otras cosas que necesita para ejecutar ese bloque en particular) están integrados en el bloque y son pruebas de que ese es el estado correcto. Ahora, ejecutar un bloque y verificar la validez de Ethereum se convierte simplemente en [tener] que tener el bloque, lo cual es realmente bueno. Ahora podemos tener nodos completos que no necesariamente tienen estado completo. Abre todo un espectro de cómo construir nodos. Así que podría tener un nodo que valide completamente y no tenga el estado, podría tener un nodo que solo mantenga el estado relevante para mí, o podría tener nodos muy completos que tengan todo el estado y ese tipo de cosas.

Esto se está trabajando activamente. De hecho, creo que actualmente hay una red de prueba con todas las otras cosas divertidas que deben suceder para que esto suceda. Mi evaluación actual es que la demanda de fragmentación y escala L1 es mayor que la amenaza inminente del crecimiento estatal. Así que es muy probable que, dado que se priorizará uno sobre el otro, se priorizará la escala. 

Dicho esto, es difícil de decir. Hay "proto-darksharding”, que es como una forma paso a paso de obtener un poco más de escala. Tal vez eso suceda y luego ocurra el estado sin estado y luego la fragmentación completa, según las necesidades y la evaluación de lo que está sucediendo y las amenazas involucradas. Creo que el pensamiento general sobre el crecimiento del estado es que debemos tener un camino y debemos arreglarlo, pero [que] los incendios inminentes se han apagado y que esto no es algo que paralizará a Ethereum en los próximos dos años. Pero es algo que hay que arreglar.

Guíeme a través de las actualizaciones que do saber para después de la fusión. ¿Habrá una actualización de limpieza? ¿Está eso separado de la actualización de Shanghái? ¿Y cuándo se introduce la fragmentación?

Es probable que Shanghái sea el nombre de la bifurcación después de la Fusión. Para retirar realmente los fondos que ha estado apostando durante casi dos años, [eso] no se habilita en la fusión. Inicialmente, se esperaba que se hicieran, pero dada la complejidad de la fusión, con el tiempo, se decidió realmente reducirlo y simplemente realizar la fusión y no agregar la funcionalidad adicional de los retiros. Esperaría mucho, mucho, mucho que los retiros estén habilitados en Shanghái, por lo tanto, la primera actualización después de la fusión. Esto se ha prometido a muchas, muchas personas que tienen mucho capital en juego y no espero ningún problema con eso. Estos generalmente se especifican, hay pruebas escritas y ese tipo de cosas. 

Hay una serie de otras mejoras de EVM [Ethereum Virtual Machine] que creo que se incluirían en este sistema: diferentes operaciones matemáticas, algunas cosas de extensibilidad diferentes, un control de versiones un poco mejor dentro de EVM y otras características. Es un poco una válvula de liberación de presión en las mejoras de EVM, que se han dejado de lado durante varios años para realizar la fusión y otras actualizaciones. Y la gente realmente quiere ver algún tipo de mejora de escalabilidad menor aquí. Por lo tanto, podría ser proto-danksharding, que sienta algunas de las bases para la fragmentación completa y obtiene un poco más de escala, o potencialmente reducciones en el precio del gas de calldata, que son muy fáciles pero no son realmente una solución sostenible. Eso es lo que esperamos, con suerte, en Shanghái: retiros y un poco de escala.

Entonces la pregunta es: ¿Qué hay después de eso? Y eso es difícil de decir. Si conseguimos un poco de escala allí, y se complementa muy bien con las L2 y las cosas van bastante bien, entonces tal vez haya una demanda para hacer sin estado en ese punto. O si los L2 tienen una necesidad insaciable de más escala, entonces tal vez eso prepare el escenario para el danksharding completo.

Esta entrevista ha sido editada y condensada. 

Publicado julio 27, 2022