Hey @energyburn, thanks for this!
What you talk about (whether spec or implementation should determine what the consensus rules are) was last being discussed in aug 2018, i.e. six months prior to mainnet. Your question made me dig quite a bit to find it, see here: Meeting notes: Governance, Aug 28 2018. There’s also the full gitter transcript you can browse here.
Relevant section:
3. Formal specification for Grin
- Discussion about approach for formal Grin spec for implementations to adhere to.
- Main options are the ETH approach (colored paper) vs BTC approach (where main software is canonical).
- Question is relevant as there’s already a Go implementation effort for Grin (albeit it appears to be dormant).
- Each approach has drawbacks, it will be a challenge to keep documentation up to date, and it can be quite opaque to interpret the reference implementation. Add to this that current state is in flux and changes rapidly.
- There’s already a documentation effort underway as part of https://github.com/mimblewimble/grin/blob/master/doc/toc.md , while not a formal coloured paper, it might act as an in between solution for now.
Decision
We will use TOC.md for the reference implementation spec for now. Anyone who wishes is happy to contribute. Once this is stable/polished enough, it can then be converted into a formal “coloured paper”.
Not that much has changed in the reasoning since then I think: Keeping a formal spec up to date is hard, and it’s not clear what happens when there are discrepancies. There are pros and cons with each approach. We’ve not felt comfortable doing a formal protocol spec yet, (but maybe this will change after HF4?). That said, if somebody wants to go about doing it, they are more than welcome to, preferably alongside ideas for how to keep that up to date and accurate.
Regarding the governance process of making protocol changes versus making changes to the software implementation, I’d argue that there’s already quite a degree of separation there: Consensus breaking changes require going through the RFC process. In contrast, releasing a new version and features of the node implementation (without consensus changes) takes a quick agreement amongst devs and can be turned around in days, see for example the recent discussion around version 4.1.0 on keybase.
How do you think we could improve further here?