-
Notifications
You must be signed in to change notification settings - Fork 15
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: verify contracts on filfox #151
base: main
Are you sure you want to change the base?
Conversation
evm/verify-filfox.js
Outdated
const { addBaseOptions } = require('./cli-utils'); | ||
const { validateParameters, loadConfig, printInfo, printError } = require('./utils'); | ||
|
||
async function verifyFilfox(options) { |
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 should be integrated into our normal verifyContract method. If chain is filecoin then call this helper method with appropriate data. you can look into how the existing verify method extracts the compiler version/optimizer runs to do the same (maybe even import that method if possible from hardhat-verify)
evm/verify-filfox.js
Outdated
}, | ||
}; | ||
|
||
const optimizerDetails = ''; |
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.
Why are the optimizerDetails and some other fields empty? Our current config has the optimizer details. Are these fields not necessary
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.
Yeah I agree, was having some trouble importing the configurations from the hardhat config in other repositories
# Conflicts: # axelar-chains-config/info/mainnet.json # axelar-chains-config/info/testnet.json
"path": "^0.12.7", | ||
"axios": "^1.6.2" |
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.
these aren't dev dependencies since it's for an exported function
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.
When I didn't have them as dependencies axelar chains config tests were failing, should I move them from dev dependencies into normal dependencies?
|
||
try { | ||
const buildInfoPath = path.join(dir, 'build-info'); | ||
const smallestFile = await getSmallestFile(buildInfoPath); |
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's the logic behind getting the smallest one? non-obvious behaviour should be commented
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.
It seems that there are often multiple build files produced within the build-info
folder, some are extremely large and unfeasible to parse just for compiler/optimize information but all seem to contain the same config information which is why I added a function to just parse the smallest file present. I agree it is a bit convoluted but I'm not sure how else to go about it
|
||
let buildInfo; | ||
|
||
try { |
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.
move try/catch to be specifically over the code that can fail
|
||
const config = require(`../../info/${env}.json`); | ||
const contractConfig = config.chains.filecoin.contracts[contractName]; | ||
const contractFileName = getContractFileName(contractConfig, contract); |
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.
isn't contractName already being passed in? you can enforce it to be passed in, and update usages in our code instead of the limited reverse map
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.
The config map has different names for addresses than actual contract file names, so this should fail @deanamiel.
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.
@milapsheth , @deanamiel can we modify all verifyContract()
calls withinverify-contract.js
to have a hardcoded contract name with it, which will simplify script execution for all the contracts. I will also be able to use this in my PR: #162
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.
The contractName
being passed would just be InterchainTokenService whereas I need each individual contract name within ITS to find the correct contract path to the flattened source code. @blockchainguyy yeah that is true, it will not work for a few contract names, I thought of adding an optional argument for the hardcoded contract name to verifyContract()
as well but am not sure it's worth all these changes for only filfox verification for their specific verification endpoint requirements, thoughts @milapsheth ?
metadata: '', | ||
}; | ||
|
||
const api = config.chains.filecoin.explorer?.api; |
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.
get the API from hardhat network or options.api?
|
||
if (fileOrDirectory.isDirectory()) { | ||
directoriesToSearch.push(fullPath); | ||
} else if (fileOrDirectory.isFile() && fileOrDirectory.name === targetFileName) { |
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.
Optional: if we convert fileOrDirectory.name
and targetFileName
to lowercase and compare them we should be able to simplify getContractFileName
by removing slicing and first letter conversion to uppercase, which should increase code readability.
Script to verify contracts on filfox explorer as per AXE-2937