Delegating stake to a fraudulent pool


#1

Hi,

What would happen in a hypothetical scenario where I delegated my ADA to a pool that in turn deliberately or inadvertently verifies a fraudulent transaction?

Thanks!


#2

Hello! That’s an interesting question!

Simple answer

Most probably your stake will just remain with a bad pool who will perform some mischiefs. Afaik, there’s a technical possibility to implement a “pool ban” when a poll shows a provably adversarial behaviour. In this case your stake may either remain locked until you manually withdraw it, or it may (technically) be automatically returned to you. But for now there’re no details about any of this.

Remember, that you can withdraw your stake at any time without any approval from the pool.

Long answer

First of all - what do you mean by “fraudulent transaction”? :slight_smile:

The whole blockchain cryptography is quite strict on the question of what transactions can and cannot do. Basically - you cannot produce a transaction and make it look like it’s from some particular other person, unless you own their secret keys. That ensures that even if someone controls 51% of network - he cannot just spend coins from people’s wallets.

Basically, an adversarial node in Cardano (Ouroboros) has quite a limited choice of adversarial things to do. His main options are:

  1. Ignore certain transactions
  2. Ignore blocks with transactions
  3. Ignore slots
  4. Try to create an alternative chain

Ignore transactions (censorship)

If a node ignores some transactions - there’s not much everyone else can do about it, or at least I don’t know it at the moment. Node can always claim that it didn’t receive a certain transaction because of network problems. Additionally game-theory suggests that for a node that’s honest in all the other aspects - there’s no much point to censor transactions, unless of course off-protocol incentives are present (bribery, governmental intervention, etc.), but that’s why it is important to have many small unrelated separate nodes around the globe. In a healthy system one node may ignore as many transaction as he likes - it will just delay them a bit. Next nodes will gladly include those transaction in the chain and collect the fees.

If a node produces a block with completely wrong “fraudulent” transactions - they will be just ignored by other nodes, since they will contradict the protocol. The protocol itself gives strict rules about what a transaction can and cannot do, and who pays for it, and who executes it. Any deviation from these rules will make a node to be ignored - next slot-leader will just not accept the block and continue the chain without it. Maybe additionally marking the bad node as “provably compromised”.

Ignore blocks with certain transactions (censorship)

An adversarial block may ignore the block that was just before him if he don’t likes it, and create new block on top of previous one. And he also may explain it by network problems (didn’t receive the block). This will cause a little “forking” and the next slot will have to chose between two possible chains, and if he choses the adversarial chain - the transactions in ignored block are rolled back. But next slot-leaders will just include them again and put them on the chain. In 99.9% of cases when something like this happens if will converge back to a single chain and be forgotten in the next two slots successfully.

And he cannot try to ignore more blocks than one from the end (more complex cases described later). If he wants to ignore the seconds from the end block - it means that he have to also ignore the one after it, since the nature of blockchain itself. And if he tries (in simple case) to ignore more than one blocks then his chain will be shorter then the original one, and the next slot will just chose the longest.

Ignoring slots

Kinda the same as above, but just more pointless. A node can just ignore its slot and leave the final chain with a missing block. This is unpleasant (for the next reason) but not critical until the number of empty slots is small.

Try create alternative chains

This is a more complex case that includes both previous ones. An adversarial node may create a block in his slot, but withhold, or partially withhold it from the rest of the network, so he kinda carries the alternative chain in the background, and once he gets a chance - he reveals that chain to the rest of the network and it becomes the main chain. But in order for it to happen - that alternative chain should be longer than the main one.

Basically the whole thing of proving Ouroboros safe was exactly about this question - how successfully can an adversarial node create a fork that may possibly replace the main chain. And proofs are shown in many many videos and presentations about the protocol. In simple words - an adversary would have to control >40% of all slots in order to be able to have a slightest chance of producing an alternative chain.

You can read more about it here in this blog post https://iohk.io/blog/on-the-ouroboros-design-how-rigour-and-engineering-are-essential-for-critical-infrastructure/

And also listen about it in this video: https://www.youtube.com/watch?v=GKqtWpdAdRA

And in this discussion: Does anybody understand Ouroboros?


#3

Thank you so much for such detailed explanation. This is one of the reasons I trust and respect Cardano team.


#4

Good response, this is one of the problems that need to be solve with pooling to maintain decentralization. The system will have to be designed such as there’s no God pool(s) that could potentially perform 51% attack individually or collaboratively with other pool.

Additionally, a misbehaving pool that tries to do harm will create an opportunity cost for those delegating member that may or may not transition quickly to a good pool thus it become detrimental to the member. I would be interested to see how IOHK team solves this issue.