Ethereum co-founder Vitalik Buterin stated that synchronizing an Ethereum node currently takes about half a day at the fastest, with aggressive configurations allowing disk usage to be below 0.5 TB, primarily due to EIP-4444 and ongoing optimizations for snapshot synchronization across various clients.

He mentioned that the upcoming Glamsterdam upgrade will continue to improve synchronization, and Nimbus's new synchronization protocol has adopted relevant mechanisms. Users can point their wallet's remote procedure calls to local nodes, but must correctly enable the node's RPC; some decentralized applications in browsers cannot effectively utilize local RPC, while others hard-code RPC to their own servers. He expressed a preference for avoiding browser applications in favor of command line usage, and has updated ENS records using a Python script connected to the local node. The next step for the Kohaku command line tool will be to integrate privacy protocols, with early development already underway.

EIP-4444 aims to relieve the execution layer from permanently storing all history, separating historical retrieval from "each full node maintaining a complete disk," while snapshot synchronization allows new nodes to pull state first and then catch up, rather than replaying from scratch. Nimbus has long pursued lightweight and beacon-side synchronization, and connecting the new protocol to Glamsterdam effectively turns client differences into a single item on the upgrade list. Kohaku is being advanced by the Ethereum Foundation's access layer initiative, aiming to make security, trustlessness, and read-write privacy the default, including assigning independent addresses for each new application and encapsulating privacy protocols like Railgun for wallets and agents to call.

Home-grade hard drives and the half-day window lower the barrier for building nodes, but browser wallets and hosted RPCs remain the default entry points. Infura, Alchemy, self-built RPCs, and wallet vendors sell usability; local nodes sell verification and privacy. Funds are flowing back from pay-per-request centralized RPCs to operators willing to allocate disk space and bandwidth, provided that the application layer no longer locks remote addresses. Beneficiaries are client teams and command line users who can point to 127.0.0.1; those under pressure are applications that hard-code RPC and rely on browser injection.

Source: Public Information