PUP-2: Whitelist Ethereum Archival Nodes in the SupportedBlockchains Parameter

Proposals Parameters
1

Attributes

  • Author(s): @o_rourke
  • Parameter: SupportedBlockchains
  • New Value: 0022 (Ethereum Archival)

Summary

I propose to add 0022 general Ethereum Archival support to the list of supported chains for Pocket Network. Currently, the protocol only supports Ethereum full nodes through Network ID 0021.

Abstract

I am proposing to enable Pocket Network to support general Ethereum archival access by whitelisting a new Network ID. Ethereum Archival nodes provide the full state and history of the Ethereum blockchain, allowing for certain types of popular calls such as eth_getLogs to be processed much more quickly. Many Ethereum apps, including most of the DeFi space, rely on Archival data to maintain high-speed user experiences. This is therefore crucial to Pocket’s adoption in the Ethereum ecosystem.

Motivation

Full nodes must compute RPC requests like eth_getLogs in real-time, which in many cases may take minutes. This is infeasible for the needs of current Ethereum applications, DeFi in particular. With Ethereum Archival support, the entire history of events and logs will be in the local database, allowing for quicker responses to these kinds of calls.

Rationale

Economic Rationale for Adding Archival support

We have assessed that there is sufficient demand for Ethereum Archival data to support the costs to Pocket Validator nodes of running Archival nodes.

At the current sale price of $0.08/POKT, and a cost of $500/mo, a single Archival node paired with one Pocket Validator node would need to do about ~25,000 requests a day to break even. If the network is seeded with 5 sovereign Archival nodes and a replicated set of 10 Pocket Validators each, the Network ID would need between 200k daily requests to break even. Please see this model - https://my.causal.app/models/15416

In my conversations with Ethereum applications in the last several months, I have found that there is a strong need for Archival support in the market. Most DeFi applications need this historical state. Middleware protocols like The Graph need Archival access. Many of these applications have significantly more traffic than the breakeven threshold defined above and are seriously considering making the switch to Pocket Network as soon as archival access is supported.

It’s clear that for Pocket Network to compete in the market, Archival support is critical.

Rationale for Network ID 0022

The Ethereum full node Network ID is 0021, so 0022 is the logical next ID for Ethereum.

Dissenting Opinions

In most cases, to whitelist a new Network ID for block rewards there should be some demonstrable usage by Apps (e.g. on a Pocket incentivized testnet) to ensure there is a strong incentive for a sufficient number of nodes to join a new Network ID.

However, Ethereum Archival is a special case in that it shares much of the demand with Ethereum Full Nodes, which we already support. We don’t need to test demand because it is clear that demand is abundant.

Further, we have already confirmed 5 sovereign Archival nodes between Pocket Network Inc and our bootstrap node infrastructure providers, and we expect a minimum of 50 Pocket Validator nodes to join this Network ID.

Analysts

Michael O’Rourke - CEO, Pocket Network Inc.

1 Like
2

We should look into / consider a protocol modification to support a higher cost per relay for this chain (and others in the future). I see a potential issue here with applications that do not need archival access all of the time choosing to hit archive nodes anyway because the price is the same and it’s more convenient to only use just one network.

2 Likes
3

Great point @BenVan - If needed I think this is something that we should look into. Observing how the 0022 supply-side market adjusts according to the demand will be valuable in determining what the right course of action will be.

There are at least a couple of directions in which this can go:

  1. Since the cost for accessing 0022 is exactly the same as 0021 on a per relay basis, will the demand naturally shift to 0022 for a more robust service? I could see 0022 cannibalizing 0021 in this scenario, leading to a larger network of Archival nodes as a result

  2. Will the demand naturally bifurcate itself in such a way where it can support a robust and secure enough archival node network? If not, then I think it makes sense looking into bespoke costs and/or rewards for individual networkID’s

The cost constraints could lead to other types of creative solutions to make it more efficient. For example, the sharing of archival nodes within the community.

It’s hard to say, but this initial Ethereum archival node support will help inform how we move forward in supporting these “heavy” clients in the future.

1 Like
4

This proposal has now been fulfilled by PIP-6.2: Settlers of New Chains.

For this reason, I’ll close this thread now.

If we want to discuss a protocol modification to support per-chain-RelaysToTokensMultipliers, that can be posted as a separate thread.

1 Like
5