feat: add more constants toVersionedConstants

[giladchase]

• Add gateway constants, these are only for transparency, and aren't used directly by the Blockifier whatsoever.
• Pass validate_max_n_steps into the blockifier via native_blockifier, to override versioned constants defaults.

Python: https://reviewable.io/reviews/starkware-industries/starkware/33582

---

This change is 

[elintul]

Reviewed 4 of 4 files at r1, all commit messages.
Reviewable status: all files reviewed, 3 unresolved discussions (waiting on @giladchase and @noaov1)

---

-- commits line 5 at r1:
Why add them then?

Code quote:

  - Add gateway constants, these are only for transparency, and aren't
    used directly by the Blockifier whatsoever.

---

crates/blockifier/src/versioned_constants.rs line 16 at r1 (raw file):

});

/// `VersionedConstants` contains constants for the Blockifier that may vary between versions.

Suggestion:

Contains

---

crates/native_blockifier/src/py_block_executor.rs line 41 at r1 (raw file):

    pub fn create(
        general_config: PyGeneralConfig,
        validate_max_n_steps: u32,

What about max number of steps for execute? Also, why not inside general config?

Code quote:

validate_max_n_steps

[giladchase]

Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @elintul and @noaov1)

---

-- commits line 5 at r1:

Previously, elintul (Elin) wrote…

Why add them then?

Lior asked for it during the design review, for transparency, and to make the blockifier a single source of truth for constants relating to its operation.

---

crates/native_blockifier/src/py_block_executor.rs line 41 at r1 (raw file):

Previously, elintul (Elin) wrote…

What about max number of steps for execute? Also, why not inside general config?

It came up in the design review as well, Lior wanted this one to be configurable but not the execute, we didn't have enough time in the meeting to enquire why.

[codecov-commenter]

Codecov Report

Attention: 15 lines in your changes are missing coverage. Please review.

Comparison is base (38af968) 70.51% compared to head (4aaa9d1) 70.42%.

Files	Patch %	Lines
crates/native_blockifier/src/py_utils.rs	0.00%	9 Missing ⚠️
crates/native_blockifier/src/py_block_executor.rs	0.00%	3 Missing ⚠️
crates/native_blockifier/src/py_validator.rs	0.00%	3 Missing ⚠️

Additional details and impacted files

@@                    Coverage Diff                    @@
##           gilad/account-tx-info    #1369      +/-   ##
=========================================================
- Coverage                  70.51%   70.42%   -0.10%     
=========================================================
  Files                         60       60              
  Lines                       7759     7769      +10     
  Branches                    7759     7769      +10     
=========================================================
  Hits                        5471     5471              
- Misses                      1861     1871      +10     
  Partials                     427      427              

☔ View full report in Codecov by Sentry.
📢 Have feedback on the report? Share it here.

[elintul]

Reviewed 1 of 1 files at r2, all commit messages.
Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @giladchase and @noaov1)

---

-- commits line 5 at r1:

Previously, giladchase wrote…

Lior asked for it during the design review, for transparency, and to make the blockifier a single source of truth for constants relating to its operation.

How is it a single source of truth if they aren't used? :(

---

crates/native_blockifier/src/py_block_executor.rs line 41 at r1 (raw file):

Previously, giladchase wrote…

It came up in the design review as well, Lior wanted this one to be configurable but not the execute, we didn't have enough time in the meeting to enquire why.

Let's try to understand, maybe in Slack?
Also understand where did the invoke max steps go. 😬

[giladchase]

Reviewable status: all files reviewed, 2 unresolved discussions (waiting on @elintul and @noaov1)

---

-- commits line 5 at r1:

Previously, elintul (Elin) wrote…

How is it a single source of truth if they aren't used? :(

Single source of truth for both python and blockifier.
Python downloads the json file via bazel (downloads it from the blockifier repo) and extracts these constants from there.

[elintul]

Reviewed 4 of 4 files at r3, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @noaov1)

[elintul]

Reviewed 2 of 26 files at r4, 26 of 26 files at r5, all commit messages.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @noaov1)

The base branch was changed.

[giladchase]

Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @noaov1)

---

crates/native_blockifier/src/py_block_executor.rs line 41 at r1 (raw file):

Previously, elintul (Elin) wrote…

Let's try to understand, maybe in Slack?
Also understand where did the invoke max steps go. 😬

Resolved f2f. Closing.

[noaov1]

Reviewed 1 of 4 files at r1, 1 of 4 files at r3, 1 of 26 files at r4, 2 of 26 files at r5, all commit messages.
Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @dorimedini-starkware and @giladchase)

---

crates/native_blockifier/src/py_block_executor.rs line 42 at r5 (raw file):

        general_config: PyGeneralConfig,
        validate_max_n_steps: u32,
        max_recursion_depth: usize,

Out of curiosity- Do we always want to pass it? Why not making it optional?

Code quote:

        validate_max_n_steps: u32,
        max_recursion_depth: usize,

[giladchase]

Note that the gateway constants will also be overriden in the native blockifier just as the validate constant is at this PR.

We'll handle this separately from this PR in an upcoming gateway.

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @dorimedini-starkware and @noaov1)

---

crates/native_blockifier/src/py_block_executor.rs line 42 at r5 (raw file):

Previously, noaov1 (Noa Oved) wrote…

Out of curiosity- Do we always want to pass it? Why not making it optional?

Just to simplify the implementation.
As an optional, it'll require the python config to also hold this optionally, and we'll have to match on it here.

[noaov1]

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @dorimedini-starkware and @giladchase)

---

crates/native_blockifier/src/py_block_executor.rs line 42 at r5 (raw file):

Previously, giladchase wrote…

Just to simplify the implementation.
As an optional, it'll require the python config to also hold this optionally, and we'll have to match on it here.

Okay. So we plan to have a copy of this constants in the python repository that will be "fed" to the blockifier?

[noaov1]

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @dorimedini-starkware and @giladchase)

[giladchase]

Reviewable status: all files reviewed, 1 unresolved discussion (waiting on @dorimedini-starkware and @noaov1)

---

crates/native_blockifier/src/py_block_executor.rs line 42 at r5 (raw file):

Previously, noaov1 (Noa Oved) wrote…

Okay. So we plan to have a copy of this constants in the python repository that will be "fed" to the blockifier?

Xactly, see the python PR for how it is passed.
In the upcoming Prs, once the infra is ready, python will no longer have copy of the default value from versioned_constants.json, it'll take it directly from the blockifier, so that the only case where they'll be different is if they are explicitly replaced at runtime or if someone overrides the defaults in one of the python presets.

[noaov1]

Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @dorimedini-starkware)

[noaov1]

Reviewed 24 of 26 files at r5.
Reviewable status: complete! all files reviewed, all discussions resolved (waiting on @dorimedini-starkware)