Acabei de chegar a Mumbai! Estou ansioso para encontrar rostos conhecidos e novos, e todos os maravilhosos projetos de tecnologia Ethereum e aberta/segura/privada/descentralizada em que todos estão trabalhando na próxima semana.

Em última análise, precompilados e EVM são ambos o local errado para implementar a maioria do suporte à criptografia no ethereum. A razão é que precompilados e EVM operam em dados que precisam ser incluídos na blockchain ethereum de alguma forma, o que, na prática, significa incluídos em um bloco como calldata. Esse espaço é limitado — mesmo com PeerDAS e blocks-in-blobs, há um limite prático de ~8 MB/s antes de começar a ficar incômodo. Lembre-se: não é uma blockchain. É um computador criptográfico mundial. Qualquer dado/computação que não precise estar no “thread principal” de dados/execução não deve ser colocado nesse thread principal. A solução correta é... maximalismo do EIP-8288. Se você tiver qualquer computação pesada e autocontida, calcule-a e gere um STARK no lado do cliente (isso está ficando cada vez mais rápido, até em telefones) e envie o STARK por meio do mecanismo de agregação recursiva do EIP-8288. A cadeia vê apenas o fato de que a computação foi realizada e qual é o resultado; ela nunca precisa ver os dados ou a computação reais. Dessa forma, todos podem usar qualquer criptografia que desejarem, a cadeia ethereum pode ser leve e nunca mais precisaremos adicionar mais precompilados.

Curiosidade do dia: O custo da mineração de bitcoin é dividido aproximadamente 50/50 entre capex de computação e eletricidade. Enquanto isso, a inferência de IA é quase completamente dominada pelo capex de computação. https://t.co/PCFKZSuNRw

Wrapped zkAPI + Tor + tráfego de cobertura adicional + reescrita local de prompts LLM em um daemon compatível com OpenAI, e criei um wrapper de "modo paranoico" para meu agente (pi): Cada conversa recebe um circuito Tor separado, suas requisições são mascaradas com tráfego de cobertura aleatório, o zkAPI garante que você não vaze sua identidade por meio de pagamentos, e todos os prompts são reescritos localmente (traga-seu-próprio-modelo-local; estou usando qwen3.8-flash-next). https://t.co/MepCFCrLv1 Meu agente é encapsulado com um sandbox bwrap (também experimentando com MicroVM) e novamente encapsulado com torsocks, então tudo o que ele faz passa pelo Tor. Aqui está o que parece quando eu peço a ele para realizar uma tarefa simples de pesquisa. Está ficando bastante utilizável! Embora você ainda pague bastante em latência aumentada, especialmente ao iniciar uma nova conversa. Além disso, o Tor está longe de ser ideal aqui para privacidade; o mecanismo de tráfego de cobertura é razoável contra adversários passivos, mas muito mais fraco se o provedor do LLM estiver coludindo com o guardião e manipulando ativamente o tempo. Esse tipo de tarefa realmente exige uma mixnet mais especializada, provavelmente aceitando a compensação de um multiplicador de largura de banda maior e tráfego de cobertura constante integrado. Também, custos muito mais baixos de gás para depositar e sacar com zkAPI estão chegando ao mainnet em breve.

Correção: para multisigs, a regra ideal de "segurança" é que cada assinante deve alterar sua chave após cada operação. (Isso pressupõe implicitamente que o ECDSA possa se tornar fraco, mas não ao ponto de qualquer quebra ser literalmente instantânea, então você realmente precisaria se preocupar com, por exemplo, frontrunning no mempool) Você ainda deseja coletar assinaturas offchain, se possível, para minimizar o número de horas entre "assinatura revelada" e "chave não mais ativa". Mas, novamente: é muito fácil perder fundos com uma atualização apressada e mal configurada, então... não apresse nada.

