RFC: Do not propagate operations inside blocks

[damip]

RFC: Do not propagate operations inside blocks

General idea

Currently, operations are propagated twice:

• once naked
• once within a block

This RFC proposed propagating operations naked, and only referencing them by their hash in blocks

Block propagation and processing

Currently, block propagation and processing works this way:

• a header is announced
• the full block is asked
• the full block is sent, including the header and all ops
• the full block is received, deserialized (incl. all ops)
• the hash of every op is recomputed and checked against the cache

What we could do:

• a header is announced
• the op hash list is asked for that header
• the op hash list is sent for that block (non-truncated hashes must be used)
• the op hash list is received, deserialized, and the total op hash is checked against the one in the header
• the hash list is compared to the operations cache
  • the list of missing ops is asked to the sender (non-truncated hashes must be used)
    • this must be prioritized over normal op propagation
  • once we have all ops, the block is processed
  • if the remote node fails to send us all missing ops after a timeout (or if any is invalid):
    • ban the node and disconnect from it
    • ask for missing ops from another node that announced the block (if any, otherwise just forget about that block for now)

Gains

• important reduction in bandwidth and CPU usage
• no problem with signature malleability (see RFC: Exclude signature from objectID computation #2690 )

Possible problems

• more latency in block processing in case of missing ops

[AurelienFT]

I don't see any bad point on this except that it's better if we are sure about our operation naked propagation algorithm before

[damip]

Possible attack vector when combining with operation ID truncation: #2584 (comment)

[gterzian]

@damip

What we could do:

Is it correct to read that list of actions as resulting in a node never "asking for a block", instead constructing it locally from the header + ops? This would mean that the block concept could be removed from the networking concept, as it only is a kind of internal structure created from header + ops received over the network?

In most cases all the ops for the header would likely already be present at the receiving node, because those would have been propagated already prior to block production?

Also, what is the "op hash list", do you have a reference in the current code?

Can we not send the "op hash list" alongside the header?

Finally, we already have quite a lot of "ask block" code/infra, see for example

massa/massa-protocol-worker/src/protocol_worker.rs

Line 580 in e114c23

async fn update_ask_block(

So I guess we could change that to "ask operations for a block"? The ask/re-ask logic should be quite similar don't you think?

[damip]

"op hash list" is the list of operation IDs contained in the block. Full (non-truncated) hashes.

We can see it this way: operations are downloaded separately from the block, but we consider that the block is complete and ready for processing when all its dependencies (parents and operations) have been processed.

Sending the list of block operation IDs alongside the header would cause a large overhead (we announce it to all connected nodes 2x per second), which is why we prefer announcing headers and then explicitly asking for the op id list, then for the missing ops.

Part of the existing block ask infra could be reused I guess, but I'm not sure how extensively

[gterzian]

Ok, thanks for the info.

[gterzian]

@damip By the way, how do endorsements play into this? We would need them as well in order to process the block, right?

[AurelienFT]

Endorsements are part of the header so I don't think it change something.

[damip]

It's true that we could do the same thing for endorsements, but the code complexity vs size gains are not worth it for now, so let's keep them inside the headers.