無法驗證合約 - 字節碼差異很小
部署後忘記驗證 ERC20 代幣合約。現在 5 個月後，我再次這樣做，完全忘記了哪個編譯器，如果我不小心更改了程式碼上的任何內容。
在玩過 Remix 之後，我發現我使用 v0.5.11 作為粗體十六進製文本 0b 表示十進制中的 11。您可以看到幾乎相同的 ByteCode，除了 BOLD 中的十六進制。這是整個字節碼的最後。如果您有任何線索，請提供幫助。
字節程式碼預期：
…… 6f6d20746865207a65726f206164647265737345524332303a2064656372656173656420616c6c6f77616e63652062656c6f77207a65726fa265627a7a72315820 55d977d29270099c12d5a11dea2a02d7991cc2c05448c6bd893bc1564278a96a 64736f6c63430005 0B 0032526f6c65733a206163636f756e7420697320746865207a65726f2061646472657373
字節程式碼從混音編譯：
…… 6f6d20746865207a65726f206164647265737345524332303a2064656372656173656420616c6c6f77616e63652062656c6f77207a65726fa265627a7a72315820 3fb4a2175649a2bc0e44a5cac18a7cafc7728139b46c3c1922298c8a2df8a0ab 64736f6c63430005 0B 0032526f6c65733a206163636f756e7420697320746865207a65726f2061646472657373
讓我們看看這裡發生了什麼。
在solidity v0.5.11 中，字節碼的結尾包括以下內容：
0xa2
0x65
627a7a7231 => 十六進制的“bzzr1”
0x58
0x20
<32 字節群散列>
0x64
736f6c63 -> 十六進制的“solc”
0x43
<3 字節版本編碼>
0x00
0x32
這正是你所擁有的。在你的兩個字節碼中 55d977d29270099c12d5a11dea2a02d7991cc2c05448c6bd893bc1564278a96a和3fb4a2175649a2bc0e44a5cac18a7cafc7728139b46c3c ,1922298c8a字節也被稱為元數據。元數據部分因開發環境而異，對智能合約程式碼沒有影響。因此，這兩個字節碼匹配同一個智能合約，你很好。
請注意，0x0032 ( 526f6c65733a206163636f756e7420697320746865207a65726f2061646472657373 ) 之後的部分是指建構子參數。實際上，您的兩個字節碼是作為部署事務的數據參數傳遞的創建字節碼。****執行時（或部署的）字節碼由創建字節碼產生，不包括建構子部分。