Jormungandr: "Block theft" seems to be happening

[Aranad]

My node goes through a fair few periods of trouble where it needs to restart and go through the bootstrapping period, and often has to do this a few times in a row.

I know this is fairly normal in the testnet, but looking at the timing of these downtimes it's looking more and more like there's some kind of malicious activity involved because they seem to be consistently occuring shortly before my next scheduled slot.

This may be a possible way of gaming or disrupting the system that might need some thought.

[mmahut]

Can you elaborate on this anecdotal report and perhaps support it with some evidence, please?

[Aranad]

I don't have anything concrete as I don't know how to do sophisticated connection monitoring etc, I'm just logging my downtime and noticing that it seems to be happening just before my slot a lot of the time, so was just raising this as something to think about.

The general idea is that if I know all the slots my node is lined up as the first backup for (i.e. that I would be selected if the elected leader failed to produce), then I would increase my chances of getting more blocks if I ddos'd all the nodes that were elected for those slots.

[mmahut]

The general idea is that if I know all the slots my node is lined up as the first backup for ...

Only you know your slot schedule, no else else. Also, there is no such thing as first/backup node for a slot.

Can you provide the timestamps for the downtime, type of downtime and the your slots, please? However, this seems highly unlikely.

[Aranad]

This is my schedule for epoch 27, 4386, 18500 and 18565 were successful. 8080 I created but was not accepted (this is also something that's been happening with many of my blocks, many are created by someone else). All the others (apart from the last one which hasn't happened yet) have failed due to the node going down shortly before and then recovering shortly after.

scheduled_at_date: "27.4386"
scheduled_at_date: "27.8080"
scheduled_at_date: "27.15571"
scheduled_at_date: "27.18500"
scheduled_at_date: "27.19565"
scheduled_at_date: "27.29712"
scheduled_at_date: "27.33988"
scheduled_at_date: "27.34182"
scheduled_at_date: "27.35573"
scheduled_at_date: "27.42107"

That's great to know that nobody else can know your schedule.... but in that case how can it be deterministically known at the start of each epoch? And also if there is no "backup node" to make the block in the case that the leader can't produce it, then who is creating all the blocks that were scheduled for me that I created but that someone else created?

[Aranad]

Ah I see I think I get it, is it that if the elected leader can't produce a block for the slot, then that block has to wait for the leader of another slot to create it?

I can't find any of the exact slots where I created a block that was not accepted in the explorer, many I see a block in a different slot with the same parent and subsequent block as I have logged, but for some reason even though I was at the tip my block wasn't accepted.

[mmahut]

but in that case how can it be deterministically known at the start of each epoch?

It is not 100% known, therefore multiple leaders for one slot are possible and accepted in the network. Which ever node communicates its block to the next elected leader wins the slot.

And also if there is no "backup node" to make the block in the case that the leader can't produce it, then who is creating all the blocks that were scheduled for me that I created but that someone else created?

No one, if the leader miss the block, we have an empty slot and another slot is presented for a block to the next leader ec.

[Aranad]

No one, if the leader miss the block, we have an empty slot and another slot is presented for a block to the next leader ec.

I take it you mean here that if none of the multiple leaders miss the block?

How is it that nobody else can know my schedule and it also be deterministic? i.e. how can other peers know when I publish a block that I was scheduled properly and didn't just decide to publish one anyway? Sorry if it's not the right place for noob questions!

[cardanocloud-com]

@Aranad, if you want to know the details of how this works then you need to read chapter 3 of the spec (https://eprint.iacr.org/2018/378.pdf).

Simply put, this happens with a verifiable random function (VRF). With your secret key, stake size and randomness from the previous epoch this VRF is able to determine for which slots you are eligible to be the slot leader. Once you sign the block others are able to cryptographically verify that you are indeed the slot leader for that block.

Currently a lot of "block theft" is happening (more than 20% of the blocks per epoch). This is because there are multiple adversarial pools with a large combined stake that constantly create adversarial forks. If you add your block to an adversarial fork then your block will be discarded.

Currently, Jormungandr doesn't discard blocks from adversarial pools. Subscribe to #1503 if you want to follow the progress.

[mmahut]

I don't know what the reporter is seeing is related to the adversarial forks, however agree that he should read the paper and/or ask these in the telegram channels, as github is not the best place for it.

Feel free to close this issue, please.