Visão geral dos desafios de segurança

Uma característica que define as blockchains é a natureza atômica das transações: uma vez que uma atualização é registrada na blockchain, não há possibilidade de intervenção ou reversão. Isso oferece garantias de consistência e segurança em nível de protocolo, mas expõe os usuários a um risco operacional elevado: um único erro, chave comprometida ou aprovação apressada pode levar a perdas irreversíveis.

Como resultado, grande parte da responsabilidade pela segurança recai sobre o usuário. Para usar o Ethereum com segurança, indivíduos e organizações devem manter e gerenciar suas chaves com segurança, interagir com aplicativos onchain e usar suas chaves para assinar transações, sejam elas de transferência de ativos ou para atualizar o estado do Ethereum.

Cada um desses requisitos apresentam riscos como comprometimento ou perda de chaves, aprovações precipitadas e desinformadas, ou comprometimento do software de carteira no qual os usuários confiam para informá-los e orientá-los na interação com o Ethereum.

1.1 Gerenciamento de chaves

Muitos usuários não estão equipados para gerenciar chaves criptográficas com segurança.

A maioria das carteiras de software mais utilizadas depende de usuários que armazenam com segurança as seeds representando sua chave privada, o que muitas vezes os leva a usar soluções alternativas inseguras, como armazenar em texto simples, em serviços de nuvem ou escrevê-las no papel.

Carteiras de hardware são uma alternativa, permitindo que os usuários gerenciem uma chave criptográfica armazenada em um dispositivo físico para fins específicos. No entanto, carteiras de hardware têm suas próprias falhas e superfície de ataque. Carteiras de hardware podem ser perdidas, danificadas ou roubadas. Muitas carteiras de hardware não são de código aberto e podem ter cadeias de suprimentos opacas, aumentando o risco de um ataque à cadeia de suprimentos, onde dispositivos comprometidos são vendidos no mercado.

Não importa se as chaves são gerenciadas em uma carteira de software ou hardware: muitos usuários ficam compreensivelmente nervosos com a autocustódia quando ela pode ser comprometida por roubo físico ou agressão.

Usuários corporativos e institucionais enfrentam desafios adicionais no gerenciamento de chaves. Se funcionários possuem as chaves (por exemplo, como parte de uma carteira multiassinada), a organização precisa ser capaz de substituí-las e criar novas devido às mudanças de pessoal ao longo do tempo. Requisitos de conformidade em diferentes setores e jurisdições podem exigir fluxos de trabalho personalizados ou trilhas de auditoria não suportadas pelos softwares de carteira existentes. Em alguns casos, usuários corporativos recorrem a custodiantes terceirizados para ativos digitais, o que pode introduzir outra camada de risco de segurança a serem considerados.

1.2 Assinatura às cegas e incerteza da transação

Usuários rotineiramente aprovam transações "às cegas", sem entender o que estão fazendo. As carteiras frequentemente apresentam dados hexadecimais brutos, endereços de contrato truncados ou outras informações insuficientes para que o usuário entenda as consequências de uma determinada transação. Isso deixa usuários de todos os tipos vulneráveis ​​a contratos inteligentes maliciosos, phishing, golpes, interfaces falsificadas, comprometimentos de front-end e erros básicos do usuário.

1.3 Gerenciamento de aprovação e permissão

Em muitas aplicações Ethereum, é comum que os usuários concedam certas permissões à aplicação subjacente como parte do uso normal. Por exemplo, um usuário pode conceder a uma exchange descentralizada como a Uniswap permissão para mover seus tokens e trocá-los por ETH.

Essas aprovações podem ter limites de valor, mas muitas carteiras concedem aprovações ilimitadas sem data de validade. Não há como os usuários gerenciarem ou revisarem suas aprovações pendentes na maioria das carteiras.

Isso pode expor os usuários a aplicativos maliciosos ou front-ends comprometidos, pois o padrão de muitos usuários é conceder aprovações ilimitadas, o que pode ser usado para drenar seus fundos. Mesmo que um usuário conceda uma aprovação a um contrato inteligente legítimo, se esse contrato for posteriormente comprometido enquanto a aprovação estiver em vigor, o contrato comprometido poderá drenar os fundos do usuário.

