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 😃