-
Notifications
You must be signed in to change notification settings - Fork 248
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Add contract creation allow lists to EVM domains #3350
Conversation
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
#[pallet::storage] | ||
pub(super) type ContractCreationAllowedBy<T: Config> = | ||
StorageValue<_, PermissionedActionAllowedBy<T::AccountId>, OptionQuery>; | ||
|
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
An alternative would be change the default return value of is_allowed_to_create_contracts
to true
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
This comment was marked as resolved.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Left some questions.
there are a lot of changes between the commits that is very confusing. Not a blocker for this PR
origin: OriginFor<T>, | ||
contract_creation_allowed_by: PermissionedActionAllowedBy<T::AccountId>, | ||
) -> DispatchResult { | ||
ensure_root(origin)?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is fine to expect as sudo but ideally a domain owner should be able to update this allowlist instead of sudo so that Consensus sudo is not always required and is also a longer process.
Currently domain owner can update the XDM allow list that is initiated from the Consensus chain so I see no reason why the same domain owner should not be able to update this list as to who can create contracts as well.
Thoughts @dariolina
Apologies for not bringing this earlier.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don’t know how to implement that, can you show me an example?
Edit: an example is in pallet-messenger
. We'll add this in the next PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
there are a lot of changes between the commits that is very confusing. Not a blocker for this PR
I'm happy to squash the commits if that would help, but I've just got feedback in another PR that I squashed too much. So can you be more specific?
(Or we can leave it as it is if it's not a blocker.)
origin: OriginFor<T>, | ||
contract_creation_allowed_by: PermissionedActionAllowedBy<T::AccountId>, | ||
) -> DispatchResult { | ||
ensure_root(origin)?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I don’t know how to implement that, can you show me an example?
Edit: an example is in pallet-messenger
. We'll add this in the next PR.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
The changes make sense to me overall just one nit, and thanks for the refactoring and testing infra!
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
This is ready for another review.
I wasn't able to squash some commits, because they were different kinds of changes.
I still haven't set auto-merge, because I'm not sure where we're up to with the other Taurus deployments or migrations.
Edit: here is the diff since the last review:
https://github.com/autonomys/subspace/compare/c013f78b0fd9c328373ee23284b1fffb4768c45c..ee8c6466edb8c79fc659e7b7f29cee896be2126a
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Make sense!
Thank you for being patient
I believe we are missing migrations for the structures
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
left one minor suggestion
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
ignore the previous migrations suggestions.
I see a new PR for that to taurus specifically.
How to review this PR
This PR is the second in a series of PRs which add "private EVM" functionality to subspace. The accompanying spec PR is subspace/protocol-specs#55 and user documentation is TODO.
The first PR in the series is #3359, it moves some test code around, and makes minor fixes.
The third PR in the series is #3360, it applies these changes and a storage migration to the Taurus runtime. (This storage isn't currently deployed on mainnet, so a migration isn't needed there.)
What it does
This PR adds a pallet which filters ethereum contract creation using an allow list. The allow list can be updated by the domain sudo account.
By default, all accounts can create contracts, to maintain compatibility with existing EVM domains. But the chainspec can be configured with an initial allow list of accounts. For our "private" EVM, that will be the domain sudo.
Close #3344.
This PR doesn't do a dynamic check for the domain sudo inside the pallet or runtime. We decided that isn't needed, because we can add the sudo account in the chainspec, or they can add themselves to the list using the (sudo) call provided by the pallet.
Part of #3353.
Other Changes
This PR makes it easier to add further code which:
EvmOnchainStateApi
runtime API, and contract address calculation functionIt also simplifies some existing code which was doing those things.
Bug Fixes
Fixes some transfer prevention extension code, which recursed through
pallet-utility
calls to use an iterator loop instead. The calls are checked in the same order, but references to the "Call stack" are stored on the heap instead. This avoids stack overflow for deeply nested calls.Fixes some bugs in test-only code which made it harder to use.
TODOs
Code contributor checklist: