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

Implement force transaction inclusion #1626

Closed
xgreenx opened this issue Jan 24, 2024 · 0 comments · Fixed by #1787
Closed

Implement force transaction inclusion #1626

xgreenx opened this issue Jan 24, 2024 · 0 comments · Fixed by #1787
Assignees
Labels
epic An epic is a high-level master issue for large pieces of work.

Comments

@xgreenx
Copy link
Collaborator

xgreenx commented Jan 24, 2024

https://www.notion.so/fuellabs/Forced-Transaction-Inclusion-FTI-b7c6391efa1646fb9d96f939adf78342

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 xgreenx changed the title Force transaction inclusion Implement force transaction inclusion Feb 1, 2024
@xgreenx 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
Labels
epic An epic is a high-level master issue for large pieces of work.
Projects
None yet
Development

Successfully merging a pull request may close this issue.

2 participants