Una consecuencia positiva de todo el reciente pensamiento detallado sobre formatos de transacción —no solo 8141, sino también discusiones sobre el "futuro del estado", como UTXOs, PBT, nonces con clave y el mempool recursivo STARK— es que tenemos una comprensión mucho más explícita de cómo las transacciones tienen "acciones" y "dependencias", y podemos diseñar optimizaciones para cada una por separado. Una acción es un efecto que tiene una transacción. Una dependencia es un hecho sobre la transacción y/o el estado que debe ser verdadero para que la transacción sea válida. Por ejemplo: una firma es una dependencia, una prueba Merkle de un UTXO es una dependencia, un ZK-SNARK (o STARK) es una dependencia, una llamada que envía ETH es una acción. Las dependencias pueden procesarse en paralelo. Las dependencias que involucran estado pueden razonarse mediante un mempool, especialmente si el estado específico accedido se declara estáticamente. Las dependencias puras (que no permiten llamadas a estado) pueden procesarse una sola vez en la capa del mempool y nunca necesitar volver a procesarse —y potencialmente incluso reemplazarse con un STARK que las verifique, permitiendo no solo omitir la ejecución sino también los datos. En principio, las dependencias y las acciones pueden expresarse todas como llamadas (si es necesario, llamadas a precompilados). Esto haría que el formato de transacción en sí fuera muy minimalista (una lista de llamadas, banderas para el tipo de cada llamada, por ejemplo: las dependencias serían llamadas estáticas o puras, y origen, nonce, etc.) y permitiría una máxima compatibilidad cruzada, incluso si distintas cadenas EVM tienen características diferentes. En la Ethereum de 2015, pensar explícitamente en estas diferencias no era muy importante: la ejecución era ejecución, había suficientemente pocas transacciones como para procesarlas todas en serie, y las cuentas ECDSA de clave única eran suficientes para todos. La estrategia actual de escalado de Ethereum, sin embargo, requiere ir más allá de ese paradigma. Ethereum es querido por muchos desarrolladores porque su modelo de ejecución y estado es tan dinámico y flexible. Pero lo dinámico y flexible no es amigable con el escalado. Afortunadamente, más del 90% de la actividad de Ethereum en volumen no requiere nada dinámico ni flexible. Por lo tanto, requerimos que los contratos, cuentas y transacciones especifiquen explícitamente qué es dinámico y flexible y qué es más analizable estáticamente pero más restrictivo; y lo analizable estáticamente obtiene el menor costo de gas y, por lo tanto, escala más. En efecto, aprendiendo de lo mejor del modelo de Ethereum de 2015 y de un modelo más parecido a Bitcoin (recordatorio: Bitcoin ha tenido lo que yo llamo abstracción de cuenta desde el principio), y haciendo disponible una mezcla de ambos (en realidad, todo el espectro entre ambos), con costos de gas adecuados al nivel de escalado involucrado. Nuevos tipos de estado, el mempool recursivo STARK, los nonces con clave, etc., van todos en esta dirección. Todo esto se relaciona con los tipos de transacción, porque un tipo de transacción de propósito general es una capa de interfaz muy natural sobre la cual todo esto puede implementarse, y el pensamiento actual sobre el tipo de transacción EIP-8141 va exactamente en esta dirección, favorable a este tipo de generalizaciones futuras. Por lo tanto, en ese sentido, 8141 bien implementado no es solo la culminación de 10 años de trabajo en abstracción de cuenta, sino también una preparación para los próximos años de hiperescalado responsable y amigable con la descentralización.