Foundations

We’re working to improve the user story for reading Ethereum. To explain how, we first need a clear and accessible model of the problems at hand. Ethereum has evolved significantly, and we expect it to keep evolving. Nonetheless, the foundations of what Ethereum is and aims to be remain constant.

Ethereum is fundamentally a social agreement: a collection of protocols with clearly specified rules, agreed upon by people, and instantiated by voluntary participation. Part of what underpins the legitimacy of Ethereum is the absence of a central authority that hands down its state by decree. Instead, Ethereum is a globally distributed singleton: consensus establishes what state is canonical, and every participant independently enforces validity.

Every reader of Ethereum, whether a full node or a wallet, must answer the same four questions:

  • Connectivity: who can I talk to? Find and reach the peers that make up the network.
  • Canonicity: what do I trust? Securely obtain a canonical trust anchor.
  • Authentication: given a trust anchor, what is true? Prove facts against that anchor.
  • Availability: how can I obtain data? Retrieve data, such as balances, today and into the future.

A reader reaches consensus through the network, obtains a trust anchor, and proves balances, code, and storage against it

To improve reading Ethereum is to improve how readers answer these four questions. Failing any one of them is failing entirely. Our strategy has two parts: ecosystem stewardship and technology derisking.

Ecosystem stewardship

We document the problem space and candidate solutions, so the ecosystem can act on a shared model. By naming problems and curating solutions we can support incremental progress and help steer towards ends which reflect the core values of Ethereum.

One core value we strive to foster is optionality: ensuring that users can freely choose between interchangeable peers with minimal switching costs. This is achieved through pushing for open standards where markets can emerge to compete on price and quality, with standard interfaces.

Technology derisking

Some candidate directions depend on techniques that are unproven at the scale readers need. Providers won’t build on techniques whose feasibility and cost are unknown. We answer those questions ourselves: we build prototypes, measure real costs, and publish the results as reusable libraries.

For example, private information retrieval (PIR) lets a reader query a provider without revealing what it retrieved, which mitigates both surveillance and censorship. Historically, PIR’s latency, compute cost, and operational burden have kept it out of production. As research on any such technique progresses, we try to get ahead and prepare for adoption across the ecosystem.

01

Connectivity

Who can I talk to?

Find and reach the peers that serve you. A peer you cannot discover is absent, and one you cannot dial might as well be.

02

Canonicity

What do I trust?

Obtain a trust anchor rather than being handed one. Everything downstream is measured against it.

03

Authentication

What is true?

Prove facts against that anchor instead of accepting them. A balance you cannot check is a balance someone told you.

04

Availability

How do I get the data?

Retrieve state today and years from now, without the act of retrieving it announcing what you were looking for.

05

Open problems

described once, properly

Requirements that cannot be expressed or verified show up as specific, describable failures. These are the ones in scope, written up once and properly, each with a stable URL. Not all of them are about privacy.