-
Notifications
You must be signed in to change notification settings - Fork 11
chore(ci): update Dojo to v1.7.0
#284
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Open
kariy
wants to merge
9
commits into
main
Choose a base branch
from
update-dojo-integration-test
base: main
Could not load branches
Branch not found: {{ refName }}
Loading
Could not load tags
Nothing to show
Loading
Are you sure you want to change the base?
Some commits from the old base branch may be removed from the timeline,
and old review comments may become outdated.
Open
Conversation
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
## 'Legacy' Transaction V3 When V3 transaction was first introduced in RPC [v0.6.0], the `resource_bounds` field consists of only two fields; `l1_gas` and `l2_gas`. These values are included in the hash computation for the V3 transaction. But RPC [v0.8.0], a new field is added to the mapping, `l1_data_gas`. The addition of the new field means there are now two variations of the V3 transaction - with or without `l1_data_gas`. Depending on the presence of the field, the transaction hash is computed differently. Transaction V3 w/o `l1_data_gas` (legacy) hash: ``` h( "prefix", version, sender_address, h(tip, l1_gas_bounds, l2_gas_bounds), h(paymaster_data), chain_id, nonce, data_availability_modes, h(account_deployment_data), h(calldata) ) ``` Transaction V3 w/ `l1_data_gas` hash: ``` h( "prefix", version, sender_address, h(tip, l1_gas_bounds, l2_gas_bounds, l1_data_gas_bounds), h(paymaster_data), chain_id, nonce, data_availability_modes, h(account_deployment_data), h(calldata) ) ``` V3 transaction without the `l1_data_gas` is referred to as 'legacy' V3. ## Previous Refactors When pull request [#141] was made, I didn't take into account the possibility that a transaction with 'legacy' resource bounds would have a nonzero `l2_gas`. Hence why in that pull request, the `ResourceBoundsMapping::L1Gas` wraps a `ResourceBounds` struct - intended only for the `l1_gas` field. Currently, when computing the hash for transaction that uses the legacy resource bounds mapping, Katana naively assumes that the `l2_gas` bounds is 0. While this is true for most part, because some Starknet client libraries (eg `starknet-rs`) hardcoded the `l2_gas` to 0, but this doesn't fully negate the possibility that a transaction could be submitted with non-zero `l2_gas`. Even though the `l2_gas` wasn't actually used for execution, it is still used to compute the hash for the transaction. Preserving all the bounds is important if we want to make sure the hashes of transactions stored in the Katana database are reproducible! Honestly, if we only consider the transaction version that Katana supports now - 0.14.0 compatible transaction where all 3 bounds must be present - then this change really doesn't do anything at all. Transactions using legacy resource bounds will be outright rejected by the RPC server, and we don't have to worry about ensuring their hashes reproducibility. This change only matters once we have Katana running as a full node, syncing from Starknet mainnet/sepolia where transactions with only `l1_gas` and `l2_gas` resource bounds exist. As such, it is important that all details of a transaction is preserved correctly. ## Database Compatibility This change isn't compatible with the current database format. As such a database version bump is required! [v0.6.0]: https://github.com/starkware-libs/starknet-specs/blob/49665932a97f8fdef7ac5869755d2858c5e3a687/api/starknet_api_openrpc.json#L3714 [v0.8.0]: https://github.com/starkware-libs/starknet-specs/blob/b4f81445c79b2a8b2b09ff5bb2b7eddca78a32de/api/starknet_api_openrpc.json#L3494-L3514 [#141]: #141 --------- Co-authored-by: Claude <noreply@anthropic.com>
Switch from GitHub-hosted runners to [Blacksmith] runners. This is an initial test migration. The change may be reverted if Blacksmith runners do not provide the expected benefits. [Blacksmith]: https://www.blacksmith.sh/ --- Co-authored-by: blacksmith-sh[bot] <157653362+blacksmith-sh[bot]@users.noreply.github.com> Co-authored-by: Ammar Arif <evergreenkary@gmail.com>
Fixes build script triggering on every `cargo build` even when contract files haven't changed ## Problem The `katana-contracts` build script was being triggered unnecessarily on every `cargo build` command, even when no files in the `crates/contracts/contracts` directory had changed. ## Root Causes * The build script was watching the entire `contracts/` directory with `cargo:rerun-if-changed=contracts/`, which is unreliable in Cargo * `scarb build` updates `Scarb.lock` file timestamp even when content doesn't change ## Solution Instead of watching the entire `contracts/` directory, the script watches the nested directories instead to avoid including `Scarb.lock` file in the watch list. 🤖 Generated with [Claude Code](https://claude.ai/code) --------- Co-authored-by: Claude <noreply@anthropic.com>
…modes (#280) Refactor `katana init` command to use explicit subcommands for rollup and sovereign chain modes. Now running `katana init` requires you to select the mode as a subcommand: `katana init rollup` or `katana init sovereign`. One of the reason why we made this change is because the CLI argument configurations will always require you to provide the arguments instead of falling back to prompting. The expected behaviour when you literally just run `katana init` is for it to prompt the arguments like so: <img width="411" height="51" alt="Screenshot 2025-09-23 at 10 03 49 AM" src="https://github.com/user-attachments/assets/e910a787-e412-4c61-b519-ea574d689382" /> But due to how the CLI arguments is being configured, we instead get an error for not providing the arguments using flags: <img width="1030" height="149" alt="Screenshot 2025-09-23 at 10 04 05 AM" src="https://github.com/user-attachments/assets/d5ab9ab6-ecb3-43f7-bd80-e4b9b646edfc" /> This is mainly because of the `#[arg(required_unless_present = "sovereign")]` tag we're using that forces us to provide the options if `--sovereign` is not present. https://github.com/dojoengine/katana/blob/d584d4224f75f3648d55d1e4cec773ed638967ff/bin/katana/src/cli/init/mod.rs#L44-L48 Afaik it doesn't seem to be possible to 'fix' this using `clap` derive macro. Even if it does, I believe separating the mode into separate commands feels like a better UX. ## Comparison with current behaviour - Current: `katana init --id my-chain --settlement-chain sepolia ...` - New: `katana init rollup --id my-chain --settlement-chain sepolia ...`
🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
v1.7.0
Replace building sozo from source with downloading the prebuilt binary from Dojo v1.7.0 GitHub release. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
Member
Author
|
1 Job Failed: test / dojo-integration-test failed on "Build sozo from source"Summary: 1 failed workflow
Last updated: 2025-09-23 23:01:22 UTC |
The prebuilt binary requires GLIBC 2.38/2.39 which is not available in the CI container. Added comment explaining why we need to build from source. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
Codecov Report✅ All modified and coverable lines are covered by tests. Additional details and impacted files@@ Coverage Diff @@
## main #284 +/- ##
==========================================
+ Coverage 73.32% 75.70% +2.38%
==========================================
Files 209 229 +20
Lines 23132 27091 +3959
==========================================
+ Hits 16961 20509 +3548
- Misses 6171 6582 +411 ☔ View full report in Codecov by Sentry. 🚀 New features to boost your workflow:
|
Sozo v1.7.0 requires Rust 1.88+ due to clap dependency API changes. The CI container uses Rust 1.86 which causes compilation errors. 🤖 Generated with [Claude Code](https://claude.ai/code) Co-Authored-By: Claude <noreply@anthropic.com>
e3bd68b to
e897bbb
Compare
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
Bump the Dojo version in the integration test to the newly released, 1.7.0 version. This release no longer requires nightly scarb but uses the stable 2.12.2.