Block Proposal Tx Store

[PhilWindle]

No description provided.

[spalladino]

Is there an issue if a malicious proposer enters a malicious url into that field? Can it use the url to cause 20k nodes to simultaneously hit an endpoint not prepared to handle those? Or is there a risk for nodes to download a payload from a random location?

I was thinking if we could have an alternate design leveraging the "block body" repositories we discussed for syncing. We could keep a set of well-known repositories for block bodies that also serve txs associated with proposals, and proposers can send an authenticated (with their proposer key) request to those repositories to push the txs for their proposal. This way a node would only follow the proposal's url if it was previously whitelisted in the config. However, this means that these repositories are no longer just a cloud-based filestore, but require an API for posting data, adding complexity.

Last point, do we need this? Or do we think supernodes would be enough?

[PhilWindle]

Is there an issue if a malicious proposer enters a malicious url into that field? Can it use the url to cause 20k nodes to simultaneously hit an endpoint not prepared to handle those? Or is there a risk for nodes to download a payload from a random location?

Downloading a payload from a random location I don't think is a problem. Presumably the node would reproduce the tx hash and verify against that expected, then verify the proof. Any discrepancies and it would just be ignored/deleted.

However, one thing that might be a problem is malicious nodes modifying the proposal with a different url. Maybe an improvement is the proposer stores a signature over the tx along with the tx. This should be a very fast download and verify so the retriever knows the data was put there by the proposer.

I was thinking if we could have an alternate design leveraging the "block body" repositories we discussed for syncing. We could keep a set of well-known repositories for block bodies that also serve txs associated with proposals, and proposers can send an authenticated (with their proposer key) request to those repositories to push the txs for their proposal. This way a node would only follow the proposal's url if it was previously whitelisted in the config. However, this means that these repositories are no longer just a cloud-based filestore, but require an API for posting data, adding complexity.

I like this idea, yes it would be more complex but I don't think it would be too bad.

Last point, do we need this? Or do we think supernodes would be enough?

In short, I don'tknow. My hope is that our P2P peerscoring improvments + the improved req/resp protocol greatly reduce the tx availability problem. Supernodes are an even stronger addition to this, but of course they rely entirely on people runinng them, which is ourside of our control. I was exploring ways in which I as a proposer can be sure of making my transactions available to those that need them.

[spalladino]

However, one thing that might be a problem is malicious nodes modifying the proposal with a different url. Maybe an improvement is the proposer stores a signature over the tx along with the tx. This should be a very fast download and verify so the retriever knows the data was put there by the proposer.

In my mind, the proposal URL was signed by the proposer, so nodes can verify the URL even before attempting the download.