## Where communities thrive

• Join over 1.5M+ people
• Join over 100K+ communities
• Free without limits
##### Activity
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?
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.
El De-dog-lo
@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.
El De-dog-lo
@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)
?
El De-dog-lo
@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!
El De-dog-lo
@fubuloubu
@njgheorghita how finalized is v3? specification still says WIP: http://ethpm.github.io/ethpm-spec/v3-package-spec.html
El De-dog-lo
@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
sahiltrehan
@sahiltrehan
Hey, need help in installing the EthPM package via truffle. Please suggest.
Nick Gheorghita
@njgheorghita
Hey @sahiltrehan do you know what ethpm version the package is using? Or can you drop a link to the package here?
El De-dog-lo
@fubuloubu
@njgheorghita wen Last Call for https://eips.ethereum.org/EIPS/eip-2678 ?
@carlfarterson was wondering
Nick Gheorghita
@njgheorghita
@fubuloubu Good call, I’ll push it into Last Call stage tomorrow
El De-dog-lo
@fubuloubu
exciting! :rocket:
Nick Gheorghita
@njgheorghita
@fubuloubu Sorry for the misinformation - I was unaware that we have to undergo a Review phase before Last Call. The spec is currently sitting in Review. There’s an open question on the eth-magicians forum about whether a Checksum should be required for in-lined sources. Once that’s resolved, I feel safe moving onto Last Call (finally :sweat_smile: ). Do you happen to remember why we settled on this requirement during the Solidity Summit sessions?
El De-dog-lo
@fubuloubu
Review is new yeah