Visão Geral dos Desafios de Segurança

Uma característica definidora das blockchains é a natureza atômica das transações: uma vez que uma atualização é registrada na blockchain, não há oportunidade para intervenção ou reversão. Isso fornece fortes garantias de consistência e segurança no nível do 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, um fardo significativo de segurança recai sobre o usuário. Para usar o Ethereum com segurança, indivíduos e organizações devem manter e gerenciar chaves com segurança, interagir com aplicativos onchain e usar suas chaves para assinar transações para transferir ativos ou atualizar o estado do Ethereum.

Cada um desses requisitos introduz riscos como comprometimento ou perda de chaves, aprovações apressadas ou desinformadas, ou comprometimento do software de carteira no qual os usuários confiam para informá-los e guiá-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 amplamente utilizadas depende de os usuários armazenarem com segurança frases semente (seed phrases) que representam sua chave privada criptográfica subjacente, o que muitas vezes os leva a usar soluções alternativas inseguras, como armazenar frases semente em texto simples, em serviços de nuvem ou anotá-las em papel.

As carteiras de hardware são uma alternativa, que permitem aos usuários gerenciar uma chave criptográfica armazenada em um dispositivo físico de propósito especial. No entanto, as carteiras de hardware têm suas próprias falhas e superfície de ataque. As 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.

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

Usuários corporativos e institucionais enfrentam desafios adicionais no gerenciamento de chaves. Se funcionários individuais mantiverem chaves (por exemplo, como parte de uma multisig), a organização deve ser capaz de substituí-las e criar novas devido a mudanças de pessoal ao longo do tempo. Os requisitos de conformidade em diferentes setores e jurisdições podem exigir fluxos de trabalho personalizados ou trilhas de auditoria não suportados pelo software de carteira existente. Em alguns casos, os usuários corporativos recorrem a custodiantes terceirizados para ativos digitais, o que pode introduzir outra camada de riscos de segurança a serem considerados.

1.2 Assinatura cega e incerteza de transação

Os usuários rotineiramente aprovam transações "cegamente" sem entender o que estão fazendo. As carteiras geralmente apresentam dados hexadecimais brutos, endereço de contrato truncado ou outras informações que não são suficientes para o usuário entender 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 muitos aplicativos do Ethereum, é comum que os usuários concedam certas permissões ao aplicativo subjacente como parte do uso normal. Por exemplo, um usuário pode conceder a uma exchange descentralizada como o Uniswap permissão para mover seus tokens a fim de trocá-los por ETH.

Essas aprovações podem ter limites no valor, mas muitas carteiras têm como padrão conceder 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 frontends comprometidos, porque o padrão para muitos usuários é conceder aprovações ilimitadas que podem ser usadas 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 permanecer em vigor, o contrato comprometido poderá drenar os fundos do usuário.

Isso é igualmente um risco para usuários organizacionais. Por exemplo, uma organização pode optar por conceder a um roteador DEX uma permissão ilimitada de USDC por conveniência operacional, o que a expõe a riscos se o contrato do roteador for 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 via seu dispositivo móvel ou navegador web.

Esses frontends podem ser vulneráveis a ataques por meios familiares, como sequestro de DNS, injeção de JavaScript malicioso, hospedagem insegura ou várias 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 mitigar ou ampliar os riscos de segurança para usuários de todos os tipos.

Proteções de privacidade mais fracas expõem usuários individuais 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, por exemplo, reutilização de endereço, dados de KYC e outros vazamentos de metadados.

Para instituições e empresas, a privacidade costuma ser um requisito de negócios fundamental por motivos de conformidade ou certos casos de uso. Além dessas questões, ela pode criar exposição a riscos de segurança específicos. Por exemplo, um usuário de um sistema de cadeia de suprimentos construído no 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 em como diferentes carteiras lidam com comportamentos essenciais, como exibir transações, lidar com aprovações ou rotular contratos. Essa fragmentação da experiência do usuário adiciona atrito à capacidade do usuário de aprender a usar carteiras com segurança e aumenta os riscos.

Por exemplo, os usuários não podem confiar em dicas consistentes de UX para se protegerem de phishing e falsificação (spoofing), pois elas diferem entre as carteiras. Os usuários não podem formar expectativas confiáveis sobre como o Ethereum funciona se cada ferramenta funcionar de maneira diferente.

A segurança de contratos inteligentes melhorou radicalmente ao longo da história do Ethereum. Os primeiros incidentes de segurança, como o hack da DAO, motivaram o ecossistema a profissionalizar e melhorar as salvaguardas em todo o ciclo de vida do software que leva o código a ser implantado onchain. Os principais avanços incluem:

• A auditoria de segurança tornou-se uma prática padrão, com várias empresas de segurança entrando no ecossistema e desenvolvendo experiência.
• Ferramentas, testes e sistemas de análise estática amadureceram e se tornaram prática padrão.
• Bibliotecas de componentes comuns pré-auditados deram aos desenvolvedores blocos de construção seguros por padrão.
• Técnicas de verificação formal 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 fraquezas e áreas de melhoria neste domínio.

