Public RPC node incentives

Development
1

There is clearly a demand for public nodes and not enough supply. Those service providers bear the costs of bandwidth, compute, and resource management.

At least, the current set of operators capable of supplying the service aren’t jumping at the opportunity to be altruistic.

In my situation, it would cost me an additional ~$25/month to host a public node, but I’m not receiving any sort of compensation.

Today, I propose an incentive model that introduces a new dynamic in our current delegation order. Those who embrace this incentive will likely rise to the top 30 pillars while the others could lose weight, especially as we onboard new aliens in the ecosystem.

I’ve PoC’d* a websocket proxy in Golang that can intercept Zenon client RPC requests and selectively return data based on any criteria. Service providers can choose which RPC calls they want to allow or deny.

Examples of aforementioned criteria:

  • Return data only for addresses that have delegated X amount to a specific pillar for Y days
  • Return data based on an arbitrary allow-list
    • only for your small Discord community
    • only paying subscribers
    • only orchestrators or other node operators can use it
  • Drop data based on request type or source address

We can productize this solution to simplify the criteria selection process for less technical pillars.
They can reduce the rewards they share in order to offset the cost for this service.

For example, if a non-delegator makes a request to query their account balance in Syrius, they will see a spinning wheel. Only delegators would have unrestricted access to all RPC calls.
Pillars can get creative with their offerings.
Non-pillars could potentially adopt this by finding other ways to receive compensation for their service.

Eventually, we could have a page like this one, displaying node capabilities, current status, etc.

* the PoC is rough but could be worth pursuing if the community supports the idea.

inb4 Trust. Don’t Verify.

Until we have a process to validate which nodes are acting honestly, the community will have to trust the nodes they connect to. Given pillars are incentivized to maintain a good relationship with their delegators, they will likely provide truthful data.

We can also work towards the goal of node validation. There are some objective sources of truth that we can leverage, minimizing the amount of trust required to use them. Eventually, we’ll solve this problem too.

Some scenarios

  • Service providers bear all the costs
    • Not scalable – little participation to date
    • Not sustainable for anyone that isn’t generating income for this service
  • Public nodes are subsidized by AZ
    • Not scalable to many service providers
    • May not be sustainable or a good use of funds
  • Freemium model
    • A subset of functionality is free or rate-limited
    • Criteria is defined for “paying” subscribers
      • These could be delegators
    • Premium access is less/not limited
  • Public nodes as a premium service
    • Privately-funded, dedicated infrastructure for subscribers
    • Scalable and sustainable
5 Likes
2

So if I run a public node I finally can get weight ? Good

1 Like
3

!wen PoC beta testing? Great idea BTW @sol

4

Great idea

1 Like
5

@sol can you clarify the title to reflect that this is for RPC
as public protocol nodes fall under sentinels

6

Brilliant idea Sol! Public facing nodes are a vital component for scaling the user base in the future.

One thing that I would address is onboarding new Syrius desktop users. Most of them will be non-technical people that don’t even know what a node is and will go with the default option in Syrius after creating their wallet.

This is not good, as they won’t be able to make any transactions until the embedded node is fully synced. I’ve already highlighted the problem here.

How can we address this issue?

2 Likes
7

I understand that the requirements to run a Nostr relay are significantly less than a public NoM node. However, the point still stands that running a nostr relay is not free, yet there are a great number of people running them and coming up with ways to monetize them. Isn’t what you are describing basically the same thing?

It’s easier to see after your great explanation that pillars are the most trustworthy public node operators, and the free market is already showing promise of going in that direction (i.e deeznnutz offering public infra since day one).

I think your PoC is great and will significantly increase the number of pillars that choose to incentivize delegating to them or coming up with their own ideas for value add by offering reliable public nodes.

2 Likes
8

I would prefer to implement a dynamic solution in Syrius.

Option A

  • We hard-code specific nodes in Syrius source code
  • List is difficult to maintain, slow reaction when a node is no longer available

Option B

  • Trusted entities manage their own list of valid nodes and permit Syrius to download that list dynamically
  • We would have to hard-code these trusted entity endpoints into Syrius but hopefully this won’t need to change frequently

Examples

My main concerns are flexibility and availability.
Maybe Syrius can do a ping check before establishing a connection to verify availability.
We already have a way to inform users when the connected node’s chainId is not mainnet (1).

Other concerns: privacy, data integrity, performance, operational honesty. These can be evaluated by the groups that curate dynamic lists.

I’m open to other suggestions. I haven’t done extensive research on this topic.

1 Like
9

Option C

  • Implement a Nostr client into Syrius
  • Public nodes will host relays and will advertise their availability
10

I appreciate the suggestion. I’m trying to assess how it’s different/better than Option B, though there is the argument of redundancy.

Wouldn’t Syrius still need to connect to a centralized relay that keeps track of all available nodes?
This reminds me of the IBD initialization problem.

11

Idk, but we need a solution for new users that are installing Syrius.

12

Are you opposed to Option B for the initial implementation?
Option C is more complex and I’m not sure if it’s better in any way.

Shouldn’t take much time to develop this solution, but I’d like to give everyone time to suggest alternatives before committing to this.

1 Like
13

Not at all.

14

Option B looks good. LMK the format of the json and I will test it out with zenon.info/nodes.json

15

I wouldn’t hardcode zenon.info in Syrius.

16

Which trusted entities would you add to Syrius?

0x is a respected member of the community. I don’t see a problem here…

I’m hoping we have multiple data providers and users can choose who they trust.

Perhaps we can poll the community to see who wants to be a data provider and have another poll to see which ones are most trusted to provide curated data?

I’m almost willing to give all devs a pass as long as they want to participate.

1 Like
17

how do we determine the trusted entities to provide /nodes.json?

deeZNNutz == 0x == zenon.info

Is one URL better / worse than the other?

18

Sorry, didn’t want to sound negative at all.

In my opinion ipfs is one of the best options if we go with Option B.

We also have Option D: hardcode the seed list from go-zenon, parse it and discover nodes that satisfy the following requirements:

  • Have wss configured
  • Respond in a certain amount of time
1 Like
19

I considered Option D but didn’t want to use nodes that aren’t explicitly consenting to this procedure.
We could say there’s already consent since they configured a public service but I’m not sure if we should be promoting them automatically.

Also, this option doesn’t support testnets.

afaik there are only three public nodes that use wss at the moment. I’m hoping this increases soon.

20

what if we setup some repos on github

/zenon-network/nodes/nodes.json
/hypercore-one/nodes/nodes.json
/hypercore-team/nodes/nodes.json

Community members can submit PRs to add their nodes to the list. Devs will need to diligence the requests.