Isso representa igualmente um risco para os usuários organizacionais. Por exemplo, uma organização pode optar por conceder uma permissão ilimitada de USDC para um roteador DEX por conveniência operacional, o que os expõe a riscos caso o contrato do roteador seja atualizado.

1.4 Interfaces web comprometidas

A maioria dos usuários não interage diretamente com um contrato inteligente, mas sim por meio de uma interface web através do seu dispositivo móvel ou navegador web.

Esses front-ends podem ser vulneráveis ​​a ataques por meios conhecidos, como sequestro de DNS, injeção maliciosa de JavaScript, hospedagem insegura ou diversas dependências de terceiros. Uma UX de aplicativo comprometida pode redirecionar usuários de todos os tipos para contratos inteligentes maliciosos ou levá-los a assinar transações enganosas.

1.5 Privacidade

A privacidade pode atenuar ou ampliar os riscos de segurança para usuários de todos os tipos.

Proteções de privacidade mais fracas expõem usuários a uma variedade de ameaças direcionadas, como phishing, exploração, golpes ou ataques físicos. Muitos padrões comuns de UX expõem os usuários, como reutilização de endereços, dados KYC e outros vazamentos de metadados.

Para instituições e empresas, a privacidade costuma ser um requisito comercial fundamental por questões de conformidade ou por determinados casos de uso. Além desses problemas, ela pode gerar exposição a riscos de segurança específicos. Por exemplo, um usuário de um sistema de cadeia de suprimentos baseado em Ethereum pode exigir fortes garantias de privacidade para proteger ativos de propriedade intelectual que poderiam ser comprometidos se o sistema fosse transparente.

1.6 Fragmentação

Há uma falta de consistência na forma como diferentes carteiras lidam com comportamentos essenciais, como exibir transações, processar aprovações ou rotular contratos. Essa fragmentação da experiência do usuário dificulta a aprendizagem do uso seguro das carteiras, além de aumentar os riscos.

Por exemplo, os usuários não podem confiar em indicações consistentes de UX para se protegerem de phishing e spoofing, pois elas variam de acordo com a carteira. Os usuários não podem formar expectativas confiáveis ​​sobre o funcionamento do Ethereum se cada ferramenta funcionar de forma diferente.

A segurança dos contratos inteligentes melhorou radicalmente ao longo da história do Ethereum. Incidentes de segurança iniciais, como o hack da DAO, motivaram o ecossistema a profissionalizar e aprimorar as proteções em todo o ciclo de vida do software, que leva à implantação do código onchain. Os principais avanços incluem:

• A auditoria de segurança se tornou uma prática padrão, com diversas empresas de segurança entrando no ecossistema e desenvolvendo expertise.
• Ferramentas, testes e sistemas de análises estáticas amadureceram e se tornaram práticas padrão.
• Bibliotecas de componentes comuns pré-auditados forneceram aos desenvolvedores blocos de construção seguros por padrão.
• Técnicas formais de verificação foram adotadas, especialmente para pontes, sistemas de staking e contratos de alto valor.
• A cultura de segurança e as melhores práticas do ecossistema melhoraram.
• A criação de programas de recompensas significativos que fortaleceram a camada de aplicativos.

No entanto, ainda existem fragilidades e áreas de melhoria neste domínio.

2.1 Vulnerabilidades dos Contratos

Apesar dos avanços na segurança de contratos inteligentes, ainda existem vulnerabilidades que podem levar a problemas de segurança significativos, incluindo:

• Risco de atualização de contrato. Alguns contratos são projetados para serem modificáveis ​​após a implantação, para permitir que uma equipe de desenvolvimento continue a atualizar e aprimorar um aplicativo. No entanto, isso apresenta riscos. Atualizações podem resultar em novas vulnerabilidades ou na perda total dos fundos do usuário no caso de uma atualização maliciosa.
• Reentrância, onde o contrato A chama um contrato externo B antes de atualizar seu próprio estado interno, e o contrato B chama de volta o contrato original A antes que a primeira chamada termine.
• Uso inseguro de bibliotecas externas, onde um contrato chama uma biblioteca externa que pode não ser auditada, maliciosa ou atualizável.
• Componentes não auditados. Embora a auditoria e o uso de bibliotecas padrão tenham melhorado, às vezes os desenvolvedores dependem de componentes não auditados em seus aplicativos.
• Falhas no controle de acesso, onde as permissões são configuradas incorretamente ou definidas de forma muito ampla, permitindo que invasores realizem ações maliciosas.
• Acesso não autorizado, onde uma chave privada capaz de controlar o contrato é obtida por um agente malicioso.
• Pontes e interações crosschain. Pontes e protocolos crosschain introduzem complexidade adicional, e invasores podem explorar fraquezas na forma como as mensagens crosschain são passadas ou validadas.
• Delegação de conta de propriedade externa (EOA) ou uso indevido de assinatura. Aplicativos maliciosos podem induzir os usuários a transferir a delegação completa de suas contas para terceiros, possibilitando o roubo. Aplicativos maliciosos também podem usar mensagens assinadas pelo usuário de maneiras inesperadas, por exemplo, em um ataque de repetição.
• Risco emergente de bugs introduzidos pela geração de código de IA ou ferramentas de refatoração automatizadas.

