If you just want to clone the repo and quickly have a couple local proof of authority networks (Geth/Clique and Parity/Aura) running with the contracts deployed then you can just clone the repo and run:
docker-compose -f source/support/test/integration/docker-compose-[geth/parity].yml up --build --force-recreate
- Parity HTTP RPC will be available on localhost port
- Geth HTTP RPC will be available on localhost port
- An abundant supply of ETH is available using the private key
- The log output will let you know what the address of the various Augur contracts are.
You need system-wide installations of Python 2.7.6+, Node.js 8+, and Solidity 0.4.20. (Or Docker; see below.) Install the dependencies:
npm install npxnpm installpip install -r requirements.txt
Solidity contract deployment is handled by
ContractDeployer.ts and the wrapper programs located in
source/deployment. This deployment framework allows for incremental deploys of contracts to a given controller (specified via a configuration option). This allows us to deploy new contracts without touching the controller, effectively upgrading the deployed system in-place.
- source/libraries/ContractCompiler.ts - All logic for compiling contracts, generating ABI
- source/libraries/ContractDeployer.ts - All logic for uploading, initializing, and whitelisting contracts, generating addresses and block number outputs.
- source/libraries/NetworkConfiguration.ts -
- source/deployment/compileAndDeploy.ts - Compiles and Uploads contracts in one step. Useful for integration testing.
- source/deployment/compiledContracts.ts - Compile contract source (from source/contracts) and output contracts.json and abi.json. Outputs to output/contracts or CONTRACTS_OUTPUT_ROOT if defined.
- source/deployment/deployNetworks.ts - Application that can upload / upgrade all contracts, reads contracts from CONTRACTS_OUTPUT_ROOT, and uses a named network configuration to connect to an ethereum node. The resulting contract addresses are stored in output/contracts or ARTIFACT_OUTPUT_ROOT if defined.
The tests directory (augur-core/tests) contain tests and test fixtures to test the various functionalities present in Augur, including trading, reporting, and wcl tests.
- conftest.py -- contains the class ContractFixture, which deals with caching compiled contracts, signatures, etc. as well as resetting the blockchain before each test.
- delegation_sandbox.py -- tests the delegator contract.
- sandbox.py -- used for testing miscellaneous Solidity behaviors
- reporting -- contains tests for reporting purposes.
- trading -- contains tests for trading purposes.
- solidity_test_helpers -- small contracts to help run tests.
- test_controller.py -- tests controller functionalities.
- test_mutex.py -- tests mutex functionalities.
- test_helpers.py -- tests the controller, safeMath, and assertNoValue macros.
- test_legacyRep.py -- tests for legacyRepToken's functionalities.
- utils.py -- contains useful functions for testing, such as conversion between different data types.
- wcl-in-python.py -- contains functions for making and taking various types of bids.
- wcl.txt -- explains tests for the various situations when filling a bid and filling an ask.
Use pytest to run Augur's test suite:
This executes all the tests. To run a test individually, run the following:
pytest path/to/test_file.py -k 'name_of_test'
When writing tests, it is highly recommended to make use of the ContractFixtures class for "placeholder" variables. Python's unit testing framework comes handy here; encapsulate tests within functions that start with "test_", and use
assert statements when testing for certain values. Parameterized tests are recommended as well to test various possibilities and edge cases.
To generate a coverage report simply run the command:
node --max-old-space-size=12288 source/tools/generateCoverageReport.js
The results will be displayed on the command line and a much richer HTML output will be generated in the
coverage folder of the project.
Make sure you actually have enough memory to run the command above. The coverage tool being used will pull a massive file into memory to generate the report and will fail with an OOM exception if not enough is available. Since tests take about 40 minutes to run with coverage enabled this will be a sad event.
augur-core can optionally be built, run, and tested using Docker. A number of Docker commands are included as npm scripts, which map to the non-Dockerized versions where this makes sense. Docker commands beginning with
docker:run execute the command within the Docker image. Docker commands without
docker:test) first build the image, then execute
npm run docker:build
# With a pre-built imagenpm run docker:run:test:unit:all# Build and run all unit tests and integration testsnpm run docker:test# Build and run just integration tests (using Geth)npm run docker:run:test:integration:geth# Build and run just integration tests (using Parity)npm run docker:run:test:integration:parity
For quicker iteration on integration tests follow the instructions here to run tests locally against a node running in docker:
If the contracts aren't changing, after the first run you can add "AUGUR_CONTROLLER_ADDRESS": "..." to the env and it will even skip re-uploading the contracts with each run of the integration tests.
Install Oyente locally. This can be done by following the instructions on their GitHub: https://github.com/melonproject/oyente
Run the oyente script with this command to get the output for all contracts:
python source/tools/runOyente.py -p
Source code organization
Augur's smart contracts are organized into four folders:
source/contracts/factories: Constructors for universes, markets, fee windows, etc.
source/contracts/libraries: Data structures used elsewhere in the source code.
source/contracts/reporting: Creation and manipulation of universes, markets, fee windows, and reporting-related tokens.
source/contracts/trading: Functions to create, view, and fill orders, to issue and close out complete sets of shares, and for traders to claim proceeds after markets are closed.
General information about Augur
EVM numbers are always integers
There are no floating-point numbers in the EVM, only integers. Therefore, Ether and Reputation values in contracts are always represented in units of wei (i.e., indivisible units of 10^-18 Ether or 10^-18 Reputation).
Worst-case-loss escrow for trades
Verifying the REP contract on the main Ethereum network
On Augur, each Universe has a Reputation Token Contract that is created by the Universe, which is uniquely associated with that Universe. The Reputation token contract is technically a "Delegator" Contract, which simply calls through to its delegation target contract, the Verified Reputation Token Contract.
You can verify that the REP token contract is a
Delegator by verifying the
ReputationTokenFactory is what created the contract.
To do this, go to the new REP contract 0x1985365e9f78359a9b6ad760e32412f4a445e862. Then go to its creator 0x8fee0da3a35f612f88fb58d7028d14c7d99a3643. Then click on internal transactions and you'll see this 0x44c09f8eeff886723b79890e14743192a8c8d8a8eac158ed17600c94e502cce8 transaction which creates the initial universe.
Then click on internal on that page and you'll see here that that contract created the REP token contract.
You can verify that the REP Token contract is delegating to the verified REP token contract target by calling lookup on the Controller with the string