Feature: Support permissionless node inclusion for access nodes

[pgebheim]

Issue To Be Solved

Enable access nodes to be staked without being explicitly added to the node allow list, and provide a cap to the maximum number of nodes which can be staked.

(Optional): Suggest A Solution

• Modify removeUnapprovedNodes to ignore the allow list IFF the node type is 5 (access node).
• Modify staking table to track maximum number of nodes per type
• Modify staking actions to fail if adding the node would increase the total number of nodes of that type above its maximum count.

Context

The current implementation of FlowIDStakingTable has an allow list for all nodes which can be included in the network. The short term goal is to provide support for permissionless access nodes, such that when the node software can support permissionless access nodes, the staking system can immediately disable the allow-list for access nodes, allowing anyone to add a node.

[bluesign]

Can't wait to add my node :)

What is the point of staking AN btw?

I mean:

• It is not slashed
• It is not adding advantage to the security of the network ( even opposite )

I mean other than staking requirement, it looks very nice improvement.

But please don't put them into public AN pool.

[pgebheim]

• Access Nodes can provide security to the network. Currently its not done but in the long term I think there's an argument for access nodes being slashed for submitting "bad" transactions to collection clusters (e.g. ones that can't cover their cost).
• For the short term, providing a minimum stake would be a bare bones spam prevention, meaning that someone needs to care enough to operate a node that they need to put up 500 flow without getting rewards.

Edit: Fixed error bluesign pointed out below ;-)

[bluesign]

I mean if you want to justify you can find some work for them too.

I think there's an argument for access nodes being slashed for submitting "bad" transactions to consensus nodes. This is wrong, it is the responsibility of Collection Node.

For the short term, providing a minimum stake would be a bare bones spam prevention, meaning that someone needs to care enough to operate a node that they need to put up 500 flow without getting rewards.

Spam protection also should be responsibility of Collection Node to be honest

We are just inventing something new here ( to act like we are opening up something ), technically access node is not even part of the network.

[pgebheim]

I think there's an argument for access nodes being slashed for submitting "bad" transactions to consensus nodes. This is wrong, it is the responsibility of Collection Node.

For the short term, providing a minimum stake would be a bare bones spam prevention, meaning that someone needs to care enough to operate a node that they need to put up 500 flow without getting rewards.

Fixed. I meant to say collection clusters there. The issue here is that collection clusters don't necessarily have all the information that is needed to make a determination of if a txn is good. In fact they almost always do not have the necessary information, namely the execution state. There do exist scenarios where an access node could useless bourdon on the collection clusters where some sort of back pressure and potential slashing may be valuable.

[pgebheim]

technically access node is not even part of the network.

This is incorrect. There are access nodes inside the network, and observer nodes outside of the network.

[bluesign]

This is incorrect. There are access nodes inside the network, and observer nodes outside of the network.

This is incorrect, but it is very hard to discuss this. Access Node is technically user-agent. As Browser is not part of my server stack, it is not technically part of the network. It is consumer of the network.

I think it is not even mentioned in the white papers.

[pgebheim]

Been thinking through this code in the staking table. I think its feasible to add the randomized selection logic in a simple way by modifying “removeUnapprovedNodes” as follows:

• First loop through all the nodes and remove nodes which don’t have enough stake, are not in the allow list and are not (access, consensus).
• During this loop, count how many nodes per node type have a weight > 0; make a list of nodes which are pending assignment (weight == 0 && have enough stake [since those would have been disgarded above]).
• If currentNodeCount[nodeType] + pendingNodes[nodeType].length < maxNodeCount[nodeType]
  • Enable all nodes in pendingNodes[nodeType]
• Else if pendingNodes[nodeType].length - maxNodeCount[nodeType] > 0
  • Randomly select (pendingNodes[nodeType].length - maxNodeCount[nodeType]) nodes, and set their weight = 100
• Else
  • Disable all nodes in pendingNodes[nodeType]

This doesn’t have the logic for adding N nodes per epoch, just filling the max number that is configured.

[bluesign]

Btw we never discussed but why random selection ?

Why not you put some FLOW ( preferably not so small not so big amount ) for to keep your position in the queue ( without any rewards ). First come first served. You stay in the queue. You can leave queue by taking your FLOW back. ( but later you can join to the end )

You can see how many people ahead, when spot opens, who waited longest gets the first spot. Random selection is open to manipulation. I think better to give access to normal people than to give rich people.

[joshuahannan]

Closing this because we're merging the feature branch