You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
We can consider moving the existing AccountBuilder behind the testing feature out and make it part of the non-testing interface. We can also check whether the inner AccountIdBuilder is truly necessary or if it can be replaced with something simpler.
In particular we want to be able to replace this pattern:
This is actually already working code using the existing builder.
Open Questions
Related to the AccountIdBuilder question we should decide whether to make the builder generic over Rng which is used for the AccountId build process as a source of randomness, or if an init_seed: [u8; 32] is sufficient (as in AccountId::get_account_seed. We might want to just pick a simple solution here for now, as Account ID structure updates #140 might change how we build AccountIds anyway, and this would be the proper time to revisit how to easily construct IDs.
When is this task done?
This task is done when we can build an Account using components in non-testing code with an AccountBuilder type.
We should ensure that, with the builder, it is not possible for users to build an Account using AccountCode and AccountStorage that does not match the type of the account. For example, if an AccountStorage was created from faucet components and thus has a reserved slot 0, then we should not be able to build a regular account from that storage. Note that this is possible using the above pattern that we want to replace since multiple calls are needed to build the full account.
Additional context
No response
The text was updated successfully, but these errors were encountered:
What should be done?
Add an
AccountBuilder
type that allows for easy and safe account creation.As an example, the interface might look like this, copied from #766 (comment):
And faucets (or any other account) could be created using the same interface:
How should it be done?
We can consider moving the existing
AccountBuilder
behind thetesting
feature out and make it part of the non-testing interface. We can also check whether the innerAccountIdBuilder
is truly necessary or if it can be replaced with something simpler.In particular we want to be able to replace this pattern:
with something like this:
This is actually already working code using the existing builder.
Open Questions
AccountIdBuilder
question we should decide whether to make the builder generic overRng
which is used for theAccountId
build process as a source of randomness, or if aninit_seed: [u8; 32]
is sufficient (as inAccountId::get_account_seed
. We might want to just pick a simple solution here for now, as Account ID structure updates #140 might change how we buildAccountId
s anyway, and this would be the proper time to revisit how to easily construct IDs.When is this task done?
This task is done when we can build an
Account
using components in non-testing code with anAccountBuilder
type.We should ensure that, with the builder, it is not possible for users to build an Account using
AccountCode
andAccountStorage
that does not match the type of the account. For example, if anAccountStorage
was created from faucet components and thus has a reserved slot 0, then we should not be able to build a regular account from that storage. Note that this is possible using the above pattern that we want to replace since multiple calls are needed to build the full account.Additional context
No response
The text was updated successfully, but these errors were encountered: