When executing the verify method, we only allow access to the Immutable Storage of the Principal Account.
(and of course, we're only talking about read-access since it's immutable data).
We'll implement the Self Spawn feature in the Simple Coin Integration #4.
When we execute the verify within the Self-Spawn context, we won't know whether the Principal will become active. It'll depend on whether the verify returns true or not (and later whether the ctor will run to its completion without panicking).
Therefore we want to have these rules implemented:
Non-Self Spawn
That is the Spawn we've today. When running Non-Self Spawn, the Principal Account already exists as an active Account.
In that case, the immutable_data given in the Spawn Transaction (see #469) should not be used when running the verify method (since it runs on behalf of the Principal).
That immutable_data will be stored for the newly spawned account, right before executing its ctor (and of course, assuming that the verify passed).
Self Spawn
Again, we don't want to implement that feature fully. Instead, it's the topic of Simple Iteration #4.
So right now, the code will consistently execute Non-Self Spawn, but it'll have some preparation work done for when we'll want to finish that feature (next iteration).
Implementation Proposal
To have more fine-grained control, I propose to add these Rust structs:
FuncKind - holding the kind of function that the Runtime will execute
TxKind - holding the Transaction kind (the TxKind::Spawn refers to the Non-Self Spawn)
FuncData - encapsulates the current FuncKind and TxKind and immutable_data
Lastly, it has an optional field named immutable. In practice, it'll hold the immutable_data supplied in the Spawn Transaction but only for Self-Spawn. So it's OK to assume that this value will always be None for now.
Important: We can discard the AccessMode struct in favor of the new FuncKind and TxKind.
Depends on: #469
When executing the
verify
method, we only allow access to theImmutable Storage
of thePrincipal Account
. (and of course, we're only talking about read-access since it's immutable data).We'll implement the
Self Spawn
feature in theSimple Coin Integration #4
. When we execute theverify
within theSelf-Spawn
context, we won't know whether thePrincipal
will become active. It'll depend on whether theverify
returnstrue
or not (and later whether thector
will run to its completion without panicking).Therefore we want to have these rules implemented:
Non-Self Spawn
That is the
Spawn
we've today. When runningNon-Self Spawn,
thePrincipal Account
already exists as an activeAccount
.In that case, the
immutable_data
given in theSpawn Transaction
(see #469) should not be used when running theverify
method (since it runs on behalf of thePrincipal
).That
immutable_data
will be stored for the newly spawned account, right before executing itsctor
(and of course, assuming that theverify
passed).Self Spawn
Again, we don't want to implement that feature fully. Instead, it's the topic of
Simple Iteration #4
. So right now, the code will consistently executeNon-Self Spawn,
but it'll have some preparation work done for when we'll want to finish that feature (next iteration).Implementation Proposal
To have more fine-grained control, I propose to add these Rust structs:
FuncKind
- holding the kind of function that theRuntime
will executeTxKind
- holding theTransaction
kind (theTxKind::Spawn
refers to theNon-Self Spawn
)FuncData
- encapsulates the currentFuncKind
andTxKind
andimmutable_data
Lastly, it has an optional field namedimmutable
. In practice, it'll hold theimmutable_data
supplied in theSpawn Transaction
but only forSelf-Spawn
. So it's OK to assume that this value will always beNone
for now.Important: We can discard the
AccessMode struct
in favor of the newFuncKind
andTxKind
.After having the
FuncEnv
equipped with the new functionality, we need to update the Storage host functions: https://github.com/spacemeshos/svm/blob/master/crates/runtime/src/vmcalls/storage.rsHere is a draft of how it should probably look like. The host functions dealing with
Blob
will probably haveread_blob
andwrite_blob
helpers.