Ethereum Core Devs Meeting 38 Agenda

[lrettig]

Ethereum Core Devs Meeting 38 Agenda

Meeting Date/Time: Friday 05/18/18 at 14:00 GMT

Meeting Duration 1.5 hours

YouTube Live Stream Link

Livepeer Live Stream Link

Agenda

1. Testing & EIP 1085: Common genesis.json format scheme across all client implementations
2. Client Updates
3. Research Updates
4. EIP 908: Reward clients for a sustainable network - When each transaction is validated, give a reward to clients for developing the client - When each transaction is validated, give a reward to clients for developing the client and provide a reward to full nodes for validating the transaction (Ethereum Magicians thread).
5. EIP 1057: ProgPOW, a programmatic Proof-of-Work - an alternate proof-of-work algorithm - “ProgPoW” - tuned for commodity hardware in order to close the efficiency gap available to specialized ASICs. Technical details.
6. EIP 210: Blockhash refactoring - @holiman wants to finalize a few points:
   a. the original intent (no semantic changes to BLOCKHASH -- only gas changes) versus the current spec (semantic changes), and
   b. whether to make it nicer to ABI-call it, and
   c. whether to add genesis lookup in there.
   d. Fixes for EIP-210 blockhash contract: EIP-210: Fixes for blockhash contracts EIPs#1094.
   See this summary document.
7. EIP 1051: Overflow checking for the EVM
8. EIP 1052: EXTCODEHASH Opcode
9. EIP 1087: Net gas metering for SSTORE operations
10. Concerns that using native browser VMs for running eWasm is not DoS hardened. See this comment and this comment.
11. Constantinople hard fork timing and what to include (continuing conversation from last call).
12. Core dev meeting discussion & changes - scope of agenda items, role of participants, etc.

Please provide comments to add or correct agenda topics.

[MysticRyuujin]

devcon4

[jamesray1]

I suggest continuing discussion on EIP 908 as well as to discuss adding a link to ethereum.org to the Ethereum wiki which contains a plenitude of useful information, including from basic and introductory information such as the White Paper, through to R&D info, dapp development, Ethereum technologies, infrastructure, Web3 technologies, and more. There's a PR for adding the link here.

[lrettig]

@jamesray1 re: EIP-908, do you know whether you, @MicahZoltu, or anyone else has made any progress on the thread Incentives for running full Ethereum nodes? In particular on formalizing this into an EIP?

[jamesray1]

@lrettig EIP-908 was created from that thread.

[jamesray1]

Since the last meeting I've added more reasons why I don't think a layer 2 solution is enough, such as that not everyone would use such a solution, so it would not be necessary; and why it is necessary for the sustainability of the protocol, plus other information. If users can get away without paying for fees for full nodes and clients then they will do so. I don't see how a layer 2 solution can make such fees mandatory. Feedback is welcome.

[jamesray1]

If users can get away without paying for fees for full nodes and clients then they will do so. I don't see how a layer 2 solution can make such fees mandatory.

[lrettig]

@jamesray1 roger that, added 908 to the agenda.

[fulldecent]

Topic request: Consider to change EIP-721 to FINAL status

Note: I am asking in this forum as specified by https://github.com/ethereum/EIPs/blob/master/README.md

Justification: I can cite three supporting implementations on both sites of the standard (producers and consumers):

PRODUCERS:

• CryptovoxelsProperty -- https://etherscan.io/address/0x3a81d175f3dfd76e5013a57772929ed85f7d6380#code
• KnownOriginDigitalAsset -- https://etherscan.io/address/0xdde2d979e8d39bb8416eafcfc1758f3cab2c9c72#code
• CryptoCrystal -- https://etherscan.io/address/0xcfbc9103362aec4ce3089f155c2da2eea1cb7602#code
• EthergotchiOwnershipV2 -- https://etherscan.io/address/0x449f5c827cf7726cc5f181090aa147ca5fb88a40#code
• SuSquares -- https://etherscan.io/address/0x6731560e455537c9f088ea02a47a0ecfa28a9231#code
• Dark -- https://etherscan.io/address/0x1f28211cd78363c7e0d44a90157017422599526c#code
• BlockchainCutiesCore -- https://etherscan.io/address/0xd73be539d6b2076bab83ca6ba62dfe189abc6bbe#code
• ChibiFighters -- https://etherscan.io/address/0x71C118B00759B0851785642541Ceb0F4CEea0BD5#code
• Etherbots -- https://etherscan.io/address/0xd2f81cd7a20d60c0d558496c7169a20968389b40#code
• CryptoKitties -- https://etherscan.io/address/0x06012c8cf97bead5deae237070f9587f8e7a266d#code (sort of)
• Decentraland -- https://etherscan.io/address/0x236db4283035d4f497e35bda4cab7965350a89e1#code (see also https://twitter.com/eordano/status/996123893105602560)

CONSUMERS:

• OpenSea - https://medium.com/@opensea/announcing-open-sea-4e90daa8c84
• NonFungibles.com - https://nonfungible.com/pages/cryptopunks/market/history
• OPSkins - https://blog.opskins.com/opskins-welcomes-cryptofighters/
• 0xcert scanner - NEED URL
• Rare Bits - https://rarebits.io/developers

