Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
    Nick Gheorghita
    @njgheorghita
    It was my understanding from the last time we talked about licenses (which I believe was the soldity summit) was that the ethpm spec would only officially define the package-wide ”meta” license. Leaving it up to individual tooling / frameworks to decide if they want to include a license for a SourceObject (eg. solc metadata including ”license” in a SourceObject would still be a valid ethpm package).
    On one hand, it would be very simple to officially define a ”license” field for a SourceObject. On the other hand, this introduces complexities regarding which license takes precedence as @fubuloubu elaborated upon.
    If i’m reading the room correctly, consensus is now that we should define both a ”license” field in the top-level ”meta” object and a SourceObject (which I can update shortly)?
    chriseth
    @chriseth
    the solidity compiler will use the newly introduced license comments to add a license to each source file individually. How that relates to the whole package has to be determined my a human, I would say. So the fields "package license" and "license of an individual file" are two different things, even when they are related
    also it can be rather common that libraries have a different license than the project using the library, so it would make sense to have a granularity at the file level
    El De-dog-lo
    @fubuloubu

    If i’m reading the room correctly, consensus is now that we should define both a ”license” field in the top-level ”meta” object and a SourceObject (which I can update shortly)?

    yes, and to make it simpler, a SourceObject license overrides the project-wide one

    so if you want it to extend, you have to do it manually
    chriseth
    @chriseth
    while implementing, I found another minor issue: We also support compiling starting from a previously exported AST, without a source file. I think this can be solved by supporting more than just 'solidity', 'vyper' and 'abi-json' as file type, but I have not done this yet
    so I would maybe use something like 'soliditiy-ast-json'
    El De-dog-lo
    @fubuloubu
    @chriseth what's the use case for that?
    also, @axic did you ever end up making an ABIv2 ERC?
    chriseth
    @chriseth
    @fubuloubu you can output the ast, modify it and "recompile". One of the use-cases is mutation testing.
    Nick Gheorghita
    @njgheorghita
    @chriseth As of now the spec states that for the type of a source file, The field **should** be one of the following values: “jsonabi", “solidity", “vyper".I interpret this as the list is non-exhaustive, and any string is a valid type, but I’m happy to include solidity-ast-json as one of the suggested types if you give a :thumbsup: - also I can update ”jsonabi” to ”abi-json” if that is the preferred identifier.
    @fubuloubu thanks for helping think this through, the update is in ethpm/ethpm-spec#155
    chriseth
    @chriseth
    yeah, abi-json is probably a better name. Thanks!
    El De-dog-lo
    @fubuloubu

    One of the use-cases is mutation testing.

    Ah gotcha

    @fubuloubu thanks for helping think this through, the update is in ethpm/ethpm-spec#155

    awesome!

    El De-dog-lo
    @fubuloubu
    Have we ever talked about having the EVM version in the package? Is that a thing?
    e.g. istanbul, constantinople, etc.
    chriseth
    @chriseth
    Hm, it could, but I think it is not very straightforward. Ther are two "evm versions" to consider: 1. This bytecode has been compiled for EVM version X, 2. This sourcecode is writter for EVM version Y
    El De-dog-lo
    @fubuloubu
    I think (1) would be most pertinent
    if you have bytecode, and it was compiled targeting a version other than the default for a given compiler version, that's a useful flag to know
    without knowing that, you would be unable to reproduce the bytecode
    (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:

    1. 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
    2. 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...

    El De-dog-lo
    @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!
    El De-dog-lo
    @fubuloubu
    where's my mention! lol
    just add me below Ben, I like riding on coattails
    El De-dog-lo
    @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)
    El De-dog-lo
    @fubuloubu
    Wait, what is the usecase for runtimeBytecode under ContractInstance? (not ContractType)
    El De-dog-lo
    @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...
    El De-dog-lo
    @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!

    El De-dog-lo
    @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:
    El De-dog-lo
    @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?