Preço de Eigen

A verificabilidade é a vantagem mais importante da criptografia. Bitcoin e Ethereum nos deram dinheiro e finanças verificáveis. A próxima etapa relacionada à verificabilidade é diferente das 2 etapas anteriores. O problema com as inovações do Bitcoin e do Ethereum é que esses dois tipos de verificabilidade existem no ambiente criptográfico, mais precisamente, no ambiente on-chain. Depois que as pessoas realmente exploraram o poder da verificabilidade on-chain, houve um tempo em que as pessoas tentavam construir tudo on-chain. Jogos, mensageiros, utilitários, músicas, notícias, todo tipo de aplicativo clássico foi colocado (ou quase colocado) na cadeia. Durante essa mania, poucas pessoas disseram: "Por que tem que estar no blockchain?". Muitas pessoas dos setores de TradFi e TI começaram a construir as mesmas coisas que estavam construindo em suas indústrias, mas no blockchain. A maioria deles não deu certo, mais precisamente, quase nenhum deles deu certo. Essa pergunta se tornou um meme. A principal resposta a esta pergunta foi: "não precisa estar no blockchain". Acredito que tanto a pergunta quanto a resposta estavam erradas. 1. Primeiro motivo: as pessoas não entenderam a proposta de valor central das criptomoedas. A ideia central era apenas colocar algo onchain, sem pensar nos benefícios que a implantação onchain traz. Portanto, a proposta de valor central naquele momento é que algo on-chain já é melhor do que algo que não é on-chain, apenas porque é construído em infraestrutura descentralizada. • A principal vantagem é clara - o aplicativo está usando arquitetura descentralizada. • As principais desvantagens também são claras – cálculos caros e lentos em comparação com a arquitetura centralizada. Então é isso, certo? Não. O principal valor que os aplicativos ganham por estar no blockchain não é a infraestrutura descentralizada em si, mas a verificabilidade que essa infraestrutura descentralizada traz. Construir toda a lógica do aplicativo on-chain é doloroso e irracional, por vários motivos: • Você está limitado a um software específico que só funciona em determinada VM (máquina virtual) • Você está limitado a hardware específico para as necessidades de sua aplicação • Você está limitado ao protocolo de consenso do blockchain • Você está limitado a interações com o mundo exterior e à obtenção de dados externos Sim, os contratos inteligentes podem obter dados externos por meio de oráculos, mas eles têm seus próprios problemas de confiança e esses dados são públicos. Blockchains operam com base na premissa de transparência, portanto, obter dados públicos externos não é difícil, mas obter dados privados é muito mais difícil (não se esqueça das suposições de confiança). Seguindo essa lógica, pode parecer que devemos nos ater apenas ao que a indústria on-chain oferece e construir dentro desses limites, certo? Claro que não! A maior vantagem que a criptografia tem é a verificabilidade: cada usuário pode verificar de forma independente a correção, integridade e autenticidade de cada ação. Mais importante ainda, eles podem ter certeza de que não são traídos e se impedir de trair outros usuários. No entanto, como eu disse antes, nem tudo pode ser colocado na cadeia, porque é lento, caro ou simplesmente impossível. Você não pode simplesmente colocar instruções expressivas e complexas (código) onchain. Copiar e colar não funciona nesse caso. É por isso que as soluções anteriores não funcionaram: eles tentaram colocar toda a infraestrutura onchain, o que naturalmente limita a funcionalidade do aplicativo, porque as ferramentas de desenvolvimento web3 são muito mais estreitas do que as ferramentas web2 (pelo menos por enquanto). 2. Se não podemos construir toda a infraestrutura on-chain, podemos construir pelo menos uma parte dela? Todos os aplicativos precisam de verificabilidade? Não, mas a maioria deles. Vamos pegar uma plataforma onde você está lendo este texto - Twitter. Conforme observado por @shilpi_jc, o Twitter precisa de verificabilidade para: • cálculos de receita de anúncios (porque os criadores querem ter certeza de que são pagos de forma justa) • visualizações reais do usuário (para garantir que as visualizações não sejam botadas) • trending topics (porque tem enorme poder sobre o discurso público) •etc. "Por que estamos discutindo o Twitter? Ninguém vai colocar o Twitter em um blockchain". Sim, ninguém vai fazer isso, porque é impossível: • você não pode chamar APIs • Você não pode executar algoritmos de detecção de bots • você não pode fazer nada complexo O que você pode fazer é escrever uma função simples que calcule os pagamentos com base apenas na contagem de visualizações, que pode ser facilmente botada. Se considerarmos sistemas complexos como a IA, @_jasonwei escreveu sobre a Lei do Verificador: "A facilidade de treinar a IA para resolver uma tarefa é proporcional à verificabilidade da tarefa". Se algo é fácil de resolver (como transferências), pode ser verificável on-chain. O treinamento de modelos complexos de IA consome muitos recursos, portanto, a verificação desse modelo também exigirá muitos recursos, que a infraestrutura blockchain atual simplesmente não está pronta para alocar. • Não podemos colocar lógica de aplicativo complexa on-chain, mas talvez possamos colocar pelo menos a parte central dessa lógica para atualizar o estado e facilitar as transferências de valor? • Você não pode executar algoritmos de detecção de bots para calcular o número real de visualizações, mas podemos pelo menos ter pagamentos por essas visualizações on-chain? Podemos, também podemos armazenar e atualizar o estado final on-chain, não é tão caro computacionalmente. Então, decidimos que podemos manter a lógica relacionada ao consenso na cadeia, mas e os cálculos mais complexos? Para se ter uma ideia de quão longe estamos de colocar tudo on-chain, @0xbodu notei que: • Seriam necessárias centenas de cadeias MegaETH para replicar a funcionalidade global do Uber. • E seriam necessárias centenas de cadeias MegaETH para fazer o mesmo apenas para Nova York. 3. Podemos manter a lógica básica onchain e tornar a lógica complexa verificável? Definitivamente, queremos manter a lógica básica on-chain, mas e quanto a outras lógicas mais complexas? O primeiro pensamento natural é usar algo como a AWS e seus microsserviços. Sim, podemos, mas falta verificabilidade, o que é crucial para muitos aplicativos de consumo e infraestrutura. O que devemos fazer? Temos que encontrar uma maneira de tornar essa lógica complexa verificável. Já temos muita verificabilidade para ativos digitais e contratos inteligentes, mas agora queremos aplicar isso a infraestruturas mais complexas. 4. EigenCloud? @eigenlayer recentemente renomeado para EigenCloud para aumentar o foco na verificabilidade. Embora o EigenLayer fosse conhecido principalmente como o protocolo de restaking no Ethereum, essa percepção não é exatamente correta. Refazer o staking subconscientemente significa verificabilidade, se algo pode ser cortado - pode ser verificado. O restaking é parte do motivo pelo qual a verificabilidade é possível, mas adicionar cortes à infraestrutura não a torna automaticamente verificável. Todas as aplicações consistem em vários componentes. O principal aprendizado por trás do produto EigenCloud é que nem todos os componentes do aplicativo precisam ser verificáveis e, se precisarem de verificação, existem diferentes níveis disso. Existem 3 níveis diferentes de verificabilidade na maioria das aplicações: • Lógica simples (transferências): verificabilidade on-chain • Lógica complexa (API, algoritmos, AI/ML): verificabilidade off-chain • Lógica de rotina: sem verificabilidade O EigenCloud se concentra na verificabilidade fora da cadeia, onde sistemas complexos e componentes de sistemas complexos devem ser verificados. Houve inúmeros artigos sobre a arquitetura EigenCloud, verificabilidade off-chain e como ela funciona e não quero repeti-los. O que eu quero fazer é dar 3 exemplos de como a verificabilidade de sistemas complexos é importante e como até mesmo sistemas não criptográficos podem se beneficiar do EigenCloud. Vou pegar 3 casos diferentes: jogos, robótica (inspirada em @jinglingcookies) e futuro relacionamento cyberpunk entre agente e humano. 5. Verificabilidade em jogos e como tornar o jogo mais justo. Passei 7 anos da minha vida (mais precisamente 12.000 horas) jogando Team Fortress 2 (TF2), que é um jogo de tiro multiplayer. Já vi o suficiente e sei como funciona cada mecânica do jogo. No entanto, houve coisas que me deixaram profundamente chateado. Eu não percebi o porquê até começar a aprender mais sobre verificabilidade e aplicá-la à minha experiência anterior. • Tivemos o problema de bots hackers inundando os servidores e 13 dos 24 jogadores eram bots. • Os bots estavam chutando jogadores reais votando, porque eles são a maioria. • Eles destruíram servidores e tornaram o jogo literalmente impossível de jogar por um certo período de tempo. Sim, existem sistemas anti-cheat, mas esses sistemas anti-cheat não foram capazes de identificar que eram bots e hackers, eles continuaram jogando o jogo injustamente. Se os sistemas anti-cheat verificassem que o jogador é um bot, hacker ou está usando cheats, eles não seriam capazes de jogar. Se os sistemas anti-trapaça acusassem falsamente jogadores reais de trapacear - esses sistemas seriam cortados. Outra característica interessante do TF2 são os críticos aleatórios. Críticos aleatórios acontecem aleatoriamente quando o jogador atira na arma e dá 3x mais dano do que normalmente receberia com um acerto normal. • Problema: existem algumas armas no jogo que constantemente dão mais críticos aleatórios do que outras armas. • Quando a chance crítica aleatória básica é de 2%, algumas armas deram 20% de chance e usaram vantagem injusta sobre outros jogadores. Se a lógica responsável por críticos aleatórios fosse realizada em EigenCloud, seria verificável e a arma acabaria sendo nerfada. Obviamente, o TF2 não precisa de verificação para tudo, mas alguns componentes realmente precisam disso. A lógica para armazenar e trocar itens dentro do jogo pode ser armazenada on-chain e ser totalmente verificável, porque essa lógica é bastante trivial. Eu jogaria mais alguns anos se eles consertassem esses problemas (talvez). 6. Verificabilidade na indústria de robótica e por que é muito mais importante do que você pensa. A indústria de robótica está se desenvolvendo muito rapidamente e também há muitos problemas, especialmente relacionados à interoperabilidade segura entre 2 robôs. • Imagine que você tem um robodog que patrulha sua casa. • Robodog detecta algo estranho e suspeito. • Robodog alerta seu robô humanóide em casa sobre o que viu. O processo de informar é a transferência de dados, que os dados devem ser seguros e verificáveis, caso contrário, podem literalmente arriscar sua vida. Nesse caso, ambos os robôs podem até operar como mini-blockchain armazenando um estado compartilhado de memória, onde cada informação é verificável. Para o processo de verificação (EigenVerify), os dados devem ser armazenados em algum lugar (EigenDA), para garantir que estejam disponíveis para verificação por todos os períodos de tempo dentro de um período de tempo. • Quando lidamos com robôs, temos que ter certeza de que cada robô é verificável. • Se lidarmos com vários robôs, temos que garantir que as mensagens (interoperabilidade) entre esses robôs também sejam verificáveis. O desalinhamento e o comportamento injusto podem ter consequências muito piores do que os bots em jogos de computador. 7. Verificabilidade em futuras empresas com zero funcionários administradas por agentes de IA. @shayonsengupta escreveu um artigo incrível no início de 2025 sobre a Relação Humano-Agente. De acordo com o artigo, no futuro haverá empresas com zero funcionários onde há um ou vários agentes operando. Será financiado por humanos e os agentes alocarão capital para ações que não podem fazer ou serão inteligentes o suficiente para pensar sobre o que precisam para fazer a empresa crescer. A suposição é que os agentes podem fazer o mesmo no futuro e serão tão inteligentes que qualquer contribuição humana arruinará o resultado e a tendência para zero. (O mesmo aconteceu antes com os bots de xadrez, onde o impacto humano mínimo faz com que o sistema tenha um desempenho pior do que sem o toque humano) Se houver realmente o mundo em que viveremos, realmente precisamos da verificabilidade de cada ação que o agente fará. Especialmente nesta conexão entre agentes e humanos. Os agentes darão tarefas aos humanos e os recompensarão após a conclusão. • Como verificar se a tarefa foi realmente concluída? • Como verificar se um agente recompensou o humano? • Como verificar se um agente recompensou o humano certo? • Como verificar se um agente recompensou a quantia certa de dinheiro para o humano certo? Existem infinitas perguntas e apenas uma resposta: Tudo foi verificado para garantir que o sistema não seja malicioso e prejudicial. Os trilhos de criptografia são os mais adequados neste caso, pois os pagamentos podem ser facilitados on-chain, enquanto a infraestrutura mais complexa de agentes e a coordenação humano-agente podem ser off-chain. 8. Uso de verificabilidade fora da indústria de criptografia. A infraestrutura tenderá a ser aplicada globalmente ao ecossistema cripto mais amplo e, em seguida, fora da criptografia. • Por exemplo: EigenCloud não se limita ao Ethereum, esta infra pode ser usada para outros L1s como Solana ou outros L2s com ou fora do Ethereum. • O mesmo com o EigenDA, não é apenas middleware entre L2 e L1, ele pode ser aplicado a qualquer componente onde as entradas e saídas de computação devem permanecer acessíveis para verificação. A verificabilidade de criptografia pode até ser usada em eventos de julgamento esportivo. • Em esportes como patinação artística ou ginástica, os juízes pontuam subjetivamente as performances em arte e técnica, muitas vezes levando a pontuações variadas. • Pontuações discrepantes podem convidar a acusações de escrutínio ou preconceito. • Os juízes podem se alinhar com a maioria para evitar críticas. Um modelo de IA pode padronizar as avaliações usando métricas predefinidas (por exemplo, rastreamento de movimento), com penalidades apenas para os operadores que manipulam as entradas ou saídas do modelo. Cada ação desse modelo de IA deve ser verificável, caso contrário, também pode ser tendenciosa em relação a determinados resultados e simplesmente não faz sentido. Existem 3 níveis de verificação: • Blockchain (on-chain): lida com pagamentos, não custódia e lógica simples • EigenCloud (off-chain): lida com sistemas complexos que realmente precisam de verificabilidade • Nuvem tradicional: lida com armazenamento de conteúdo, interfaces de usuário, etc. Embora a maioria dos aplicativos exija genuinamente verificabilidade, eles não precisam ser totalmente verificáveis. Isso ocorre porque alguns aspectos simplesmente não precisam de verificação e não há necessidade de incluí-los apenas por uma questão de verificabilidade. A ideia central por trás do EigenCloud e da borda mais ampla da criptografia é fornecer verificabilidade onde ela é realmente necessária, não para tudo o que existe. A criptomoeda permitiu um progresso significativo nas provas de conhecimento zero - um conceito que existia anteriormente, mas recebeu menos atenção. O mesmo acontecerá com a verificabilidade, na verdade, já está acontecendo.