Este documento fue motivado por nuestro trabajo en el FOCIL especificación de consenso 23, donde nos dimos cuenta de que el protocolo requería una consideración más reflexiva en torno a las limitaciones de recursos, ya que ciertos detalles no se especificaron explícitamente en elFOCIL Ethereum publicación de investigación 14.

PrerrequisitoAntes de comenzar, asumimos la siguiente configuración para establecer una base limpia para nuestras consideraciones:

• La configuración se basa en la bifurcación dura de Electra. También tiene sentido revisar esto sobre la base de EIP-7732 (ePBS) para comparación- Estamos asumiendo la construcción y liberación de bloques en solitario, donde el proponente no está ejecutando MEV-Boost. Este es el primer componente clave para hacerlo bien, mientras que la API del Constructor es una consideración secundaria- Estamos asumiendo una configuración de solo staker con los requisitos típicos de computación, memoria y ancho de banda que puedes seguir fácilmente en la cadena de Ethereum hoy en día.# ActoresAntes de proceder, asumimos que los siguientes actores forman parte del protocolo y analizamos sus responsabilidades:

• Los miembros del comité de la Lista de Inclusión (IL), que son responsables de restringir al próximo proponente de ranura por su conjunto de transacciones de lista de inclusión- El proponente, quien es responsable de proponer el siguiente slot- Attesters, que están atestiguando el siguiente espacio para la cabeza de la cadena- Los nodos, que verifican y siguen la cadena. Los proponentes y atestiguadores son parte de los nodos que han apostado Ether.# Línea de tiempoSuponemos la siguiente línea de tiempo en la que el comité IL, el proponente y los atestiguadores realizan algunas acciones honestas:

• Ranura n-1, t=6: El comité de IL publica sus Listas de Inclusión locales (IL) sobre un tema global después de aprender el contenido del bloque n-1- Slot n-1, t=9: Los Attesters y los nodos verificadores honestos bloquean su visión de los ILs locales- Slot n, t=0: El proponente de bloque para la ranura n libera el bloque B, que incluye la carga útil que debe cumplir con el requisito de IL- Slot n, t=4: Los validadores para la ranura n votan sobre el bloque B, verificando la agregación IL comparándola con sus vistas locales de IL y confirmando si el bloque B es “válido”Sobrecargamos la palabra “válido” cuando nos referimos a un bloque, pero podría significar “importable”, “canónico” o algo más. Consulte la pregunta abierta para obtener más aclaraciones## Intervalo 1: Comité de IL publica IL local### Actor: Comité de Lista de InclusiónLos miembros del comité de IL recuperan una lista de transacciones de IL del cliente EL dado el encabezado (CL → llamada EL), luego firman el IL local (transacciones + resúmenes) y lo liberan a la red de gossip.

Consideraciones de Recursos- Recuperando transacciones IL de la mempool EL → CPU/MEM- Firma de la lista de inclusión → CPU- Cargando la lista de inclusión a la red de gossip → Ancho de banda (Carga)### Actor: Nodos (incluidos Attesters)Los nodos que siguen la cadena descargarán el IL, lo verificarán para anti-DOS (sin importarlo todavía a EL) y lo enviarán a otros pares. Los nodos también importan el IL en la elección de bifurcación y realizan un seguimiento de qué IL se ha visto utilizando una caché aggreGate. Los Attesters y los nodos que siguen la cadena deberían tener la misma visión de la cadena.

Consideraciones de recursos- Descargando el IL → Ancho de banda (Descargar)- Reenviando el IL → Ancho de banda (Carga)- Verificando el IL para anti-DOS → CPU/MEM- Caché vista y aggreGate ILs → MEM### Actor: PropositorEl proponente para el siguiente slot monitorea activamente la red de gossip de IL y recopila y agrega los IL locales, luego en el corte de agregación de IL (intervalo n. ° 2) el proponente actualiza el proceso de construcción de bloques con una lista de transacciones IL que se incluirán en su bloque. Esto requiere una llamada de CL a EL.

