Tim Beiko 6dbd82303b First pass

Signed-off-by: Tim Beiko <t.beiko23@gmail.com>

2023-01-04 10:01:39 -08:00

12 KiB

Raw Permalink Blame History

All Core Devs: Meeting 13

Time: 4/7/2017 14:00PM UTC (actually started at 13:00 UTC)

Audio/Video of Meeting

Agenda:

[2:58-8:49/13:20-19:54/39:38-41:46] Resolution for STATICCALL, PURECALL, REVERT Opcode, & Dynamic Return Discussion
[8:50] Update on EIP 225: Rinkeby and Clique PoA
[19:55] EIP 186: Reduce ETH issuance before proof-of-stake.
[41:46] Metropolis testing and client implementation updates.
[56:50] Unplanned topics (transaction propagation issues and potential solutions & making RETURNDATACOPY and CALLDATA to throw in certain situations).

Notes

1. Resolution for STATICCALL, PURECALL, REVERT Opcode, & Dynamic Return Discussion [Core Devs]

The parties interested in coming to a resolution on what EIPs from the list above to include were added to a Skype discussion and have come to the following conclusions:

Withdraw EIP 5: Gas Usage for RETURN and CALL* in favor of EIP 211.
Withdraw EIP 195: PURE_CALL in favor of other EIPs.
Include EIP 206: REVERT
Include EIP 211: RETURNDATACOPY and RETURNDATASIZE
Include EIP 214: STATIC_CALL

Christian R.: It was suggested that we clear the RETURNDATA buffer on the first memory resize (raised by Gavin in the EIP 211).

Nick: Not speaking for Gavin, but minimize the max memory consumption and allow for contiguous memory for the entire call stack rather than a separate chunk for each contract. Personally, I think it would be fine if it is designed to erase it after expansion so you can copy RETURNDATA into newly expanded memory.

Christian R: I would like to avoid that because it complicates things, such as the optimizer and static analysis.

[Christian, Nick, and Martin H.S continue to discuss this for the next few minutes.]

