Mechanism for implementing code-level protocol upgrades with backward compatibility

[csuwildcat]

No description provided.

[OR13]

I believe there is some linkage between blockchainTime and supported crypto / hashing algorithms.

It sounds like maybe this ticket is asking for official client version binding. There is no way a client that does not support new hash algorithm can process new DIDs, nor a new client old ones if an old hash algorithm is dropped.

There is this ticket for defining protocol version: #265

We've thought about this a lot with element, in particular, can we support a great UX on top of multiple versions of the sidetree protocol?

The pruning / dos change being a good example of a major change. We'd like to be able to support ongoing use and the upgraded version.

Protocol version could be embedded in the anchorFile.

Old clients could ignore new protocol version anchorFiles, but the state they built should probably not be trusted.

I think we need to test a series of client upgrades in integration tests, where the structure of files changes. Probably a blocking dependency for #266

[csuwildcat]

The way Henry is implementing this assumes that upgrades to the protocol that result in breaking/forking changes require nodes to run the upgraded version to remain in the same 'network'. There are upgrades that can be optional, if they only are optimizations to existing protocol rules that do not result in forking conditions, but anything that changes the state of what a node sees as valid DIDs, ops, and resulting DID Document state will require network-wide upgrades.

[thehenrytsai]

Implemented.