Ethereum está analizando el rendimiento de EIP-1559 en redes grandes

Resumen

Ahora tenemos un análisis económico detallado de EIP-1559

Estamos construyendo una red de prueba con capacidad a nivel de red principal para analizar el rendimiento de 1559 en una red grande

Hemos progresado en abordar los problemas del conjunto de transacciones causados ​​por el cambio de la TARIFA BASE

Contamos con nuevas simulaciones para analizar el comportamiento de transacciones heredadas así como transacciones estilo 1559 en una sola red

OpenEthereum está contratando un ingeniero de tiempo completo enfocado en 1559

Análisis Económico

En diciembre de 2020, Tim Roughgarden, un investigador líder en teoría de juegos y ciencias de la computación, publicó un análisis económico de más de 50 páginas de EIP-1559. Escribió la esencia del informe en un tuit y en la primera parte del informe, pero vale la pena compartirlo aquí completo:

Anotación: Para ver la traducción del resumen de diez puntos anterior, consulte "Ethereum Seven-Day Talk • 2020/12/7".

En el pasado, los críticos de 1559 mencionaron a menudo que carece de un análisis económico formal, argumentando que 1559 se basa en la intuición sobre el mercado de tarifas de transacción de Ethereum. Este informe proporciona un análisis exhaustivo y generalmente positivo de EIP-1559. ¡¿Incluso parece haber convencido a algunos famosos escépticos de 1559 como Nick Johnson?!

Este informe destaca algunos aspectos de 1559 que merecen una mayor consideración, a saber, la posible colusión de los mineros y un mejor análisis de las reglas de actualización de la tarifa base. La séptima reunión de implementadores de EIP-1559 discutió el escenario de colusión de mineros, pero no se sacaron conclusiones definitivas. Y sobre la regla de actualización de la tarifa base, lancé una llamada de Twitter para expertos en el tema, y ​​algunas personas se han acercado a mí para ayudar.

Roughgarden también mencionó que espera que la comunidad de Ethereum aproveche al máximo el informe y que cualquier persona pueda comunicarse con él si tiene preguntas, comentarios o inquietudes. Su sitio web enumera sus diversos datos de contacto.

Gran red de prueba estatal

Como se discutió en la actualización anterior, el próximo hito de la prueba de EIP-1559 será la prueba en condiciones similares a las de la red principal. El primer método considerado es bifurcar una red desde la red principal, reducir la dificultad e iniciar EIP-1559 en ella. Aunque esto nos daría una copia del estado de la red principal, la idea fue rechazada por motivos de seguridad.

En cambio, el equipo de Besu ha estado construyendo un gran generador de redes de prueba estatales. El generador toma una gran cantidad de cuentas y ranuras de almacenamiento como entrada, inicia un contrato inteligente llamado "ballena", le pide que envíe una pequeña cantidad de ETH y crea una ranura de almacenamiento para cada entrada. Hay una demostración completa en la 7.ª reunión de implementadores de EIP-1559, a partir de la 1:16:00. Aquí hay una captura de pantalla de la herramienta en acción.

La red principal ahora tiene alrededor de 100 millones de cuentas, por lo que la última vez que ejecutamos la herramienta, creamos una red con 100 millones de cuentas y ranuras de almacenamiento. Este proceso tarda unos 4 días y la capacidad de la base de datos necesaria es de unos 240 GB. A medida que crece la capacidad de la red, el tiempo para crear una red aumenta casi exponencialmente, una red de capacidad de 100k tarda el doble que una red de capacidad de 10k, y una red de capacidad de 1M tarda 10 veces más que una red de capacidad de 100k. El tiempo necesario para ¡una red de 10 M de capacidad es 15 veces más larga que una red de 1 M de capacidad, y el tiempo requerido para una red de 100 M de capacidad es 40 veces más largo que el de una red de 10 M de capacidad!

Ahora que tenemos esta base de datos, intentaremos sincronizar todas las implementaciones de clientes con esta red y luego bombardearemos la red con la herramienta de generación de transacciones que construimos anteriormente. De esta manera, podemos obtener información sobre cómo los clientes pueden manejar bloques completos al 200 % sin problemas bajo la regla 1559 cuando tienen que administrar el estado de la capacidad a nivel de la red principal.

Grupo de negociación

En la actualización anterior, discutimos algunos problemas importantes relacionados con la administración del conjunto de transacciones, que aún deben resolverse. Los expliqué en un documento, pero la esencia es que debido a que la TARIFA BASE entre bloques es diferente, y la transacción especificará la tarifa máxima (FEE CAP) y la propina del minero (TIP) que están dispuestos a pagar, un minero empaqueta La tarifa recibida por la transacción cambiará con el cambio de la TARIFA BASE, lo que significa que los nodos son potencialmente necesarios para reorganizar el grupo de transacciones de cada bloque, lo cual es muy ineficiente.

Ansgar del equipo de Quilt ha estado prestando atención a este problema y compartió un artículo sobre este tema en la séptima reunión de implementadores.

En resumen, hay dos problemas que deben resolverse: los mineros quieren que las transacciones incluidas en el bloque les paguen la tarifa más alta; los nodos no mineros deben tener una política de desalojo de transacciones cuando su grupo de transacciones está lleno.