Não recomendo que ninguém se apresse para transferir seus fundos para novas carteiras hoje. Mas devemos levar a sério os riscos à criptografia provenientes da matemática acelerada por IA e minimizar nossa exposição não apenas à criptografia vulnerável a quantum, mas também à criptografia potencialmente vulnerável a IA. A nova área central de risco, infelizmente, é o ML-DSA / FHE / reticulados. (e também é mais uma razão, juntamente com o quantum, pela qual o ECDSA pode cair ainda mais rápido do que o esperado, daí a recomendação de “endereço novo”) Até agora, a maioria das pessoas tem pensado assim: “curvas elípticas quebradas, hashes seguros, reticulados seguros”. Mas há uma boa chance de que a segurança concreta dos reticulados sofra sérios golpes nos próximos dois anos de matemática impulsionada por IA. O modelo de ameaça básico é: fatoração é algo que, ingenuamente, leva 2^(n/2) tempo, mas ao longo de décadas pessoas inteligentes descobriram e otimizaram peneiras de corpo numérico, reduzindo isso para 2^O(n^(1/3)), o que explica por que chaves e assinaturas RSA precisam ter ~400 bytes (e não 64 bytes). E se houver esqueletos no armário assim, tanto para curvas elípticas quanto para reticulados, que simplesmente não somos inteligentes o suficiente para descobrir — mas bots em breve serão? Essa é uma grande parte da razão pela qual, no último ano, a rota da ethereum enxuta tem seguido na direção “apenas hash”: sem reticulados, sem ML-DSA, sem Falcon, sem compromissos baseados em reticulados dentro de provas ZK, etc. Assinaturas na ethereum enxuta são todas baseadas em hash, seja WOTS ou SPHINCS-. Para assinaturas e provas, já sabemos como ir apenas com hash. O maior desafio é para *criptografia de chave pública* — e isso vai muito além das blockchains. Comunicação segura, protocolos de anonimização, muitas coisas precisam de criptografia de chave pública. E infelizmente existem teoremas matemáticos bem estabelecidos que mostram por que a criptografia de chave pública não pode ser feita apenas com hashes. É necessário algum tipo de objeto “armadilha” que tenha pelo menos uma forma de “estrutura” utilizável — seja teoria de grupos (incluindo isogenias), reticulados, baseados em códigos ou talvez no futuro até coisas ainda mais novas e estranhas (mistura local?). Mas para qualquer coisa que tenha estrutura, você deve assumir que a IA fará pelo menos algum progresso em quebrar essa estrutura. Aqui, uma inferência razoável é que, se você quiser tornar algo plausivelmente seguro a longo prazo, multiplique os tamanhos das chaves por 10. Para mim, esse é um mundo muito plausível e algo nada extremo de prever. Se a IA nos trazer 50 anos de matemática em 2 anos, então esses 50 anos de matemática podem muito bem incluir uma melhoria do tipo “fatoração ingênua → GNFS” na nossa capacidade de quebrar reticulados. Nesse mundo, os reticulados ainda existirão, mas terão que ser significativamente maiores para garantir o mesmo nível de segurança. E nesses novos tamanhos maiores, construções baseadas em hash superarão construções baseadas em reticulados em eficiência concreta em todos os casos de uso onde construções baseadas em hash são possíveis. Teoricamente, é claro que é possível que os hashes também sejam quebrados (por exemplo, P = NP implicaria isso). Mas acho P = NP muito improvável. E intuitivamente, é muito mais provável que um objeto matemático tenha exatamente nenhuma estrutura explorável (como os hashes são intencionados a ser), do que que um objeto matemático tenha exatamente ~3 formas de estrutura explorável (para curvas elípticas: associatividade, Schoof, emparelhamentos) e nenhuma quarta forma secreta de estrutura ainda não descoberta que degrade drasticamente sua segurança (para curvas elípticas: ECDLP e segurança de emparelhamentos). O mesmo vale para LWE, SVP, RLWE e toda a gama de problemas de reticulados. Por essa razão, ainda não vemos nenhuma razão para se preocupar e começar a aumentar o tamanho em bytes dos hashes (se começarmos a nos preocupar mais, aumentaríamos primeiro o número de rodadas antes de fazer qualquer coisa ao tamanho em bytes). TLDR concreto, minhas próprias opiniões pessoais: * Hash-based > lattice-based, nas situações onde hash-based é possível em absoluto * Para qualquer coisa baseada em reticulados, seja muito mais paranoico com os tamanhos dos parâmetros. Lembre-se de que blockchains são apenas uma pequena parte da história da criptografia; esse ponto vai muito além das blockchains e se aplica a, por exemplo, acesso a sites, mensagens seguras, Tor / VPNs... * Para protocolos de privacidade, prefira fortemente NÃO colocar notas criptografadas na blockchain. Em vez disso, envie-as offchain por meio de algum mecanismo de terceiros. * Se não for difícil para você, manter seus fundos em endereços que ainda não foram usados para fazer uma transação é uma boa ideia. Se for fácil para você, faça isso. **Mas tenha cuidado com migrações; pessoalmente perdi mais dinheiro em migrações mal-sucedidas do que em todos os hacks combinados**. * Para carteiras multisig, fazer confirmações offchain é melhor do que onchain, pois dessa forma as assinaturas das carteiras dos signatários não ficam expostas ao público; assim, se o ECDSA cair muito mais rápido do que o esperado por IA, pelo menos o multisig “degrada suavemente” para um 1-de-1 onde o 1 é quem estava reunindo as assinaturas — um lugar muito melhor do que “qualquer um pode pegar o dinheiro”. https://t.co/oVjwZog2lL

