10

I wrote an article that goes over this information in depth. I will summarize it here. tl;dr - There are only two types of bytecode on Ethereum but five different names to describe them. Creation Bytecode This is the code that most people are referring to when they say bytecode. This is the code that generates the runtime bytecode—it includes constructor ...


4

Surely, you may do this. Here are high-level steps: To the end of your bytecode append a few additional opcodes that copy stack and storage content into memory and return them together with memory content. Prepend you bytecode with a simple constructor that will just deploy your bytecode as a contract. Deploy modified bytecode and obtain deployed smart ...


4

Unfortunately, you cannot store the deploying contract's bytecode as a variable in the contract directly, as that creates a circular reference. From the docs: This property can not be accessed in the contract itself or any derived contract. It causes the bytecode to be included in the bytecode of the call site and thus circular references like that are ...


4

That's because they are not the same thing. When you execute the getCode(...) function, you get the deployed bytecode of a specific address, as the docs says. The bytecode on the blockchain is the result of the execution of the compiled bytecode of your contract, which includes initialization code. About the contract you provide, which is verified: await ...


3

Sure. To deploy smart contract one needs to publish a transaction with empty to address and with data containing contract initialization code concatenated with values of constructor parameters. Initialization code usually consists of constructor byte code and contract's byte code to be deployed. So, deployed byte code does not contain constructor and ...


3

You can use ERC930 Eterenal Storage pattern in contract design, through which you can be use to write up-gradable contract by separating your contract's storage and business logic. I can came something what are you expecting to do (correct me if i'm wrong) in RocketPool's smart contract .


3

In remix you have selected ApproveAndCallFallBack as your selected contract. You need to select NicePointsToken as your contract. See my image attachment to know where to find the contractdropdown.


3

Compiler does not have to put function body into contract bytecode as a consequent range. Actually, optimizing compiler could decide to inline small functions used only in few places, i.e. copy their bytecode into every place the function is actually used. However, I believe, current versions of Solidity does not do this. The body of the unction usually ...


3

Why there are some contract addresses that do not have contract source code? Because the source code of a deployed contract becomes available on etherscan only after its author has verified it on etherscan.


2

You could store them in variables. Doing so would provide no assurance of fidelity with the actual contract as would rely on the deployment ceremony doing it honestly. Another issue is you would have to convert the ABI to Hex or find another way to escape the quotes. pragma solidity 0.5.16; contract SimpleIntrospection { bytes public BYTECODE; ...


2

I'm really not an expert in this but I would imagine (mostly) no, especially if optimization is turned on. There is no need for the bytecode to include any indications of the original language so including such details would be a waste of space - each extra byte costs gas. However I might imagine different language compilers to exhibit certain ...


1

Constructor arguments are passed during deployment, not during compilation.


1

Alternatively to Mikahil Vladimirovs answere, you could also implement a bytecode interpreter smart contract, which will parse the bytes within a loop, determine the opcodes and following data and finally execute the relevant EVM instructions in YUL code. For complete functionality, the interpreter smart contract must be called using "delegatecall". I think ...


1

Once your contract is deployed, you can use assembly code within solidity to access your byte code as seen in this example below. The benefit of this vs just saving a parameter is that you are confident this is actually the byte code of the contract. One downside is that trying to use this in the constructor I do not believe will work. assembly link ...


1

For your question no. 1: Search for "type": "constructor" in your ABI. From this object, you can see the inputs that has an array of parameters along with their name and type. Example: { "inputs": [ { "internalType": "uint256", "name": "_ff", "type": "uint256" }, { "internalType": "string", "...


1

No, the bytecode of a contract is generated by a compiler when your contract is compiled, not when it is deployed. When a contract is deployed, its address is deterministically computed based on the address of the creator. See this question for how contract addresses are computed.


1

I'm unsure what Rattle was referring to. Do you have a link or a reference to their exact phrasing? If they said exactly "32 elements in the stack", then that's incorrect. The stack has a maximum size of 1024 entries, where each entry is 32 bytes. Yes, the memory has a maximum side of 2^256 entries, where each entry is a byte, which is far more memory than ...


1

Basically, yes to your first question. The Solidity compiler generates native EVM code and wraps it in a function that causes the EVM to create a contract and give it that code. It's worked this way since the beginning, so any contract creation transaction data from previous versions of Solidity should still work. There aren't that many reasons that you'd ...


1

Yes, it is possible, but the means to do it would probably be bad form. Read contract storage directly, as Mikhail suggests. This involves finding your way around. Probe it. Attempts to access array elements beyond the length boundary will fail. It's nice to know there are possibilities in the case of a production contract that cannot be amended. On ...


1

Sure, this is possible. Size of dynamic array is stored in contract's storage along with array elements. Particular address in storage, where the size of array is stored, depends on how the array is defined. See this page for details. You may use this function to read smart contract's storage.


1

Bytecode only includes the original contract code. All the subsequent data is in transactions and I assume you mean the size of an array which is modified after contract deployment. So I already gave you a hint. The array is modified only in the constructor (upon deployment) and in transactions. Therefore you "only" need to look at the constructor code and ...


1

According to ethereum yellow paper, it is like a simple not operation in any other programming language. You can search for the use of not operation on many case but they mostly use so that you dont have to check for many condition: https://stackoverflow.com/questions/4775379/using-not-operator-in-if-conditions.


Only top voted, non community-wiki answers of a minimum length are eligible