Saltar para o conteúdo principal

4 posts marcados com "Restaking"

Mecanismos de restaking

Ver todas as tags

$ 606 milhões em 18 dias: Por que bugs introduzidos por atualizações são o novo principal vetor de ataque do DeFi

· 14 min de leitura
Dora Noda
Software Engineer

Em apenas 18 dias neste mês de abril, atacantes drenaram $ 606 milhões do setor DeFi. Esse único período apagou as perdas do primeiro trimestre de 2026 em 3,7 vezes e tornou o mês o pior desde o assalto à Bybit em fevereiro de 2025. Dois protocolos — Drift na Solana e Kelp DAO na Ethereum — foram responsáveis por 95 % dos danos. Ambos haviam sido auditados. Ambos passaram por análises estáticas. Ambos lançaram atualizações de rotina que silenciosamente invalidaram as premissas que seus auditores haviam verificado.

Este é o novo rosto do risco DeFi. Os exploits catastróficos de 2026 não são mais sobre bugs de reentrância ou estouros de inteiros que ferramentas de fuzzing podem detectar em CI. Eles tratam de vulnerabilidades introduzidas por atualizações: mudanças sutis em configurações de pontes, fontes de oráculos, funções de administrador ou padrões de mensagens que transformam códigos anteriormente seguros em uma porta aberta — sem que nenhuma linha individual de Solidity pareça obviamente errada.

Se você constrói, faz custódia ou simplesmente detém ativos em DeFi, a conclusão de abril de 2026 é desconfortável: um relatório de auditoria limpo datado de três meses atrás não é mais evidência de que um protocolo é seguro hoje.

O Padrão de Abril: Configuração, Não Código

Para entender por que "introduzido por atualização" merece sua própria categoria, observe como os dois maiores exploits realmente ocorreram.

**Drift Protocol — 285milho~es,1deabrilde2026.AmaiorDEXdeperpeˊtuosdaSolanaperdeumaisdametadedoseuTVLapoˊsatacantespassaremseismesesexecutandoumacampanhadeengenhariasocialcontraaequipe.Assimqueaconfianc\cafoiestabelecida,elesusaramorecursode"noncesduraˊveis"daSolanaumaconvenie^nciadeUXprojetadaparapermitirqueusuaˊriospreˊassinemtransac\co~esparasubmissa~oposteriorparaenganarmembrosdoConselhodeSeguranc\cadaDriftaautorizaremoquepensavamserassinaturasoperacionaisderotina.Essasassinaturaseventualmenteentregaramocontroleadministrativoaosatacantes,quelistaramumtokendecolateralfalso(CVT),depositaram500milho~esdeunidadesdeleeretiraram285 milhões, 1 de abril de 2026.** A maior DEX de perpétuos da Solana perdeu mais da metade do seu TVL após atacantes passarem seis meses executando uma campanha de engenharia social contra a equipe. Assim que a confiança foi estabelecida, eles usaram o recurso de "nonces duráveis" da Solana — uma conveniência de UX projetada para permitir que usuários pré-assinem transações para submissão posterior — para enganar membros do Conselho de Segurança da Drift a autorizarem o que pensavam ser assinaturas operacionais de rotina. Essas assinaturas eventualmente entregaram o controle administrativo aos atacantes, que listaram um token de colateral falso (CVT), depositaram 500 milhões de unidades dele e retiraram 285 milhões em USDC, SOL e ETH reais. O recurso da Solana estava funcionando conforme projetado. Os contratos da Drift estavam fazendo o que seus administradores instruíram. O ataque viveu inteiramente na lacuna entre o que os signatários do multisig pensavam que estavam aprovando e o que realmente estavam.

Kelp DAO — $ 292 milhões, 18 de abril de 2026. Atacantes atribuídos pela LayerZero ao Lazarus Group da Coreia do Norte comprometeram dois nós RPC que sustentavam a ponte rsETH cross-chain da Kelp, trocaram os binários que rodavam neles e usaram um DDoS para forçar um failover de verificador. Os nós maliciosos então informaram ao verificador da LayerZero que uma transação fraudulenta havia ocorrido. O exploit só funcionou porque a Kelp operava uma configuração de verificador 1-de-1 — o que significa que uma única DVN operada pela LayerZero tinha autoridade unilateral para confirmar mensagens cross-chain. De acordo com a LayerZero, essa configuração 1-de-1 é o padrão em seu guia de início rápido e é usada atualmente por aproximadamente 40 % dos protocolos na rede. Em 46 minutos, um atacante drenou 116.500 rsETH — cerca de 18 % de todo o suprimento circulante — e isolou colaterais embrulhados em 20 chains. A Aave, que lista rsETH, foi forçada a uma crise de liquidez enquanto os depositantes corriam para a saída.

Nenhum dos ataques exigiu um bug de contrato inteligente. Ambos exigiram entender como uma configuração — fluxos de assinatura multisig, contagem padrão de DVNs, redundância de RPC — foi silenciosamente elevada de "detalhe operacional" para "premissa de segurança estrutural".

Por Que Auditorias Estáticas Ignoram Esta Classe de Bug

A auditoria tradicional de DeFi é otimizada para o modelo de ameaça errado. Empresas como Certik, OpenZeppelin, Trail of Bits e Halborn se destacam na revisão de código linha por linha e na execução de testes de invariantes contra uma versão de contrato congelada. Isso captura reentrância, erros de controle de acesso, estouros de inteiros e falhas do tipo OWASP.

But a classe de bugs introduzidos por atualizações possui três propriedades que derrotam esse fluxo de trabalho:

  1. Vive no comportamento de execução composto, não no código-fonte. A segurança de uma ponte depende da configuração do verificador de sua camada de mensagens, do conjunto de DVNs, da redundância de RPC dessas DVNs e da exposição ao slashing desses operadores. Nada disso está no Solidity que um auditor lê.

  2. É introduzido por mudanças, não pela implantação inicial. A ponte da Kelp presumivelmente parecia correta quando a LayerZero v2 foi integrada pela primeira vez. A contagem de DVNs tornou-se perigosa apenas à medida que o TVL cresceu o suficiente para valer a pena atacar e quando o Lazarus investiu no comprometimento da infraestrutura de RPC.

  3. Exige testes diferenciais comportamentais — respondendo "o invariante X foi preservado sob o novo caminho de código?" — o que nenhuma das principais empresas de auditoria transforma em um serviço pós-atualização programado. Você recebe uma auditoria pontual na versão 1.0 e uma auditoria pontual separada na versão 1.1, mas nenhuma afirmação contínua de que atualizar da 1.0 para a 1.1 não quebra propriedades nas quais a 1.0 dependia.

As estatísticas do primeiro trimestre de 2026 quantificam essa lacuna. O DeFi registrou 165,5milho~esemperdasem34incidentesemtodootrimestre.Apenasabrilproduziu165,5 milhões em perdas em 34 incidentes em todo o trimestre. Apenas abril produziu 606 milhões em 12 incidentes. O lado da implantação escalou — mais de $ 40 bilhões em novo TVL foram adicionados no primeiro trimestre — enquanto a capacidade de auditoria, a resposta a incidentes e a validação pós-implantação permaneceram praticamente estáveis. Algo tinha que ceder.

Três Forças Que Tornam 2026 o Ano em Que Isso se Torna Crítico em Escala

1. A cadência de atualizações acelerou em todas as camadas

Cada L1 e L2 está iterando mais rapidamente. A atualização Pectra do Ethereum está em implementação ativa, Fusaka e Glamsterdam estão em fase de design, e Solana, Sui e Aptos lançam mudanças na camada de execução em ciclos de várias semanas. Cada atualização no nível da blockchain pode alterar sutilmente a semântica de gas, os esquemas de assinatura ou a ordenação de transações de formas que impactam as suposições da camada de aplicação. O exploit da Drift é um exemplo claro — um recurso da Solana (nonces duráveis) destinado à conveniência da experiência do usuário (UX) tornou-se o vetor para uma invasão administrativa.

2. O restaking amplia a superfície de ataque das atualizações

A stack de restaking — EigenLayer (ainda com mais de 80 % do mercado), Symbiotic, Karak, Babylon, Solayer — adiciona uma terceira dimensão ao problema. Um único LRT como o rsETH está posicionado acima da EigenLayer, que por sua vez está acima do staking nativo de ETH. Cada camada lança suas próprias atualizações em seu próprio cronograma. Uma mudança na semântica de slashing da EigenLayer tem consequências implícitas para cada operador e cada LRT que consome a validação desse operador. Quando a ponte da Kelp foi drenada, o contágio ameaçou imediatamente o TVL da EigenLayer, porque os mesmos depositantes tinham uma exposição de re-hipotecagem de três camadas que nunca haviam sido forçados a modelar. O roadmap da EigenCloud, com suas expansões iminentes de EigenDA, EigenCompute e EigenVerify, apenas ampliará essa superfície.

3. A atividade de DeFi impulsionada por IA move-se mais rápido que a revisão humana

Stacks de agentes como XION, Brahma Console e Giza agora interagem com contratos atualizados na velocidade das máquinas. Enquanto um tesoureiro humano pode esperar dias após a atualização de um contrato antes de interagir novamente, um agente realiza backtests, integra-o e roteia capital através dele em poucas horas. Qualquer atualização que quebre silenciosamente um invariante é testada sob estresse por fluxos adversariais antes que um auditor humano possa revisá-la.

A Arquitetura Defensiva Começa a Surgir

A notícia encorajadora é que a comunidade de pesquisa em segurança não tem estado ociosa. As perdas de abril de 2026 catalisaram propostas concretas em quatro frentes.

Verificação formal contínua. A colaboração de longa data da Certora com a Aave — financiada como uma concessão de verificação contínua em vez de um compromisso único — é agora um modelo. O Certora Prover executa automaticamente provas de invariantes toda vez que um contrato é alterado, revelando falhas antes do merge. Halmos e HEVM oferecem caminhos alternativos de código aberto para o mesmo objetivo. Quando a verificação formal capturou recentemente uma vulnerabilidade em uma integração com a atualização Electra do Ethereum que as auditorias tradicionais haviam perdido, não foi um caso isolado; foi uma prévia.

Serviços de auditoria de diff de atualização. Spearbit, Zellic e Cantina começaram a pilotar serviços pagos que auditam o diff entre duas versões de contrato, não a nova versão isoladamente. O modelo trata cada atualização como uma nova atestação e examina explicitamente se os invariantes anteriores são preservados. O programa de subsídio de auditoria de $ 1 milhão da Fundação Ethereum, lançado em 14 de abril de 2026, com uma lista de parceiros que inclui Certora, Cyfrin, Dedaub, Hacken, Immunefi, Quantstamp, Sherlock, Spearbit, Zellic e Zokyo, visa em parte expandir a capacidade para exatamente este tipo de trabalho.

Engenharia de caos e monitoramento em tempo de execução. OpenZeppelin Defender e ferramentas emergentes estão integrando simulações de mainnet bifurcada (forked) em pipelines de CI, permitindo que os protocolos repliquem cenários adversariais contra cada atualização proposta. A disciplina é emprestada diretamente das práticas de SRE da Web2 — e já deveria ter chegado ao DeFi há muito tempo.

Custódias de atualização com bloqueio de tempo (Timelocks). O padrão Compound Timelock v3, onde cada atualização aprovada pela governança permanece em uma fila pública por um atraso fixo antes da execução, dá à comunidade tempo para identificar problemas que a revisão interna perdeu. Isso não evita bugs introduzidos por atualizações, mas ganha tempo para que sejam descobertos antes da exploração.

A Comparação com TradFi: Auditoria Contínua é a Norma Fora do DeFi

As finanças tradicionais resolveram o problema análogo décadas atrás. O SOC 2 Type II, o padrão ao qual a maioria dos provedores de serviços institucionais é submetida, não é uma atestação única; é uma janela de auditoria contínua de seis a doze meses. O framework de risco de contraparte de Basileia III exige que os bancos atualizem seus modelos de capital à medida que as exposições mudam, não anualmente. Um banco de custódia que atualizasse um sistema de liquidação não teria permissão para operar com base em "auditamos a v1; a v2 foi apenas uma pequena mudança".

A cultura predominante no DeFi — "audite uma vez, implante para sempre, re-audite apenas em grandes reescritas" — é a prática que a TradFi rejeitou explicitamente após a crise de 2008. Na taxa de perda atual, a indústria está a caminho de $ 2 bilhões ou mais em perdas anuais por exploits de atualização. Isso é grande o suficiente para atrair reguladores que já veem os padrões de auditoria DeFi como insuficientes, e é grande o suficiente para tornar a validação contínua uma pré-condição para o capital institucional.

O Que Isso Significa para Construtores, Depositantes e Infraestrutura

Para as equipes de protocolo, o mandato operacional é direto, mesmo que não seja barato: cada atualização deve ser tratada como um novo lançamento que re-deriva, e não herda, suas garantias de segurança. Isso significa re-auditorias programadas com base em diffs, especificações de verificação formal que acompanham cada proposta de governança e bloqueios de tempo (timelocks) significativos antes da execução. Significa publicar — ao estilo da Aave — um framework de risco em cascata quantificado que nomeie em quais protocolos você depende e como é sua exposição quando um deles falha.

Para os depositantes, a lição é que "este protocolo foi auditado" não é mais um sinal útil por si só. A pergunta correta é "quando foi a última execução de verificação contínua, contra quais invariantes e em qual versão do código implantado?". Protocolos que não conseguem responder a isso devem ter seus riscos precificados de acordo.

Para provedores de infraestrutura — operadores de RPC, indexadores, custodiantes — o incidente da Kelp é um aviso direto. O comprometimento ocorreu em dois nós de RPC cujos binários foram trocados silenciosamente. Qualquer pessoa que execute infraestrutura que participe da verificação cross-chain (DVNs, nós de oráculo, sequenciadores) agora faz parte do modelo de segurança, quer tenha se inscrito para isso ou não. Compilações reproduzíveis, binários atestados, quóruns multi-operadores acima dos padrões 1-de-1 e verificação de binários assinados na inicialização não são mais opcionais.

Atualizações no nível da blockchain — Pectra e Fusaka no Ethereum, lançamentos de execução paralela em Solana e Aptos, metas de rendimento de Glamsterdam — continuarão a ampliar a superfície. Os protocolos e operadores de infraestrutura que sobreviverem a 2026 serão aqueles que adotaram a validação contínua cedo o suficiente para que sua próxima atualização de rotina seja também seu próximo checkpoint de segurança comprovável.

A BlockEden.xyz opera infraestrutura de produção de RPC, indexadores e nós em Sui, Aptos, Ethereum, Solana e uma dezena de outras blockchains. Tratamos cada atualização de protocolo — na camada da blockchain ou na camada da aplicação — como um novo evento de segurança, não como uma tarefa de manutenção. Explore nossa infraestrutura empresarial para construir sobre uma base projetada para sobreviver à cadência de atualizações que temos pela frente.

Fontes

O Slashing da EigenLayer Está Ativo: Começa o Teste de Realidade de US$ 15 Bilhões em Restaking

· 13 min de leitura
Dora Noda
Software Engineer

Durante dois anos, a proposta da EigenLayer para os restakers tem sido simples: faça stake de ETH, proteja o protocolo de outra pessoa, receba rendimento extra. Os parâmetros de slashing existiam apenas no papel. Os operadores não podiam realmente perder capital por se comportarem mal em um AVS, porque o código que retiraria o seu stake ainda não tinha sido lançado. Essa era terminou em 17 de abril de 2026, quando a EigenLayer ativou o slashing de produção na mainnet.

Aproximadamente US$ 15 – 18 bilhões em ETH em restaking estão agora expostos a perdas criptoeconômicas reais pela primeira vez desde o lançamento do protocolo. A pergunta que os restakers, operadores, construtores de AVS e os mercados de empréstimo DeFi que detêm centenas de bilhões em dívidas garantidas por LST têm evitado educadamente por vinte de quatro meses está finalmente prestes a ser respondida: o rendimento de restaking é uma compensação por um trabalho de segurança real, ou é uma compensação por um risco que ninguém estava realmente correndo?

Dois Anos de Teatro de Slashing

A EigenLayer foi lançada na mainnet em 2023 com uma promessa clara. Os operadores fariam o restake de ETH para proteger Serviços Validados Ativamente (AVS) — redes de oráculos, pontes, camadas de disponibilidade de dados, coprocessadores — e, se se comportassem mal, o AVS poderia aplicar o slashing no seu stake. O modelo deveria criar um mercado unificado para segurança criptoeconômica, onde qualquer novo protocolo poderia pegar emprestado o conjunto de validadores do Ethereum em vez de inicializar um conjunto de validadores próprio.

O que realmente foi entregue foi a primeira metade dessa promessa. Os operadores podiam registrar-se, delegar e ganhar recompensas. A própria lógica de slashing foi substituída por parâmetros de preenchimento (placeholders). Ao longo de 2024 e na maior parte de 2025, um AVS que detectasse um operador assinando duplamente, censurando dados ou produzindo uma prova inválida não tinha uma forma ao nível do protocolo de confiscar o ETH desse operador. O número de "segurança passível de slashing" nos painéis era apenas aspiracional.

Isso não era segredo. A documentação da EigenLayer era explícita sobre a implementação em fases. Mas o efeito no comportamento dos operadores e nas expectativas dos restakers foi significativo. Um operador de AVS executando EigenDA, Hyperlane e Lagrange simultaneamente sabia que um bug de software, um desvio de oráculo ou mesmo um comportamento inadequado deliberado poderia custar-lhes o rendimento, mas não o capital principal. Os restakers, por sua vez, trataram o restaking como uma variante de maior rendimento do simples stake de ETH, em vez de um produto de risco fundamentalmente diferente.

O ELIP-002 — "Slashing via Unique Stake & Operator Sets" — foi o que finalmente mudou o cálculo. A atualização da mainnet de 17 de abril ativa os contratos que permitem que um AVS execute uma transação de slashing contra a alocação específica de um operador específico, com ETH real saindo de carteiras reais. A era dos marcadores de posição acabou.

O Que Realmente Entrou em Vigor

A atualização não é um interruptor único que corta cada operador no momento em que ocorre uma violação de especificação. É uma estrutura na qual os AVSs, operadores e restakers agora optam deliberadamente.

Conjuntos de Operadores (Operator Sets) são o novo primitivo central. Um AVS não tem mais um pool global de operadores protegendo-o. Em vez disso, ele define um ou mais Conjuntos de Operadores, cada um com as suas próprias regras de registro, atribuições de tarefas, condições de slashing e estrutura de recompensas. Um operador que queira proteger um AVS registra-se num Conjunto de Operadores específico e aceita explicitamente as condições de slashing associadas a esse conjunto.

Alocação de Stake Única (Unique Stake Allocation) é o modelo de contabilidade subjacente. Cada operador começa com uma Magnitude Total definida pelo protocolo (1 × 10^18 unidades) representando o seu stake delegado total. O operador aloca fatias dessa magnitude para diferentes Conjuntos de Operadores. Apenas o AVS que possui um determinado Conjunto de Operadores pode aplicar o slashing na fatia alocada a ele. Se o Conjunto de Operadores da EigenDA detém 40% da magnitude de um operador e o da Hyperlane detém 30%, um evento de slashing na EigenDA pode, no máximo, consumir esses 40% — o stake da Hyperlane é intocável para o slasher da EigenDA e vice-versa.

Opt-in por padrão é o mecanismo de implementação gradual. Operadores que já executam AVSs sob o regime pré-slashing não são inscritos automaticamente nos novos Conjuntos de Operadores. Eles têm de rever as condições de slashing de cada AVS, decidir quais são aceitáveis e optar por participar. Da mesma forma, os AVSs têm de escrever as suas condições de slashing e publicá-las para os operadores avaliarem. Na prática, isso significa que a exposição ao slashing aumentará ao longo de semanas e meses, à medida que os operadores e os AVSs migram do modelo antigo para os Conjuntos de Operadores, em vez de aparecer da noite para o dia como um único raio de impacto.

O token EIGEN adiciona um mecanismo separado para falhas "intersubjetivas" — comportamentos inadequados que não podem ser provados on-chain, mas que qualquer observador razoável concordaria que merecem uma penalidade. Quando uma super-maioria de stakers de EIGEN conspira para atacar um AVS de uma forma que um fork possa resolver, os desafiadores podem criar um fork de slashing do token. Isso é independente do slashing de ETH no ELIP-002 e visa uma classe diferente de falha.

Considerados em conjunto, o design é conservador de uma forma que importa. A Alocação de Stake Única isola o raio de impacto por AVS, o que aborda diretamente o risco de restaking mais citado: que um AVS com bugs e um circuito de slashing quebrado possa derrubar AVSs não relacionados por meio do stake compartilhado do operador. Esse modo de falha é agora estruturalmente mais difícil de desencadear.

A Questão Empírica que o Restaking tem Evitado

A EigenLayer detém atualmente entre 15,2bilho~ese15,2 bilhões e 19,7 bilhões em ativos de restaking, dependendo de como você contabiliza, dominando cerca de 94% do mercado de restaking. Mais de 4,3 milhões de ETH estão delegados. O protocolo garante mais de 20 AVSs, com EigenDA, Hyperlane e Lagrange gerando a maior parte da receita de taxas.

Esses números foram construídos durante um período em que o slashing era teórico. A questão empírica que a ativação de 17 de abril agora impõe é simples: quanto da segurança que esses AVSs têm "fornecido" era real?

Considere as duas possibilidades.

No primeiro cenário, os principais AVSs têm operado em alto nível o tempo todo. Seus operadores gerenciam infraestrutura de nível de produção, suas especificações de slashing capturam comportamentos inadequados genuínos e a taxa de slashing de base pós-ativação se estabiliza em algo significativamente acima do nível próximo de zero da Lido — talvez de 10 a 100 pontos-base anualizados, refletindo o fato de que proteger uma camada de DA ou uma bridge é um trabalho mais difícil do que validar blocos. Os rendimentos de restaking se reajustam para cima para compensar esse risco, e a tese de que o ETH em restaking fornece segurança econômica adicional se mantém.

No segundo cenário, muito do que pareceu segurança por dois anos foi, na verdade, uma coincidência de ausência de fiscalização. Os operadores têm coletado recompensas por executar serviços cujas especificações de slashing nunca foram testadas contra má conduta real. Assim que o slashing é ativado, uma de três coisas acontece: os AVSs descobrem que suas próprias especificações são muito frouxas e deixam passar comportamentos inadequados reais; eles descobrem que suas especificações são muito rígidas e punem operadores honestos devido a casos extremos que o ambiente de teste nunca revelou; ou os operadores, ao verem os primeiros eventos reais de slashing, concluem que o rendimento ajustado ao risco é pior do que o staking de ETH comum e retiram seus fundos.

A razão pela qual o segundo cenário é plausível é que ninguém foi disciplinado por perdas. AVSs que desejam parecer de alta segurança não tiveram como provar isso, e AVSs que foram negligentes não tiveram como ser pegos. Ambos parecem idênticos em um painel de controle. A ativação do slashing é o primeiro mecanismo que força a separação dos dois grupos.

A comparação que importa aqui é com a Lido. A Lido perdeu menos de 0,01% do ETH em staking para slashing na camada de consenso desde 2020. Esse é o referencial para "staking passivo", onde o único trabalho é seguir as regras de atestação que foram testadas por centenas de milhões de dólares em penalidades reais ao longo de cinco anos. Se os AVSs da EigenLayer estão realizando um trabalho genuinamente mais difícil — operando oráculos, bridges, camadas de DA, coprocessadores — suas taxas de slashing deveriam ser maiores que as da Lido, porque um trabalho mais difícil cria mais oportunidades de falha. Se as taxas de slashing pós-ativação convergirem para as da Lido, isso é uma evidência forte de que os AVSs não têm produzido a segurança adicional que suas taxas sugerem.

O Risco de Transmissão de LST

