O que aconteceu com o re-staking?

Análise aprofundada do caminho do restaking da EigenLayer: os obstáculos enfrentados, os méritos do EigenDA, tudo pavimentando o novo rumo do EigenCloud.

Autor: Kydo, responsável pela narrativa do EigenCloud

Tradução: Saoirse, Foresight News

De tempos em tempos, amigos me enviam tweets zombando do restaking, mas essas provocações nunca acertam o ponto. Por isso, decidi escrever eu mesmo um texto reflexivo e crítico.

Talvez penses que estou demasiado envolvido para ser objetivo; ou que sou orgulhoso demais para admitir que "errámos". Podes achar que, mesmo que todos já tenham decretado o "fracasso do restaking", eu ainda escreveria um longo texto para argumentar, sem nunca pronunciar a palavra "fracasso".

Essas opiniões são compreensíveis e, em muitos casos, fazem sentido.

Mas este artigo pretende apenas apresentar os factos de forma objetiva: o que realmente aconteceu, o que foi concretizado, o que não conseguimos fazer e que lições tirámos disso.

Espero que as experiências aqui relatadas sejam universais e possam servir de referência para desenvolvedores de outros ecossistemas.

Depois de mais de dois anos integrando todos os principais AVS (Serviços de Validação Autônoma) no EigenLayer e desenhando o EigenCloud, quero fazer uma análise honesta: onde errámos, onde acertámos e para onde vamos a seguir.

Afinal, o que é restaking?

Se ainda preciso explicar "o que é restaking", isso por si só já mostra que, quando o restaking era o foco da indústria, não conseguimos comunicar a ideia claramente. Esta é a "lição zero": focar numa narrativa central e repeti-la constantemente.

O objetivo da equipa Eigen sempre foi "fácil de explicar, difícil de executar": aumentar a verificabilidade dos cálculos off-chain, permitindo que as pessoas construam aplicações on-chain de forma mais segura.

O AVS foi a nossa primeira tentativa clara nesse sentido.

O AVS (Serviço de Validação Autônoma) é uma rede proof-of-stake (PoS), composta por um grupo de operadores descentralizados que executam tarefas off-chain. O comportamento desses operadores é monitorado e, em caso de violação, o capital em staking é penalizado. Para que haja "mecanismo de penalização", é necessário haver "capital em staking" como suporte.

É aí que reside o valor do restaking: sem que cada AVS precise construir seu próprio sistema de segurança do zero, o restaking permite reutilizar o ETH já em staking para garantir a segurança de vários AVS. Isso reduz o custo de capital e acelera o arranque do ecossistema.

Assim, o quadro conceptual do restaking pode ser resumido em:

• AVS: a "camada de serviço", que serve de base para novos sistemas de segurança criptoeconómica PoS;
• Restaking: a "camada de capital", que reutiliza ativos já em staking para garantir a segurança desses sistemas.

Ainda considero esta ideia brilhante, mas a realidade não foi tão ideal quanto o diagrama sugeria — muitos resultados ficaram aquém das expectativas.

O que não correu como esperado

1. Escolhemos o mercado errado: demasiado nicho

Não queríamos "qualquer computação verificável", mas sim sistemas que, desde o primeiro dia, fossem descentralizados, baseados em penalização e com segurança criptoeconómica total.

Queríamos que o AVS fosse um "serviço de infraestrutura" — tal como os desenvolvedores podem criar SaaS (Software as a Service), qualquer pessoa poderia construir um AVS.

Esta posição, embora de princípio, reduziu drasticamente o universo de potenciais desenvolvedores.

O resultado foi um mercado "pequeno, lento e de alta barreira": poucos utilizadores potenciais, custos elevados de implementação e ciclos longos para ambas as partes (equipa e desenvolvedores). Tanto a infraestrutura do EigenLayer, como as ferramentas de desenvolvimento e cada AVS de topo, levam meses ou até anos a ser construídos.

Avançando quase três anos: atualmente temos apenas dois AVS principais em produção — DIN (Decentralized Infrastructure Network) da Infura e EigenZero da LayerZero. Esta "taxa de adoção" está longe de ser "ampla".

Para ser sincero, o cenário que desenhámos era "equipas que querem segurança criptoeconómica e operadores descentralizados desde o início", mas o mercado real procura soluções "mais graduais e centradas na aplicação".

2. Limitados pelo ambiente regulatório, fomos forçados ao "silêncio"

Quando lançámos o projeto, estávamos no auge da "era Gary Gensler" (nota: Gary Gensler é presidente da SEC dos EUA e adotou uma postura rigorosa em relação à indústria cripto). Na altura, várias empresas de staking estavam sob investigação e processos judiciais.

Como "projeto de restaking", quase tudo o que dizíamos em público podia ser interpretado como "promessa de investimento", "publicidade de retorno" ou até resultar numa intimação judicial.

Este nevoeiro regulatório determinou a nossa forma de comunicar: não podíamos falar livremente, mesmo perante uma avalanche de notícias negativas, parceiros a sacudir responsabilidades ou ataques públicos, não podíamos esclarecer os mal-entendidos em tempo real.

Nem sequer podíamos dizer "as coisas não são assim" sem antes pesar o risco jurídico.

O resultado foi que, sem comunicação suficiente, lançámos tokens bloqueados. Olhando para trás, foi de facto arriscado.

Se alguma vez sentiste que "a equipa Eigen evitava certos temas ou estava estranhamente silenciosa", provavelmente foi devido a este ambiente regulatório — um tweet errado podia trazer riscos consideráveis.

3. Os AVS iniciais diluíram o valor da marca

A influência inicial da marca Eigen deveu-se em grande parte a Sreeram (membro central da equipa) — a sua energia, otimismo e crença de que "sistemas e pessoas podem melhorar" geraram muita simpatia.

Os milhares de milhões em capital em staking reforçaram ainda mais essa confiança.

No entanto, a promoção conjunta dos primeiros AVS não correspondeu a esse "nível de marca". Muitos AVS iniciais faziam muito barulho, mas apenas perseguiam tendências; não eram exemplos "tecnicamente superiores" nem "os mais íntegros".

Com o tempo, as pessoas começaram a associar "EigenLayer" a "novas campanhas de liquidity mining e airdrops". As dúvidas, saturação e até aversão que enfrentamos hoje remontam a essa fase.

Se pudesse voltar atrás, gostaria de ter começado com "menos, mas melhores AVS", sendo mais seletivo com os parceiros que poderiam receber o endosso da marca, mesmo que isso significasse um ritmo mais lento e menos hype.

4. Excesso de busca por "minimização de confiança" levou a design redundante

Tentámos construir um "sistema de penalização universal perfeito" — que fosse genérico, flexível e cobrisse todos os cenários de penalização, alcançando assim a "minimização de confiança".

Na prática, isso tornou a iteração do produto lenta e exigiu muito tempo para explicar um mecanismo que "a maioria ainda não estava pronta para entender". Mesmo hoje, ainda precisamos de explicar repetidamente o sistema de penalização lançado há quase um ano.

Olhando para trás, o caminho mais sensato teria sido: lançar primeiro uma solução simples de penalização, permitir que diferentes AVS experimentassem modelos mais focados e só depois aumentar a complexidade do sistema. Mas colocámos o "design complexo" à frente, pagando o preço em "velocidade" e "clareza".

O que realmente conseguimos

As pessoas adoram rotular rapidamente as coisas como "fracasso", mas isso é precipitado.

No capítulo do "restaking", há muitos feitos notáveis, e esses resultados são cruciais para o nosso futuro.

1. Provámos que conseguimos vencer em mercados competitivos

Preferimos "win-win", mas não tememos a concorrência — se entrarmos num mercado, queremos liderar.

No restaking, Paradigm e Lido apoiaram juntos o nosso concorrente direto. Na altura, o TVL do EigenLayer era inferior a 1.1 billions.

O concorrente tinha vantagem narrativa, recursos, capital e "confiança padrão". Muitos me disseram: "A equipa deles vai executar melhor e esmagar-vos". Mas não foi assim — hoje temos 95% da quota de mercado de capital de restaking e atraímos 100% dos principais desenvolvedores.

No domínio da "data availability (DA)", começámos mais tarde, com equipa menor e menos fundos, enquanto os pioneiros já tinham vantagens e marketing forte. Mas agora, por qualquer métrica, o EigenDA (solução de DA da Eigen) detém uma grande fatia do mercado DA; com o lançamento total do maior parceiro, essa quota crescerá exponencialmente.

Ambos os mercados eram extremamente competitivos, mas conseguimos destacar-nos.

2. EigenDA tornou-se um produto maduro que "transforma o ecossistema"

Lançar o EigenDA sobre a infraestrutura EigenLayer foi uma enorme surpresa.

Tornou-se a pedra angular do EigenCloud e trouxe ao Ethereum algo muito necessário — um canal DA de grande escala. Com ele, os rollups podem operar rapidamente sem abandonar o ecossistema Ethereum em busca de velocidade noutras blockchains.

O lançamento do MegaETH só aconteceu porque a equipa confiava que Sreeram poderia superar o gargalo DA; quando a Mantle propôs à BitDAO construir uma L2, foi pela mesma confiança.

O EigenDA também se tornou o "escudo defensivo" do Ethereum: com uma solução DA nativa de alta capacidade, blockchains externas têm mais dificuldade em "atrair atenção com a narrativa Ethereum e sugar valor do ecossistema".

3. Impulsionámos o mercado de pré-confirmação

Um dos temas centrais do início do EigenLayer era como desbloquear a pré-confirmação do Ethereum através do EigenLayer.

Desde então, a pré-confirmação ganhou destaque com a rede Base, mas a implementação ainda enfrenta desafios.

Para impulsionar o ecossistema, lançámos o programa Commit-Boost — para resolver o "efeito de bloqueio" dos clientes de pré-confirmação, criando uma plataforma neutra onde qualquer um pode inovar através de compromissos de validadores.

Hoje, dezenas de bilhões de dólares circulam pelo Commit-Boost, e mais de 35% dos validadores já aderiram. Com o lançamento dos principais serviços de pré-confirmação nos próximos meses, essa percentagem aumentará ainda mais.

Isto é crucial para a "antifragilidade" do ecossistema Ethereum e estabelece as bases para inovação contínua no mercado de pré-confirmação.

4. Sempre garantimos a segurança dos ativos

Durante anos, protegemos a segurança de dezenas de bilhões de dólares em ativos.

Esta frase pode soar banal, até "aborrecida" — mas basta pensar em quantas infraestruturas cripto já "colapsaram" de várias formas para perceber o quão valioso é esse "tédio". Para evitar riscos, construímos um sistema operacional seguro, recrutámos e formámos uma equipa de segurança de classe mundial e incorporámos o "pensamento adversarial" na cultura da equipa.

Esta cultura é vital para qualquer negócio que envolva fundos de utilizadores, IA ou sistemas do mundo real, e "não pode ser remendada depois" — tem de ser sólida desde o início.

5. Impedimos que a Lido mantivesse mais de 33% do staking por muito tempo

O restaking teve um impacto subestimado: grandes quantidades de ETH fluíram para provedores de LRT, evitando que a Lido mantivesse uma quota de staking superior a 33% por muito tempo.

Isto é fundamental para o "equilíbrio social" do Ethereum. Se a Lido mantivesse mais de 33% do staking sem alternativas fiáveis, haveria enormes disputas de governança e conflitos internos.

O restaking e os LRT não "descentralizaram magicamente" tudo, mas mudaram a tendência de concentração do staking — e isso não é um feito menor.

6. Definimos onde está a "verdadeira fronteira"

O maior "ganho" foi conceptual: comprovámos o argumento central de que "o mundo precisa de mais sistemas verificáveis", mas também percebemos que o "caminho para lá chegar" estava errado.

O caminho certo não é "começar com segurança criptoeconómica genérica, insistir em operadores totalmente descentralizados desde o início e esperar que todos os negócios se integrem nesse nível".

O que realmente acelera a "fronteira" é dar ferramentas diretas aos desenvolvedores para que possam implementar verificabilidade nas suas aplicações específicas, com primitivas de verificação adequadas. Devemos "aproximar-nos das necessidades dos desenvolvedores", não exigir que sejam "designers de protocolos" desde o início.

Por isso, já começámos a construir serviços modulares internos — EigenCompute (serviço de computação verificável) e EigenAI (serviço de IA verificável). Algumas funcionalidades que outras equipas precisariam de centenas de milhões de dólares e anos para lançar, nós conseguimos em meses.

Os próximos passos

Então, perante estas experiências — timing, sucessos, fracassos, "cicatrizes" de marca — como vamos reagir?

Aqui está um resumo dos nossos próximos planos e da lógica por trás deles:

1. Tornar o token EIGEN o núcleo do sistema

No futuro, todo o EigenCloud e todos os produtos que construirmos ao seu redor terão o token EIGEN no centro.

A função do token EIGEN é:

• Motor central de segurança económica do EigenCloud;
• Ativo que garante os vários riscos assumidos pela plataforma;
• Ferramenta central de captura de valor para todas as taxas e atividades económicas da plataforma.

No início, muitos tinham expectativas desalinhadas sobre "que valor o token EIGEN pode capturar" versus "o mecanismo real" — isso gerou confusão. Na próxima fase, vamos preencher essa lacuna com design concreto e sistemas implementados. Mais detalhes serão divulgados em breve.

