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

Do not transfer ETH with selfDestruct #98

Open
chfast opened this issue May 27, 2018 · 5 comments · May be fixed by #113
Open

Do not transfer ETH with selfDestruct #98

chfast opened this issue May 27, 2018 · 5 comments · May be fixed by #113

Comments

@chfast
Copy link
Collaborator

chfast commented May 27, 2018

In EVM1 the SELFDESTRUCT is messy and complex due to the additional ETH transfer coupled with it.

  1. Simplify selfDestruct by removing its address argument and do no transfer ether. The ether is destroyed with the account.
  2. Add transfer() function that only transfers ether to other account. The target account's code is not executed. This function is needed to implement SELFDESTRUCT in evm2wasm.
@ehildenb
Copy link
Collaborator

@axic and I had a similar discussion about this yesterday (adding a seperate EEI method transferFunds and using that for the various call/selfdestruct). I think the concern was that then the owner of the contract being transferred to has no say in how to execute when people transfer into it. I think it's a good idea though, to add such a primitive transfer. People could take advantage of the safer transfer on the ewasm shard instead of an empty call.

@chfast
Copy link
Collaborator Author

chfast commented May 27, 2018

I'm aware of the cons of such transfer(). But you can emulate it in EVM1 by creating a temporary contract and selfdestructing it. Such ether transfer is unnoticed by the targeted contract.
If the evm2wasm is still a goal, i propose to have simpler EEI functions and have other EVM1 quirks implemented in evm2wasm so the eWASM is not polluted.

My questions is, can you implement fully compliant EVM1 SELFDESTRUCT having the EEI functions as described above?

@ehildenb
Copy link
Collaborator

I think so. I'm still working on the K spec for the EEI, and my focus is on conforming to the type signatures that eth_interface specifies, while using the EEI functionality directly with KEVM (so moving the logic out of KEVM that is needed into KEEI). If the KEVM tests pass with the KEEI, then we know it's possible.

@ehildenb
Copy link
Collaborator

Advantages of having an executable spec :P

@chfast
Copy link
Collaborator Author

chfast commented Jul 31, 2018

Changes proposed in #113.

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging a pull request may close this issue.

3 participants