Prioridades de CometBFT para el segundo trimestre de 2023

https://medium.com/the-interchain-foundation/cometbft-priorities-for-2023-q2-3735253eacc9

Aspectos clave: En el segundo trimestre, el equipo de Comet se enfocará en cinco áreas de trabajo. Cada área tiene como objetivo abordar un problema importante de nuestra lista de prioridades.

Los problemas que estamos abordando tienen un alcance más amplio que este trimestre. Por lo tanto, esperamos seguir centrados en estos problemas durante el resto de 2023.

Los cinco problemas en los que nos enfocaremos son, en orden de prioridad:

CometBFT brinda un soporte deficiente para el diseño de protocolos a los desarrolladores de aplicaciones.

Actualmente no hay una alternativa para la sincronización de estado basada en red.

El JSON/RPC que exponen los nodos de CometBFT es inestable.

El almacenamiento y el consumo de ancho de banda son costosos para los operadores que ejecutan nodos de CometBFT.

Para soluciones específicas, consulte la publicación completa a continuación.

Contexto Lanzamos CometBFT a principios de febrero de 2023. Han pasado 2 meses desde entonces. En este breve tiempo, hemos avanzado significativamente en el desarrollo de CometBFT. En esta publicación, primero resumiremos cuáles fueron nuestros principales éxitos durante el primer trimestre. Luego, proporcionaremos una descripción general de las prioridades que planeamos abordar como parte del segundo trimestre, así como el proceso que utilizamos para llegar a estas prioridades.

Resumen del primer trimestre El primer trimestre fue un período interesante para el equipo de CometBFT porque el primer mes (enero) estuvo lleno de actividades relacionadas con el fork de Tendermint Core, el cambio de nombre de ese fork a CometBFT y la preparación de su anuncio público. Este trabajo fue tedioso pero muy gratificante: nos permitió reiniciar el desarrollo y proporcionar una base sólida para seguir evolucionando este software hacia el crecimiento del Interchain. Por favor, lea el anuncio que presenta CometBFT aquí y en este hilo.

En cuanto a los entregables técnicos y de documentación, durante el primer trimestre enviamos lo siguiente:

3 y 4 de febrero: lanzamos v0.34.25 y v0.34.26, siendo el primer lanzamiento un parche de seguridad para la línea v0.34.. Ambos de estos lanzamientos se realizaron desde el fork público del equipo de Informal Systems de Tendermint Core. 27 de febrero: lanzamos v0.34.27, el primer lanzamiento oficial de CometBFT, un reemplazo directo de Tendermint Core v0.34.x 28 de febrero: publicamos la documentación oficial de CometBFT en https://docs.cometbft.com/ 6 de marzo: lanzamos v0.37.0, el primer lanzamiento de CometBFT con ABCI 1.0 29 de marzo: lanzamos v0.38.0-alpha.1, una versión preliminar con ABCI 2.0 Tanto v0.37. como v0.38.* han estado en preparación durante mucho tiempo. Agradecemos a todos los equipos y colaboradores que han ayudado a diseñar y refinar ABCI2.0 durante los últimos ~2 años. Es realmente emocionante ver todo este trabajo dar sus frutos y la numerosas redes interesadas en aprovechar las nuevas características en la interfaz ABCI.

Durante las últimas dos semanas de marzo, hemos estado ocupados gestionando nuestro backlog y ordenando nuestras prioridades para tener claridad sobre el trabajo que realizaremos en los próximos 3 meses.

Prioridades para el segundo trimestre (abril, mayo, junio) Tenemos cinco áreas de investigación y desarrollo planificadas para el próximo trimestre. Primero hablaremos sobre el problema que cada una de estas áreas de trabajo intenta abordar y luego proporcionaremos un contexto sobre el espacio de soluciones.

