You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
The Probe package allows turning on-chain data into Go types using protobuf. This requires the package knowing the possible types beforehand and including the potential Msg interface definitions in the app Codec.
Proper usage of proto types requires the application developer to keep old message protos around in a properly versioned way so that Nodes and RPC queriers can handle old (and potentially deprecated) types as well as new ones.
One danger of this is that some chain developers may not properly deprecate their old message types and instead just update the proto files, thus breaking interface unpacking for old blocks.
One way to get around this is to include the proto definitions for old types. However, due to Type URL usage, these would supersede the new definitions and the problem would just shift to newer blocks.
It may be possible to build a potential extension to Codec handling such that certain codecs can be applied to a particular block height (or set of blocks), allowing the application to switch to the proper type at runtime without crashing.
One way it could work is a map like:
varappCodecsByHeightmap[uint64]<CodecType>
where the application would choose which Codec to use by retrieving the Codec based on range.
The text was updated successfully, but these errors were encountered:
The Probe package allows turning on-chain data into Go types using protobuf. This requires the package knowing the possible types beforehand and including the potential Msg interface definitions in the app Codec.
Proper usage of proto types requires the application developer to keep old message protos around in a properly versioned way so that Nodes and RPC queriers can handle old (and potentially deprecated) types as well as new ones.
One danger of this is that some chain developers may not properly deprecate their old message types and instead just update the proto files, thus breaking interface unpacking for old blocks.
One way to get around this is to include the proto definitions for old types. However, due to Type URL usage, these would supersede the new definitions and the problem would just shift to newer blocks.
It may be possible to build a potential extension to Codec handling such that certain codecs can be applied to a particular block height (or set of blocks), allowing the application to switch to the proper type at runtime without crashing.
One way it could work is a map like:
where the application would choose which Codec to use by retrieving the Codec based on range.
The text was updated successfully, but these errors were encountered: