mirror of
https://github.com/pezkuwichain/revive-differential-tests.git
synced 2026-04-22 04:28:02 +00:00
Omar
0b97d7dc29
* Introduce a custom kitchensink network * fix formatting * Added `--dev` to `substrate-node` arguments. This commit adds the `--dev` argument to the `substrate-node` to allow the chain to keep advancing as time goes own. We have found that if this option is not added then the chain won't advance forward. * fix clippy warning * fix clippy warning * Fix function selector and argument encoding * Avoid extra buffer allocation * Remove reliance on the web3 crate * Update the async runtime with syntactic sugar. * Fix tests * Fix doc test * Give nodes a standard way to get their alloy provider * Add ability to get the chain_id from node * Get kitchensink provider to use kitchensink network * Use provider method in tests * Add support for getting the gas limit from the node * Add a way to get the coinbase address * Add a way to get the block difficulty from the node * Add a way to get block info from the node * Expose APIs for getting the info of a specific block * Add resolution logic for other matterlabs variables * Fix tests * Add comment on alternative solutions * Change kitchensink gas limit assertion * Remove un-needed profile config
revive-differential-tests
The revive differential testing framework allows to define smart contract tests in a declarative manner in order to compile and execute them against different Ethereum-compatible blockchain implmentations. This is useful to:
- Analyze observable differences in contract compilation and execution across different blockchain implementations, including contract storage, account balances, transaction output and emitted events on a per-transaction base.
- Collect and compare benchmark metrics such as code size, gas usage or transaction throughput per seconds (TPS) of different blockchain implementations.
- Ensure reproducible contract builds across multiple compiler implementations or multiple host platforms.
- Implement end-to-end regression tests for Ethereum-compatible smart contract stacks.
Declarative test format
For now, the format used to write tests is the matter-labs era compiler format. This allows us to re-use many tests from their corpora.
The retester utility
The retester helper utilty is used to run the tests. To get an idea of what retester can do, please consults its command line help:
cargo run -p revive-dt-core -- --help
For example, to run the complex Solidity tests, define a corpus structure as follows:
{
"name": "ML Solidity Complex",
"path": "/path/to/era-compiler-tests/solidity/complex"
}
Assuming this to be saved in a ml-solidity-complex.json file, the following command will try to compile and execute the tests found inside the corpus:
RUST_LOG=debug cargo r --release -p revive-dt-core -- --corpus ml-solidity-complex.json