使用solcjs和remix的不同字节码

Question

在任何合同中使用solcjs最终都会产生更长的字节码，而不是使用混合。

例如，这个简单的智能契约

pragma solidity >=0.8.0;

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

使用solcj 0.8.4生成此字节码：

solcjs --bin ./filename.sol

60806040523480156100115760006000fd5b50610017565b61020a806100266000396000f3fe60806040523480156100115760006000fd5b506004361061003b5760003560e01c8063771602f714610041578063c3da42b81461005d5761003b565b60006000fd5b61005b600480360381019061005691906100ba565b61007b565b005b610065610097565b6040516100729190610109565b60405180910390f35b80826100879190610125565b60006000508190909055505b5050565b60006000505481566101d3565b6000813590506100b3816101b8565b5b92915050565b60006000604083850312156100cf5760006000fd5b60006100dd858286016100a4565b92505060206100ee858286016100a4565b9150505b9250929050565b6101028161017c565b825250505b565b600060208201905061011e60008301846100f9565b5b92915050565b60006101308261017c565b915061013b8361017c565b9250827fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff038211156101705761016f610187565b5b82820190505b92915050565b60008190505b919050565b7f4e487b7100000000000000000000000000000000000000000000000000000000600052601160045260246000fd5b565b6101c18161017c565b811415156101cf5760006000fd5b505b565bfea264697066735822122023e6550dca95b7639bddac283c9a25eeffea2cec5b91baf6becf24c3c9034fd064736f6c63430008040033

使用0.8.4 (无优化) 608060405234801561001057600080fd5b506101e8806100206000396000f3fe608060405234801561001057600080fd5b50600436106100365760003560e01c8063771602f71461003b578063c3da42b814610057575b600080fd5b610055600480360381019061005091906100a6565b610075565b005b61005f61008b565b60405161006c91906100f1565b60405180910390f35b8082610081919061010c565b6000819055505050565b60005481565b6000813590506100a08161019b565b92915050565b600080604083850312156100b957600080fd5b60006100c785828601610091565b92505060206100d885828601610091565b9150509250929050565b6100eb81610162565b82525050565b600060208201905061010660008301846100e2565b92915050565b600061011782610162565b915061012283610162565b9250827fffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffffff038211156101575761015661016c565b5b828201905092915050565b6000819050919050565b7f4e487b7100000000000000000000000000000000000000000000000000000000600052601160045260246000fd5b6101a481610162565b81146101af57600080fd5b5056fea26469706673582212205733a2d0235d969fa16994d7de6e82cf2340b83c0e583155bdc54777eed9ce6564736f6c63430008040033进行混炼

这两种代码都按预期运行(甚至对于更详细的合同也是如此)

因此，使用solcjs生成的代码不能在以太扫描中进行验证，以太扫描在验证过程中产生的字节码等于使用混合的字节码。

对这种差异有什么解释吗？在默认情况下，solcjs是否使用一些可以解释这些差异的选项？

Answer 1

这个问题似乎是solcj中的一个bug，请参阅这里。

使用solcjs --bin ./filename.sol并不表示优化标志，这应该是假的，但事实并非如此。正如上面链接中的@Kamil所描述的那样，这会生成一个代码，它不等同于将优化设置为false，也不等同于将其设置为true。

因此，生成的代码根本没有被优化(使用优化，false将仍然运行窥视孔优化器和跳跃式清除器)。

这样代码就更长了，因为根本没有优化，但是它是正确的代码。有关bug的更多信息，请参见这里。