For solidity we generally follow the style guide as shown in the solidity documentation with some exceptions:
All variable name should be in snake case, just like in python. Function names on the other hand should be mixedCase. MixedCase is essentially like CamelCase but with the initial letter being a small letter. This helps us to easily determine which function calls are smart contract calls in the python code side.
function iDoSomething(uint awesome_argument) {
doSomethingElse();
}Calls into other contracts might call back into our contract. This causes problems when storage accesses and an external call interleave. For example,
check(storage[address])
other_contract.method()
storage[address] = new_valuepossibly has a bug, where an attacker can set up other_contract.method() so that it calls back into this piece of code.
Then, the check() still sees an old value.
- Solidity documentation usually has an answer somewhere.
- Also keep an eye of upcoming changes.
- Remix allows step-execute a transaction.
- (Not So) Smart Contracts contains examples of common vulnerabilities.
- Awesome Ethereum Security contains relevant links.
This repository follows the same guidelines as the Raiden Client, regarding the Python code used in tests and scripts: https://github.com/raiden-network/raiden/blob/master/CONTRIBUTING.md#coding-style.
- If you're fixing a bug or adding a feature, add an entry to CHANGELOG.md.
- If you've changed a Solidity source, run
make compile_contractsand add the resultingraiden_contracts/data/contracts.jsonin the PR. - If you're changing documentation only, add
[skip ci]in the commit message so Travis does not waste time.- But, if you've changed comments in a Solidity source, do not add
[skip ci]and let Travis check the hash of the source.
- But, if you've changed comments in a Solidity source, do not add
- Add type annotations (especially on function arguments).
Read our Test Guide
Currently, our setup is:
- for core contracts:
./raiden_contracts/data/source/raiden - for 3rd party services:
./raiden_contracts/data/source/services - libraries:
./raiden_contracts/data/source/lib - non-production test contracts:
./raiden_contracts/data/source/test
Update package constants with the new contract's name, events, gas requirements etc.
Note: gas requirements are currently calculated using ./raiden_contracts/tests/test_print_gas.py, so the contract needs to be added here. This is not optimal: raiden-network#16
- add a new file with the new contract fixture in ./raiden_contracts/tests/fixtures, to be used across tests and add that file to ./raiden_contracts/tests/fixtures/init.py
- read our Test Guide for how to add new tests for the contract
- make sure it's covered by our compilation tests
- add it to the deployment tests
We need to add the new contract to the precompiled data. If the new contract is located in one of the existing directories, then it will automatically be added. If a new contracts directory is created, then it must be added to the compilation process: https://github.com/raiden-network/raiden-contracts/blob/810ea24b61221f74939a732e6f20f20184039507/raiden_contracts/contract_manager.py#L250-L267
Make sure the new contract's precompiled data and deployment info is included in ./raiden_contracts/data, by adding the contract to the deployment process
- if it is a core contract, add it to deploy_raiden_contracts and to verify_deployed_contracts
- if it is a service contract, add it to deploy_service_contracts and to verify_deployed_service_contracts
- add it to the Etherscan verification script
Check if the deployment info file path still stands: https://github.com/raiden-network/raiden-contracts/blob/810ea24b61221f74939a732e6f20f20184039507/raiden_contracts/contract_manager.py#L270-L274
We need to make sure the contract and related data is part of the release process:
- update .bumpversion_contracts.cfg
- mention the addition in the CHANGELOG.md
- make sure the deployment and precompiled data for the new contract is contained in the MANIFEST.in referenced files.