Uma consequência positiva de todo o pensamento detalhado recente sobre formatos de transação — não apenas o 8141, mas também discussões sobre “o futuro do estado”, como UTXOs, PBT, nonces com chave e mempool recursivo STARK — é que temos uma compreensão muito mais explícita de como as transações possuem “ações” e “dependências”, e podemos projetar otimizações para cada uma separadamente. Uma ação é um efeito que uma transação produz. Uma dependência é um fato sobre a transação e/ou o estado que deve ser verdadeiro para que a transação seja válida. Por exemplo: uma assinatura é uma dependência, uma prova Merkle de um UTXO é uma dependência, um ZK-SNARK (ou STARK) é uma dependência, uma chamada que envia ETH é uma ação. Dependências podem ser processadas em paralelo. Dependências que envolvem estado podem ser analisadas por um mempool, especialmente se o estado específico acessado for declarado estaticamente. Dependências puras (sem chamadas a estado permitidas) podem ser processadas uma única vez na camada do mempool e nunca mais precisam ser processadas novamente — e potencialmente até substituídas por um STARK que as verifique, permitindo não apenas a execução, mas também a elisão de dados. Em princípio, dependências e ações podem todas ser expressas como chamadas (se necessário, chamadas a precompilados). Isso tornaria o próprio formato de transação muito minimalista (uma lista de chamadas, flags para o tipo de cada chamada — por exemplo, dependências seriam chamadas estáticas ou puras — e origem, nonce, etc.), permitindo máxima compatibilidade cruzada mesmo que diferentes cadeias EVM tenham recursos distintos. Na Ethereum da era 2015, pensar explicitamente sobre essas diferenças não era muito importante: execução era execução, havia poucas transações suficientes para processá-las todas sequencialmente, e contas ECDSA de chave única eram suficientes para todos. A atual estratégia de escalabilidade da Ethereum, no entanto, exige ir além desse paradigma. A Ethereum é amada por muitos desenvolvedores porque seu modelo de execução e estado é tão dinâmico e flexível. Mas dinâmico e flexível não é amigável à escalabilidade. Felizmente, mais de 90% da atividade da Ethereum em volume não requer nada dinâmico ou flexível. Portanto, precisamos que contratos, contas e transações especifiquem explicitamente o que é dinâmico e flexível e o que é mais analisável estaticamente, mas mais restritivo; e coisas mais analisáveis estaticamente recebem o menor custo de gás e, portanto, escalam mais. Efetivamente, aprendendo com o melhor dos dois modelos — o da Ethereum da era 2015 e um modelo mais parecido com o Bitcoin (lembrete: o Bitcoin possui o que chamo de abstração de conta desde o início) — e disponibilizando uma mistura de ambos (na verdade, todo o espectro entre eles), com custos de gás apropriados ao nível de escalabilidade envolvido. Novos tipos de estado, o mempool recursivo STARK, nonces com chave, etc., todos seguem nessa direção. Isso tudo está relacionado aos tipos de transação, porque um tipo de transação de propósito geral é uma camada de interface muito natural sobre a qual tudo isso pode ser implementado, e o pensamento atual em torno do tipo de transação EIP-8141 está indo exatamente nessa direção, amigável a essas generalizações futuras. Portanto, nesse sentido, o 8141 bem feito não é apenas o culminar de 10 anos de trabalho em abstração de conta, mas também um preparativo para os próximos anos de hiper-escalabilidade responsável e amigável à descentralização.