About Breaking Changes

[mmtftr]

Proposal Description

As the core of the bridge protocol, most design decisions this library makes will likely be very very very difficult to change (if at all possible). Thus, we have to consider the design decisions we have made so far, the decisions we might want to change in the future, and how the change process would be done. This will likely take a lot of effort due to the overhead in all standardization efforts.

We should create a comprehensive plan to be executed before the mainnet release, that will at least ensure that:

• Any changes that we are likely to make in the future will be possible with a soft fork
• Our CI/CD processes are able to catch all known breaking changes. (unknown unknowns are the worst, but hopefully some approaches like fuzzing alongside property-based testing can help us catch most of them)
  • Some recommendations with automatic libraries: cargo-semver-checks for changes in publicly exposed API, versionize for versioned binary serialization, buf.build for protobuf/gRPC API compatibility, (TODO something that will detect breaking sqlx schema changes)
  • A comprehensive test suite with all known scenarios of our Bitcoin contract. (I'm not clear on how complete our current tests are)
  • A test suite that runs before/after versions of our codebase on PRs against each other. In other words, if branch A is pull requested to dev, then the test should run the verifier on A with the aggregator on dev and so on. At least a couple combinations must be tested with the above test suite.

[ceyhunsen]

Also #331 will be nice addition to this.