Problema (1) CometBFT v0.34 brinda un soporte deficiente a los desarrolladores de aplicaciones para abordar casos de uso novedosos. CometBFT v0.34, utilizado en producción en la actualidad, comprende la interfaz ABCI v0.17. ABCI es la API que separa la aplicación del motor de consenso. Esta es la interfaz que los desarrolladores de aplicaciones tienen a su disposición para interactuar con CometBFT.

ABCI v0 fue diseñada alrededor de 2015-2016. Desde entonces, el ecosistema criptográfico en general ha evolucionado rápidamente. Las aplicaciones demandan más flexibilidad y control hoy en día. Los desarrolladores de aplicaciones buscan tener un control más detallado sobre lo que CometBFT coloca dentro de los bloques y utilizar CometBFT para intercambiar información entre nodos que no sea a través de bloques.

Para abordar este problema, se propuso ABCI++ alrededor de 2020 (RFC 013). ABCI++ se está entregando en dos versiones: ABCI v1 (CometBFT v0.37) y ABCI v2 (CometBFT v0.38). Como se mencionó anteriormente, hemos lanzado ABCI v1, y para v2 estamos en las fases finales: ya hemos lanzado una versión alpha-1. Lo que queda es ajustar el diseño de la interfaz, escribir una documentación más completa de ABCI v2 y realizar una extensa QA a gran escala que generalmente implica testnets de 200 nodos.

Estimamos que el lanzamiento de v0.38.0 llevará otros 1-2 meses de trabajo.

Problema (2) Actualmente no hay alternativa para la sincronización de estado basada en red. En CometBFT v0.34, la sincronización de un nodo nuevo con el resto de la red se basa en un protocolo que obtiene instantáneas de otros pares en la red. Algunas desventajas de este enfoque son que es frágil (porque las instantáneas de los pares pueden no estar disponibles de inmediato) y consume mucho ancho de banda.

Existen alternativas a la sincronización de estado basada en red. Por ejemplo, utilizando una instantánea local, que puede haber sido generada por el propio nodo o copiada de una fuente de confianza, la sincronización de estado podría evitar transferencias grandes desde pares remotos. Se ha explorado una alternativa de este tipo y planeamos incorporar ese trabajo en una versión futura de CometBFT.

Este problema es particularmente interesante porque los operadores emplean la sincronización de estado de nuevos nodos con frecuencia. Lo hacen porque el consumo de almacenamiento de los nodos aumenta con el tiempo, por lo que hay una preferencia por configurar nuevos nodos regularmente. El problema del crecimiento del almacenamiento es algo que conocemos y también es una prioridad (ver abajo). En resumen, este es un problema importante y, como un usuario importante mencionó en el problema de seguimiento, es esencial abordarlo.

Problema (3) El JSON/RPC que exponen los nodos de CometBFT es inestable. Hay múltiples dimensiones en este problema. En primer lugar, la implementación de JSON/RPC es muy compleja y, en segundo lugar, es ortogonal a la tarea principal de CometBFT, que es la replicación de máquinas de estado (no RPC), por lo que infla innecesariamente la superficie que debemos mantener. En tercer lugar, somos conscientes de preocupaciones de seguridad, es decir, que el RPC es un posible vector de DDoS, por lo que recomendamos medidas defensivas. En cuarto lugar, la interfaz RPC puede ser un cuello de botella para las operaciones de retransmisión IBC; esto se desprende de nuestra experiencia en el desarrollo de Hermes IBC Relaye y su ejecución como parte de Informal Staking. En quinto lugar, la interfaz RPC puede ejercer presión sobre otros componentes de CometBFT (por ejemplo, el consenso), lo que puede hacer que el nodo sea poco confiable al quedar fuera de sincronización con la red.

Nuestro enfoque para solucionar esto todavía está en la fase de exploración, pero tenemos una solución prometedora en forma de un Data Companion. Recientemente discutimos esto en nuestra llamada comunitaria y esperamos comentarios directamente en los PR (ADR 100, ADR 101).

