Transaction.gasPrice Optional

[garyschulte]

Signed-off-by: garyschulte [email protected]

PR description

Systemic treatment of gasPrice as Optional has revealed several areas where we are still assuming gasPrice is not null and where we do not have specific treatment of 1559 fee fields

Fixed Issue(s)

#2389

Changelog

• I thought about the changelog and included a changelog update if required.

[matkt]

LGTM

[matkt]

@garyschulte maybe you have to ask those who work on the privacy features to be sure that there is no impact

[lucassaldanha]

Overall it is looking good and I don't think it will cause any side effects on private txs.

I've left a few comments/suggestions. Nothing major.

[lucassaldanha]

This clause is getting harder and harder to understand. Maybe we could encapsulate the "tx cost zero" logic into a method in the Transaction class?

Something like: transaction.hasGasPrice() or transaction.isGasPriceZero() (I'm not great with names, feel free to come up with a better name for this method).

I recon this would make this if statement easier to read:

if (goQuorumCompatibilityMode && transaction.hasGasPrice()) {
    ....
}

[garyschulte]

encapsulated in core Transaction. I went ahead and added 1559 fields just in case.

[lucassaldanha]

One thing that I'm thinking that we might want is to simplify the access to the tx gas price when we don't want to handle the optional value (e.g. when optional.empty means zero and not-empty means a Wei value).

e.g.
return transaction.getGasPrice().orElse(Wei.ZERO) and transaction.getGasPrice().get().getValue().longValue()
could become:
return transaction.getGasPriceValue() and transaction.getGasPriceValue().longValue()

What I'm thinking is that having a method like transaction.getGasPriceValue() or something, that "hides" the optional value in favour of a Wei or numeric might simplify the access to this property in some places.