Add a feature that propose u32 tx_pointer in fuel-tx and fuel-vm

[AurelienFT]

Having u32 tx_pointer is mendatory to make our system scales and support more than u16::MAX tx in a block.

However, changing this in the current network is a hard breaking change and is not needed for now. That's why we decided to add this change to the VM behind a feature flag if we want to use in other system or be able to enable it in our principal one too.

Checklist

• Breaking changes are clearly marked as such in the PR description and changelog
• New behavior is reflected in tests
• If performance characteristic of an instruction change, update gas costs as well or make a follow-up PR for that
• The specification matches the implemented behavior (link update PR if changes are needed)

Before requesting review

• I have reviewed the code myself
• I have created follow-up issues caused by this PR and linked them here

[rymnc]

LGTM, but in the malleable_fields_do_not_affect_* tests if we used u16::MAX and u32::MAX to indicate change in size vs adding some zeroes OR using rng to generate those values, would be nice, but is out of scope for this PR :)

[xgreenx]

It is a big breaking change for the type system. We need to have proper testing and double check that serialization and deserialization will be not affected for mainnet/testnet/devnet blocks. It would be nice try to use extreme values and see when postcard serialization/deserialiation will be different(like from 1 to u16::MAX).

Also maybe Rollup team uses bitcode, if yes, then it also break compressed blocks for them

[AurelienFT]

@xgreenx I didn't want to activate this feature on Ignition is it something we want to do in the near future ? For xxx, it will be a new network and will be in the specs.

[xgreenx]

We can activate it on Ignition, if tests show that old database types are compatible with it.

[AurelienFT]

I have added a test to showcase that we have a difference on the postcard serialization format (it's expected because postcard use varint encoding). I tried our .to_bytes() which doesn't break because it's not using varint and was padded to a 8 bytes value so u32 fits.

I don't really understand how we could activate this on Ignition but if we want to make more tests to activate this for Ignition they should be done on the fuel-core repository

[xgreenx]

I don't really understand how we could activate this on Ignition but if we want to make more tests to activate this for Ignition they should be done on the fuel-core repository

The answer for this is:

I have added a test to showcase that we have a difference on the postcard serialization format (it's expected because postcard use varint encoding)

Because we use postcard in P2P and Database, the variant encoding of integers should help us to deserialize old types of transactions, because we know that tx pointer is not more than u16. We just need to have a test that verifies that(that we can decode the old transaction type into a new one with any old tx pointer).

[xgreenx]

Along with this change would be nice to introduce "block_max_transactions" parameter to ConsensusParameters. It can be a separate change, we just need these two things released together.

[AurelienFT]

We just need to have a test that verifies that(that we can decode the old transaction type into a new one with any old tx pointer).

Added in 9273970

[rymnc]

lgtm, would be nice for some fuzzing/proptest for this new change

[xgreenx]

Because we use postcard in P2P and Database, the variant encoding of integers should help us to deserialize old types of transactions, because we know that tx pointer is not more than u16. We just need to have a test that verifies that(that we can decode the old transaction type into a new one with any old tx pointer).

It should be a compatibility test where we use the previous release(published crate) of the fuel-tx to serialize the transaction and the latest version to deserialize it. You can set TxPointer in the loop form 0..u16::MAX to see how it affects serialization and deserialization. To compare old Tx and new Tx, you can compare them as strings, or JSONs

[AurelienFT]

Thanks for the detailed explanation @xgreenx. Done :)

[xgreenx]

May I ask you to do the same for script transaction please?=D Or Mint transaction for simplicity