Solidity Scratch Pad – Understanding Its Purpose in EVM and Assembly

assemblyevmmemorysolidity

I'm reading up on upgradable proxies, came across this in openzeppelin.

    //solium-disable-next-line
    assembly {
      // Copy msg.data. We take full control of memory in this inline assembly
      // block because it will not return to Solidity code. We overwrite the
      // Solidity scratch pad at memory position 0.
      calldatacopy(0, 0, calldatasize())

      // Call the implementation.
      // out and outsize are 0 because we don't know the size yet.
      let result := delegatecall(gas(), implementation, 0, calldatasize(), 0, 0)

      // Copy the returned data.
      returndatacopy(0, 0, returndatasize())

      switch result
        // delegatecall returns 0 on error.
        case 0 {
          revert(0, returndatasize())
        }
        default {
          return(0, returndatasize())
        }
    }
  }

Particularly I'm curious about this line " Solidity scratch pad at memory position 0.".

I understand the gist of this statement that we are writing the 0th position in our memory data type using assembly. But what is the "solidity scratch pad"? Why is it called that and what exactly does that mean. Does it have any significance?

Best Answer

A solidity scratch pad is a memory location for short term memory allocation. It is called that because it is used by proxy to write an arbitrary amount of data starting at position 0 because proxy doesn't care about overwriting allocating memory or respecting solidity memory model.

See:

https://forum.openzeppelin.com/t/upgradable-contract-assembler/9723

Related Solutions

Ethereum EVM – List of Available OPCODES

All of the opcodes and their complete descriptions are available in the Ethereum Yellow paper. For convenience, though, I've made a handy reference list of them all:

0s: Stop and Arithmetic Operations

0x00    STOP        Halts execution
0x01    ADD         Addition operation
0x02    MUL         Multiplication operation
0x03    SUB         Subtraction operation
0x04    DIV         Integer division operation
0x05    SDIV        Signed integer
0x06    MOD         Modulo
0x07    SMOD        Signed modulo
0x08    ADDMOD      Modulo
0x09    MULMOD      Modulo
0x0a    EXP         Exponential operation
0x0b    SIGNEXTEND  Extend length of two's complement signed integer

10s: Comparison & Bitwise Logic Operations

0x10    LT      Lesser-than comparison
0x11    GT      Greater-than comparison
0x12    SLT     Signed less-than comparison
0x13    SGT     Signed greater-than comparison
0x14    EQ      Equality  comparison
0x15    ISZERO  Simple not operator
0x16    AND     Bitwise AND operation
0x17    OR      Bitwise OR operation
0x18    XOR     Bitwise XOR operation
0x19    NOT     Bitwise NOT operation
0x1a    BYTE    Retrieve single byte from word

20s: SHA3

0x20    SHA3    Compute Keccak-256 hash

30s: Environmental Information

0x30    ADDRESS         Get address of currently executing account
0x31    BALANCE         Get balance of the given account
0x32    ORIGIN          Get execution origination address
0x33    CALLER          Get caller address. This is the address of the account that is directly responsible for this execution
0x34    CALLVALUE       Get deposited value by the instruction/transaction responsible for this execution
0x35    CALLDATALOAD    Get input data of current environment
0x36    CALLDATASIZE    Get size of input data in current environment
0x37    CALLDATACOPY    Copy input data in current environment to memory This pertains to the input data passed with the message call instruction or transaction
0x38    CODESIZE        Get size of code running in current environment
0x39    CODECOPY        Copy code running in current environment to memory
0x3a    GASPRICE        Get price of gas in current environment
0x3b    EXTCODESIZE     Get size of an account's code
0x3c    EXTCODECOPY     Copy an account's code to memory

40s: Block Information

0x40    BLOCKHASH   Get the hash of one of the 256 most recent complete blocks
0x41    COINBASE    Get the block's beneficiary address
0x42    TIMESTAMP   Get the block's timestamp
0x43    NUMBER      Get the block's number
0x44    DIFFICULTY  Get the block's difficulty
0x45    GASLIMIT    Get the block's gas limit

50s Stack, Memory, Storage and Flow Operations

0x50    POP         Remove item from stack
0x51    MLOAD       Load word from memory
0x52    MSTORE      Save word to memory
0x53    MSTORE8     Save byte to memory
0x54    SLOAD       Load word from storage
0x55    SSTORE      Save word to storage
0x56    JUMP        Alter the program counter
0x57    JUMPI       Conditionally alter the program counter
0x58    PC          Get the value of the program counter prior to the increment
0x59    MSIZE       Get the size of active memory in bytes
0x5a    GAS         Get the amount of available gas, including the corresponding reduction
0x5b    JUMPDEST    Mark a valid destination for jumps

60s & 70s: Push Operations

0x60    PUSH1   Place 1 byte item on stack
0x61    PUSH2   Place 2-byte item on stack
…
0x7f    PUSH32  Place 32-byte (full word) item on stack

80s: Duplication Operations

0x80    DUP1    Duplicate 1st stack item
0x81    DUP2    Duplicate 2nd stack item
…
0x8f    DUP16   Duplicate 16th stack item

90s: Exchange Operations

