POR QUÉ DUSK NO HACE QUE UN SOLO NODO HAGA TODO
Hace dos semanas intentaba ahorrar dinero en un VPS. Coloqué mi aplicación principal, las copias de seguridad de la base de datos y un trabajo pesado de procesamiento de imágenes en el mismo servidor pequeño. Parecía eficiente. No lo era. El trabajo de imágenes se iniciaba y, de repente, mi aplicación principal desaparecía las solicitudes.
Ese tonto problema del VPS me vuelve a la mente cuando leo la configuración de nodos de Dusk. Dusk separa el trabajo entre las funciones de Provisioner, Archive y Prover. No son tres nombres elegantes para que una sola máquina haga todo.
Un Provisioner se enfoca en el consenso y necesita al menos 1.000 DUSK en staking. Un Archive Node mantiene el historial finalizado para cosas como "moonlightHistory" y "finalizedEvents". Un Prover se encarga del trabajo más pesado de las pruebas de Zero-Knowledge.
Luego llego al Prover y el problema de hardware cambia de nuevo. Dusk dice que la generación de pruebas es de un solo hilo, así que importa un rendimiento fuerte de un solo núcleo. La infraestructura de Archive tiene un punto de partida diferente: 4 núcleos, 8 GB de RAM, 500 GB de almacenamiento y redes de 100 Mbps.
Y esta es la parte que se siente familiar. Dusk recomienda mantener la infraestructura de API de producción separada de las tareas del Provisioner porque el tráfico de consultas y el mantenimiento pueden competir con el trabajo de consenso. Aprendí lo mismo de la manera molesta en ese VPS.
Ahora miro las tres funciones un poco diferente. Si el consenso, las consultas históricas y la generación de ZK comienzan a pelearse por los mismos recursos, quizá una sola caja haciendo todo no sea realmente la opción más simple.
@Dusk #dusk $DUSK
Hace dos semanas intentaba ahorrar dinero en un VPS. Coloqué mi aplicación principal, las copias de seguridad de la base de datos y un trabajo pesado de procesamiento de imágenes en el mismo servidor pequeño. Parecía eficiente. No lo era. El trabajo de imágenes se iniciaba y, de repente, mi aplicación principal desaparecía las solicitudes.
Ese tonto problema del VPS me vuelve a la mente cuando leo la configuración de nodos de Dusk. Dusk separa el trabajo entre las funciones de Provisioner, Archive y Prover. No son tres nombres elegantes para que una sola máquina haga todo.
Un Provisioner se enfoca en el consenso y necesita al menos 1.000 DUSK en staking. Un Archive Node mantiene el historial finalizado para cosas como "moonlightHistory" y "finalizedEvents". Un Prover se encarga del trabajo más pesado de las pruebas de Zero-Knowledge.
Luego llego al Prover y el problema de hardware cambia de nuevo. Dusk dice que la generación de pruebas es de un solo hilo, así que importa un rendimiento fuerte de un solo núcleo. La infraestructura de Archive tiene un punto de partida diferente: 4 núcleos, 8 GB de RAM, 500 GB de almacenamiento y redes de 100 Mbps.
Y esta es la parte que se siente familiar. Dusk recomienda mantener la infraestructura de API de producción separada de las tareas del Provisioner porque el tráfico de consultas y el mantenimiento pueden competir con el trabajo de consenso. Aprendí lo mismo de la manera molesta en ese VPS.
Ahora miro las tres funciones un poco diferente. Si el consenso, las consultas históricas y la generación de ZK comienzan a pelearse por los mismos recursos, quizá una sola caja haciendo todo no sea realmente la opción más simple.
@Dusk #dusk $DUSK