Heads up that after CREATE2 is deployed (in Constantinople), that verifying contract source gets a bit more complicated. Why? The bytecode for a C2 contract can change over time. The easiest solution to verifying contract source is to just make sure it's not a C2 contract. You can do that by storing the sender and nonce so that you can recompute the contract address.
Yeah, it is sort of a side-effect. I should note that this is entirely theoretical, haven't tried this in practice yet, but no one in the room has told me it's crazy yet. Roughly: you create a helper contract whose sole job is to hold your desired final bytecode, then you run a CREATE2 with init code that loads and returns the bytecode from the helper. Then, at upgrade time, you load the new bytecode into the helper, self-destruct the contract, and re-deploy the upgraded contract using the same init code.
FWIW, I made the proof-of-concept on Goerli for the above idea about contract replacement, so now it's confirmed. Source verification can get stale, and contracts could be swapped out at any time. Best to just stick to verifying
CREATE and blacklisting CREATE2 for now, I suspect. Most likely, that means adding some extra input data to verify that the contract was generated by CREATE .
This is an example contract that I could swap out at any time, into the same address: https://goerli.etherscan.io/address/0x0140248b581ed533ba7e5f1d137d1b12bdf83839#code
not sure if that's what you're asking
I basically want to run Python tests using a Truffle package
was fantasizing how to do that lol
@fubuloubu if you want, let's move this conversation to gitter.im/trufflesuite/truffle-dev and we can discuss requirements and such
BTW, I recently realized that upgrading-in-place can be done on regular
CREATE contracts as well as CREATE2, after Constantinople. So, I'm not sure the package manager source verification can/should do anything. Maybe look for selfdestruct, callcode, delegatecall and issue a warning that it could be possible to swap the contract in place, when verifying source. But that seems pretty brittle to an evolving EVM.
I looked in an
ethpm.json file and under the list of dependencies I found one named "tokens". Where do I find out information about that package? I'm getting a 404 Not Found from https://www.ethpm.com/registry
I go to http://explorer.ethpm.com/browse/mainnet/tokens but I learn nothing
@ttmc The information for the
”tokens” package should be included in the ethpm.json. Since there’s no central package registry in ethpm there’s no global “tokens” package, so it’s hard to know which specific ”tokens” package is the one referenced in your case, but if you can link the ethpm.json you’re talking about I can dig a bit deeper
@njgheorghita Here's the
ethpm.json file I'm looking at, wondering what it means by the "tokens" package: https://github.com/oceanprotocol/keeper-contracts/blob/v0.8.6/ethpm.json
Was able to pin things in a way to keep everything working. Just curious.
@mikeshultz Haha, yeah. I’d say we’re on a full press for web3 v5. The newest release of ethpm (
0.1.4a13) should play nicely with web3 4.9, but in terms of ethpm supporting web3.py < 5.0, it’s probably going to be up to the user to modify ethpm as needed (unless there’s strong demand for it)
Hey @rmi7 If i’m not mistaken, the page I believe you’re referring to was from version 1 of the EthPM spec - which is no longer supported. In version 2, we don’t have a centralized registry where everybody publishes their packages. Instead we encourage everybody to deploy their own, authorized registry where they can publish their own smart contract packages. There’s a short list of available registries here but I’m not sure if they contain the packages that you’re looking for.
Hey @njgheorghita - Daniel here from the Consensys Ethereum bootcamp (student).
I think a lot of the incoming requests are coming from people coming from the Truffle Docs + EthPM guide
I've created an issue to update the Truffle Docs for EthPM v2. Happy to work on it if you can give a high-level summary of what you'd like written, and pointers on where to look for information
TypeError: Cannot convert undefined or null to object
at Function.keys (<anonymous>)
at Object.resolve_dependencies (/usr/local/lib/node_modules/truffle/build/webpack:/~/ethpm/lib/preflight.js:14:1)
at /usr/local/lib/node_modules/truffle/build/webpack:/~/ethpm/lib/installer.js:29:1
Truffle v5.0.27 (core: 5.0.27)
Node v11.11.0
Hi guys, small question in regards o EthPM. When you publish something into an EthPM registry, does it include the generated artifacts genareted by the compiler? (ABI, bin, etc) Couldn't find it anywhere and I could not manage to publish a really sample project using Truffle.
I ask because we are looking for a good way to actually store generated artefacts which can later be referenced for a deployment (similar as you do with Docker, you build your image, store in a registry and then simply deploy it to an environment)
@javier-tarazaga confirming @fubuloubu ’s answer. Though, afaik Truffle hasn’t been updated yet to the new ethPM spec, so that might be why you’re having trouble generating your package. If you’re in python world,
web3.py exposes a builder tool which will help you create manifests, or within the next week or two I hope to release ethpm-cli which will let you easily create packages from your command line.
Hi @njgheorghita ! ethpm-cli seems really promising. The docs linked in the repo are missing: https://ethpm-cli.readthedocs.io
@ResourceHog AFAIK there’s somewhat of a shortage of ethPM v2 packages.
ethpm-cli is coming soon to help change that, so you can easily make your own cool packages. Otherwise this directory is a good place to start exploring.
Oh thanks for the answer (and the amazing work!). So to give you some more context in why we need that, in Superblocks we are currently seeking the best way to introduce contract Release Management into the platform (we already have a functional CI). In order to do so, we were thinking to offer some artifactory registry. We would love to work with standards (and even help setting them), thats why Ethpm is the first place to look, in which you could publish your contracts after being compiled/tested in the CI service. We know traceability and artifactory immutability is even more crucial in the Smart Contract world (you don't want to build every time you want to per example promote contracts from Testnet to Mainnet, as imagine you forgot to lock one dependency and all of the sudden your bytecode is different when deploying). We see the process as Docker. You specify your Docker image, you build it, upload it to a registry (a good practice would be to include the commit hash in the title), and then simply when needed to be released, pull the image and deploy it.
Also a great thing we see with this approach is that you could publish your compiled contracts into the registry, and actually an auditor could pull them so when building locally the application, you can compare the generated bytecode and be 100% certain is the exact same code