[Bug] Malicious validator can send fake BlockResponse to block honest validators from processing messages about snarkos

[raychu86]

On the MAX_TRANSACTIONS front, there are 2 limiters:

1. The protocol limit allows up to 2^20 transactions according to our merkle tree standard.
2. The BFT worst case scenario formula is MAX_NUM_VALIDATORS * NUM_TRANSACTIONS_IN_PROPOSAL * MAX_GC_ROUNDS as defined by Transactions::<N>::MAX_ABORTED_TRANSACTIONS. In testnet, this value is 100 * 50 * 100 = 500,000. Which is already large enough that the problem still persists

I would say that this problem needs a more fundamental fix/avoidance than just lowering the size check.

[elderhammer]

I think there are two problems to solve:

1. Refer to the changes in #3304 and put the deserialization work into the rayon thread
2. Appropriately reduce MAX_TRANSACTIONS (I remember that each certificate can only have a maximum of 50 transactions)

[vicsn]

@joske can you confirm if this is an issue (and the related PR resolves it?)

[joske]

I think #3304 should avoid the node getting stuck on big blocks. That said, there's still a deadlock in sync that we haven't found yet.

I don't know about the MAX_TRANSACTIONS

[elderhammer]

I think #3304 should avoid the node getting stuck on big blocks. That said, there's still a deadlock in sync that we haven't found yet.

I don't know about the MAX_TRANSACTIONS

I've looked at change 3304, which is a change to node/router/src/inbound.rs, but the problem described there is within the BFT module:

snarkOS/node/bft/src/gateway.rs

Lines 629 to 644 in cf83035

	Event::BlockResponse(block_response) => {
	// If a sync sender was provided, then process the block response.
	if let Some(sync_sender) = self.sync_sender.get() {
	// Retrieve the block response.
	let BlockResponse { request, blocks } = block_response;
	// Perform the deferred non-blocking deserialization of the blocks.
	let blocks = blocks.deserialize().await.map_err(|error| anyhow!("[BlockResponse] {error}"))?;
	// Ensure the block response is well-formed.
	blocks.ensure_response_is_well_formed(peer_ip, request.start_height, request.end_height)?;
	// Send the blocks to the sync module.
	if let Err(e) = sync_sender.advance_with_sync_blocks(peer_ip, blocks.0).await {
	warn!("Unable to process block response from '{peer_ip}' - {e}");
	}
	}
	Ok(())
	}

The value of MAX_TRANSACTIONS is hardcoded to 1048575, which means that a fake BlockResponse may be filled with 1048575 transactions, which will make deserialization extremely time-consuming.

[joske]

it's probably a good idea to defer this deserialization to rayon in Gateway too, yes.