You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Thus, the current verify code-generation is a stopgap since authors of Template will have to write their own verify.
Probably, the best thing will be to remove this stub and enforce each template to have svm_verify created.
I think that the elegant way will be to add a #[verify] decorator for such a method (similar to the #[ctor] and #[endpoint]) and let the compiler take care of generating svm_verify at the final Wasm.
Note: the compiler needs to enforce only one (and exactly one) method that could be annotated with the #[verify] attribute within a Template.
Write Wasm Manually
That is also a valid option, but it might be a bit harder but still feasible. For example, we can manually compose a Wasm file in its Text representation and convert a binary Wasm.
Then we can manually create a JSON for the Template Metadata (empty Data layout and pick a ctor).
Finally, we could stitch the pieces using the CLI.
Other
Once we have a working test, it should be easy to test an invalid svm_alloc method and other required SVM Template functions (more due to the Nonces Schemes).
The text was updated successfully, but these errors were encountered:
YaronWittenstein
changed the title
Testing a Spawn and Call transactions with an invalid verify function signature
Testing a Deploy transaction with an invalid verify function signature
Oct 21, 2021
Each valid
Template
under SVM needs to have thesvm_verify
method and it should have() -> (i32)
function signatureThis time we want to feed
Deploy
with an invalidsvm_verify
input.We'd expect
ValidateDeploy
to fail.There are two options to generate such an input:
Modify the SDK code-generation
The current SDK's code at the point of writing this issue generates an empty
verify.
https://github.com/spacemeshos/svm/blob/22fb1cf627d5c82d20c285744dd9ee708e9c7c08/crates/sdk-macros/src/template.rs#L283
Thus, the current
verify
code-generation is a stopgap since authors ofTemplate
will have to write their ownverify.
Probably, the best thing will be to remove this stub and enforce each template to have
svm_verify
created.I think that the elegant way will be to add a
#[verify]
decorator for such a method (similar to the#[ctor]
and#[endpoint]
) and let the compiler take care of generatingsvm_verify
at the final Wasm.Note: the compiler needs to enforce only one (and exactly one) method that could be annotated with the
#[verify]
attribute within aTemplate.
Write Wasm Manually
That is also a valid option, but it might be a bit harder but still feasible. For example, we can manually compose a Wasm file in its Text representation and convert a binary Wasm.
Then we can manually create a JSON for the Template Metadata (empty
Data
layout and pick actor
).Finally, we could stitch the pieces using the CLI.
Other
Once we have a working test, it should be easy to test an invalid
svm_alloc
method and other required SVM Template functions (more due to theNonces Schemes
).The text was updated successfully, but these errors were encountered: