The env will point to a Wasm buffer containing the encoded Envelope (as returned from wasm_encode_envelope).
The msg will point to a Wasm buffer containing the encoded Message as returned from one of:
wasm_encode_spawn
wasm_encode_call
For Deploy, the Message is the binary data given by the SVM SDK toolchain.
That's why there's no wasm_encode_deploy.
@neysofu @avive, my recommendation is that the svm-codec-npm will introduce a method such as loadDeployTemplate that will ask for a file-path pointing to a binary Deploy Transaction.
Then, it will call wasm_alloc asking to allocate the Deploy Transaction size.
Once the JS code holds the Wasm buffer, it will call again, this time to wasm_buffer_data and copy Deploy Transaction to the Wasm Instance Memory.
Decode Transaction
This one is a bit more tricky. Probably better to split into a couple of methods:
Decode only the Envelope
First we'll have the wasm_extract_tx_envelope method:
It will return a Wasm buffer pointing only to the Envelope part (in its binary form).
Then a call to wasm_decode_envelope will return the Envelope in its JSON format.
Decode only the Message
Similary, we'll have the wasm_extract_tx_message method:
It will return a Wasm buffer pointing only to the Message part (in its binary form).
Then a call to wasm_decode_spawn or wasm_decode_call will return the decoded Message in a JSON format.
Notes
Don't forget to release Wasm Buffers by calling the wasm_free.
The Deploy Template is out of scope for the decoding part.
Depends on #458
This issue will extend the Wasm API of the
svm_codec.wasm
Consequently, the svm-codec-npm will have to be extended as wellOn the
Simple Coin #Iteration 2
, thesvm_codec.wasm
will be extended again to support theSignatures
appended to the end of the Transaction.@avive FYI
Extensions to be implemented:
Envelope
The input should be a JSON:
Envelope
Should return a JSON of the same schema as the input given to
wasm_encode_envelope
Transaction
env
will point to a Wasm buffer containing the encodedEnvelope
(as returned fromwasm_encode_envelope
).msg
will point to a Wasm buffer containing the encodedMessage
as returned from one of:wasm_encode_spawn
wasm_encode_call
Deploy
, theMessage
is the binary data given by the SVM SDK toolchain. That's why there's nowasm_encode_deploy
.@neysofu @avive, my recommendation is that the svm-codec-npm will introduce a method such as
loadDeployTemplate
that will ask for a file-path pointing to a binaryDeploy Transaction
.Then, it will call
wasm_alloc
asking to allocate theDeploy Transaction
size. Once the JS code holds the Wasm buffer, it will call again, this time towasm_buffer_data
and copyDeploy Transaction
to the Wasm Instance Memory.Transaction
This one is a bit more tricky. Probably better to split into a couple of methods:
Envelope
First we'll have the
wasm_extract_tx_envelope
method:It will return a Wasm buffer pointing only to the
Envelope
part (in its binary form). Then a call towasm_decode_envelope
will return theEnvelope
in its JSON format.Message
Similary, we'll have the
wasm_extract_tx_message
method:It will return a Wasm buffer pointing only to the
Message
part (in its binary form). Then a call towasm_decode_spawn
orwasm_decode_call
will return the decodedMessage
in a JSON format.Notes
wasm_free
.Deploy Template
is out of scope for the decoding part.