A EigenLayer não vive isolada. O maior LST individual em DeFi é o stETH da Lido, e o stETH é uma das formas de colateral mais amplamente aceitas no sistema de restaking. Camadeie isso sobre os principais mercados de empréstimo: Aave, Morpho e Spark juntos detêm mais de $ 30 bilhões em depósitos, uma parte significativa dos quais é stETH ou wstETH sendo usados como colateral para empréstimos de stablecoins.

A cadeia de exposição funciona assim. Um detentor de stETH faz o restaking na EigenLayer. O operador da EigenLayer ao qual ele delega executa um AVS que sofre um evento de slashing. Parte do lastro de stETH agora vale menos do que seu valor de resgate em ETH implicaria. Se o slashing for grande o suficiente para afetar significativamente a paridade do stETH com o ETH, as posições alavancadas de stETH na Aave e na Morpho começam a sofrer danos de liquidação. As liquidações forçam mais stETH no mercado, aprofundando o depeg e desencadeando mais liquidações. O ciclo de feedback que ameaçou brevemente o sistema em maio de 2022 — quando o stETH perdeu a paridade durante o colapso da UST — tem um novo gatilho potencial.

Vários fatores estruturais tornam isso menos assustador do que parece. A Alocação Única de Stake limita o raio de impacto a um AVS específico, em vez de permitir que uma falha se propague. A maioria dos AVSs possui limites de slashing bem abaixo de 100%, portanto, mesmo um evento de gravidade máxima consome apenas uma fração do stake em risco. As retiradas da Beacon Chain tornaram o resgate de stETH muito mais fluido do que era em 2022, reduzindo a sensibilidade ao depeg. E a rampa de entrada opcional (opt-in) significa que os primeiros eventos de slashing atingirão uma pequena fração da base total de restaking.

Mas o risco não é zero, e é maior do que a maioria dos usuários que detêm stETH como colateral de "rendimento seguro" entende. Qualquer pessoa operando stETH alavancado na Aave ou na Morpho agora tem uma nova variável exógena em seu cálculo de liquidação. Mutuários que antes não acompanhavam as condições de slashing dos AVSs agora estão indiretamente expostos a elas.

Como Devem Ser os Próximos Seis Meses

A resposta honesta é que ninguém sabe. Mas o formato do que observar está claro.

O primeiro evento real de slashing definirá a narrativa. Se atingir um grande AVS e o post-mortem revelar um bug na especificação em vez de má conduta genuína do operador, a confiança no modelo será abalada e os restakers começarão a fazer perguntas mais difíceis sobre a qualidade das especificações de cada AVS. Se atingir uma má conduta genuína e o sistema penalizar de forma limpa o mau operador enquanto deixa os operadores honestos intactos, a tese do restaking ganha um grande impulso de credibilidade. Ambos os resultados são possíveis e a diferença importa enormemente.

A receita de taxas dos AVSs irá se estratificar. AVSs que puderem demonstrar especificações de slashing robustas e comportamento limpo do operador comandarão rendimentos mais altos, porque os restakers os precificarão corretamente como provedores de segurança real. AVSs cujas especificações pareçam negligentes terão que se ajustar ou perderão operadores para alternativas melhor geridas. Espere que uma lacuna visível se abra entre os três primeiros e a cauda longa nos próximos dois trimestres.

Os operadores irão se consolidar. Operar AVSs com exposição real ao slashing exige infraestrutura e disciplina operacional que muitos operadores atuais não possuem. Espere que uma fração significativa de operadores menores saia em vez de absorver o risco. O mercado de operadores se concentrará em empresas que podem realmente defender sua superfície de slashing.

Os emissores de LRT terão que ser explícitos. Os Liquid Restaking Tokens — os produtos em forma de wrapper sobre a EigenLayer — historicamente têm sido vagos sobre quais AVSs o stake subjacente está protegendo. Pós-ativação, essa vagueza torna-se um passivo. Espere que os emissores de LRT publiquem transparência na alocação de AVS ou percam mercado para aqueles que o fazem.

A ativação não é uma crise. É o momento em que o restaking deixa de ser uma narrativa e passa a ser um produto com um modelo de risco real. Pela primeira vez desde 2023, a curva de rendimento do ETH em restaking será forçada a refletir o que está realmente acontecendo dentro dos AVSs, em vez do que os restakers imaginam que está acontecendo. Essa é uma transição saudável, e os protocolos que têm feito o trabalho correto serão beneficiados. Aqueles que têm apenas seguido o fluxo, não.

BlockEden.xyz fornece infraestrutura de RPC e indexação de nível empresarial para o Ethereum e seu ecossistema de restaking. Se você está construindo ou operando AVSs, LRTs ou ferramentas de monitoramento que precisam de acesso de baixa latência ao estado da EigenLayer, explore nosso marketplace de APIs para construir em uma infraestrutura projetada para a era do slashing em produção.

Fontes

Contratos Futuros de Blockspace de US$ 3 Bi: Como ETHGas e ether.fi Deram à Ethereum Sua Primeira Curva Futura

· 14 min de leitura
Dora Noda
Software Engineer

Por mais de uma década, a Ethereum precificou seu recurso mais importante da mesma forma que um mercado de peixes precifica o atum às 4 da manhã: quem grita mais alto no último segundo vence. A cada doze segundos, um novo leilão abre e fecha, sem nenhuma maneira de travar um preço no dia anterior, sem maneira de fazer hedge contra um pico e sem maneira de um validador saber como será a receita da próxima terça-feira.

Isso mudou em 15 de abril de 2026. A ETHGas e a ether.fi firmaram um acordo comercial de três anos e US$ 3 bilhões que introduz o primeiro mercado a termo sério para o espaço de bloco da Ethereum. A ether.fi, o maior protocolo de staking líquido fora o Lido, com 2,8 milhões de ETH sob gestão, está comprometendo aproximadamente 40% de suas participações no serviço de Staking de Alto Desempenho da ETHGas. Em troca, a ETHGas obtém a profundidade de validadores de que precisa para vender algo que a Ethereum nunca teve: um assento garantido e com preço pré-definido em um bloco que ainda não foi construído.

Parece encanamento. É encanamento. Mas também foram os primeiros contratos futuros de gás natural em 1990, e eles acabaram remodelando a forma como todas as companhias aéreas, concessionárias e compradores industriais do planeta fazem negócios.

Restaking no Ethereum e o “Security-as-a-Service” da EigenLayer

· 52 min de leitura
Dora Noda
Software Engineer

O Restaking Explicado: No modelo proof-of-stake do Ethereum, os validadores normalmente fazem o staking de ETH para proteger a rede e ganhar recompensas, com o risco de slashing se agirem de má fé. O restaking permite que esse mesmo ETH em staking (ou seus derivativos de staking líquido) seja reutilizado para proteger protocolos ou serviços adicionais. A EigenLayer introduziu o restaking por meio de contratos inteligentes que permitem aos stakers de ETH fazer o opt-in para estender sua segurança a novos sistemas em troca de rendimento extra. Na prática, um validador do Ethereum pode se registrar na EigenLayer e conceder aos seus contratos permissão para impor condições de slashing adicionais especificadas por protocolos externos. Se o validador agir de forma maliciosa em qualquer serviço em que tenha feito o opt-in, os contratos da EigenLayer podem aplicar o slashing em seu ETH em staking, exatamente como o Ethereum faria por violações de consenso. Esse mecanismo transforma efetivamente a robusta segurança de staking do Ethereum em uma “Segurança como Serviço” (Security-as-a-Service) composível: os desenvolvedores podem pegar emprestada a segurança econômica do Ethereum para inicializar novos projetos, em vez de começar sua própria rede de validadores do zero. Ao aproveitar os mais de 31M+ de ETH que já protegem o Ethereum, o restaking da EigenLayer cria um mercado de “segurança compartilhada” (pooled security) onde vários serviços compartilham a mesma base de capital confiável.

A Abordagem da EigenLayer: A EigenLayer é implementada como um conjunto de contratos inteligentes no Ethereum que coordenam esse processo de restaking. Validadores (ou detentores de ETH) que desejam fazer o restaking depositam seus tokens de staking líquido ou, no caso de stakers nativos, redirecionam suas credenciais de retirada para um contrato gerenciado pela EigenLayer (frequentemente chamado de EigenPod). Isso garante que a EigenLayer possa aplicar o slashing ao bloquear ou queimar o ETH subjacente, se necessário. Os restakers sempre mantêm a propriedade de seu ETH (sacável após um período de saída/custódia), mas fazem o opt-in para novas regras de slashing além das do Ethereum. Em troca, eles tornam-se elegíveis para recompensas de restaking adicionais pagas pelos serviços que protegem. O resultado final é uma camada de segurança modular: o conjunto de validadores e o stake do Ethereum são “alugados” para protocolos externos. Como diz o fundador da EigenLayer, Sreeram Kannan, isso cria uma “Nuvem Verificável” para a Web3 – de forma análoga a como a AWS oferece serviços de computação, a EigenLayer oferece segurança como serviço para desenvolvedores. A adoção inicial tem sido forte: em meados de 2024, mais de 4,9 milhões de ETH (~ $15B) haviam passado pelo processo de restaking na EigenLayer, demonstrando a demanda dos stakers para maximizar o rendimento e de novos protocolos para inicializar com o mínimo de custo fixo. Em resumo, o restaking no Ethereum reaproveita a confiança existente (ETH em staking) para proteger novas aplicações, e a EigenLayer fornece a infraestrutura para tornar esse processo composível e sem permissão.

Padrões de Design de Serviços de Validação Ativa (AVSs)

O que são AVSs? Serviços de Validação Ativa (Actively Validated Services - AVSs) referem-se a qualquer serviço ou rede descentralizada que requer seu próprio conjunto de validadores e regras de consenso, mas que pode terceirizar a segurança para uma plataforma de restaking como a EigenLayer. Em outras palavras, um AVS é um protocolo externo (fora da L1 do Ethereum) que contrata os validadores do Ethereum para realizar algum trabalho de verificação. Exemplos incluem sidechains ou rollups, camadas de disponibilidade de dados, redes de oráculos, pontes (bridges), sequenciadores compartilhados, módulos de computação descentralizada e muito mais. Cada AVS define uma tarefa de validação distribuída única – por exemplo, um oráculo pode exigir a assinatura de feeds de preços, enquanto uma cadeia de disponibilidade de dados (como a EigenDA) exige o armazenamento e a atestação de blobs de dados. Esses serviços executam seu próprio software e possivelmente seu próprio consenso entre os operadores participantes, mas dependem da segurança compartilhada: o stake econômico que os sustenta é fornecido pelo ETH em restaking (ou outros ativos) dos validadores do Ethereum, em vez de um token nativo para cada nova rede.

Arquitetura e Funções: A arquitetura da EigenLayer separa claramente as funções neste modelo de segurança compartilhada:

  • Restakers – Stakers de ETH (ou detentores de LST) que fazem o opt-in para proteger AVSs. Eles depositam nos contratos da EigenLayer, estendendo seu capital em staking como colateral para múltiplos serviços. Os restakers podem escolher quais AVSs apoiar, diretamente ou via delegação, e ganham recompensas desses serviços. Crucialmente, eles arcam com o risco de slashing se qualquer AVS apoiado relatar comportamento indevido.

  • Operadores – Operadores de nós que realmente executam o software cliente off-chain para cada AVS. Eles são análogos aos mineradores/validadores da rede do AVS. Na EigenLayer, um operador deve se registrar e ser aprovado (inicialmente em uma whitelist) para participar, e pode então fazer o opt-in para servir AVSs específicos. Os restakers delegam seu stake aos operadores (se eles próprios não executarem nós), de modo que os operadores agregam stake de potencialmente muitos restakers. Cada operador está sujeito às condições de slashing de qualquer AVS que apoie, e ganha taxas ou recompensas por seu serviço. Isso cria um mercado de operadores competindo em desempenho e confiabilidade, já que os AVSs preferirão operadores competentes e os restakers preferirão aqueles que maximizam as recompensas sem incorrer em slashing.

  • AVS (Actively Validated Service) – O próprio protocolo ou serviço externo, que normalmente consiste em dois componentes: (1) um binário ou cliente off-chain que os operadores executam para realizar o serviço (ex: um software de nó de sidechain), e (2) um contrato de AVS on-chain implantado no Ethereum que faz a interface com a EigenLayer. O contrato do AVS no Ethereum codifica as regras para o slashing e a distribuição de recompensas desse serviço. Por exemplo, ele pode definir que, se duas assinaturas conflitantes forem enviadas (prova de equivocação por um operador), um slash de X ETH é executado no stake desse operador. O contrato do AVS se conecta aos gestores de slashing da EigenLayer para efetivamente penalizar o ETH em restaking quando ocorrem violações. Assim, cada AVS pode ter lógica de validação e condições de falha personalizadas, enquanto conta com a EigenLayer para aplicar punições econômicas usando o stake compartilhado. Esse design permite que os desenvolvedores de AVS inovem em novos modelos de confiança (mesmo novos mecanismos de consenso ou serviços criptográficos) sem reinventar um token de vinculação/slashing para segurança.

  • Consumidores/Usuários de AVS – Finalmente, os usuários finais ou outros protocolos que consomem a saída do AVS. Por exemplo, um dApp pode usar um AVS de oráculo para dados de preços ou um rollup pode postar dados em um AVS de disponibilidade de dados. Os consumidores pagam taxas ao AVS (muitas vezes financiando as recompensas que restakers/operadores ganham) e dependem de sua correção, que é garantida pela segurança econômica que o AVS alugou do Ethereum.

