ethereum/pm

Ethereum Core Devs Meeting 38 Agenda

lrettig opened this issue · 41 comments

lrettig commented

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: ethereum/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 commented

devcon4

  • 👍6
  • 🎉1
jamesray1 commented

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.

  • 👍2
lrettig commented

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

  • 👍1
jamesray1 commented

@lrettig EIP-908 was created from that thread.

jamesray1 commented

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 commented

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 commented

@jamesray1 roger that, added 908 to the agenda.

  • 👍1
fulldecent commented

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:

CONSUMERS:

  • 👍17
  • 🎉6
  • ❤️6
holiman commented

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

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.

  • 👍6
  • 👎2
fulldecent commented

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.

  • 👍1
  • 👎2
  • 😕1
ifdefelse commented

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

  • 👍2
  • ❤️1
fulldecent commented

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.

  • 👍1
  • 👎1
  • 😕1
jamesray1 commented

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

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

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

  • 👎1
ifdefelse commented

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

  • ❤️1
ifdefelse commented

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

  • 👍1
RSAManagement commented

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 commented

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.

  • 👍5
Souptacular commented

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

  • 👍2
  • 🎉1
Souptacular commented

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

  • 🎉6
holiman commented

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 commented

@holiman: Added your topic.

ifdefelse commented

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

Can we please add:

benefit14snake commented

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 commented

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 commented

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

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 commented

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 commented

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

  • 👍3
Arachnid commented

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

Arachnid commented

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

  • 👍3
chfast commented

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

jamesray1 commented

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 commented

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

AlexeyAkhunov commented

@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

5chdn commented

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?