-
Notifications
You must be signed in to change notification settings - Fork 2.8k
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
Implement force transaction inclusion #1626
Labels
epic
An epic is a high-level master issue for large pieces of work.
Comments
xgreenx
added a commit
that referenced
this issue
Jan 30, 2024
It is preparation for the #1568. The changes make relayer storage independent from the executor storage. Before, the relayer and executor shared write ownership to the `Messages` table. The relayer was inserting new messages, and the executor was removing them. With this change, only the executor modifies the `Messages` table(inserts and removes messages). The relayer has its own new `History` table, that stores all events from the DA layer per each height. This change also makes the insertion of upcoming events from DA as part of the state transition, allowing in the future handle [force transaction inclusion](#1626). The change: - Adds blanket implementation for the `VmStorageRequirements` since the executor requires access to the `FuelBlocks` table, and we can inherit this implementation. - Adds new tests for the executor that verifies fetching data from the relayer. - Introduces a new general `Event` type for messages and forced transactions (in the future).
xgreenx
changed the title
Force transaction inclusion
Implement force transaction inclusion
Feb 1, 2024
xgreenx
added
the
epic
An epic is a high-level master issue for large pieces of work.
label
Feb 4, 2024
xgreenx
pushed a commit
that referenced
this issue
Apr 13, 2024
Closes #1626 todo: tests / requirements - - [x] query the status of failed forced transactions - [x] prevent non-chargeable txs from being included - [x] handle duplicate relayed txs ids (what should gql api report if there are duplicate FTIs?) - ~NOTE: The current solution is each duplicate gets added to the `skipped_transactions` for the block. We might want to find a different solution if UX is bad--but it's _findable_ at least currently.~ Edit: We are now reporting duplicate txs just like any other execution error for relayed txs. Since they will all have unique nonces in practice, all of their ids will be unique. - [x] ensure that skipped fti's due to invalid state (ie. missing utxo inputs) have their status reported - [x] ensure that sentry nodes also include the status of failed FTIs without failing the processing of the block - [x] ensure users aren't double charged for gas payed on l1 --------- Co-authored-by: mitchell <james.mitchell.turner@gmail.com>
crypto523
added a commit
to crypto523/fuel-core
that referenced
this issue
Oct 7, 2024
It is preparation for the FuelLabs/fuel-core#1568. The changes make relayer storage independent from the executor storage. Before, the relayer and executor shared write ownership to the `Messages` table. The relayer was inserting new messages, and the executor was removing them. With this change, only the executor modifies the `Messages` table(inserts and removes messages). The relayer has its own new `History` table, that stores all events from the DA layer per each height. This change also makes the insertion of upcoming events from DA as part of the state transition, allowing in the future handle [force transaction inclusion](FuelLabs/fuel-core#1626). The change: - Adds blanket implementation for the `VmStorageRequirements` since the executor requires access to the `FuelBlocks` table, and we can inherit this implementation. - Adds new tests for the executor that verifies fetching data from the relayer. - Introduces a new general `Event` type for messages and forced transactions (in the future).
crypto523
added a commit
to crypto523/fuel-core
that referenced
this issue
Oct 7, 2024
Closes FuelLabs/fuel-core#1626 todo: tests / requirements - - [x] query the status of failed forced transactions - [x] prevent non-chargeable txs from being included - [x] handle duplicate relayed txs ids (what should gql api report if there are duplicate FTIs?) - ~NOTE: The current solution is each duplicate gets added to the `skipped_transactions` for the block. We might want to find a different solution if UX is bad--but it's _findable_ at least currently.~ Edit: We are now reporting duplicate txs just like any other execution error for relayed txs. Since they will all have unique nonces in practice, all of their ids will be unique. - [x] ensure that skipped fti's due to invalid state (ie. missing utxo inputs) have their status reported - [x] ensure that sentry nodes also include the status of failed FTIs without failing the processing of the block - [x] ensure users aren't double charged for gas payed on l1 --------- Co-authored-by: mitchell <james.mitchell.turner@gmail.com>
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
https://www.notion.so/fuellabs/Forced-Transaction-Inclusion-FTI-b7c6391efa1646fb9d96f939adf78342
The text was updated successfully, but these errors were encountered: