Análise profunda do caminho da re-stake da EigenLayer: os erros cometidos, os méritos da EigenDA, tudo a preparar o novo rumo da EigenCloud. Este artigo é da autoria de Kydo, responsável pela narrativa da EigenCloud, com organização, tradução e redação de Saoirse, Foresight News.
(Resumo anterior: Relatório de 10 mil palavras — Compreender totalmente o líder da re-stake, EigenLayer)
(Informação de fundo: O que é EigenDA, o produto emblemático do protocolo de re-stake EigenLayer?)
De tempos a tempos, amigos enviam-me tweets a gozar com a re-stake, mas nenhum deles acerta verdadeiramente no ponto. Por isso decidi escrever eu próprio um artigo com uma certa dose de reflexão e crítica.
Talvez penses que estou demasiado envolvido para ser objetivo; ou que sou demasiado orgulhoso para admitir que “falhámos”. Podes pensar que, mesmo que toda a gente já considere que a “re-stake falhou”, eu ainda escreveria um longo artigo a defender-me, sem nunca usar a palavra “falha”.
Todas estas opiniões são razoáveis e, em muitos casos, justificadas.
Mas este artigo pretende apenas apresentar os factos de forma objetiva: o que aconteceu realmente, o que resultou, o que não correu bem e que lições tirámos disso.
Espero que as experiências partilhadas aqui sejam universais e possam servir de referência a outros programadores do ecossistema.
Depois de mais de dois anos a integrar todos os principais AVS (Serviços de Validação Autónoma) na EigenLayer e a desenhar a EigenCloud, quero fazer uma retrospetiva honesta: onde errámos, onde acertámos e qual o caminho a seguir.
Afinal, o que é a re-stake (Restaking)?
O simples facto de eu ainda precisar de explicar “o que é a re-stake” mostra que, mesmo quando era o centro das atenções da indústria, não conseguimos esclarecer devidamente o conceito. Eis a “lição zero” — focar numa narrativa central e repeti-la continuamente.
O objetivo da equipa Eigen sempre foi “fácil de explicar, difícil de fazer”: ao aumentar a verificabilidade do cálculo off-chain, permitir que as pessoas construam aplicações on-chain de forma mais segura.
O AVS foi o nosso primeiro e claro ensaio nesta direção.
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 destes operadores é monitorizado e, em caso de violação das regras, os seus ativos em stake são penalizados. Para que este “mecanismo de penalização” funcione, é necessário que exista “capital em stake” como suporte.
É aqui que reside o valor da re-stake: sem que cada AVS tenha de construir um sistema de segurança do zero, a re-stake permite reutilizar o ETH já em stake, fornecendo segurança a vários AVS. Isto não só reduz o custo de capital, como acelera o arranque do ecossistema.
Portanto, o quadro conceptual da re-stake pode ser resumido assim:
AVS: a “camada de serviço”, base dos novos sistemas de segurança criptoeconómica PoS;
Re-stake: a “camada de capital”, que, ao reutilizar ativos em stake, fornece segurança a estes sistemas.
Continuo a achar esta ideia engenhosa, mas a realidade não foi tão perfeita como no diagrama — muitos resultados ficaram aquém do esperado.
O que não correu como esperado
Escolhemos o mercado errado: demasiado nicho
Não queríamos “qualquer tipo de cálculo verificável”, mas insistimos num sistema que fosse, desde o primeiro dia, descentralizado, baseado em penalizações e totalmente seguro do ponto de vista criptoeconómico.
Queríamos que o AVS fosse um “serviço de infraestrutura” — tal como os programadores podem criar SaaS (Software as a Service), qualquer pessoa poderia construir um AVS.
Esta posição, embora de princípio, reduziu imenso o universo potencial de programadores.
O resultado foi um mercado “pequeno, lento e com barreiras elevadas”: poucos utilizadores potenciais, custos de implementação elevados e ciclos longos para ambas as partes (equipa e programadores). Quer a infraestrutura da EigenLayer, quer as ferramentas de desenvolvimento, quer cada AVS de topo, tudo leva meses ou anos a ser construído.
Avançando quase três anos: atualmente temos apenas dois AVS principais em produção — o DIN (Decentralized Infrastructure Network) da Infura e o EigenZero da LayerZero. Esta “taxa de adoção” está longe de ser “generalizada”.
A verdade é que, no início, concebemos cenários para “equipas que querem, desde o primeiro dia, segurança criptoeconómica e operadores descentralizados”, mas a procura de mercado real pedia soluções “mais graduais, mais centradas na aplicação”.
Fomos forçados ao “silêncio” pelo ambiente regulatório
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 regulatória rigorosa em relação às criptomoedas). Nessa altura, várias empresas de staking estavam sob investigação e processos judiciais.
Como projeto de re-stake, quase tudo o que dizíamos em público podia ser interpretado como “promessa de investimento”, “publicidade de rendimentos” e até atrair intimações.
Este nevoeiro regulatório condicionou a nossa comunicação: não podíamos falar livremente, nem mesmo para rebater uma onda de notícias negativas, parceiros a sacudir responsabilidades ou ataques na opinião pública; não podíamos esclarecer mal-entendidos em tempo real.
Nem sequer podíamos dizer simplesmente “as coisas não são assim” — era preciso ponderar primeiro o risco legal.
O resultado foi que, sem comunicação suficiente, lançámos tokens com vesting. Agora, olhando para trás, foi realmente arriscado.
Se alguma vez achaste que a equipa Eigen foi evasiva ou anormalmente silenciosa sobre algum tema, provavelmente foi por causa deste ambiente regulatório — um simples tweet errado podia trazer riscos consideráveis.
Os AVS iniciais diluíram o valor da marca
A força inicial da marca Eigen devia-se, em grande parte, ao Sreeram (membro central da equipa) — a sua energia, otimismo e a crença de que tanto sistemas como pessoas podem melhorar, conquistaram grande simpatia para a equipa.
E dezenas de milhares de milhões em capital em stake reforçaram ainda mais essa confiança.
No entanto, o co-marketing com os primeiros AVS não esteve à altura desta “marca”. Muitos desses AVS eram barulhentos, mas apenas perseguiam as tendências do sector, não eram exemplos “tecnicamente superiores” ou “de máxima integridade”.
Com o tempo, as pessoas começaram a associar “EigenLayer” a “novo yield farming e airdrops”. Muitas das dúvidas, cansaço e até aversão de hoje remontam a esta fase.
Se pudesse voltar atrás, preferia começar com “menos, mas melhores AVS”, ser mais seletivo nos parceiros a quem emprestamos a marca e aceitar um ritmo mais lento e menos hype na divulgação.
Excesso de busca pela “minimização de confiança” levou a design redundante
Tentámos construir um “sistema de penalização universal perfeito” — que fosse versátil, flexível e cobrisse todos os cenários de penalização, alcançando assim a “minimização de confiança”.
Mas, na prática, isso tornou o desenvolvimento do produto lento e obrigou-nos a gastar muito tempo a explicar um mecanismo que “a maioria ainda não estava preparada para entender”. Mesmo hoje, ainda temos de fazer pedagogia sobre o sistema de penalização lançado há quase um ano.
Olhando para trás, teria sido mais sensato lançar primeiro um modelo de penalização simples, deixar cada AVS experimentar abordagens mais focadas, e só depois ir aumentando a complexidade do sistema. Mas nós pusemos o “design complexo” logo de início, acabando por pagar em “velocidade” e “clareza”…
Esta página pode conter conteúdo de terceiros, que é fornecido apenas para fins informativos (não para representações/garantias) e não deve ser considerada como um endosso de suas opiniões pela Gate nem como aconselhamento financeiro ou profissional. Consulte a Isenção de responsabilidade para obter detalhes.
O que aconteceu ao mercado de re-staking? Análise dos erros e sucessos dois anos após o design do EigenLayer
Análise profunda do caminho da re-stake da EigenLayer: os erros cometidos, os méritos da EigenDA, tudo a preparar o novo rumo da EigenCloud. Este artigo é da autoria de Kydo, responsável pela narrativa da EigenCloud, com organização, tradução e redação de Saoirse, Foresight News.
(Resumo anterior: Relatório de 10 mil palavras — Compreender totalmente o líder da re-stake, EigenLayer) (Informação de fundo: O que é EigenDA, o produto emblemático do protocolo de re-stake EigenLayer?)
De tempos a tempos, amigos enviam-me tweets a gozar com a re-stake, mas nenhum deles acerta verdadeiramente no ponto. Por isso decidi escrever eu próprio um artigo com uma certa dose de reflexão e crítica.
Talvez penses que estou demasiado envolvido para ser objetivo; ou que sou demasiado orgulhoso para admitir que “falhámos”. Podes pensar que, mesmo que toda a gente já considere que a “re-stake falhou”, eu ainda escreveria um longo artigo a defender-me, sem nunca usar a palavra “falha”.
Todas estas opiniões são razoáveis e, em muitos casos, justificadas.
Mas este artigo pretende apenas apresentar os factos de forma objetiva: o que aconteceu realmente, o que resultou, o que não correu bem e que lições tirámos disso.
Espero que as experiências partilhadas aqui sejam universais e possam servir de referência a outros programadores do ecossistema.
Depois de mais de dois anos a integrar todos os principais AVS (Serviços de Validação Autónoma) na EigenLayer e a desenhar a EigenCloud, quero fazer uma retrospetiva honesta: onde errámos, onde acertámos e qual o caminho a seguir.
Afinal, o que é a re-stake (Restaking)?
O simples facto de eu ainda precisar de explicar “o que é a re-stake” mostra que, mesmo quando era o centro das atenções da indústria, não conseguimos esclarecer devidamente o conceito. Eis a “lição zero” — focar numa narrativa central e repeti-la continuamente.
O objetivo da equipa Eigen sempre foi “fácil de explicar, difícil de fazer”: ao aumentar a verificabilidade do cálculo off-chain, permitir que as pessoas construam aplicações on-chain de forma mais segura.
O AVS foi o nosso primeiro e claro ensaio nesta direção.
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 destes operadores é monitorizado e, em caso de violação das regras, os seus ativos em stake são penalizados. Para que este “mecanismo de penalização” funcione, é necessário que exista “capital em stake” como suporte.
É aqui que reside o valor da re-stake: sem que cada AVS tenha de construir um sistema de segurança do zero, a re-stake permite reutilizar o ETH já em stake, fornecendo segurança a vários AVS. Isto não só reduz o custo de capital, como acelera o arranque do ecossistema.
Portanto, o quadro conceptual da re-stake pode ser resumido assim: AVS: a “camada de serviço”, base dos novos sistemas de segurança criptoeconómica PoS; Re-stake: a “camada de capital”, que, ao reutilizar ativos em stake, fornece segurança a estes sistemas.
Continuo a achar esta ideia engenhosa, mas a realidade não foi tão perfeita como no diagrama — muitos resultados ficaram aquém do esperado.
O que não correu como esperado
Não queríamos “qualquer tipo de cálculo verificável”, mas insistimos num sistema que fosse, desde o primeiro dia, descentralizado, baseado em penalizações e totalmente seguro do ponto de vista criptoeconómico.
Queríamos que o AVS fosse um “serviço de infraestrutura” — tal como os programadores podem criar SaaS (Software as a Service), qualquer pessoa poderia construir um AVS.
Esta posição, embora de princípio, reduziu imenso o universo potencial de programadores.
O resultado foi um mercado “pequeno, lento e com barreiras elevadas”: poucos utilizadores potenciais, custos de implementação elevados e ciclos longos para ambas as partes (equipa e programadores). Quer a infraestrutura da EigenLayer, quer as ferramentas de desenvolvimento, quer cada AVS de topo, tudo leva meses ou anos a ser construído.
Avançando quase três anos: atualmente temos apenas dois AVS principais em produção — o DIN (Decentralized Infrastructure Network) da Infura e o EigenZero da LayerZero. Esta “taxa de adoção” está longe de ser “generalizada”.
A verdade é que, no início, concebemos cenários para “equipas que querem, desde o primeiro dia, segurança criptoeconómica e operadores descentralizados”, mas a procura de mercado real pedia soluções “mais graduais, mais centradas na aplicação”.
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 regulatória rigorosa em relação às criptomoedas). Nessa altura, várias empresas de staking estavam sob investigação e processos judiciais.
Como projeto de re-stake, quase tudo o que dizíamos em público podia ser interpretado como “promessa de investimento”, “publicidade de rendimentos” e até atrair intimações.
Este nevoeiro regulatório condicionou a nossa comunicação: não podíamos falar livremente, nem mesmo para rebater uma onda de notícias negativas, parceiros a sacudir responsabilidades ou ataques na opinião pública; não podíamos esclarecer mal-entendidos em tempo real.
Nem sequer podíamos dizer simplesmente “as coisas não são assim” — era preciso ponderar primeiro o risco legal.
O resultado foi que, sem comunicação suficiente, lançámos tokens com vesting. Agora, olhando para trás, foi realmente arriscado.
Se alguma vez achaste que a equipa Eigen foi evasiva ou anormalmente silenciosa sobre algum tema, provavelmente foi por causa deste ambiente regulatório — um simples tweet errado podia trazer riscos consideráveis.
A força inicial da marca Eigen devia-se, em grande parte, ao Sreeram (membro central da equipa) — a sua energia, otimismo e a crença de que tanto sistemas como pessoas podem melhorar, conquistaram grande simpatia para a equipa.
E dezenas de milhares de milhões em capital em stake reforçaram ainda mais essa confiança.
No entanto, o co-marketing com os primeiros AVS não esteve à altura desta “marca”. Muitos desses AVS eram barulhentos, mas apenas perseguiam as tendências do sector, não eram exemplos “tecnicamente superiores” ou “de máxima integridade”.
Com o tempo, as pessoas começaram a associar “EigenLayer” a “novo yield farming e airdrops”. Muitas das dúvidas, cansaço e até aversão de hoje remontam a esta fase.
Se pudesse voltar atrás, preferia começar com “menos, mas melhores AVS”, ser mais seletivo nos parceiros a quem emprestamos a marca e aceitar um ritmo mais lento e menos hype na divulgação.
Tentámos construir um “sistema de penalização universal perfeito” — que fosse versátil, flexível e cobrisse todos os cenários de penalização, alcançando assim a “minimização de confiança”.
Mas, na prática, isso tornou o desenvolvimento do produto lento e obrigou-nos a gastar muito tempo a explicar um mecanismo que “a maioria ainda não estava preparada para entender”. Mesmo hoje, ainda temos de fazer pedagogia sobre o sistema de penalização lançado há quase um ano.
Olhando para trás, teria sido mais sensato lançar primeiro um modelo de penalização simples, deixar cada AVS experimentar abordagens mais focadas, e só depois ir aumentando a complexidade do sistema. Mas nós pusemos o “design complexo” logo de início, acabando por pagar em “velocidade” e “clareza”…