Binance Square

terencechain

0 Siguiendo
0 Seguidores
0 Me gusta
0 Compartido
Publicaciones
·
--
He visto mucho vaivén sobre el tiempo de ranura más rápido (EIP-7782) y epbs (EIP-7732), así que quería compartir dónde me encuentro. Primero, quiero enfatizar que todas las discusiones que he visto han sido de buena fe, todos quieren lo mejor para Ethereum. La pregunta principal es solo el orden de las operaciones. ¡Este es un buen problema para tener! Desde afuera puede parecer desordenado, pero así es como se ve la I+D pública. Estamos en una cocina abierta debatiendo si servir primero el filete o la langosta, el cliente recibe ambos de todos modos, solo es cuestión de cuándo y cómo. Ahora hablando solo por mí mismo (no por mi equipo), creo que deberíamos implementar EIP-7732 primero. Aquí está el porqué: 1.) Desde una perspectiva de ingeniería, tiene más sentido reestructurar primero y luego acortar. Hacerlo al revés no solo implica más trabajo de ingeniería, no es 1:1 (tampoco es lineal) pero es más difícil de razonar. 2.) Desde una perspectiva de pruebas, es más simple probar la reestructuración de ranuras primero y luego las ranuras más rápidas. ¡Como vimos en Pectra, las pruebas son el principal cuello de botella para la implementación! 3.) Desde una perspectiva de seguridad, implementar un cambio más grande (como la reestructuración) primero y luego uno más pequeño (acortamiento) es a menudo más seguro. Déjalo funcionar en mainnet y refuérzalo antes de agregar más complejidad. 4.) Desde una perspectiva de cronograma, en términos de tiempo combinado, creo que (EIP-7732 → EIP-7782) es más rápido que (EIP-7782 → EIP-7732). Podríamos implementar 7782 solo 3-4 meses después de 7732 si trabajamos en ambos en paralelo y cambiamos al modo de prueba tan pronto como 7732 se implemente. Un corto fork solo de CL podría llevarnos allí rápidamente. Esa es solo mi opinión como alguien que construye e implementa estas cosas día a día. Me falta contexto tanto en la investigación como en la comunidad. En última instancia, los usuarios de Ethereum deberían tener voz, ¿preferirías tiempos de ranura más rápidos en Glamsterdam o un límite de gas de ejecución más alto y más capacidad de bloques? ¿Por qué? Me encantaría escuchar tus pensamientos.
He visto mucho vaivén sobre el tiempo de ranura más rápido (EIP-7782) y epbs (EIP-7732), así que quería compartir dónde me encuentro. Primero, quiero enfatizar que todas las discusiones que he visto han sido de buena fe, todos quieren lo mejor para Ethereum. La pregunta principal es solo el orden de las operaciones. ¡Este es un buen problema para tener! Desde afuera puede parecer desordenado, pero así es como se ve la I+D pública. Estamos en una cocina abierta debatiendo si servir primero el filete o la langosta, el cliente recibe ambos de todos modos, solo es cuestión de cuándo y cómo.

Ahora hablando solo por mí mismo (no por mi equipo), creo que deberíamos implementar EIP-7732 primero. Aquí está el porqué:

1.) Desde una perspectiva de ingeniería, tiene más sentido reestructurar primero y luego acortar. Hacerlo al revés no solo implica más trabajo de ingeniería, no es 1:1 (tampoco es lineal) pero es más difícil de razonar.
2.) Desde una perspectiva de pruebas, es más simple probar la reestructuración de ranuras primero y luego las ranuras más rápidas. ¡Como vimos en Pectra, las pruebas son el principal cuello de botella para la implementación!
3.) Desde una perspectiva de seguridad, implementar un cambio más grande (como la reestructuración) primero y luego uno más pequeño (acortamiento) es a menudo más seguro. Déjalo funcionar en mainnet y refuérzalo antes de agregar más complejidad.
4.) Desde una perspectiva de cronograma, en términos de tiempo combinado, creo que (EIP-7732 → EIP-7782) es más rápido que (EIP-7782 → EIP-7732). Podríamos implementar 7782 solo 3-4 meses después de 7732 si trabajamos en ambos en paralelo y cambiamos al modo de prueba tan pronto como 7732 se implemente. Un corto fork solo de CL podría llevarnos allí rápidamente.

Esa es solo mi opinión como alguien que construye e implementa estas cosas día a día. Me falta contexto tanto en la investigación como en la comunidad. En última instancia, los usuarios de Ethereum deberían tener voz, ¿preferirías tiempos de ranura más rápidos en Glamsterdam o un límite de gas de ejecución más alto y más capacidad de bloques? ¿Por qué? Me encantaría escuchar tus pensamientos.
No he podido asistir a las llamadas de ACD tanto como me gustaría, pero la sesión de hoy se vio súper productiva. ¡Ethereum está enviando y escalando!
No he podido asistir a las llamadas de ACD tanto como me gustaría, pero la sesión de hoy se vio súper productiva. ¡Ethereum está enviando y escalando!
La cola de validadores de Ethereum ha estado creciendo constantemente desde finales de mayo, analicé todos los antiguos depósitos de ejecución ETH1 y los nuevos depósitos de EIP-6110 desde el slot 11649077 -> 11931977 Números a alto nivel: - Hay un total de 82,529 nuevos depósitos de EL frente a 541 antiguos depósitos de datos eth1, ya que se esperaba que el depósito eth1 fuera desaprobado - Total de 2.3M ETH depositados a través del depósito de EL - 375 depósitos de EL mayores a 32 ETH ahora compartimos algunos gráficos:
La cola de validadores de Ethereum ha estado creciendo constantemente desde finales de mayo, analicé todos los antiguos depósitos de ejecución ETH1 y los nuevos depósitos de EIP-6110 desde el slot 11649077 -> 11931977