[holiman]

@jamesray1 re 908.. It is, imo, not a proper EIP. I read it not as a technical specification of exactly what needs to be implemented when, but instead a discussion about an interesting idea. What I want from an EIP is to be able to see the exact steps that a client/evm/transaction processor will need to change.

Based on that, there can be a technical discussion about consequences, drawbacks, benefits, complexity etc. Right now, I think it's too vague to actually have a discussion around.

[ifdefelse]

Topic request: New Proof-of-Work algorithm?

ethereum/EIPs#1057
This PR describes a fully implemented algorithm based on ethminer code. It attempts to be permanently "ASIC-resistant" without the need for future small forks. The goal is to extend the runaway and allow for a gentle transition to Casper, minimizing network turbulence and maximizing time for Casper validation.

[fulldecent]

Regarding ethereum/EIPs#1057 I am against this proposal. The gentle transition to casper already has 18 steps. An unnecessary 19th step will not make the transition any better.

[ifdefelse]

@fulldecent If specialized mining ASICs start causing mining problems and minority-weight censorship attacks, would there still be time to implement an 18-step gentle transition to Casper?

[fulldecent]

That is a hypothetical attack.

If that envisioned attack were close to reality then we would know. When Ethereum was previously faced with a important and tough decision (TheDAO), changes were made in about 15 minutes.

Whereas the hypothetical attack is not imminent and whereas we could respond effectively if it became imminent and whereas such a change would be a distraction to the normal course of business now therefore such a change is not beneficial.

[jamesray1]

@holiman I updated the spec and rationale in the EIP, let me know what you think. There is still another pending merge so in the meantime read the diffs of https://github.com/ethereum/EIPs/pull/1060/files and ethereum/EIPs#1059.

https://eips.ethereum.org/EIPS/eip-908

You can comment at https://ethereum-magicians.org/t/eip-908-reward-full-nodes-and-clients-for-a-sustainable-network/24.

[ifdefelse]

@fulldecent
I don't have a good sense of how visible minority-selfish and cost-inflation strategies are. What's the best way to know whether this is happening or not?
https://cyber.stanford.edu/sites/default/files/20180124_bpase_game_theoretical_attacks_on_bitcoin.pdf

Is a 15-minute decision to fork the best way to manage today's Ethereum ecosystem vs when TheDAO happened?

I agree about the potential for distraction though. We tried to minimize that by doing the analysis, tuning, and benchmarking in advance. However, more review is definitely warranted.

[fulldecent]

@ifdefelse The best way to know would be if people are complaining that their transactions aren't being mined. And these would be weird cases where the not-mining results in high-value auctions not going to the highest bidder etc. The second best way would be if the hash rate tripled in a short period of time and that period of time was outside the normal explained by many people joining the system.

Regarding forking. I am always against forking if possible. Because of my work I have been pitching Ethereum to banks, big-4 consulting firms and other mature industries. They are almost always only considering hyperledger. When I talk about Ethereum their first question is "who owns it" and then "what is the governance process"? My answer is "the people that have commit access" and "in 15 minutes they can push a change that will basically auto-update the whole network". If we want to change this reputation and actually change the underlying truth then we will need to defend vigorously against unnecessary forks.

If you are still vying for 1057 and have new arguments then let's continue this discussion there. You can @-mention me there.

[ifdefelse]

Ack. Will move conversation.
ethereum/EIPs#1057 (comment)

[ifdefelse]

@lrettig , @pipermerriam , Since eip-1057 is related to the previously unresolved discussion on eip-969 could we talk about it at the next meeting?

[RSAManagement]

Since the most urgent problem of the network is the high uncle rate because of the db i/o isuue (and also the ethereum success :) ) it would be very interesting to know if there are plans to improve the traditional on chain scalability on that area (via client improvements), I saw a very promising work at the Edcon from @AlexeyAkhunov I wonder if he will attend this meeting

[OhGodAGirl]

Speaking up for EIP-1057: it needs to be addressed, and I believe the community wants this to be heard and debated in a rationale environment as much as I do.

Miners, it's time to vote with your voices, and not your hashrate.

[Souptacular]

