Sistemas Descentralizados/02 - Web34 min
Limites do Web3
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Esta nota existe para separar limite estrutural de limitação temporária. A distinção é o que permite avaliar a tecnologia sem torcida: alguns problemas somem com engenharia, outros são o preço do modelo e nunca vão sumir.
O trilema de escalabilidade
Formulado por Vitalik Buterin: uma cadeia quer descentralização, segurança e escalabilidade, e consegue duas bem.
| Prioriza | Sacrifica | Como fica |
|---|---|---|
| Descentralização + segurança | escala | Bitcoin, Ethereum L1 — lentos e caros |
| Escala + segurança | descentralização | poucos validadores potentes |
| Escala + descentralização | segurança | barato de atacar |
A raiz é aquela de 1. Web3 e Blockchain: se todo nó valida tudo, aumentar o volume aumenta o custo de participar, e nós menores desistem. Descentralização morre pelo custo de entrada, não por decisão de ninguém.
É por isso que a saída da indústria foi L2 / rollups: executar fora da cadeia e publicar na L1 apenas uma prova de que a execução foi correta. Isso muda o que o nó valida — de "re-executar tudo" para "verificar uma prova pequena" — e é uma mudança estrutural real, não um truque de marketing.
Limites que são estruturais
Estes não têm conserto, porque são o próprio modelo:
Imutabilidade vs. mundo real. Não dá para apagar. Direito ao esquecimento (LGPD/GDPR), conteúdo ilegal publicado por terceiros, e o simples "digitei o endereço errado" não têm solução. As mitigações são todas indiretas: guardar só o hash na cadeia, guardar o dado fora, aceitar que erro é definitivo.
Transparência total. Todo estado é público e para sempre. Análise de cadeia liga endereços a pessoas com facilidade desconfortável. Privacidade exige criptografia por cima (zk), com custo próprio.
Oráculos. A cadeia só sabe o que está nela. Qualquer fato do mundo — cotação, resultado de jogo, entrega feita — precisa ser inserido por alguém. Esse alguém é um ponto de confiança, e o smart contract "sem confiança" acaba dependendo dele. O problema do oráculo é o furo mais explorado na prática.
Gestão de chave. Não há recuperação de conta. Isso não é um bug de UX a ser corrigido: é a consequência direta de "identidade é uma chave, não uma linha em banco de dados". Mitigações (multisig, social recovery, account abstraction) melhoram muito, e todas funcionam reintroduzindo alguma confiança em terceiros.
Custo de coordenação social. Mudar as regras exige convencer mineradores, validadores, exchanges e usuários. Um bug crítico não é corrigido com deploy — é corrigido com política, às vezes com cisão da rede.
Limites que são temporários
- Throughput e taxa — melhoram muito com rollups, blobs, PoS.
- UX de carteira — melhora com account abstraction e passkeys.
- Ferramental — indexação, debugging, testes amadureceram bastante.
Trade-offs
O trade-off honesto, e o único critério que realmente importa na hora de escolher:
Blockchain troca desempenho por eliminação do operador confiável.
Se você tem um operador aceitável — sua empresa, um consórcio, um cartório, um banco central — você está pagando a conta e não levando o produto. Um banco de dados comum com log de auditoria e assinatura digital te dá 95% das propriedades desejadas por 0,001% do custo.
O critério de decisão cabe numa pergunta: "existe alguma parte em quem todos os envolvidos aceitariam confiar?" Se sim, blockchain é a escolha errada. Foi essa pergunta que derrubou a maior parte dos projetos de "blockchain corporativo" de 2018–2021 — havia operador aceitável, e todo mundo sabia disso.
Exemplo prático
Rastreabilidade de cadeia de suprimentos em blockchain — o caso de uso corporativo mais vendido, e um bom exercício de ceticismo.
A promessa: registrar cada etapa do café, da fazenda à xícara, de forma imutável.
O furo: quem digita "colhido na fazenda X em tal data" é uma pessoa, com um celular. Se ela mentir, a mentira é gravada imutavelmente para sempre. A cadeia garante que o registro não foi alterado depois — nunca que ele era verdadeiro antes.
Ou seja: o sistema resolve com enorme custo um problema (adulteração posterior do registro) que quase nunca é o gargalo, e não toca no problema real (entrada de dados falsa na origem). Um banco relacional com log assinado e append-only entregaria a mesma garantia.
Isso é o teste que vale aplicar a qualquer proposta de Web3: onde está a confiança que sobrou? Se ela continua num humano na ponta, a descentralização do meio não comprou nada.
Relacionado
Parte de MOC Web3 · ethereum.org — scaling