ethpm/Lobby

Just some guy

@fubuloubu

(2) is more of a note, I think (1) is the better use case

chriseth

@chriseth

the solidity compiler "exposes" the evm version in the compiler settings flag

Jan H. Scheufen

@j-h-scheufen

@chriseth The topic of EVM version for sourcecode vs. bytecode ^^ reminds me of a discussion we had here with Tim and Piper in the early days of ethpm: That it would make sense to separate the manifest into one for the source code that can be provided by the author/project and describes compile time dependencies and ensures authenticity of the sources. A secondary manifest would be generated as a "deployment descriptor" every time a package's bytecode gets generated, linked with libs and other addresses from a particular chain, and deployed. This second (deployment) manifest obviously can link to the source manifest. It could be provided by the original author (e.g. if he/she deployed the package to mainnet or a test net), but it can also be created (and signed) by anyone making a deployment to any other EVM system that the original author might not care about. This would support enterprise usage of the package system much better as the original source manifest can remain untouched.
Has this topic survived or has that ever been discussed again after?

Nick Gheorghita

@njgheorghita

the solidity compiler "exposes" the evm version in the compiler settings flag

:+1:

Nick Gheorghita

@njgheorghita

@j-h-scheufen If i’m understanding correctly, this use-case is possible, but discouraged (aka unlikely to be supported by ethpm tooling). The spec states that contractTypes in a manifest should reference source files in the same manifest, not from a dependency. IMO since all source files are stored on some content-addressed network, then it should straightforward to reference the content-addressed (ipfs / swarm / etc) urls from the authors manifest in a “deployment descriptor” type manifest.

chriseth

@chriseth

I do see the point that "B is a deployment of package A" is something else than "package B is deployed there and package B and package A share the same source"

But I'm not sure if ethpm should model that and much less how it could model it.

Jan H. Scheufen

@j-h-scheufen

Thanks, @njgheorghita and @chriseth!
If I followed the development of the ethpm standard correctly over the years, this scenario is still supported by the current standard, just that the same manifest format is used for both: a more "source-oriented" manifest as well as a "deployment" manifest. Example:

