apply HH-verify input simplification

[kanej]

The build info used for the input to Etherscan during verification can include extraneous files for the compilation of the contract.
In Hardhat verify there is a simplification step that is attempted to reduce the nubmer of files that have to be sent to Etherscan.
We should replicate this behaviour in Ignition's verify logic.

Questions

1. Can we get an outline of the HH-verify logic for simplifying the input to Etherscan, to determine if we can replicate it in general
2. Is it possible to reuse the HH-verify logic directly by applying it to the Etherscan class that is programmatically exposed?
3. How should Ignition, with its pre-saved artifacts and build infos recreate this behaviour?

[alcuadrado]

• Can we get an outline of the HH-verify logic for simplifying the input to Etherscan, to determine if we can replicate it in general

The pseudocode would be:

verify(contract, minifyInput):
     const buildInfo = getBuildInfoOfContractFromDeploymentArtifacts(contract);
     const fullInput = buildInfo.input;
     
     const input = minifyInput ? minifyInput(contract, buildInfo.input) : buildInfo.input;
     
     verifyOnEtherscan(contract, input)
     
minifyInput(contract, input):
   const newInput = {...};
   const filesToProcess = emptyQueue();
   filesToProcess.push(findContractFileInInput(contract, input))
   
   while !filesToProcess.isEmpty()
         const file = filesToProcess.pop();
         newInput.add(file)
         
         const dependencies = file.getResolvedImports();
         for (dep in dependencies)
              if not in newInput:
                  filesToProcess.push(dep)

• Is it possible to reuse the HH-verify logic directly by applying it to the Etherscan class that is programmatically exposed?

I don't think we'd be able to reuse the entire logic, because as hh-verify gets its input from the contracts/ folder instead of the deployment artifacts, it can reuse the compilation subtasks, which ignition can't.

• How should Ignition, with its pre-saved artifacts and build infos recreate this behaviour?

Yes

[alcuadrado]

getResolvedImports means two things:

1. extracting the inputs with solidity-analyzer
2. Resolving any relative path

[kanej]

getResolvedImports means two things:

1. extracting the inputs with `solidity-analyzer`

2. Resolving any relative path

Just to clarify. You would approach this by recreating the logic locally with solidity-analyer rather than trying to reuse internals from HH?

[alcuadrado]

getResolvedImports means two things:

1. extracting the inputs with `solidity-analyzer`

2. Resolving any relative path

Just to clarify. You would approach this by recreating the logic locally with solidity-analyer rather than trying to reuse internals from HH?

Yes, because that logic is not present "as is" in the other plugin.