Create pure_call.md

[vbuterin]

At 0xf5, add an opcode PURE_CALL that takes seven arguments from the stack: GAS, CODESTART, CODELENGTH, DATASTART, DATALENGTH, OUTPUTSTART, OUTPUTLENGTH. Processes a call with the given code and data that cannot read or write state, and pastes the result into the output memory slice.

[gcolvin]

Does that mean it can only make pure calls itself?

[vbuterin]

Does that mean it can only make pure calls itself?

Not sure I understand; what do you mean?

The EIP as written does not allow the child context to make any calls except for pure precompiles in order to guarantee state independence. I suppose you could allow the child context to itself make PURE_CALLs if you really want to, though there isn't too much additional value gained from that.

[gcolvin]

Given how tiny contracts are, it provides a safe way to break a program into small, safe pieces, with all state interaction carefully isolated.

[vbuterin]

Ok. I have no problem with allowing pure calls from inside a pure call context; we can do that.

[chriseth]

Assuming we want to switch to EVM 1.5 - is that really the amount of gas we want to charge? Or shall we completely revise the scheme with 1.5?

[gcolvin]

What revisions do you have in mind?

[chriseth]

Perhaps to add some more explanation: In EVM1.5, code that is about to be executed needs to be analyzed and sightly processed first. For regular contracts, this is done once at creation time and we can use the gas from the code deposit to pay for this preprocessing. Here, 15 bytes per gas could be too low for that.

[gcolvin]

Agreed. Not sure what the right amount is, as the preprocessing can run from simple validation to full compilation.

[Arachnid]

Please make compliant with EIP-0 (eg, add a header with number/status etc), renumber to EIP 195 (or the issue number), and update in response to any comments, and tag with editor-needs-to-review when it's ready for merge.

[obscuren]

What will ADDRESS return?

[chriseth]

I would say that address is also part of the state, so it should fail.

[holiman]

The EIP says it may make calls to non-state-changing precompiles. For forward compatibility; I'd like to clarify so it's clear that any non-state-changing precompiles that are added in the future are automatically included in the set of allowed precompiles.

[obscuren]

@chriseth yes, actually all auxiliary data including state read/write any calls with the exemption of non-state altering pre compiles will throw. Auxiliary includes address, coinbase, time, difficulty, blockheader, gaslimit

[holiman]

Also...

• CODESIZE returns CODELENGTH?
• 0-padding. Normally, CODECOPY and DATACOPY pads with zeroes when reading out of bounds. I presume it would do so here aswell.
• How about making CODE_BYTES_PER_GAS to 16, to make it into division by 16 instead of 15 ?

[axic]

CODESIZE returns CODELENGTH?

Isn't that a state reading operation and therefore forbidden?

The EIP says it may make calls to non-state-changing precompiles.

Is that actually a good idea? I think with time that might result in a very complex list of exceptions for CALL & co.

Ok. I have no problem with allowing pure calls from inside a pure call context; we can do that.

Also since PURE_CALL takes a memory location for code as opposed to an account, the only way it can make calls to other pure functions is by embedding the bytecode and storing it to memory.

[holiman]

The EIP says it may make calls to non-state-changing precompiles.
Is that actually a good idea? I think with time that might result in a very complex list of exceptions for CALL & co.

Well, if I remember correctly, all precompiles (including metropolis) are non-state changing. So it would be all precompiles, rather than a list of exceptions. I do see a point in pure calls being able to use e.g. bigint math and ecrecover.

Also since PURE_CALL takes a memory location for code as opposed to an account, the only way it can make calls to other pure functions is by embedding the bytecode and storing it to memory.

Yes, asides from the precompiles. So what is currently suggested in the EIP, afaict, is

• Allow CALL to precompiles
• Allow PURE_CALL (and thus provide the code along with it)

[Arachnid]

Please update to follow the template here and rename to EIP-195.md, and we'll merge as draft.

[pirapira]

Please waive the copyright with CC0.

[axic]

I think two versions of this instead the current proposed one would make more sense:

1. Would read from code offset and length within the current contracts code. This means calling a function part of the callee contract wouldn't need to do a codecopy to memory first in order to pass it to purecall.
2. Load code from a destination address and execute it with restricting both state reading and writing operations (staticcall's counterpart). For rules on what are state reading operations one could refer to Solidity's categorisation: https://github.com/ethereum/solidity/blob/develop/libevmasm/SemanticInformation.cpp#L192-L218

Though for 2) practically it would need a new opcode to determine the current context type (ISPURE or a more generic approach is CALLTYPE to return regular, delegate, static, pure). At least Solidity checks that no value was sent in a call if the function doesn't expect it and that is done via the CALLVALUE opcode, which is restricted in the pure context.

[Arachnid]

This is a courtesy notice to let you know that the format for EIPs has been modified slightly. If you want your draft merged, you will need to make some small changes to how your EIP is formatted:

• Frontmatter is now contained between lines with only a triple dash ('---')
• Headers in the frontmatter are now lowercase.

If your PR is editing an existing EIP rather than creating a new one, this has already been done for you, and you need only rebase your PR.

In addition, a continuous build has been setup, which will check your PR against the rules for EIP formatting automatically once you update your PR. This build ensures all required headers are present, as well as performing a number of other checks.

Please rebase your PR against the latest master, and edit your PR to use the above format for frontmatter. For convenience, here's a sample header you can copy and adapt:

---
eip: <num>
title: <title>
author: <author>
type: [Standards Track|Informational|Meta]
category: [Core|Networking|Interface|ERC] (for type: Standards Track only)
status: Draft
created: <date>
---

[fubuloubu]

@pipermerriam we should revisit this proposal, specifically @axic's last comment, with @vbuterin in context of Casper

[fulldecent]

I propose a different PURECALL that is more like STATICCALL:

• Use the same arguments as STATICCALL: gas, to, in offset, in size, out offset, out size.
• Update Yellow Paper "This states that the execution is in an exceptional halting-state if..." to include "... state access is attempted during a pure call."

---

I do not like the proposed CODESTART, CODELENGTH parameters proposed above because that is effectively a JUMP without a JUMPDEST. Also the semantics of CALL are well understood. If we wanted the seven-argument opcode as above then I would call the GOTOPURE instead.

[MicahZoltu]

@vbuterin Do you still want to pursue this? If so it will need to be updated to match the latest EIP formatting requirements.

[github-actions]

There has been no activity on this pull request for two months. It will be closed in a week if no further activity occurs. If you would like to move this EIP forward, please respond to any outstanding feedback or add a comment indicating that you have addressed all required feedback and are ready for a review.

[github-actions]

This pull request was closed due to inactivity. If you are still pursuing it, feel free to reopen it and respond to any feedback or request a review in a comment.