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 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 thesvm
namespace.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-ffi
sm_value
- this host function isn't implemented yet. It seems unrequired right now. It's a small task - just returning theamount
field out of theEnvelope
sm_balance
- I think we don't need to support that. It requires research whether we want that or not. If we implement afundable hook
logic, we could track ourselves each time anAccount
receives funding. And of course, when the running Account transfers coins to anotherAccount
, we know that.sm_principal
- Anyhow, it requires copying thePrincipal Address
of theEnvelope
to 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-codec
to get a transaction and give us back theoffset
of thetarget
within 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'sContext
info (i.e.,go-spacemesh
).sm_transfer
- so we've already got this one implemented. It's name issvm_transfer
and notsm_transfer
since it sits under thesvm
namespace.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 thesm
or any other external imports).