🎨 Refactor: Decouple GitConsensus to only commit/tag state, use seperate contracts for rewards

[mattstam]

Logic in GitConsensus could be seen as changeable (e.g. to do mint() vs. transfer() functionality in #29), which really is a no-go for immutable contracts. Any upgrades to the GitConsensus contract would wipe all state (previously saved commits/tags).

To avoid this, we should keep the GitConsensus ridiculously simple.

From

IGitConsensus.sol:

addCommit(CommitData commit) 
addRelease(TagData tag, bytes20[] hashes, uint256[] values) 
hashAddr(bytes20 hash) 
hashExists(bytes20 hash) 

* builds on the assumption of #36

 

to

IGitConsensus.sol:

addCommit(CommitData commit) 
addTag(TagData tag) 
hashAddr(bytes20 hash) 
hashExists(bytes20 hash) 

IDistribution.sol:

rewardByMint(address tokenAddr, bytes20[] hashes, uint256[] values) 
rewardByTransfer(address tokenAddr, bytes20[] hashes, uint256[] values) 
// some other rewardance mechanisms, potentially coupled with tags/releases

 

It is hard imagine a scenario is which the new IGitConsensus.sol would need to be updated now (basically just setters & getters that mirror what Git does). By isolating GitConsensus, we can create and update other logical contracts while leaving the state of this consistent, which is really important because we don’t want to remove saved hash state.

This is also going to make it easier to propose just GitConsensus interface as an future EIP / ERC to the Ethereum board, which eventually we want to do with either method.