O próprio Ethereum deve passar no teste de saída. O Ethereum é criado para ser um lar para aplicações sem confiança e minimizadas em confiança, seja em finanças, governança ou outros campos. Ele deve suportar aplicações que são mais como ferramentas – o martelo que, uma vez que você compra, é seu – do que serviços que perdem toda funcionalidade quando o fornecedor perde o interesse em mantê-los (ou pior, são hackeados ou se tornam extraídos de valor). Mesmo quando as aplicações possuem funcionalidades que dependem de um fornecedor, o Ethereum pode ajudar a reduzir essas dependências o máximo possível e proteger o usuário nos casos em que as dependências falham. Mas construir tais aplicações não é possível em uma camada base, que por sua vez depende de atualizações contínuas de um fornecedor para continuar sendo utilizável – mesmo que esse "fornecedor" seja o processo central dos desenvolvedores. O Ethereum, o blockchain, deve ter as características que buscamos nas aplicações do Ethereum. Portanto, o próprio Ethereum deve passar no teste de desistência. Isso significa que o Ethereum precisa chegar a um ponto em que _can ossificar se quisermos to_. Não precisamos parar de fazer mudanças no protocolo, mas precisamos chegar a um ponto em que a proposta de valor do Ethereum não dependa estritamente de recursos que ainda não estejam no protocolo. Isso inclui o seguinte: * Resistência quântica total. Devemos resistir à armadilha de dizer "vamos adiar a resistência quântica até o último momento possível em nome de conseguir mais eficiências por mais um tempo". Usuários individuais têm esse direito, mas o protocolo não deveria. Poder dizer "O protocolo do Ethereum, como está hoje, é criptograficamente seguro por cem anos" é algo que devemos tentar alcançar o quanto antes e insistir como motivo de orgulho. * Uma arquitetura que possa se expandir para escalabilidade suficiente. O protocolo precisa ter propriedades que permitam expandir até milhares de TPS ao longo do tempo, especialmente a validação ZK-EVM e a amostragem de dados por meio do PeerDAS. Idealmente, chegamos a um ponto em que a escalabilidade adicional é feita por meio de mudanças "apenas de parâmetros" - e idealmente _essas_ mudanças não são forks no estilo BPO, mas sim feitas com o mesmo mecanismo de votação validador que usamos para o limite de gás. * Uma arquitetura estatal que pode durar décadas. Isso significa decidir e implementar qualquer forma de ausência parcial de estado e vencimento de estado nos fará sentir confortáveis para deixar o Ethereum rodar com milhares de TPS por décadas, sem quebrar os requisitos de sincronização, disco rígido ou E/S. Também significa preparar para o futuro as árvores e os tipos de armazenamento para que funcionem bem com esse ambiente de longo prazo. * Um modelo de conta que é de propósito geral (isso é "abstração total da conta": afaste-se do ECDSA consagrado para validação de assinaturas) * Um cronograma de gás que temos confiança está livre de vulnerabilidades DoS, tanto para execução quanto para prova de ZK * Um modelo econômico PoS que, com tudo o que aprendemos ao longo dos últimos cinco anos de prova de participação no Ethereum e uma década além dele, nos faz confiar que pode durar e permanecer descentralizado por décadas, e apoia a utilidade do ETH como garantia sem confiança (por exemplo, em stablecoins com ETH minimizada por governança) * Um modelo de construção de blocos que temos confiança que resistirá à pressão centralizadora e garantirá resistência à censura mesmo em ambientes futuros desconhecidos Idealmente, faremos o trabalho duro nos próximos anos para chegar a um ponto em que, no futuro, quase toda inovação futura possa acontecer por meio da otimização do cliente e se refletir no protocolo por meio de mudanças nos parâmetros. Todo ano, devemos marcar pelo menos uma dessas caixas, e idealmente várias. Faça a coisa certa uma vez, com base no conhecimento do que é realmente certo (e não faça concessões pela metade), e maximize a robustez tecnológica e social do Ethereum a longo prazo. Ethereum vai com tudo. Este é o gwei.

Mensagem em vídeo do presidente do Federal Reserve, Jerome H. Powell:

Eu realmente acho que todo mundo nessa área deveria imediatamente mudar para usar o Vim. A RPDC começou a abusar dos ganchos VS Code que rodam _automaticamente_ em segundo plano quando você abre uma pasta. ZERO interação do usuário necessária _depois_ de confiar no repositório (a parte de confiar é importante aqui). Sim, leia de novo. ZERO. INTERAÇÃO. NECESSÁRIO. então o que acontece é o seguinte: eles (no caso usual do grupo Contagious Interview, ou seja, algum recrutador falso) compartilham repositórios do GitHub, Bitbucket e GitLab contendo um subdiretório '.vscode/' com ganchos maliciosos. o único exemplo que compartilho aqui executa uma fonte falsa que na verdade é um JS muito ofuscado e que vai te reconhecer com certeza. Todo seu software sofisticado que parece "conveniente" faz concessões. Essas trocas agora estão sendo abusadas para rekem silenciosamente seus dispositivos. Use Vim. e usar Qubes. Valeu.