You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Upon receiving a proposal, the referenced block should exist at the node and should be verified.
Per Areg:
"I think we want to verify you have the data before voting on a proposal that references (perhaps indirectly) a block. That means verifying the block ID of the block header matches and that the transaction Merkle root in the block header matches Merkel root computed from the transactions in the block. Additionally we should verify that the previous ID in the block header references another block that you have similar verified to have data present.
There is a question of whether to bother with block header validation or not at this stage. I think since it is cheap, it would be wise to do that as well.
But we don't need to actually validate the block (meaning executing transactions). That could come later. Technically it is safe to delay that until just prior to voting on a proposal that references the block (perhaps indirectly) via the final_on_qc reference.
That said, for the initial release, we could also just be more conservative and do full block validation before even the first vote. It does cost a bit of latency. But we could do that first (which I think is easier in terms of implementation) and then later see what kind of performance gain we get if we go through the effort of delaying block validation until the last moment."
Question: Should the node verify that the proposal is valid (i.e. refer to a valid block) before propagating the proposal to its peers.
The text was updated successfully, but these errors were encountered:
Upon receiving a proposal, the referenced block should exist at the node and should be verified.
Per Areg:
"I think we want to verify you have the data before voting on a proposal that references (perhaps indirectly) a block. That means verifying the block ID of the block header matches and that the transaction Merkle root in the block header matches Merkel root computed from the transactions in the block. Additionally we should verify that the previous ID in the block header references another block that you have similar verified to have data present.
There is a question of whether to bother with block header validation or not at this stage. I think since it is cheap, it would be wise to do that as well.
But we don't need to actually validate the block (meaning executing transactions). That could come later. Technically it is safe to delay that until just prior to voting on a proposal that references the block (perhaps indirectly) via the final_on_qc reference.
That said, for the initial release, we could also just be more conservative and do full block validation before even the first vote. It does cost a bit of latency. But we could do that first (which I think is easier in terms of implementation) and then later see what kind of performance gain we get if we go through the effort of delaying block validation until the last moment."
Question: Should the node verify that the proposal is valid (i.e. refer to a valid block) before propagating the proposal to its peers.
The text was updated successfully, but these errors were encountered: