Actualización de la reunión de desarrolladores principales de Ethereum: actualización de Berlín, actualización de Londres, actualización de Shanghái

Bienvenido al primer artículo de resumen de la serie AllCoreDevs.

Esta serie de artículos tiene como objetivo resumir el progreso del desarrollo del protocolo central, para que la comunidad Ethereum pueda comprender y digerir mejor. Se puede decir que la serie "AllCoreDevs Updates" es una pieza complementaria de "Core Devs Meeting Videos & Transcripts" y mi Twitter Wrap Up.

Espero que mi resumen pueda compartir los problemas que los desarrolladores principales están discutiendo con la comunidad de Ethereum en general, para que más personas puedan entender lo que está sucediendo en la comunidad de Ethereum, dar su opinión al respecto e incluso contribuir con sus propias soluciones.

La bifurcación dura de Berlín está disponible en testnet: ¡es hora de comenzar el desarrollo de aplicaciones y billeteras en testnet!

Bifurcación dura de Londres en preparación: la implementación de EIP-1559 está en marcha y el alcance de la actualización es limitado para cumplir con la fecha límite de julio o agosto.

El enfoque de actualización de la bifurcación dura de Shanghái aún se está discutiendo: los desarrolladores centrales centrarán sus esfuerzos en la fusión eth1->eth2, o cuando se prototipee la fusión, implementarán los EIP que sean más populares.

El contenido de la actualización de Berlín se ha implementado en todas las principales redes de prueba y se lanzará en la red principal el 14 de abril, a una altura de bloque de 12 244 000. Esta actualización mejorará la seguridad de Ethereum y lo preparará para el despliegue de EIP-1559 en la actualización de Londres. Si el lector está ejecutando un nodo y aún no ha actualizado la versión del cliente, ¡hágalo lo antes posible! En cuanto a la versión actualizada del cliente, se anuncia en el "Anuncio de actualización de Ethereum Berlín".

Por el lado de la seguridad, las tarifas de gas para los códigos de operación que acceden al estado de Ethereum son prohibitivamente bajas en comparación con su costo computacional, y EIP-2929 puede resolver este problema. Aprovechando los bajos costos de gas de los códigos de operación, los actores malintencionados pueden crear bloques que llaman repetidamente a estos códigos de operación, que son mucho más lentos de procesar que los bloques normales. EIP-2929 alivia esto proporcionando ~3 veces el costo del gas. En el lado del cliente, se ha mejorado la gestión de la base de datos. Por ejemplo, el formato de la base de datos de instantáneas del cliente Geth también ayuda a manejar de manera más eficiente los bloques con acceso de alto estado.

BTC superó brevemente los $ 12 450, estableciendo un nuevo máximo para el año: según los datos de Huobi Global, BTC siguió aumentando, superando los $ 12 450 por un corto tiempo, estableciendo un nuevo máximo para el año. Ahora está en $ 12 440, un intradía aumento del 4,35%. [2020/10/21]

Sin embargo, para aliviar el impacto negativo de EIP-2929 en los usuarios, Berlin Upgrade introdujo el EIP-2930 correspondiente. Permite a los usuarios especificar una "lista de acceso" al enviar una transacción para usar tarifas de gas inferiores a las especificadas en 2929. El cálculo de la tarifa de gas es un poco complicado, pero, a un nivel alto, si los clientes saben de antemano qué parte del estado involucrará una transacción, pueden precargar y cobrar menos gas por esos accesos. Animo a todos a consultar este EIP para obtener cálculos precisos.

Para los desarrolladores de aplicaciones y billeteras que quieran experimentar la función de generar "listas de acceso", el cliente Geth pronto lanzará herramientas relacionadas. Puede hacer clic aquí para ver el proceso de desarrollo:

https://github.com/ethereum/go-ethereum/pull/22550. En términos más generales, si es un desarrollador de aplicaciones o billeteras, ¡ahora es el momento de probar el contenido de la actualización de Berlín en la red de prueba!

Con respecto a EIP-1559, Berlín está ayudando de dos maneras. Primero, EIP-2929 aborda el mayor riesgo de EIP-1559: los ataques DoS en bloques dos veces más grandes que los actuales. Esta fue la primera razón por la que los desarrolladores de clientes se opusieron a EIP-1559, y se discute cada vez que se habla de 1559 en las reuniones de desarrollo central. En otras palabras, no podemos lanzar con seguridad 1559 sin 2929.

En segundo lugar, Berlín introdujo soporte para múltiples tipos de transacciones a nivel de protocolo a través de EIP-2718. La funcionalidad de creación de "lista de acceso" introducida en EIP-2930 requería un nuevo tipo de transacción, por lo que EIP-2718 proporciona un marco integral para admitir múltiples tipos de transacciones. Esto significa que la implementación de 2718 y 2930 en Berlín permite que el equipo del cliente haga el trabajo preliminar arquitectónico con anticipación, listo para admitir transacciones de tipo 1559.

