Allow whitleisting contract deployer

[girazoki]

This PR introduces two new config traits to pallet_evm, called CreateInnerOriginFilter and CreateOriginFilter. This allow you to filter who can create contracts, the first filter being through call(CREATE) and the second directly by CREATE.

If set to (), boh filters allow every account to call create, i.e., same situation as today.

We believe this could be a nice usecase for chains that want to embed EVM but want to whitelist who can deploy contracts.

I needed to PR evm also to bring some changes that are already in the master branch:: rust-ethereum/evm#312

Credit to @Agusrodri since this code is his

[conr2d]

I think this feature can be useful for some cases, but

• I don't believe the changes pointing to the user's fork of rust-ethereum/evm will be accepted.
• IMHO, it would be better if this feature is implemented in pallet-ethereum. (moreover, are the changes on evm mandatory for this feature?)

[girazoki]

I think this feature can be useful for some cases, but

• I don't believe the changes pointing to the user's fork of rust-ethereum/evm will be accepted.

The rust-ethereum/evm changes were merged to master, so I do not think there is much harm on updating the branch.

• IMHO, it would be better if this feature is implemented in pallet-ethereum. (moreover, are the changes on evm mandatory for this feature?)

Implementing the feature in pallet-ethereum(or pallet-evm) only covers cases where the contract deployment is directly done from the user. But they dont cover cases in which the contract deployment is done via another contract. We wanted to offer both possibilities, hence the reason to touch the EVM crate itself.

I think both are useful cases. One could argue that if the user-level deployment is controlled, then so is the low-level deployment, but with all precompiles and other features I think this might be challenging to achieve in reality

[albertov19]

I think this is a great feature that would greatly differentiate Parachains/Rollups/Appchains offered by Polkadot-SDK based chains compared to other rollup solutions.

One big problem about fully decentralized general purpose chains, like any rollup, is that the chain can be easily spammed and its storage bloated. We've seen this happening, a storage bloat attack performed by Xen Crypto on Moonbeam, BNB, Polygon, even Ethereum itself (but they actually paid a lot of money for it, trying to get value to its token, but it blew back).

These chains have a low gas cost to attract developers, but they are more prone to such attacks.

Whitelisting contract deployers allow deployments to be permissioned (by the team deploying the smart contract logic), but contract interaction to be permissionless. This way, a team launching their own chain for a game, can prevent a storage bloat attack, but still allow any user to interact with the game contracts 😃

[girazoki]

@sorpaas do you have an opinion for this?

[DanieleDiBenedetto]

Hi, we are looking into this feature as well for our project, and I have a question:
Wouldn't it be possible to leverage the OnCreate hook ? So one could create a pallet implementing the whitelisting and implementing this trait, and panicking when owner is not in the whitelist. Not super nice probably, but it could work without the need of modifying the evm pallet ?

[girazoki]

Hi, we are looking into this feature as well for our project, and I have a question: Wouldn't it be possible to leverage the OnCreate hook ? So one could create a pallet implementing the whitelisting and implementing this trait, and panicking when owner is not in the whitelist. Not super nice probably, but it could work without the need of modifying the evm pallet ?

That case will only cover deployments made from a user (EOA), which in theory should cover most cases. But it does not cover the case in which a smart contract deploys another smart contract (through evm opcode). Hence the reason to have 2 filters, CreateInnerOriginFilter for this last case, and CreateOriginFilter for the first.

I still have not gotten any feedback from repo maintainers though :(

[sorpaas]

@sorpaas do you have an opinion for this?

The change looks good. I still need to do a few things in rust-evm and then I'll merge this.

[girazoki]

@sorpaas do you have an opinion for this?

The change looks good. I still need to do a few things in rust-evm and then I'll merge this.

perfect, let me clean this up so that you can cleanly merge

[sorpaas]

Please change back the branch of evm and then we can merge.

[girazoki]

Please change back the branch of evm and then we can merge.

Done!