-
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
Use ref instead of owned Block
in validation
#1886
Conversation
options: ExecutionOptions, | ||
) -> ExecutorResult<Instance<InputData>> { | ||
// TODO: Can we avoid cloning the block? |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Yeah, you can have two types. One for serialization on our side and one for deserialization on the WASM side. On our side you can pass reference
// We have to return the same type here because if the input parsing fails it won't know if this | ||
// is a validation or production block. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Maybe instead of serializing ReturnType::V1(result)
in extern "C" fn execute
, we serialize some Result<ReturnType, Error>
?
That way we don't need the ReturnType
variant to return an Err
.
i.e. We can do something like:
enum ReturnType {
V1(V1ReturnType)
}
enum V1ReturnType {
Execute(ExecutionResult),
Validate(ValidationResult),
}
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We want to return an ExecutorResult
because we may change the error type later. We could add V2
that returns a validation result and name it Validation
instead of V2
=)
But I don't see any problems in returning ExecutionResult
with a block
type since we don't consume block
, and it doesn't hurt the performance.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Actually, it affects performance. We need to serialize and deserialize the block on the upgradeable executor side, so maybe we should add a new return variant. But let’s do it in a separate PR, we need to add an integration test for it to be sure that we did everything correct=)
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
## Version v0.27.0 ### Added - [#1898](#1898): Enforce increasing of the `Executor::VERSION` on each release. ### Changed - [#1906](#1906): Makes `cli::snapshot::Command` members public such that clients can create and execute snapshot commands programmatically. This enables snapshot execution in external programs, such as the regenesis test suite. - [#1891](#1891): Regenesis now preserves `FuelBlockMerkleData` and `FuelBlockMerkleMetadata` in the off-chain table. These tables are checked when querying message proofs. - [#1886](#1886): Use ref to `Block` in validation code - [#1876](#1876): Updated benchmark to include the worst scenario for `CROO` opcode. Also include consensus parameters in bench output. - [#1879](#1879): Return the old behaviour for the `discovery_works` test. - [#1848](#1848): Added `version` field to the `Block` and `BlockHeader` GraphQL entities. Added corresponding `version` field to the `Block` and `BlockHeader` client types in `fuel-core-client`. - [#1873](#1873): Separate dry runs from block production in executor code, remove `ExecutionKind` and `ExecutionType`, remove `thread_block_transaction` concept, remove `PartialBlockComponent` type, refactor away `inner` functions. - [#1900](#1900): Update the root README as `fuel-core run` no longer has `--chain` as an option. It has been replaced by `--snapshot`. #### Breaking - [#1894](#1894): Use testnet configuration for local testnet. - [#1894](#1894): Removed support for helm chart. - [#1910](#1910): `fuel-vm` upgraded to `0.50.0`. More information in the [changelog](https://github.com/FuelLabs/fuel-vm/releases/tag/v0.50.0). ## What's Changed * feat: Support block and header versions gql by @bvrooman in #1848 * Updated `croo` opcode benchmark to depend on the contract size by @xgreenx in #1876 * Return the old behaviour for the `discovery_works` test by @xgreenx in #1879 * Weekly `cargo update` by @github-actions in #1880 * Separate production from dry runs in executor & Cleanup all execution paths :) by @MitchTurner in #1873 * Use ref instead of owned `Block` in validation by @MitchTurner in #1886 * Weekly `cargo update` by @github-actions in #1893 * ci: fix typos programmatically by @sdankel in #1890 * feat: Preserve message proofs post-regenesis by @bvrooman in #1891 * chore: update README fuel-core run options by @K1-R1 in #1900 * Weekly `cargo update` by @github-actions in #1903 * chore: Make snapshot command members pub accessible by @bvrooman in #1906 * Use testnet configuration for local testnet by @xgreenx in #1894 * Enforce increasing of the `Executor::VERSION` on each release by @xgreenx in #1898 * Bumped the version of the `fuel-vm` to `0.50.0` by @xgreenx in #1910 ## New Contributors * @K1-R1 made their first contribution in #1900 **Full Changelog**: v0.26.0...v0.27.0
#1882
Checklist
Before requesting review
After merging, notify other teams
[Add or remove entries as needed]