I am assuming that you are extending existing token contracts for the onlyOwner and _burn functionality.
When you do not use the function of the contract that you inherit from, the Solidity compiler will not include the bytecode of these into your contract. Therefore if you only reference your own variable the bytecode for onlyOwner and _burn is not present ...
The ABI or the Application Binary Interface is the standard to interact with the contracts. EVM uses the ABI encoded data to understand which part of the bytecode to execute.
When does it happen?
A contract interaction is just another transaction on ethereum. The payload/what-to-do is in the data field of the transaction. ABI encoding encodes the user's ...
You don't need ABI to deploy a smart contract, it is usually used by the abstraction layer of libraries to create dynamic objects that help developers with further calls, but it is not used in the deployment phase.
That said, you can copy and deploy an already deployed smart contract without any modification in 99% of the cases, but if there's peculiar ...
Your "opcode tool" link leads to a completely different address (0x9e1b57fc92eba6434251a8458811c32690f32c45). If you check opcodes for your original address, you'll see they're the same:
Of course you can. The ABI is not required to deploy any contract, you need it to verify it (not mandatory) and to interact with it in a simplified manner. For instance, you can deploy any ERC20 compliant contract to the blockchain, avoid to verify it, and still you will be able to interact with it using any ERC20 compliant call, generated whatsoever. Or, if ...
An unconventional of EXTCODECOPY is to use a deployed contract as the "storage" of another contract, as is is done by this library:
The rationale is that writing/reading data in the contract code region can become cheaper than writing/reading data in the storage region.
Cheaper storage reads (vs SLOAD) after ...