Consideraciones de recursos- Hereda los mismos costos que los nodos que siguen la cadena#### Caso límite del proponenteSi el proponente del siguiente espacio observa un número suficiente de listas de inclusión basadas en un hash principal que no ha visto, el proponente deberá solicitar manualmente el bloque de baliza faltante, importar el bloque y construir encima de ese bloque.

ConclusiónBasándonos en lo anterior, podemos identificar áreas potenciales de alto consumo de recursos y centrarnos en ellas:

• Impacto de la CPU del Comité de IL: recuperación de transacciones de IL desde EL y firma: aunque hay demandas de recursos aquí, se presume que esto es relativamente económico y no es una preocupación importante.- Impacto del ancho de banda de los nodos: Los nodos que descargan y cargan listas de inclusión pueden utilizar toneladas de ancho de banda, especialmente porque la publicación de investigación actualmente indica que el tamaño de la lista de inclusión es flexible / no acotado. Esto introduce un posible riesgo de DOS, ya que un miembro malintencionado del comité de inclusión de la lista podría inundar la red con una gran cantidad de transacciones, incluso si son inválidas. Los nodos continuarían hablando sobre la lista de inclusión antes de importarla. Se deben considerar cuidadosamente las medidas anti-DoS.## Intervalo 2: Los nodos bloquean su vista, el proponente importa transacciones IL### Actor: ProponentEl proponente actualiza el proceso de construcción de bloques con una lista de transacciones de lista de inclusión. Se trata de una llamada CL → EL.

Consideraciones de recursos- Actualiza el proceso de construcción de bloques con una lista de transacciones de inclusión de lista → CPU/MEM### Actor: Nodos (incluyendo Attesters)Vista de lista de inclusión de bloqueo. Deje de aceptar la lista de inclusión local a partir de este punto.

Consideraciones de recursos- Vista de lista de inclusión local bloqueada → Ninguna### Conclusión- Impacto de la CPU del proponente: Importar las transacciones de la capa de ejecución en el proceso de construcción de bloques podría interrumpir el proceso de construcción de bloques, potencialmente tensionando la CPU del cliente de la capa de ejecución durante la simulación de la transacción. Esto puede volverse complicado bajo la abstracción de cuentas ya que las transacciones pueden invalidarse entre sí. Esto debe ser analizado con más detalle.## Intervalo 3: El proponente libera el bloque### Actor: ProposerEl proponente recupera la carga útil de ejecución del cliente EL (llamada CL → EL), y la libera en la red de difusión de bloques de baliza. Luego, todos los demás verifican el bloque.

Consideraciones de recursos- Recuperando la carga útil del cliente EL → CPU/MEM### Actor: NodosLos nodos reciben el bloque faro y lo verifican. Los nuevos pasos de verificación incluyen la comprobación de la construcción de aggreGate y la confirmación de si la lista de inclusión satisface la función de evaluación, que se completará en el CL. La comprobación de las condiciones de la lista de inclusión (si se pueden omitir debido a conflictos o no) se realizará en el EL.

Consideraciones de Recursos- Verificando que la lista de inclusión se cumple en CL → CPU- Verificando las condiciones de la lista de inclusión en EL → CPU### ConclusiónLos deberes adicionales para el proponente no parecen ser una preocupación significativa. Los nuevos pasos de verificación para los nodos, verificando que la lista de inclusión cumple con las condiciones satisfactorias, pueden introducir alguna carga adicional en la CPU, pero no parece ser un problema importante.

Intervalo 4: Comité de Attesters### Actor: AttesterEl validador vota por el bloque de faro utilizando la regla de elección de horquilla LMD GHOST. Los validadores solo votarán por un bloque de faro que cumpla con la función de evaluación de la lista de inclusión, basada en observaciones del Intervalo 1.

Consideraciones de recursos- Los validadores votan por un bloque que satisface la función de evaluación de la lista de inclusión → Sin costo adicional### ConclusiónNo hay diferencia que hoy.

