Embed Build and Version into contracts #735
Comments
|
There's a sketch here of a rather generic set of entries we could use for this: stellar/stellar-xdr#49 Note that this meta is not the same as the env-meta. The env-meta is known to be something we want to be long lasting, and it is part of the protocol with well defined fields that the Host will use. This meta is in the user defined / application land, and not intended to be used by the network in anyway. |
leighmcculloch
changed the title
|
To support rebuilding contracts predictably we should also capture the version of Rust, and the host architecture and OS that it is built on. And anything else that causes a build to result in a different binary. cc @graydon Edit: Host OS and arch is probably unnecessary unless someone is using macros that behave differently on different arch. |
|
The xdr here can be used to store this information. |
|
Discussed this with @leighmcculloch and this should be targeted for V1. |
### What Add rust version and sdk version to contract meta automatically. Rustc version is stored in meta under the key `rsver`. SDK version is stored in meta under the key `rssdkver`. ``` Section `contractmetav0` (100 bytes): Length: 100 (0x64) bytes 0000: 00 00 00 00 00 00 00 05 72 73 76 65 72 00 00 00 ........rsver... 0010: 00 00 00 06 31 2e 37 30 2e 30 00 00 00 00 00 00 ....1.70.0...... 0020: 00 00 00 08 72 73 73 64 6b 76 65 72 00 00 00 34 ....rssdkver...4 0030: 30 2e 38 2e 34 23 32 62 33 30 65 34 37 33 36 36 0.8.4#2b30e47366 0040: 39 66 61 63 38 30 33 31 38 38 66 61 63 30 32 63 9fac803188fac02c 0050: 62 63 66 61 36 30 39 63 31 39 64 63 63 36 2d 64 bcfa609c19dcc6-d 0060: 69 72 74 79 irty ``` ### Why The rustc version is a primitive for future supporting reproducible builds. The SDK version is for debugging situations where incompatibilities arise across different versions, and for better understanding them. Close #735 --------- Co-authored-by: Graydon Hoare <graydon@pobox.com>
Months ago we talked about the possibility of embedding meta information, such as the version of SDK and Auth SDK into contracts. This issue is to debate that.
The main requirement that drove the initial intent of this was so that it would help us debug problems in contracts as we release new SDKS, new Envs, etc. We already get visibility into this to a degree with the env interface version that is embedded into built contracts in the 'env meta' entries.
So there's two time frames of uses:
Because of that second point if we implement this we should at a point close to pubnet launch consider removing this feature. It may have limited utility past that point.
This isn't urgent, but if we agree on implementing something like this, I'd like to get this into a near future release so we don't have too many contracts out there that we can't help people debug their version and state of why it isn't working.
cc @graydon
The text was updated successfully, but these errors were encountered: