Dev/clean contracts and compiled files

[azurwastaken]

Pull Request type

Please add the labels corresponding to the type of changes your PR introduces:

• Build-related changes

What is the current behavior?

Resolves: #1379

What is the new behavior?

• Updated existing cairo 1 contract
• Created a script that compile all cairo 1 contract and put sierra and casm in genesis asset

Does this introduce a breaking change?

No

Other information

This PR is still incomplete. the goal is to submit to review the change i've done on cairo 1 contract and also to see if i going in the good way to solve this. Also I struggle to find which contract should be remove so if anyone can give me an hint

[apoorvsadana]

The script looks good but there are still a lot of duplicated contracts across the repo. For example, search for ERC20.json in the repo, there are multiple files. Ideally, we need to have a folder with all the non compiled Cairo contracts and your script which compiles them into a new folder. Then everywhere in the code, we can read from here. Is this what's expected @LucasLvy @tdelabro?

[tdelabro]

We don't have source code for Argent and openZepellin cairo1 account contract.
I think we should replace those

Talking about genesis-assets/ArgentAccountCairoOne and OpenZeppelinAccountCairoOne

[EvolveArt]

Good job on this @azurwastaken

After some internal discussion, this PR scope could be widen to truly clean everything.
As you can see right now we have cairo contracts in the cairo-contracts folder as well as in starknet-rpc-test/contracts. We also have multiple bash scripts to compile everything.

What we would want ideally is just one bash script that compiles both cairo 0 and cairo 1 contracts in the main cairo-contracts folder.

[azurwastaken]

Hello, I managed to adapt the script to compile everything. However i have this warning when compiling BraavosAccount.cairo, ArgentAccount.cairo and Openzeppelinaccount.cairo :

Warning:
the arguments of 'validate_deploy' are expected to start with:
'class_hash: felt, contract_address_salt: felt'
followed by the constructor's arguments (if exist). Found:
'class_hash: felt, salt: felt, publicKey: felt'.

Deploying this contract using DeployAccount transaction is not recommended and would probably fail.

I dont know if its important.

Also, I saw that in the old compile_all.py script, we take the feshly compiled json and change every offset in the entrypoint by type from plain int to hex. I would like to know if it matter or if we don't care.

Currently I output compiled files in a directory compiled_contract with two subfolders for cairo 0 and 1 as I don't really know where i should put them.

[tdelabro]

Warning:
the arguments of 'validate_deploy' are expected to start with:
'class_hash: felt, contract_address_salt: felt'
followed by the constructor's arguments (if exist). Found:
'class_hash: felt, salt: felt, publicKey: felt'.

It's probably due to us using old contracts. Those are cairo0 contracts?
As long as tests continue to pass we are happy.

Also, I saw that in the old compile_all.py script, we take the feshly compiled json and change every offset in the entrypoint by type from plain int to hex. I would like to know if it matters or if we don't care.

I have no idea why we did that. @apoorvsadana @EvolveArt ?

Currently I output compiled files in a directory compiled_contract with two subfolders for cairo 0 and 1 as I don't really know where i should put them.

Sound great

[azurwastaken]

Warning:
the arguments of 'validate_deploy' are expected to start with:
'class_hash: felt, contract_address_salt: felt'
followed by the constructor's arguments (if exist). Found:
'class_hash: felt, salt: felt, publicKey: felt'.

It's probably due to us using old contracts. Those are cairo0 contracts? As long as tests continue to pass we are happy.

Yes they are, how can I run test to check ?

[apoorvsadana]

Also, I saw that in the old compile_all.py script, we take the feshly compiled json and change every offset in the entrypoint by type from plain int to hex. I would like to know if it matters or if we don't care.

I have no idea why we did that. @apoorvsadana @EvolveArt ?

I am not sure as well, it might be a compiler version thing? But ya, as long as the test cases are passing we should be good.