ContractId differs between local and testnet deployments

General
1

Is this intended by design?

I create the contract using the same salt, e.g. in TS tests:

const { waitForResult } = await ContractAbi__factory.deployContract(
      bytecode,
      wallet1,
      {
        salt: "0x0000000000000000000000000000000000000000000000000000000000000000" as BytesLike
      }
    );

Returns hex: 0xd65987a6b981810a28559d57e5083d47a10ce269cbf96316554d5b4a1b78485a
The rust tests for the contracts are the same ID for local as well.

But running forc deploy --default-salt returns this hex: 0xbe731c917c10794b936a549a32ca30bb4ae8b550916923e225ba628ffe09c8b3

(–default-salt should resolve to “0x0000000000000000000000000000000000000000000000000000000000000000” according to docs)

What am I missing?

1 Like
2

Hey @xpluscal just to understand, you are deploying new contracts every single time right?

Also, could you share the contract and test you are running if that’s not the case.

1 Like
3

Hey, the goal is to only deploy the contract once on testnet.
Other contracts depend on the id, so it needs to be identical.

With deploying it aka using forc deploy --testnet --default-salt they do deploy with the same ID, but it differs to local.

I’ve spent quite some time with @Voxelot to go through it, we discovered the following:

  • salt is honored correctly
  • storage slots are identical
  • bytecode differs

Here’s our deployment process:

  • it’s a monorepo
  • I run pnpm dlx fuels build to build contracts and put the typegen output into the ts sdk
  • The ts sdk then runs all tests for the sdk (which includes deploying to local using launchTestNode)
  • those tests all check out
  • then running tests inside the contracts using cargo test. They also make use of the bytecode etc, all checks out
  • then running forc deploy —default-salt —testnet in a specific contract’s folder
  • this is where the id changes

Our current hunch is that forc is bundled differently with fuels than using forc directly. For some reason using forc deploy and using npx fuels build produce slightly different bytecodes.

Using latest fuelup toolchain and fuels 0.92.0 for build (aka build + typegen)

1 Like
4

Hey @xpluscal thanks for the detailed flow, allow me sometime to get back to you.

1 Like
5

Hey @xpluscal can you please share the output for the command fuelup show? also, can you please share codebase for us to look at?

1 Like
6

@xpluscal Could it be that contracts are being built using different build profiles?

  • forc build
  • forc build --release

If you have a fuels.config.ts, you can pass in desired forc build flags, i.e.:

// fuels.config.ts
import { createConfig } from 'fuels';

export default createConfig({
  ...
  forcBuildFlags: ['--release'], // <———— this
});

Could you please try it out and see if the binaries match now?

1 Like
7

@xpluscal Also, are you running both commands on the same computer and platform?

1 Like
8

@anderson yes both commands run on same platform and config.

So adding the release to my fuels.config.ts has resulted in the contract id generated from pnpm dlx fuels build to be the same as on deploy.

So basically does this mean that for local testing I should always do forc build --release rather than forc build?

Why do those differ?

1 Like
9

@xpluscal It all comes down to which build profile you’re using to build.

I think the confusion comes from the fact that these methods have different defaults:

  • forc build — defaults to --debug
  • forc deploy — defaults to --release

And you’ve been comparing the results of the outputs between build vs. deploy.

$ forc build --help
    --build-profile <BUILD_PROFILE>
        The name of the build profile to use
        [default: debug] # <—————————————————— DEBUG

$ forc deploy --help
    --build-profile <BUILD_PROFILE>
        The name of the build profile to use
        [default: release] # <———————————————— RELEASE
3 Likes
10

That does make sense.

@anderson so given the following use case, what would be your suggested approach?

  • Contract A makes calls to Contract B
  • Hence Contract A has the ContractId of Contract B as a const
  • We want the tests to work, hence Contract B needs to have the same ContractId when doing forc build and cargo test to test
  • We want it to work when deployed, hence forc deploy for Contract B and pnpm dlx fuels build to generate bytecode and typegen to also have the same ContractId for Contract B

Would you recommendation then be to run the tests with the --release flag?
Or deploy with debug…

The first one seems more reasonable, just couldn’t find anything in the docs.

1 Like
11

@xpluscal AFAICT, you just need to add the --release option to forcBuildFlags.

If everything else is working, this seems like the easiest path.

2 Likes