goshawk-3

Fix TestHasAnywhereBigData unit test

1

`TestHasAnywhereBigData` unit test fails on CI but always passes running locally

node: Handle a race condition between `request for a block` and `block acceptance` procedure.

2

**Describe the bug** It has been discovered that there could be a timing conflict between the `flood_request` handling and block acceptance processes. Essentially, while a node is handling a GetResource(a.k.a...

Resolves #1528 Acceptance criteria: - [x] `GetBlocks` message flow works properly as usual. It should not trigger `flood_request` - [x] `GetData` uses `flood_request` to retrieve a resource (block/transaction) from a...

#### Summary > 💡 Use "Flooding with Random Walk" impl (if beneficial for) in GetCandidate message flow. Context: `GetCandidate` P2P message is currently used in creating the winner block in...

node: Implement checkpoints for recovery procedures

3

#### Summary In scenarios similar to the one outlined in https://github.com/dusk-network/rusk/issues/1093, it is essential to have the ability to revert to either the "last epoch" or the most recent "valid"...

node: Broadcast block on a verified certificate

1

#### Summary This is to reflect the change from https://github.com/dusk-network/dusk-blockchain/issues/1446. #### Additional context

node: Re-enable consensus task on a failed block acceptance

1

#### Summary If a block is distributed with a valid certificate but contains erroneous transactions, the node should reject the block and reactivate the consensus process for the corresponding round....

node: Mitigate the impact of offline nodes over message propagation

1

#### Summary On having offline nodes for a longer period, we rely solely on kadcast redundancy factor for complete a msg broadcast. However, as suggested by @herr-seppia , we may...

node: Support the acceptance of an emergency block

9

#### Summary _In case not even the emergency mode allows the network to produce a block, the very last iteration (255) is reserved for a Dusk-signed block that is accepted...

**Describe the bug** After implementing issue #1465 , any `unbounded` queue that buffers inbound messages must be either limited or replaced by a ring buffer to mitigate any OOM attack.