Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Ethereum Core Devs Meeting 65 Agenda #111

Closed
Souptacular opened this issue Jul 8, 2019 · 16 comments
Closed

Ethereum Core Devs Meeting 65 Agenda #111

Souptacular opened this issue Jul 8, 2019 · 16 comments

Comments

@Souptacular
Copy link
Member

@Souptacular Souptacular commented Jul 8, 2019

IMPORTANT: All EIPs are on the chopping block for Istanbul at the next meeting unless there is a reference implementation or the champion can successfully argue one is not needed. EIPs not included in Istanbul are pushed back and can be reintroduced at the next fork.

Ethereum Core Devs Meeting 65 Agenda

Agenda

  1. Istanbul EIPs Chopping Block
    • EIP-615
    • EIP-1344 vs. EIP-1965
      • Can we make a decision on EIP-1344 independently of EIP-1965?
    • EIP-1283
      • There was an AMA with no further questions about the EIP.
    • EIP-1962
    • EIP-2028
    • EIP-2024
    • Other EIPs under consideration
      • State Rent EIPs
      • ProgPow
      • Others
    • Everything else gets pushed from Istanbul?
    • Update EIP-1679: Istanbul Meta
  2. EIP Refactoring
    • Given EIP-1702: Which of the Istanbul EIPs live only in version 1 code? Which live in version 0 and version 1 code?
    • Proactive refactoring of the client implementations to make EIPs more simple, and reduce their conflicts.
  3. Conformance Testing
  4. Review previous decisions made and action items
  5. Adding "Security Considerations" to EIP-1
  6. Working Group Updates
  7. Testing Updates
  8. Client Updates (only if they are posted in the comments below)
    a) Geth
    b) Parity Ethereum
    c) Aleth/eth
    d) Trinity/PyEVM
    e) EthereumJS
    f) EthereumJ/Harmony
    g) Pantheon
    h) Turbo Geth
    i) Nimbus
    j) web3j
    k) Mana/Exthereum
    l) Mantis
    m) Nethermind
  9. EWASM & Research Updates (only if they are posted in the comments below)
@CPSTL

This comment has been minimized.

Copy link
Contributor

@CPSTL CPSTL commented Jul 9, 2019

Agenda Item Request: Formally discuss whether or not we should be including ProgPow into Istanbul. If we do add it in and something comes up along the way before the hardfork, we can simply just pull it.

@gluk64

This comment has been minimized.

Copy link

@gluk64 gluk64 commented Jul 10, 2019

Agenda Item Request: status update on alternative implementation of EIP1962 in C++.

@fubuloubu

This comment has been minimized.

Copy link
Member

@fubuloubu fubuloubu commented Jul 10, 2019

So meetings are no longer every other Friday?

@shamatar

This comment has been minimized.

Copy link

@shamatar shamatar commented Jul 11, 2019

Initial PR for EIP1962 into Parity is complete (link). For Geth two options will be provided over the next two weeks:

  • Add building of Rust code into the pipeline and use Rust implementation
  • Alternative C++11 self-contained implementation for use with CGO

Plans:

  • Complete gas metering procedure (1 week)
  • Generate more initial vectors for fuzzy-testing (1 week, along with gas metering)
  • 16+ CPU-months of fuzzy testing using libfuzzer and honggfuzz
@tintinweb

This comment has been minimized.

Copy link

@tintinweb tintinweb commented Jul 11, 2019

Agenda Item Request: Discussing the EIP process template and process modification to manifest security in the EIP process by adding mandatory "Security Considerations" to EIP-1 (and EIP-x template). This has been presented at the coredevs meeting in berlin this spring. Discussion, presentation etc. are linked in the pull-request at ethereum/EIPs#1963. This is only a minor modification to add the section to the template and require proposals to provide security considerations (initially intentionally lax) analogue to the same RFC process.

@lrettig

This comment has been minimized.

Copy link
Member

@lrettig lrettig commented Jul 12, 2019

So meetings are no longer every other Friday?

They are. It's -8 hrs per call, modulo 24, I think :)

@timbeiko

This comment has been minimized.

Copy link
Collaborator

@timbeiko timbeiko commented Jul 12, 2019

