This is a bit unfortunate since we're discarding a keccak calculation.
The reason for this is here.
The received blocks must not have their hash already calculated. I suspect this is because they want to be strict on not received precomputed hashes as inputs.
For another angle, here in L15 we do let block_hash = input.blocks[0].hash(); which indirectly caches the calculated hash, thus the provided block does not meet the expectation later inside the block validation logic (linked above).
I think ideally Ethrex should accept the hashes value to be set, but always compute it in the validation and compare it (if present). This would make things a bit more flexible here, while keeping the "do not trust" values.
Note that the reason why I want the hash is to do the L23 check, so in the case of wanting to prove more than one block I can still commit to the block hash. I could simply avoid that expectation and let the host see that the third output (i.e., successful block validation) was false anyway, but feels like an unnecessary compromise to workaround this.
I also thought about doing the .len() != 1 after the execution_program, but that's a bit messy since res is a Result, plus I can't do input.blocks[0] since input was moved in execution_program(input) call.
We can live with this for a while, but eventually would be nice to remove this workaround.
Originally posted by @jsign in #176 (comment)
This is a bit unfortunate since we're discarding a keccak calculation.
The reason for this is here.
The received
blocksmust not have theirhashalready calculated. I suspect this is because they want to be strict on not received precomputed hashes as inputs.For another angle, here in L15 we do
let block_hash = input.blocks[0].hash();which indirectly caches the calculated hash, thus the providedblockdoes not meet the expectation later inside the block validation logic (linked above).I think ideally Ethrex should accept the hashes value to be set, but always compute it in the validation and compare it (if present). This would make things a bit more flexible here, while keeping the "do not trust" values.
Note that the reason why I want the hash is to do the L23 check, so in the case of wanting to prove more than one block I can still commit to the block hash. I could simply avoid that expectation and let the host see that the third output (i.e., successful block validation) was
falseanyway, but feels like an unnecessary compromise to workaround this.I also thought about doing the
.len() != 1after theexecution_program, but that's a bit messy sinceresis aResult, plus I can't doinput.blocks[0]sinceinputwas moved inexecution_program(input)call.We can live with this for a while, but eventually would be nice to remove this workaround.
Originally posted by @jsign in #176 (comment)