rht
commented
2 years ago IMO a protocol version should be assigned to a single hashchain, not a single revision. If you want to port an existing hashchain to a new protocol version, you simply turn the original hashchain last hash into the content of the first revision of a new hashchain that uses the newer protocol.
If Aqua Protocol provides a way to add value to data by anchoring it in time in space, losing the ability to verify that data because of inability to remain backward capabilities with the verification tools is increasing tx costs for verification.
As the solution would be to use an old verifier (software) which is compatible with the verification protocol version. This also means there is no way to mix data sets with different versions, forward facing. E.g.:
But this is obviously desirable as it
On a personal node, the reason that we don't have backwards capabilities, is the main reason why I did not use our solution more extensively for personal note-taking.
Therefore this is the proposal to upgrade the protocol and the current reference implementation to guarantee future backwards capabilities by abstracting the verification scheme out into the library which holds the recipe for the current version of the protocol. Where the protocol version acts as the index for the recipe. All elements of the recipe need to be implemented as stand alone functions and should be atomic so, we reduce size and complexity while having freedom to rearrange elements in future versions of the protocol.
This also requires a new data field within each revision. Which contains the version of the protocol. E.g. APv1.1 (Aqua Protocol Version 1.1).