2.2 Experiência do desenvolvedor, ferramentas e linguagens de programação

Vulnerabilidades acabam se espalhando pelo código como resultado de erros do desenvolvedor. Ferramentas aprimoradas para desenvolvedores facilitaram significativamente a implementação de contratos inteligentes seguros. No entanto, os problemas persistem.

• Falta de padrões seguros em frameworks populares. Algumas ferramentas priorizam flexibilidade ou velocidade em detrimento da segurança, definindo padrões inseguros, como aprovações ilimitadas de tokens na função approve(), ou deixando de incluir padrões de controle de acesso por padrão.
• Código operacional para controles operacionais avançados. Usuários institucionais com requisitos operacionais complexos frequentemente precisam criar os recursos necessários do zero, aumentando o risco de vulnerabilidades. Há uma falta de componentes ou estruturas de segurança padronizados para fluxos de trabalho de segurança avançados.
• Cobertura de testes inconsistente entre stacks de ferramentas, bem como a falta de normas sobre o uso de técnicas comprovadas, como fuzzing ou verificação invariante.
• Baixa adoção de métodos formais de verificação. Técnicas de verificação formal são poderosas, mas são complexas, caras, exigem conhecimento especializado e não são bem integradas aos fluxos de trabalho padrão do desenvolvedor, onde poderiam ser usadas na produção do software para verificar a segurança no estágio de especificação.
• Problemas relacionados à verificação de contratos. Usuários e desenvolvedores não conseguem avaliar facilmente a confiabilidade dos contratos implementados, a extensão de sua validação de segurança (por exemplo, auditorias de código) ou a presença de riscos latentes. Embora existam soluções para esse fim, muitos problemas persistem. Ferramentas que abordam essas questões não são amplamente adotadas, os padrões que unificariam as abordagens permanecem fragmentados e alguns dos serviços existentes são, eles próprios, dependências centralizadas.
• Riscos do compilador. Compiladores (o software que converte código legível por humanos, como o Solidity, no bytecode usado pela própria EVM) podem apresentar falhas que introduzem erros em contratos inteligentes antes de sua implantação. O ecossistema Ethereum hoje depende principalmente do compilador Solc, o que significa que um bug pode ter efeitos generalizados.
• Diversidade e profundidade da linguagem de programação. Embora o Solidity tenha um ecossistema de ferramentas profundo, alguns desenvolvedores querem recursos de segurança mais modernos encontrados em outras linguagens de programação, como segurança de memória.

2,3 Avaliação de risco on-chain code

Instituições e empresas possuem processos, padrões e requisitos para avaliar a segurança da tecnologia e dos sistemas dos quais dependem. No entanto, as estruturas existentes muitas vezes não se correlacionam claramente com os contratos inteligentes, geralmente pressupondo código mutável, controle centralizado de alterações e linhas claras de responsabilidade ou obrigação legal. Sistemas baseados em contratos inteligentes podem, às vezes, quebrar essas premissas, dificultando a adoção do Ethereum e o gerenciamento adequado de riscos pelas organizações.

Esses sistemas são uma superfície de ataque tanto para a camada de carteira quanto para a camada de aplicação (por exemplo, endpoints RPC para carteiras) e para o próprio protocolo Ethereum (por exemplo, muitos validadores são hospedados em infraestrutura de nuvem). Comprometimento de chaves privadas, phishing e falta de controles de acesso granulares podem levar a interrupções em larga escala, roubo ou alterações não autorizadas, mesmo que o protocolo blockchain subjacente permaneça seguro.

3,1 Camadas 2 cadeias

As redes da Camada 2 (L2s) funcionam como extensões do Ethereum, permitindo ambientes mais rápidos e com taxas mais baixas, mantendo algumas das garantias de segurança características da rede principal do Ethereum (dependendo de seu design específico). No entanto, elas também têm suas próprias superfícies de ataque distintas, incluindo:

• Complexidade do ativo de um ativo que permite transações em múltiplas etapas ou pontes entre diferentes sistemas ou redes. Quando ativos trafegam entre L1 e múltiplas L2, eles ficam expostos a múltiplos conjuntos de contratos, todos os quais devem ser seguros. Contabilidades incompatíveis ou interrupções nas redes L2 podem introduzir vulnerabilidades que podem ser exploradas por invasores.
• Rollup L2s dependem de sistemas de comprovação para impor a correção das atualizações de estado. Falhas ou configurações incorretas nesses sistemas podem paralisar, ou impedir a finalização, ou permitir a finalização de atualizações de estado falsas, levando à perda de fundos do usuário.
• Os conselhos de segurança são grupos de detentores de chaves que servem como um mecanismo de "backup" para atualizar o software L2 ou responder a certas emergências. Os próprios conselhos de segurança apresentam riscos, pois o comprometimento ou conluio entre os membros pode colocar os fundos dos usuários em risco, ou congelar ativos.

Consulte L2Beat (opens in a new tab) para obter uma estrutura detalhada e um painel de monitoramento que avalia e compara o desempenho e a segurança das L2s.

3.2 RPC e infraestrutura de nós

As aplicações Ethereum dependem de um pequeno número de provedores de infraestrutura para acesso RPC, APIs e serviços de nós. Isso inclui provedores de infraestrutura específicos para criptomoedas, bem como serviços de nuvem tradicionais comumente usados ​​para hospedar nós (por exemplo, AWS, Cloudflare, Hetzner).

Se esses provedores de infraestrutura ficassem offline ou tentassem censurar ou restringir o acesso, muitos usuários poderiam ser impedidos de acessar o Ethereum por meio de suas carteiras ou aplicativos, até que pudessem migrar para um novo RPC ou outro provedor de infraestrutura. Alguns desses provedores já suspenderam ou encerraram contas associadas à atividade de blockchain, levantando preocupações sobre sua confiabilidade a longo prazo para aplicativos descentralizados.

3.3 Vulnerabilidades de nível DNS

O Sistema de Nomes de Domínio (DNS) é uma camada fundamental da internet, mas também é centralizado e pode ser comprometido. Muitos usuários acessam aplicativos por meio de domínios da web, suscetíveis a:

• Sequestro de DNS, em que um invasor insere um frontend falso e malicioso.
• Apreensão de domínio, onde um governo ou registrador pode aprender domínios.
• Ataque cibernético através de domínios semelhantes, onde os invasores registram nomes quase idênticos para confundir os usuários.

3,4 Cadeia de abastecimento e bibliotecas de software

Os desenvolvedores do Ethereum dependem de bibliotecas de código aberto, muitas vezes obtidas diretamente de serviços como npm, crates.io ou GitHub. Se essas bibliotecas forem comprometidas, podem ser um vetor para ataques como:

• Inserção de pacote malicioso, onde os atacantes comprometem um pacote amplamente utilizado ou publicam um sob um nome similar
• Dependências invadidas, onde os mantenedores perdem o controle de um projeto e um ator malicioso introduz código malicioso
• Compromisso do desenvolvedor, onde os pacotes instalados contêm código que dá ao invasor controle sobre o computador do desenvolvedor.

3.5 Serviços de entrega front-end e riscos relacionados

Muitos aplicativos Ethereum disponibilizam seus frontends por meio de uma Rede de Distribuição de Conteúdo (CDN) ou de uma plataforma de hospedagem em nuvem (por exemplo, Vercel, Netlify, Cloudflare). Se esses serviços forem comprometidos, podem ser um vetor para ataques como injeção maliciosa de JavaScript, em que os invasores disponibilizam um frontend alterado aos usuários.

3.6 Censura ao nível do Provedor de Serviços de Internet

Provedores de Serviços de Internet (ISPs) ou Estados-nação podem usar o controle da infraestrutura de internet subjacente para censurar o acesso à Ethereum. Por exemplo, esses ataques podem incluir:

