ER. Contracts upgrades and updates. Bug fixing.

[roleengineer]

Bounty

Upgrade core contracts to the new solidity version. Find and fix bugs.

Scope

• Upgrade all the core contracts to the solidity version 0.8.4.
• Discover and fix the vulnerability in a ClaimFalsifier contract that gives ability for falsifiers to cheat.
• Adjust unit tests to cover the fixed bug case.
• Fix Challenger.ts small bugs.
• Implement timing logic.
• Add getter function to ClaimVerifier for Machine bytecode. Offchain-runner requires this bytecode and has no availability without this function.

Deliverables

• Upgraded and updated core contracts.
• Fixed vulnerability.

Funding Circle

General

Bounty Owner/Gardener

@roleengineer as EMO developer

Gain for the Role

Roadmap progress

Roles

bounty gardener: @roleengineer / 0 DAI bounty worker: @roleengineer / 80% bounty reviewer: @unknown / 20%

Gardener checklist

• [x] I have attached one of the size-S labels to this bounty
• [x] I have submitted this bounty via http://bounty.leapdao.org/viewform
• [x] I have added this bounty to bounty board here https://github.com/orgs/leapdao/projects/6

[roleengineer]

Found vulnerability in a core contracts. steps to reproduce the vulnerability:

1. prosecutor is able to call newDispute function with the node that is calculated from the following states:
   • first(0) leave is purely random 32bytes - that is it can be any seed that gives initialStateHash
   • next leaves can be the correct hashes of the correct states that Machine produces from the given seed.
2. go through challenge game iteration process.
3. when the Bottom is reached, there is no way to defend the claim, because firstDivergentStateHash become the initialStateHash (the path is 0), so there is no previous state that defendant can reveal.
4. prosecutor calls timeout function and wins any dispute and falsifies any claim.

[roleengineer]

two approaches to solve:

1. make impossible to open disputes with random initialStateHash: request new parameter for newDispute - leftProof and make the same calculations and requirements as it is implemented in 'reveal' function (for defendant). Pros: no need for defendants to spend time and tx fees for useless challenge games as it is explicit that falsifiers can't win the dispute (wrong initial state always gives wrong result). Cons: the tx cost of newDispute call will grow for every falsifier.

2. allow falsifiers to run such disputes and add another condition for defendants to win dispute, when the Bottom is reached and the path is 0. Pros: the newDispute tx is stable in a cost sense. Cons: allows to spam network and spend ETH for useless txs. Also clients implementations should be done with the thoughts that the game should be always profitable for a winner.

[roleengineer]

The second approach was chosen to solve the vulnerability.

[roleengineer]

solved https://github.com/leapdao/EthereumMachineOracle/pull/33/commits/39a574b184f970bd990c9bddcf9dd0ec1d0a0fbb