Currently, the IDL is deployed to a deterministic address on chain, regardless of the version.
This is problematic for some use cases like wallet/explorer type applications where the app doesn't know the program it's inspecting (and so it uses the Program.at api to automatically fetch the IDL and deserialize transactions). On an upgrade, this means that one might not be able to deserialize transactions to old versions of the program (unless it has the old IDL lying around, which is not the case for apps that assume nothing about the programs it's communicating with).
A potential solution would need three changes:
Add a version number to the IDL account's "seeds", so that the address changes on upgrade, allowing anyone to get any version of the IDL. This would have to match the version inside the idl itself.
Add versions into anchor instruction data, e.g. prepending the version to each instruction: <4-byte-version> || <8-byte-sighash> || borsh(instruction).
Anchor codegen would check the version before performing method dispatch.
Then, when looking at a transaction, one can simply look at the version number, calculate the versioned IDL address, and fetch it to decode.
(Note that none of this addresses versioning for account layouts. To support that, currently, one would have to add new account types and instructions to accommodate any breaking changes)
dzmitry-lahoda
commented
3 years ago
Currently, the IDL is deployed to a deterministic address on chain, regardless of the version.
This is problematic for some use cases like wallet/explorer type applications where the app doesn't know the program it's inspecting (and so it uses the
Program.atapi to automatically fetch the IDL and deserialize transactions). On an upgrade, this means that one might not be able to deserialize transactions to old versions of the program (unless it has the old IDL lying around, which is not the case for apps that assume nothing about the programs it's communicating with).A potential solution would need three changes:
<4-byte-version> || <8-byte-sighash> || borsh(instruction).Then, when looking at a transaction, one can simply look at the version number, calculate the versioned IDL address, and fetch it to decode.
(Note that none of this addresses versioning for account layouts. To support that, currently, one would have to add new account types and instructions to accommodate any breaking changes)