Recently, Vitalik (@ VitalikButerin) has been putting in a lot of effort. He and (@ oispoke, @ nero'eth, @ lightclients) have jointly proposed EIP-8250 (Keyed Nonces for Frame Transactions). This proposal is worth paying attention to: Because it is preparing for Ethereum to achieve ultimate scalability, privacy, and decentralization. First, let's talk about the current situation: In the past, when Ethereum was used for trading, it was like a supermarket with only one checkout counter, and everyone had to wait in long lines. After you pay, you will receive a number called nonce (the sender's account serial number), which is used to prevent replay attacks and sorting. If someone gets stuck ahead (due to delayed or failed transactions), everyone behind has to wait and do. Especially with regards to privacy transfer, the biggest issue is that many ZK privacy pools use shared senders (sending multiple withdrawals from the same address), which require waiting for the previous one to be on chain before sending the next one. Otherwise, nonce conflicts can occur, making it particularly prone to traffic congestion. What does EIP-8250 want to do now? It is equivalent to adding a "nonce key" to each Ethereum transaction thus, Previously, there was only one long queue at the checkout counter, but now there can be multiple queues because different keys are different queues. Moreover, each small queue forms its own queue without affecting each other. For privacy scenarios, there is a 'nullifier' (one-time voucher/ticket to prevent double spending) in privacy transfers, and each withdrawal action is unique. Nowadays, under this approach, it is supported to directly use this ticket as a "channel number": Do you want to withdraw 10 amounts of money at the same time? Send directly with 10 different channel numbers together. The first one to be put on the chain will void the corresponding ticket to prevent double spending. At the same time, you don't have to wait for the previous confirmation, you can run in parallel. In the long run, this is what Vitalik cares most about: EIP-8250 is not only intended to solve the problem of queue congestion, but also to prepare for future large-scale expansion. Ethereum will distinguish between two types of "storage" in the future: • Ordinary dynamic storage (DeFi and other relatively complex applications) • Dedicated simple storage (specifically for storing these nullifier tickets) Dedicated storage is easy to optimize: • Can be divided into sections You can use black technologies such as Bloom filters to store billions of ticket nodes without getting stuck Node computers do not need to store hundreds of TB of data and can maintain decentralization In summary, Transforming single lane highways into multi lane highways, while preparing for a future that is fast, private, and decentralized.