[At this point in the call I discover that I started the call 1 hour early because I can't time zone. Doh!]

Arkidiy joins the call and later provides this summary of the concern as well as summaries of concerns in the EIP comments.

Arkadiy: The concern is that the EIP increases max memory consumption. We have to keep returndata around from the call that you make, but if you expand memory before leaving returndata you will get higher peak memory usage.

Christian suggested having a separate call and discussion outside of all core devs call to talk about the concerns. Those who want to be involved can talk to Christian. It appears that there is already active discussion on the EIP page as well.

2. Update on EIP 225: Rinkeby and Clique PoA [Peter]

Next steps: Submit the EIP as a PR to begin process of official approval. Peter: We've been working on a tool to deploy these Rinqby private networks including a Github authenticated faucet. Still writing some tests, but otherwise mostly done from a Go team perspective. We are aiming to release an "Olympic testnet" version of Rinkeby for initial deployment and can make that implementation more important if it doesn't blow up.

3. EIP 186: Reduce ETH issuance before proof-of-stake [Hudson]

Carbonvote link. Reddit thread #1. Reddit thread #2.

Hudson: Haven't looked into this, but it seems to be getting some community traction so I added it to the agenda.

AVSA: My initial thoughts are that we should not be playing with the issuance or economic policies if things are not very broken. Additionally it would increase the controversy of the upcoming Metropolis hard fork that is currently non-controversial.

Martin H.S: I don't particularly support this, but I am curious at how large the community support is.

We discuss that carbon vote's website is running a poll on it, but we are skeptical about the reach and how it truly represents the community in this instance because this EIP is not widely being contentiously debated or discussed outside of Reddit posts and the EIP itself.

Nick: I generally think it is not a bad idea if it is greater than or equal to the amount they would have received with the ice age because at that point they are not likely to oppose the fork because they will be worse off.

Hudson: This may not even be a question of whether it should go on, but whether it should go in for Metropolis or should be discussed for a different hard fork (in order to avoid making Metro a big deal). Those who deal with economic policy and other related research fields have commented on this primarily, but this week many of them are in Malta at a conference and therefore aren't here to provide comment. I saw Vitalik write somewhere that he would be willing to consider it more seriously with enough community support behind the idea. What changes would have to happen on the technical end in order for this to go in?

Pawel: Change in code is super simple. My perspective is that this could make a less controversial hard fork a controversial one.

Hudson: So I'm wondering if it is better to implement this based on some possibilities that we aren't sure yet, but face the backlash of a more controversial hardfork and related complications, as well as setting precedence for changing core economic principles on a whim?

Peter: Aren't we already changing core economics by delaying the ice age?

Hudson: True, but this economic change is more of a side affect of preventing the impending block time changes that will affect the network.

AVSA: The ice age was never meant to be taken into prod. People never took it seriously that we wanted to slow the system down to a halt, it is just a mechanism to force a fork. No one believes we want to have a 10 min. block time. Idea was that PoS would be ready by then, but it is not, so the economic policy of the ice age should not really count. My fear is that we are taking something the community doesn't really want and are creating a discussion around it when it isn't truly widely recognized. I could be wrong though.

Martin H.S: I think it's a good thing we are talking about this because it shows that we are looking out for what is being discussed in the community even if we (core devs) aren't following it closely ourselves.

Hudson: Alex, I think that there is a level of legitimate support around this EIP, due to the fact that the EIP was written in Dec. 2016 before the recent price spike and Vlad's blog, which can be considered incentive to change this policy. I think the intentions behind the EIP are good so discussion is good. Like all of these things it comes down to the clients wanting to implement it and seeing how large the community push is for this change.

Alex B: Are we changing the block # for the ice age in Metro?

Peter: Idea was that we add special rules to the difficulty calculation to effectively pause the difficulty between different blocks #s.

We discuss if we are doing 1 or 2 hard forks for Metro/ice age changes. In previous dev meetings, we discussed having 1 HF for metro, so that seems like what we are doing.

We will bring this up next meeting to let some of the researchers, like Yoichi and Vitalik, comment on this.

4. Metropolis testing and client implementation updates [Dimitry and Core Devs]

Dimitry gives an overview of how the tests are coming along and what can devs do to help.

Dimitry: To make tests better it would help to have better indication in Github of which EIPs are included in Metropolis. It is hard to follow what is included.

Hudson will work on this by updating the tables on the README page and adding Github labels. We will also incorporate Alex B.'s EIP 233: Adding Meta EIP for Hard Forks.

Dimitry: As far as implementation, we already did REVERTCALL tests and I've seen some client implement general state tests. If client's submit their general state tests Martin H.S can run the tests on Hive once I convert them into generic blockchain tests. Every client that implements these protocol tests will be tested using Hive. Not every test is converted to Hive yet, but the general state tests are the most updated one. Transaction tests are halfway done. We are now using a branch on the test repository so every change will be in a different branch. Please review this document I have created and contribute feedback about the test coverage.

Hudson: Great. What is the best way to communicate with you to send data?

Dimitry: Gitter and Skype.

Updates from clients on Metro implementation of EIPs

Parity: We are almost done. Just waiting on finalization of the pending EIPs.
cpp-ethereum: We are somewhere in the middle, but don't have exact details on where we are at. It depends on the EIP, some are done and some are getting started.
Geth: Jeff is handling Metro EIPs, but has been busy recently. It appears that most of the metro EIPs are done.
pyethereum: We are mostly concerned with getting back to being able to sync to the main chain.

Basically, all EIPs that are going in to metro are finalized, but next meeting we will double check. Many of the EIPs are submitted, but the specs are being tweaked.

5. Other topics

Transaction propagation issues and potential solutions [Peter]

Peter: We have discussed this in the past, but we are trying to sort out how to sort out transaction propagation issues. One of the current issues with transactions are that they have an infinite lifetime. If I create a transaction today, it could be included now or in 10 years. The Bitcoin network was spammed last year and transactions that were sent as part of that spam persisted in the network for 8 months. It would be nice if we could avoid issues like that by saying a transaction has a limited lifetime to propagate cheap transactions easier. Does someone want to do an EIP on this?

Nick: I think this is a great idea. I will write an EIP on this.

[Additional discussion on this is included in the audio, including the breaking of offline signing of transactions.]

Making RETURNDATACOPY and CALLDATA to throw in certain situations [Nick]

Nick: I discussed this in some chat channels, but wanted to talk about the possibility of making RETURNDATACOPY throw if you attempt to copy beyond the end of RETURNDATA and CALLDATA in Metropolis to throw if a contract requests data beyond the end of the call data, instead of returning 0s. Motivation: Currently we pad it with 0's, but IMO this is us assuming what the user wants. This may help prevent the issues that exchanges had surrounding the Golem ERC20 token exchange implementation flaw (or attack).

Nick has been running some searches on the blockchain for contracts that seem to purposefully read past the end of call data. The only contracts so far that this has been found in is Augur related Serpent contracts due to a compiler optimizations in Serpent.

Discussion continues (see audio) about the balance of potentially breaking contracts that rely on this behavior (and potential EVM consistency and complexity) vs the benefits of making this change. Nick is going to comment on the existing EIP and continue his tests to discuss this issue more in the future.

Attendance

Alex Beregszaszi (EWASM), Andrei Maiboroda (cpp-ethereum), Arkadiy Paronyan (Parity), Casey Detrio (Volunteer), Christian Reitwiessner (cpp-ethereum/Solidity), Dimitry Khokhlov (cpp-ethereum), Frankie Pangilinan (MetaMask), Greg Colvin (EVM), Hudson Jameson (Ethereum Foundation), Konrad Feldmeier (pyethereum), Martin Becze (EWASM/EthereumJS), Martin Holst Swende (geth/security), Paweł Bylica (cpp-ethereum), Péter Szilágyi (geth)

12 KiB Raw Permalink Blame History