Skip to content

Conversation

obycode
Copy link
Contributor

@obycode obycode commented Aug 20, 2025

Description

This is the first step in the Clarity 4 proposal (see SIP PR #218). This changes adds Epoch 3.3, Clarity version 4, and costs-4, which is needed for the new builtins. Epoch 3.3 is currently set to activate at Bitcoin height 33,000,000, and Clarity 4 does not activate until 3.3, so it should be safe to merge into develop.

Checklist

  • Test coverage for new or modified code paths
  • Changelog is updated
  • Required documentation changes (e.g., docs/rpc/openapi.yaml and rpc-endpoints.md for v2 endpoints, event-dispatcher.md for new events)
  • New clarity functions have corresponding PR in clarity-benchmarking repo

See clarity-lang/reference#88 and
stacks-network#6320 for dicsussion
about this new builtin function.
For now, this is only accessible via the CLI:
```sh
stacks-inspect contract-hash <path-to-contract>
```
Also adds Epoch 3.3 and costs-4 to support this new function and removes
the MAST implementation from the previous proposal.
@obycode obycode requested review from a team as code owners August 20, 2025 19:02
@obycode obycode moved this to Status: In Review in Stacks Core Eng Aug 20, 2025
@obycode obycode added this to the 3.3.0.0.0 milestone Aug 20, 2025
@obycode obycode linked an issue Aug 20, 2025 that may be closed by this pull request
This is not needed since it will actually execute a read-only call in
the Clarity version for the called contract. Removing this allows us to
safely set `ClarityVersion::latest()` to return `Clarity4`.
@obycode obycode self-assigned this Aug 20, 2025
@aldur aldur requested review from kantai and hstove August 21, 2025 14:53
@obycode
Copy link
Contributor Author

obycode commented Aug 22, 2025

These failing integration tests all pass locally. I don't recall seeing these be flaky in other PRs. I will take a look to see if I introduced a new source of flakiness somewhere.

@obycode
Copy link
Contributor Author

obycode commented Aug 25, 2025

I believe the flakiness I saw before is solved by #6420.

Copy link
Contributor

@kantai kantai left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

This looks good to me, just have a few comments

kantai
kantai previously approved these changes Sep 3, 2025
hstove
hstove previously approved these changes Sep 3, 2025
@obycode obycode dismissed stale reviews from hstove and kantai via 0b862ec September 3, 2025 21:04
@obycode obycode requested review from hstove and kantai September 3, 2025 21:06
@obycode
Copy link
Contributor Author

obycode commented Sep 3, 2025

Sorry to request again @kantai and @hstove -- I just realized there was an error when GitHub merged the changelog.

kantai
kantai previously approved these changes Sep 3, 2025
@obycode obycode mentioned this pull request Sep 3, 2025
4 tasks
hstove
hstove previously approved these changes Sep 3, 2025
@obycode
Copy link
Contributor Author

obycode commented Sep 4, 2025

The new test, tests::nakamoto_integrations::test_epoch_3_3_activation, is failing due to the changes for the epoch markers, c6074fb and 2a41ead. I need to figure out the right way to fix that...

@obycode
Copy link
Contributor Author

obycode commented Sep 4, 2025

What I've come up with is to do this in make_block_commit to allow us to test advancing to the latest epoch without yet "supporting" the latest epoch. Let me know if you have any better ideas.

            memo: if cfg!(test) && target_epoch.epoch_id > StacksEpochId::latest() {
                vec![marker_for_epoch(target_epoch.epoch_id).expect("Unsupported epoch")]
            } else {
                vec![STACKS_EPOCH_LATEST_MARKER]
            },

Also harden the `test_epoch_3_3_activation` test a bit.
@obycode obycode dismissed stale reviews from hstove and kantai via 46fdd6b September 4, 2025 18:30
@obycode
Copy link
Contributor Author

obycode commented Sep 5, 2025

What I've come up with is to do this in make_block_commit to allow us to test advancing to the latest epoch without yet "supporting" the latest epoch. Let me know if you have any better ideas.

Actually, I realized just have a test version of StacksEpochId::latest() is much cleaner. I'll add that now.

The test implementation returns epoch 3.3 while the non-test version
returns 3.2.
@obycode obycode requested review from hstove and kantai September 5, 2025 16:07
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
Status: Status: In Review
Development

Successfully merging this pull request may close these issues.

[Clarity-4] contract-hash?
4 participants