qwen3.8-flash-next cliente ethereum 100+ GB de wikipedia, gutenberg e artigos científicos baixados localmente o que mais? (Eliminar a necessidade de serviços centralizados de pinagem no IPFS está definitivamente entre as principais prioridades)

É uma vitória subestimada dos desenvolvedores de clientes Ethereum que o PeerDAS está funcionando há quase um ano com praticamente nenhum problema. PeerDAS foi uma tarefa complexa: é o primeiro exemplo em grande escala de uma blockchain que alcança consenso sobre a disponibilidade de dados sem exigir que qualquer nó baixe o bloco inteiro. Consenso descentralizado sem replicação. E, ainda assim, funcionou.

Disgusto com a tendência recente de pessoas que claramente ainda acreditam em mais de 80% das crenças centrais do efetivismo altruista, mas rejeitam o EA e dizem “ah, certamente não somos isso, somos [rebrand]” puramente estrategicamente, apenas porque sentem que criticar o EA agora é “chique”. É muito mais honroso simplesmente dizer: “sim, isso foi parte significativa da minha formação intelectual, e seus valores centrais — cuidado com os outros, cosmopolitismo e rigor na alocação eficaz de recursos — continuam sendo muito importantes para mim. E aqui estão pontos específicos em que discordo, e aqui está meu argumento sobre por que acho que esse subconjunto desse estilo de pensamento é o que mais falhou”. E, portanto, vou dizer: Sim, o efetivismo altruista foi uma parte significativa da minha formação intelectual, e seus valores centrais de cuidado com os outros, cosmopolitismo e rigor na alocação eficaz de recursos continuam sendo muito importantes para mim. E aqui estão pontos específicos em que discordo do que acho ser o subconjunto desse estilo de pensamento que mais falhou: https://t.co/iJYPFNaOgg

Um pequeno exemplo da tese central d/acc (melhorar a tecnologia passiva de defesa melhora a segurança e, ao mesmo tempo, melhora a liberdade e a maioria das outras propriedades da organização social que nos importam) são as paredes insonorizadas. Antigamente, tínhamos muito menos isolamento acústico e regras de comportamento muito mais restritivas, disputas (tanto dentro das famílias quanto entre elas), despejos, etc. Mais tarde, resolvemos esse problema criando e implantando paredes melhores, e agora isso é uma questão sobre a qual todos nós precisamos nos preocupar muito menos. Quais são as “paredes insonorizadas” do século XXI que ainda não construímos ou implantamos suficientemente?