Author/project releases package A with manifest, does NOT deploy it on any chain, so posts a manifest and package to IPFS that just describes the source content and other packages required to compile
A consumer project wants to leverage package A in their project X and creates another manifest when compiling and deploying (let's say, to their test chain or a permissioned Besu chain). This creates the manifest containing the addresses of deployed contracts since the original author obviously was not able to provide a manifest that combines the source metadata and the specific addresses for this project's deployment reality.

The problem (or inconvenience) I see is that the deployment manifest would need its own name or version, right? Project X would basically take the published package A (v1.2.0) and create a manifest for their deployment on their particular chain and have to call it package A (v1.2.1) or rename the package. Even though the original package has not changed, a new manifest with new name and version number is needed, just to include the deployed addresses of that package.

If my understanding here is incorrect, I'd appreciate a pointer. Coming from an enterprise background and with permissioned EVM chains being more wide-spread now, I've struggled to understand how exactly this scenario would look like.

Nick Gheorghita

@njgheorghita

Ultimately, the spec is designed to be as flexible as possible, to suit any use case. In version 3, we no longer strictly require that every package contains a name and version. However, it’s suggested since those are useful identifiers. But, it’s perfectly reasonable to release a manifest json that doesn’t contain name and version fields onto any registry under any given name and version.

However, I’m a little confused by this sentance Even though the original package has not changed, a new manifest with new name and version number is needed, just to include the deployed addresses of that package.. If you are adding deployments (addresses, txhashes, etc..) to a “source” package, isn’t this inherently more than just adding a new name and version, and wouldn’t you anyways want a new name and version to identify the newly added deployments? But, maybe I’m not understanding your use case exactly...

Just some guy

@fubuloubu

In version 3, we no longer strictly require that every package contains a name and version.

This is a good decision because use cases like development frameworks don't strictly need a name/version until it comes time to deploy your package

Nick Gheorghita

@njgheorghita

The EIP for EthPM v3 is here - ethereum/EIPs#2678 . It would be great if anybody has time to give it a review. It was generated from the docs so it should be the exact same as http://ethpm.github.io/ethpm-spec/v3-package-spec.html . A couple reviews would be super helpful, then we can move on to finalizing v3!

Just some guy

@fubuloubu

where's my mention! lol

just add me below Ben, I like riding on coattails

Just some guy

@fubuloubu

so, thinking about the usecase of having a service like Etherscan verify a contract directly from a Manifest

I think we have everything they need except the constructor arguments for a deployed instance (ABI-encoded)

Just some guy

@fubuloubu

Wait, what is the usecase for runtimeBytecode under ContractInstance? (not ContractType)

Just some guy

@fubuloubu

Also, I really wish ABIv2 was an EIP spec that we could refer to, instead of linking to Solidity's documentation

chriseth

@chriseth

@fubuloubu unfortunately, the constructor arguments have to be verified from an archive node with additional indexing - we actually need that to verify the constructor itself already

phew, this is a hefty piece of a document...

Just some guy

@fubuloubu

@fubuloubu unfortunately, the constructor arguments have to be verified from an archive node with additional indexing - we actually need that to verify the constructor itself already

not sure I see your point?

can you rephrase?

Nick Gheorghita

@njgheorghita

where's my mention! lol

done! sorry for the brain fart, I really do appreciate your contributions here. and with great self-control I was able to resist the urge to add you as I’m just a doggie boi

phew, this is a hefty piece of a document…

it certainly is! many thanks to you and bryant for the reviews!

Just some guy

@fubuloubu

where's my mention! lol

done! sorry for the brain fart, I really do appreciate your contributions here. and with great self-control I was able to resist the urge to add you as I’m just a doggie boi

But I am just a doggie boi!

Thanks! :smile:

Just some guy

@fubuloubu

if we're standardizing ethPM v3, wouldn't it make sense to have it point to another standard for ABI objects, instead of the Solidity documentation? (which is indirectly pointed to via https://github.com/ethereum/wiki/wiki/Ethereum-Contract-ABI#json)

let's say there is an ABIv3, then would ethPMv3 point to ABIv2, or would it point to whatever is the latest? Would that make previously compliant ethPMv3 manifests uncompliant?

Nick Gheorghita

@njgheorghita

i’m not sure it’s obvious that’s a case for which the ethpm spec should provision. not being up to date with the possibility of an ABIv3, some questions I’d have are… How likely is it that there will be a v3 & when? And, my greater hope would be that v3 ABIs will be inherently differentiable from v2 - so tooling would be able to recognize each version and treat each ABI accordingly. If that’s not the case, then I’d be inclined to agree that this is something to consider for ethpm v3.

Just some guy

@fubuloubu

I think it's unlikely at this point, but we also can't tell the future of either of these standards. There's no reliable versioning information that differentiate v1 and v2, so between v2 and v3 it would probably be difficult to tell the difference between them. I think for posterity, there should be an effort to try and formalize ABIv2 (at least) so we don't even have to have these discussions. It seems like a no-brainer that such an important encoding format be standardized in some way.

And the Solidity docs are not the place for it, because it's not an immutable or version controlled display format

I think we tried to get this done last summer, but it never happened.

Just some guy

@fubuloubu

I just went ahead and translated ABIv2 to an EIP:
ethereum/EIPs#2792

also turns out it was 2018 that I was remembering :grimacing:

Nick Gheorghita

@njgheorghita

ERC 2678 aka ethpm v3 is up! It’s still in Draft stage so if anybody has questions or suggestions please post them here!

@fubuloubu I’m definitely open to the idea of specifying the abi version in some way, let’s revisit this once #2792 lands

chriseth

@chriseth

I'm not sure ABI should be versioned - maybe it is better to talk about which features are supported?

solidity's v1/v2 distinction is less about the standard and more about the implementation

bodytexture

@bodytexture

hi, total newby here, what is the absolute easyest way to explore ethpm (I know some python but would rather have a look at a GUI to start and see what 's inside to get an idea)

Just some guy

@fubuloubu

@bodytexture Brownie has support for EthPM v2, which should still work (hopefully). Still haven't updated to support EthPM v3 (not sure how that's coming along)

bodytexture

@bodytexture

@fubuloubu thanks, I wish to have a look at all available preaudited smart contracts to see if they come toughether as building blocks , at least in my mind, to start immagining a project that could catch my curiosity enough to push me to study (i have little time because of family and other company)

Nick Gheorghita

@njgheorghita

hey @bodytexture ! ethpm is currently upgrading from v2 to v3. native support for v3 in truffle should be available within the next couple of weeks. the ethpm-cli (https://github.com/ethpm/ethpm-cli) currently supports v3. to my knowledge, there isn’t a large supply of audited ethpm v3 packages at the moment- we’re hoping that will change once truffle integration and we’ll start to see the more popular projects release their contracts as ethpm packages. if you just want to get a feel for how ethpm works, i’d start with the cli & the docs (https://www.ethpm.com). if you just want to explore audited smart contracts - your best bet is to explore various github repos. if you find this frustrating, tweeting at your favorite protocols that they should release their audited contracts as ethpm packages is a great idea!

Just some guy

@fubuloubu

@njgheorghita how finalized is v3? specification still says WIP: http://ethpm.github.io/ethpm-spec/v3-package-spec.html

Just some guy

@fubuloubu

also, would like to sign myself up for a v3 package manifest for yearn. it perfectly fits my use case, and I want to be able to make it work with our Vyper contract

Nick Gheorghita

@njgheorghita

@fubuloubu I can definitely help you out with that. And i’d like to push v3 into last call mode sometime this week, but i’ll notify this channel when that happens.

ANN

@FeliciaXmL_gitlab

Solidity is the correct place due to the abi can be reconstructed causing the validation to be true

dapp-whisperer

@dapp-whisperer

I am having problems using the cli, error

ipfshttpclient.exceptions.VersionMismatch: Unsupported daemon version '[0, 7, 0]' (not in range: [0, 4, 3] – [0, 5, 0])

even when using virtual env as suggested, and installing ipfs system daemon @0.5.0

Is there a way to browse packages without writing a script with one of the apis?

Nick Gheorghita

@njgheorghita

@dapp-whisperer Hey! A fix just came through the release pipeline - a new version ethpm-cli==0.3.0 is now available that should work, let me know if you have any more problems

Nick Gheorghita

@njgheorghita

@darealsisyphe Hey! That means that you’ll have to sign up for an infura account to get a project id and then set it as the environment variable WEB3_INFURA_PROJECT_ID. More details on how to can be found here: https://web3py.readthedocs.io/en/stable/quickstart.html?highlight=infura#provider-infura

Where communities thrive

People

Repo info

Activity