$DUSK Já pratiquei e rodei em muitos nós na prática; o que mais dá trabalho não é tanto o volume de transações disparar, e sim o tipo de “colapso” na base P2P que vira um verdadeiro desastre de broadcast. Antigas blockchains: quando mexe uma coisa, já trava; tudo se resume àquelas velhas e ultrapassadas mecânicas de Gossip. É basicamente envio burro para o grupo inteiro; basta a rede dar uma balançada mínima para o efeito dominó de pacotes perdidos em repetição provocar uma avalanche que inutiliza a memória do servidor na hora.
Depois, ao analisar a base do @Dusk , vi que eles fizeram algumas manobras espertas na arquitetura Kadcast. O projeto não seguiu a velha rota de “alagamento” (broadcast massivo) antigo: ele pega diretamente o algoritmo XOR para desenhar uma malha de distribuição direcionada. Cada dispositivo só precisa cuidar do seu próprio empurrão de dados em uma área pequena. Assim, desde a origem, você impede que toda sorte de lixo de broadcast seja enfiada em rotas fixas. Mesmo que o volume de transações suba de repente, os dados “detritos” nas bordas ainda ficam contidos.
Mas, pelo que eu já fui pisando e quebrando no caminho, mesmo que no papel o plano de redução de carga seja “o máximo”, quando entra no datacenter real tem que fazer concessões. Se você encaixa a topologia por XOR na camada de transporte, parece que um computador comum consegue subir nós; porém o problema é que diariamente tem um bocado de gente derrubando a conexão e desligando. Quando acontece uma queda em massa e o sistema fica para trás, a tabela de roteamento não consegue reagir. Quando realmente rola uma ruptura de rede, consertar essas rotas precisas é bem mais difícil do que com broadcast massivo; além disso, tentar investigar perda de pacotes pode enlouquecer as pessoas. $BTC
Para saber se o “osso” de uma cadeia é realmente bom, não olhe só para os testes de TPS inflados. Tem que ver se a arquitetura aguenta pancada quando tudo desaba no pior cenário. Travar dados pela “distância” matemática e impedir que eles se espalhem de forma caótica é, de fato, um caminho que foca em eficácia. Mas, na prática, em uma operação extremamente errática, será que isso segura? Eu acho que só dá pra saber depois de jogar um tempo com um fluxo enorme de dinheiro e tráfego real batendo forte. #dusk $ETH
Depois, ao analisar a base do @Dusk , vi que eles fizeram algumas manobras espertas na arquitetura Kadcast. O projeto não seguiu a velha rota de “alagamento” (broadcast massivo) antigo: ele pega diretamente o algoritmo XOR para desenhar uma malha de distribuição direcionada. Cada dispositivo só precisa cuidar do seu próprio empurrão de dados em uma área pequena. Assim, desde a origem, você impede que toda sorte de lixo de broadcast seja enfiada em rotas fixas. Mesmo que o volume de transações suba de repente, os dados “detritos” nas bordas ainda ficam contidos.
Mas, pelo que eu já fui pisando e quebrando no caminho, mesmo que no papel o plano de redução de carga seja “o máximo”, quando entra no datacenter real tem que fazer concessões. Se você encaixa a topologia por XOR na camada de transporte, parece que um computador comum consegue subir nós; porém o problema é que diariamente tem um bocado de gente derrubando a conexão e desligando. Quando acontece uma queda em massa e o sistema fica para trás, a tabela de roteamento não consegue reagir. Quando realmente rola uma ruptura de rede, consertar essas rotas precisas é bem mais difícil do que com broadcast massivo; além disso, tentar investigar perda de pacotes pode enlouquecer as pessoas. $BTC
Para saber se o “osso” de uma cadeia é realmente bom, não olhe só para os testes de TPS inflados. Tem que ver se a arquitetura aguenta pancada quando tudo desaba no pior cenário. Travar dados pela “distância” matemática e impedir que eles se espalhem de forma caótica é, de fato, um caminho que foca em eficácia. Mas, na prática, em uma operação extremamente errática, será que isso segura? Eu acho que só dá pra saber depois de jogar um tempo com um fluxo enorme de dinheiro e tráfego real batendo forte. #dusk $ETH