Tenho pensado numa coisa: o mais difícil na blockchain e na rede descentralizada não é o início. Na altura, com poucos dados, tudo parecia fácil de resolver. O verdadeiro problema surge quando os dados acumulam até um certo nível.
À medida que os dados históricos se tornam cada vez mais pesados, as recompensas se fragmentam cada vez mais, e os operadores capazes de suportar toda a carga não aumentam de número, o sistema começa a tender inconscientemente para a centralização. Isto não é uma conspiração por parte de alguém, mas uma inevitabilidade do próprio funcionamento da economia e da arquitetura.
O meu objetivo principal com o projeto WAL é exatamente isso: provar que uma quantidade massiva de dados pode ser suportada sem depender de forças centralizadas. Isto é, na essência, uma questão de design económico, e não de desempenho.
**Quanto mais pesados os dados, mais longas as mãos da centralização**
Muitas redes acabam por se tornar centralizadas, e a razão é simples — os dados tornam-se demasiado pesados. Os custos de armazenamento disparam, e cada vez há menos nós capazes de sincronizar toda a cadeia de dados. O direito de validar não é algo que alguém roube à força, mas concentra-se naturalmente nas mãos daqueles grandes jogadores com capital e recursos.
À primeira vista, a rede ainda funciona normalmente, os blocos continuam a ser criados, e os dados podem ser consultados. Mas se quer verificar uma transação? Desculpe, só alguns grandes operadores podem realmente validar — onde fica a descentralização aí? Na minha opinião, isto não é uma concessão, é uma falha de design.
**Sharding é a chave, não é preciso que todos armazenem tudo**
A abordagem tradicional é a cópia completa: cada nó mantém uma cópia integral dos dados, confiando na redundância para segurança. No início, parece estável, mas à medida que os dados crescem, este método tende a favorecer aqueles operadores com recursos abundantes — os pequenos nós simplesmente não conseguem acompanhar os custos de hardware.
Ver original
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
Tenho pensado numa coisa: o mais difícil na blockchain e na rede descentralizada não é o início. Na altura, com poucos dados, tudo parecia fácil de resolver. O verdadeiro problema surge quando os dados acumulam até um certo nível.
À medida que os dados históricos se tornam cada vez mais pesados, as recompensas se fragmentam cada vez mais, e os operadores capazes de suportar toda a carga não aumentam de número, o sistema começa a tender inconscientemente para a centralização. Isto não é uma conspiração por parte de alguém, mas uma inevitabilidade do próprio funcionamento da economia e da arquitetura.
O meu objetivo principal com o projeto WAL é exatamente isso: provar que uma quantidade massiva de dados pode ser suportada sem depender de forças centralizadas. Isto é, na essência, uma questão de design económico, e não de desempenho.
**Quanto mais pesados os dados, mais longas as mãos da centralização**
Muitas redes acabam por se tornar centralizadas, e a razão é simples — os dados tornam-se demasiado pesados. Os custos de armazenamento disparam, e cada vez há menos nós capazes de sincronizar toda a cadeia de dados. O direito de validar não é algo que alguém roube à força, mas concentra-se naturalmente nas mãos daqueles grandes jogadores com capital e recursos.
À primeira vista, a rede ainda funciona normalmente, os blocos continuam a ser criados, e os dados podem ser consultados. Mas se quer verificar uma transação? Desculpe, só alguns grandes operadores podem realmente validar — onde fica a descentralização aí? Na minha opinião, isto não é uma concessão, é uma falha de design.
**Sharding é a chave, não é preciso que todos armazenem tudo**
A abordagem tradicional é a cópia completa: cada nó mantém uma cópia integral dos dados, confiando na redundância para segurança. No início, parece estável, mas à medida que os dados crescem, este método tende a favorecer aqueles operadores com recursos abundantes — os pequenos nós simplesmente não conseguem acompanhar os custos de hardware.