Aproveitando a Segurança Compartilhada: A beleza deste modelo é que até mesmo um serviço totalmente novo pode começar sua vida com garantias de segurança de nível Ethereum. Em vez de recrutar e incentivar um novo conjunto de validadores, um AVS utiliza um conjunto de validadores experiente e economicamente vinculado desde o primeiro dia. Cadeias menores ou módulos que seriam inseguros sozinhos tornam-se seguros ao aproveitarem a estrutura do Ethereum. Essa segurança compartilhada aumenta significativamente o custo para atacar qualquer AVS individual – um invasor precisaria adquirir e fazer o staking de grandes quantidades de ETH (ou outro colateral na whitelist) e depois correr o risco de perdê-lo via slashing. Como muitos serviços compartilham o mesmo pool de ETH em restaking, eles formam efetivamente um guarda-chuva de segurança compartilhada: o peso econômico combinado do stake desencoraja ataques a qualquer um deles. Do ponto de vista de um desenvolvedor, isso modulariza a camada de consenso – você se concentra na funcionalidade do seu serviço enquanto a EigenLayer cuida da segurança dele com um conjunto de validadores existente. Os AVSs podem, portanto, ser muito diversos. Alguns são serviços “horizontais” de uso geral que muitos dApps poderiam usar (ex: um sequenciador descentralizado genérico ou uma rede de computação off-chain), enquanto outros são “verticais” ou específicos de aplicação (ajustados para um nicho como uma ponte específica ou um oráculo DeFi). Exemplos iniciais de AVSs na EigenLayer abrangem disponibilidade de dados (ex: EigenDA), sequenciamento compartilhado para rollups (ex: Espresso, Radius), redes de oráculos (ex: eOracle), pontes cross-chain (ex: Polymer, Hyperlane), computação off-chain (ex: Lagrange para provas ZK) e muito mais. Todos esses aproveitam a mesma base de confiança do Ethereum. Em resumo, um AVS é essencialmente um módulo plugável que terceiriza a confiança para o Ethereum: ele define o que os validadores devem fazer e o que constitui uma falha passível de slashing, e a EigenLayer aplica essas regras em um pool de ETH que é usado globalmente para proteger muitos desses módulos.

Mecanismos de Incentivo para Restakers, Operadores e Desenvolvedores

Um design de incentivo robusto é fundamental para alinhar todas as partes em um ecossistema de restaking. O EigenLayer e plataformas similares criam um "ganha-ganha-ganha" ao oferecer novas receitas para stakers e operadores, enquanto reduzem os custos para protocolos emergentes. Vamos detalhar os incentivos por função:

  • Incentivos para Restakers: Os restakers são motivados principalmente pelo rendimento (yield). Ao optar pelo EigenLayer, um staker de ETH pode ganhar recompensas extras além do seu rendimento padrão de staking de Ethereum. Por exemplo, um validador com 32 ETH em staking na beacon chain do Ethereum continua ganhando o APR base de ~ 4-5 %, mas se ele fizer o restaking via EigenLayer, pode simultaneamente ganhar taxas ou recompensas em tokens de múltiplas AVSs que ajuda a proteger. Esse "double dipping" aumenta dramaticamente os retornos potenciais para os validadores. Na fase inicial do EigenLayer, os restakers receberam pontos de incentivo que foram convertidos em airdrops de tokens EIGEN (para bootstrap); mais tarde, um mecanismo de recompensa contínua (Incentivos Programáticos) foi lançado, distribuindo milhões de tokens EIGEN para restakers como liquidity mining. Além dos incentivos em tokens, os restakers se beneficiam da diversificação de renda – em vez de depender apenas das recompensas de bloco do Ethereum, eles podem ganhar em vários tokens de AVS ou taxas. É claro que essas recompensas mais altas vêm com maior risco (maior exposição a slashing), portanto, restakers racionais só optarão por AVSs que acreditam ser bem gerenciadas. Isso cria uma verificação baseada no mercado: as AVSs devem oferecer recompensas atraentes o suficiente para compensar o risco, ou os restakers as evitarão. Na prática, muitos restakers delegam para operadores profissionais, então eles também podem pagar uma comissão ao operador a partir de suas recompensas. Mesmo assim, os restakers têm a ganhar significativamente ao monetizar a capacidade de segurança anteriormente ociosa de seu ETH em staking. (Notavelmente, o EigenLayer relata que mais de 88 % de todos os EIGEN distribuídos foram diretamente para staking / delegação novamente – indicando que os restakers estão ansiosos para capitalizar suas posições.)

  • Incentivos para Operadores: Os operadores no EigenLayer são os provedores de serviço que realizam o trabalho pesado de rodar nós para cada AVS. O incentivo deles é a receita de taxas ou a participação nas recompensas pagas por essas AVSs. Normalmente, uma AVS pagará recompensas (em ETH, stablecoins ou seu próprio token) para todos os validadores que a protegem; os operadores recebem essas recompensas em nome do stake que hospedam e geralmente ficam com uma porcentagem (como uma comissão) por fornecer a infraestrutura. O EigenLayer permite que os restakers deleguem para operadores, de modo que os operadores competem para atrair o máximo de ETH em restaking possível – quanto mais stake delegado, mais tarefas eles podem realizar e mais taxas são ganhas. Essa dinâmica incentiva os operadores a serem altamente confiáveis e a se especializarem em AVSs que podem operar com eficiência (para evitar o slashing e maximizar o tempo de atividade). Um operador com boa reputação pode garantir uma delegação maior e, consequentemente, recompensas totais maiores. É importante destacar que os operadores enfrentam penalidades de slashing por má conduta, assim como os restakers (já que o stake que eles carregam pode ser cortado), alinhando seu comportamento com a execução honesta. O design do EigenLayer cria efetivamente um mercado aberto para serviços de validador: as equipes de AVS podem "contratar" operadores oferecendo recompensas, e os operadores escolherão as AVSs que são lucrativas em relação ao risco. Por exemplo, um operador pode se concentrar em rodar uma AVS de oráculo se ela tiver taxas altas, enquanto outro pode rodar uma AVS de camada de dados que exige muita largura de banda, mas paga bem. Com o tempo, esperamos um equilíbrio de mercado livre, onde os operadores escolhem o melhor mix de AVSs e definem uma divisão de taxas apropriada com seus delegadores. Isso contrasta com o staking tradicional de uma única rede, onde os validadores têm deveres fixos – aqui, eles podem realizar multitarefas entre serviços para acumular ganhos. O incentivo para os operadores é, portanto, maximizar seus ganhos por unidade de colateral em staking, sem sobrecarregar-se a ponto de sofrer slashing. É um equilíbrio delicado que deve impulsionar a profissionalização e talvez até soluções de seguro ou hedge (operadores podem fazer seguros contra slashing para proteger seus delegadores, etc.).

  • Incentivos para Desenvolvedores de AVS: Os desenvolvedores de protocolos (as equipes que constroem novas AVSs ou redes) possivelmente têm mais a ganhar com o modelo de "terceirização de segurança" do restaking. Seu principal incentivo é a economia de custo e tempo: eles não precisam lançar um novo token com alta inflação ou convencer milhares de validadores independentes a proteger sua rede do zero. Fazer o bootstrap de uma rede PoS normalmente exige dar grandes recompensas em tokens aos validadores iniciais (diluindo a oferta) e ainda pode resultar em segurança fraca se o valor de mercado do token for baixo. Com a segurança compartilhada, uma nova AVS pode entrar em operação protegida pelos mais de $ 200 bilhões em segurança econômica do Ethereum, tornando ataques economicamente inviáveis instantaneamente. Este é um grande atrativo para projetos de infraestrutura como bridges ou oráculos que precisam de fortes garantias de segurança. Além disso, os desenvolvedores podem focar na lógica de sua aplicação e confiar no EigenLayer (ou Karak, etc.) para o gerenciamento do conjunto de validadores, reduzindo drasticamente a complexidade. Economicamente, embora a AVS deva pagar pela segurança, ela muitas vezes pode fazer isso de uma forma mais sustentável. Em vez de uma inflação enorme, ela pode redirecionar taxas do protocolo ou oferecer uma modesta remuneração em token nativo. Por exemplo, uma AVS de bridge poderia cobrar taxas dos usuários em ETH e usá-las para pagar os restakers, alcançando segurança sem imprimir tokens sem lastro. Uma análise recente observa que eliminar a necessidade de "mecanismos de recompensa altamente diluidores" foi uma motivação fundamental por trás do design de restaking universal do Karak. Essencialmente, a segurança compartilhada permite o "bootstrap com orçamento limitado". Além disso, se a AVS tiver um token, ele pode ser usado mais para governança ou utilidade do que puramente para gastos com segurança. Os desenvolvedores também são incentivados pelos efeitos de rede: ao se conectarem a um hub de restaking, seu serviço pode interoperar mais facilmente com outras AVSs (usuários e operadores compartilhados) e ganhar exposição à grande comunidade de stakers de Ethereum. O outro lado é que as equipes de AVS devem projetar esquemas de recompensa atraentes para atrair restakers e operadores no mercado aberto. Isso geralmente significa oferecer inicialmente rendimentos generosos ou incentivos em tokens para impulsionar a participação – de forma semelhante ao liquidity mining no DeFi. Por exemplo, o próprio EigenLayer distribuiu o token EIGEN amplamente para stakers / operadores iniciais para incentivar a participação. Vemos padrões semelhantes com novas plataformas de restaking (por exemplo, a campanha XP do Karak para futuros tokens $ KAR). Em resumo, os desenvolvedores de AVS trocam a entrega de algumas recompensas aos stakers de Ethereum para evitar o problema do início do zero de proteger uma nova rede. O ganho estratégico é um tempo de chegada ao mercado mais rápido e maior segurança desde o primeiro dia, o que pode ser uma vantagem decisiva, especialmente para infraestruturas críticas como bridges cross-chain ou serviços financeiros que exigem confiança.

Riscos Regulatórios e Preocupações de Governança

