search

spacemeshos / research

Spacemesh research tasks tracking issues
2 stars 0 forks source link

Make path to genesis clearer #43

Closed lrettig closed 1 year ago

lrettig commented 4 years ago

We discussed this on the R&D call yesterday. On the testnet, we've seen a whale join and broadcast bad block data, i.e., data from a previous testnet instance/different network ID, leading to a fork.

One issue here is that, when a miner receives a block they haven't seen before, there's no way to immediately know that it descends from a bad genesis - without requesting and downloading all of the intermediate mesh data and walking back to that bad genesis. That makes it sound like a DoS vector as well.

What can we do to improve this?

tal-m commented 4 years ago

I think the current easiest suggestion for a short-term patch was to have every block include a "genesis hash" field, and check that this field matches when testing syntactic validity.

It might be enough to add this field only for blocks in the genesis epoch (this would solve the problems we had so far, but we need to make sure it would solve similar types of problems that we could have).

lrettig commented 4 years ago

I think the current easiest suggestion for a short-term patch was to have every block include a "genesis hash" field, and check that this field matches when testing syntactic validity.

What if the attack then becomes, rather than flooding the network with blocks with an invalid genesis, instead flood the network with blocks that are contextually invalid but still require a node to download and process many intermediate blocks to determine that? (E.g., imagine a fork not "from genesis" but rather "from layer one")

tal-m commented 4 years ago

(1) This suggestion is a hack that solves our immediate problems. The actual solution is to implement a robust genesis flow. (2) The attack you describe should be blocked at the gossip layer. Basically, a node will not consider a block syntactically valid unless it has a path to the "real" genesis (the same one as the node). Nodes might have to wait to get intermediate blocks until they can determine syntactic validity, but they shouldn't gossip them until they know. In this case, an attacker can cause a single node to use a lot of memory, but not the whole network (and of course, this can be further mitigated by having nodes ignore gossip neighbors who send them blocks in the "wrong" order)

lrettig commented 1 year ago

this was resolved with genesisID, see https://github.com/spacemeshos/SMIPS/issues/75