ethPM V3 Specification Working Group

Just a heads up, if you’re not already attending the solidity online conference. There’s going to be an ethpm discussion tomorrow at 8:55 pm central european time. The conversation will revolve around ethpm devx and the v3 technical specification. If you can make it, it’d be great to see everyone there!

https://interspace.solidity-summit.ethereum.org/

Hey all - to continue with the discussion from today’s solidity summit we’ll have a call next Thursday, May 7 at 9AM CST / 3PM CET. I’ll post a zoom link here shortly before.

1 Like

General friendly reminder / ping about the sync tomorrow. It should be the last sync before finalizing the v3 spec! Hope to see y’all there - i’ll post the zoom link here shortly before start time.

Sorry for any confusion, my timezone math was off. Correct times for the sync: 8AM CDT / 9AM EDT / 3PM CEST

sync link: https://us04web.zoom.us/j/73933580804?pwd=Q3MrSDUwd2IzUVZLSUs2VDJuMnpkdz09

Would you consider this a “last call” at this point? I will Tweet something out to see if there are others who would like to submit feedback.

2 Likes

Yeah, @njgheorghita would it be possible to draft a blog post about this so we can Tweet it out and get Last Call comments on it before you draft the EIP?

1 Like

Yeah, that would be excellent. Tweet blasts are much appreciated as my twitter game is pretty weak. I’ll type it up and link it here as soon as it’s ready.

2 Likes

ping @fubuloubu @jpitts. I wrote up a short outline of the proposed v3 changes here - thanks for the blast!

Let me know if I forgot something or got anything horribly wrong.

I’m also proposing a spec freeze date of May 18 - which can be delayed if there are any problems found.

2 Likes

Moving conversation here @njgheorghita since this isn’t really about the EIP structure (which is all that should really be discussed in PRs).

I’m specifically referring to the source checksum which explicitly says that it is required if there is no URI (meaning the file is not available on a content-addressable filesystem). Either you have a URI like ipfs://… or swarm://…, or you don’t. In the case that you do, the checksum field is redundant. In the case that you don’t, the checksum field is useless.

In the case that you don’t have a URI - it is required to include the contract source as a string (under the “content” key) in which case the checksum field is also required, containing a checksum object with the algorithm used to generate a hash and the resolved hash of the inlined source.

What is the purpose of including the checksum in this scenario? What problem does it solve? What value does it provide to the user?

If my memory serves correctly, this requirement was enforced to enable tooling / frameworks to perform additional verification of any in-lined source assets. It is possible for ethpm packages to be imported solely as a json file (for example… if a user copy/pastes the json directly from an ipfs explorer rather than importing via the ipfs uri), in which case requiring the checksum provides some extra confidence in the authenticity of the inlined sources. However, if a user is interacting with the ethpm ecosystem as it was intended, then this requirement is overkill. I’d be on board to update the requirement to include a Checksum object along with inlined sources to just a recommendation, unless there are other objections.

Why not checksum the entire file in that case, as is common practice throughout the industry (serving a file hash as well as the file itself to protect users from MITM attacks)? This way, users in such a scenario can use existing tooling rather than needing custom tooling. This also would mean the entire file would be checksummed, rather than just part of the file.

1 Like

Just mandate the IPFS CID, and then allow an alternative link that would give the same file as if you downloaded it from IPFS

Just to have some more concrete examples to work with here, these are the three ways that the spec currently allows users to include a source.

  1. In-lined source requires a Checksum object
{"sources": {
	"Owned.sol": {
		"content": "pragma ...",
		"checksum": {
			"algorithm": "sha256",
			"hash": "a1b2c3..."
		}
	},
}}
  1. Source identified by a content-addressed URI does not require Checksum object
{"sources": {
	"Owned.sol": {
		"uls": ["ipfs://Qm..."]
	}
}}
  1. Source identified by a generic URI (aka a URI without a checksum of its contents) requires a Checksum object.
{"sources": {
	"Owned.sol": {
		"uls": ["github.com/myproject/Owned.sol"],
		"checksum": {
			"algorithm": "sha256",
			"hash": "a1b2c3..."
		}
	}
}}

@fubuloubu If I understand your example correctly, it would fall under the third category where the package creator could populate the Checksum object with the ipfs cid.

@MicahZoltu Correct me if I’m wrong, your concern is that in #1 requiring the Checksum object is redundant. I’m ok with dropping the requirement for a Checksum object to a recommendation in the first scenario.

Yes, in (1) the checksum provides no value because the payload source and the checksum source are the same which means it is trivial to put in a checksum that matches the provided payload.

In (2) no checksum is needed.

In (3) a checksum is valuable and I am OK with it being required there.

1 Like

Sorry for the delay - I’ve updated the EIP here.

Is this ready for Last Call?

1 Like

Last Call pr is up! https://github.com/ethereum/EIPs/pull/3269
Review period ends March 2. If there are any last minute suggestions / amendments to discuss please post them here asap!

I implemented a basic version of this spec for usage with brownie / vyper compilation, and overall I found it fairly natural and straightforward, the team clearly put a lot of thought into developing this spec.

The only thing that was a bit confusing for me was the installPath property of the Source object. This isn’t needed for Vyper and I think this may be Solidity specific? It could be helpful to add a comment to the spec specifying anything that’s specific to one language’s compiler vs. another, etc.

Alternatively, another option would be to adjust the name of installPath to something like ‘LocalPath’ or ‘CachePath’. Using Vyper I just compile from an in-memory string, whereas with Solidity this doesn’t seem possible hence the need for this property, if I’m understanding correctly.

1 Like

I never understood the point of the 0x prefix. It seems like an attempt to mix type information into the data itself. Ironically, something like “0x44” is valid Base64 and valid ASCII and a million other things, yet ‘x’ is not a valid hex character. So decoders have to decide whether to reject it or require it, or allow it optionally but check whether it’s actually there). I don’t think it improves readability by computers or humans. And certainly not interoperability.

‘0x’ is good for programming languages where multiple represenations can be used when assigning a variable. Multiple representations for the same field seems like a bad idea inside a standard.