Incerteza Regulatória: O novo modelo de restaking existe em uma zona cinzenta jurídica, levantando várias questões regulatórias. Uma preocupação é se a oferta de “segurança como serviço” poderia ser vista pelos reguladores como uma oferta de valores mobiliários não registrada ou uma forma de produto de investimento de alto risco. Por exemplo, a distribuição do token EIGEN por meio de um airdrop para stakers e recompensas contínuas atraiu escrutínio sobre a conformidade com as leis de valores mobiliários. Os projetos devem ter cuidado para que seus tokens ou esquemas de recompensa não acionem definições de valores mobiliários (por exemplo, o teste de Howey nos EUA). Além disso, os protocolos de restaking agregam e realocam stakes entre redes, o que pode ser visto como uma forma de investimento coletivo ou até mesmo uma atividade bancária se não for devidamente descentralizada. A equipe da EigenLayer reconhece o risco regulatório, observando que a mudança nas leis pode impactar a viabilidade do restaking e que a EigenLayer “pode ser classificada como uma atividade financeira ilegal em algumas regiões”. Isso significa que os reguladores podem determinar que a entrega do controle de slashing para serviços de terceiros (AVSs) viola as regras financeiras ou de proteção ao consumidor, especialmente se usuários de varejo estiverem envolvidos. Outro ângulo são as sanções / AML : o restaking move o stake para contratos que então validam outras cadeias – se uma dessas cadeias estiver processando transações ilícitas ou estiver sob sanção, os validadores de Ethereum poderiam, inadvertidamente, violar as normas de conformidade? Isso permanece não testado. Até agora, não existem regulamentações claras visando especificamente o restaking, mas a postura em evolução sobre o staking de cripto (por exemplo, as ações da SEC contra serviços de staking centralizados) sugere que o restaking pode atrair escrutínio à medida que cresce. Projetos como a EigenLayer adotaram uma abordagem cautelosa – por exemplo, o token EIGEN foi inicialmente não transferível no lançamento para evitar negociações especulativas e possíveis problemas regulatórios. No entanto, até que os marcos sejam definidos, as plataformas de restaking operam com o risco de que novas leis ou fiscalizações possam impor restrições (como exigir a acreditação dos participantes, divulgações ou até mesmo proibir certos tipos de restaking cross-chain).

Preocupações de Governança e Consenso: O restaking introduz desafios de governança complexos, tanto no nível do protocolo quanto para o ecossistema Ethereum mais amplo:

  • Sobrecarregar o Consenso Social do Ethereum: Uma preocupação proeminente, expressa por Vitalik Buterin, é que os usos estendidos do conjunto de validadores do Ethereum poderiam, inadvertidamente, arrastar o próprio Ethereum para disputas externas. A advertência de Vitalik: “O uso dual do ETH em stake do validador, embora tenha alguns riscos, é fundamentalmente bom, mas tentar ‘recrutar’ o consenso social do Ethereum para os propósitos da sua própria aplicação não é.”. Em termos simples, é aceitável se os validadores do Ethereum também validarem, digamos, uma rede de oráculos e forem penalizados (slashed) individualmente por mau comportamento lá (sem efeito no consenso do Ethereum). O que é perigoso é se um protocolo externo esperar que a comunidade Ethereum ou o protocolo principal intervenha para resolver algum problema (por exemplo, para realizar um fork para remover validadores que se comportaram mal no serviço externo). O design da EigenLayer tenta conscientemente evitar esse cenário, mantendo as falhas passíveis de slashing objetivas e isoladas. As condições de slashing são criptográficas (por exemplo, prova de assinatura dupla) e não exigem a intervenção da governança do Ethereum – assim, qualquer punição é autocontida no contrato da EigenLayer e não envolve o Ethereum alterando seu estado ou regras. Em casos de falhas subjetivas (onde o julgamento humano é necessário, por exemplo, para uma disputa de preços de oráculo), a EigenLayer planeja usar sua própria governança (por exemplo, uma votação do token EIGEN ou um conselho) em vez de sobrecarregar a camada social do Ethereum. Essa separação é fundamental para manter a neutralidade do Ethereum. No entanto, à medida que o restaking cresce, existe um risco sistêmico de que, se ocorresse um incidente grave (como um bug causando slashing em massa de uma enorme parte dos validadores), a comunidade Ethereum poderia ser pressionada a responder (por exemplo, revertendo os slashes). Isso emaranharia o Ethereum no destino de AVSs externos – exatamente o que Vitalik alerta contra. O risco de consenso social, portanto, refere-se principalmente a casos extremos de “cisne negro”, mas ressalta a importância de manter o núcleo do Ethereum minimalista e não envolvido na governança do restaking.

  • Cascateamento de Slashing e Segurança do Ethereum: Relacionadamente, existe a preocupação de que eventos de slashing no restaking possam cascatear e comprometer o Ethereum. Se um AVS muito popular (com muitos validadores) sofresse uma falha catastrófica levando ao slashing em massa, milhares de validadores de ETH poderiam perder seu stake ou ser forçados a sair. Em um cenário de pior caso, se stake suficiente for penalizado, o próprio conjunto de validadores do Ethereum poderia encolher ou se centralizar rapidamente. Por exemplo, imagine que um operador importante da EigenLayer que gerencia 10% de todos os validadores sofra slashing em um AVS – esses validadores poderiam ficar offline após perder fundos, reduzindo a segurança do Ethereum. A Chorus One (um serviço de staking) analisou a EigenLayer e observou que esse risco de cascata é exacerbado se o mercado de restaking levar a apenas alguns grandes operadores dominantes. A boa notícia é que, historicamente, o slashing no Ethereum é raro e geralmente em pequena escala. A EigenLayer também limitou inicialmente a quantidade de stake e desativou o slashing enquanto o sistema era novo. Em abril de 2025, a EigenLayer ativou o slashing na mainnet com monitoramento cuidadoso. Para mitigar ainda mais slashes não intencionais (por exemplo, devido a bugs), a EigenLayer introduziu “comitês de veto de slashing” – essencialmente uma multi-sig de especialistas que podem anular um slashing se parecer ser um erro ou um ataque ao protocolo. Esta é uma medida de centralização temporária, mas aborda o risco de um contrato inteligente de AVS defeituoso causar estragos. Com o tempo, tais comitês poderiam ser substituídos por uma governança mais descentralizada ou dispositivos de segurança.

  • Centralização do Restaking e da Governança: Uma preocupação fundamental de governança é quem controla o protocolo de restaking e seus parâmetros. Nos estágios iniciais da EigenLayer, as atualizações e decisões críticas eram controladas por uma multisig da equipe e da comunidade próxima (por exemplo, uma multisig 9-de-13). Isso é prático para a segurança do desenvolvimento rápido, mas é um risco de centralização – esses detentores de chaves poderiam coludir ou ser comprometidos para alterar as regras de forma maliciosa (por exemplo, para roubar fundos em stake). Reconhecendo isso, a EigenLayer estabeleceu uma estrutura formal de EigenGov no final de 2024, introduzindo um Conselho do Protocolo de especialistas e um processo de governança comunitária para mudanças. O conselho agora controla as atualizações por meio de uma multisig 3-de-5, com supervisão da comunidade. Com o tempo, a intenção é evoluir para a governança dos detentores de tokens ou um modelo totalmente descentralizado. Ainda assim, em qualquer sistema de restaking, as decisões de governança (como quais novas garantias apoiar, qual AVS “abençoar” com status oficial, como as disputas de slashing são resolvidas) carregam riscos elevados. Existe um conflito de interesses potencial: grandes provedores de staking (como a Lido ou exchanges) poderiam influenciar a governança para favorecer seus operadores ou ativos. De fato, a concorrência está surgindo – por exemplo, os fundadores da Lido apoiando a Symbiotic, uma plataforma de restaking multi-ativos – e pode-se imaginar guerras de governança se, por exemplo, surgir uma proposta para banir um certo AVS que seja visto como arriscado. A própria camada de restaking precisa de uma governança robusta para gerenciar tais questões de forma transparente.

  • Centralização de Validadores: Do lado operacional, há a preocupação de que os AVSs escolham preferencialmente grandes operadores, causando centralização em quem realmente valida a maioria dos serviços de restaking. Se, por eficiência, muitas equipes de AVS selecionarem todas um punhado de validadores profissionais (por exemplo, grandes empresas de staking) para atendê-las, essas entidades ganham um poder desproporcional e uma parcela maior das recompensas. Elas poderiam então subcotar outras oferecendo melhores condições (graças às economias de escala), potencialmente se transformando em um oligopólio. Isso reflete preocupações no staking nativo de Ethereum (por exemplo, a dominância da Lido). O restaking poderia amplificar isso, já que os operadores que executam múltiplos AVSs têm mais fluxos de receita. Essa é tanto uma preocupação econômica quanto de governança – pode exigir limites impostos pela comunidade ou incentivos para encorajar a descentralização (por exemplo, a EigenLayer poderia limitar quanto stake um operador pode controlar, ou os AVSs poderiam ser obrigados a distribuir suas atribuições). Sem verificações, a dinâmica de que “o rico fica mais rico” poderia levar a alguns poucos operadores de nós controlando efetivamente grandes partes do conjunto de validadores do Ethereum em muitos serviços, o que é prejudicial para a descentralização. A comunidade está discutindo ativamente tais questões, e alguns propuseram que os protocolos de restaking incluam mecanismos para favorecer operadores menores ou impor a diversidade (talvez por meio da estratégia de delegação ou através da coordenação social pelas comunidades de stakers).

Em resumo, embora o restaking desbloqueie uma inovação tremenda, ele também introduz novos vetores de risco. Os reguladores estão observando se isso representa produtos de rendimento não regulamentados ou se apresenta perigos sistêmicos. A liderança do Ethereum enfatiza a importância de não emaranhar a governança da camada base nesses novos usos. A comunidade EigenLayer e outros responderam com um design cuidadoso (apenas slashing objetivo, tokens de dois níveis para diferentes tipos de falha, verificação de AVSs, etc.) e controle central provisório para evitar acidentes. Os desafios contínuos de governança incluem descentralizar o controle sem sacrificar a segurança, garantir a participação aberta em vez da concentração e estabelecer marcos legais claros. À medida que essas redes de restaking amadurecem, espere que estruturas de governança aprimoradas e, possivelmente, padrões da indústria ou regulamentações surjam para abordar essas preocupações.

EigenLayer vs. Karak vs. Babylon: Uma Análise Comparativa

O cenário de restaking / segurança compartilhada agora inclui várias estruturas com designs diferentes. Aqui comparamos EigenLayer, Karak Network e Babylon – destacando suas arquiteturas técnicas, modelos econômicos e foco estratégico:

Arquitetura Técnica e Base de Segurança: O EigenLayer é um protocolo nativo do Ethereum (contratos inteligentes na L1 do Ethereum) que utiliza ETH em staking (e os equivalentes Tokens de Staking Líquido) como colateral de segurança. Ele se apoia na beacon chain do Ethereum – os validadores optam por participar via contratos no Ethereum, e o slashing é aplicado em seu saldo de ETH. Isso significa que a segurança do EigenLayer está fundamentalmente ligada ao PoS do Ethereum e ao valor do ETH. Em contraste, o Karak posiciona-se como uma "camada de restaking universal" não vinculada a uma única rede base. O Karak lançou sua própria blockchain L1 (com compatibilidade EVM) otimizada para serviços de segurança compartilhada. O modelo do Karak é agnóstico em relação à rede e ao ativo: ele permite o restaking de muitos tipos de ativos em várias redes, não apenas ETH. O colateral suportado inclui, supostamente, ETH e LSTs, além de outros ERC-20s (stablecoins como USDC / sDAI, tokens de LP e até outros tokens de L1). Isso significa que a base de segurança do Karak é uma cesta diversificada; a validação no Karak poderia ser apoiada por, por exemplo, uma combinação de ETH em staking, SOL em staking (se houver ponte), stablecoins, etc., dependendo do que o AVS (ou “VaaS” na terminologia do Karak) aceitar. O Babylon segue um caminho diferente: ele aproveita a segurança do Bitcoin (BTC) – o maior ativo cripto – para proteger outras redes. O Babylon foi construído como uma rede baseada em Cosmos (Babylon Chain) que se conecta ao Bitcoin e a redes PoS via protocolo IBC. Os detentores de BTC bloqueiam BTC nativo na rede principal do Bitcoin (em um cofre inteligente com trava de tempo) e, assim, fazem "staking" de BTC no Babylon, que então usa isso como colateral para proteger redes PoS consumidoras. Assim, a base de segurança do Babylon é o valor do Bitcoin (com mais de $ 500 B de capitalização de mercado), acessado de forma trustless (sem BTC embrulhado ou custodiantes – ele utiliza scripts do Bitcoin para aplicar o slashing). Em resumo, o EigenLayer depende da segurança econômica do Ethereum, o Karak é multiativo e multirrede (uma camada genérica para qualquer colateral), e o Babylon estende a segurança proof-of-work do Bitcoin para ecossistemas PoS.