@Souptacular the actions items linked are the wrong one (call #63 and not #64)

@fubuloubu

This comment has been minimized.

Copy link
Member

@fubuloubu fubuloubu commented Jul 12, 2019

It's -8 hrs per call, modulo 24

Modulo 24 which timezone though? This meeting is only on Friday during the day for those in Asia and the South Pacific

@timbeiko

This comment has been minimized.

Copy link
Collaborator

@timbeiko timbeiko commented Jul 12, 2019

@fubuloubu the goal was to never have it be on a Saturday for anyone, so it rotates from 14:00 UTC Friday, 6:00UTC Friday and 22:00UTC Thursday, and then back to 14:00 UTC Friday.

@GuthL

This comment has been minimized.

Copy link

@GuthL GuthL commented Jul 16, 2019

EIP2028 would like to present our results on the call. Could we be added to the agenda?

@shemnon

This comment has been minimized.

Copy link
Contributor

@shemnon shemnon commented Jul 16, 2019

If we are going to discuss ProgPOW add the need for a hash multiplier for ProgPOW total difficulty to the agenda: https://ethereum-magicians.org/t/eip-progpow-a-programmatic-proof-of-work/272/13?u=shemnon

But in my opinion this is less important than discussing reference tests and the other already discussed EIPs, so place it on the agenda appropriately.

@timbeiko

This comment has been minimized.

Copy link
Collaborator

@timbeiko timbeiko commented Jul 17, 2019

Following last AllCoreDevs, and inspired by an idea that @MadeofTin gave me, I pinged all the attendees from the previous call and asked them what the Top 3 things they'd like to see discussed on the call were.

8 attendees answered, and here are their compiled answers. Hopefully this can influence the agenda so that most of the time is spent discussing these issues.

  1. "How we work towards Istanbul": what EIPs are included, excluded and other roadmap considerations. These EIPs were mentioned explicitly:
    1. EIP-615
    2. EIP-1344 vs. EIP-1965
      • Can we make a decision on EIP-1344 independently of EIP-1965?
    3. EIP-1283
      • There was an AMA with no further questions about the EIP. Should it move to Accepted?
    4. EIP-1962
    5. State Rent EIPs
    6. Other EIPs
      • ProgPow?
      • EIP-2028?
  2. EIP Refactoring
    • Given EIP-1702: Which of the Istanbul EIPs live only in version 1 code? Which live in version 0 and version 1 code?
    • Proactive refactoring of the client implementations to make EIPs more simple, and reduce their conflicts. See "Comment by Alexey" below for details.
  3. Conformance Testing
  4. Gas costs improvements that help developers today

Comment by Alexey: I would like to introduce this idea that, regardless of whether EIPs are accepted or not, part of their implementation that "loosens" up the code, should be done anyway. It means that instead of EIP implementations bringing all the complexity with them, some of the complexity is eliminated upfront. This is a new concept, but I think it is quite important to promote.

@fubuloubu

This comment has been minimized.

Copy link
Member

@fubuloubu fubuloubu commented Jul 17, 2019

Re: EIP-1344 vs. EIP-1965, as I said before I won't be able to make the meeting until almost 1.5 hours into the call. Calls usually go this long, so if I am needed to make a decision on EIP-1344 I will try to attend. If not, if someone could inform me via Gitter when that decision is made, it would help me out immensely so I am not rushing to join the call to find out everyone had already left. Thanks!

@valuead

This comment has been minimized.

Copy link

@valuead valuead commented Jul 17, 2019

is there a testnet?
is the network needs validators?

@sorpaas

This comment has been minimized.

Copy link
Contributor

@sorpaas sorpaas commented Jul 18, 2019

Given EIP-1702: Which of the Istanbul EIPs live only in version 1 code? Which live in version 0 and version 1 code?

Regarding this, in the call we'll basically want to discuss two options:

  1. Treat old versions as "immutable" -- define a new version each time we do a hard fork. This will be really good to ensure backward compatibility. And because older versions are not changed, clients may be able to make more assumption of the versions to simplify the design. The drawback is that we'll get 2 new versions per year.
  2. Treat versions the same as how we do semantic versioning. Deploy a new version when a feature qualify as a "major release", and only change existing versions when a feature is "minor release" or "patch release". I'm okay with this, but I have worries about all the gas reduction EIPs for Istanbul -- I cannot convince myself that they won't have backward compatibility issues.

If we decide on (2), then we may not have a new version this time, because most Istanbul EIPs (except EIP-615 and state rents) are minor changes. However, I do want to propose that we ensure account versioning is implemented in all the clients and include it in Istanbul testing, because it allows people to write EIPs with the assumptions that we have account versioning, which in many situations will greatly simplify things (for example, state rent EIPs' new account RLP fields).

@timbeiko

This comment has been minimized.

Copy link
Collaborator

@timbeiko timbeiko commented Jul 23, 2019

Closed in favour of #113

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
You can’t perform that action at this time.