Sistemas Descentralizados/02 - Web34 min
Web3 e Blockchain
- Que problema isso resolve?
- Quando usar / quando NÃO usar?
- Qual o principal trade-off?
- Como isso falha em produção?
Conceito
Web3 é o termo (cunhado por Gavin Wood, co-fundador do Ethereum, em 2014) para a ideia de uma internet em que o usuário possui seus dados e ativos, sem depender de plataformas. O slogan é "read–write–own".
Slogan de lado, a arquitetura por baixo tem um nome bem estabelecido na literatura, décadas mais antigo que a palavra Web3:
Uma máquina de estados replicada, com tolerância a falhas bizantinas e membresia aberta.
Vale destrinchar os três termos, porque cada um explica um comportamento que de fora parece arbitrário.
1. Máquina de estados replicada
Todos os nós guardam o estado inteiro e re-executam todas as transações, na mesma ordem, chegando ao mesmo resultado. Não é sharding, não é particionamento: é replicação total.
estado_novo = aplicar(estado_antigo, transação)
Se todos partem do mesmo estado e aplicam as mesmas transações na mesma ordem, todos terminam iguais — sem precisar confiar uns nos outros, porque cada um verifica por conta própria. Essa é a ideia central.
O preço: a capacidade do sistema é a capacidade do nó mais fraco que você quer manter capaz de validar. Adicionar nós não adiciona throughput — só redundância.
2. Tolerância a falhas bizantinas (BFT)
Em Raft e Paxos, um nó defeituoso apenas cai ou atrasa. Em blockchain, ele pode mentir deliberadamente: enviar dados diferentes para vizinhos diferentes, forjar histórico, tentar gastar a mesma moeda duas vezes.
Isso muda a matemática. Consenso tolerante a crash precisa de maioria (N/2 + 1); consenso bizantino clássico precisa de mais de 2/3 honestos, e muito mais troca de mensagens.
3. Membresia aberta (permissionless)
E aqui está o problema que blockchain realmente resolveu de novo. BFT clássico (PBFT, 1999) exige saber quem são os N participantes para calcular 2/3. Numa rede aberta, qualquer um cria mil identidades de graça — o ataque Sybil — e o quórum perde sentido.
A solução do Bitcoin foi trocar "contar votos de participantes conhecidos" por "contar recurso escasso":
| Mecanismo | Recurso escasso | Custo de atacar |
|---|---|---|
| Proof of Work | poder computacional | comprar >50% do hashrate + energia |
| Proof of Stake | capital travado no protocolo | comprar >1/3 ou >2/3 do stake, e perdê-lo |
Não é preciso saber quem você é — só provar que você queimou algo real. É essa peça, e não o "banco de dados imutável", que era a novidade.
A pilha Web3
| Camada | Função | Exemplos |
|---|---|---|
| Consenso (L1) | ordem e finalidade | Bitcoin, Ethereum, Solana |
| Execução | rodar código sobre o estado | EVM, smart contracts |
| Escala (L2) | processar fora e provar na L1 | rollups (Arbitrum, Optimism, zk) |
| Armazenamento | arquivos grandes fora da cadeia | IPFS, Arweave |
| Identidade | chaves e nomes | carteiras, ENS, DIDs |
| Indexação | consultar o estado | The Graph, provedores de RPC |
A camada de indexação existir é sintomática: um blockchain é ótimo para escrever de forma verificável e péssimo para consultar. Não tem índice, não tem query, não tem join. Toda aplicação real precisa de um indexador — normalmente um Postgres — do lado.
Trade-offs
O trade-off que resume tudo:
Um fator de replicação de milhares de nós não é design de escalabilidade — é design de integridade.
Você não replica para ir mais rápido; replica para que ninguém consiga mentir sozinho. Por isso os números parecem absurdos comparados a um banco comum:
| Sistema | Throughput | Latência até "definitivo" | Custo por escrita |
|---|---|---|---|
| Bitcoin | ~7 tx/s | ~1h (6 blocos, probabilístico) | taxa de rede |
| Ethereum L1 | dezenas de tx/s | ~13 min (finalidade) | gas em $ |
| Postgres, 1 máquina | dezenas de milhares/s | ms | ~0 |
A comparação é injusta de propósito: os sistemas resolvem problemas diferentes. Se existe um operador aceitável, o Postgres ganha por várias ordens de grandeza. Web3 só é a ferramenta certa quando não existe operador aceitável — partes que se desconfiam mutuamente precisando de um livro-razão compartilhado, sem árbitro.
Os outros custos, todos estruturais:
- Imutabilidade — não dá para apagar. Conflita com LGPD/GDPR e com "escrevi errado".
- Transparência total — todo estado é público. Privacidade exige criptografia por cima, não vem de graça.
- Custo por byte — modelagem de dados vira otimização de gas, o que distorce o design.
- Gestão de chave — perdeu a chave privada, perdeu o ativo. Sem recuperação, sem suporte.
Exemplo prático
A centralização das bordas. É o padrão mais instrutivo de Web3 na prática.
O contrato é imutável e sem dono. Mas rodar um nó completo custa disco e banda, então quase todo dApp fala com um punhado de provedores de RPC (Infura, Alchemy). O frontend está na Vercel, o DNS na Cloudflare, a carteira é a MetaMask, e o token é comprado numa exchange centralizada.
Resultado: o backend é resistente à censura e a porta de entrada não é. Se a Infura cai, metade do ecossistema "descentralizado" para.
Isso não invalida a tecnologia — mas ensina uma lei geral de arquitetura, que vale muito além de cripto: a descentralização vaza no ponto de menor esforço do usuário. Se validar por conta própria é caro e confiar num provedor é grátis, o sistema vai reconcentrar sozinho, sem ninguém decidir isso.
Relacionado
- 2. Consenso e Finalidade
- 3. Limites do Web3
- 2. Tipos de Sistemas Distribuídos
- 1. Nostr vs Blockchain
Parte de MOC Web3 · ethereum.org/developers