Different bytecodes using solcjs and remix

Question

Using solcjs in any contract ends up producing significantly longer bytecode that using remix

For instance this simple smart contract

pragma solidity >=0.8.0;

contract test {
    uint256 public c;
    function add(uint256 a, uint256 b) public {
        c = a + b;        
    }
}

Produces this bytecode with solcj 0.8.4 :

solcjs --bin ./filename.sol

60806040523480156100115760006000fd5b50610017565b61020a806100266000396000f3fe60806040523480156100115760006000fd5b506004361061003b5760003560e01c8063771602f714610041578063c3da42b81461005d5761003b565b60006000fd5b61005b600480360381019061005691906100ba565b61007b565b005b610065610097565b6040516100729190610109565b60405180910390f35b80826100879190610125565b60006000508190909055505b5050565b60006000505481566101d3565b6000813590506100b3816101b8565b5b92915050565b60006000604083850312156100cf5760006000fd5b60006100dd858286016100a4565b92505060206100ee858286016100a4565b9150505b9250929050565b6101028161017c565b825250505b565b600060208201905061011e60008301846100f9565b5b92915050565b60006101308261017c565b915061013b8361017c565b9250827fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff038211156101705761016f610187565b5b82820190505b92915050565b60008190505b919050565b7f4e487b7100000000000000000000000000000000000000000000000000000000600052601160045260246000fd5b565b6101c18161017c565b811415156101cf5760006000fd5b505b565bfea264697066735822122023e6550dca95b7639bddac283c9a25eeffea2cec5b91baf6becf24c3c9034fd064736f6c63430008040033

In remix using 0.8.4 (no optimization) 608060405234801561001057600080fd5b506101e8806100206000396000f3fe608060405234801561001057600080fd5b50600436106100365760003560e01c8063771602f71461003b578063c3da42b814610057575b600080fd5b610055600480360381019061005091906100a6565b610075565b005b61005f61008b565b60405161006c91906100f1565b60405180910390f35b8082610081919061010c565b6000819055505050565b60005481565b6000813590506100a08161019b565b92915050565b600080604083850312156100b957600080fd5b60006100c785828601610091565b92505060206100d885828601610091565b9150509250929050565b6100eb81610162565b82525050565b600060208201905061010660008301846100e2565b92915050565b600061011782610162565b915061012283610162565b9250827fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff038211156101575761015661016c565b5b828201905092915050565b6000819050919050565b7f4e487b7100000000000000000000000000000000000000000000000000000000600052601160045260246000fd5b6101a481610162565b81146101af57600080fd5b5056fea26469706673582212205733a2d0235d969fa16994d7de6e82cf2340b83c0e583155bdc54777eed9ce6564736f6c63430008040033

Both codes run as expected (even for more elaborated contracts)

As a consequence the code generated with solcjs can not be verified in etherscan which during verification produces a bytecode equal to the one obtained using remix.

Any explanation for this differences? is solcjs using by default some options that account for these differences?

Answer 1

The issue seems to be a bug in solcj, see here

Using solcjs --bin ./filename.sol does not indicate the optimization flag, which then should be false but this is not the case. As described by @Kamil in the link above, this produces a code that is not equivalent to set optimize to false, neither to true.

As a consequence the code produced is not optimized at all (using optimize false will still run peephole optimizer and jumpdest remover).

The code is then longer as is not optimized at all but it is correct code. See here for more info about the bug.