Clarity Version undefined while deployment says 2

[friedger]

Describe the bug Clarity version used in a deployment is not written to the chain

To Reproduce Steps to reproduce the behavior:

1. Apply the following deployment:

---
id: 0
name: Mainnet deployment
network: mainnet
stacks-node: "https://api.hiro.so"
bitcoin-node: "http://blockstack:[email protected]:8332"
plan:
  batches:
    - id: 0
      transactions:
        - contract-publish:
            contract-name: fp-payout-1
            expected-sender: SP21YTSM60CAY6D011EZVEVNKXVW8FVZE198XEFFP
            cost: 20000
            path: contracts/payout/payout-self-service.clar
            anchor-block-only: true
            clarity-version: 2

2. See that the clarity-version is undefined

Expected behavior clarity-version should be 2

https://api.hiro.so/extended/v1/tx/0x8d51044024c60b4684f93514ebfbeba2c7b277cd2fc449b69ef2ff1e4c8c24ae

Additional context Add any other context about the problem here:

[hugoclrd]

Thanks for reporting @friedger

The clarity-version set in deployments is for internal use in clarinet but doesn't impact the contract on chain. Because you can't set the clarity version of a contract when deploying it, it only depends on the epoch.

It's more likely an issue on the API, @zone117x should I transfer to the API repo?

[zone117x]

The clarity version can be specified when deploying a contract. A VersionedSmartContract tx type was created just for that purpose. Here's an example of one: https://api.hiro.so/extended/v1/tx/0x69ff769f3c2d5a10265d743c1b95cc65ec027fc47722447643a43ac2480c4886

And here's some stacks.js code that generates those tx types: https://github.com/hirosystems/stacks.js/blob/260f2d58577c92ef37d0f1d276e1e0fc0fd267b3/packages/transactions/src/builders.ts#L828-L846

it only depends on the epoch

It looks like there may have been some ambiguity in the SIP that introduced clarity 2. The VersionedSmartContract tx type can be used to explicitly specify which clarity version should be used.

However, it may also be the case that the clarity version is implicitly decided by the stacks-node if the original SmartContract tx type is used after the 2.1 epoch. IMO tooling should not depend on that kind of hidden footgun behavior -- the version should be specified if the user is explicitly requesting it.

Regardless, the API doesn't receive the information needed to determine this implicit epoch gating behavior via the event-stream, so the client would have to query /v2/pox (or similar) in order to disambiguate these implicitly-versioned txs.

[hugoclrd]

The clarity version can be specified when deploying a contract.

Ah my bad, I wasn't aware of that.

1. On the clarinet side, we should double check that the clarity version is taken into account when deploying a contract (maybe it's already the case)

2. @zone117x Wouldn't it make more sense for the API to not return the clarity_version if it always return null? Or does it only return the clarity_version if it's explicitly specified in the deployment tx?

[zone117x]

@zone117x Wouldn't it make more sense for the API to not return the clarity_version if it always return null? Or does it only return the clarity_version if it's explicitly specified in the deployment tx?

The API returns the clarity version when the tx type specifies it, see the above example https://api.hiro.so/extended/v1/tx/0x69ff769f3c2d5a10265d743c1b95cc65ec027fc47722447643a43ac2480c4886

My guess is that Clarinet is not specifying the clarity version using a VersionedSmartContract tx type.

[hugoclrd]

Ok I see. We'll need to address that, thanks!