FLIP-1057: Automated Slot Assignment

I was more concerned about the case where someone is specifically trolling or trying to load up all slots with their own nodes.

If that actor doesn’t then actually run the nodes there’s 0 chance that new good nodes are added.

So: the randomization case does have the factor that wealthier individuals can add more nodes there is some chance that others are selected.

I’m not actually sure which is worse. Are there other options for the short term?

Edit: NOTE Auctions also have the effect that richer individuals or consortiums can more easily get node slots because they can absorb the opportunity cost of the initial stake more easily. There are some approaches to getting around this such as NEAR’s approach where all stakers are divided into tranches and the winners of the auction are selected such that certain % of the total stake comes from stakers bidding in the range of those tranches.

I think approaches like that do need a little work from the auction theory perspective to tell us about the properties we will care about here.

This is where slashing can take on a more corrective role. If there is the capability to slash an amount for unresponsiveness, and additionally kick the node from the active set (as both a punishment, and a way to protect well-intentioned node operators from further slashing in the case of unexpected downtime) this can help incentivize proper behavior. In some networks, there is even an “unjailing” fee that must be paid by a node to become eligible again. It would provide a disincentive from taking up slots as spam or malicious behavior while allowing a more open selection process.

Great point.

So one item we would love to tackle (soon) is more automated slashing. We currently have a somewhat manual process for slashing based on downtime :(. I had been talking with @flowjosh about implenting a better solution, and so I didn’t even think about improving slashing for this specific issue.

Perhaps we could simply add some more slashing criteria to the already weekly manual process as a stop gap, and that could decrease the attack surface enough to make first come first serve workable in the short term.

I feel like unjailing fees aren’t super workable in the permissionless case because one would instead just Sybil attack instead of paying an extra fee. Of course it could be framed as a partial refund.

Anyway great thoughts I’d love to discuss further.

is there any node that is slashed so far?

On June 14th two nodes had rewards slashed. slashing rewards for two nodes · onflow/service-account@f9d6f64 · GitHub

This isn’t slashing stake but rewards. In the permissionless case of access nodes there would only be a possibility of node slashing is there was enough stake.

The difficulty of course is choosing the cost.

Yeah this is not slashing :slight_smile:

Since all these nodes are permissioned the classic slashing as a disincentive for malicious behavior hasn’t applied (yet).

Since all these nodes are permissioned the classic slashing as a disincentive for malicious behavior hasn’t applied (yet).

That reminded me a summer evening of 2012, which was raining because I took my umbrella while leaving home that evening.

" Since there is no slashing mechanism, all nodes are permissioned now"

Except that’s incorrect.

The node software isn’t fully byzantine fault tolerant. There’s a number of pieces of the implementation which are being worked on to correct that. In an upcoming spork the implementation will be able to work even with byzantine access nodes in the system, and as such we can now explore allowing operators to do so permissionelssly and the slashing implementation necessary.

Which part is incorrect ?

I said ( actually corrected the statement ) as “Since there is no slashing mechanism, all nodes are permissioned now”

“The node software isn’t fully byzantine fault tolerant.”

If it was fully byzantine fault tolerant, there would be “slashing” of bad actors.

So reason we are not slashing is not we have trusted network.
We have to have trusted network cause we cannot slash. ( we are not BFT )

Slashing is a necessary but not sufficient condition for BFT in the flow network.

Is it a necessity to make sure at least 66.7% of FlowTokes are staked for the consensus algo working properly in Flow?

No. The BFT threshold if 2/3 of nodes, not 2/3 of total supply.

The inequality that needs to hold is loosely can an attacker extract more value out of an attack than the total cost of the attack. So in the brute for case, how many token would I need to buy to stake enough nodes of each node type such that I control the part of the network I need to in order to extract value for a certain amount of time.

How is the equation there? How much of supply I need to run an attack with expected 50% chance of success?

I have an update to the original FLIP - https://github.com/onflow/flips/pull/61

Marking this FLIP as Accepted https://github.com/onflow/flips/pull/62