Closed vbuterin closed 2 years ago
@Smithgift Hm, okay. Is that syntax documented anywhere? I can't find any mention of it.
@vbuterin or anyone else: Will this proposal make it possible to send someone Ether without sending their address a message, but instead just sending a message to address 0
? If so, that prevents some of the complexity caused by having to account for malicious or broken recipients, but also means contracts can't "reject" ether like they can now.
That would also completely break wallets, so I doubt it.
@PeterBorah I believe it is both. The ether contract does not contact the receiving contract, but if there is common use of a cheque mechanism as described in the original post a contract can still reject ether. (Specifically, a contract would simply never accept the cheque.)
Pattern-match to make sure that gas payment code at the end is exactly the same as in the code above.
Doesn't this depend on the type of contract being used and the position the gas is sent in at? Will miners be able to pattern match for this kind of thing in general?
What will happen to the current balance residing at address 0
?
A tx.gas opcode is added alongside the existing msg.gas at index 0x5c; this new opcode allows the transaction to access the original amount of gas allotted for the transaction
Would it make sense implementing this separately, perhaps earlier? It is fixing an oversight in the current EVM.
Just as a reminder: With the release of an Ether-token some old contracts may become vulnerable. I had a look at wallet.sol
(https://github.com/ethereum/dapp-bin/blob/master/wallet/wallet.sol) the multisig wallet which is used by many. wallet.sol
is restricting transactions sending Ether with .value()
using multisig. Using Ether-tokens those transactions could be done only using the data
field. The multisig would become a shared wallet. It seems an easy auto-translation would not be possible.
@vbuterin:
# bytes 128-159: gasprice
# bytes 172-191: to
# bytes 192+: data
While reading the code, it seems these offsets are wrong and at offset 160 should be the to
.
~call(40000, 0, [SEND, block.coinbase, ~calldataload(128) * (tx.gas - msg.gas + 50000)], 96, 0, 0)
Can you also explain the format of the calls to the crypto contract? The above translates as:
bytes 0 - 31: command
bytes 32 - 63: account (token holder)
bytes 64 - 95: value
Can we make the crypto contract conform to ERC20 (token interface) and make calls accordingly?
Also here's an rough implementation in Solidity: https://gist.github.com/axic/528017d2d67801fa669fd75577c2093c. In order to be optimised a lot more would need to be moved to inline assembly, nullifying the benefit of Solidity.
Is there a chance to have a pre-compiled ed25519 signature check contract in the near future ?
I have submitted an EIP pull request for the ed25519 addition: https://github.com/ethereum/EIPs/pull/665
@picostocks cool.
Here are my comments on this blog post.
Wait, ~mstore(0, ~txexecgas())
is overwritten by the next line, ~calldatacopy(32, 96, ~calldatasize() - 96)
, which writes the length of the input data to the first word of memory. So I don't see what the point of that first line is.
This seems outdated according to the current yellow Paper version (equation 217), as it omits the gas limit after the gas price
# bytes 0-31: v (ECDSA sig)
# bytes 32-63: r (ECDSA sig)
# bytes 64-95: s (ECDSA sig)
# bytes 96-127: sequence number (formerly called "nonce")
# bytes 128-159: gasprice
# There should be a line here for bytes 160-161: gaslimit
# bytes 172-191: to
# bytes 192-223: value
# bytes 224+: data
Also for:
~mstore(0, ~sha3(0, ~calldatasize() - 64))
I don't understand why there is minus 64. The SHA3 function is
μ_s[0] ≡ Keccak(μ_m[μ_s[0] . . . (μ_s[0] + μ_s[1] − 1)])
μ_i' ≡ M (μ_i , μ_s[0], μ_s[1])
According to Appendix F in the Yellow Paper, the hash function excludes v, r and s, which makes sense. I think that line should change to have minus 96, not minus 64.
~mstore(0, ~sha3(0, ~calldatasize() - 96))
~call(5000, 3, [h, ~calldataload(0), ~calldataload(32), ~calldataload(64)], 128, ref(addr), 32) Blog post: ~call(5000, 1, 0, 0, 128, 0, 32) Note the difference. The blog post was posted on December 24 2015 while this issue was opened on 21 November 2015, so it's a while ago, but this issue is still open. The first line is more descriptive.
There are other differences which makes things confusing.
~mstore(0, msg.gas) % above code
~mstore(0, ~txexecgas()) % blog post
txexecgas seems more like tx.gas.
h = sha3(96, ~calldatasize() - 96)
~mstore(0, ~sha3(0, ~calldatasize() - 64)) % blog post
I suggest changing the above line to:
~mstore(0, ~sha3(0, ~calldatasize() - 96))
-64 doesn't make sense as you omit v, r and s (not just v and r) for the SHA3 opcode / Keccak function, as shown in appendix F, which can be found more easily in this version of the paper here, which has a document outline and extra features for readability. (A PR is here.)
Going back to: ~call(5000, 3, [h, ~calldataload(0), ~calldataload(32), ~calldataload(64)], 128, ref(addr), 32) Blog post: ~call(5000, 1, 0, 0, 128, 0, 32) "gas, to, value, in offset, in size, out offset, out size." However, it looks like the order of CALL for ECRECOVER (which would presumably need to be the same order for all call opcodes, unless you had a separate call opcode for ECRECOVER, or I am misunderstood) is changed in the above which I assume is like so: gas, ECRECOVER_CONTRACT_CODE_PRECOMPILE_ADDRESS, sequencenumber, in offset, to, outsize. Unless ref(addr) is the out offset at the to address, but it is ambiguous to me. I guess you can't have in size because that depends on the data field.
Is there any chance to get a secp256r1 (aka prime256v1 or NIST P-256) pre-compiled signature verification?
I believe there is a strong case for supporting this scheme, as it's the only one implemented natively in both Android's Trusted Execution Environment [1] and iOS' Secure Enclave [2]. This would allow for stronger security in the application layer for virtually all mobile wallet apps, and other third-party cryptographic hardware (as the NIST P-256 is the preferred standard of the hardware industry, rather than secp256k1).
[1] https://source.android.com/security/keystore/implementer-ref [2] https://www.apple.com/business/docs/iOS_Security_Guide.pdf
I think there is a concern that the NIST curve could have a backdoor, as another NIST curve was found to have a backdoor.
That's a hypothesis and I wouldn't discard it entirely.
However, assuming that secp256r1 is not backdoored by design, we get to significantly strengthen the mobile wallet security against a wider array of attack vectors (from side channels to memory dumps) as the cryptographic operations would be performed inside a dedicated hardware processor. I believe the gains are outweighing the risks for this one.
Sounds fair enough. I haven't done much research on this so it's hard to know for sure.
Is there any update(s) on this as to when it will be implemented?
@greggmojica : i guess i'ts gonna be difficult to have a date of implementation of this, as there's very few information about the implementation of EIP101.
It's not even listed in the main page of the repo unfortunately. I'm also quite interested in being able to follow the steps of development of this EIP as it is a major step for Ethereum Ecosystem.
@greggmojica @Asone discussion on this topic is continuing here https://ethresear.ch/t/tradeoffs-in-account-abstraction-proposals/263
@cdetrio : Thanks for pointing out ! Added to my favs.
Can i suggest to add the EIP in readme.md and point out the link to the new discussion or should it stay completely outside of the readme ?
This EIP is a major one, and even if far away of being implemented, easing users to find the new location will allow many to stay up to date about the discussion.
Much datalove
There has been no activity on this issue 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.
This issue 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.
Title
Specification
0
, we premine a contract which contains all ether holdings. Theeth.getBalance
command in web3 is remapped appropriately.msg.value
no longer exists as an opcode, and neither doestx.gasprice
tx.gas
opcode is added alongside the existingmsg.gas
at index0x5c
; this new opcode allows the transaction to access the original amount of gas allotted for the transactionNote that
ECRECOVER
, sequence number/nonce incrementing and ether are now nowhere in the bottom-level spec (NOTE: ether is going to continue to have a privileged role in Casper PoS). To replicate existing functionality under the new model, we do the following.Simple user accounts can have the following default standardized code:
This essentially implements signature and nonce checking, and if both checks pass then it uses all remaining gas minus 50000 to send the actual desired call, and then finally pays for gas.
Miners can follow the following algorithm upon receiving transactions:
msg.gas - 50000
as its gas limit parameter)This process ensures that miners waste at most 50000 gas before knowing whether or not it will be worth their while to include the transaction, and is also highly general so users can experiment with new cryptography (eg. ed25519, Lamport), ring signatures, quasi-native multisig, etc. Theoretically, one can even create an account for which the valid signature type is a valid Merkle branch of a receipt, creating a quasi-native alarm clock.
If someone wants to send a transaction with nonzero value, instead of the current
msg.sender
approach, we compile into a three step process:msg.value
opcode anywhere in the function that is being called, then we have the contract cash out the cheque at the start of the function call and store the amount cashed out in a standardized address in memoryRationale
This allows for a large increase in generality, particularly in a few areas:
It also substantially simplifies and purifies the underlying Ethereum protocol, reducing the minimal consensus implementation complexity.
Implementation
Coming soon.