2. Permitir que desenvolvedores construam "aplicações verificáveis", não apenas AVS

O nosso argumento central mantém-se: aumentar a verificabilidade dos cálculos off-chain para que as pessoas possam construir aplicações on-chain com mais segurança. Mas as ferramentas para alcançar "verificabilidade" não se limitarão a uma só.

Às vezes será segurança criptoeconómica; outras vezes, provas ZK, TEE (Trusted Execution Environment) ou soluções híbridas. O importante não é "favorecer uma tecnologia", mas tornar a "verificabilidade" uma primitiva padrão acessível diretamente na stack dos desenvolvedores.

O objetivo é reduzir a distância entre dois estados:

De "tenho uma aplicação" para "tenho uma aplicação que utilizadores, parceiros ou reguladores podem verificar".

Pelo estado atual da indústria, "criptoeconomia + TEE" é claramente a melhor escolha — equilibra "programabilidade para desenvolvedores" (o que podem construir) e "segurança" (não só teórica, mas realmente aplicável).

No futuro, quando provas ZK e outros mecanismos de verificação estiverem maduros e atenderem às necessidades dos desenvolvedores, também os integraremos ao EigenCloud.

3. Investir profundamente em IA

A maior transformação global na computação é a IA — especialmente os agentes inteligentes (AI Agents). O setor cripto não pode ficar de fora.

Os agentes inteligentes são, essencialmente, "modelos de linguagem envoltos em ferramentas, executando operações em ambientes específicos".

Hoje, não só os modelos de linguagem são "caixas pretas", como a lógica operacional dos agentes de IA também é opaca — por isso já ocorreram ataques de hackers devido à "necessidade de confiar no desenvolvedor".

Mas se os agentes de IA forem "verificáveis", as pessoas não precisarão confiar nos desenvolvedores.

Para tornar os agentes de IA verificáveis, são necessários três requisitos: o processo de inferência do LLM (Large Language Model) deve ser verificável, o ambiente de execução das operações deve ser verificável e a camada de dados para armazenar, recuperar e compreender o contexto deve ser verificável.

O EigenCloud foi desenhado exatamente para estes cenários:

• EigenAI: fornece serviços de inferência LLM determinísticos e verificáveis;
• EigenCompute: fornece ambientes de execução de operações verificáveis;
• EigenDA: fornece serviços de armazenamento e recuperação de dados verificáveis.

Acreditamos que "agentes de IA verificáveis" são um dos cenários mais competitivos para o nosso "cloud verificável" — por isso já temos uma equipa dedicada a este campo.

4. Redefinir a narrativa de "staking e rendimento"

Para obter rendimento real, é preciso assumir risco real.

Estamos a explorar cenários de staking mais amplos, permitindo que o capital em staking suporte os seguintes riscos:

• Risco de smart contract;
• Riscos de diferentes tipos de computação;
• Riscos claramente definidos e quantificáveis.

Os rendimentos futuros refletirão os "riscos transparentes e compreensíveis" assumidos, e não apenas a busca por "modas de liquidity mining".

Esta lógica será naturalmente incorporada nos cenários de uso, âmbito de garantia e mecanismos de circulação de valor do token EIGEN.

Considerações finais

O restaking não se tornou a "camada universal" que eu (e outros) esperávamos, mas também não desapareceu. Ao longo do desenvolvimento, tornou-se aquilo que a maioria dos "produtos de primeira geração" acaba por ser:

Um capítulo importante, lições valiosas e a infraestrutura que hoje sustenta negócios mais amplos.

Continuamos a manter as operações relacionadas ao restaking e ainda o valorizamos — só não queremos mais ficar presos à narrativa inicial.

Se és membro da comunidade, desenvolvedor de AVS ou investidor que ainda associa Eigen ao "projeto de restaking", espero que este artigo te ajude a entender melhor "o que aconteceu" e "para onde estamos a ir".

Agora estamos a entrar num campo com um "Total Addressable Market (TAM)" muito maior: de um lado, cloud services; do outro, necessidades diretas da camada de aplicação para desenvolvedores. Também exploramos a "pista de IA ainda pouco desenvolvida", e vamos avançar nestas direções com a mesma intensidade de sempre.

A equipa continua motivada e mal posso esperar para provar a todos os céticos — nós conseguimos.

Nunca estive tão otimista com a Eigen e continuo a aumentar a minha posição em EIGEN, e assim continuarei no futuro.

Ainda estamos apenas no começo.