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 GM::GetVerifyingPredicate metadata instr #174

Merged
merged 3 commits into from
Jul 27, 2022

Conversation

vlopes11
Copy link
Contributor

The context of the execution should contain more info such as the index
of the current predicate so we decouple that from the vm initialization.

Also, its worthy to create a type that will encapsulate the behavior of
the runtime predicates since it needs to store not only the program to
be executed - so it can't be represented just as a memory slice - but
the original input index that created the predicate.

The input index is not required for the predicate execution since the
program memory offset is a constant function of the consensus
parameters, but it might be consumed by the user - as in the specs.

The context of the execution should contain more info such as the index
of the current predicate so we decouple that from the vm initialization.

Also, its worthy to create a type that will encapsulate the behavior of
the runtime predicates since it needs to store not only the program to
be executed - so it can't be represented just as a memory slice - but
the original input index that created the predicate.

The input index is not required for the predicate execution since the
program memory offset is a constant function of the consensus
parameters, but it might be consumed by the user - as in the specs.
@vlopes11 vlopes11 added the enhancement New feature or request label Jul 21, 2022
@vlopes11 vlopes11 self-assigned this Jul 21, 2022
@@ -13,11 +13,10 @@ use std::io;

impl<S> Interpreter<S> {
/// Initialize the VM with a given transaction
pub fn init(&mut self, predicate: bool, block_height: u32, tx: CheckedTransaction) -> Result<(), InterpreterError> {
pub fn init(&mut self, block_height: u32, tx: CheckedTransaction) -> Result<(), InterpreterError> {
Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Block height seems to be something that belongs to the context, and not to VM initialization. Should we tackle that in this PR?

Copy link
Member

@Voxelot Voxelot Jul 21, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

It seems like we shouldn't be setting block_height on the VM at all, especially now that we moved the transaction validation logic out of VM initialization I don't think it would be used. The block height opcode should be able to just fetch it from interpreter storage as needed.

The tricky part is that we'll need to make sure the interpreter storage returns the height of the currently executing block before it gets saved, rather than the height of the previously executed block.

ref: #156

Since we already have a separate issue filed for removing block_height, I think it's fine to leave it as is on this PR since it'll be easier to remove than if it got bundled in with context.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copy link
Contributor Author

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

The previous implementation of the context isn't good. Also, the block height belongs to the context and should be fetched from the storage a single time (on script init since block height isn't valid for predicates).

We shouldn't fetch the block height from the storage during runtime because this is a fallible implementation from the storage:

2f781e3

let block_height = self.storage.block_height().map_err(InterpreterError::from_io)?;

self.init(predicate, block_height, tx)
self.context = Context::Script;
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

[nit] Should we also have a Create context?

Copy link
Contributor Author

@vlopes11 vlopes11 Jul 22, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Its a bit odd indeed that we don't have a Create context, but that is because it will never happen at runtime. For a Create tx, the only executable code is the predicates, and these will be Predicate context

@vlopes11 vlopes11 requested a review from Voxelot July 22, 2022 10:24
The context getter of the interpreter should not have underlying logic
since this increases the magic box effect of the implementation.
Instead, the context should be update whenever the frame pointer
register is updated; depending on the current context.
/// Initialize the VM for a predicate context
pub fn init_predicate(&mut self, tx: CheckedTransaction) -> bool {
self.context = Context::Predicate {
program: Default::default(),
Copy link
Member

@Voxelot Voxelot Jul 26, 2022

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

why use a default value here instead of actually setting the real predicate from an idx?

@vlopes11 vlopes11 merged commit d616615 into master Jul 27, 2022
@vlopes11 vlopes11 deleted the vlopes11/metadata-get-predicate-idx branch July 27, 2022 06:32
ControlCplusControlV pushed a commit that referenced this pull request Dec 1, 2022
@mitchmindtree mitchmindtree added the fuel-vm Related to the `fuel-vm` crate. label Dec 9, 2022
xgreenx pushed a commit that referenced this pull request Dec 20, 2022
xgreenx pushed a commit that referenced this pull request Dec 20, 2022
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
enhancement New feature or request fuel-vm Related to the `fuel-vm` crate.
Projects
Status: Done
Development

Successfully merging this pull request may close these issues.

3 participants