Skip to content
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

fault_proving(global_roots): Populate tables for upgrade transactions #2584

Closed
netrome opened this issue Jan 16, 2025 · 0 comments · Fixed by #2621
Closed

fault_proving(global_roots): Populate tables for upgrade transactions #2584

netrome opened this issue Jan 16, 2025 · 0 comments · Fixed by #2621
Assignees

Comments

@netrome
Copy link
Contributor

netrome commented Jan 16, 2025

Following the initial scaffolding in #2553, we should add logic to populate the ConsensusParametersVersions and StateTransitionBytecodeVersions tables whenever we process an upgrade transaction, and add tests for this.

Definition of done

Whenever a upgrade transaction is processed, the ConsensusParametersVersions and StateTransitionBytecodeVersions tables are appropriately updated.

@acerone85 acerone85 self-assigned this Jan 22, 2025
rymnc pushed a commit that referenced this issue Feb 5, 2025
…ion (#2621)

on on upgrade transaction

Closes #2584

Questions for the reviewers: 

- [ ] I am assuming that the latest known state transition bytecode
version and latest known consensus parameters versions will be loaded
from the storage when the global root service starts, and will be passed
to the proces_block function through the `UpdateMerklizedTables` trait.
Is this reasonable?
- [ ] I am revalidating the upgrade transaction metadata, but I am not
sure if this is needed?
- [ ] I am assuming that both state transition bytecode version and
consensus parameters version increment by 1 when an upgrade transaction
with the corresponding purpose is processed, is this correct?




## Linked Issues/PRs
<!-- List of related issues/PRs -->

## Description
<!-- List of detailed changes -->

## Checklist
- [ ] Breaking changes are clearly marked as such in the PR description
and changelog
- [ ] New behavior is reflected in tests
- [ ] [The specification](https://github.com/FuelLabs/fuel-specs/)
matches the implemented behavior (link update PR if changes are needed)

### Before requesting review
- [ ] I have reviewed the code myself
- [ ] I have created follow-up issues caused by this PR and linked them
here

### After merging, notify other teams

[Add or remove entries as needed]

- [ ] [Rust SDK](https://github.com/FuelLabs/fuels-rs/)
- [ ] [Sway compiler](https://github.com/FuelLabs/sway/)
- [ ] [Platform
documentation](https://github.com/FuelLabs/devrel-requests/issues/new?assignees=&labels=new+request&projects=&template=NEW-REQUEST.yml&title=%5BRequest%5D%3A+)
(for out-of-organization contributors, the person merging the PR will do
this)
- [ ] Someone else?

---------

Co-authored-by: Mårten Blankfors <[email protected]>
Co-authored-by: green <[email protected]>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants