-
Notifications
You must be signed in to change notification settings - Fork 1.7k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feat(cast) add creation-code method [#8973] #9029
base: master
Are you sure you want to change the base?
Conversation
crates/cast/bin/cmd/creation_code.rs
Outdated
async fn fetch_creation_code( | ||
contract: Address, | ||
client: Client, | ||
provider: &Arc<RetryProvider>, |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
provider: &Arc<RetryProvider>, | |
provider: &RetryProvider, |
crates/cast/bin/cmd/creation_code.rs
Outdated
// Extract creation code from tx traces | ||
let mut creation_bytecode = None; | ||
|
||
let traces = provider.trace_transaction(creation_tx_hash).await?; |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
this will work, but is usually not available on the free tier, so this can fail with a serde rpc error "method not found" or "unavailable", we should add an eyre context here like "failed to trace tx 0x..."
} | ||
} | ||
|
||
/// Fetches the creation code of a contract from Etherscan and RPC. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
We should document whether or not this includes constructor args appended to initcode
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mds1 right, I should probably strip them to make the bytecode useful for local deployment. Maybe worth returning constructor args separately?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I'm reading up there's is no a single unified convention for encoding constructor args with different solidity versions. So I think I'll just add a comment that they are appended.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
What is the use case for this method? I think that impacts whether or not you want to strip the constructor args. If you do want to strip them you'll likely need to use blockscout or etherscan to fetch constructor args
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
I want to get bytecode that I can use for deploying contracts locally, without compiling them myself. So prefer creation code without constructor args appended. But, optionally knowing what were the args values is also useful.
Eventually I want to add artifact
method that will combine creation bytecode with JSON ABI, for simply use with sol!
Alloy macro.
I'm thinking to add --without-args
and --only-args
flags. I think it's possible to know the size of appended args from the ABI. WDYT?
I've added
|
c224c30
to
e1df312
Compare
Motivation
As described in #8973, currently there's no simple way to obtain contract creation code without compiling them locally. It is needed to deploy contracts with
sol!
macro.If this is accepted I'll add
artifact
method generating file that can be used directly withsol!
macro.Solution
This PR adds
cast creation-code
method. It outputs the contract creation code.Example usage