Ethereum
Um contrato que continua executando após uma chamada falha não tem hoje uma maneira confiável de determinar se o chamado foi revertido intencionalmente ou simplesmente ficou sem gás, escolha do remetente. Essa lacuna é a raiz do griefing por gás insuficiente, e uma nova proposta em rascunho tenta fechá-la no nível EVM. EIP-8456, aberta para discussão no Ethereum Magicians na segunda-feira, adiciona uma instrução chamada CALLSTATUS, temporariamente no opcode 0xA5 por 2 de gás. Ela empurra o status de conclusão da chamada ou operação de criação mais recente no frame atual como três bits. O bit 0 significa um revert, o bit 1 significa uma parada excepcional, como falta de gás, e o bit 2 significa que algo em um frame abaixo foi interrompido. O autor aponta que a única evidência atual é a aritmética de gasleft() após a chamada, e que cada fork de repricing quebrou esses limiares. O proposto gás bidimensional da EIP-8037 tornaria essa aritmética ainda mais fraca, pois seu reservatório não é visível através do opcode GAS. Então, por que o terceiro bit? A maioria das chamadas reais passa por intermediários como proxies, o wrapper functionCall da OpenZeppelin, Multicall3 ou verificadores de assinatura ERC-1271. Se apenas o resultado do chamado direto fosse relatado, um wrapper que captura uma parada por falta de gás e faz um revert com uma razão pareceria um revert intencional. O rascunho mantém uma flag persistente que viaja por todos os frames, de modo que um remetente que controla apenas o gás nunca pode fazer um chamador ler um revert simples. Ele relata resultados em vez de causas, e um chamado ainda pode produzir uma parada intencional com INVALID. Ele protege apenas código escrito após seu lançamento, pois contratos implantados não o lerão. Ainda não há revisões externas, o número do opcode ainda está aberto, e um protótipo mais testes para 58 casos listados ainda está pendente. Link - https://t.co/KnByUBgWrY
A maioria das carteiras de ethereum ainda exibe todo o histórico financeiro do usuário para qualquer pessoa que tenha seu endereço, e a Ethereum Foundation agora está classificando isso como uma falha de segurança, e não apenas como um recurso de privacidade desejável. Na segunda-feira, a Foundation publicou que os ataques e explorações da semana passada deixaram claro para eles que privacidade e segurança não podem ser tratadas como objetivos separados. Sua posição é que você pode se preocupar menos com um atacante usando seu histórico onchain contra você quando a privacidade for o padrão. A postagem citou uma atualização sobre o Kohaku, o projeto de ferramentas de privacidade da Foundation. O repositório JavaScript divide-se em pacotes que uma equipe de carteira pode adotar um por vez. Há bibliotecas para Privacy Pools e Tornado Cash, além de uma biblioteca Railgun que o README atualmente marca como em manutenção. Um pacote de plugins define uma interface padrão para protocolos de pool blindado, permitindo que uma carteira se comunique com todos eles da mesma maneira. Um pacote provider abstrai ethers, viem, Helios e Colibri. O repositório também inclui uma conta ERC-4337 pós-quântica. Crate em Rust estão em um repositório irmão separado. Gosto que isso seja apresentado como um SDK e não como mais uma carteira de privacidade pedindo aos usuários para transferirem fundos. A ideia é que carteiras existentes adicionem fluxos blindados sem que cada equipe precise reimplementar três protocolos. O README é direto sobre o estado atual das coisas. Alguns componentes estão marcados como não prontos para produção, e os pacotes contêm código não auditado. Jordan Enev, da Ambire, disse na sexta-feira passada que a equipe passou meses testando as integrações, e nenhuma data de lançamento pública foi anunciada. Vitalik e Nicolas Consigny estão programados para demonstrar o Kohaku com a Ambire no mainnet do ethereum na próxima terça-feira, segundo a lista de sessões. Aqui está o repositório - https://t.co/egNbLgAo0J
Seu terminal agora pode responder a você, e o curioso é que ele faz isso sem chamar nenhuma API em nuvem. No sábado, a Ollama lançou a versão 0.40.11 com síntese de voz no macOS. O primeiro modelo de voz é o Phonon, uma família de pequenos modelos TTS da Gradium. Você o baixa com o comando ollama pull phonon e o executa como qualquer outro modelo. A parte que os desenvolvedores realmente vão se importar é a API. Phonon funciona com o endpoint /v1/audio/speech compatível com OpenAI em localhost. Se seu código já usa o SDK da OpenAI para voz, a documentação diz que você só precisa de uma nova URL base. A resposta é transmitida enquanto o áudio está sendo gerado, permitindo que a reprodução comece antes de todo o texto ser concluído. Você pode até encadear diretamente a resposta de um modelo de chat para o Phonon, e ele começa a falar após a primeira frase. A saída é em 24 kHz mono, em formato WAV por padrão ou PCM bruto de 16 bits se solicitado. A documentação lista alguns limites que são fáceis de ultrapassar. Cada solicitação aceita até 4.096 caracteres, embora o ollama run divida automaticamente textos mais longos. Preços, símbolos, e-mails e URLs são pronunciados letra por letra, enquanto datas numéricas são lidas como escritas; por isso, a documentação sugere escrever datas por extenso. Opções não suportadas, como velocidade ou instruções, retornam um erro 400 em vez de serem ignoradas silenciosamente. A licença merece uma leitura cuidadosa antes de você lançar qualquer coisa. O modelo padrão em inglês do Phonon é Apache 2.0. As variantes em francês, alemão, espanhol, português e multilíngues de 40M são CC BY-NC 4.0, o que exclui uso comercial. A Ollama também afirma que, em um MacBook Pro M5 Max, ele funcionou 35% mais rápido que o próprio runtime da Gradium — um benchmark da própria empresa, não independente. A síntese de voz é exclusiva para Apple Silicon por enquanto, com suporte ao Windows e Linux listado como em breve.
Um L2 do Ethereum que aceita assinaturas zero parece um bug de segurança, mas o BB84 está fazendo isso intencionalmente para evitar ataques quânticos. No fim de semana passado, seu fundador, que posta como Hadamard, publicou o design no Ethereum Research e pediu feedback crítico. BB84 é um rollup da OP Stack no mainnet, ativo desde 30 de setembro, onde as transações L2 não utilizam ECDSA em absoluto. Cada conta é a ponta de uma cadeia de hashes keccak-256 construída a partir de um segredo, com 1.000 passos, por padrão. Para gastar, sua carteira revela o valor anterior na cadeia, que qualquer um pode verificar com um único hash. Dentro do L2, a única suposição restante é a resistência à pré-imagem do keccak-256, que o algoritmo de Grover reduz para cerca de 2^128 de trabalho. Revelar um segredo o torna público, então o protocolo adiciona um passo de commit e reveal para vincular cada pré-imagem a uma transação primeiro. Dois novos tipos de transação no op-geth lidam com isso, e a verificação do remetente substitui o ecrecover. A autorização é consumida mesmo quando a chamada é revertida, e se uma carteira perder o passo de renovação no último elo, esse endereço fica inativo. O post inclui uma falha de front-running que a equipe descobriu enquanto o escrevia. Commits não carregam assinatura, então um novo commit anteriormente podia substituir um pendente, e um atacante poderia vincular uma pré-imagem revelada ao seu próprio pagamento. Uma regra que entrou em vigor em 21 de outubro faz com que o primeiro commit vença. Os limites são explicitados claramente. Depósitos e saques L1 ainda usam ECDSA. Ainda não há fault proofs, e segundo o próprio post, a cadeia nem sequer alcançaria o Estágio 0 do L2BEAT. O sequenciador é executado pela equipe, e endereços de 160 bits deixam cerca de 2^80 de resistência quântica a pré-imagens secundárias. O post também pergunta se contas baseadas em cadeias de hash poderiam se tornar um EIP-7702 ou um modo nativo de validação de abstração de conta em L2s gerais.
A OpenZeppelin tornou a Chainlink a padrão para cross-chain e conformidade em suas ferramentas de token, e se você marcar a caixa de conformidade, a licença do seu token muda. Há uma semana, a OpenZeppelin anunciou uma parceria estratégica com a Chainlink. CCIP e ACE, o protocolo cross-chain da Chainlink e seu Automated Compliance Engine, agora estão integrados ao Contracts Wizard, as ferramentas de IA da OpenZeppelin e sua documentação. Os geradores de ERC20, Stablecoin e RWA oferecem ambas as opções. Selecionar a opção CCIP expõe as chamadas de mint e burn necessárias para o pool de burn-and-mint da Chainlink, atrás das permissões próprias do token. Também nomeia um administrador para o registro CCIP. Essa parte mantém a licença que você escolheu, pois nenhum código da Chainlink é inserido. A opção ACE é diferente. Ela encaminha transferências, mints e burns para um Policy Engine que você implanta e configura. A própria documentação da OpenZeppelin afirma que tokens que usam ACE estão sob a BUSL-1.1, e o uso em produção deve satisfazer a licença ACE e suas autorizações de uso adicionais. Por anos, um token gerado pela OpenZeppelin carregava a licença que você escolheu, geralmente MIT. Agora, uma única caixa de seleção muda isso, e um desenvolvedor júnior apressado pode nunca perceber. O gerador não registra seu pool, define permissões nem escreve suas políticas. Conectar um Policy Engine não configura nenhuma política, e você permanece responsável por cumprir quaisquer regras aplicáveis a você. O anúncio também menciona um caminho de migração do OpenZeppelin Defender para o Runtime Environment da Chainlink. Nada disso está oculto, e para uma equipe de RWA que já deseja a Chainlink, isso economiza trabalho real de integração. Só quero que os construtores escolham isso intencionalmente, não porque o assistente o colocou lá.
Smart contract maxis, Seu compilador Solidity pode ter excluído silenciosamente um armazenamento que você precisava, e você nunca o veria em seu código-fonte. O Solidity 0.8.38 foi lançado na quinta-feira passada. Ele corrige um bug no otimizador Yul que estava presente em todas as versões de 0.8.19 a 0.8.37. O otimizador mantém anotações sobre o que está na memória e no armazenamento. Ele usa essas anotações para substituir uma carga por um valor que já conhece e para pular um armazenamento que escreve o que já está lá. Para decidir se dois endereços podem se sobrepor, ele descreve cada um como uma variável base mais um deslocamento. Mesma base, deslocamento diferente, então devem ser slots diferentes. Essas descrições eram armazenadas em cache. Depois, alguém reatribui a variável base. O otimizador nem sempre percebe. Agora ele compara um endereço construído com o valor antigo com outro construído com o valor novo, como se compartilhassem a mesma base. Ele decide que são diferentes, mas em tempo de execução apontam para o mesmo local. O resultado é uma anotação desatualizada. Uma carga posterior pode retornar um valor antigo. Um armazenamento que você precisava pode ser removido. Um keccak256 nesse local pode gerar hash de dados desatualizados. Apenas código compilado com o otimizador ativado está exposto. Com via-IR, qualquer código pode atingi-lo, mesmo sem assembly embutido. Com o pipeline legado padrão, apenas alguns trechos de assembly embutido e funções auxiliares geradas pelo compilador. Builds não otimizados são seguros. A equipe classifica como baixa gravidade, e fizeram algo que desejo que toda equipe de compiladores fizesse: Recompilaram todos os contratos verificados no banco de dados do Sourcify com e sem a correção, e o bytecode foi idêntico para todos eles. Portanto, é raro. Raro não é o mesmo que nunca, especialmente se seu código for novo e ainda não implantado. O bug foi descoberto através do programa de recompensa de falhas da Ethereum Foundation, e um segundo relatório mostrou que Solidity simples, sem assembly, também pode acioná-lo.
O impulso masculino de ser ETH maxi. 🥳
Ethereum é Ethereum e sempre será. No próximo fork, a comunidade Ethereum verá a verdadeira magia do protocolo.