I wrote an article that goes over this information in depth. I will summarize it here.
tl;dr - There are only two types of bytecode on Ethereum but five different names to describe them.
This is the code that most people are referring to when they say bytecode. This is the code that generates the runtime bytecode—it includes constructor ...
bin-runtime is the code that is actually placed on the blockchain. The regular bin output is the code placed on the blockchain plus the code needed to get this code placed on the blockchain, the code of the constructor.
The basics of the Ethereum Virtual Machine is defined in Section 9.1 of the Ethereum Yellow Paper.
To answer this ...
I'm really not an expert in this but I would imagine (mostly) no, especially if optimization is turned on. There is no need for the bytecode to include any indications of the original language so including such details would be a waste of space - each extra byte costs gas.
However I might imagine different language compilers to exhibit certain ...
This GitHub issue helped me find the answer. Basically what I needed can be achieved with the ethereumjs-vm module:
const VM = require("ethereumjs-vm").default;
const BN = require("bn.js");
const vm = new VM();
code: Buffer.from(creationBytecode + abiEncodedConstructorArguments, "hex"),
gasLimit: new BN(...)...
Etherscan has introduced some multifile methods that might help with this.
The good old-fashioned method is to create a flat version of the contract for verification purposes. That can be done manually or with the help of a utility (google Solidity Flattener).
A flat version would be a single file Test1.sol where you remove the import and simply append ...