Avoid whitelisting out of range block data #2096
Conversation
SebastianMarian
commented
Jul 12, 2020
SebastianMarian
commented
- Rejected whitelisting miniblocks included in headers which are out of range (this will fix the situation when a node is syncing and it will receive headers with higher nonces compared with the last one processed. Because of these headers which are received, it will whitelist its miniblocks and afterwards its transactions. More than this it will also add these transactions into immunized cache. This will fill up these caches (whitelist cache, immunized cache) with a lot of information which is not needed right now and which will also be evicted until its time will come)
…of range (this will fix the situation when a node is syncing and it will receive headers with higher nonces compared with the last one processed. Because of these headers which are received, it will whitelist its miniblocks and afterwards its transactions. More than this it will also add these transactions into immunized cache. This will fill up these caches (whitelist cache, immunized cache) with a lot of information which is not needed right now and which will also be evicted until its time will come)
SebastianMarian
added
type:bug
| @@ -2495,3 +2557,34 @@ func TestBaseBlockTrack_DoWhitelistWithShardHeaderIfNeededMetaShouldWhitelistCro | |||
|
|
|||
| assert.True(t, ok) | |||
| } | |||
|
|
|||
| func TestBaseBlockTrack_IsHeaderOutOfRangeShouldWork(t *testing.T) { | |||
There was a problem hiding this comment.
The tests run under the assumption that lastCrossNotarizedHeader has round 0, nonce 0. Did I understood corectly?
There was a problem hiding this comment.
Yes, what I wanted to test is that if the difference between last cross notarized header, no matter if it has nonce and round 0 (genesis), and the current header received is out of range ( <= last notarized or > last notarized + window ) the method works correctly. So, if you are syncing block with nonce 1 or 2, last cross notarized is for sure still 0 as you can include cross nonce 1 not early than in your block with nonce 3 (because of the finality), you don't care about received cross headers with nonces greater than 11. So you will not extract from these out of range cross headers, mini blocks to whitelist them and afterward because they were whitelisted you will also accept cross transactions which will be whitelisted too and then added into the immunized cache.
There was a problem hiding this comment.
Anyway, I have refactored the test to be more clear now
…block-data' into Avoid-whitelisting-out-of-range-block-data
SebastianMarian
dismissed stale reviews from raduchis and sasurobert
via
1d74e38
