ethereum/pm

All Core Devs Meeting 16 Agenda

Souptacular opened this issue · 13 comments

Souptacular commented

All Core Devs Meeting 16 Agenda

Meeting Date/Time: Friday 5/19/17 at 14:00 UTC

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

  1. ERC-20 Token Standard Finalization [Fabian, Nick, or Hudson]
  1. Metropolis updates/EIPs.
  1. [Time permitting] "If we have time (no high priority), I would like to get some feedback about adding functionality that allows dapps to be notified whenever a certain address was touched by a transaction (including internal calls). This information does not necessarily have to be part of the block, but could be an isolated index database." [Christian R.]

Please provide comments to add or correct agenda topics.

vbuterin commented

Agreeing on gas costs for MODEXP, ECADD, ECMUL, ECPAIRING.

For MODEXP specifically, are we going to modify it to somehow incorporate bit length or not?

vbuterin commented

Another item: I am starting to get cold feet about the REVERT opcode being able to return data. My main concern is that it will break any applications that depend on being able to micro-charge for getting data. I do realize that such applications are not extremely secure in any case because the fee can always be circumvented via merkle proof magic, but even still such strategies always have some cost, and so there is opportunity for applications to be able to charge at least enough to pay back any fixed costs they have for transaction fees. I'm concerned that (i) we are introducing an economic change which breaks things, and that (ii) the marginal benefits of knowing why an error happened may not be worth the costs.

pirapira commented

An alternative without the economic change is REVERTLOG that almost aborts, but logs one event. So (benefit of REVERT) - (benefit of REVERTLOG) needs to outweigh the costs.

[EDIT: REVERTLOG needs to consume all gas, lest information can be encoded in the gas consumption]

pirapira commented

Item: proposal about freezing EIPs to allow time for testing.

Currently, no test cases are ready and stable because there are no indications which EIPs have stopped changing.

I propose introducing the notion of "freezing an EIP for Metropolis". Once EIPs are frozen for Metropolis, any change in the EIP that changes test cases needs to go through the All Core Devs meeting with the unanimous vote (it's meant to be hard, but not impossible, to achieve).

As an effect, when a frozen EIP has a critical problem, but if any party says they have not enough time to test the fix, the EIP would be dropped from Metropolis.

The first question is if we shall try to have this distinction "frozen". (Implementation details should come afterward: e.g. how to keep track of the frozen states; which EIPs to freeze first; shall we set the minimum duration between freeze and activation.)

pirapira commented

Item: was there a decision about opcodes of RETURNDATASIZE and RETURNDATACOPY?

I heard somewhere that that last coredev meeting decided that RETURNDATASIZE and RETURNDATACOPY shall move from 0xd and 0xe to some new opcodes, but I didn't attend it. I don't see the change in the EIP or in the last meeting's records (I found none). Was there a decision? If yes, what are the new opcodes? The EIP has been updated.

pirapira commented

Regarding EIP 96: should the gas price of BLOCKHASH already change from the beginning of the Metropolis, or from the block where the behavior of BLOCKHASH changes? https://github.com/ethereum/EIPs/pull/210/files#r117211219

chriseth commented

If we have time (no high priority), I would like to get some feedback about adding functionality that allows dapps to be notified whenever a certain address was touched by a transaction (including internal calls). This information does not necessarily have to be part of the block, but could be an isolated index database.

pirapira commented

Regarding EIP 211 (RETURNDATACOPY): the behavior of reading out-of-bounds from the returndata buffer is under discussion. We can at least gather opinions.

pirapira commented

Regarding EIP98 (med state removal): this should start at (inclusive) METROPOLIS_FORK_BLKNUM instead of one block after that (as written in the EIP). Pointed out by @gumb0 ethereum/EIPs#98 (comment)

pirapira commented

Regarding EIP96 (BLOCKHASH contract): should the blockhash-maintainance call at the beginning of each block increment the nonce of SYSTEM_ACCOUNT? https://github.com/ethereum/EIPs/pull/210/files#r117260179

arkpar commented

@chriseth We have transaction tracing for internal calls implemented in Parity. It allows to do exactly that - query for any changes for the account.

  • 🎉1
pirapira commented

@Souptacular I gave a wrong link about EIP211 discussion: the last point in 2.a. This should be under discussion. Currently, the link doesn't point to a discussion but to a test file. Sorry.

  • 👍1