Este es un hilo sobre la consagración. Siempre ha habido un impulso de diferentes sectores para tener ePBS sin la eliminación de jugadores confiables. El dicho común es "podemos estar consagrando lo malo". Quiero disputar esto con vehemencia, y este puede ser un hilo largo. 1/11

Como prometí, este es mi recordatorio de que ePBS es real ahora, bien estudiado, implementado y ahora respaldado por la mayoría de los equipos de los clientes

Una extensión interesante que permite el diseño de TimeBoost es informar a las aplicaciones sobre las transacciones "TimeBoosted", en el momento de la ejecución. Esto podría dar lugar a que las aplicaciones adapten sus mecanismos de tarifas. Si eso sucede, los arbitrajistas que usan TimeBoost también se adaptarán a eso🧵

¡Estoy feliz de compartir que nuestro trabajo ganó el premio al mejor artículo! Gracias, @will_wjk, @StefLeonardos y al equipo por organizar una gran conferencia.

📢 Una propuesta para la medición multidimensional de gas en Ethereum L1 Permite aumentar la capacidad del bloque, sin cambiar el límite de gas del bloque y sin complicar la UX. + se puede ampliar fácilmente a precios multidimensionales fáciles de usar (¡final del juego 1559!). 👇 Tl; DR y enlaces a continuación

Ha habido mucha confusión sobre TimeBoost, especialmente lo que realmente hace. Algunas de las siguientes son mis conclusiones personales al respecto y algunas son hechos que pueden resultarle interesantes: 1. ¿Qué?: La política de pedidos de transacciones de Arbitrum antes de TimeBoost era por orden de llegada (FCFS). Con TimeBoost es casi lo mismo: las transacciones "TimeBoosted" forman la orden FCFS inmediatamente, que se fusiona con las transacciones regulares que también forman la orden FCFS con un retraso de 200 ms. Es importante destacar que TimeBoost NO da derecho a proponer bloques y NO otorga derechos de secuenciación. 2. ¿Por qué?: TimeBoost ha sido diseñado principalmente para cambiar la inversión de los buscadores de arbitraje en la reducción de la latencia y la infraestructura a los ingresos de la cadena, ya que el primero es un valor perdido para (todo tipo de) usuarios de la cadena. El segundo objetivo era reducir las transacciones revertidas debido a los retrocesos probabilísticos. El tercer objetivo era estar lo más cerca posible de la política de pedidos de la FCFS. TimeBoost NO ha sido diseñado para maximizar los ingresos, especialmente a corto plazo. 3. ¿Cómo se desempeña?: El objetivo principal se logra parcialmente, qué tan grande es esta parte es a) difícil de calcular, b) debe probarse con el tiempo. El segundo objetivo aún no se ha logrado, pero creo que mejorará. El tercer objetivo está claramente logrado. En general, me parece un diseño alternativo interesante para el orden de transacciones para estudiar, desde una perspectiva de investigación, y ahora también con datos de la vida real. La parte de la subasta de TimeBoost está bastante relacionada con la idea de los boletos de ejecución propuesta por los investigadores de la Fundación Ethereum.

Esperamos presentar nuestro documento "MEV Capture Through Time-Advantaged Arbitrage" (con @robin_ethz, @misilva73, @EdFelten, @convoluted_code) en la conferencia MARBLE la próxima semana. Programa completo de la conferencia: El artículo estudia el valor de TimeBoost proveniente del arbitraje CEX-DEX y (empíricamente) lo compara con las subastas FCFS y PGA.

Espero poder hablar sobre TimeBoost hoy en @ZuBerlinCity.

Para las oportunidades de backrunning, argumentamos que la ventaja de tiempo (por ejemplo, TimeBoost) puede reducir drásticamente la tasa de transacciones probabilísticas, lo que se traduce en un "spam": , en comparación con FCFS, en el que todo el valor se desperdicia en spam. Para el ejemplo de distribución de valores obtenida por estimaciones aproximadas, la reducción fue de solo el 15% del valor gastado en spam. Para algunas distribuciones, puede resultar en un valor 0 gastado en spam.

En un nuevo artículo con Benny Sudakov de @ETH_en, comparamos el Restaking con el protocolo Proof-of-Stake (PoS). En primer lugar, analizamos la condición suficiente para que un gráfico de replanteamiento sea seguro. Bajo esta condición, siempre es posible transformar un grafo de retaking en protocolos PoS seguros.