What does harness mean?

what does harness mean?


Harness is a term we use to refer to additional solidity code we need to write to bypass things that aren’t reachable from within the spec.

There are several types of harnesses:

  1. One may change the original contract he/she verify to get access, for example changing modifiers from internal to public, adding a count var, a sum var, etc.
    This is the kind of harness that we try to avoid in all costs for obvious reasons, however sometimes it’s necessary and so we try to change/add/remove the least amount of code, and we always mention it in the report so that the limitation of our approximation/simplification will be clear.

  2. One may create a ContractHarness.sol file that inherits from the original contract. That in itself frequently allow to do most of what you’d like to do in the original code. Such harnesses usually contain getters to types that aren’t supported and wrappers to functions that require sending types that aren’t supported or that are internal (note that this is temporary. Allowing access to these types and functions are one of our top goal for the near future).

  3. The third type of what we call harness is for handling external function calls. Since calls to external functions (functions that are in another contract) are havocing[1] values as a default behavior, we often need to create dummy implementation of such contracts so that the original contract could operate in a deterministic and desired manner. Such examples can be contracts that call an external price oracle, a swap service, etc.

[1] havocing means the return value can take any value. Read more here.

We work hard on making harness a thing of the past as part of our building and improvement of the tool.