0x90    SWAP1   Exchange 1st and 2nd stack items
0x91    SWAP2   Exchange 1st and 3rd stack items
…   …
0x9f    SWAP16  Exchange 1st and 17th stack items

a0s: Logging Operations

0xa0    LOG0    Append log record with no topics
0xa1    LOG1    Append log record with one topic
…   …
0xa4    LOG4    Append log record with four topics

f0s: System operations

0xf0    CREATE          Create a new account with associated code
0xf1    CALL            Message-call into an account
0xf2    CALLCODE        Message-call into this account with alternative account's code
0xf3    RETURN          Halt execution returning output data
0xf4    DELEGATECALL    Message-call into this account with an alternative account's code, but persisting the current values for `sender` and `value`
0xf5    CREATE2         Create a child contract with a deterministic address

Halt Execution, Mark for deletion

0xff    SELFDESTRUCT    Halt execution and register account for later deletion

[Ethereum] How to return dynamic sized array’s original address on the memory of Solidity

Revised as previous answer wasn't completely true as it is possible in memory, but it can only be done in assembly and is quite involved. I've been looking at this quite a lot recently and your issue is primarily down to a memory pointer. There is two reasons why the above won't work in direct memory; the first is the msize opcode should point to the largest accessed memory index, but it doesn't which is being overwritten. The second is that we need to discard the data type size as this will automatically be allocated by the EVM.

As you can see from your example mload is using 0x40 (in memory this will reference bytes 64-96) which is the currently allocated memory size (msize) and is making the msize point to 0x20 (byte 32).

Layout in memory

Solidity reserves three 256-bit slots:

0 - 64: scratch space for hashing methods

64 - 96: currently allocated memory size (aka. free memory pointer)

Scratch space can be used between statements (ie. within inline assembly).

Solidity always places new objects at the free memory pointer and memory is never freed (this might change in the future).

Source: http://solidity.readthedocs.io/en/develop/miscellaneous.html#layout-in-memory

msize

"size of memory, i.e. largest accessed memory index"

Source : http://solidity.readthedocs.io/en/develop/assembly.html#opcodes

From the source code:

msize (note that msize also depends on memory read access)

Source: https://github.com/ethereum/solidity/blob/18a72dbe4668e23aaf38404183b978fbbb1824d1/libevmasm/SemanticInformation.cpp#L63

Example of a test resetting the msize:

(mstore 0x40 0)     ; Set initial MSIZE to 0x60

Source: https://github.com/ethereum/solidity/blob/6cbb726fb8970c6cb98e9b6a2928ef612ad9d760/test/liblll/EndToEndTest.cpp#L641

Because the code uses a return, it halts execution and returns the value stored in memory which is being referenced.

"end execution, return data mem[p..(p+s))"

Source : http://solidity.readthedocs.io/en/develop/assembly.html#opcodes

This will freeze the state of the memory and return the value of the memory which you reference.

In memory solution

Let's look at returning a broken value by altering the code to something like:

contract C {

    function c() public returns (uint[]) {
        return f(1,2);
    }

    function f(uint a, uint b) private returns (uint[] memory memOffset) {
        assembly {
             // Create an dynamic sized array manually.
             // Don't need to define the data type here as the EVM will prefix it
             mstore(add(memOffset, 0x00), 2) // Set size to 2
             mstore(add(memOffset, 0x20), a) // array[0] = a
             mstore(add(memOffset, 0x40), b) // array[1] = b
        }
    }
}

We now get an array with invalid values, this is due to additional operations being executed by the contract which is overwriting the memory you allocated. To fix this we need to move where we are writing memory to and let the evm know where the msize should be pointing to.

contract C {

    function c() public returns (uint[]) {
        return f(1,2);
    }

    function f(uint a, uint b) private returns (uint[] memory memOffset) {
        assembly {
             // Create an dynamic sized array manually.
             // Don't need to define the data type here as the EVM will prefix it
             memOffset := msize() // Get the highest available block of memory
             mstore(add(memOffset, 0x00), 2) // Set size to 2
             mstore(add(memOffset, 0x20), a) // array[0] = a
             mstore(add(memOffset, 0x40), b) // array[1] = b
             mstore(0x40, add(memOffset, 0x60)) // Update the msize offset to be our memory reference plus the amount of bytes we're using
        }
    }
}

The above should now return the correct value.

Previous answer:

Dynamic arrays cannot be stored in memory due to their nondeterministic size. Basically, if you have a dynamic array which has a incremental growing and shrinking storage you would have to either constantly keep shuffling around the memory, risk overwriting existing memory or reserve a large block of memory which is incredibly inefficient and gas heavy. Other programming languages resolved this issue using dictionaries and linked list structures where you reference various memory locations instead of a sequence of memory. The reason why its possible to do in the stack/storage is because it optimizes the storage similar to a linked list, but this hasn't been applied to the use within memory. In short arrays in Solidity are far from complete and need some work yet, so I would consider using other techniques such as storing data as bytes.

Best Answer

Related Solutions

Ethereum EVM – List of Available OPCODES

[Ethereum] How to return dynamic sized array’s original address on the memory of Solidity

Related Topic