RPC is the most vulnerable layer in Web3

A collective wake-up call seven years into the ascendance of decentralized applications asks an uncomfortable question: Are we building blockchains wrong? The optimistic promise of a secure, globally integrated, and open internet has not only failed to materialize; it’s left us a fragmented ecosystem with growing pains permanently etched on-chain.

The normalization of the JSON Remote Procedure Call (RPC), a key conduit facilitating communication between the application interface (JSON-RPC consumer) and independent JSON-RPC providers in blockchain networks, highlights this. Acting as a bridge between application users and Web3 experiences, JSON-RPC APIs enable decentralized applications to retrieve and commit data to blockchains in real time, serving as a key foundational component of their operations.

Instead of a secure foundation for Web3’s infrastructure, however, JSON-RPC remains a critically vulnerable layer. Its susceptibility has made Web3 infrastructure a large target for security threats capable of compromising the integrity of various blockchain ecosystems at the fundamental but often overlooked execution layer.

Ethereum’s Cascading Tech Debt

The prevalent design patterns fostered by the Ethereum Execution API and others present various attack vectors in the event of compromised operational trust between an RPC consumer and an independent RPC provider. Current solutions in development, such as light clients, provide long-term cryptographic answers. Still, they aren’t applicable in the short term, leaving applications and users in a perpetual state of risk.

When provider trust is compromised, the consequences are dire: Indirect theft of funds through maliciously created MEV arbitrage opportunities, direct theft of funds for a significant majority of existing DeFi applications, and exposure to XSS and malware distribution for applications resolving media and code either stored or linked to on-chain are all possible. These scenarios are a threat that lurks behind all pillars of the web3 ecosystem: DeFi, Decentralized Namespaces, NFTs, and Reusable Account Abstraction Entry points. In high-transaction volume environments, the resultant losses could be monumental.

Building in a Non-Idempotent World

At the root of these risks is the non-idempotent nature of Ethereum’s JSON-RPC API. In computing, an operation is idempotent if its repeated execution delivers consistent results. Contrarily, non-idempotent processes could produce variable outcomes with each execution, thus leading to consistency challenges and security vulnerabilities.

Underpinning these vulnerabilities is the assumption that the same RPC request will always yield the same RPC response. The reality, however, contradicts this: most ETH RPC calls are not idempotent. This lack of idempotency introduces the inability to identify attack vectors or compromised operational trust in real-time from an end consumer’s logging context, and the absence of redundancy systems for immediate identification and mitigation of these compromises.

Two primary application patterns are exposed to significant risk if provider trust is compromised:

1. Applications relying on an address returned from an on-chain lookup for transaction construction, leading to the risk of theft of funds.
2. Applications relying on a URI returned from an on-chain lookup to resolve some form of media, leading to exposure to XSS or malware distribution depending on the kind of resolved resource.

Although these attack vectors are not direct consequences of implementing the Ethereum RPC execution API, the lack of idempotency makes it impossible to build automated solutions to detect or mitigate compromised trusted providers. It becomes challenging to discern a compromised node in a fleet deployment of RPC nodes, allow a consumer to wait for multiple independent nodes’ responses before trusting the outcome, or enable a consumer to audit a remote server’s historical RPC response.

Consider a simple scenario where you have access to two RPC nodes and want to find out the current owner of item 1 in an ERC721 collection. When querying both nodes for collection.ownerOf(1), in the background web3.js would make an RPC request using the eth_call method to the collection contract at the ‘latest’ block. Theoretically, both nodes should provide the same answer, but what happens if they don’t?

There are two likely explanations: a transfer of the asset happened in the last block, and one node is lagging a block behind the other, or one of the nodes could have been compromised and is behaving maliciously. The absence of idempotency in these ‘latest’ block calls means that you couldn’t historically detect a breach of trust or automate a system to perform this check in real time.

Non-idempotency impedes the ability to instigate on-chain accountability for negligent or bad actors, relegating the task of discerning data correctness to applications. Most blockchain data services shoulder the heavy burden of validating new and old data. Even with idempotent RPC, the node’s actual computation via the RPC method doesn’t allow for trustless transmission of the result. Leaving the responsibility of data verification to consumers is not a sustainable solution and merely offloads existing problems to individual organizations.

Web3 Infrastructure has Failed

At the onset of Web3 development, centralized solutions offered growth to developers with their quick time to market and stable performance. However, centralized systems are burdened with unsustainable costs, and come with the inescapable risk of single points of failure, posing significant security and reliability concerns.

Further compounding the issue, the non-idempotent conditions of blockchains render centralized providers untraceable. In the unfortunate event of an exploit, applications find themselves blindsided, devoid of any recourse to rectify or draw learnings from it, as even tracing log-level information is not possible.

On the other end of the spectrum, as decentralized alternatives have emerged, they’ve brought their own set of challenges. Encouraged by the race to offer cheaper, competitive services, permissionless networks of RPC providers have gained traction. Their seemingly democratizing proposition of crowd-sourcing operations and low entry barriers hid a serious flaw: the trust placed in these anonymous entities.

Trust in how we currently design decentralized systems is a double-edged sword. While they lower barriers to entry, these systems inadvertently expose application developers and might even incentivize nefarious players to disseminate fraudulent or malicious data.

These are not tradeoffs that providers should force applications to make. Secure, dependable, and decentralized infrastructure is crucial for the existence and success of Web3. Without it, applications cannot function, users cannot interact, and the entire ecosystem grinds to a halt.

Transitioning to Trust-Minimized Decentralization

This uncomfortable situation uncovers a complex paradox around the push for decentralization and its security risks. The path forward lies in managing this delicate balance.

As the landscape evolves, ensuring data integrity and shielding against financial exploitation has become paramount. The industry needs to gravitate toward trust-minimized decentralization, which reduces our reliance on intermediaries and emphasizes security and verifiability.

Addressing RPC vulnerabilities is the first step toward this new paradigm. It involves a new secure, decentralized, and sustainable middleware capable of providing safe and scalable consumer access to blockchain data.

Stateless: A New Standard

Stateless presents a nuanced approach to redefining the trust assumptions of blockchain data access.

Our API middleware solution offers an evolution in the Web3 developer experience, aiming for a more stable and user-friendly decentralized ecosystem. Here’s how Stateless is forging the path:

• Data Integrity: Stateless provides performant blockchain clients that focus on ensuring data remains accurate, untampered, and auditable.
• Developer Autonomy: Stateless offers tools that allow developers to refine their data consumption experience, emphasizing choice and adaptability regarding data providers and risk tolerance.
• User-Centric Integration: Our endpoints integrate seamlessly with existing application interfaces, streamlining the process for developers.
• Decentralized Trust: Through a federated node network, Stateless embraces trust-minimized decentralization, fortifying the protocol’s data consistency and reliability.

Ready to build on these foundations, Stateless recognizes the challenges that the current decentralized landscape presents and is committed to contributing to the foundations of a web that’s not only efficient and accessible but also inherently safe and equitable for all.

Learn more about our mission and join the waitlist to test our API middleware today.