Part 1 — Node1, node2, node3: towards decentralized web3 access
Each blockchain node is a pathway into web3, a vibrant digital commons. It is increasingly vital that no single entity can gain and consolidate control over these paths.
Over time, web3 has adjusted to the usability and scalability requirements needed to power a new, global internet. As it evolved, so too has its node infrastructure. Across all ecosystems, this evolution followed a recurrent pattern, swapping decentralized ideology for centralized performance and scalability; the self-sovereignty of running a node is very often traded for the more practical service of SaaS node providers. This trend stems from the absence of a few important mechanisms: (1) native distribution allowing for a decentralized, distributed network of node runners to provide RPC service to applications, (2) a protocol which aligns economic incentives between network participants, to ensure no provider can accrue centralized control over the network.
This article explores the trajectory of blockchain data access and sets the stage for the third and final act: node3.
So, you want to access blockchain data?
Remote Procedure Call (RPC) is a request-response communication protocol, allowing clients to execute procedures on a remote server. The client sends a relay request and the server sends back a response. An RPC node is a blockchain node that exposed its endpoints to accept RPC calls.
In web3, RPC is the standard protocol that applications use to access blockchain data. Every time a user opens their wallet, sends a transaction or trades on a DEX, they make a call to an RPC node to query blockchain State or submit transactions for propagation in the peer-to-peer network. We have previously explored how RPC works on a low-level, using examples of queries from the Cosmos and Osmosis ecosystems.
You can think of a node as an individual’s personal gateway to participating in web3 — the atomic unit of the decentralized web. Blockchains were built with the idea that all users would trustlessly access and verify the State by running and querying their own nodes. Given the lack of practicality at scale, this service has since been abstracted away and applications today primarily use nodes run by centralized entities.
As this new internet hopes to stay decentralized (censorship-resistant, permissionless, user-owned) while improving performance at scale (think danksharding, verkle trees, Zk-rollups), so must node infrastructure.
Just like the evolution from web1 to web3, node infrastructure must move from node1 to node3.
Convergence towards centralization
Blockchain data access follows a similar evolution to that of the web.
Web1 and Node1: The Internet was built with the idea of peer-to-peer communication via protocols like HTTP and SMTP.
Example: In the web1 era, it was common for internet users to run their own private mail servers. Similarly, node1 is the phase of web3 characterised by self-hosted nodes, which allow sovereign and trustless access to the “decentralized web”.
Web2 and Node2: Centralized offerings generally provide greater usability and scalability. They run centralized servers and are trusted with user data, maintaining service access and upholding service quality.
Example: In the web2 era, users no longer run their own mail servers and have deferred to centralized but more practical offerings like Gmail or Outlook. Node2 is the movement towards centralized node providers, like Alchemy or Infura, which offer better performance at scale.
Web3 and Node3: A new decentralized internet, which introduces digital scarcity and ownership but is built on the premise that each individual runs their own node.
Example: The Ethereum protocol can be owned by its users in the form of ether. But if node3 combines the best of node1 and node 2 to create decentralization and performance, at scale — what does it look like?
Node1 — Run your own node
Run your own node
✅ Censorship-resistant, performant
❌ Not scalable
Public blockchains are built with the idea that users will run nodes and take part in a permissionless, decentralized, and distributed network. Participants run a client that syncs with their peers to arrive at consensus over a shared ledger.
Running your own node is the first iteration of web3 — it gives you trustless, verifiable, and uncensored access to blockchain data. Running a local node also considerably reduces latency and is often preferred by developers for participating in activities such as large NFT mints.
One measure of a blockchain’s decentralization looks at the number of nodes storing a copy of the latest state. Running your own node contributes to this vision.
However, node running is resource-intensive, requiring computing power, lots of storage, and hands-on maintenance. For example, a full node on the Cosmos Hub requires over 1.4TB of always-online data storage.
This makes running nodes a poor scalability solution for access to blockchain data — and as Moxie put it “If there’s one thing […] we’ve learned about the world, it’s that people do not want to run their own servers.”
Node2 — Centralized providers
Public RPC endpoints
✅ Easy to use — plug and play
❌ Not scalable, not private, censorable, unreliable service
To make it easier for developers to interact with a blockchain, blockchains themselves began offering their own public infrastructure. These free, altruistically-run endpoints allow developers to bootstrap applications, without worrying about spinning up their own nodes.
However, public RPC endpoints suffer from a “Tragedy of the Commons”, a problem shared by all common goods. Due to the misalignment of incentives between individuals and the rest of the network, users are encouraged to maximise their own economic gain by selfishly exploiting the free resource, leading to depletion.
Public endpoints are rate-limited to mitigate this effect, which reduces their utility for production-grade applications in need of scale.
NaaS Providers
✅ Performant, scalable
❌ Entirely trust-based, not private, censorable, unverifiable data
As blockchain adoption and the web3 developer community grew, professional Node-as-a-Service businesses rose to satisfy the increasing demand unfulfilled by throttled public endpoints. Centralized NaaS provides a scalable solution and in many of the major ecosystems, they are the most common way for builders to interact with the blockchain.
While these businesses helped lower the barrier of entry for web3 developers, their relationship with users is trust-based — creating a single point of failure, in addition to censorship surface.
Centralized RPC providers are the greatest contradiction in web3 today, and recent events, like the censorship of Tornado Cash following the OFAC sanctions, have shown them to be a significant weakness in the decentralized stack.
Multiple Centralized Providers
✅ Performant at scale, high uptime, high data integrity
❌ Costly, resource-intensive
Aiming to reduce reliance on any one provider, the largest projects are now choosing to build and manage architecture using n centralized node providers simultaneously or as fallback options. This is a manual attempt to ensure uptime and data integrity, with developer teams load-balancing traffic and cross-referencing relay responses from different providers. Data integrity and uptime increase with the number of providers leveraged.
This is still far from ideal. Active-active and active-passive architectures are resource-intensive and require a hands-on DevOps team to maintain.
Node3
✅ Decentralized, performant, scalable
Node3 is the final act of blockchain data access, combining the best of node1 and node2. It achieves this by creating a trustless ecosystem of accountable, incentive-aligned blockchain data transmission, with no single point of failure.
We’ll explore this in greater detail in part 2 of this series.
Conclusions:
Node infrastructure follows a predictable pattern that fails to deliver long-term sustainability and web3 native experience for users.
Node1 — The first evolution of node infrastructure embodied the early ethos of the crypto community: trustlessness, self-sovereignty, privacy and verifiability.
Node2 — With increased adoption, “casual” users and applications opted to sacrifice decentralization for convenience and scalability, making way for node2 .Largely dependent on more convenient and scalable centralized infrastructure, web3 today relies on web2 infrastructure.
Node3 — Decentralized. Performant. Scalable.
About Lava
Lava is a scalable protocol which allows developers to access RPC data, across any blockchain. Developers fetch data directly from independent node runners, who are held financially accountable for fast, reliable and accurate service. Through Lava, developers can add web3 magic to their applications, without a middleman.
Accountability, not trust 🌋
