Desta vez, ao ler a documentação de desenvolvimento do Dusk, não foi o ZK, nem a privacidade, o que realmente me fez parar.
Foi um detalhe bem pequeno de uma interface:
**O nó informa ao cliente a própria versão do Rusk, e o cliente também pode solicitar ativamente um intervalo de versões.**
Se a versão não for compatível, simplesmente recusa.
À primeira vista, isso não tem nada a ver com a grande narrativa das blockchains.
Mas quando eu coloquei isso dentro de um fluxo real de desenvolvimento, achei bem interessante.
Porque o que muitos aplicativos on-chain temem não é só uma interface mais lenta.
E sim:
Hoje funciona, mas depois de um upgrade, de repente começam a aparecer situações como “alguns nós reconhecem, outros não”.
Se o desenvolvedor não souber exatamente qual versão está rodando no nó ao qual ele está se conectando, fica muito difícil determinar se o problema vem do código, do nó, ou do próprio protocolo.
Agora, o Dusk coloca essas informações de versão diretamente na resposta HTTP, e também permite que o cliente faça um check estrito de versão (strict version check).
Antes, eu estava mais acostumado a avaliar se um L1 é utilizável olhando para TPS e para a finalidade (finalidade).
Agora, porém, passei a achar que essas pequenas regras na camada de interface deixam mais evidente se uma rede realmente considerou os problemas que os desenvolvedores de fato vão enfrentar.
Porque a infraestrutura não teme a complexidade.
O que ela teme é a **incerteza**.
Se um aplicativo depende de uma capacidade de um nó, e após o upgrade o comportamento do nó muda, o infortúnio maior muitas vezes não recai sobre a equipe do protocolo — e sim sobre os aplicativos que já estão em produção.
Então, essa “gestão de versão” que parece tão, digamos, de engenheiro, na verdade resolve um problema bem real:
Fazer com que o desenvolvedor saiba com que conjunto de regras de protocolo ele está falando.
Esse é também um ponto do Dusk que eu acho que vale a pena estudar agora.
Um L1 realmente maduro não é apenas “fazer a cadeia rodar”.
Tem também que deixar claro, para quem vai se conectar depois, onde estão os limites.
#dusk $DUSK @Dusk
Foi um detalhe bem pequeno de uma interface:
**O nó informa ao cliente a própria versão do Rusk, e o cliente também pode solicitar ativamente um intervalo de versões.**
Se a versão não for compatível, simplesmente recusa.
À primeira vista, isso não tem nada a ver com a grande narrativa das blockchains.
Mas quando eu coloquei isso dentro de um fluxo real de desenvolvimento, achei bem interessante.
Porque o que muitos aplicativos on-chain temem não é só uma interface mais lenta.
E sim:
Hoje funciona, mas depois de um upgrade, de repente começam a aparecer situações como “alguns nós reconhecem, outros não”.
Se o desenvolvedor não souber exatamente qual versão está rodando no nó ao qual ele está se conectando, fica muito difícil determinar se o problema vem do código, do nó, ou do próprio protocolo.
Agora, o Dusk coloca essas informações de versão diretamente na resposta HTTP, e também permite que o cliente faça um check estrito de versão (strict version check).
Antes, eu estava mais acostumado a avaliar se um L1 é utilizável olhando para TPS e para a finalidade (finalidade).
Agora, porém, passei a achar que essas pequenas regras na camada de interface deixam mais evidente se uma rede realmente considerou os problemas que os desenvolvedores de fato vão enfrentar.
Porque a infraestrutura não teme a complexidade.
O que ela teme é a **incerteza**.
Se um aplicativo depende de uma capacidade de um nó, e após o upgrade o comportamento do nó muda, o infortúnio maior muitas vezes não recai sobre a equipe do protocolo — e sim sobre os aplicativos que já estão em produção.
Então, essa “gestão de versão” que parece tão, digamos, de engenheiro, na verdade resolve um problema bem real:
Fazer com que o desenvolvedor saiba com que conjunto de regras de protocolo ele está falando.
Esse é também um ponto do Dusk que eu acho que vale a pena estudar agora.
Um L1 realmente maduro não é apenas “fazer a cadeia rodar”.
Tem também que deixar claro, para quem vai se conectar depois, onde estão os limites.
#dusk $DUSK @Dusk
