search

git-consensus / contracts

Converts the informal ownership structure of an open-source git project to a formal DAO, with token distribution mechanisms for contributors.
GNU General Public License v3.0
13 stars 0 forks source link

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

Open mattstam opened 2 years ago

mattstam commented 2 years ago

Logic in GitConsensus could be seen as changeable (e.g. to do mint() vs. transfer() functionality in https://github.com/git-consensus/contracts/issues/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 https://github.com/git-consensus/contracts/issues/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.