Autor: Marco González
Editor: Randall Roland
Traductor: Erick Birbe
Los operadores de nodos, los desarrolladores principales de Antelope y los miembros de la comunidad se reúnen cada semana para discutir las preguntas cautivadoras del día. El objetivo principal de cada mesa redonda de operadores de nodos es:
“...mejorar el protocolo Antelope (específicamente) para los operadores de nodos”.
Las reuniones tienen lugar todos los miércoles de 14 UTC a 15 UTC.
Comenzando el 01 de febrero, las discusiones de la Mesa Redonda de Operadores de Nodos se centraron en los parámetros de configuración para Leap v3.2 y posteriores. Los Nodos de Propósito Especial encontraron inclusión el 8 de febrero. Los Nodos Dedicados para Fines Especiales consumieron las reuniones del mes de febrero 15 y 22. El grupo siguió avanzando en el documento 'Proyecto de taxonomía de las funciones que desempeñan los diferentes nodos Antelope'.
15 de febrero: Nodos de Propósito Especial (continuación) - Nodos API
Vea la mesa redonda del 15 de febrero en el YouTube de la ENF. Lee las notas sobre EOS Nation (Leap) en GitHub.
ACTUALIZACIONES:
Como se mencionó anteriormente, se espera que Leap v4.0.0 comience a probarse en Jungle en marzo. Una actualización de consenso probablemente no ocurrirá hasta septiembre. Además, se espera una congelación del código antes de las primeras pruebas en las próximas semanas.
TEMAS CLAVE DISCUTIDOS
La última reunión terminó con los nodos API. La reunión del 15 de febrero revisó las definiciones fundamentales de los tipos de nodos. Esta semana se introdujeron un par de tipos de nodos, junto con un estimador de transacciones. Ver el (borrador) taxonomía de nodos Antelope para detalles.
Acerca de los tipos de nodos
Las clasificaciones de tipos de nodos se definieron por primera vez la semana pasada. La atención se centró en los propósitos principales.
Tipos de nodos discutidos anteriormente
Nodo Productor de Bloques, objetivos principales y configuración de prácticas recomendadas
Nodo de Retransmisión Bloques Unicamente y configuración de mejores prácticas
Nodo de Retransmisión de Bloques y Transacciones
Comenzando el enfoque en los nodos de la API
Dos tipos de nodos API principales identificados fueron:
Nodo de API Push: "Acepta transacciones a través de clientes HTTP y actúa como un relay de transacciones salientes".
"No acepta transacciones p2p entrantes, a menos que también actúe como un nodo de retransmisión de bloques y transacciones".
Nodo API de la Cadena: "Proporciona acceso para leer primitivos de blockchain... y datos de estado..."
Los tipos de Nodos de Historial tienen requisitos muy diferentes a los que puede proporcionar un Nodo API de la cadena.
Ver el proyecto de documento de taxonomía para notas detalladas y una posible discusión dedicada.
Cerrando las clasificaciones de tipos de nodos esta semana estuvieron las siguientes utilidades generales:
Otros dos tipos de nodos (clasificados como "alimentadores" durante la discusión de la próxima semana) fueron:
Nodo de Instantáneas: periódicamente toma una instantánea y publica un archivo en un host interno/externo
Ver el borrador para una definición más detallada.
Nodo API de Seguimiento: registra información de seguimiento transaccional en el disco local de un cliente para acceder a través de la API.
Soluciones de Capa 2
Un Nodo Proveedor de Recursos estuvo entre las primeras soluciones de capa 2 identificadas:
Nodo Proveedor de Recursos: acepta, interpreta, valida y realiza la lógica comercial en las transacciones del cliente para determinar si se garantiza un cosignatario para cubrir los costos de CPU/NET/RAM
Se incluyó una nota sobre el servicio de nodo del proveedor de recursos que puede convertirse en una solución de complemento llave en mano.
PERSPECTIVAS
Varios temas coinciden con la discusión sobre tipos de nodos y posibles soluciones de capa 2. Incluyen la redacción de las mejores prácticas en los tipos de nodos, posiblemente la exploración de paquetes de nodos especiales y banderas integradas para los valores predeterminados de configuración.
22 de febrero: Nodos de Propósito Especial (continuación): Alimentadores y Capa 2
Vea la mesa redonda del 22 de febrero sobre el YouTube de la ENF. Lee las notas sobre EOS Nation (Leap) GitHub.
ACTUALIZACIONES:
La ENF espera ver las características de Leap v4.0.0 antes de la congelación de código mencionada anteriormente. Vuelva a consultar la fecha de la llamada de la Mesa Redonda que describe las nuevas funciones.
TEMAS CLAVE DISCUTIDOS
La discusión de los nodos de propósito especial continuó con comentarios sobre el documento (borrador) taxonomía de nodo de Antelope. Las notas detalladas de la reunión se pueden encontrar allí. Se presentaron un Nodo de Registro de DeepMind y un Nodo de Historial de estado para avanzar en una solución de capa 2. Los servicios de historia son de particular interés aquí.
Tenga en cuenta que se mencionó la idea de 'carga prioritaria'. La idea es instituir una regla de 3 avisos para resolver un problema (bot) de larga data. La carga prioritaria parece efectiva incluso cuando se trata de los desafiantes problemas de transacciones de WAX. Ampliar los tiempos de medio segundo a unos pocos segundos "limpiaría" un nodo. La solución no cambiaría significativamente las operaciones existentes (para la mayoría). Ampliar la prioridad de carga a uno o dos minutos sería una exageración. Una solución sencilla y eficiente incluso si el tema no aparece en la grabación.
Conceptualización de nodos de alimentación
Consulte la sección anterior para obtener información sobre los tipos de nodos. Ambos tipos de nodos de alimentación discutieron el trabajo mediante la recepción de bloques de pares configurados. Ambos también ayudan a habilitar soluciones de historial de capa 2:
Nodo Registrador de DeepMind: "continuamente serializa el bloque actual, las trazas, etc. y los transmite a la salida estándar para su posterior procesamiento..."
Nodo de Historial de Estado: "almacena bloques/rastros en un archivo de historial de estado..."
Soluciones de Capa 2
Después de los pensamientos de la semana pasada sobre las soluciones de capa 2, hubo un par de servicios más. El formato fue clave para la discusión.
Servicio de Captura de Eventos: Aborda el trabajo de procesar las salidas del nodo alimentador en formatos de propósito especial para garantizar los propósitos previstos. Se utilizó un servicio de proveedor de historial como ejemplo.
Servicio de Proveedor de Historial: un servicio básico disponible en cualquier formato que proporciona datos históricos a pedido de un cliente a través de una API
Tenga en cuenta que el servicio de captura de eventos debe manejar la resolución de la bifurcación.
PERSPECTIVAS
Además de los elementos de perspectiva enumerados para el 15 de febrero, varios otros elementos se enumeraron en Próximos pasos: consulte el (borrador) taxonomía de nodo de antelope para detalles. Las soluciones de capa 2 esperan continuar la próxima semana. Además, se debe definir una matriz de características para los alimentadores.