Sharding related opcodes

[jannikluhn]

In the current sharding implementation we introduce some additional opcodes: SIGHASH (ethereum/py-evm#226), PAYGAS (ethereum/py-evm#234), and CREATE2 (ethereum/py-evm#224). We write user account contracts that use (some of) these opcodes with Vyper LLL. To successfully compile these contracts we currently have to monkey-patch Vyper:

from viper.opcodes import opcodes
opcodes['PAYGAS'] = [0xf5, 1, 0, 0]
opcodes['SIGHASH'] = [0x3f, 0, 1, 0]

While this works fine, it would be nice to have them usable from Vyper-LLL directly. At the same time, one should probably not be able to use those when compiling for Ethereum 1.0.

In the long run it might make also to make sense to add something like tx.sig_hash and maybe paygas(gas_price) to Vyper itself.

I haven't created a VIP because I'm unsure of how best to do this. Two options could be to (temporarily?) create a separate sharding branch or to add a target_protocol flag to the compilation functions.

See also: ethereum/py-evm#266

[fubuloubu]

I see no problem with directly adding these opcodes right now, but in order to build implementation around them, I think there needs to be a good discussion about what they are, how they work, and what the tradeoffs could be.

For example, PAYGAS, based on your example implementation, looks like you need to supply the gas price to it, which means someone needs to decide what that gas price is, either hardcoded in contract method or softcoded as an input. Softcoded as an input strikes me as a potential attack vector, what if someone chooses a really large gas price (like 1 Eth/gas) for a trivial transaction that pays for it's own gas and that attacker mines it's own transaction to steal the funds from a contract. Conversely, if it is hardcoded, it won't be able to adjust to market conditions, like right now with the really high gas prices we have been facing.

[NIC619]

Softcoded seems more reasonable to me. In my understanding, PAYGAS should be triggered only after some verifications of the transaction data is done so miner won't be able to drain the contract's fund unless he can provide valid proofs, e.g. a valid signature, in transaction data. But of course if the contract was not designed to verify the transaction before paying to miner then miner will be able to replay the same transaction to drain all the funds.

[jannikluhn]

See https://ethresear.ch/t/tradeoffs-in-account-abstraction-proposals/263 for discussion of the actual functionality.

[jacqueswww]

Looks good, might make sense to do it all in one shot tx.sig_hash and paygas function included, just putting them in the LLL seems to defy the purpose. @DavidKnott I think we create 2x issues for each opcode / function ? @jannikluhn not sure what would be a good function name for CREATE2 we currently have a function named create_with_code_of ?

[DavidKnott]

@jannikluhn We talked about this on our biweekly Vyper call and we're going to make a Vyper sharding branch.

[DavidKnott]

See here https://github.com/ethereum/vyper/tree/sharding

[jannikluhn]

@jannikluhn not sure what would be a good function name for CREATE2 we currently have a function named create_with_code_of ?

The difference between CREATE and CREATE2 seems to be that CREATE2 takes an additional salt parameter. Therefore, would it be an option to overload create_with_code_of (salt given --> CREATE2, no salt given --> CREATE)?

@NIC619 is implementing CREATE2 right now in ethereum/py-evm#269, maybe he's got better suggestions.

[NIC619]

Will create_with_code_of stay as is? I might be mistaken, but it seems create_with_code_of currently only deploys a hardcoded contract?
If so, what about saving this name for CREATE2 and rename original hardcoded contract deploying function to something specific like create_validation_contract, create_sanity_check_contract(or whatever the hardcoded contract is for) etc.?

[jacqueswww]

@NIC619 @jannikluhn just want to check 'CALLBLACKBOX': [0xf5, 7, 1, 700] is already in opcodes at 0xf5, is it OK to override it? I think it was also just another proof-of-concept opcode.

[DavidKnott]

@NIC619 That sounds like a good idea to me!

[jamesray1]

According to the draft phase 1 spec the EVM won't be specified until phase 2.

[jacqueswww]

Closing as this isn't relevant anymore. Rather open a new issue for anything related.