Why the EVM processes transactions one at a time
The Ethereum Virtual Machine executes transactions sequentially within a block, one after another, in a single thread. This isn't an oversight, it's a direct consequence of the contract-storage model: since the EVM doesn't know in advance which storage slots a given transaction will touch until it actually runs, and any transaction could in principle read or write any contract's storage, the safe default is to process them strictly in order. Running things one at a time guarantees no two transactions can step on each other's state mid-execution, but it means throughput is capped by how fast a single core can churn through the queue, adding more hardware to a validator doesn't make execution faster.
Solana's Sealevel runtime takes a different approach that's only possible because of the account model covered earlier. Because every transaction must explicitly declare, upfront, exactly which accounts it will read and which it will write, the runtime can inspect a batch of pending transactions before executing any of them and figure out which ones have overlapping account access and which don't. Transactions that don't touch any of the same accounts are provably independent of each other, there's no way they can interfere, so they can be scheduled onto separate cores and run genuinely at the same time.