ethereum/pm

Ethereum Core Devs Meeting 58 Agenda

Souptacular opened this issue · 14 comments

Souptacular commented

Ethereum Core Devs Meeting 58 Agenda

Agenda

  1. Roadmap
  2. EIPs
    a) EIP 1599 - Fee Market Change for Eth 1.0 Chain
    b) EIP - Ethereum Network Upgrade Windows
    c) EIP - Opcode repricing for trie-size-dependent opcodes
  3. Working Group Updates
    a) State Fees
    b) EWasm
    c) Pruning/Sync (ETH V64 Call for Proposals & Stopgaps for cleaning up discovery peers pre-Discovery v5)
    d) Simulation
    e) Istanbul & ETH1x Roadmap Planning Meeting - April 17th & 18th in Berlin
  4. ProgPoW Audit Update & Carbonvote Being Taken Down
  5. Testing Updates
  6. Client Updates
    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) Nethereum
  7. EWASM & Research Updates
shemnon commented

Ordering request: can progpow be put at the end of the agenda? Or at least after the working group updates? It tends to consume all available time. This way the other topics of the agenda won't be facing time constraints.

  • 👍5
econoar commented

Can we be sure EIP-1559 is discussed? Vitalik mentioned he wants to present for it for the Berlin talks but if we are discussing EIPs for Istanbul here too I want to be sure it’s considered.

  • 👍1
timbeiko commented

It was mentioned in today's Ethereum Cat Herders call that the ProgPow carbonvote will be taken down. When ProgPow does get mentioned in the call, can we be sure to not forget highlighting this? ethcatherders/PM#23

  • 👍3
Matthalp-zz commented

@Souptacular I will not be able to make tomorrow's call, but the main update for ETH V64 is that (1) ETH V64 conversation is going to be moved over to the devp2p repo and (2) will be in a discussion/prototyping phase until the sync proposals mature. Once those are at a good place we'll figure out how to integrate the ETH V64 proposals that end up maturing.

  • 👍1
gcolvin commented

A request: Can the decisions taken at each meeting be clearly stated somewhere under ethereum/pm?

A lot of the confusion around progPoW seems to have arisen simply because our January consensus was buried in the transcript, where it was hard to find and not clear out of context.

  • 👍2
holiman commented

I have just submitted an EIP that I would like to have eventually included into the next hard fork: https://github.com/holiman/EIPs/blob/reprice/EIPS/eip-draft_reprice_opcodes.md . If there's enough time, I'd like a few minutes to present it.
Before I make the pull request to include it in next HF, I'd be grateful for some review and discussions.

Edit: now moved to https://github.com/holiman/EIPs/blob/reprice/EIPS/eip-1884.md

  • 👍1
winsvega commented

Testing updates:

Fork names EIP
ethereum/EIPs#1848

Strict name specification for genesis file parsing on all clients.

Retesteth docker (run tests via RPC with your client)

AlexeyAkhunov commented

Update on working groups:

  1. State Fees (rent) - I published first data from the stateless client prototype yesterday: https://medium.com/@akhounov/data-from-the-ethereum-stateless-prototype-8c69479c8abc. Next steps are outlined at the end of the article. This might come into the 4th version of the State Fees proposal

  2. Advanced sync protocol (Red Queen). Andrey has produced a modelling code that simulates the sync with 100 million accounts, and with 1 MiB/sec bandwidth the overhead (due to having to catch up with the current state) is around 20%. I am currently preparing some analysis on the probabilistic estimation of the contract sizes, which could help while syncing contract storage. In couple of weeks we will start prototyping the Red Queens in Turbo-Geth, to arrive at more accurate specification. Currently the description is here: https://github.com/yperbasis/silkworm/blob/master/doc/sync_protocol.pdf
    I am thinking of taking the sync protocol into a separate working group.

  3. I would like to form a new working work on using the beacon chain as the finality gadget for Ethereum 1.x. First steps would be researching the biggest challenges for Beacon chain light client: https://ethereum-magicians.org/t/eth2-in-eth1-light-clients/2880, and exploring whether we want to make it natively or virtualised using EVM/eWASM + precompiles.

  4. The probabilistic estimation of contract sizes can potentially be used to bring forward the change J (fixed prepayment for contract storage) from the 3rd version of the State Fees proposal. Currently, it requires knowing the number of storage items in a contract, but if we can efficiently approximate it, this change can be done in the first hard fork. The main benefit is that the increase in the Block Gas limit can be done straight after the 1st hard fork, and not the second.

  5. There might be ways to improve on the contract recovery schemes, I will research and introduce possible improvements into the 4th version of the State Fees proposal.

  6. I am also planning more research into the linear storage because it can integrate much better with eWASM engine (via memory mapping).

Update on Turbo-Geth:

Started rebasing to go-ethereum. Currently managed to rebase Constantinopole/Petersburg changes, so that Turbo-Geth now sync past the hard fork. There was a lot of refactoring in go-ethereum lately, that would take a while for me to rebase to.

  • 👍1
timbeiko commented

@gcolvin re: stating the decisions taken, the Cat Herders will start providing summaries of the transcripts on Eth Magicians. Look out for the first one in the ~24hrs following this call.

  • 👍2
chfast commented

Aleth update:

  • aleth-bootnode improvements (the devp2p discovery "client").
  • new release 1.6 is planned to happen before the next AllCoreDevs.
  • we are considering implementing discovery v5 / ENR; let us know if this is bad idea.
  • upgrading leveldb on Windows causes 50% performance degradation.
davidmurdoch commented

Ganache update:

Ganache-core and ganache-cli betas introduce a new algorithm for gas estimation that we call "Gas Exactimation". We don't use a binary search to find the gas estimate; we need only one execution of the transaction/opcodes. The algorithm should result in perfectly accurate gas estimations even transactions that execute opcodes affected by EIP-114 (1/64ths rule).

Release notes: https://github.com/trufflesuite/ganache-core/releases/tag/v2.5.4-beta.2

  • 👍1
timbeiko commented

Meeting transcript, now including a "Summary" section that compiles the action items and decisions taken: https://github.com/ethereum/pm/blob/master/All%20Core%20Devs%20Meetings/Meeting%2058.md#summary

Souptacular commented

Closing. New agenda: #93