Mecanismo de Restaking: No EigenLayer, o restaking é opcional via contratos Ethereum; o slashing é programático e aplicado pelo consenso do Ethereum (respeitando os contratos do EigenLayer). O Karak, como uma L1 independente, mantém sua própria lógica de restaking em sua rede. O Karak introduziu o conceito de Validação como Serviço (VaaS) – análogo ao AVS do EigenLayer – mas com um marketplace universal de validadores entre redes. Os validadores (operadores) do Karak executam sua rede e qualquer número de Serviços de Segurança Distribuídos (DSS), que são o equivalente do Karak aos AVSs. Um DSS pode ser uma nova blockchain específica para um aplicativo ou um serviço que aluga segurança do pool de ativos em staking do Karak. A inovação do Karak é padronizar os requisitos para que qualquer rede ou aplicativo (Ethereum, Solana, uma L2, etc.) possa se conectar e usar sua rede de validadores e colaterais variados. O slashing no Karak seria gerenciado por suas regras de protocolo – como ele permite staking de, por exemplo, USDC, presume-se que cortaria o USDC de um validador se ele se comportar mal em um serviço (a mecânica exata de slashing multiativo é complexa e não é pública, mas a ideia é semelhante: cada colateral pode ser retirado se as violações forem comprovadas). O mecanismo do Babylon é único devido às limitações do Bitcoin: o Bitcoin não suporta contratos inteligentes para o slashing automático, então o Babylon usa truques criptográficos. O BTC é bloqueado em uma saída especial que requer uma chave. Se um participante do staking de BTC trapacear (por exemplo, assinar dois blocos conflitantes em uma rede cliente), o protocolo utiliza um esquema de assinatura única extraível (EOTS) para revelar a chave privada do participante, permitindo que seu BTC bloqueado seja enviado para um endereço de queima. Em termos mais simples, o mau comportamento faz com que o staker de BTC efetivamente se puna (slashing), pois o ato de trapacear entrega o controle de seu depósito (que é então destruído). A rede baseada em Cosmos do Babylon coordena esse processo e se comunica com redes parceiras (via IBC) para fornecer serviços como checkpointing e finalidade usando os carimbos de data/hora (timestamps) do BTC. No Babylon, os validadores da rede Babylon (chamados de provedores de finalidade) são separados – eles executam o consenso do Babylon e auxiliam no retransmissão de informações para o Bitcoin – mas não fornecem segurança econômica; a segurança econômica vem puramente do BTC bloqueado.

