Skip to main content

5 posts tagged with "Architecture & System Design"

View All Tags

The Problem​

Today, securing Ethereum costs 32 ETH—locking out most users. Proof-of-Work and Proof-of-Stake make influence expensive. This ensures Sybil resistance but hurts decentralization.

To build a truly open network, anyone should be able to help secure it cheaply, without compromising safety.

The Idea: Lightweight Validators + Data Nodes​

Instead of making every participant store all data or stake huge sums, split responsibilities:

Data Nodes​

  • Store and serve blockchain data.
  • Require high bandwidth/CPU.
  • Open, replicated network. Validators audit them, so strict Sybil resistance is less critical.

Validator Nodes (Phones, Laptops)​

  • Run lightweight validation tasks.
  • Sign votes, challenge data nodes, contribute entropy.
  • Participation measured by uniqueness and uptime, not capital or compute.

Result: anyone with a phone or laptop can secure the network indirectly.

How It Could Work​

  • Random committee selection: Validators are sampled each round. Fake identities are ineffective.
  • Proof of unicity: Validator identity tied to a unique human or device using VDFs, hardware attestation, social proofs, or zkPassport-style zero-knowledge proofs.
  • Data availability sampling: Validators check small, random slices of the blockchain. Full verification remains with full nodes.
  • Layered participation: Light nodes vote and sign for integrity; heavy tasks stay with full nodes.

Why It Matters​

  • Security: Sybil resistance comes from uniqueness and randomness, not money or energy.
  • Low bandwidth: Light validators handle minimal data; replication handled by data nodes.
  • Inclusivity: Anyone can join consensus and contribute to network safety.
  • Churn tolerance: Randomized selection and fraud proofs allow nodes to join/leave safely.

Challenges​

  • Proofs of uniqueness without breaking privacy. Projects like zkPassport on Rarimo show that zero-knowledge proofs can verify uniqueness without revealing personal identity, potentially solving this.
  • Malicious data nodes vs. lightweight bandwidth limits: Light validators only fetch small slices of blockchain data to save bandwidth. Malicious nodes could serve incorrect or incomplete data, and validators might miss it. Protocol design must ensure fraud detection is reliable despite limited visibility. This is similar to Polkadot’s fishermen, who audit network behavior without producing blocks and are rewarded for catching misbehavior.
  • Incentives: Light participants need rewards without large deposits.

Takeaway​

Decentralization means rethinking Sybil resistance: separate data storage from validation power, leverage human uniqueness and randomness, and enable lightweight participation.

The vision: securing a blockchain should be as easy as running a simple app on your phone.

Last year, while scaling an API service, I found myself reaching for Redis and EC2 auto-scaling groups far too early. It seemed like the “right” thing to do—after all, it was what I’d seen in tutorials, open-source projects, and most blogs. As a junior developer, I thought that using “production-grade” solutions like these was the most logical path.

At the time, it felt like progress. I was learning AWS, configuring auto-scaling groups, and managing Redis instances. But what I didn’t realize was that all of this came with significant overhead—both in terms of time and complexity.

When designing software interfaces—especially APIs—it's tempting to favor flexibility and abstraction. But there are domains where performance, predictability, and simplicity demand a different mindset.

This is what design is about: the Tradeoffs.

Let's take Ethereum Virtual Machine (EVM) as an example: