Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Create pure_call.md #195

Closed
wants to merge 2 commits into from
Closed

Create pure_call.md #195

wants to merge 2 commits into from

Conversation

vbuterin
Copy link
Contributor

@vbuterin vbuterin commented Jan 26, 2017

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
Copy link
Contributor

gcolvin commented Jan 26, 2017

Does that mean it can only make pure calls itself?

@vbuterin
Copy link
Contributor Author

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
Copy link
Contributor

gcolvin commented Jan 26, 2017

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
Copy link
Contributor Author

vbuterin commented Jan 27, 2017

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

### Parameters

* BASE_GAS_COST: 80
* CODE_BYTES_PER_GAS: 15
Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

What revisions do you have in mind?

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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.

Copy link
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@Arachnid
Copy link
Contributor

Arachnid commented Feb 21, 2017

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
Copy link
Contributor

What will ADDRESS return?

@chriseth
Copy link
Contributor

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

@holiman
Copy link
Contributor

holiman commented Mar 19, 2017

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
Copy link
Contributor

@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
Copy link
Contributor

holiman commented Mar 19, 2017

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
Copy link
Member

axic commented Mar 19, 2017

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
Copy link
Contributor

holiman commented Mar 19, 2017

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
Copy link
Contributor

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


* Adding functional programming features for higher-level languages
* Generally allowing for forms of computation that are safer and can be efficiently optimized/memoized due to their state-independence
* Processing validation code for Casper validators in the future
Copy link
Member

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Please waive the copyright with CC0.

@axic
Copy link
Member

axic commented Dec 12, 2017

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
Copy link
Contributor

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
Copy link
Contributor

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

@fulldecent
Copy link
Contributor

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.

@axic axic mentioned this pull request Jun 22, 2019
@axic axic added the type: Core label Jul 4, 2019
@MicahZoltu
Copy link
Contributor

@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
Copy link

github-actions bot commented Nov 4, 2020

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 github-actions bot added the stale label Nov 4, 2020
@github-actions
Copy link

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.

@github-actions github-actions bot closed this Nov 11, 2020
@MicahZoltu MicahZoltu deleted the vbuterin-patch-1 branch December 25, 2020 01:37
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.