Solidity Tutorial – Execute Raw Bytecode in EVM

bytecodeevmsolidity

Suppose, I have the following bytecode (0x610101610102016000526001601ff3) that pushes two numbers to the stack, adds them and returns the value.

Now I want to write a function in Solidity that will take this bytecode as input and return the final result (i.e., the final stack, memory, and storage contents after the execution inside EVM). How can I write this function? Is it possible to do so (for example – using the solidity assembly)? Please suggest. Thanks in advance.

Best Answer

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 contract address.
Call just deployed smart contract. This effectively will execute original bytecode and return stack, storage, and memory content after the execution.

The challanges here are how to determine stack depth and how to find out modified storage keys. May you make the bytecode being executed to follow some convention about these things, such as leave stack depth and storage keys on the stack after execution?

If you need to execute each bytecode only once, you may add SELFDESTRUCT opcode before RETURN in order to destroy the smart contract after the call.

Related Solutions

Solidity – Why Local Variables are Allocated to Storage Instead of Memory

It seems to be related to the data type that you're using. As TripleSpeeder noted, only complex data types (arrays and structs) default to storage inside functions, while all others default to memory.

Inside this StackExchange question is a description of the difference between memory and storage. To paraphrase one of the answers:

Storage is a key/value store where keys and values are both 32 bytes. Memory is a byte-array. Memory starts off zero-size, but can be expanded in 32-byte chunks by simply accessing or storing memory at indices greater than its current size.

A consequence of this design difference is that storage is dynamic and memory is not. Because arrays and structs are complex and could be of variable length, they are defaulted to storage, which has this key:value behavior. Simpler variables like bool, uint, et cetera are not variable in length, and are therefore defaulted to memory, which is cheaper than storage. So, think of the design choice as a compromise between flexibility and cost.

It is possible to create memory arrays, but once created they cannot be resized (check out the Allocating Memory Arrays section).

Passing Storage Structure Addresses Between Solidity Contracts

Instinctively, I believe that the only solution is to pass the structure to the function "by address"

You cannot access the physical addresses of storage variables (like you can with C), this is not allowed in Solidity. The address type is only used to refer to the addresses of other accounts (contract or external), and is not used to refer to memory addresses.

A work around would be to use a smart contract to store your data instead of a struct. This way you would be able to pass the address of the smart contract around instead of having to pass the data around. I've posted an example below:

contract Person {
    uint public age;
    uint public weight;

    function Person(uint _age, uint _weight) public {
        age = _age;
        weight = _weight;
    }
}

contract PersonHolder {

    address[] public people; // Could use Person[] here

    function addPerson(uint age, uint weight) public {
        people.push(new Person(age, weight));
    }

    function getPerson(uint index) public view returns (Person) {
        require(people.length > index);

        return Person(people[index]);
    }
}

Best Answer

Related Solutions

Solidity – Why Local Variables are Allocated to Storage Instead of Memory

Passing Storage Structure Addresses Between Solidity Contracts

Related Topic