Eu estava analisando a arquitetura do Dusk de forma errada

Achei que a arquitetura antiga do @Dusk só precisava de otimização.

Mas minha percepção estava errada.

Eu percebi que o problema não era simplesmente o motor. Era o blueprint ao redor dele.

A arquitetura anterior do Dusk usava infraestrutura personalizada para suas necessidades. Mas, conforme o ecossistema cresceu, as integrações passaram a exigir mais trabalho customizado, tempo e custo.

Isso me lembrou de uma ponte de pista única. Com pouco tráfego, funciona bem. À medida que cresce, às vezes a ponte precisa ser redesenhada.

Isso me fez pensar: se a arquitetura antiga estava funcionando, por que redesenhá-la?

O novo design separa responsabilidades: o DuskDS cuida do settlement e da disponibilidade de dados, enquanto o DuskVM e o DuskEVM fornecem ambientes de execução.

Aí entendi: claro, o objetivo não era apenas melhorar a arquitetura antiga. Era fazê-la se encaixar no que o Dusk estava se tornando.

Eu vi uma atualização como ajuste do motor. Agora vejo como redesenho do blueprint.

Um sistema pode superar o design que o construiu.

Sistemas em crescimento precisam de uma nova arquitetura, não apenas de melhor desempenho?

$DUSK #dusk

Quando um sistema cresce, o que importa mais?