Skip to content

Conversation

@kariy
Copy link
Member

@kariy kariy commented Sep 23, 2025

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.

kariy and others added 5 commits September 19, 2025 08:00
## '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>
@kariy kariy changed the title chore: update dojo to v1.7.0 and scarb to 2.12.2 chore(ci): update Dojo to v1.7.0 Sep 23, 2025
kariy and others added 2 commits September 23, 2025 15:15
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>
Copy link
Member Author

kariy commented Sep 23, 2025

1 Job Failed:

test / dojo-integration-test failed on "Build sozo from source"
[...]
     |                   required by a bound introduced by this call
     |
     = help: the following other types implement trait `From<T>`:
               `clap::builder::Str` implements `From<&&str>`
               `clap::builder::Str` implements `From<&clap::builder::Str>`
               `clap::builder::Str` implements `From<&str>`
               `clap::builder::Str` implements `From<clap::Id>`
     = note: required for `std::string::String` to implement `Into<clap::builder::Str>`
     = note: required for `std::string::String` to implement `IntoResettable<clap::builder::Str>`
note: required by a bound in `clap::Command::version`
    --> /usr/local/cargo/registry/src/index.crates.io-1949cf8c6b5b557f/clap_builder-4.5.47/src/builder/command.rs:2079:40
     |
2079 |     pub fn version(mut self, ver: impl IntoResettable<Str>) -> Self {
     |                                        ^^^^^^^^^^^^^^^^^^^ required by this bound in `Command::version`

For more information about this error, try `rustc --explain E0277`.
error: could not compile `sozo` (bin "sozo") due to 1 previous error
error: failed to compile `sozo v1.7.0 (/__w/katana/katana/dojo/bin/sozo)`, intermediate artifacts can be found at `/__w/katana/katana/dojo/target`.
To reuse those artifacts with a future compilation, set the environment variable `CARGO_TARGET_DIR` to that path.
Error: Process completed with exit code 101.

Summary: 1 failed workflow
  • test (7 jobs succeeded, 1 job failed)

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
Copy link

codecov bot commented Sep 23, 2025

Codecov Report

✅ All modified and coverable lines are covered by tests.
✅ Project coverage is 75.70%. Comparing base (9bde0ae) to head (ecc5432).
⚠️ Report is 122 commits behind head on main.

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.
📢 Have feedback on the report? Share it here.

🚀 New features to boost your workflow:
  • ❄️ Test Analytics: Detect flaky tests, report on failures, and find test suite problems.

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>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants