Hot answers tagged

91

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 ...


47

Compilation back to the original source code is impossible because all variable names, type names and even function names are removed. It might be technically possible to arrive at some source code that is similar to the original source code but that is very complicated, especially when the optimizer was used during compilation. I don't know of any tools ...


31

The Yellow Paper is actively maintained and should always be current, and it's not as easy as a table, but the gas costs are there in Appendix G. Fee Schedule and read it with Appendix H. Historically: A spreadsheet of opcodes and their gas costs that Ethereum launched with are here. It has some analysis per How were gas costs chosen for the Ethereum ...


30

Even though I do not know the real reason, I will try to guess. There would be the following considerations: Size of the namespace. There are not so many possible opcodes, so these need to be allocated very sparingly. The space of contract addresses, on the other hand, is practically unlimited for all practical purposes. Risk of name re-use. It is a good ...


12

Not an authority, but I know of someone who is... From Vitalik's article, A Prehistory of the Ethereum Protocol The second was the idea of “precompiles”, solving the problem of allowing complex cryptographic computations to be usable in the EVM without having to deal with EVM overhead. We had also gone through many more ambitious ideas about “...


12

Yes, using storage has different gas costs: 20,000 gas when a value is set to non-zero from zero; 5,000 gas when writing to existing storage or setting a value to zero; and a 15,000 gas refund when a non-zero value is set to zero. The Yellow Paper is the underlying source.


11

As per the documentation you will find timestamp of the current block in seconds since the epoch so you have a single timestamp (when it is created) per block therefore time1=time2 read more about timestamp at Is the block.timestamp value in Solidity seconds or milliseconds?


10

A user on Reddit kindly posted an opcode-by-opcode analysis for you: PUSH1 0x60 PUSH1 0x40 MSTORE Store 0x60 at memory location 0x40. I think this is normally used for variable indexing if you have one. I've never got into the detail of this PUSH1 0x6 DUP1 Push 2 values of 0x6 into the stack. One is to be used as a parameter to CODECOPY, the other is to be ...


9

The Yellow Paper mentions an EVM opcode EXTCODECOPY which copies an account's code to memory. The answer appears to be yes: a contract can access the code of another contract. Solidity 0.3.1 now provides extcodecopy and other opcodes as part of its inline assembly feature: The following example provides library code to access the code of another ...


9

In a January 15 2016 blog post, Vitalik mentions: Ring signatures are more mathematically involved than simple signatures, but they are quite practical to implement; some sample code for ring signatures on top of Ethereum can be found here. Here is a snippet: def verify(msgHash:bytes32, x0:uint256, s:uint256[], Ix:uint256, Iy:uint256, pub_xs:uint256[...


9

Within the assembly code, _data is the memory address of the start of the array data. However, the first memory word (32 bytes = 0x20 bytes) is reserved for the length of the array, so we need to step over this. Thus, _data[0] is at memory address _data + 0x20. In the code, this looks like add(_data, 0x20). The array elements follow consecutively, ...


7

In reference to your comment about transaction timestamps, the timestamps of all transactions in a block are the same. There can be many transactions in a block, all have the same timestamp, and all are the same timestamp as the block's.


7

The "data" section mentioned in the yellow paper is the part that follows the PUSH instruction, i.e. the yellow paper only talks about push data. What you see in the assembly output is a higher-level concept. The (init code of the) blank contract copies the final contract code from code into memory and then returns that. Both the final contract code and ...


6

Yes, they are indeed available now in Solidity as opcodes in assembly, along with CREATE2, and you are free to use them. However, for the time-being they will just fail with "invalid opcode" if any pre-Metropolis EVM tries to execute them - i.e. any node on the current main net. I think the intent here is to allow for pre-release testing of Metropolis using ...


6

Each word in the EVM is 32 = 0x20 bytes wide, so when you use PUSH1 40 to store a word at 0x40 it fills up all the bytes up to 0x5f. The EVM uses "big-endian" format, so the least significant bytes of the word are stored at the end. Thus the byte "0x60" is correctly written to location 0x5f in your example. The layout of the data from Browser Solidity is a ...


6

CREATE, in a way, does a built in CALL. What actually happens is that the data passed to call isn't the contract bytecode, it's the init bytecode. When CREATE opcode is executed, the EVM creates a call frame in the context of the new contract (e.g. address(this) is the new contracts address). This executes the data passed to CREATE as the code, which in ...


5

There is a project Porosity now https://github.com/comaeio/porosity It's also integrated into Quorum toolchain https://www.coindesk.com/first-ethereum-decompiler-launches-jp-morgan-quorum-integration/


5

Yes, the compiler handles the pointer functionality. You do not need to explicitly de-reference a storage pointer when you want to write to or read from the storage location it points to. I think the fact that they are called pointers is very confusing. It reminds me of C pointers, but storage pointers in Solidity are much more like C++ or PHP references ...


5

I can only give you a general guide on how to do this: 1) Modify core/vm/instructions.go to add your instruction code, something like: func opAdd(pc *uint64, evm *EVM, contract *Contract, memory *Memory, stack *Stack) ([]byte, error) { x, y := stack.pop(), stack.pop() stack.push(math.U256(x.Add(x, y))) evm.interpreter.intPool.put(y) ...


5

Awesome! That is a great way to learn about the EVM. The answer may be verbose but it will be complete. Two's Complement Two's complement is a way to represent integers in binary. It enables us to easily and simply express signed integers (pasted for convenience; see source for more details): Suppose we're working with 8 bit quantities (for simplicity's ...


5

I managed to fix it by explicitly defining the EVM version in my truffle config file. It's still weird because Remix supports this (as seen in the attached image) as well but still fails. compilers: { solc: { version: "0.6.0", settings: { optimizer: { enabled: true }, evmVersion: "petersburg" } } ...


4

I've written another disassembler to help me understand some of this stuff, and because I really wanted offsets beside the instructions. You can find it here. https://github.com/jamiehale/evm_disasm


4

A SUICIDE operation is effective at the end of the transaction. I can replicate the issue, so it likely is a bug in the geth traceTransaction implementation, where the other prior transactions in the block are not taken into account. Edit: this bug has been fixed


4

In general as other users commented it is not possible to get back the original source code in practice. In theory, however, both compiled and source applications should produce exactly the same output (i.e. have the same semantics) so it should be possible to get a program in source code representation that does exactly the same thing as the bytecode. ...


4

block.timestamp is the value what miner decides to publish there when he or she finds a block. It is subject to some interpretation and can be skewed, though only for a while: How would a miner cope with a huge block time? How does Ethereum avoid inaccurate timestamps in blocks? https://ethereum.stackexchange.com/a/428/620


4

This is probably a result of the technology moving faster than updates to the yellow paper. Your best bet is to go to the source. Pyethereum is a good source for readability. You can see the latest opcodes here (where 0xfd) is referenced. I would also look here for more details and a potential hint into invalid operations. EIPs such as the one for ...


4

Because if it was very large, then executing a contract would be more expensive (ie, require more memory). I think 1024 was a very conservative value to be as safe as possible I think the justification is that if you need that much stack space, then you should be offloading some of it to memory (which is practically unlimited, though you must pay gas for ...


4

How to separate functions in evm bytecode? Solidity will create a dispatcher block for function calls at the beginning of the bytecode. Similar to an if .. elseif .. elseif .. else Single function calls will follow the following repeating pattern: DUP1 PUSH4 <4-byte function signature> EQ PUSH2 <jumpdestination for the function> JUMPI From ...


3

What's being exploited? The attacker is exploiting a combination of inadequate pricing (too cheap) for specific EVM operations and inefficient client implementation of that operations (mainly geth which is the most widely used one). This specially crafted "bad transactions" cause a lot of I/O on the clients, resulting in many of them not being able to keep ...


3

The 2 arguments to the RETURN opcode are offsets into memory: the starting and ending offset. The EVM execution is stopped and data consisting of the memory bytes from [start, end-1] are the output of the execution. Example: If memory is [5, 6, 7, 8, 9, 10], a return with offsets 1, 4 would produce a result (output) of 3 bytes (6, 7, 8).


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