@jamesray1: Added your item and reached out on Gitter to see if you can attend.
@fulldecent: We are moving ERC topics out of the core dev calls (will explain more in the call this Friday). Your EIP should be moved to final soon imo and I will bring it up with the editors.
@ifdefelse & @OhGodAGirl : Added your item and reached out to some miners on Twitter to see if you or someone else who is technical can join (https://twitter.com/BitsBeTrippin/status/996731882925633537). Whoever ya'll decide should join needs to reach out to me on Gitter.
@RSAManagement: Normally the client updates include client improvement updates and @AlexeyAkhunov is always welcome to join with his updates 😄

[Souptacular]

This meeting will feature live streams on both YouTube and Livepeer!

[holiman]

I'd like to add a discussion point about EIP 210, to finalize a few points. Such as

1. the original intent (no semantic changes to BLOCKHASH -- only gas changes) versus the current spec (semantic changes), and
2. whether to make it nicer to ABI-call it, and
3. whether to add genesis lookup in there.

[Souptacular]

@holiman: Added your topic.

[ifdefelse]

@Souptacular Never done this before. How do I actually call-in/join? Is there a Zoom meeting link that will be sent out before the meeting?

[Arachnid]

Can we please add:

• EIP 1051 Overflow checking for the EVM
• EIP 1052 EXTCODEHASH Opcode
• EIP 1087 Net gas metering for SSTORE operations

[benefit14snake]

I support fair mining and EIP 1057. I think it completely goes against the spirit of ethereum to allow centralization through manufacturing control.

Also as far as common network attacks I feel a bribe based attack would be much harder to pull off than a rented attack for the simple fact of we don’t know the true rentable no questions asked capacity available to a rental attack. It was seemingly implied that a bribe based attack would be cheaper but I feel it would be easier to pull off if the miners were more centralized which historically they have been when comparing ASIC to GPU.

[gcolvin]

I have been hearing for a long time that we plan to use native browser VMs for running eWasm. I remain concerned that none of them are DoS-hardened. I've been asking about this for a long time and have yet to hear anything from the eWasm group or the client teams to allay my concerns. Most of those people are represented here. Can we please discuss this?

[Souptacular]

@jamesray1: Removed the piece you requested.
@Arachnid: Added your items.
@gcolvin: Added your item, but it may not make it into the meeting because the agenda is already pretty full. If it doesn't it will be in the next one for sure.

[jamesray1]

Sorry to ask again, but I updated the proposal with a significant change, which is to remove a proposal to reward full nodes, leaving just the proposal to reward clients. Could you remove references to reward full nodes?

EIP 908: Reward clients for a sustainable network - When each transaction is validated, give a reward to clients for developing the client.

[gcolvin]

My most specific concern is with JIT execution being vulnerable. An attacker can do things like

• force the JIT to compile code that takes quadratic time
• force the JIT to compile code that is no longer called
• force the JIT to cache compiled code that is no longer called
  For performance reasons eWasm must be compiled. For security reasons it must be compiled at deployment time, not just-in-time.

[AlexeyAkhunov]

I won't be able to join the meeting on time. Currently preparing data for the next blog post update on Turbo-Geth, but here is a quick summary:

1. At block 5'560'000 the database size is about 340Gb (this is equivalent to archive mode), breakdow is being calculated and analysis will be published.
2. Done a lot of work on reducing memory allocations - to relieve the garbage collector - comparative sync graphs will be published.
3. Patricia trie rewinding functionality (for reorg support) implemented, but there is no good way of testing it properly, therefore (3)
4. Developing a tool to test things like reorgs (and then generally stress testing of the client) directly via p2p "eth" protocol.
5. Experimenting with what I call "thunk-EVM" - lazy execution in the EVM to defeat some of the spam attacks that are still hard for HDD (for example, where a balance of an account is requested but never used). This would also semi-automate some of my security audit work related to symbolic execution of byte code (currently done in spreadsheets). Thunk-EVM may also enable things like mass reading of state for multiple transaction at a time, as well as concurrent execution of transactions.
6. Collected data on account access and creation - I am planning to write up a research task on bloom filters for accounts, to outsource on Gitcoin.

If anyone wants to watch the recording of my talk about Turbo-Geth at EDCON, here is the link to it: https://youtu.be/vlLFQqfgOPk?t=23579

[Arachnid]

Apologies, the link for that last EIP should be https://eips.ethereum.org/EIPS/eip-1087

[Arachnid]

@AlexeyAkhunov Great work on turbo geth! Are you planning to send PRs to the Geth team?

[chfast]

Please add to point 6: fixes for EIP-210 blockhash contract: ethereum/EIPs#1094.

[jamesray1]

Good stuff Alexey!

Done a lot of work on reducing memory allocations - to relieve the garbage collector - comparative sync graphs will be published.

This is a key reason why I like Rust...

[holiman]

I summarized my things for point 6 here: https://notes.ethereum.org/s/HJXvL-h0f# , so y'all fine folks don't have to listen to me explain it during the call

[Souptacular]

@holiman @jamesray1 @chfast @gcolvin Added/correct items.

[AlexeyAkhunov]

@Arachnid Thanks! I promise I will start sending PRs when I am less overwhelmed. At the moment I am still playing catch up with geth :)

@jamesray1 Yes, I have been thinking of Rust quite a lot while dealing with subtle bugs related to mutable/immutable objects

[jamesray1]

@karalabe, @holiman and @pipermerriam, I updated the EIP with the attack that you mentioned and a solution, let me know what you think. https://eips.ethereum.org/EIPS/eip-908. https://ethereum-magicians.org/t/eip-908-reward-full-nodes-and-clients-for-a-sustainable-network/241

[5chdn]

At block 5'560'000 the database size is about 340Gb (this is equivalent to archive mode), breakdow is being calculated and analysis will be published.

Hi @AlexeyAkhunov - I don't understand this. It's way too much for a pruned node, but super small for an archive node. What exactly is it?