2.1 Vulnerabilidades de contrato

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 melhorar um aplicativo. No entanto, isso introduz riscos. As 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, ser maliciosa ou atualizável.
• Componentes não auditados. Embora a auditoria e o uso de bibliotecas padrão tenham melhorado, os desenvolvedores às vezes dependem de componentes não auditados em seus aplicativos.
• Falhas de controle de acesso, onde as permissões são mal configuradas ou definidas de forma muito ampla, permitindo que invasores tomem ações maliciosas.
• Acesso não autorizado, onde uma chave privada capaz de controlar o contrato é obtida por um ator malicioso.
• Pontes e interações crosschain. Pontes e protocolos crosschain introduzem complexidade adicional, e os 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 enganar os usuários para que assinem a delegação total de sua conta para outra parte, permitindo o roubo. Aplicativos maliciosos também podem usar mensagens assinadas pelo usuário de maneiras inesperadas, por exemplo, em um ataque de repetição (replay attack).
• Risco emergente de bugs introduzidos pela geração de código por IA ou ferramentas de refatoração automatizadas.

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

As vulnerabilidades acabam no código implantado como resultado de erro do desenvolvedor. Ferramentas aprimoradas para desenvolvedores tornaram significativamente mais fácil implantar contratos inteligentes seguros. No entanto, os problemas permanecem.

• Falta de padrões seguros em frameworks populares. Algumas ferramentas priorizam a flexibilidade ou a velocidade em detrimento da segurança, definindo padrões inseguros, como aprovações ilimitadas de tokens na função approve(), ou falhando em incluir padrões de controle de acesso por padrão.
• Código personalizado para controles operacionais avançados. Usuários institucionais com requisitos operacionais complexos muitas vezes devem construir os recursos necessários do zero, aumentando o risco de vulnerabilidades. Há uma falta de componentes ou frameworks seguros padronizados para fluxos de trabalho de segurança avançados.
• Cobertura de testes inconsistente em pilhas de ferramentas, bem como uma falta de normas em torno do uso de técnicas comprovadas, como fuzzing ou verificação de invariantes.
• Baixa adoção de métodos de verificação formal. As técnicas de verificação formal são poderosas, mas são complexas, caras, exigem conhecimento especializado no domínio e não estão bem integradas aos fluxos de trabalho padrão dos desenvolvedores, onde poderiam ser usadas muito mais cedo na produção de software para verificar a segurança na fase de especificação.
• Problemas relacionados à verificação de contrato. Usuários e desenvolvedores não podem avaliar facilmente a confiabilidade dos contratos implantados, 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 permanecem. As ferramentas que abordam esses problemas 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 de compiladores. Compiladores (o software que converte código legível por humanos, como Solidity, no bytecode usado pela própria EVM) podem ter falhas que introduzem erros em contratos inteligentes antes de serem implantados. O ecossistema Ethereum hoje depende principalmente do compilador solc, o que significa que um bug pode ter efeitos generalizados.
• Diversidade e profundidade de linguagens de programação. Embora a Solidity tenha um ecossistema profundo de ferramentas construído sobre ela, alguns desenvolvedores desejam 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 de código onchain

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

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

3.1 Cadeias de camada 2

As cadeias de camada 2 (l2s) servem como extensões para o 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 de ativos em pontes de múltiplos saltos. Quando os ativos viajam entre a camada 1 (l1) e múltiplas l2s, eles são expostos a vários conjuntos de contratos, todos os quais devem ser seguros. Contabilidade incompatível ou interrupções nas cadeias l2 podem introduzir vulnerabilidades que podem ser exploradas por invasores.
• As l2s de rollup dependem de sistemas de prova para impor a correção das atualizações de estado. Bugs ou configurações incorretas nesses sistemas podem travar ou impedir a finalização, ou permitir a finalização de atualizações de estado falsas, levando à perda de fundos dos usuários.
• Conselhos de segurança são grupos de detentores de chaves que servem como um mecanismo de "backup" para atualizar o software de l2 ou responder a certas emergências. Os próprios conselhos de segurança representam riscos, pois o comprometimento ou conluio entre os membros pode colocar os fundos dos usuários em risco ou congelar ativos.

Consulte o 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 Infraestrutura de RPC e nós

Os aplicativos do Ethereum dependem de um pequeno número de provedores de infraestrutura para acesso a RPC, APIs e serviços de nós. Isso inclui provedores de infraestrutura específicos de cripto, bem como serviços de nuvem tradicionais que são comumente usados para hospedar nós (por exemplo, AWS, Cloudflare, Hetzner).

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

3.3 Vulnerabilidades no nível do 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, que são suscetíveis a:

• Sequestro de DNS, onde um invasor insere um frontend falso e malicioso.
• Apreensão de domínio, onde um governo ou registrador pode confiscar domínios.
• Phishing por meio de domínios semelhantes, onde invasores registram nomes quase idênticos para confundir os usuários.

