Estou cedendo, vou chamar o Twitter de "X" a partir de agora. "Tweet" se torna um termo genérico para mensagens em qualquer plataforma que priorize conteúdo de texto curto com UX semelhante ao X, linguisticamente semelhante ao "kleenex". Guia de uso: * "Vitalik só está tuitando sobre Farcaster e Lens este ano, não é horrível o quanto ele é elitista da torre de marfim?" * "Você viu o novo e chocante tweet racista de Donald Trump no Truth Social?" * "Quando enviei isso em 2019, era um tweet, e por essa nova definição ainda é, mas agora também podemos nos referir a isso ex-post como um X post" "Crypto Twitter" pode permanecer como uma frase fixa, de forma semelhante a como Peking Duck ainda é chamado de Peking Duck, embora, claro, seria engraçado se mais pessoas o chamassem de CryptoX (também conhecido como CrypTox). (Este tweet foi enviado simultaneamente pelo X, Farcaster e Lens via Firefly)

Tenho acompanhado as reações ao que eu disse sobre L2 há cerca de 1,5 dias. Uma coisa importante que acredito é: "criar mais uma cadeia EVM e adicionar uma ponte otimista para o Ethereum com um atraso de 1 semana" é infraestruturar o que forkar Compound é para a governança – algo que fizemos demais por tempo demais, porque nos acostumamos, e que esgotou nossa imaginação e nos colocou em um beco sem saída. Se você fizer uma cadeia EVM *sem* uma ponte otimista para o Ethereum (também conhecida como um L1 alternativo), isso é ainda pior. Não precisamos de mais blockchains de EVM, e definitivamente não precisamos de mais L1s. O L1 está escalando e vai trazer muito espaço de bloco EVM - não infinito (IAs em particular vão precisar tanto de mais espaço de bloco quanto de menor latência do que até mesmo um L1 muito escalonado pode oferecer), mas muito. Construa algo que traga algo novo para a mesa. Dei alguns exemplos: privacidade, eficiência específica do app, latência ultra-baixa, mas minha lista certamente está muito incompleta. Uma segunda coisa importante que acredito é: sobre "conexão com Ethereum", as vibrações precisam combinar com conteúdo. Pessoalmente, sou fã de muitas coisas que podem ser chamadas de "cadeias de aplicativos". Por exemplo, acho que há uma grande chance de que a arquitetura ótima para mercados de previsão seja algo como: o mercado é emitido e resolvido no L1, as contas dos usuários estão no L1, mas a negociação acontece em algum sistema baseado em rollup ou outro tipo L2, onde a execução lê o L1 para verificar assinaturas e mercados. Gosto de arquiteturas onde a conexão profunda com o L1 é de primeira classe, e não um pensamento tardio ("somos praticamente uma cadeia separada, mas sim, temos uma ponte, e ok, tudo bem, vamos colocar 1-2 devs para levar ao estágio 1 para que o pessoal do L2beat coloque um selo verde para o Vitalik gostar da gente"). O outro extremo da "cadeia de aplicativos", por exemplo, A versão em que você convence algum registro governamental, ou plataforma de redes sociais, ou coisa de jogos, a começar a colocar raízes Merkle em seu banco de dados, com STARKs que provam que toda atualização foi autorizada, assinada e executada de acordo com um algoritmo pré-comprometido, onchain, também é razoável – isso é o que faz mais sentido para mim em termos de "L2s institucionais". Obviamente não é Ethereum, não é credivelmente neutro e não é confiável – o operador sempre pode simplesmente escolher dizer "agora estamos mudando para uma versão diferente com regras diferentes". Mas isso possibilitaria transparência algorítmica verificável, uma propriedade que muitos de nós adoraríamos ver no governo, nos algoritmos das redes sociais ou em qualquer outro lugar, e pode possibilitar atividades econômicas que de outra forma não seriam possíveis. Acho que, se você for a primeira opção, é válido e ótimo se chamar de aplicativo Ethereum – ele não sobrevive sem Ethereum nem tecnologicamente, maximiza a interoperabilidade e a composabilidade com outras aplicações Ethereum. Se você é a segunda coisa, então você não é Ethereum, mas está (i) trazendo para a humanidade mais transparência algorítmica e minimização de confiança, então está perseguindo uma visão semelhante, e (ii) dependendo dos detalhes, provavelmente é sinérgico com o Ethereum. Então você deveria dizer essas coisas diretamente! Basicamente: 1. Faça algo que traga algo realmente novo para a mesa. 2. As vibrações devem combinar com o conteúdo – o grau de conexão com o Ethereum na sua imagem pública deve refletir o grau de conexão que seu projeto tem com o Ethereum na realidade.

Na verdade, não acho que seja complicado. Na minha opinião, o futuro do design de mecanismos onchain vai se encaixar principalmente em um padrão: [algo que pareça um mercado de previsão] -> [algo que pareça um dispositivo de definição de preferências resistente à captura e não financializado] Em outras palavras: * Uma camada que seja o máximo aberta e maximize a responsabilidade (é um mercado, qualquer um pode comprar e vender, se você tomar boas decisões ganha dinheiro; se tomar decisões ruins, perde dinheiro) * Uma camada que é descentralizada e pluralista, e que maximiza o espaço para a motivação intrínseca. Isso não pode ser baseado em tokens, porque os donos de tokens não são pluralistas, e qualquer um pode comprar e receber 51% deles. Os votos aqui deveriam ser anônimos, idealmente com MACI para reduzir o risco de conluio. O mercado de previsão é a forma correta de fazer um "executivo descentralizado", porque o primitivo mais lógico para "responsabilidade" em um conceito sem permissão é exatamente esse. Embora às vezes você queira manter simples e fazer um executivo centralizado nessa camada: [executivo centralizado substituível] -> [algo que pareça um dispositivo de definição de preferências resistente à captura e não financeirizado] Pensar explicitamente nessas duas camadas: (i) o que está fazendo sua execução, (ii) o que está fazendo sua definição de preferências e o julgamento do(s) executor(es), é o melhor.