Contar nós, medir hashrate ou observar quem escreve o software revela partes diferentes do problema. Para entender a descentralização do Bitcoin, precisamos localizar funções, dependências e poderes concretos — e resistir à tentação de resumir tudo em um único número.
“Descentralizado” virou uma palavra que muitas vezes encerra a conversa antes de ela começar. No debate sobre Bitcoin, basta alguém dizer que não existe banco central, que qualquer pessoa pode rodar um nó ou que os mineradores estão espalhados por vários países para a questão parecer resolvida. Do outro lado, também aparecem conclusões rápidas: se poucos pools produzem grande parte dos blocos, se há fabricantes dominantes de equipamentos ou se uma implementação de software é muito utilizada, então toda a descentralização seria apenas aparência.
Essas posições chegam a conclusões opostas pelo mesmo caminho. Tratam a descentralização como uma característica única, que a rede teria em maior ou menor quantidade.
Mas uma rede complexa não distribui todas as suas funções da mesma maneira. A validação pode ser independente e, ao mesmo tempo, a fabricação de equipamentos pode permanecer concentrada. Também podemos ter regras que nenhum administrador consegue alterar sozinho, enquanto muitos usuários acessam o sistema por meio de poucas empresas custodiais. Em outro nível, milhares de máquinas podem executar software semelhante sem que isso corresponda a milhares de centros independentes de decisão econômica.
Por isso, perguntar simplesmente se “o Bitcoin é descentralizado” é começar pelo fim. Antes, precisamos descobrir o que está sendo descentralizado, entre quem e com qual efeito prático.
É essa mudança de pergunta que orienta este artigo. Não vamos procurar um selo para declarar o Bitcoin centralizado ou descentralizado. Vamos tentar construir um mapa: quais poderes estão distribuídos, onde aparecem concentrações, que dependências permanecem e quanto custa escapar delas.
O desenho da rede é só o começo
Uma referência histórica recorrente nesse debate é o trabalho de Paul Baran sobre redes de comunicação distribuídas, publicado na década de 1960. Baran estudava como uma rede poderia continuar funcionando mesmo quando parte de sua infraestrutura fosse destruída. A forma de conexão entre os pontos importava porque uma arquitetura dependente de um centro único apresentava um tipo de fragilidade diferente de uma estrutura em que as mensagens pudessem encontrar caminhos alternativos.
Essa distinção continua útil, mas precisa ser colocada no lugar certo.
O desenho de uma rede diz muito sobre comunicação, redundância e pontos de falha. Não diz, sozinho, quem possui os equipamentos, quem consegue alterar o software, quem domina o conhecimento técnico, quem controla a liquidez ou quem decide as condições de acesso dos usuários.
Duas redes podem ter topologias parecidas e relações de poder muito diferentes. Também podemos distribuir máquinas sem distribuir decisões. E uma organização pode possuir mecanismos democráticos de decisão enquanto depende de uma infraestrutura física concentrada em poucos fornecedores.
É por isso que não devemos transformar o conhecido contraste entre redes centralizadas, descentralizadas e distribuídas numa teoria automática de poder social. A topologia é uma dimensão do problema, não sua conclusão.
Quando a topologia não basta
Além disso, pesquisas empíricas sobre criptomoedas chegaram a dificuldade semelhante. Em 2018, Adem Efe Gencer e coautores estudaram Bitcoin e Ethereum por diferentes critérios: recursos dos nós, interconexão, requisitos operacionais e resistência a ataques, entre outros. Os números daquele estudo pertencem a um período específico e não devem ser usados como fotografia da rede em 2026. O ponto que permanece útil é metodológico: o resultado muda conforme a dimensão observada.
Um trabalho qualitativo mais recente, de Alexander Lynham e Geoffrey Goodell, chegou a outra formulação interessante a partir de entrevistas com operadores de nós: os participantes frequentemente distinguiam a topologia da rede da topologia da governança, isto é, a forma de conexão técnica da distribuição do poder de decisão. O estudo não fornece uma definição universal de descentralização, mas reforça a necessidade de dizer exatamente do que estamos falando.
Antes de contar, precisamos saber o que estamos contando
Métricas são necessárias. O problema começa quando a métrica perde sua pergunta original e passa a representar a rede inteira.
Para evitar isso, podemos submeter qualquer afirmação sobre descentralização a cinco perguntas simples.
- Qual função estamos observando? Comunicação entre pares, validação, produção de blocos, desenvolvimento de software, custódia, liquidez e fabricação de hardware são atividades diferentes.
- Qual é a unidade real que está sendo contada? Máquinas, endereços, empresas, pessoas, pools e instalações físicas não são equivalentes. Várias instâncias técnicas podem pertencer ao mesmo ator, e um único serviço pode representar milhões de usuários.
- Que poder aquela posição permite exercer? Propor uma mudança é diferente de mesclar código; validar é diferente de produzir blocos; custodiar chaves é diferente de possuir hashrate; controlar liquidez não é o mesmo que alterar regras de consenso.
- Quanto custa sair daquela dependência? Poder trocar de pool, custodiante, implementação ou fornecedor só limita de fato um centro de poder quando existem alternativas utilizáveis e o custo da mudança não torna a saída apenas formal.
- Contra qual risco estamos tentando nos descentralizar? Queda de servidor, censura, captura de desenvolvimento, concentração econômica, dependência industrial e vigilância exigem respostas diferentes.
Essas perguntas não eliminam a necessidade de números. Fazem o contrário: ajudam a impedir que um número responda por algo que ele não mede.
Validação: poder de recusar não é poder de comandar
No Artigo 04 discutimos em detalhe o que um nó completo faz e por que rodá-lo amplia autonomia de verificação sem produzir, por si só, soberania econômica.
Aqui basta recuperar uma distinção.
Um full node verifica blocos e transações segundo as regras executadas localmente. A documentação do Bitcoin descreve os nós completos como participantes que baixam e verificam blocos e transações antes de retransmiti-los. Isso permite ao operador deixar de depender integralmente da palavra de um servidor externo para saber se aquilo que recebeu obedece às regras que decidiu aceitar.
Essa capacidade é importante para a descentralização da validação. Não existe uma autoridade central cuja aprovação seja necessária para um participante verificar a cadeia.
Mas validar não significa comandar os demais. Um nó consegue rejeitar localmente um bloco que considera inválido; ele não transforma essa rejeição em ordem para os outros participantes. Tampouco existe uma relação simples de “um nó, um voto”. A mesma pessoa ou empresa pode operar diversas instâncias, enquanto muitos usuários podem não operar nenhuma.
Por isso, a contagem de nós pode ajudar a estudar alcance, conectividade e distribuição da capacidade de validação, mas não responde sozinha quem produz blocos, quem possui infraestrutura, quem controla liquidez ou quem exerce influência no desenvolvimento.
Por isso, até o número de nós exige contexto metodológico. O Bitnodes, por exemplo, utiliza um crawler que descobre participantes da rede por meio de mensagens do protocolo e procura estimar seu tamanho. Esse procedimento produz informação útil, mas não transforma cada endereço observado em uma pessoa, empresa ou centro independente de decisão. A medição técnica precisa continuar ligada ao que efetivamente mede.
Mineração: hashrate, pool e construção do bloco não são a mesma coisa
A mineração talvez seja o melhor exemplo de como uma única estatística pode esconder funções diferentes.
Painéis públicos costumam mostrar a parcela de blocos atribuída a diferentes pools. Essa distribuição importa. Pools coordenam trabalho, recebem provas parciais dos participantes e organizam pagamentos. Dependendo do protocolo utilizado, também podem possuir influência direta sobre o conteúdo dos blocos que seus participantes tentam produzir.
Mas o nome do pool associado a um bloco não identifica automaticamente o proprietário de todas as máquinas que contribuíram com aquele trabalho computacional.
Mineradores podem reunir hashrate em pools justamente para reduzir a variação de receita. Uma instalação no Texas, outra no Paraguai e uma terceira operada por uma empresa diferente podem aparecer sob o mesmo coordenador. Isso não torna a concentração do pool irrelevante; apenas mostra que coordenação e propriedade do hardware são coisas diferentes.
Além disso, também precisamos separar outras funções. Quem fornece o hashrate? Como é definido o método de pagamento? A montagem do conjunto de transações candidatas fica sob responsabilidade de quem? E a infraestrutura física, quem opera? Por fim, o participante consegue mudar de coordenador sem interromper a atividade?
O que o Stratum V2 redistribui
O Stratum V2 torna essa decomposição particularmente visível. Em configurações que utilizam seu Job Declaration Protocol, o minerador pode construir um trabalho personalizado e escolher transações, em vez de receber necessariamente do pool todo o conteúdo do bloco. A documentação do protocolo apresenta justamente essa característica como uma forma de evitar que o pool imponha unilateralmente o trabalho aos mineradores que se conectam a ele.
Isso não “resolve a centralização da mineração”. Seria exagerado dizer isso. O que a mudança faz é redistribuir uma função específica: parte do poder sobre a construção do bloco pode sair do operador do pool e voltar para quem fornece o trabalho computacional.
Esse exemplo ajuda a perceber por que frases como “quatro pools controlam a mineração” precisam de complemento. Controlam o quê? Em que protocolo? Possuem as máquinas ou coordenam trabalho alheio? Escolhem as transações? Custodiam pagamentos? Qual é a facilidade de migração dos participantes?
Se olharmos apenas para a participação dos pools nos blocos, podemos detectar uma concentração relevante e ainda não saber quem possui os meios físicos de mineração. Se olharmos apenas para a localização das máquinas, podemos perder um centro de coordenação capaz de afetar a seleção de transações. As duas medidas são importantes porque descrevem poderes diferentes.
E há uma dimensão temporal. Uma distribuição observada durante sete dias é uma fotografia, não uma estrutura eterna. Pools ganham e perdem participantes, mineradores migram e tecnologias mudam. Ao mesmo tempo, dizer que “eles podem simplesmente mudar de pool” não basta. A possibilidade de saída só disciplina um centro quando a migração é tecnicamente viável, economicamente suportável e existem alternativas reais.
Desenvolvimento: software aberto não significa ausência de poder
A discussão sobre desenvolvedores costuma oscilar entre dois extremos. De um lado, “os desenvolvedores controlam o Bitcoin porque escrevem o código”. De outro, “os desenvolvedores não controlam nada porque qualquer pessoa pode executar outra versão”.
Nenhuma das duas frases descreve bem o processo.
Bitcoin Core é um projeto de software aberto. Qualquer pessoa pode estudar o código, testar, revisar e propor alterações. Isso não significa que todas as funções dentro do projeto sejam idênticas. A documentação atual de contribuição reconhece a existência de mantenedores do repositório, responsáveis por tarefas como mesclar pull requests, participar do ciclo de lançamento e moderar o projeto.
Esse é um poder real. Decidir o que é incorporado a uma implementação amplamente utilizada importa.
Projeto de software não é consenso da rede
Mas o próprio processo do Bitcoin Core faz uma separação explícita entre decisões sobre o projeto de software e mudanças nas regras de consenso do protocolo da rede. Alterações que pretendem modificar o consenso exigem discussão muito mais ampla, revisão adicional e coordenação com participantes externos ao repositório. O fato de um trecho de código entrar numa versão do Bitcoin Core não obriga automaticamente a rede inteira a reconhecê-lo como nova regra.
O processo de BIPs ajuda a enxergar essa diferença. O BIP 3, que atualmente organiza esse processo, deixa claro que os editores exercem funções administrativas e editoriais e não decidem se uma proposta será adotada pelo Bitcoin. Não existe um conselho que transforme a publicação de uma BIP em regra da rede por votação interna.
Por outro lado, isso também não significa ausência de hierarquias informais.
Conhecimento técnico, reputação, disponibilidade para revisar código, domínio histórico de determinadas partes da implementação e capacidade de participar continuamente das discussões são recursos distribuídos de maneira desigual. Uma pessoa que acompanha o desenvolvimento diariamente possui condições de influência diferentes das de um usuário que apenas instala uma carteira pronta.
A formulação mais precisa, portanto, não é dizer que desenvolvedores “mandam” ou “não mandam”. É separar os poderes: propor código, revisar, mesclar, lançar software, convencer participantes a atualizar e alterar regras efetivamente reconhecidas pela rede são etapas distintas.
A descentralização aparece justamente no intervalo entre essas etapas. Nenhuma delas, isoladamente, garante controle sobre todas as outras.
Custódia: uma rede distribuída pode ser usada por portas de entrada concentradas
A forma como o protocolo funciona não determina automaticamente a forma como as pessoas o utilizam.
Uma pessoa que mantém as próprias chaves possui uma relação diferente com a rede daquela que enxerga apenas um saldo numa corretora. No segundo caso, a empresa controla as chaves e oferece ao cliente uma promessa de disponibilidade do saldo segundo suas regras, procedimentos e infraestrutura.
O Artigo 03 já discutiu com mais profundidade a diferença entre controle técnico, propriedade e infraestrutura. Não precisamos refazer essa discussão aqui. Para o problema da descentralização, interessa observar outra coisa: muitos usuários podem se concentrar operacionalmente atrás de poucos intermediários.
Isso cria uma situação aparentemente contraditória, mas perfeitamente possível. A camada de validação pode continuar aberta e distribuída enquanto a camada de acesso cotidiano se recentraliza.
Uma corretora não passa a controlar as regras de consenso só porque possui muitos clientes. Mas ela pode decidir quais saques processa, que endereços aceita, quais funcionalidades disponibiliza, quais informações coleta e em que condições o usuário consegue retirar seus fundos. São poderes diferentes do poder protocolar, mas são poderes reais.
Aqui aparece outra distinção importante: “qualquer pessoa pode fazer” não significa “muitas pessoas conseguem ou escolhem fazer”. A autocustódia pode existir como possibilidade técnica e, ainda assim, a experiência social dominante ser intermediada.
Se queremos avaliar a descentralização do acesso, precisamos observar práticas de custódia, custos, conhecimento necessário, liquidez e dependência de interfaces — não apenas as propriedades da camada base.
Poder econômico não é consenso, mas também não é irrelevante
Outro erro recorrente aparece quando tentamos resolver a discussão separando completamente protocolo e economia.
É correto afirmar que possuir muitos bitcoins não concede a alguém o direito de produzir um bloco inválido e obrigar um nó independente a aceitá-lo. O Bitcoin não funciona como uma empresa em que unidades monetárias correspondem diretamente a votos sobre as regras de consenso.
Mas daí não segue que concentração econômica seja politicamente ou institucionalmente irrelevante.
Capital permite financiar infraestrutura, desenvolvimento, custódia, aquisição de equipamentos, lobbying regulatório, campanhas, serviços e operações de mercado. Grandes agentes econômicos também podem concentrar liquidez e funcionar como pontos importantes de conversão entre bitcoin, moedas estatais e outros ativos. Nada disso deve ser confundido com poder de reescrever as regras de validação. Também não deveria desaparecer da análise apenas porque pertence a outra camada.
Nesse sentido, essa distinção é importante para o método que estamos construindo. O objetivo não é somar todos os tipos de poder numa categoria vaga e concluir que “quem tem dinheiro controla a rede”. É identificar como poderes econômicos podem influenciar condições de acesso, coordenação e infraestrutura sem se transformarem automaticamente em autoridade protocolar.
Uma rede pode ser resistente a alterações unilaterais de suas regras e continuar inserida numa economia marcada por propriedade desigual, concentração de capital e diferenças profundas de capacidade material entre os participantes.
Descentralização técnica não cancela essas relações. Também não precisa ser descartada porque não as resolve.
A infraestrutura material reaparece
O software pode ser copiado. A rede, não.
Para existir, Bitcoin depende de máquinas, armazenamento, eletricidade, conectividade, semicondutores, sistemas de resfriamento, cabos, centros de dados, instalações de mineração e cadeias industriais distribuídas pelo mundo.
Essa camada costuma desaparecer da percepção porque o protocolo aparece na tela como software. Mas nenhuma rede digital existe fora da matéria.
Aqui, novamente, o objetivo não é repetir a discussão geral sobre infraestrutura do Artigo 03. A pergunta é mais estreita: uma dependência material cria um ponto de concentração capaz de bloquear, encarecer ou condicionar determinada função?
Suponha que a mineração esteja distribuída entre muitas empresas, mas dependa de poucos fabricantes de ASICs — equipamentos especializados em executar os cálculos do proof-of-work. Isso cria um tipo de concentração industrial diferente da concentração de pools. Se vários nós são operados por pessoas distintas, mas uma parcela relevante depende de um pequeno número de provedores de hospedagem, surge outro tipo de dependência. Se uma carteira pode ser substituída facilmente, o poder daquele fornecedor é diferente do poder de um componente cujo substituto exige anos de investimento industrial.
É por isso que substituibilidade importa tanto quanto quantidade.
Quantos fornecedores existem? Eles realmente produzem alternativas independentes? Quanto tempo e dinheiro seriam necessários para mudar? A substituição exige apenas instalar outro programa ou construir uma nova fábrica? Uma dependência não se torna absoluta só porque existem poucos fornecedores, mas seu custo de saída ajuda a medir o poder associado à posição que eles ocupam.
Essa pergunta também impede que “descentralização” vire sinônimo de dispersão geográfica. Ter equipamentos em muitos países pode reduzir alguns riscos jurisdicionais e físicos. Não diz, por si só, se todos dependem da mesma cadeia de suprimentos, do mesmo fabricante ou do mesmo serviço de coordenação.
Por que um único índice tende a dizer menos do que parece
A vontade de resumir tudo isso num número é compreensível. Seria muito mais simples afirmar que uma rede possui, por exemplo, “8 de 10 em descentralização”. O problema é que a precisão seria em grande parte estética.
Uma métrica baseada em número de nós privilegia validação e conectividade. Uma métrica de hashrate observa capacidade computacional aplicada à mineração. Participação de pools mede uma forma de coordenação. Número de contribuidores aproxima-se do desenvolvimento de software, mas não mede automaticamente influência. Dados de custódia descrevem outra camada. Concentração patrimonial descreve outra.
Além disso, mesmo dentro de uma única dimensão, a unidade escolhida muda o resultado. Dez mil máquinas podem pertencer a cem operadores. Cem endereços podem pertencer a uma empresa. Uma empresa pode atender milhões de usuários. Uma parcela de hashrate pode mudar de pool sem que a propriedade física de uma única máquina seja alterada.
O período observado também importa. Uma concentração temporária pode desaparecer. Uma dependência industrial pode persistir durante anos. Uma mudança técnica pode redistribuir uma função enquanto outra camada se concentra por motivos econômicos.
Por isso, abordagens multidimensionais são menos elegantes e mais úteis. Elas aceitam que o mesmo sistema possa apresentar tendências contraditórias ao mesmo tempo.
Isso não é uma fraqueza da análise. É exatamente o que deveríamos esperar de uma infraestrutura que combina software, mercados, hardware, trabalho, instituições e escolhas individuais.
Alguns atalhos que parecem resolver a discussão — mas não resolvem
“Ninguém controla o Bitcoin” contém uma parte verdadeira: não existe um agente com autoridade suficiente para comandar sozinho todas as funções descritas neste artigo. O problema surge quando a frase é estendida até significar que ninguém exerce poder relevante em nenhuma camada. Um custodiante controla as chaves que guarda. Um pool coordena determinadas funções de mineração. Mantenedores exercem poder sobre um repositório. Fabricantes decidem sua produção. Nenhum desses poderes é soberania sobre o sistema inteiro, mas nenhum é imaginário.
“Qualquer pessoa pode rodar um nó” também expressa uma propriedade importante. A função de validação não exige uma licença concedida por uma instituição central. Só que isso não mede automaticamente mineração, custódia, desenvolvimento ou capacidade econômica. Possibilidade formal de participação e distribuição efetiva de capacidade são perguntas relacionadas, não idênticas.
“Mineradores podem mudar de pool” aponta para um mecanismo real de saída. A ameaça de perder hashrate pode limitar a capacidade de um pool impor determinadas decisões. Mas a força desse mecanismo depende das alternativas, dos custos operacionais e das funções que o minerador consegue levar consigo na mudança.
E “riqueza não muda as regras de consenso” é tecnicamente importante, mas insuficiente como descrição de poder. Capital pode não fabricar um bloco válido por decreto, mas pode financiar os meios através dos quais milhões de pessoas acessam, negociam e interpretam a rede.
Esses exemplos mostram por que a resposta mais precisa quase sempre exige uma frase a mais.
Descentralização como mapa de poderes
Depois de separar essas camadas, a pergunta inicial fica menos confortável: afinal, o Bitcoin é descentralizado?
A resposta mais útil é que determinadas funções do Bitcoin são distribuídas por mecanismos diferentes e enfrentam concentrações diferentes.
Operadores independentes podem verificar regras. A rede peer-to-peer permite comunicação sem um servidor central obrigatório. Mineradores competem para produzir blocos, mas frequentemente se organizam por pools. Desenvolvimento ocorre de forma aberta, embora conhecimento e influência sejam desigualmente distribuídos. Usuários podem manter as próprias chaves, mas muitos utilizam custodiantes. A infraestrutura física atravessa fornecedores, mercados de energia, fabricantes e jurisdições que possuem seus próprios pontos de concentração.
Não existe contradição em reconhecer tudo isso ao mesmo tempo.
O erro está em escolher uma camada e fazê-la falar pelas demais.
Contar nós e concluir que todo o sistema é descentralizado é tão insuficiente quanto observar quatro grandes pools e concluir que um único grupo controla toda a rede. O primeiro ignora coordenação econômica e infraestrutura; o segundo confunde produção de blocos com validação, propriedade, desenvolvimento e acesso.
Talvez, então, a pergunta “quem controla o Bitcoin?” também precise ser abandonada quando aparece sozinha. Podemos substituí-la por algo menos elegante, mas muito mais informativo:
quem pode fazer o quê, quem pode impedir o quê, de quais recursos depende e quanto custa escapar dessa dependência?
Essa pergunta não entrega um slogan. Entrega um método.
E talvez essa seja a maneira mais séria de tratar a descentralização: não como uma qualidade que o protocolo possui por definição, mas como uma distribuição concreta de capacidades que precisa ser examinada continuamente.
Referências e documentação
BARAN, Paul. On Distributed Communications Networks. IEEE Transactions of the Professional Technical Group on Communications Systems, v. 12, n. 1, 1964.
https://www.rand.org/about/history/baran.html
BITCOIN DEVELOPERS. P2P Network — Developer Guide.
https://developer.bitcoin.org/devguide/p2p_network.html
BITCOIN IMPROVEMENT PROPOSALS. BIP 3: Updated BIP Process.
https://bitcoin.org/bip/3/
BITCOIN CORE. Contributing to Bitcoin Core.
https://github.com/bitcoin/bitcoin/blob/master/CONTRIBUTING.md
BITNODES. Bitcoin network crawler — source code and methodology.
https://github.com/ayeowch/bitnodes
GENCER, Adem Efe; BASU, Soumya; EYAL, Ittay; VAN RENESSE, Robbert; SIRER, Emin Gün. Decentralization in Bitcoin and Ethereum Networks. 2018.
https://arxiv.org/abs/1801.03998
LYNHAM, Alexander; GOODELL, Geoffrey. Decentralization: A Qualitative Survey of Node Operators. Manuscrito de 2025; disponibilizado no SSRN em 2026.
https://papers.ssrn.com/sol3/papers.cfm?abstract_id=6274978
STRATUM V2. Mining Protocol; Job Declaration Protocol.
https://stratumprotocol.org/specification/05-mining-protocol/
https://stratumprotocol.org/specification/06-job-declaration-protocol/