[FR] - need to implement detection/punishing of multiple blocks produced for a given slot by the same pool

[bergr01]

On both Rust ITN and current Haskell test network a pool operator can launch multiple nodes using the same set of keys. If pool has adequate amount of stake delegated, these nodes will be producing blocks at assigned times, with only one of the produced blocks surviving at most. However, in addition to the undesirable amount of forking such setup results in, this also means that in case of multi-leader slots this pool would have a better chance of claiming the reward for it.

While in the ideal world a node started with the same set of keys as already running node would not be allowed to join the network topology (not sure how feasible that is to implement), at a minimum we should be making sure that chain selection algorithm - if presented with multiple unique block hashes for the same parent slot which have the same associated pool id would ignore all of these blocks (so adversarial behaviour does not have a chance to be rewarded). Stricter punishment, such as forfeiting rewards for the entire epoch could also act as an extra deterrent potentially if that is possible to implement (I'm not sure what sort of on-chain information needs to be created for such purpose)

[vix-io]

Hi bergr01, this is Viktor at IOHK Tech Support. Thank you for submitting this Feature Request. We have added it to our backlog and we`ll allocate it to one of our future development sprints. We appreciate your participation and support for the Cardano project!

[rdlrt]

This will be one of the common attacks from adversaries early in mainnet, hope this does not get dropped to a sprint too far away that it cannot make it to mainnet in time

[mrbrinker]

Hey @vix-io how is the development of this issue is going?

[vix-io]

hi @mrbrinker - being an enhancement, we will be looking at this at a later point so that we can focus on bugs/issues

hi @kevinhammond - any thoughts on this?

[AndrewWestberg]

Given that chain selection is deterministic and not latency-based, I don't think this will result in forks except in the event we have slow block propagation. Likely, the multiple blocks won't make it out to the greater network. They will be pruned at the pool's own relay nodes.

[shawnim]

Is the deterministic chain selection based on something that would be identical between the forkers multiple blocks?If not, the forker would still have an advantage. On Monday, September 21, 2020, 10:02:42 AM PDT, Andrew Westberg <notifications@github.com> wrote: Given that chain selection is deterministic and not latency-based, I don't think this will result in forks except in the event we have slow block propagation. Likely, the multiple blocks won't make it out to the greater network. They will be pruned at the pool's own relay nodes. — You are receiving this because you are subscribed to this thread. Reply to this email directly, view it on GitHub, or unsubscribe.

[AndrewWestberg]

@shawnim Yes, if each core node had a different set of transactions in the mempool, it would generate a different hash. That would give it two chances to get a lower hash instead of just 1. While it's an advantage and probably an edge case, I don't think the forked block would propagate out into the greater network.

[kantp]

Using multiple nodes with the same credential is indeed an attack that we thought about how best to mitigate. It's an open adversarial action, and so in principle, it's amenable to on-chain punishment.

However, a local solution (punishment through an individual honest node) like the one suggested here is not optimal: consider an attack where an operator runs two node copies. For a given slot, each produces a block, let's call them A and B. They propagate though the network, but not together. So some nodes add A to their chain, and some B, and we have a fork. If all nodes would see both A and B before the next honest block gets made, they could all ignore A and B. But what if the next slot leader has already created a block C by that time? C depends on one of those blocks, should it get dropped? That would punish the pool that created C, who is honest. And nodes that have not seen both A and B have no reason to drop either of those blocks, so there is a risk of longer forks.

A better thing to do here is to add a mechanism for posting a proof that a certain pool did perform this attack (this could be derived from the headers of A and B) to the chain, and then collectively ignoring blocks from such a pool in the future. But it's not a trivial change, needing changes to both the consensus and the ledger layer.

In the short term, we have three ways to mitigate this attack:

1. Monitor, and punish off-chain via social pressure. This could be done by the community.
2. Rely on the improved networking stack on the mainnet, and educate SPOs that it's not necessary, and indeed and attack on the system, to run multiple copies of their node.
3. Work on a proper high availability solution (which would help against operators that do the attack in order to boost their apparent performance, but not against deliberate attacks that aim to harm the system).

[rdlrt]

@kantp - would something as per #1883 be a proper solution - as you mention in point 3 - especially in absence of something native provided by node?

(PS: additional stress on having no single point of failure being paramount for HA solution)

[mark-stopka]

The issue has been debated at length here - for Jormungand and here.

[mark-stopka]

Issue has been observed in the wild on Cardano mainnet, see attached report generated using CNCLI block database.

[mark-stopka]

In the short term, we have three ways to mitigate this attack:

1. Monitor, and punish off-chain via social pressure. This could be done by the community.
2. Rely on the improved networking stack on the mainnet, and educate SPOs that it's not necessary, and indeed and attack on the system, to run multiple copies of their node.
3. Work on a proper high availability solution (which would help against operators that do the attack in order to boost their apparent performance, but not against deliberate attacks that aim to harm the system).

We may further improve the networking stack by developing an application level firewall, that we may use to detect and block adversarial behavior in Rust... basically a relay node, that could maintain a shared library with state of the chain, and include dcSpark dApp Rollback Handler mechanics.

We already have the networking crate in Rust, and are applying for Catalyst funding to move the project along:

https://cardano.ideascale.com/a/dtd/CRUST-Cardano-Node-in-Rust/381179-48088

[benapetr]

Do not rely on #1 that will not work. Delegators rarely care about anything else than ROI. This has to be implemented in form of consensus based punishment, similar to not adhering to the pledge. That's the only way to stop this.

[benapetr]

Also just because it's not needed doesn't mean people will not do it. Given that this is causing harm to the network, it could be abused by whoever who wants to damage it. Imagine some high-stake pool gets hacked, the attacker could just take the keys and run many BPs with the same set of keys connected through many different relays to create as many forks and as much mess as possible.

Malicious behaviour shouldn't be tolerated.

[mark-stopka]

Imagine some high-stake pool gets hacked, the attacker could just take the keys and run many BPs with the same set of keys connected through many different relays to create as many forks and as much mess as possible.

We already had few stakepool hacked...

• https://twitter.com/AdagoPool/status/1351781426094632965
• https://forum.cardano.org/t/spos-do-not-repeat-my-mistakes-keep-your-core-node-safe/37766

We also know SPaaS is quite prevelent phenomena, it's a long range attack of an adaptive adversary bound to happen. Addressing this will at least enable us to punish an adversary if he slips up...

[Jimbo4350]

Closing this. If this is still relevant please re-open.