3.4 Cadeia de suprimentos de software e bibliotecas

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

• Injeção de pacote malicioso, onde invasores comprometem um pacote amplamente utilizado ou publicam um com um nome semelhante
• Dependências sequestradas, onde os mantenedores perdem o controle de um projeto e um ator malicioso introduz código prejudicial
• Comprometimento 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 de frontend e riscos relacionados

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

3.6 Censura no 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 ao Ethereum. Por exemplo, esses ataques podem incluir:

• Bloqueio ou limitação de tráfego para portas comuns do Ethereum
• Filtragem de solicitações de DNS que resolvem para serviços relacionados ao Ethereum
• Bloqueio geográfico (geofencing) ou banimentos de IP contra nós conhecidos do Ethereum
• 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 em todo o mundo para suprimir o acesso a informações, ferramentas de protesto ou criptomoedas hoje.

O protocolo de consenso do Ethereum provou ser robusto na prática, com zero tempo de inatividade desde o seu primeiro lançamento em 2015 e ao longo de várias atualizações. No entanto, ainda existem á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 de bifurcação e finalidade do Ethereum são resilientes, mas não são invulneráveis. Durante certas condições extremas (como desacordo prolongado de validadores, bugs de clientes ou partições de rede), o consenso pode travar ou divergir temporariamente. Em condições extremas, isso pode levar a penalizações em cascata de validadores por meio de vazamentos de inatividade ou penalização, o que pode levar ainda mais à fuga de capital dos validadores.

4.2 Diversidade de clientes

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

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

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

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

4.4 Slashing social indefinido e lacunas de coordenação

Em alguns modos de falha extremos, o Ethereum dependeria do "slashing social" para penalizar os validadores que agissem maliciosamente para atacar a rede (consulte a seção 6.1). No entanto, a infraestrutura, as normas e os processos esperados para esse tipo de penalização estã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 da teoria dos jogos

Muitos vetores de ataque econômicos em potencial permanecem pouco estudados, incluindo:

• Ataques de griefing ou griefing de penalização (slash griefing). Os validadores podem incorrer em custos ou penalizações não devido a suas próprias falhas, mas devido a um comportamento adversário destinado exclusivamente a prejudicar os outros a um custo líquido para o invasor.
• Saídas estratégicas ou inatividade cronometrada. Os validadores podem intencionalmente ficar offline ou sair em momentos críticos para maximizar os lucros ou interromper o consenso com penalidades mínimas.
• Conluio entre validadores ou retransmissores (relays). 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 propositor-construtor (PBS) ou design de staking líquido. Os atores podem manipular condições raras do protocolo para obter recompensas desproporcionais.

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 esse não seja um risco iminente, uma ameaça crível pode tornar instantaneamente vulneráveis as carteiras, contratos e chaves de staking existentes. Esse desafio futuro enfraquece as garantias de longo prazo do Ethereum para os 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 as coisas dão errado, deve haver sistemas eficazes para mitigar, detectar e responder. Os desafios aqui incluem:

• Alcançar 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 dos respondentes de recuperar fundos.
• Escalar problemas em organizações relacionadas. Quando o problema envolve uma plataforma (como uma rede social ou corretora centralizada), pode ser um desafio para os respondentes escalar o problema se não tiverem um contato pré-existente.
• Coordenação de resposta. Muitas vezes não está claro quantas equipes de resposta a incidentes estão auxiliando o aplicativo afetado, levando a falhas de comunicação ou desperdício de esforço quando um esforço em grupo poderia ter sido mais eficaz.
• Falta de recursos de monitoramento. Pode ser difícil monitorar problemas onchain e offchain, o que forneceria um aviso prévio e garantiria uma resposta rápida às ameaças.
• Acesso a 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, hoje poucas opções de seguro estão disponíveis nos serviços financeiros tradicionais para o ecossistema cripto.

Esses riscos tendem a ser mais orientados a 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 stake

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

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

Se esse cenário extremo acontecesse, a comunidade do Ethereum sugeriu que o "slashing social" poderia ser a resposta. O slashing social é o uso do consenso social offchain para decidir penalizar validadores malcomportados, como um controle sobre seu poder. Mas não existem normas, procedimentos ou ferramentas claras para promulgar 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 (RWA), onde os ativos são 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 grandes stablecoins funcionam dessa maneira.

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

6.3 Ataque ou pressão regulatória

Governos e reguladores podem pressionar várias entidades que controlam componentes importantes da pilha do Ethereum para censurar ou interferir de outra forma no protocolo Ethereum. Os usuários institucionais do Ethereum também podem 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 certos 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 impulsionados por um conjunto diversificado e global de equipes e empresas que mantêm o software cliente principal, a infraestrutura e as ferramentas.

Várias formas de influência (aquisições corporativas, dependências de financiamento, emprego de contribuidores-chave, conflitos de interesse dentro de organizações existentes) 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 impulsionado pela comunidade e do roteiro estabelecido, potencialmente enfraquecendo a neutralidade e a resiliência do Ethereum ao longo do tempo.