Modelo Econômico e Recompensas: O modelo econômico do EigenLayer está centrado na economia de staking do Ethereum. Os restakers ganham recompensas específicas de AVS – que podem ser pagas em taxas de ETH, no token próprio do AVS ou em outros tokens, dependendo do design de cada AVS. O EigenLayer introduziu o token EIGENprincipalmenteparagovernanc\caepararecompensarosprimeirosparticipantes,masosAVSsna~osa~oobrigadosausaroupagaremEIGEN(na~oeˊumtokendegaˊsparaeles).Aplataformavisaumequilıˊbriodemercadolivre,ondecadaAVSdefineumataxaderecompensaparaatrairseguranc\casuficiente.OKarakpareceestarlanc\candoseutokennativoEIGEN principalmente para governança e para recompensar os primeiros participantes, mas os AVSs não são obrigados a usar ou pagar em EIGEN (não é um token de gás para eles). A plataforma visa um equilíbrio de mercado livre, onde cada AVS define uma taxa de recompensa para atrair segurança suficiente. O **Karak** parece estar lançando seu token nativo KAR (ainda não disponível no início de 2025) como o principal ativo em seu ecossistema. O Karak arrecadou 48Mefoiapoiadoporgrandesinvestidores,oqueimplicaqueo48 M e foi apoiado por grandes investidores, o que implica que o KAR terá valor e provavelmente será usado para governança e possivelmente para pagamentos de taxas na rede Karak. No entanto, a principal promessa do Karak é a "ausência de inflação" para novas redes que o utilizam – em vez de emitirem seus próprios tokens para segurança, elas aproveitam ativos existentes via Karak. Assim, uma nova rede usando o Karak poderia pagar validadores, por exemplo, em suas taxas de transação (que poderiam ser em uma stablecoin ou no token nativo da rede, se houver), mas não precisaria emitir continuamente novos tokens para recompensas de staking. O Karak estabeleceu um marketplace de validadores onde os desenvolvedores podem postar recompensas para que os validadores façam o restaking de ativos e protejam seu serviço. Essa abordagem de marketplace visa tornar as recompensas mais competitivas e consistentes, em vez de uma inflação extremamente alta seguida de uma queda – teoricamente reduzindo os custos para os desenvolvedores e oferecendo aos validadores uma renda estável e multi-rede. A economia do Babylon também difere: os stakers de BTC que bloqueiam seu Bitcoin ganham rendimento (yield) nos tokens das redes que estão protegendo. Por exemplo, se você fizer staking de BTC para ajudar a proteger uma zona Cosmos (uma das redes clientes do Babylon), você recebe as recompensas de staking dessa zona (seu token de staking nativo) como se fosse um delegador lá. Essas redes parceiras se beneficiam ao obter uma camada extra de segurança (checkpoints no Bitcoin, etc.) e, em troca, alocam uma parte de sua inflação ou taxas aos stakers de BTC via Babylon. Na prática, o Babylon atua como um hub onde os detentores de BTC podem delegar segurança para muitas redes e serem pagos em muitos tokens. A própria rede Babylon tem um token chamado BABY,usadoparastakingnoproˊprioconsensodaBabylon(aBabylonaindaprecisadeseusproˊpriosvalidadoresPoSparaexecutarainfraestruturadarede).OBABY**, usado para staking no próprio consenso da Babylon (a Babylon ainda precisa de seus próprios validadores PoS para executar a infraestrutura da rede). O BABY também é provavelmente usado na governança e talvez para alinhar incentivos (por exemplo, provedores de finalidade fazem staking de BABY). Mas, crucialmente, o BABYna~osubstituioBTCcomofontedeseguranc\caeleeˊmaisparaaexecuc\ca~odaredeenquantooBTCeˊocolateralquesustentaoservic\codeseguranc\cacompartilhada.Emmaiode2025,oBabylonfoiinicializadocomsucessocommaisde50.000BTCemstaking( BABY **não** substitui o BTC como fonte de segurança – ele é mais para a execução da rede – enquanto o BTC é o colateral que sustenta o serviço de segurança compartilhada. Em maio de 2025, o Babylon foi inicializado com sucesso com mais de **50.000 BTC em staking ( ~ 5,5 bilhões ) por detentores de BTC, tornando-se uma das redes Cosmos mais seguras por capital. Esses stakers de BTC ganham recompensas de staking de várias redes conectadas (por exemplo, ATOM do Cosmos Hub, OSMO da Osmosis, etc.), alcançando rendimentos diversificados enquanto mantêm seus BTC.

Foco Estratégico e Casos de Uso: A estratégia do EigenLayer tem sido centrada no Ethereum, visando acelerar a inovação dentro do ecossistema Ethereum. Seus primeiros casos de uso alvo (disponibilidade de dados, middleware como oráculos, sequenciamento de rollups) todos aprimoram o Ethereum ou seus rollups. Ele essencialmente potencializa o Ethereum como uma metacamada de serviços e agora, com seu suporte planejado para "multi-chain" (adicionado em 2025), o EigenLayer permitirá que os AVSs funcionem em outras redes EVM ou L2s enquanto ainda utilizam o conjunto de validadores do Ethereum. Essa verificação cross-chain significa que o EigenLayer está evoluindo para um provedor de segurança cross-chain, mas ancorado no Ethereum (validadores e staking ainda residem no Ethereum para o slashing). O Karak posiciona-se como uma camada base globalmente extensível para todos os tipos de aplicações – não apenas infraestrutura cripto, mas também ativos do mundo real (RWA), mercados financeiros e até serviços governamentais, de acordo com seu marketing. O nome "Camada Base Global para o PIB Programável" sugere a ambição de trabalhar com instituições e Estados-nação. O Karak enfatiza a integração das finanças tradicionais e IA, sugerindo que buscará parcerias além do reino puramente cripto. Tecnicamente, ao suportar ativos como stablecoins e potencialmente moedas fiduciárias governamentais, o Karak poderia permitir, por exemplo, que um governo lançasse uma blockchain protegida por seu próprio token fiduciário em staking via validadores do Karak. Seu suporte para empresas e múltiplas jurisdições é um diferencial. Em essência, o Karak está tentando ser o "restaking para todos, em qualquer rede, com qualquer ativo" – uma rede mais ampla do que a abordagem focada primeiro no Ethereum do EigenLayer. O foco do Babylon está em conectar os ecossistemas Bitcoin e Cosmos (e o ecossistema PoS mais amplo). Ele melhora especificamente a segurança inter-redes ao fornecer a imutabilidade e o peso econômico do Bitcoin para redes proof-of-stake que, de outra forma, seriam menores. Um dos casos de uso de destaque do Babylon é adicionar checkpoints de finalidade do Bitcoin a redes PoS, tornando extremamente difícil para essas redes serem atacadas ou reorganizadas sem atacar também o Bitcoin. Assim, o Babylon se comercializa como trazendo a "segurança do Bitcoin para todo o mundo cripto". Seu foco de curto prazo tem sido as redes Cosmos SDK (que ele chama de Redes Bitcoin Supercharged na Fase 3), mas o design foi feito para ser interoperável com Ethereum e rollups também. Estrategicamente, o Babylon acessa a vasta base de detentores de BTC, oferecendo-lhes uma opção de rendimento (o BTC, de outra forma, é um ativo sem rendimento) e, ao mesmo tempo, oferecendo às redes acesso ao "padrão ouro" da segurança cripto (BTC + PoW). Isso é bastante distinto do EigenLayer e do Karak, que tratam mais de aproveitar ativos PoS.

Tabela: EigenLayer vs Karak vs Babylon

RecursoEigenLayer (Ethereum)Karak Network (L1 Universal)Babylon (Bitcoin–Cosmos)
Ativo de Segurança BaseETH (staking de Ethereum) e LSTs permitidos na whitelist.Multiativo: ETH, LSTs, stablecoins, ERC-20s, etc. Também ativos cross-chain (Arbitrum, Mantle, etc.).BTC (Bitcoin nativo) bloqueado na rede principal do Bitcoin. Usa a alta capitalização de mercado do Bitcoin como segurança.
Arquitetura da PlataformaContratos inteligentes na L1 do Ethereum. Usa validadores / clientes do Ethereum; slashing aplicado pelo consenso do Ethereum. Agora em expansão para suportar AVSs em outras redes via provas do Ethereum.Rede de Camada 1 independente (“Karak L1”) com EVM. Fornece uma estrutura de restaking (KNS) para lançar novas blockchains ou serviços com conjuntos de validadores instantâneos. Não é um rollup ou L2 – é uma rede separada conectando múltiplos ecossistemas.Rede baseada em Cosmos (Babylon Chain) conectando-se ao Bitcoin via protocolos criptográficos. Usa IBC para vincular-se a redes PoS. Os validadores do Babylon executam um consenso Tendermint, e a rede Bitcoin é aproveitada para timestamps e lógica de slashing.
Modelo de SegurançaRestaking opcional: Stakers de Ethereum delegam saldo ao EigenLayer e optam por condições de slashing específicas de cada AVS. As condições de slashing são objetivas (provas criptográficas) para evitar problemas de consenso social no Ethereum.Validação universal: Os validadores do Karak podem fazer staking de vários ativos e são designados para proteger Serviços de Segurança Distribuídos (DSS) (semelhantes aos AVSs) em muitas redes. Slashing e recompensas gerenciados pela lógica da rede Karak; padroniza a segurança como um serviço para qualquer rede."Staking remoto" de BTC: Os detentores de Bitcoin bloqueiam BTC em cofres de autocustódia (UTXOs com trava de tempo) e, se agirem mal em uma rede cliente, sua chave privada pode ser exposta para realizar o slashing (queima) de seu BTC. Usa a mecânica própria do Bitcoin (sem tokens embrulhados). A rede Babylon coordena isso e fornece checkpointing (finalidade do BTC) para redes clientes.
Token e RecompensasToken EIGEN: Usado para governança e para recompensar os primeiros participantes (via airdrop, incentivos). Os restakers ganham principalmente em taxas ou tokens de AVS (pode ser ETH, stablecoins ou tokens nativos do AVS). O EigenLayer em si não exige uma porcentagem para os detentores do token EIGEN na receita do AVS (embora o EIGEN possa ter utilidade futura em tarefas de validação subjetiva).Token KAR: Ainda não lançado (esperado para 2025). Será o principal token de utilidade / governança no ecossistema do Karak. O Karak propõe ausência de inflação nativa para novas redes – os validadores ganham recompensas consistentes ao proteger muitos serviços. Novos protocolos podem incentivar validadores via marketplace do Karak em vez de tokens de alta inflação. Provavelmente o KAR será usado para a segurança da rede Karak e decisões de governança.Token BABY: Nativo da Babylon Chain (para staking de seus validadores, governança). Os stakers de BTC não recebem BABY por seu serviço, em vez disso, ganham rendimento nos tokens das redes PoS conectadas que protegem. (Ex: stake de BTC para proteger a Rede X, ganha as recompensas de staking da Rede X). Isso mantém a exposição dos stakers de BTC principalmente a tokens existentes. O papel do BABY é proteger o hub da Babylon e possivelmente como gás ou governança no ecossistema Babylon.
Casos de Uso NotáveisInfraestrutura alinhada ao Ethereum: ex. EigenDA (disponibilidade de dados para rollups), redes de oráculos (ex. Tellor / eOracle), pontes cross-chain (integração do LayerZero), sequenciadores compartilhados para rollups (Espresso, Radius), computação off-chain (Risc Zero, etc.). Também explorando serviços de retransmissão MEV descentralizados e derivativos de restaking líquido. Essencialmente, estende as capacidades do Ethereum (escalabilidade, interoperabilidade, middleware DeFi) ao fornecer uma camada de confiança descentralizada.Foco amplo, incluindo integração com finanças tradicionais: ativos do mundo real tokenizados, mercados de negociação 24/7, até aplicações governamentais e de IA em redes personalizadas. Por exemplo, KUDA (marketplace de disponibilidade de dados) e outros estão sendo construídos no ecossistema do Karak. Poderia hospedar redes de consórcios empresariais que usam stablecoins de USD como colateral de staking, etc. O Karak tem como alvo desenvolvedores multi-chain que desejam segurança sem estarem limitados aos validadores do Ethereum ou apenas ao ETH. Também enfatiza a interoperabilidade e eficiência de capital – ex: usar ativos com menor custo de oportunidade (como tokens de L1 menores) para restaking, para que os rendimentos possam ser maiores sem competir com o rendimento do ETH.Segurança para redes Cosmos e além: ex. usar BTC para proteger o Cosmos Hub, Osmosis e outras zonas (aumentando sua segurança sem que essas zonas aumentem a inflação). Fornece finalidade de timestamp do Bitcoin – qualquer rede que opte pode ter transações importantes registradas no Bitcoin para resistência à censura e finalidade. Especialmente útil para novas redes PoS que desejam evitar ataques de longo alcance ou adicionar uma "raiz de confiança" no Bitcoin. O Babylon cria efetivamente uma ponte entre o Bitcoin e as redes PoS: os detentores de Bitcoin ganham rendimento de PoS, e as redes PoS ganham a segurança e a comunidade do BTC. É complementar ao restaking com ETH; por exemplo, uma rede pode usar o EigenLayer para segurança econômica de ETH e o Babylon para a robustez do BTC.

Diferenças Estratégicas: O EigenLayer se beneficia do enorme conjunto de validadores descentralizados e da credibilidade do Ethereum, mas está limitado à segurança baseada em ETH. Ele se destaca em atender projetos orientados ao Ethereum (muitos AVSs são projetos de rollup ou middleware do Ethereum). A estratégia do Karak é capturar um mercado maior sendo flexível no suporte a ativos e no suporte a redes – não está casado com o Ethereum e até argumenta que os desenvolvedores podem evitar ficar "confinados exclusivamente ao Ethereum para segurança". Isso pode atrair projetos em ecossistemas como Arbitrum, Polygon ou mesmo redes não-EVM que desejam um provedor de segurança neutro. A abordagem multiativo do Karak também significa que ele pode acessar ativos que têm rendimentos mais baixos em outros lugares; como observou o cofundador Raouf Ben-Har, "Muitos ativos têm custos de oportunidade mais baixos em relação ao ETH… o que significa que [nossos serviços] têm um caminho mais fácil para rendimentos sustentáveis.". Por exemplo, o ARB em staking (token da Arbitrum) atualmente tem poucos usos; o Karak poderia permitir que os detentores de ARB fizessem o restaking para proteger novos dApps, criando uma situação de ganha-ganha (rendimento para detentores de ARB, segurança para o dApp). Essa estratégia, no entanto, traz complexidade técnica (gerenciar riscos de ativos diferentes) e suposições de confiança (fazer a ponte de ativos para a plataforma do Karak com segurança). A estratégia do Babylon é distinta ao focar no Bitcoin – ele está aproveitando o maior ativo cripto por capitalização de mercado, que também possui uma comunidade e um perfil de uso muito diferentes (detentores de longo prazo). O Babylon basicamente desbloqueou uma nova fonte de staking que antes era inexplorada: $ 1,2 trilhão de BTC que não podia fazer staking nativamente. Ao fazer isso, ele aborda um enorme pool de segurança e visa redes que valorizam as garantias do Bitcoin. Também atrai detentores de Bitcoin ao oferecer-lhes uma maneira de obter rendimento sem abrir mão da custódia do BTC. Poderia se dizer que o Babylon é quase o inverso do EigenLayer: em vez de estender a segurança do Ethereum para fora, ele está importando a segurança do Bitcoin para as redes PoS. Estrategicamente, ele poderia unir os mundos historicamente separados do Bitcoin e do DeFi.

Cada uma dessas estruturas tem vantagens e desvantagens. O EigenLayer desfruta atualmente de uma vantagem competitiva por ter sido o primeiro no restaking de Ethereum e um grande TVL ( ~ $ 20 B restakeados até o final de 2024), além de um suporte profundamente integrado da comunidade Ethereum. O Karak é mais recente (rede principal lançada em abril de 2024) e visa crescer cobrindo nichos que o EigenLayer não cobre (colateral não-ETH, redes fora do Ethereum). O Babylon opera na arena Cosmos e aproveita o Bitcoin – ele não compete com o EigenLayer por stakers de ETH, mas oferece um serviço ortogonal (alguns projetos podem usar ambos). Estamos vendo uma convergência onde múltiplas camadas de restaking podem até interoperar: ex. uma L2 do Ethereum poderia usar o EigenLayer para segurança baseada em ETH e também aceitar segurança BTC via Babylon – demonstrando que esses modelos não são mutuamente exclusivos, mas parte de um "mercado de segurança compartilhada" mais amplo.

Desenvolvimentos Recentes e Atualizações do Ecossistema ( 2024 – 2025 )

Progresso da EigenLayer : Desde a sua criação em 2021 , a EigenLayer evoluiu rapidamente de um conceito para uma rede ativa. Foi lançada na mainnet do Ethereum em fases – a Fase 1 , em meados de 2023 , permitiu o restaking básico e, em abril de 2024 , o protocolo EigenLayer completo ( com suporte para operadores e AVSs iniciais ) foi implementado. O crescimento do ecossistema tem sido substancial : no início de 2025 , a EigenLayer reporta 29 AVSs ativas na mainnet ( e mais de 130 em desenvolvimento ) , variando de camadas de dados a oráculos. Mais de 200 operadores e dezenas de milhares de restakers estão a participar, contribuindo para um TVL em restaking que atingiu ~ $ 20 bilhões no final de 2024 . Um marco importante foi a introdução do slashing e da aplicação de recompensas na mainnet em abril de 2025 , marcando o passo final da entrada em vigor do modelo de segurança da EigenLayer. Isto significa que as AVSs podem agora penalizar verdadeiramente o mau comportamento e pagar recompensas de forma trustless, ultrapassando a “fase de teste” onde estas funcionalidades estavam desativadas. Juntamente com isto, a EigenLayer implementou uma série de atualizações : por exemplo, a atualização MOOCOW ( julho de 2025 ) melhorou a eficiência dos validadores ao permitir levantamentos e consolidação de restaking mais fáceis ( aproveitando o fork Pectra do Ethereum ) . Talvez a nova funcionalidade mais significativa seja a Verificação Multi-Chain , lançada em julho de 2025 , que permite que as AVSs operem em várias redes ( incluindo L2s ) enquanto continuam a utilizar a segurança baseada no Ethereum. Isto foi demonstrado na testnet Base Sepolia e será implementado na mainnet, transformando efetivamente a EigenLayer num provedor de segurança cross-chain ( não apenas para aplicações L1 do Ethereum ) . Isto aborda uma limitação anterior de que as AVSs da EigenLayer tinham de publicar todos os dados no Ethereum; agora, uma AVS pode correr, por exemplo, num Optimistic Rollup ou noutra L1, e a EigenLayer verificará as provas ( usando Merkle roots ) de volta no Ethereum para aplicar o slashing ou recompensar conforme necessário. Isto expande significativamente o alcance e o desempenho da EigenLayer ( as AVSs podem operar onde é mais barato, mantendo a segurança do Ethereum ) . Em termos de comunidade e governança, a EigenLayer lançou o EigenGov no final de 2024 – um conselho e uma estrutura de ELIP ( Proposta de Melhoria da EigenLayer ) para decentralizar a tomada de decisões. O Conselho do Protocolo ( 5 membros ) supervisiona agora mudanças críticas com o contributo da comunidade. Além disso, a EigenLayer tem estado consciente das preocupações levantadas pela comunidade principal do Ethereum. Em resposta aos avisos de Vitalik, a equipa publicou materiais explicando como evitam sobrecarregar o consenso do Ethereum , por exemplo, utilizando o token EIGEN para quaisquer serviços “subjetivos” e deixando o restaking de ETH para casos de slashing puramente objetivos. Esta abordagem de dois níveis ( ETH para falhas claras, EIGEN para decisões mais subjetivas ou lideradas pela governança ) ainda está a ser refinada, mas mostra o compromisso da EigenLayer em alinhar-se com o ethos do Ethereum.

No lado do ecossistema , o surgimento da EigenLayer inspirou uma onda de inovação e discussão. Em meados de 2024 , os analistas notaram que o restaking se tinha tornado “uma narrativa dominante dentro da comunidade Ethereum” . Muitos projetos de DeFi e infraestrutura começaram a planear como alavancar a EigenLayer para segurança ou rendimento adicional. Ao mesmo tempo, os membros da comunidade estão a debater a gestão de riscos : por exemplo, o relatório de risco detalhado da Chorus One ( abril de 2024 ) chamou a atenção para a centralização de operadores e riscos de slashing em cascata, impulsionando mais pesquisas e possivelmente funcionalidades como a monitorização da distribuição de stake. A distribuição do token EIGEN também foi um tema quente – no 4 º trimestre de 2024 , a EigenLayer realizou um “stake drop” onde utilizadores ativos do Ethereum e participantes iniciais da EigenLayer receberam EIGEN, mas este era inicialmente não transferível. Alguns membros da comunidade ficaram descontentes com aspetos do drop ( por exemplo, grandes porções alocadas a VCs, e alguns protocolos DeFi que integraram a EigenLayer não sendo recompensados diretamente ) . Este feedback levou a equipa a enfatizar incentivos mais centrados na comunidade daqui para a frente e, de facto, os Incentivos Programáticos introduzidos visam recompensar continuamente aqueles que estão realmente a fazer restaking e a operar. Em 2025 , a EigenLayer é um dos ecossistemas de desenvolvedores que mais cresce – reconhecido até num relatório da Electric Capital – e garantiu parcerias importantes ( por exemplo, com LayerZero, ConsenSys, Risc0 ) para impulsionar a adoção de AVSs. No geral, a trajetória da EigenLayer em 2024 – 2025 mostra uma plataforma em maturação que aborda preocupações iniciais e expande a funcionalidade, consolidando a sua posição como a pioneira do restaking de Ethereum .

Karak e Outros Competidores : A Karak Network entrou em destaque com o lançamento da sua mainnet em abril de 2024 e posicionou-se rapidamente como uma rival notável da EigenLayer no Ethereum e noutras redes. Apoiada por grandes investidores e até por certos stakeholders do Ethereum ( Coinbase Ventures, entre outros ) , a promessa da Karak de “restaking para todos, em qualquer chain, com qualquer ativo” atraiu atenções. No final de 2024 , a Karak atualizou para uma mainnet V2 com funcionalidades melhoradas para segurança universal, completando as migrações entre Arbitrum e Ethereum em novembro de 2024 . Isto indica que a Karak expandiu o suporte para mais ativos e possivelmente melhorou os seus contratos inteligentes ou consenso. No início de 2025 , a Karak aumentou a sua base de utilizadores através de um programa de incentivos XP ( encorajando a participação na testnet, staking, etc., com a esperança de um futuro airdrop de $ KAR ) . As discussões da comunidade em torno da Karak comparam-na frequentemente com a EigenLayer : a Bankless notou em maio de 2024 que, embora o valor total em stake na Karak ainda estivesse “longe do tamanho da EigenLayer” , tinha registado um crescimento rápido ( 4 x num mês ) , possivelmente devido a utilizadores que procuravam recompensas mais elevadas ou diversificação para fora da EigenLayer. O apelo da Karak reside no suporte a ativos como tokens de rendimento da Pendle, ARB da Arbitrum, token da Mantle, etc. , o que amplia o mercado de restaking. Em 2025 , a Karak está provavelmente focada em integrar mais clientes de “Validação como Serviço” e possivelmente a preparar o lançamento do seu token KAR ( a sua documentação sugere seguir os canais oficiais para atualizações do token ) . A competição entre a EigenLayer e a Karak permanece amigável, mas significativa – ambas visam atrair stakers e projetos. Se a EigenLayer detém o segmento maximalista de ETH , a Karak apela a utilizadores multi-chain e àqueles com ativos não-ETH que procuram rendimento. Podemos esperar que a Karak anuncie parcerias no próximo ano, talvez com redes Layer 2 ou até players institucionais, dada a sua marca de “grau institucional”. O mercado de restaking não é, portanto, um monopólio; em vez disso, várias plataformas estão a encontrar nichos, o que poderá levar a um ecossistema fragmentado, mas rico, de provedores de segurança compartilhada.

Lançamento da Babylon e a Fronteira de Staking de BTC : A Babylon completou um marco importante em 2025 ao ativar a sua funcionalidade principal – Staking de Bitcoin para segurança compartilhada . Após uma testnet de Fase 1 e um lançamento gradual, a mainnet da Fase 2 da Babylon entrou em funcionamento em abril de 2025 e, em maio de 2025 , reportou mais de 50 k BTC em staking no protocolo. Esta é uma conquista notável, ligando efetivamente ~ $ 5 bilhões de Bitcoin ao mercado de segurança interchain. As redes de adoção inicial da Babylon ( as primeiras “Bitcoin Supercharged Networks” ) incluem várias redes baseadas em Cosmos que integraram o light client da Babylon e começaram a depender da finalização de checkpoint de BTC. A própria chain Babylon Genesis foi lançada em 10 de abril de 2025 , assegurada pelo novo staking do token $ BABY , e um dia depois ( 11 de abril ) o staking de BTC trustless foi pilotado com um limite inicial de 1000 BTC. Em 24 de abril de 2025 , o staking de BTC abriu-se de forma permissionless para todos e o limite foi removido. A operação estável nas primeiras semanas levou a equipa a declarar o staking de Bitcoin como “arrancado com sucesso” , chamando à Babylon Genesis agora “uma das L1s mais seguras do mundo em termos de capitalização de mercado de staking” . Com a Fase 2 concluída, a Fase 3 visa integrar muitas redes externas como clientes , transformando-as em BSNs ( Bitcoin Supercharged Networks ) . Isto envolverá módulos de interoperabilidade para que o Ethereum, os seus rollups e qualquer rede Cosmos possam usar a Babylon para obter segurança do BTC. A comunidade Babylon – composta por detentores de Bitcoin, desenvolvedores de Cosmos e outros – tem discutido ativamente a governança do token $ BABY ( garantindo que a rede Babylon permaneça neutra e confiável para todas as redes conectadas ) e a economia ( por exemplo, equilibrando as recompensas de staking de BTC entre muitas redes consumidoras para que seja atraente para os detentores de BTC sem subsidiar excessivamente ) . Um desenvolvimento interessante é o suporte da Babylon para itens como a cobertura da Nexus Mutual ( de acordo com uma publicação de maio de 2025 ) para oferecer seguros sobre o slashing no staking de BTC, o que poderia atrair ainda mais participantes. Isto mostra o amadurecimento do ecossistema em torno da gestão de riscos para este novo paradigma.

Discussões da Comunidade e Entre Projetos : Em 2025 , está a decorrer uma conversa mais ampla sobre o futuro da segurança compartilhada no setor cripto. A comunidade do Ethereum acolhe em grande parte a EigenLayer, mas permanece cautelosa; o artigo de Vitalik ( maio de 2023 ) definiu o tom para uma delimitação cuidadosa do que é aceitável. A EigenLayer envolve-se regularmente com a comunidade através do seu fórum, abordando questões como “A EigenLayer está a sobrecarregar o consenso do Ethereum?” ( resposta curta : eles argumentam que não, devido a salvaguardas de design ) . Na comunidade Cosmos, a Babylon despertou entusiasmo, pois resolve potencialmente problemas de segurança de longa data ( por exemplo, zonas pequenas que sofrem ataques de 51 % ) sem exigir que se juntem a um hub de segurança compartilhada como a Polkadot ou o ICS do Cosmos Hub. Há também uma convergência interessante : alguns membros da comunidade Cosmos perguntam se o staking de Ethereum poderia algum dia alimentar redes Cosmos ( que é mais o domínio da EigenLayer ) , enquanto os membros do Ethereum se perguntam se o staking de Bitcoin poderia proteger rollups de Ethereum ( o conceito da Babylon ) . Estamos a ver sinais iniciais de polinização cruzada : por exemplo, ideias de usar a EigenLayer para fazer restaking de ETH em redes fora do Ethereum ( Symbiotic e Karak são passos nessa direção ) e usar o staking de BTC da Babylon como uma opção para as L2s do Ethereum . Até a Solana tem um projeto de restaking ( Solayer ) que lançou um teste inicial e atingiu os limites rapidamente, mostrando que o interesse abrange vários ecossistemas.

Os desenvolvimentos de governança nestes projetos incluem uma representação crescente da comunidade. O conselho da EigenLayer inclui agora membros externos da comunidade e financiou subsídios ( através da Eigen Foundation ) para desenvolvedores principais do Ethereum, sinalizando boa vontade para com o núcleo do Ethereum. A governança da Karak provavelmente girará em torno do token KAR – atualmente, eles operam um sistema XP off-chain, mas espera-se um DAO mais formal assim que o KAR tiver liquidez. A governança da Babylon será crucial, pois coordena entre o Bitcoin ( que não tem governança formal ) e as redes Cosmos ( que têm governança on-chain ) . Estabeleceu uma Fundação Babylon e um fórum comunitário para discutir parâmetros como períodos de unbonding para o BTC, que exigem um alinhamento cuidadoso com as restrições do Bitcoin.

Em resumo, em meados de 2025 , o mercado de restaking e segurança compartilhada passou da teoria à prática . A EigenLayer está totalmente operacional com serviços reais e slashing, comprovando o modelo no Ethereum . A Karak introduziu uma variante multi-chain convincente, ampliando o espaço de design e visando novos ativos. A Babylon demonstrou que até o Bitcoin pode juntar-se à festa da segurança compartilhada através de criptografia inteligente, abordando um segmento de mercado completamente diferente. O ecossistema é vibrante : novos concorrentes ( por exemplo, Symbiotic no Ethereum, Solayer na Solana, BounceBit usando BTC custodial ) estão a surgir, cada um experimentando diferentes compensações ( Symbiotic alinhando-se com a Lido para usar stETH e qualquer ERC-20 , BounceBit adotando uma abordagem regulada com Bitcoin embrulhado, etc. ) . Este cenário competitivo está a impulsionar uma inovação rápida – e, fundamentalmente, a discussão sobre padrões e segurança . Fóruns comunitários e grupos de pesquisa estão a debater ativamente questões como : Devem existir limites para o stake em restaking por operador? Como implementar melhor as provas de slashing cross-chain? Poderia o restaking aumentar involuntariamente a correlação sistémica entre redes? Tudo isto está a ser estudado. Os modelos de governança também estão a evoluir – a mudança da EigenLayer para um conselho semidescentralizado é um exemplo de equilíbrio entre agilidade e segurança na governança.

Olhando para o futuro, o paradigma do restaking está posicionado para se tornar uma base da infraestrutura Web3 , tal como os serviços na nuvem se tornaram essenciais na Web2 . Ao comoditizar a segurança, permite que projetos menores sejam lançados com confiança e que projetos maiores otimizem o uso de capital. Os desenvolvimentos até 2025 mostram uma trajetória promissora, mas cautelosa : a tecnologia funciona e está a escalar, mas todos os intervenientes estão atentos aos riscos. Com os desenvolvedores principais do Ethereum, construtores de Cosmos e até Bitcoiners agora envolvidos em iniciativas de segurança compartilhada, é claro que este mercado apenas crescerá. Podemos esperar uma colaboração mais estreita entre ecossistemas ( talvez pools de segurança conjuntos ou provas de slashing padronizadas ) e, inevitavelmente, clareza regulatória à medida que os reguladores acompanham estas construções multi-chain e multi-ativos. Entretanto, pesquisadores e desenvolvedores têm um tesouro de novos dados da EigenLayer, Karak, Babylon e outros para analisar e melhorar, garantindo que a “revolução do restaking” continue de forma segura e sustentável.

Fontes :

  1. Documentação e whitepaper da EigenLayer – definição de restaking e AVS
  2. Blog da Coinbase Cloud ( maio de 2024 ) – visão geral da EigenLayer, papéis de restakers / operadores / AVSs
  3. Blockworks News ( abril de 2024 ) – fundadores da Karak sobre “restaking universal” vs EigenLayer
  4. Pesquisa da Ditto ( 2023 ) – Comparação de suporte de ativos da EigenLayer, Symbiotic e Karak
  5. Messari Research ( abr de 2024 ) – “Babylon : Segurança Compartilhada do Bitcoin” , mecanismo de staking de BTC
  6. HashKey Research ( jul de 2024 ) – rendimentos de restaking da Babylon vs EigenLayer
  7. Fórum da EigenLayer ( dez de 2024 ) – Discussão sobre o texto de Vitalik “Não sobrecarregue o consenso do Ethereum” e a abordagem da EigenLayer
  8. Blockworks News ( abr de 2024 ) – Relatório da Chorus One sobre os riscos da EigenLayer ( cascata de slashing, centralização )
  9. Kairos Research ( out de 2023 ) – Visão geral de AVS da EigenLayer e nota sobre risco regulatório
  10. Blog da EigenCloud ( jan de 2025 ) – “Revisão do Ano de 2024” ( estatísticas da EigenLayer, atualizações de governança )
  11. Blockworks News ( abr de 2024 ) – cobertura do lançamento da Karak e suporte a ativos
  12. Blog da Babylon Labs ( maio de 2025 ) – “Resumo do lançamento da Fase-2” ( staking de Bitcoin ativo, 50 k BTC em staking )
  13. Bankless ( maio de 2024 ) – “A Competição de Restaking” ( EigenLayer vs Karak vs outros )
  14. Vitalik Buterin, “Não sobrecarregue o consenso do Ethereum” , maio de 2023 – Orientações sobre o reuso de validadores vs consenso social
  15. Guia do Desenvolvedor da Coinbase ( abr de 2024 ) – Detalhes técnicos sobre a operação da EigenLayer ( EigenPods, delegação, estrutura AVS ) .