Agreed that installPath is not the most intuitive design. If I’m remembering correctly, we went with this design in order to preserve the rule that the key in the sources object can be any unique string - rather than the filepath itself. You’re correct, this is important for compatibility with the solidity compiler output, which was one of the primary design goals for v3. Thanks for bringing this up though, it’s really helpful feedback. I’ll add a note to the spec, but personally, I’m not convinced that it’s worth changing the spec. If you or somebody else feels strongly about this, I’m happy to give it further consideration.
1 Like
The 0x prefix is used to identify that the following string is hex encoded. It’s fairly standard encoding practice across the ethereum ecosystem. The spec and tooling supports unprefixed hex-strings, but specifies that all hex-strings should use the 0x prefix for consistency. Personally, I always use 0x prefixed hex-strings and rarely see unprefixed hex-strings in the wild. The spec also specifies that the package must use utf-8 encoding. Tooling shouldn’t have a problem decoding hex-strings according to the spec, all that’s needed is a simple check whether or not hex-string fields have the 0x prefix, and then handle those fields accordingly. I’m not eager to change the hex-string encoding conventions of the spec at this point, especially since it’s in-line with broad standard practice in the community and I’ve never heard concerns from tooling developers or users.
I’d be quite happy with a note added to the spec. I understand not changing the spec itself at this point in the process. Thank you very much for your consideration on my feedback!
Bouncycastle and apache commons (commons-codec) both barf on 0x (rightly, in my opinion). Seems strange that ethereum would require a bespoke implementation of hexadecimal decoding.
I do know that cryptographic hashes are by convention never prefixed with 0x. So keccak256 fields are violating that convention.