Is it true you get priority in terms of receiving and sending txns based on stake in the gossip network

“after some code reading it looks like you get priority based on stake in the gossip/broadcast network. Someone correct me if i’m wrong. It’s also not clear to me why a challenge is needed. the challenge is just a random number that nodes sign and end with their weight. the weight can already be retrieved from peer list” from discord

Where did you see that in the code?

To my knowledge, there is absolutely no such priority.
The only thing that may happen is that if you have a large stake, you may run a custom participation node, which, when it becomes block proposers, prioritize your transactions.
But on average, if you have x% of the online stake, you will only propose blocks every x%.

I am not sure that the “challenge” they are referring to is.

1 Like

I believe the weight there indicates the performance of the relay.
Indeed, a node regularly update the relays to which it is connected to, and drop the least performing ones for better performing ones.

Note that relays anyway do not have stake associated to them.

on further inspection the weight comes from rewards and i’m wondering what rewards are doing since they were phased out

MicroAlgosWithRewards is named as such because it gets the total amount of MicroAlogs an account has, including rewards. On mainnet/testnet rewards are disabled, but reward functionality still exists in the protocol. This means on testnet/mainnet the prioWeight is determined by account balance.

Looking at where this is used

$ grep -rn "\.prioWeight" | grep -v _test.go
./network/wsNetwork.go:851:             go wn.prioWeightRefresh()
./network/wsNetwork.go:1865:                    weight := peer.prioWeight
./network/wsNetwork.go:2326:    wn.prioTracker.setPriority(peer, peer.prioAddress, peer.prioWeight)
./network/netprio.go:98:                peer.prioWeight = weight
./network/netprio.go:107:                       if peer.prioAddress == addr && peer.prioWeight == weight {
./network/netprio.go:112:                       old.prioWeight = 0
./network/netprio.go:127:       peer.prioWeight = weight
./network/peersheap.go:73:      return pi.prioWeight > pj.prioWeight

The only significant usage we can see is go-algorand/peersheap.go at master · algorand/go-algorand · GitHub which is the definition of Less which is used by heap. This means the priority of peers in the heap is based on account balance.

I’m not super familiar with go-algorand source so you might want to wait for additional confirmation before drawing conclusions.

alright, but @fabrice said relays don’t have stake so whose stake/weight does this belong to

The addr comes from the sender of the challenge response: go-algorand/netprio.go at master · algorand/go-algorand · GitHub

What this all means at a functional level, I’m not entirely sure.

After asking core engineers, the mechanism highlighted above is to allow relays to send messages in priority to high-stake participation nodes, in case of DOS attack. This way, we are sure that high-stake participation nodes receive consensus messages and are still able to reach consensus even if a lot of “fake” nodes are connecting to relays and trying to saturate them.
See go-algorand/localTemplate.go at e6172bc8c415e18b4afe3ae87255e498259fdc2c · algorand/go-algorand · GitHub and go-algorand/localTemplate.go at e6172bc8c415e18b4afe3ae87255e498259fdc2c · algorand/go-algorand · GitHub

This mechanism is not for nodes to select relays. Relays do not have stake. The selection of relays from nodes is a completely different mechanism that rely on performance metrics gathered by the node. See go-algorand/wsNetwork.go at 4e4ee2cd71727b10b9190e551b327c1d9c146961 · algorand/go-algorand · GitHub

2 Likes