Problemas (4) y (5) El almacenamiento y el consumo de ancho de banda son costosos para los operadores que ejecutan nodos de CometBFT. En cuanto al almacenamiento, el problema es que la poda no funciona de manera efectiva. Esto conduce a un aumento de los costos de almacenamiento con el tiempo. A un nivel más básico, CometBFT admite múltiples bases de datos, pero no existe un caso de uso documentado de las características de carga de trabajo esperadas de estas bases de datos. En consecuencia, no está claro cuál de ellas es más adecuada desde una perspectiva de rendimiento y eficiencia. Al igual que con el problema de JSON/RPC, queremos reducir la superficie bajo nuestro mantenimiento y, por lo tanto, preferiríamos reducir las bases de datos admitidas a la que mejor se adapte.

En términos de ancho de banda, somos conscientes de que los operadores están incurriendo en costos elevados debido al consumo de ancho de banda de las redes basadas en CometBFT. Para mitigar esto, una investigación inicial condujo a una reducción del 50% de los votos de Precommit enviados entre pares. Continuamos esa investigación hacia la reducción del consumo de ancho de banda no relacionado con votos (por ejemplo, partes de bloques o transacciones). Un elemento importante de esta investigación comprende la elaboración de especificaciones para los módulos P2P y de consenso, que son el centro de atención en lo que respecta al uso de ancho de banda.

Proceso Hemos elegido los problemas en función de los comentarios y la retroalimentación que hemos estado recopilando de varios canales (Slack, Discord, Telegram, Twitter y llamadas comunitarias).

Los elementos específicos de retroalimentación que nos preocupaban eran:

¿Hay personas específicas que pueden confirmar el problema? ¿Tenemos una buena comprensión de las preocupaciones subyacentes o la causa raíz? ¿Existe una articulación del impacto del problema, por ejemplo, en términos de dinero, oportunidades, tiempo o energía? ¿Eso hace que el problema sea urgente en comparación con otros problemas? ¿Hay usuarios específicos con los que podemos trabajar para compartir nuestras ideas, reducir el riesgo de soluciones y garantizar una retroalimentación continua? ¿Podemos dar pasos incrementales hacia una solución? Además, también dimos una ligera preferencia a los problemas de victoria rápida y alto impacto.

Esto nos llevó a categorizar los problemas en una tabla. Esto arrojó luz y claridad sobre todos los problemas al compararlos en términos de urgencia, impacto, usuarios, complejidad y esfuerzo.

La tabla a continuación es una captura de pantalla de nuestras notas en bruto durante el ejercicio de priorización. Muestra los problemas principales (más urgentes) para el segundo trimestre. Tenga en cuenta que la columna "Usuario" no es exhaustiva: algunos usuarios no se mencionan para evitar que la tabla se hinche.

La siguiente captura de pantalla también muestra nuestra lista de problemas de la cola de espera actual.

Tanto las prioridades elegidas como la lista de problemas de la cola de espera están alineadas con el tablero del proyecto. La diferencia es que en estas tablas y en nuestras discusiones internas profundizamos más en la evaluación del problema y el espacio de soluciones, al tiempo que capturamos a los usuarios y su impacto.

Pensamientos finales Somos conscientes de que este enfoque para la priorización no es totalmente objetivo. Si hay comentarios o ideas para mejorar, estaríamos encantados de colaborar con la comunidad para perfeccionar nuestra priorización.

Finalmente, estamos ejecutando estas prioridades en paralelo a un trabajo de investigación de varios trimestres sobre bifurcaciones de Tendermint Core y CometBFT (por ejemplo, bifurcaciones de Celestia, Sei, Skip, Numia o Polygon, entre muchas otras). El objetivo de esta investigación es descubrir qué mejoras hicieron otros equipos en sus bifurcaciones que serían apropiadas y deseables para incorporar en CometBFT. Para cada candidato, estamos evaluando su complejidad e impacto. La idea es trabajar con algunos de estos equipos para incorporar cambios en el CometBFT principal, de modo que toda la comunidad pueda beneficiarse de las mejoras correspondientes.