As you can see, the SDK expects part of the host functions to sit under the "sm" namespace when importing them.
This design is a relic of the times before moving the Global State to sit under the Rustland.
The Runtime doesn't expect any external functions imports as a dependency anymore with the new design.
It means that each host function used is intrinsic to SVM and sits under the svm namespace.
So we need to decide what to do with each of the current host functions obsolete definitions under svm-sdk-ffi
sm_value - this host function isn't implemented yet. It seems unrequired right now.
It's a small task - just returning the amount field out of the Envelope
sm_balance - I think we don't need to support that. It requires research whether we want that or not.
If we implement a fundable hook logic, we could track ourselves each time an Account receives funding. And of course, when the running Account transfers coins to another Account, we know that.
sm_principal - Anyhow, it requires copying the Principal Address of the Envelope to Memory starting at the function input parameter
sm_target - This seems also doesn't necessary at the moment.
However, the implementation should be very similar to this issue #441; we need the svm-codec to get a transaction and give us back the offset of the target within the transaction.
(it's relevant only for transactions of type Call, otherwise, we should panic).
sm_layer - Again, not sure if we need this right now. The implementation is easy since this data is given in the Node's Context info (i.e., go-spacemesh).
sm_transfer - so we've already got this one implemented. It's name is svm_transfer and not sm_transfer since it sits under the svm namespace.
Note
Each host function we'll decide to implement inside SVM should be renamed to be prefixed as svm_ and not sm_.
(as explained above - we no longer support the sm or any other external imports).
This PR refers to this piece of code: https://github.com/spacemeshos/svm/blob/6edb73de199fafce0953f82af061ca1090ff911c/crates/sdk-host-ffi/src/ext.rs#L47-L71
As you can see, the SDK expects part of the host functions to sit under the "sm" namespace when importing them. This design is a relic of the times before moving the
Global Stateto sit under the Rustland.The
Runtimedoesn't expect any external functions imports as a dependency anymore with the new design. It means that each host function used is intrinsic to SVM and sits under thesvmnamespace.Here is where we register the imports functions before running the Wasm code: https://github.com/spacemeshos/svm/blob/6edb73de199fafce0953f82af061ca1090ff911c/crates/runtime/src/runtime/runtime.rs#L298
So we need to decide what to do with each of the current host functions obsolete definitions under
svm-sdk-ffism_value- this host function isn't implemented yet. It seems unrequired right now. It's a small task - just returning theamountfield out of theEnvelopesm_balance- I think we don't need to support that. It requires research whether we want that or not. If we implement afundable hooklogic, we could track ourselves each time anAccountreceives funding. And of course, when the running Account transfers coins to anotherAccount, we know that.sm_principal- Anyhow, it requires copying thePrincipal Addressof theEnvelopeto Memory starting at the function input parametersm_target- This seems also doesn't necessary at the moment. However, the implementation should be very similar to this issue #441; we need thesvm-codecto get a transaction and give us back theoffsetof thetargetwithin the transaction. (it's relevant only for transactions of typeCall,otherwise, we should panic).sm_layer- Again, not sure if we need this right now. The implementation is easy since this data is given in the Node'sContextinfo (i.e.,go-spacemesh).sm_transfer- so we've already got this one implemented. It's name issvm_transferand notsm_transfersince it sits under thesvmnamespace.Note
Each host function we'll decide to implement inside SVM should be renamed to be prefixed as
svm_and notsm_. (as explained above - we no longer support thesmor any other external imports).