Números a alto nivel:
- Hay un total de 82,529 nuevos depósitos de EL frente a 541 antiguos depósitos de datos eth1, ya que se esperaba que el depósito eth1 fuera desaprobado
- Total de 2.3M ETH depositados a través del depósito de EL
- 375 depósitos de EL mayores a 32 ETH

ahora compartimos algunos gráficos:
https://launchpad.ethereum.org/es/acciones-de-validador es criminalmente subestimado. La experiencia de usuario para el depósito parcial, retiro y compuesto es súper fluida. Un gran reconocimiento al equipo detrás de esto, pero como siempre, haz tu propia investigación.
https://launchpad.ethereum.org/es/acciones-de-validador es criminalmente subestimado. La experiencia de usuario para el depósito parcial, retiro y compuesto es súper fluida. Un gran reconocimiento al equipo detrás de esto, pero como siempre, haz tu propia investigación.
He estado investigando bloques durante el último mes y encontré algo interesante: 172 bloques no tenían transacciones, 85 no tenían destinatarios de tarifas. Eso es ~5–6 por día, aproximadamente la misma tasa que los reorgs. Ejemplo: https://t.co/lw0pSAePBt ¿Podrían los reorgs de último minuto estar sorprendiendo a los constructores? ¿Alguien sabe más? cc @Data_Always
He estado investigando bloques durante el último mes y encontré algo interesante:
172 bloques no tenían transacciones, 85 no tenían destinatarios de tarifas.
Eso es ~5–6 por día, aproximadamente la misma tasa que los reorgs.
Ejemplo: https://t.co/lw0pSAePBt
¿Podrían los reorgs de último minuto estar sorprendiendo a los constructores? ¿Alguien sabe más? cc @Data_Always
Un mes desde la actualización de Pectra. Escribí un script rápido para descargar todos los bloques desde & el uso de solicitudes de ejecución de estudio. Lo que encontré a través de 236k espacios: - De 236k espacios, solo 30,587 bloques tuvieron alguna solicitud de ejecución - En esos bloques, hubo 69,041 solicitudes de depósito, 312 solicitudes de retiro (¡por qué tan pocas!), y 17,570 solicitudes de consolidación - Para depósitos, vimos 57,293 claves públicas únicas y 2,102 credenciales de retiro únicas - Para retiros, 262 claves públicas de validador únicas y 100 direcciones de origen únicas - Para consolidación, 3,422 direcciones de destino únicas y 3,544 auto-consolidaciones, lo que parece ser ~1.3% de los validadores consolidados ¿Algo te llamó la atención aquí?
Un mes desde la actualización de Pectra. Escribí un script rápido para descargar todos los bloques desde & el uso de solicitudes de ejecución de estudio. Lo que encontré a través de 236k espacios:

- De 236k espacios, solo 30,587 bloques tuvieron alguna solicitud de ejecución
- En esos bloques, hubo 69,041 solicitudes de depósito, 312 solicitudes de retiro (¡por qué tan pocas!), y 17,570 solicitudes de consolidación
- Para depósitos, vimos 57,293 claves públicas únicas y 2,102 credenciales de retiro únicas
- Para retiros, 262 claves públicas de validador únicas y 100 direcciones de origen únicas
- Para consolidación, 3,422 direcciones de destino únicas y 3,544 auto-consolidaciones, lo que parece ser ~1.3% de los validadores consolidados

¿Algo te llamó la atención aquí?
Hoodi testnet alcanzando 60M límite de gas 🚀
Hoodi testnet alcanzando 60M límite de gas 🚀
Una semana después de Pectra: las reorganizaciones por día han vuelto a los niveles previos a Petra, luciendo bien hasta ahora
Una semana después de Pectra: las reorganizaciones por día han vuelto a los niveles previos a Petra, luciendo bien hasta ahora
La red de prueba Sepolia alcanzando un límite de 60M de gas🚀
La red de prueba Sepolia alcanzando un límite de 60M de gas🚀
Pectra guardó el precio de eth, ¿quién sabía que todo lo que se necesitaba era mover el índice del comité fuera de la atestación?
Pectra guardó el precio de eth, ¿quién sabía que todo lo que se necesitaba era mover el índice del comité fuera de la atestación?
Pectra lanza mainnet en ~20 horas No estaré twitteando la finalización—solo espero que todo salga bien 🫶
Pectra lanza mainnet en ~20 horas
No estaré twitteando la finalización—solo espero que todo salga bien 🫶
Inicia sesión para explorar más contenidos
Descubre las últimas noticias sobre criptomonedas
⚡️ Participa en los debates más recientes sobre criptomonedas
💬 Interactúa con tus creadores favoritos
👍 Disfruta del contenido que te interesa
Correo electrónico/número de teléfono
Mapa del sitio
Preferencias de cookies
Términos y condiciones de la plataforma