You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
Here I am with another instance of #14494 and #14250.
Submitting this issue because these are supposed to be fixed in the latest versions but I encountered this originally in v0.8.26, and was able to also reproduce in v0.8.28
JSON Inputs
There are two instances (ie. std JSONs) of the same contract. One with extra files and one with only the files used by the compilation.
Below are the outputs with 0.8.26+commit.8a97fa7a. I haven't noticed any differences across binaries solc-js vs Darwin
etherscan-response-input.json (Larger JSON): This is the full JSON with extra files, called "etherscan-response" because this is from Etherscan and its the content of the response
sourcify-etherscan-import-input.json (Minimal JSON): This is the minimal JSON because we first import the file from Etherscan, generate the metadata by compiling the Larger JSON, and compile with the JSON based on this metadata. Since metadata.json generated strips away the source files not used by this contract, this creats a minimal JSON (expectedly).
constfs=require("fs");// Function to read and parse JSON filesfunctionreadJSONFile(filePath){try{constdata=fs.readFileSync(filePath,"utf8");returnJSON.parse(data);}catch(error){console.error(`Error reading or parsing file ${filePath}:`,error);process.exit(1);}}// Get file paths from command-line argumentsconst[file1Path,file2Path]=process.argv.slice(2);if(!file1Path||!file2Path){console.error("Please provide paths for both files as arguments.");process.exit(1);}// Read and parse the JSON filesconstfile1=readJSONFile(file1Path);constfile2=readJSONFile(file2Path);// Extract the keys of the sources objectsconstfile1Keys=Object.keys(file1.sources);constfile2Keys=Object.keys(file2.sources);// Find keys that are in file1 but not in file2constinFile1NotInFile2=file1Keys.filter((key)=>!file2Keys.includes(key));// Find keys that are in file2 but not in file1constinFile2NotInFile1=file2Keys.filter((key)=>!file1Keys.includes(key));// Output the resultsconsole.log(`Keys in ${file1Path} but not in ${file2Path}:`,inFile1NotInFile2);console.log(`Keys in ${file2Path} but not in ${file1Path}:`,inFile2NotInFile1);
In the Middle example, you can see the pattern 3 being replaced by b
In the Last Part, there are longer additions in green (hence the difference in lengths). You can see the metadata hashes are identical.
v0.8.28
I also reproduced this with 0.8.28. The Minimal JSON compiles directly with 0.8.28, although the Larger JSON has strict versions pragma solidity 0.8.26; so I need to manually set them to pragma solidity 0.8.28;
The bytecode lengths are same as before (30000 vs 30016 characters). The bytecode between same JSONs but different versions ("Larger JSON 0.8.26" vs. "Larger JSON 0.8.28") are different as expected. But from what I can see the shifts are the same, ie. the diff screenshots above and here are almost identical.
Notice the metadata hashes are again identical. One might have expected the metadata hash to change since we touched pragma statements, however we only touched the files that are not supposed to be used in the compilation. Therefore the metadata hashes remain the same expectedly.
For convenience I'm also adding the command I used to extract the runtime bytecode from the JSON outputs:
Here I am with another instance of #14494 and #14250.
Submitting this issue because these are supposed to be fixed in the latest versions but I encountered this originally in v0.8.26, and was able to also reproduce in v0.8.28
JSON Inputs
There are two instances (ie. std JSONs) of the same contract. One with extra files and one with only the files used by the compilation.
Below are the outputs with 0.8.26+commit.8a97fa7a. I haven't noticed any differences across binaries solc-js vs Darwin
etherscan-response-input.json
(Larger JSON): This is the full JSON with extra files, called "etherscan-response" because this is from Etherscan and its the content of the responsesourcify-etherscan-import-input.json
(Minimal JSON): This is the minimal JSON because we first import the file from Etherscan, generate the metadata by compiling the Larger JSON, and compile with the JSON based on this metadata. Since metadata.json generated strips away the source files not used by this contract, this creats a minimal JSON (expectedly).Input differences
Here's the output of the script that checks for source file differences between the two JSON inputs:
Script Output
The JS script
Bytecode differences
Compiled runtime bytecode of the Larger JSON:
11155111-0xAD7714459F728E78279a77A019fE948A21480B83-etherscan-response-output-runtime-bytecode.txt
Compiled runtime bytecode of the Minimal JSON:
11155111-0xAD7714459F728E78279a77A019fE948A21480B83-sourcify-etherscan-import-output-runtime-bytecode.txt
Even though they are mostly identical, the bytecodes are also different in lengths
Taking the bytecode diff:
Some screenshots from the diff.
Middle:
Only the last part:
In the Middle example, you can see the pattern
3
being replaced byb
In the Last Part, there are longer additions in green (hence the difference in lengths). You can see the metadata hashes are identical.
v0.8.28
I also reproduced this with 0.8.28. The Minimal JSON compiles directly with 0.8.28, although the Larger JSON has strict versions
pragma solidity 0.8.26;
so I need to manually set them topragma solidity 0.8.28;
Larger JSON with replaced 0.8.28:
11155111-0xAD7714459F728E78279a77A019fE948A21480B83-etherscan-response-input-0.8.28.json
Minimal JSON is identical
Larger JSON 0.8.28 runtime bytecode:
11155111-0xAD7714459F728E78279a77A019fE948A21480B83-etherscan-response-output-0.8.28-runtime-bytecode.txt
Minimal JSON 0.8.28 runtime bytecode:
11155111-0xAD7714459F728E78279a77A019fE948A21480B83-sourcify-etherscan-import-output-0.8.28-runtime-bytecode.txt
Diff command
Similar noticable patterns:
Middle:
Ending:
The bytecode lengths are same as before (30000 vs 30016 characters). The bytecode between same JSONs but different versions ("Larger JSON 0.8.26" vs. "Larger JSON 0.8.28") are different as expected. But from what I can see the shifts are the same, ie. the diff screenshots above and here are almost identical.
Notice the metadata hashes are again identical. One might have expected the metadata hash to change since we touched
pragma
statements, however we only touched the files that are not supposed to be used in the compilation. Therefore the metadata hashes remain the same expectedly.For convenience I'm also adding the command I used to extract the runtime bytecode from the JSON outputs:
The text was updated successfully, but these errors were encountered: