Today's options are
- Run a full node. That takes days to sync and at least 1TB SSD...
- Run a light node. Barely works, relies on altruism from full nodes who are serving an API for free.
- Use a hosted node API, like Infura or Alchemy.
Almost everyone uses that last option, often without even realizing it. Metamask, for example, defaults to Infura. Unfortunately, the last option is also completely trusted and centralized. An API provider can tell you anything about the state of the chain, and your client (wallet, browser, etc) has no way to verify.
This is about to improve. We a few amazing technologies that are approaching maturity.
1. The new light client protocol. The Merge is coming. Ethereum is about to switch from proof-of-work to proof-of-stake. The new protocol--the one currently powering the Beacon Chain--comes with much improved light client support. This is under active development, but looks close to the finish line.
2. API provider support for light clients. This seems like a detail at first, but is actually a huge change in the role of API providers. Today, API providers represent a significant risk, trusted by most Ethereum end-users without verification. After this change, Ethereum clients can sync the chain thru an API provider instead of just using RPC to ask questions like "what's the latest block" or "what's the balance of this account". The provider becomes untrusted: simply a more efficient, more sustainable (paid), lower-latency way for a light client to download data. The client verifies, independently, that a supermajority of all staked eth has attested the tip of the chain by checking signatures.
An API provider can still censor a client's transactions, but they can no longer do so sneakily. The client will know whether their transaction made it into the canonical chain or not. The API provider can't lie about the state of the chain in any way. Alchemy, Infura, etc become fully commoditized, competing only on price and performance, not on trustworthiness.
An Ethereum client can even connect to several providers, treating them just like P2P peers. Score each one based on latency and bandwidth, send requests preferentially to the best ones, etc. Paying per-request creates a real-time revenue incentive for each provider to maximize performance. At maturity, we should see thoroughly colocated API providers, using Cloudflare or similar, giving Ethereum users sub-20ms-latency access to information--this is faster than most web2 apps.
To mitigate censorship risk, clients can write (send transactions) to a different provider than they read (sync the chain) from. For example, send transactions to a Flashbots relay, while reading from both Alchemy and Infura. Censorship is easily detectable and the client can automatically ban offending providers from its rotation.
--
A lot of the foundational work for an Ethereum-native browser is coming together. I have conviction, at this point, that the next era of crypto dapps will not just be websites running in Chrome, requesting Metamask. We can do better than that. One key ingredient is reliable, high-performance light clients, and it looks like we'll be getting those by the end of the year.
It's an exciting time. And as always, the bear is for builders 🐻