In Algorand, every user can participate in the blockchain verification and transaction baking / block production (Pure Proof of Stake). But there are no penalties when a user is malicious - all funds are never at risk.
Why the authors disregard slashing for malicious behavior?
Penalizing a participant could be a double ended sword. What if someone is trying to attack the system by making the system believe that valid votes are malicious ?
Instead of “punishing” malicious votes, Algorand implementation simply ignores them.
Also keep in mind that what seems to you as malicious might not be malicious at all. For example, let’s say that you send a proposal for a block. But since you have a bad internet connection and a super slow computer, it’s getting sent 10 seconds after the moment it would be effective. Do you want to be penalized for your participation ?
2 Likes
What if someone is trying to attack the system by making the system believe that valid votes are malicious
Then it’s a form of an attack (because someone is trying to corrupt the system by making true-negatives). Ideally this activity should be handled (and imho penalized).
For example, […] internet connection and a super slow
Then this group of users are not helping the system. In fact they are disturbing the system and increase the probability of a successful attack. Since they will not produce a block on time they will not get any reword, and as explained above, they create a potential damages. Hence it would be better for the network and themselves (since they will not need to run the node) that they will not participate in consensus.
I think current Ethereum 2.0 proposal is good: if there is a small damage (like unintentional misbehave, individual drop, …) the penalty is very very small – this will at least dis-incentivize validators who are not helping. When the misbehave or an attack grows, the penalty grows exponentially.
I would have to disagree regarding the second paragraph. These users never meant to disturb the system. They only tried to perform their role, and failed due to unexpected lack of resources ( network, cpu or other. it doesn’t matter ). I wouldn’t want to be penalized for trying to help. and I wouldn’t penalize others.
I think that the Algorand design balance these tradeoffs better. The extra processing cost of misplaced vote/transaction is pretty minimal, and an Algorand node would just filter it out so that the processing cost would not propagate to the reminder of the network.
1 Like
I know that these user don’t want to disturb the system. But the problem is that if there are many of them they unintentionally harm it.
Hence the idea to disincentive users who don’t help and almost don’t have any chance to get rewords.
Here is an Ethereum 2.0 design doc which explains there adaptive slashing mechanism. Nice reading:
I agree with Tsachi. I don’t think slashing is necessary and all the slashing logic would increase the complexity of the codebase and the attack surface for no real value added.
There is already a cost in making transactions (fee and electricity cost, even if both are low) so a malicious node whose invalid transactions are ignored already loses money. In the case of a DDOS for example, the cost of the attack would rise quickly as honest nodes would increase their transactions fees (and the malicious ones would need to do the same).
We should keep Algorand implementation as “pure” as possible. If something is not necessary, the code is better off without it.
Holy three years later dude
This man went deep into the rabbit hole this weekend 
1 Like
The problem is that this impacts “normal” users, and there is as time delay for increasing the TX cost.