Autor: Marco González
Editor: Randall Roland
Traductor: Cristhian Rincon
Operadores de nodos, desarrolladores del núcleo de Antelope y miembros de la comunidad se reúnen cada semana para debatir las preguntas más 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 (de 13 UTC a 14 UTC durante el horario de verano). La EOS Network Foundation ofrece tutoriales y documentación para quienes deseen aprender los fundamentos del funcionamiento de un nodo EOS (y mucho más).
A continuación figura la lista de las dos mesas redondas incluidas en este resumen bimensual:
5 de julio: Eficiencia y estabilidad: Tráfico, tamaño/tiempo de bloque y SHiP
12 de julio: Soluciones fáciles de usar para autorizaciones multiacción y 5.0
Busque notas y comentarios adicionales sobre la reunión en GitHub. Los vídeos están en el YT de la ENF.
Mesa redonda del 5 de julio:
Eficacia y estabilidad: Tráfico, tamaño de bloque/tiempo, 5.0 y SHiP
A medida que se acerca Leap 5.0, las mesas redondas adoptan la forma de debates abiertos. Alinear las operaciones de los nodos con el lanzamiento de la versión 5.0 es todo un reto. El seguimiento del sentimiento de la comunidad, el intercambio de actualizaciones de desarrollo y la comunicación probablemente determinen la fluidez de la actualización anual consensuada este otoño (2023).
Los intereses de la comunidad el 5 de julio se centraron en el tamaño de los bloques y los tiempos.
Visión general
La eficacia y la estabilidad caracterizan el debate sobre el alto tráfico (en la versión 4.0 de Leap), el tamaño/tiempo de los bloques, 5.0 y los problemas de SHiP. Persiste una sensación de armonía a medida que se acerca Leap 5.0.
Actualizaciones
próximamente un parche con más detalles
Tema de la Comunidad: Eficacia y Estabilidad
El debate se centró en general en la eficiencia y la estabilidad. Se examinaron detalles como el rendimiento y el tráfico de la red, SHiP, el tamaño de los bloques, el tiempo de procesamiento y las mejoras de Leap 5.0. También se incluye un enlace sobre cómo evitar fallos al procesar APIs.
Tráfico
Aunque la Red EOS es el centro de las mesas redondas de operadores de nodos, las reuniones están abiertas a debates en todas las cadenas públicas de AntelopeIO. Entre las de mayor tráfico se encuentra WAX.
El enorme tráfico de WAX pone al límite a los operadores de nodos. Discutir los problemas de tráfico de WAX ayuda al desarrollo de nuevas versiones del software AntelopeIO. Las futuras iteraciones de EOS, WAX y otras cadenas AntelopeIO mejorarán sin duda gracias a las investigaciones sobre el tráfico.
WAX lucha por implementar la versión 4.03 de Leap debido a algunos problemas existentes. Las pruebas continúan a medida que surgen informes de errores. También hay que tener en cuenta las pruebas de carga en el mundo real. Hay que tener en cuenta que la versión 5.0 de Leap prepara unas capacidades de rendimiento muy superiores a las que son posibles actualmente en entornos 4.0.
Tamaño/Tiempo de bloque y Leap 5.0
El tamaño de bloque sigue siendo un tema de gran interés. Cuando se lanzó EOS, el tiempo máximo de bloqueo de la CPU se fijó en 100 milisegundos. Los tiempos aumentaron a 250 milisegundos, pero en respuesta a algunos problemas iniciales, la red se estableció en 200 milisegundos, donde permanece hoy. Leap 5.0 volverá a 250 milisegundos con la capacidad de manejar velocidades mucho más rápidas.
Otros temas y preocupaciones planteados incluyen:
configuración variable del tamaño de los bloques
cuellos de botella
tiempos de fallo y evaluación de transacciones
rendimiento de la red
listas blancas y niveles de cuentas
tiempos establecidos frente a tiempo porcentual
Leap 5.0 cambiará las operaciones de los nodos mediante rondas más rápidas y ventajas derivadas de la finalización anticipada de bloques. Los detalles de las rondas más rápidas se desglosan como:
elige siempre el tiempo de bloque más pequeño
desplazamientos de milisegundos frente a conjuntos de bloques
La finalización anticipada de bloques implica permitir inicios de bloque más tempranos aunque la hora de finalización siga siendo la misma.
Aunque la 5.0 realizará inicios de bloque más rápidos (respecto a la 4.0), el equipo de desarrollo sigue queriendo ver las capacidades existentes en la 4.0.
La necesidad de llegar a un hilo principal e interrumpir transacciones en proceso se resuelve en 5.0. La posibilidad de intercesión sigue existiendo. A continuación se mencionó la programación y el deseo de comenzar pronto las pruebas, antes de la versión de otoño.
Problemas de SHiP
Una nueva versión del parche debería resolver los problemas recientes con SHiP (State History Plugin). Un informe identificó la falta de respuesta de SHiP sin conexiones entre pares. Las instantáneas pueden ser útiles en tales casos. Las correcciones abordan la sincronización de EOS desde Genesis. Otro problema detectado se refería a la no recepción de datos ABI. El flujo de datos se detenía al desconectarse de SHiP. Todo parece fácil de solucionar.
Esté atento a los próximos lanzamientos de parches.
Mesa redonda del 12 de julio:
Soluciones Fáciles de usar para Autorizaciones Multiacción y 5.0
En la reunión del 12 de julio se estudiaron aplicaciones dinámicas para autorizaciones de usuarios. Se abordaron las correcciones de seguridad. Los preparativos iniciales para Leap 5.0 podrían comenzar en las próximas semanas.
Visión general
Las aplicaciones dinámicas deben tener en cuenta a los usuarios. Se estudiaron soluciones tanto desde el punto de vista de los monederos como de los cambios de código específicos para los operadores de nodos. Las soluciones de monedero para la autorización multiacción pueden resultar más útiles por varias razones.
Actualizaciones
Las versiones solucionan una vulnerabilidad de seguridad. Consulte los enlaces de las versiones asociadas para obtener más información sobre cada corrección (incluida una solución de estabilidad).
Soluciones Fáciles de usar para Autorizaciones Multiacción y 5.0
La mesa redonda de hoy analizó un tema candente. Los usuarios de Blockchain necesitan mantener el control sobre los activos al tiempo que experimentan una funcionalidad familiar similar a la de Web2. Las autorizaciones dinámicas que tienen en cuenta en primer lugar las soluciones de monedero probablemente sean la mejor opción.
Algunas combinaciones de autorización consideradas durante esta mesa redonda incluyen:
una opción de caducidad
recibo (token) para autorización guardada en cadena específica para usuarios
autorizaciones delegadas de contratos inteligentes
normas comunes para opciones variables
listas blancas
solicitud de autorización (RFP)
Las opciones de caducidad y las listas blancas son las que más llaman la atención. Aunque pueden existir soluciones a través de cambios en el código central, las soluciones de wallets de confianza parecen ser un primer paso prudente.
Por ejemplo, las RFP pueden funcionar bien con una solución "wallet-first" similar a las anteriores funciones de Scatter. Sin embargo, surgieron preocupaciones en torno a la programación de transacciones y los cierres asíncronos de monederos/aplicaciones (especialmente juegos).
"un espacio de nombres (.ra) y luego usas la clave pública del usuario para registrar una nueva cuenta"
Un planteamiento general para cualquier solución es considerar en qué difieren las perspectivas de los usuarios de la parte técnica. Se hicieron comparaciones con la racionalización de las autorizaciones web tradicionales frente a las expectativas de los usuarios. Es posible que los usuarios deseen mantener una única cuenta de blockchain aunque la realidad sea más complicada a nivel de desarrollador. Se sugirieron de nuevo las funciones de wallet.
El moderador sugirió temas relacionados con Leap 5.0, como la finalidad instantánea (IF) y la ruptura del consenso. Entre los temas clave del resto de la mesa redonda se incluyen:
la coordinación de una actualización del protocolo de consenso
más información sobre los permisos de listas blancas frente a los de cuentas (aspectos temporales)
una nueva clave pública para las opciones de caducidad (preocupación de seguridad planteada) frente al reconocimiento de inicio de sesión del monedero
anotación sobre los monederos que actualmente almacenan claves y no aplicaciones
las aplicaciones móviles pueden necesitar opciones de caducidad únicas y límites de control a nivel de eosio (por ejemplo, permisos de nombres premium para ventas en el mercado)
preguntado en el chat: "...permiso para eliminar su propio permiso..." o siempre se necesita una clave de propietario
Algunas ideas cerraron la reunión. Entre los temas a considerar figuran la comprensión de las aspiraciones, mantenerse al día (por ejemplo, gestores de paquetes), facilitar herramientas de desarrollo personalizadas y subrayar la importancia de la documentación fundamental.