POR QUE O DUSK NÃO FAZ UM NÓ FAZER TUDO
Há duas semanas eu tentava economizar em um VPS. Coloquei meu app principal, backups do banco de dados e um trabalho pesado de processamento de imagens no mesmo servidor pequeno. Parecia eficiente. Não era. O job de imagens começava e, de repente, meu app principal ficava sem requisições.
Esse chato problema do VPS volta na minha cabeça quando eu leio a configuração de nós do Dusk. O Dusk separa o trabalho entre as funções Provisioner, Archive e Prover. Elas não são apenas nomes sofisticados para uma única máquina fazendo tudo.
Um Provisioner foca em consenso e precisa ter pelo menos 1.000 DUSK em stake. Um Archive Node mantém o histórico finalizado para coisas como "moonlightHistory" e "finalizedEvents". Um Prover lida com o trabalho mais pesado de provas de Zero-Knowledge.
Aí chego no Prover e o problema de hardware muda de novo. O Dusk diz que a geração de provas é single-threaded, então um desempenho forte em um único núcleo importa bastante. A infraestrutura do Archive parte de outro ponto: 4 núcleos, 8 GB de RAM, 500 GB de armazenamento e rede de 100 Mbps.
E é aqui que a coisa fica familiar. O Dusk recomenda manter a infraestrutura de API de produção separada das funções do Provisioner porque o tráfego de consultas e a manutenção podem competir com o trabalho de consenso. Eu aprendi a mesma lição do jeito chato no tal VPS.
Agora estou olhando para essas três funções de um jeito um pouco diferente. Se consenso, consultas históricas e o proving de ZK começarem a brigar pelos mesmos recursos, talvez uma única máquina fazendo tudo não seja, na verdade, a opção mais simples.
@Dusk #dusk $DUSK
Há duas semanas eu tentava economizar em um VPS. Coloquei meu app principal, backups do banco de dados e um trabalho pesado de processamento de imagens no mesmo servidor pequeno. Parecia eficiente. Não era. O job de imagens começava e, de repente, meu app principal ficava sem requisições.
Esse chato problema do VPS volta na minha cabeça quando eu leio a configuração de nós do Dusk. O Dusk separa o trabalho entre as funções Provisioner, Archive e Prover. Elas não são apenas nomes sofisticados para uma única máquina fazendo tudo.
Um Provisioner foca em consenso e precisa ter pelo menos 1.000 DUSK em stake. Um Archive Node mantém o histórico finalizado para coisas como "moonlightHistory" e "finalizedEvents". Um Prover lida com o trabalho mais pesado de provas de Zero-Knowledge.
Aí chego no Prover e o problema de hardware muda de novo. O Dusk diz que a geração de provas é single-threaded, então um desempenho forte em um único núcleo importa bastante. A infraestrutura do Archive parte de outro ponto: 4 núcleos, 8 GB de RAM, 500 GB de armazenamento e rede de 100 Mbps.
E é aqui que a coisa fica familiar. O Dusk recomenda manter a infraestrutura de API de produção separada das funções do Provisioner porque o tráfego de consultas e a manutenção podem competir com o trabalho de consenso. Eu aprendi a mesma lição do jeito chato no tal VPS.
Agora estou olhando para essas três funções de um jeito um pouco diferente. Se consenso, consultas históricas e o proving de ZK começarem a brigar pelos mesmos recursos, talvez uma única máquina fazendo tudo não seja, na verdade, a opção mais simples.
@Dusk #dusk $DUSK