If I launch a smart contract on polygon mainnet and start interacting/testing it, is it possible for others to see my contract code without me verifying the code through polygonscan?
I think the answer is no...
If I launch a smart contract on polygon mainnet and start interacting/testing it, is it possible for others to see my contract code without me verifying the code through polygonscan?
I think the answer is no...
"Contract verification allows smart contract developers to prove and publish the source code of the contracts deployed on-chain."
As far as I understand the bytecode is always available, but it is created by encrypting your contracts code. It is kind of like a public key (bytecode) and private key (contract code)?
The bytecode is result of compiling your contracts, not encrypting.
The bytecode is the contract. As it says in the name, it "tells" the EVM what to do, just like when you run a binary program, it contains CPU instructions.
You can try to decompile a contract using a too like https://ethervm.io/decompile
I appreciate the help and the link. Fun fact polygonscan.com offers a similar thing now. I went to get the bytecode from an old contract to test it at the link you sent and I noticed an option available on polygonscan "Decompile bytecode." It was not very accurate though.
When I said encryption earlier I meant that compiling bytecode is one way without the original code, it can not easily be decompiled in a standard way. I still don't know if that's true or not but it seems like the current Decompile Bytecode stuff can get bits and pieces but not the whole picture.
Getting the exact code is impossible by decompiling. The best the tool can do is to represent in solidity what the bytecode represents.
Most explorers (scan. sites that forked from etherscan) have an option to decompile the contract available. ethervm.io is usually more accurate. It's output is probably more useful if you understand how the evm works and which instructions are represented.
Sometimes you will see something like this. The output isn't wrong, it's representing a POP
from the stack which discards the popped value. There are other
var_1 = 0x00
// ...
var_1 = 0x1234
// var_1 never gets used