This repository has been archived by the owner on Aug 14, 2023. It is now read-only.
Copy the Transaction
to the Wasm Instance Memory
#462
Labels
Depends on: #456 #457 #460 #461
As things stand now, the
Runtime
takes the relevantcalldata
piece of the transaction and it copies only it to the Wasm Instance Memory before running it.If the function to run is
verify
(svm_verify
if to be precise) then thecalldata
piece will be theverifydata
field given in theTransaction
svm/crates/runtime/src/runtime/runtime.rs
Line 655 in 6edb73d
If the function to run is the
ctor
for aSpawn Transaction
then thecalldata
will be thectordata
field given:svm/crates/runtime/src/runtime/runtime.rs
Line 53 in 6edb73d
maybe better to rename:
ctor_data
toctordata
Call Transaction
then thecalldata
should be thefuncdata
field given(see issue Rename
calldata
tofuncdata
#461)svm/crates/runtime/src/runtime/runtime.rs
Line 676 in 6edb73d
This issue wants to achieve two things:
calldata
separately since this data is already parts of theTransaction
(it's just that the field holding that data is contextual to the running code).Implementation Proposal
Update the
Call
struct (see also #458)Since this issue depends on #456 we should have now the binary transaction accessible within the
FuncEnv
.The
run
method in theRuntime
is a lower-level abstraction that will execute code.Each execution will end up calling this function for running:
svm/crates/runtime/src/runtime/runtime.rs
Line 104 in 6edb73d
It seems that if we'll update the
Call
struct (might have a different name by now - see #458)https://github.com/spacemeshos/svm/blob/6edb73de199fafce0953f82af061ca1090ff911c/crates/runtime/src/runtime/call.rs
to be like:
Since the
calldata
is held in thebinary Transaction
we can manage by just specifying that theCall
is for executing averify/ctor/call tx function
. If we decide to have alsoauthorize
then it'd be easy to adapt.Adapt how the
calldata
offsets are extractedTBD
The text was updated successfully, but these errors were encountered: