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.
Antes de comenzar, asumimos la siguiente configuración para establecer una base limpia para nuestras consideraciones:
Antes de proceder, asumimos que los siguientes actores forman parte del protocolo y analizamos sus responsabilidades:
Suponemos la siguiente línea de tiempo en la que el comité IL, el proponente y los atestiguadores realizan algunas acciones honestas:
Los 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.
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.
El 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.
Si 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.
Basándonos en lo anterior, podemos identificar áreas potenciales de alto consumo de recursos y centrarnos en ellas:
El 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.
Vista de lista de inclusión de bloqueo. Deje de aceptar la lista de inclusión local a partir de este punto.
El 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.
Los 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.
Los 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.
El 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.
No hay diferencia que hoy.
Como 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.
Basándonos en lo anterior, esbozamos varias preguntas abiertas que influirán en cómo se redacta la especificación:
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.
Antes de comenzar, asumimos la siguiente configuración para establecer una base limpia para nuestras consideraciones:
Antes de proceder, asumimos que los siguientes actores forman parte del protocolo y analizamos sus responsabilidades:
Suponemos la siguiente línea de tiempo en la que el comité IL, el proponente y los atestiguadores realizan algunas acciones honestas:
Los 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.
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.
El 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.
Si 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.
Basándonos en lo anterior, podemos identificar áreas potenciales de alto consumo de recursos y centrarnos en ellas:
El 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.
Vista de lista de inclusión de bloqueo. Deje de aceptar la lista de inclusión local a partir de este punto.
El 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.
Los 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.
Los 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.
El 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.
No hay diferencia que hoy.
Como 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.
Basándonos en lo anterior, esbozamos varias preguntas abiertas que influirán en cómo se redacta la especificación: