“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
3 Likes
Hi fabrice thank you for the answer, this is super interesting and I’d like to find out more about this mechanism. Do you have any more infos about how this works to prevent a DoS attack? First of all, what is the attack scenario and second, how is such an attack mitigated exactly with this mechanism? How does the BroadcastConnectionsLimit configuration flag play into this?
Thank you!
The idea is to block an attack where new “fake” nodes are created to saturate the relays.
Then it would slow down the consensus because real participation may not receive quickly enough the messages.
The mechanism above ensures that high-stake participation nodes will receive in priority messages in the case of such an attack. So consensus will still be achieved.
Ok so under this attack scenario, nodes with high stake would be prioritized by relays during broadcast to ensure they receive important messages first. This makes sense.
I am trying to get the full picture of how the mitigation works during a sustained attack. As long as relays don’t have an upper limit to the number of peers that can connect to them, I believe relays could still get slowed down significantly. Given the following scenario:
- A large number of such “fake” nodes connect to a relay.
- Shortly after, the relay receives consensus message 1 from a neighboring relay and needs to relay it to all peers.
- It first relays to prioritized peers (online nodes), as described by you.
- But then still relays to all other peers, including the malicious ones.
- If the number of malicious peers is high enough, the relay will get slowed down by having to send to many messages.
- It would get slowed down to the point where upon receiving consensus message 2, the relay is still busy sending consensus message 1 to non-prioritized peers.
- Now relaying of message 2 gets slowed down even for prioritized peers because relaying of message 1 that is going on.
- The slow down effect could start compounding.
You earlier linked to the BroadcastConnectionsLimit configuration flag. I assume that this flag should be used in an attack scenario to eliminate the problems described in points 5-8 in the list above (this limit is infinite by default though). Is this correct?
1 Like
That’s my understanding too.
If you observe your relay is under too much pressure, you would set BroadcastConnectionsLimit that would only broadcast to the highest-stake peers.
1 Like
hiiii @fabrice, im sorry i have something to say
so thats why there is only 1 arbitrage bot on this chain?
this “solution” to avoid an attack also created a monster bot that is already consuming all arbitrage opportunities, im sure you know who i mean
as of today everybody on the algorand chain is forced to read transactions after they have been prioritized to who accumulated more
are you sure this is the best solution for an attack? to me looks like allowing a continuous attack, not of denial of service, but of decentralization
I don’t see how it’s related, you can your bot now if you want
is directly related since having priority over the knowledge of the content of the tx pool obviously give priority as the word itself says
anyway i dont need to explain myself, just go to any block and see what is the arbitrage done; yep theres only 1 account doing it in the whole chain
Lol, I’m the who posed the question so I at least know something. This kicks off if there’s an attack and it’s for consensus msgs. Arbitrage bots are good
note that arbitrage uses the mem pool, and giving priority to some users effectively created a monster bot already
moreover, i should learn to not talk to other people, but this is the only topic talking about priority of peers; anyway, bye
If there’s an attack, there’s no attack yet. Proposers are still randomly and independently selected