All Core Devs Meeting 16 Agenda

[Souptacular]

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]

• Point of contention: throw vs return false;

2. Metropolis updates/EIPs.

• a. Details and implementations of EIPs.
  • "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?" [Vitalik]
  • Concerns around the REVERT opcode introducing an economic change that may break things and revisiting cost/benefit analysis of the opcode. [Vitalik]
  • "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?" More info: https://github.com/ethereum/EIPs/pull/210/files#r117211219 [Yoichi]
  • "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" [Yoichi]
  • "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 Remove medstate from receipts EIPs#98 (comment)" [Yoichi]
  • "Regarding EIP 211 (RETURNDATACOPY): the behavior of reading out-of-bounds from the returndata buffer is under discussion." [Yoichi]
• b. Updates to testing.
  • Proposal: "Freeze" EIPs to allow for testing. [Yoichi]
• c. Any "subtleties" we need to work out.
• d. Review time estimate for testing/release.

3. [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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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]

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

[pirapira]

@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.

[Souptacular]

Notes are here: https://github.com/ethereum/pm/blob/master/All%20Core%20Devs%20Meetings/Meeting%2016.md

Closing issue.