Open mversic opened 2 months ago
It's worth pointing out that CommittedTransaction::error
also isn't protected with block signature
while this doesn't affect consensus or integrity of the blockchain, client that receives a block can't ever be certain that this value is correct. Then again client can't trust any event or block stream produced by the node. Client should connect to a trusted node anyhow
IMO we should keep CommittedTransaction::error
separate from the block but make sure we return it to clients on FindBlocks
query and block stream. Nodes themselves have no use for it
If we keep it in the block, should we (during consensus voting) reject those blocks that have it set to an incorrect value?
We already do that when validating transactions.
Since
CommittedTransaction::error
is not protected by the block hash why keep it in the block? Every block replays all transactions and determines whether transaction is correct or faultyIf we keep it in the block, should we (during consensus voting) reject those blocks that have it set to an incorrect value?