Contract whitelist for appchains

[tdelabro]

Goal

Some of the appchain will want to only offer a reduced set of usable smart contracts for users to use.
To do so we want to enable the chain developers to whitelist some contracts so that only those can be deployed.

Solutions

Whitelist at the declare level

In order to be deployed and executed, a contract must be declared before. If we only allow to declare a predefined list of contracts, those will be the only one declarable.
Problem: I can see a lot of usecase where the chain want only some contracts only be deployed once or only by some specific root users. This is not possible with this solution

Whitelist at the deploy level

There is two types of deployment in Starknet. The account deployment and the regular contracts deployments.
The account deployment txs can easily be filtered because their payload contains the has class_hash of the contract to be deployed.
The regular deploy in the other hand is done through invoke transactions. Which are super generic, their core input is the calldata field, which is just a vec of Felt that can be interpreted in any imaginable way by the Account executing the Tx. So there is no generic way to filter that, in a chain which allows for account diversity.

Whitelist in the BlockifierStateAdapter

One thing we can do tho is change our impl of <BlockifierStateAdapter as State>::set_class_hash_at so that it returns an error. The idea would be for BlockifierStateAdapter to be instanciated with a field containing the address of the account executing the tx, and to call a fn is_my_user_allowed_to_deploy_that_contract(ContractAddress, ClassHash) -> bool method and return an error if not. The transaction execution will stop instantly.

Whitelist the accounts

The chain maintainers can also opt for only allowing one (or a few) type of accounts to be deployed. This could allow them to indirectly control which contracts can be deployed. This can be done in two way:

1. Because they know the account internal impl, they can decode it's calldata in InvokeTx, filter and early return before even entering the Blockifier.
2. They can allow only for a modified version of Argent or Braavos account contract, that will query another smart contract (owned by root and only modifiable by them) in order to know if this account is allowed to deploy a specific contract.

Each of the tree solutions has it's pro an cons.

Implementation

Because this features drive us away from the canon Starknet impl, I think it should be hidden behind a feature flag.
The lib users will be free to combine different non-canon features for their own chain, by activating different set of those flags.
But because this is only an addition to the canon behavior, and because it will probably be used by multiple different appchains, it can live in the core madara repo.

What's next

We have to decide which solution, or solutions, we want to see implemented. Once done @ybensacq would like to take care of it. He has a great experience with Substrate and has done the research that lead to this discussion.

[EvolveArt]

I think we should go with the first option:

• Revert at the BlockifierStateAdapter level by looking in some root-defined class hashes vec

A few questions:

• how should admin operations go ? We might want to make sure the list of white listed class hashes corresponds to the current state. Hence there needs to be some upgrade process that happens whenever this list is change in the same fashion as runtime upgrades. You basically need to propagate the config changes to your chain's state.
• do we even need to differentiate between account contracts and other contracts ?

[tdelabro]

how should admin operations go ?

With the solution 1 it should be done at the substrate level. My implementation would be to add a new type in the pallet-straknet config, that implement a trait "DeploymentPermisionAuthority" which implement this method is_allowed_to_deploy(deployer: AccountAddress, contract: ClassHash). Then it's up for the runtime to decide which impl to use. It can be an harcoded list, ingoring the deployer; or another pallet that contains all this complex logic, can read from the starknet storage, be updated by some root substrate address or even runtime update.
With solution 2, it's kind of the same but as the starknet level, with a variety of smart contract possibly implementing this Interface. The only thing you have to manage in substrate is the liste of the class of the whitelisted account ClassHash. It can be a simple storage, with only root being able to modify it.

do we even need to differentiate between account contracts and other contracts ?

If we wanted to act at the extrinsic/transaction level, yes. There is two transaction that can deploy contracts. If we use solution 1, no, there is no difference. If we use solution 2 it's not relevant, the contracts should just be allowed to deploy it's own class hash and we will be fine.

Because the second solution is less substrate intensive, I would actually prefer this one. Everything is on starknet, every is proved, everything is charged. But because it's more starknet intensive, in involve the development of at least one new account contract, and then the multiple whitelisting logics in Cairo.
I having a substrate-simple solution that can easily be extended by anyone by writing Cairo is more realist and reusable than having the different appchain deal with substate pallet interoperability and runtime config.
Realistically all you need is to edit a lil bit Argent and Braavos and you are good. If you are building an appchain where you whitelist users contracts, I don't see you wanting a huge account diversity.