• Bloqueio ou limitação de tráfego para portas Ethereum comuns
• Filtrando solicitações de DNS que resolvem para serviços relacionados ao Ethereum
• Geofencing ou proibições de IP contra nós Ethereum conhecidos
• Inspeção profunda de pacotes para identificar e censurar o tráfego relacionado ao protocolo Ethereum

Muitas dessas técnicas básicas já são usadas por governos autoritários ao redor do mundo para suprimir o acesso a informações, ferramentas de protesto ou criptomoedas hoje.

O protocolo de consenso da Ethereum provou ser robusto na prática, com zero tempo de inatividade desde o lançamento em 2015 e após diversas atualizações. No entanto, ainda há áreas de melhoria a longo prazo para tornar o sistema mais resiliente e seguro.

4.1 Fragilidade do consenso e riscos de recuperação

As regras de escolha e finalidade de fork do Ethereum são resilientes, mas não invulneráveis. Em certas situações extremas (como desacordo prolongado entre validadores, bugs no cliente ou partições de rede), o consenso pode estagnar ou divergir temporariamente. Em condições extremas, isso pode levar a penalidades em cascata para os validadores por meio de vazamentos ou slashing de inatividade, o que pode levar ainda mais à fuga de capitais dos validadores.

4.2 Diversidade de clientes

A diversidade de clientes líder do setor da Ethereum protege a rede contra bugs em qualquer cliente. No entanto, a diversidade de clientes ainda pode ser melhorada com a adoção de clientes minoritários para reduzir ainda mais esses riscos.

4.3 Centralização de staking e dominância de pool

Uma parcela significativa do peso dos validadores está concentrada em protocolos de staking de liquidez, serviços de custódia e grandes operadores de nós. Essa concentração pode levar a riscos como:

• Captura ou influência na governança. Se entidades que controlam grandes quantidades de participação (ou entidades com poder legal para influenciá-las) se coordenassem, poderiam ter uma influência descomunal sobre quais blocos são propostos e atestados, potencialmente censurando usuários ou influenciando atualizações de protocolo.
• Homogeneidade na escolha do cliente e na configuração da infraestrutura, o que pode aumentar os riscos de falhas correlacionadas.

4.4 Lacunas indefinidas de coordenação e slashing social

Em alguns modos extremos de falha, o Ethereum recorreria ao "slashing social" para penalizar validadores que agissem maliciosamente para atacar a rede (ver seção 6.1). No entanto, a infraestrutura, as normas e os processos esperados para esse tipo de slashing são subdesenvolvidos. Não há um mecanismo estabelecido que a comunidade usaria para se envolver nesse processo.

4.5 Vetores de ataque econômicos e teóricos

Muitos potenciais vetores de ataque econômico ainda são pouco estudados, incluindo:

• Ataques de "griefing" ou "slash griefing". Os validadores podem incorrer em custos ou penalidades de "slashing" não por suas próprias falhas, mas por comportamento adversário com a única intenção de prejudicar terceiros, com um custo monetário para o agressor.
• Saídas estratégicas ou inatividade temporária. Os validadores podem ficar offline intencionalmente ou sair em momentos críticos para maximizar lucros ou interromper o consenso com penalidades mínimas.
• Conluio entre validadores ou retransmissores. O comportamento coordenado entre validadores ou entre retransmissores e validadores pode reduzir a descentralização ou extrair MEV.
• Exploração de incentivos de casos extremos em MEV, separação entre proponente e construtor ou design de staking líquido. Atores podem manipular condições raras de protocolo para obter recompensas extraordinárias.

4.6 Risco quântico

A criptografia central do Ethereum (por exemplo, assinaturas de curva elíptica como secp256k1) pode um dia ser quebrada por computadores quânticos. Embora este não seja um risco iminente, uma ameaça real poderia tornar instantaneamente vulneráveis carteiras, contratos e chaves de staking existentes. Este desafio futuro enfraquece as garantias de longo prazo do Ethereum aos usuários.

Caminhos de migração para criptografia resistente a quantum (por exemplo, por meio de esquemas de assinatura pós-quântica) precisam ser projetados, testados e possivelmente incorporados ao protocolo anos antes de serem necessários. Organizações em todo o ecossistema Ethereum, incluindo a Fundação Ethereum, estão explorando ativamente essas opções e monitorando os riscos.

Mesmo um ecossistema de blockchain idealizado terá riscos, ataques e vulnerabilidades. Quando algo dá errado, é preciso haver sistemas eficazes para mitigar, detectar e responder. Os desafios aqui incluem:

• Alcançando a equipe afetada. Pode ser difícil entrar em contato com a equipe cujo aplicativo foi comprometido. Isso pode levar a horas de atraso, limitando a capacidade da equipe de resposta de recuperar os fundos.
• Problemas crescentes em organizações relacionadas. Quando o problema envolve uma plataforma (como uma rede social ou uma exchange centralizada), pode ser difícil para os socorristas escalarem o problema se não tiverem um contato preexistente.
• Resposta coordenada. Muitas vezes, não fica claro quantas equipes de resposta a incidentes estão auxiliando o aplicativo afetado, o que leva a falhas de comunicação ou desperdício de esforço quando um esforço em grupo poderia ter sido mais eficaz.
• Falta de capacidades de monitoramento. Pode ser difícil monitorar problemas onchain e offchain, o que forneceria um alerta antecipado e garantiria uma resposta rápida às ameaças.
• Acesso ao seguro. O seguro é uma ferramenta essencial para mitigar perdas na maioria dos sistemas tradicionais que lidam com dinheiro, sistemas financeiros, identidade e outras informações valiosas. No entanto, atualmente, poucas opções de seguro estão disponíveis em serviços financeiros tradicionais para o ecossistema de criptomoedas.

Esses riscos tendem a ser mais voltados ao longo prazo e dizem respeito ao Ethereum como um todo, em vez da segurança de usuários ou aplicativos individuais.

6.1 Centralização de stakes

A centralização de grandes quantidades de stake pode representar riscos para o Ethereum como um todo se as entidades que controlam esses stakes decidirem conspirar.
Essa centralização econômica cria o potencial para a captura da governança social. Se um pequeno grupo de validadores controlar uma supermaioria dos stakes, eles poderiam:

• Coordenar ou resistir aos forks.
• Censurar certas transações ou contratos.
• Minar o consenso da comunidade ameaçando saída ou oposição.

Se esse cenário extremo acontecesse, a comunidade Ethereum sugeriu que o "slashing social" poderia ser a solução. O slashing social consiste no uso do consenso social offchain para decidir cortar validadores que se comportam mal, como forma de controlar seu poder. Mas não existem normas, procedimentos ou ferramentas claras para implementar tais medidas (consulte a seção 4.4).

6.2 Centralização de ativos offchain

O Ethereum hospeda quantidades significativas de ativos do mundo real, mantidos offchain em contas bancárias ou outros depósitos, que são então negociados onchain por meio de tokens que representam uma reivindicação sobre os ativos offchain. Por exemplo, muitas stablecoins de grande porte funcionam dessa maneira.

As instituições que detêm os depósitos offchain podem ter influência sobre o ecossistema Ethereum. Por exemplo, durante um cenário extremo em que há um Fork disputado ou uma atualização de rede, grandes depositantes podem influenciar qual cadeia se tornará amplamente aceita, optando por reconhecer apenas tokens de uma ou outra.

6.3 Ataque ou pressão regulatória

Governos e reguladores poderiam pressionar diversas entidades que controlam componentes importantes da infraestrutura do Ethereum a censurar ou interferir de alguma forma no protocolo Ethereum. Usuários institucionais do Ethereum também poderiam ser impactados por essas pressões, o que teria consequências adicionais para seus usuários (por exemplo, um banco que não pode mais oferecer determinados produtos cripto devido a proibições regulatórias).

6.4 Captura organizacional da governança

Os processos de governança e desenvolvimento de código aberto do Ethereum são conduzidos por um conjunto diversificado e global de equipes e empresas que mantêm o software, a infraestrutura e as ferramentas principais do cliente.

Diversas formas de influência (aquisições corporativas, dependências de financiamento, contratação de colaboradores chave, conflitos de interesse dentro de organizações) podem mudar gradualmente a cultura e as prioridades da governança do Ethereum. Isso pode levar ao alinhamento com interesses comerciais ou externos específicos que divergem do ethos orientado pela comunidade e do roteiro estabelecido, potencialmente enfraquecendo a neutralidade e a resiliência do Ethereum ao longo do tempo.