Fix/sync-on-hash

[dvilelaf]

Proposed changes

The db size has grown a lot on Contribute. This PR implements changes so agents sync on the db hash instead of the db data.

Fixes

n/a

Types of changes

What types of changes does your code introduce? (A breaking change is a fix or feature that would cause existing functionality and APIs to not work as expected.)
Put an x in the box that applies

• Non-breaking fix (non-breaking change which fixes an issue)
• Breaking fix (breaking change which fixes an issue)
• Non-breaking feature (non-breaking change which adds functionality)
• Breaking feature (breaking change which adds functionality)
• Refactor (non-breaking change which changes implementation)
• Messy (mixture of the above - requires explanation!)

Checklist

Put an x in the boxes that apply.

• I have read the CONTRIBUTING doc
• I am making a pull request against the main branch (left side). Also you should start your branch off our main.
• Lint and unit tests pass locally with my changes
• I have added tests that prove my fix is effective or that my feature works
• I have locally run services that could be impacted and they do not present failures derived from my changes

Further comments

n/a

[Adamantios]

Let's open an issue to use the remote IPFS at some point to enable the agents to sync the data among them. Otherwise, if one stays back, then it cannot ever rejoin.

You could use some structure for the db instead of a dict in the future.

Try to avoid unnecessarily overriding the rounds' end_block in the future. It makes the code hard to read and maintain.

Try to split PRs in the future as it is hard to review huge PRs like this one which change too many things at once.

[dvilelaf]

Let's open an issue to use the remote IPFS at some point to enable the agents to sync the data among them. Otherwise, if one stays back, then it cannot ever rejoin.

You could use some structure for the db instead of a dict in the future.

Try to avoid unnecessarily overriding the rounds' end_block in the future. It makes the code hard to read and maintain.

Try to split PRs in the future as it is hard to review huge PRs like this one which change too many things at once.

#126