- New EIP GitHub process and cleanup. [Facilitator: Hudson]
- Come to final agreement on EIP 196: EC addition and scalar multiplication on the elliptic curve
alt_bn128
, to be used in zk-SNARK verification. [Facilitator: Christian] - Update on EIP 197 for EC pairing precompile [Facilitator: Christian]
- Metropolis and associated EIPs. [Facilitator: Vitalik/Christian]
- EIP 5/8: Gas costs for return values [Facilitator: Christian]
- EIP 86: Proposed initial abstraction changes for Metropolis [Facilitator: Vitalik]
- EIP 96: putting block hashes and state roots into the state [Facilitator: Vitalik]
- EIP 100: uncle mining incentive fix [Facilitator: Vitalik]
- EIP 196 & EIP 197: pairings [Facilitator: Christian/Vitalik]
- EIP 198: bigint arithmetic [Facilitator: Vitalik]
- EIP 206: Revert OPCODE and EIP207: Encoding of revert OPCODE [Facilitator: Vitalik]
- EIP 116: New opcode
STATIC_CALL
follow-up. [Facilitator: Christian]
IN PROGRESS
- Address
8
assigned to precompile - Settled on 2 dimensional co-ordinates for curve points (x, y) rather than (X, Y, Z)
- Gas costs still to be determined
- Do costs vary based on the inputs?
- Implementations should be finished before gas costs finalise
- Number of input points to the function may be limited
- Gas price will probably be linear in number of EC points
- Needed for zk-snark verification to be efficient enough to actually use
- Gas costs still to be determined
- Multiplication gas costs may be complex (as the cost scales linearly with the size of the scalar being multiplied by), can be handled similiar to EXP gas costs
- go implementation: in progress
- Parity implementation: going to pull in from a library
- new rules only if the return size is 2^256-1
Nick: seems complicated, what about adding returndatasize
and returndatacopy
similar to calldatasize
and calldatacopy
that can access return data even if return area size was specified as zero
- Accounting for return values has turned out to be more complicated than people realised
- Vitalik says the suggested improvements seems over-complicated
- Decided to try and resolve offline rather than on-call.
- Allow a new type of transaction with signature 000000, sender address assumed to be 0xff..f
- Type of transaction where instead of the account, there's a destination, which is assumed to be a forwarding contract. The forwarding contract checks the transaction data for a signature, and if this signature is valid (according to rules defined in the forwarding contract), the transaction is passed along to its intended destination.
- abstract away account security
- abstract away nonces
- allows contracts to pay for gas
Things to be done:
-
Items 2 & 3 in EIP86 (get rid of things based on sender and nonce, and instead base on code and sender)
-
Implement new opcode
-
extra protocol things:
- logic in miner and logic in transaction propagating nodes
- check for regexp that says the account the transaction goes to will pay a fee to the miner
-
Partially implemented in go (apart from the mining/transaction propogation changes)
-
Can't drain contracts because the contract code is only executed if the signature (abstracted signature -- the one in the data field) is valid, so the contract only has to check the signature and then dismiss transactions. Cost of validating these signatures is approx equal to checking non-verifying ECDSA signatures anyway.
Christian Reitwiessner (cpp-ethereum/Solidity), Hudson Jameson (Ethereum Foundation), Arkadiy Paronyan (Parity), Vitalik Buterin (Research & pyethereum)