Aunque el documento no propone una solución a este problema, destaca una característica interesante de las transacciones para los mineros: las recompensas cambiantes. Bajo 1559, puede imaginar una transacción que tenga dos "estados" posibles. El primer estado es "constante", es decir, la TARIFA MÁXIMA de la transacción es mayor que la suma de la TARIFA BASE y la TIP, y los mineros obtendrán la TIP completa. El segundo estado es "cambiante", es decir, el TOPE DE TARIFA sigue siendo superior a la TARIFA BASE, pero inferior a la suma de la TARIFA BASE y la PROPIA. En este caso, los mineros obtienen la diferencia entre FEE CAP y BASE FEE.

Cuando las transacciones no están en estos dos estados, puede crear un orden relativo entre ellos (por TIP para estados de clase "constante" y para estados de clase "variando" por su "punta efectiva", por ejemplo: FEE CAP - BASE FEE)

La idea del artículo de Ansgar es que las transacciones de la clase de estado "cambio" conservarán el mismo orden relativo entre bloques, ya que un aumento/disminución de la TARIFA BASE tendrá el mismo efecto sobre ellas. Esto significa que el núcleo del problema es encontrar una forma eficaz de determinar qué transacciones cambian de "constante" a "variable" cuando cambia la TARIFA BASE, y cómo manejar adecuadamente estas transacciones.

¡¿Esperemos que en la próxima publicación de Quilt tengamos respuestas a estas preguntas?!

Simular actualización

El equipo de Nethermind ha publicado un nuevo cuaderno sobre simulaciones que explora la interacción entre las transacciones heredadas y las transacciones de estilo 1559 en la red, y que las transacciones heredadas se pueden interpretar como transacciones de estilo 1559. Estos estudios se basan en simulaciones anteriores de Barnabé Monnot y su equipo.

Esta simulación presenta tres tipos de usuarios: usuarios 1559 ingenuos que siempre disparan su TIP al valor más bajo; usuarios 1559 inteligentes que establecen estratégicamente su TIP en función del uso de la red; usuarios de transacciones heredadas inteligentes, que establecen estratégicamente el precio de la gasolina en función del uso de la red.

Para cada tipo de usuario, se envía a la red un número fijo de transacciones. Ese informe analizó qué tipos de transacciones se incluyeron, cuánto pagaron esos usuarios y cuánto tiempo terminaron esperando los usuarios.

La sección "Resumen" del informe es corta y vale la pena leerla en su totalidad, pero daré el resumen de todos modos:

Vemos dos "fases" claras en la simulación: cuando BASE FEE converge a su valor de equilibrio, y cuando es estable

En la etapa inestable de TARIFA BASE, los usuarios de smart 1559 iniciarán la mayoría de las transacciones que se empaquetan

El comportamiento del conjunto de transacciones cambia según la "etapa" en la que nos encontremos. Cuando la tarifa base es inestable, hay muchas transacciones desalojadas y el grupo de transacciones debe reorganizarse; pero cuando es estable, el grupo de transacciones tiene muy pocas transacciones desalojadas.

Cuando se habla de burlas en las reuniones de implementadores, surgen dos cuestiones interesantes.

Primero, la TARIFA BASE corre el riesgo de volverse menos estable si aparecen más transacciones heredadas en la red, y las transacciones de estilo 1559 tienden a empaquetarse preferentemente cuando esas fases crean incentivos para adoptar transacciones de estilo 1559.

En segundo lugar, a medida que crece el uso de transacciones al estilo 1559 y la TARIFA BASE se estabiliza, los precios estimados de la gasolina para las transacciones heredadas serán más precisos porque pueden usar el valor de la TARIFA BASE en sus estimaciones. En otras palabras, los usuarios de 1559 ayudarán a reducir la volatilidad de los precios del gas en la red, estrechando los intervalos de confianza de las estimaciones del estimador del precio del gas.

Otras actualizaciones

Se han escrito muchas actualizaciones anteriormente, y un último punto que vale la pena mencionar es que OpenEthereum está contratando a un desarrollador de tiempo completo para trabajar en EIP-1559.

Trabajo de seguimiento

Esta actualización es muy tarde! Esto es lo que vamos a hacer a continuación:

Comparta los resultados del trabajo reciente de I + D con la comunidad, incluido AllCoreDevs, para recopilar comentarios;

Encuentre expertos para proporcionar un mejor análisis de las reglas básicas de actualización de tarifas

Sincronice todos los clientes con una red de prueba de estado grande y use la herramienta generadora de transacciones para probar el rendimiento en la red

Proponga un buen algoritmo que pueda clasificar el grupo de transacciones de los nodos mineros y no mineros

Aunque esto es poco probable en 1559, tales estudios siguen siendo útiles.

Bifurcar la red principal y revelar las principales variables de la red en el cliente puede conducir fácilmente a repetidos ataques y fraudes.

Detrás de escena, envía ETH a 0x0...1, 0x0..2, 0x0..3, etc., y crea entradas de almacenamiento para 0x0..1, 0x0..2, 0x0..3, etc., hasta el deseado La cuenta deseada y el número de ranuras de almacenamiento.

Si FEE CAP es inferior a BASE FEE, entonces la transacción no se puede incluir en el bloque.

Enlace original:

https://hackmd.io/@timbeiko/1559-updates/https%3A%2F%2Fhackmd.io%2F%40timbeiko%2F1559-update-004

Fuente | El Estado de 1559

Autor | Tim Beiko

Tags：

OKX Exchange