Resumen de Consideración de RecursosComo se ha visto anteriormente, las preocupaciones más importantes sobre los recursos giran en torno a la carga y descarga de listas de inclusión y el potencial de spam desde la perspectiva de un nodo. Otra preocupación clave es la sobrecarga de los nodos para verificar e importar la lista de inclusión, así como la necesidad del proponente de actualizar su proceso de creación de bloques para satisfacer la lista de inclusión. Estos aspectos requieren una cuidadosa consideración y diseño para garantizar la eficiencia y la seguridad.

Preguntas AbiertasBasándonos en lo anterior, esbozamos varias preguntas abiertas que influirán en cómo se redacta la especificación:

• Bloque que no cumple la función de evaluación: ¿Cómo se debe manejar un bloque que no cumple la función de evaluación de la lista de inclusión y qué consideraciones de diseño entran en juego para tales condiciones?¿Debería tratarse de manera similar a los blobs y no poder importarse?- ¿No debería filtrarse por elección de bifurcación?- ¿No debería ser válido en la función de transición de estado?- Equivocaciones en la lista de inclusión: Si un miembro del comité de lista de inclusión envía diferentes versiones de la lista de inclusión a diferentes nodos, y todas se propagan a través de la red, ¿cuáles son las consecuencias de esta acción? ¿Cómo podría este comportamiento impactar negativamente en el proponente que construye el siguiente bloque?- El proponente ya está construyendo en una cabeza diferente: Si el proponente construye en una cabeza diferente a la enviada por el comité de inclusión, y por lo tanto necesita cambiar su visión de la cabeza, ¿cuáles son las consecuencias de esta acción para la validez del bloque y el comportamiento del proponente?- Invalidaciones de transacciones de la lista de inclusiones: Las transacciones de la lista de inclusiones locales pueden ser invalidadas de varias maneras. Incluso si estas transacciones son invalidadas, el bloque aún debería poder cumplir con la función de evaluación. Las transacciones pueden ser invalidadas a medida que varias listas de inclusiones se fusionan entre sí o con transacciones en el bloque. Además de la verificación típica de nonce, la abstracción de cuenta introduce nuevas formas de invalidar transacciones, ya que el saldo puede ser drenado con un nonce estático. Aún queda por ver cuánta simulación adicional necesita realizar un generador de bloques debido a la invalidación de transacciones y cuánto afecta esto a su capacidad de cálculo de la CPU tanto para los actores de MEV-Boost como para los generadores locales.- Observación del proponente de la subred del comité de lista de inclusión: El proponente supervisa la subred del comité de lista de inclusión para saber cuándo está listo para construir el aggreGate. Aquí hay dos enfoques de diseño, y vale la pena considerarlos más a fondo. El primer enfoque es un proponente codicioso, donde el proponente espera hasta t=9, reúne tantos IL como sea posible, los envía al EL, y el EL actualiza su bloque. El segundo enfoque es un proponente selectivo, donde el proponente espera hasta tener una lista de inclusión suficiente para satisfacer la función de evaluación, los envía al EL, y puede hacer esto en menos de t=9s o incluso antes. La pregunta es si el segundo enfoque justifica la optimización para permitir que el proponente libere el aggreGate de la lista de inclusión antes. El segundo enfoque puede ser adecuado solo para un IL con su propio límite de gas dedicado.### Descargo de responsabilidad:- Este artículo es una reimpresión de [ethresear]. Todos los derechos de autor pertenecen al autor original [terence]. Si hay objeciones a esta reimpresión, por favor contactar al Aprendizaje de la puertaequipo, y ellos lo resolverán rápidamente.- Descargo de responsabilidad por responsabilidad: Las opiniones expresadas en este artículo son únicamente las del autor y no constituyen ningún consejo de inversión.- Las traducciones del artículo a otros idiomas son realizadas por el equipo de Gate Learn. A menos que se mencione, está prohibido copiar, distribuir o plagiar los artículos traducidos.