Finalmente, todos tienen otra preocupación sobre la actualización de Berlín, preocupada de que EIP-2929 aumente el costo de las transacciones de DeFi. Sin embargo, la introducción de EIP-2930 compensará algunos (no todos). La solución obvia para evitar este tipo de aumento de la tarifa de gas de transacción es aumentar el límite de gas del bloque.

Sin embargo, siempre hay ventajas y desventajas al hacerlo: aumentar el tamaño del bloque acelera el crecimiento del estado, lo que dificulta que los nodos se sincronicen con la red. Por otro lado, no aumentar el límite de gas del bloque aumentará el costo de transacción (pagar costosas tarifas de gas) para los usuarios de la red. Quizás este sea un compromiso más justo: introducir 2929 para reducir el riesgo de DoS, y luego aumentar lentamente el tamaño del bloque hasta que el aumento de la tarifa de gas de 2929 se compense gradualmente.

Con la bifurcación dura de Berlín en camino a la red principal, los desarrolladores centrales ahora se están enfocando en la próxima actualización de la red: Londres. Esta actualización es un poco especial, ya que la bomba de dificultad ocurrirá en agosto, por lo que la actualización de Londres debe implementarse antes de esa fecha. Es decir, el desarrollo y la actualización de la próxima actualización (Londres) comenzarán antes de que se implemente la actualización anterior. Esta es la primera vez que los desarrolladores principales se encuentran con una situación así.

La actualización de Londres implementará el tan esperado EIP-1559 en la red principal. Si el lector es nuevo en el EIP, elaboré una lista de recursos y documenté el proceso de desarrollo durante el año pasado.

(Nota del traductor: ECN archivó la traducción de la actualización de 1559)

Este EIP solo ha cambiado Ethereum más que todas las actualizaciones de EIP en Berlín combinadas. Y el tiempo de implementación y prueba es más corto que las actualizaciones anteriores, por lo que los desarrolladores principales están tratando de reducir el alcance de la actualización de Londres para que pueda completarse a tiempo. Hasta ahora, la actualización de Londres solo ha incluido EIP-1559 y EIP-3238 (propone retrasar la bomba de dificultad hasta el segundo trimestre de 2022). Una vez finalizada la implementación y las pruebas de 1559, los desarrolladores principales estarán en una posición más activa y luego decidirán qué EIP agregar.

Dado que el alcance de la mejora de Londres se ha reducido deliberadamente, los principales desarrolladores han comenzado una planificación de alto nivel para la mejora de Shanghái. Tenemos las siguientes dos posibilidades principales:

Primero, podemos implementar EIP que son imposibles de implementar en Londres, como:

EIP-3074: Permitir "transacciones financiadas" y más

EIP-2537: agregar compatibilidad con la curva BLS-12381 (utilizada por Beacon Chain)

EIP-2327: Bueno para equipos de Solidez y Optimismo

EIP-2935: útil para clientes ligeros y clientes sin estado

Alternativamente, la comunidad se está enfocando cada vez más en la fusión entre las capas de consenso (eth2) y aplicación (eth1), en pocas palabras, Merge™️. El repositorio de especificaciones de eth2 ya tiene un PR para la propuesta de "especificaciones de fusión simplificadas", y es bastante similar a lo que el equipo del cliente debería poder crear.

Si bien la especificación fusionada puede ser relativamente simple, todavía hay varios problemas de ingeniería que deben resolverse para que los clientes de la capa de aplicación utilicen la cadena de balizas como su motor de consenso. Llamar la atención de los desarrolladores de clientes en ambos lados sobre estos problemas es cómo los encontramos y los solucionamos.

El equipo del cliente aún necesita manejar mejor la digestión de las especificaciones y comenzar a construir prototipos antes de que puedan decidir si estamos listos para convertir toda nuestra energía en el esfuerzo de fusión, o si se necesita un pequeño grupo de trabajo antes de que todos se involucren. más trabajo hecho. Para acelerar este proceso, los clientes de las capas de aplicación y consenso desarrollarán prototipos de las últimas especificaciones durante el Scaling Ethereum Hackathon.

El final del Scaling Ethereum Hackathon coincide con la finalización de la mayor parte del trabajo en Londres y la actualización de Altair (que tendrá lugar en junio). Esto significa que el prototipo debería estar listo a tiempo para que tomemos una decisión sobre la actualización de Shanghái. ?

¡Lo anterior es el contenido actualizado de este problema! La próxima reunión de AllCoreDevs se llevará a cabo el viernes 2 de abril a las 22:00 hora de Beijing. ¡Hasta la próxima!

Enlace original:

https://hackmd.io/@timbeiko/acd/https%3A%2F%2Fhackmd.io%2F%40timbeiko%2FH1US36qzO

Fuente | Actualización de AllCoreDevs

Autor | Tim Beiko

Tags：

MATIC