Tracking: Malleable inputs for Checked<Transaction> type

[xgreenx]

Maybe move fuel_core_executor::Executor::compute_inputs to Checked or add a way of updating it.

[xgreenx]

Actually not, we decided to keep them malleable FuelLabs/fuel-specs#542. But we still need to update the implementation of FuelVM to zero fields

[Dentosal]

@xgreenx Do I understand correctly that the issue description is now outdated, and we just have to zero the malleable fields before execution?

[xgreenx]

Yep=) We need to update the specification to reflect this change and update our codebase to zero all malleable fields(except witnesses)

[Dentosal]

Yep=) We need to update the specification to reflect this change and update our codebase to zero all malleable fields(except witnesses)

So like this? FuelLabs/fuel-specs#545 It feels weird to even have things like InputCoin::tx_pointer if that's zero-initialized.

[xgreenx]

Yeah, looks correct. Maybe it also worth removing the corresponding GTF

All instances of TxPointer exist only for light clients and for fraud-proofing purposes. It simplifies the flow significantly allowing the passing of direct data based on the pointer=)

[Dentosal]

@xgreenx Currently, receipts_root is updates in-memory after modifying receipts. Moreover, it's specified to be:

Note: when executing a script, receiptsRoot is initialized to zero.

The receipts root receiptsRoot is the root of the binary Merkle tree of receipts. If there are no receipts, its value is set to the root of the empty tree, i.e. 0xe3b0c44298fc1c149afbf4c8996fb92427ae41e4649b934ca495991b7852b855.

This seems to conflict itself. What's the actual behavior we want here? Do we even need access to this value during execution?

[xgreenx]

Note: when executing a script, receiptsRoot is initialized to zero.

By this phrase, we usually mean at the start of the execution of the transaction something should be zero=)

So, modifying it shouldn't affect the validity of the block(I mean the validator should receive the same result as a producer).

But, I don't think there is any use case for accessing the receipts root during the execution. Maybe somehow for the old fraud-proof model, but since we still need access to all old receipts to calculate the next receipt root, I don't think so. cc @Voxelot @dmihal

Maybe it makes sense from a performance perspective only to do one root calculation at the end of the script execution. But it means we need to update the specification since it says that we need to update it each time:

Append a receipt to the list of receipts, modifying tx.receiptsRoot: