As detailed in the SVM Self-Spawn SMIP, we want to add a new flow of Accounts Spawning - the Self-Spawn.
There are two main stages:
Creating a new Stub Account (I prefer Pending Account or Inactive Account).
It should be done when running a Call Transaction (and not via running the ctor of a Spawn Transaction).
Executing a Spawn Transaction that will activate that pending Account.
The criterion of whether a Spawn Transaction will have the default flow or the Self-Spawn one determines whether or not the Principal Address of the transaction is active.
If it's, then it's a default Spawn. Otherwise, it must be in a Pending state, and the transaction will activate it.
In any case, if the Principal Account isn't found, then the transaction should be discarded.
One option is implementing a new dedicated host function named svm_account_create.
It will receive as input the Address of the new Account to create and its initial balance.
Computing the Address should be done separately.
Funding the new Pending Account will transfer coins from the current Target Account.
(of the currently executing Call Transaction) to the newly created Stub Account.
If there is already an Account (Stub or Active) with the given Address - the host function should panic.
fn account_create(env: &FuncEnv, addr_ptr: i32, initial_balance: i64) {
// Assert that we're not running the `ctor`
// ...
}
Why not adjust the svm_transfer host function?
It's possible to do so. The reason, I think, it's not ideal is for Gas Pricing.
Transferring coins between two existing Accounts should be priced differently than creating a new Account and funding it with its initial balance.
Since we want to give better pricing on compile-time (a requirement for the Fixed-Gas), we might better end up with a dedicated svm_account_create host function.
Of course, it is possible to adjust the svm_transfer to fall back to creating a new Stub Account when the destination account doesn't exist (the current code panics on such a case).
That said, in case we want to support a case where we don't know at compile-time whether the Account exists or not.
It seems we need to go for the svm_transfer adjusting path.
(the Gas Pricing will be less accurate, but that's the trade-off).
Depends on: #467
As detailed in the SVM Self-Spawn SMIP, we want to add a new flow of Accounts Spawning - the
Self-Spawn.
There are two main stages:
Creating a new
Stub Account
(I preferPending Account
orInactive Account
). It should be done when running aCall Transaction
(and not via running thector
of aSpawn Transaction
).Executing a
Spawn Transaction
that will activate that pending Account. The criterion of whether aSpawn Transaction
will have the default flow or theSelf-Spawn
one determines whether or not thePrincipal
Address of the transaction is active.If it's, then it's a default Spawn. Otherwise, it must be in a
Pending
state, and the transaction will activate it. In any case, if thePrincipal Account
isn't found, then the transaction should be discarded.One option is implementing a new dedicated host function named
svm_account_create
. It will receive as input theAddress
of the newAccount
to create and its initial balance.Computing the
Address
should be done separately.Funding the new
Pending
Account will transfer coins from the currentTarget Account.
(of the currently executingCall Transaction
) to the newly createdStub Account.
If there is already an
Account
(Stub
orActive
) with the givenAddress
- the host function should panic.Why not adjust the
svm_transfer
host function?It's possible to do so. The reason, I think, it's not ideal is for
Gas Pricing.
Transferring coins between two existingAccounts
should be priced differently than creating a newAccount
and funding it with its initial balance.Since we want to give better pricing on compile-time (a requirement for the Fixed-Gas), we might better end up with a dedicated
svm_account_create
host function.Of course, it is possible to adjust the
svm_transfer
to fall back to creating a newStub Account
when the destination account doesn't exist (the current code panics on such a case).That said, in case we want to support a case where we don't know at compile-time whether the
Account
exists or not. It seems we need to go for thesvm_transfer
adjusting path. (theGas Pricing
will be less accurate, but that's the trade-off).