diff --git a/README.md b/README.md index 4250b45..5118f57 100644 --- a/README.md +++ b/README.md @@ -24,15 +24,18 @@ This repo hosts a collection of [standards](./interop) to aid in client interope 13 | Thu, Feb 28, 2019 14:00 UTC | [agenda](https://github.com/ethresearch/eth2.0-pm/issues/31) \| [notes](eth2.0-implementers-calls/call_013.md) \| No reddit | [video](https://www.youtube.com/watch?v=0ZWG8hMbxes) | 14 | Thu, Mar 14, 2019 14:00 UTC | [agenda](https://github.com/ethresearch/eth2.0-pm/issues/33) \| [notes](eth2.0-implementers-calls/call_014.md) \| [reddit](https://www.reddit.com/r/ethereum/comments/b0ud27/live_eth20_implementers_call_14_201903214_starts/) | [video](https://www.youtube.com/watch?v=zeceWlmxseY) | 15 | Thu, Mar 28, 2019 14:00 UTC | [agenda](https://github.com/ethresearch/eth2.0-pm/issues/35) \| [notes](eth2.0-implementers-calls/call_015.md) \| No reddit | [video](https://www.youtube.com/watch?v=bC4v_a-gcrs) | - 16 | Thu, Apr 18, 2019 14:00 UTC | [agenda](https://github.com/ethereum/eth2.0-pm/issues/37) \| [notes](https://github.com/ethereum/eth2.0-pm/blob/master/eth2.0-implementers-calls/call_016.md) \| No Reddit | [video](https://www.youtube.com/watch?v=eN_O8bSaS5Q) | + 16 | Thu, Apr 18, 2019 14:00 UTC | [agenda](https://github.com/ethereum/eth2.0-pm/issues/37) \| [notes](eth2.0-implementers-calls/call_016.md) \| No Reddit | [video](https://www.youtube.com/watch?v=eN_O8bSaS5Q) | 17 | Thu, May 02, 2019 14:00 UTC | [agenda](https://github.com/ethereum/eth2.0-pm/issues/42) \| No Notes \| No Reddit | [video](https://www.youtube.com/watch?v=bi7lh5Ie3x0) | - 18 | Thu, May 23, 2019 14:00 UTC | [agenda](https://github.com/ethereum/eth2.0-pm/issues/43) \| [notes](https://github.com/ethereum/eth2.0-pm/blob/master/eth2.0-implementers-calls/call_018.md) \| [Reddit](https://www.reddit.com/r/ethereum/comments/bs37os/eth20_implementers_call_18_2019523/) | [video](https://www.youtube.com/watch?v=dw2GmEuLr5k) | - 19 | Thu, Jun 13, 2019 14:00 UTC | [agenda](https://github.com/ethereum/eth2.0-pm/issues/45) \| [notes](https://github.com/ethereum/eth2.0-pm/blob/master/eth2.0-implementers-calls/call_019.md) \| No Reddit | [video](https://www.youtube.com/watch?v=izspfej05lE) | - 20 | Thu, Jun 13, 2019 14:00 UTC | [agenda](https://github.com/ethereum/eth2.0-pm/issues/51) \| [notes](https://github.com/ethereum/eth2.0-pm/blob/master/eth2.0-implementers-calls/call_020.md) \| [Reddit](https://www.reddit.com/r/ethereum/comments/c6nuwh/eth20_implementers_call_20_2019627/) | [video](https://www.youtube.com/watch?v=Y8rhSbtY-Pg) | - 21 | Thu, Jul 11, 2019 14:00 UTC | [agenda](https://github.com/ethereum/eth2.0-pm/issues/55) \| [notes](https://github.com/ethereum/eth2.0-pm/blob/master/eth2.0-implementers-calls/call_021.md) \| [Reddit](https://www.reddit.com/r/ethereum/comments/cbsyu4/live_eth20_implementers_call_21_2019711_1400_gmt/) | [video](https://www.youtube.com/watch?v=YB8o_5qjNBc) | - 22 | Thu, Jul 25, 2019 14:00 UTC | [agenda](https://github.com/ethereum/eth2.0-pm/issues/64) \| [notes](https://github.com/ethereum/eth2.0-pm/blob/master/eth2.0-implementers-calls/call_022.md) \| No Reddit | [video](https://www.youtube.com/watch?v=ReSiB2940AE) | - 23 | Thu, Aug 15, 2019 14:00 UTC | [agenda](https://github.com/ethereum/eth2.0-pm/issues/68) \| [notes](https://docs.google.com/document/d/197ZK_cyxcwAF3V5yQ7DIPKFJ0zz2VMt7gGiSWbutygg/edit#) \| [Reddit](https://www.reddit.com/r/ethereum/comments/cqng6t/live_eth20_implementers_call_23_2019815_1400_gmt/) | [video](https://www.youtube.com/watch?v=Av74vZRXeKo) | - 24 | Thu, Aug 29, 2019 14:00 UTC | [agenda](https://github.com/ethereum/eth2.0-pm/issues/73) \| [notes](https://docs.google.com/document/d/1jA4H6uQvPsWYrOUGFJeQWqXzP6YUq6BFKfPYAI7_y3g/edit) \| [Reddit](https://www.reddit.com/r/ethereum/comments/cwxlye/live_eth20_implementers_call_24_2019829_1400_gmt/) | [video](https://www.youtube.com/watch?v=sz87_i5Uy1I) | - 25 | Thu, Sep 9, 2019 14:00 UTC | [agenda](https://github.com/ethereum/eth2.0-pm/issues/85) \| [notes](https://github.com/ethereum/eth2.0-pm/blob/213decb59f9f78d0791b6273332b6aa11e760122/eth2.0-implementers-calls/call_025.md) \| [Reddit](https://www.reddit.com/r/ethereum/comments/d6beer/eth20_implementers_call_25_2019919_1400_gmt/) | [video](https://www.youtube.com/watch?v=pEdqjXO6euY) | - 26 | Thu, Oct 24, 2019 14:00 UTC | [agenda](https://github.com/ethereum/eth2.0-pm/issues/89) \| [notes](https://docs.google.com/document/d/1UN16SgDzG9mMVCKTrpw9QKANM-TBc_Jz6rhkGke7hAM/edit) \| [Reddit](https://www.reddit.com/r/ethereum/comments/dmgoqf/live_eth20_implementers_call_26_20191024_1400_gmt/) | [video](https://www.youtube.com/watch?v=DXGeC7cg71Y) | - 27 | Thu, Nov 7, 2019 14:00 UTC | [agenda](https://github.com/ethereum/eth2.0-pm/issues/95) \| [notes](https://docs.google.com/document/d/1ixUUwstiO16obctBJ16ApS2IfNrza1UrZqN2mch-QPg/edit) \| [Reddit](https://www.reddit.com/r/ethereum/comments/dsxbhc/live_eth20_call_27_2019117_1400_gmt/) | [video](https://www.youtube.com/watch?v=4_EGNG-Yek4) | + 18 | Thu, May 23, 2019 14:00 UTC | [agenda](https://github.com/ethereum/eth2.0-pm/issues/43) \| [notes](eth2.0-implementers-calls/call_018.md) \| [Reddit](https://www.reddit.com/r/ethereum/comments/bs37os/eth20_implementers_call_18_2019523/) | [video](https://www.youtube.com/watch?v=dw2GmEuLr5k) | + 19 | Thu, Jun 13, 2019 14:00 UTC | [agenda](https://github.com/ethereum/eth2.0-pm/issues/45) \| [notes](eth2.0-implementers-calls/call_019.md) \| No Reddit | [video](https://www.youtube.com/watch?v=izspfej05lE) | + 20 | Thu, Jun 13, 2019 14:00 UTC | [agenda](https://github.com/ethereum/eth2.0-pm/issues/51) \| [notes](eth2.0-implementers-calls/call_020.md) \| [Reddit](https://www.reddit.com/r/ethereum/comments/c6nuwh/eth20_implementers_call_20_2019627/) | [video](https://www.youtube.com/watch?v=Y8rhSbtY-Pg) | + 21 | Thu, Jul 11, 2019 14:00 UTC | [agenda](https://github.com/ethereum/eth2.0-pm/issues/55) \| [notes](eth2.0-implementers-calls/call_021.md) \| [Reddit](https://www.reddit.com/r/ethereum/comments/cbsyu4/live_eth20_implementers_call_21_2019711_1400_gmt/) | [video](https://www.youtube.com/watch?v=YB8o_5qjNBc) | + 22 | Thu, Jul 25, 2019 14:00 UTC | [agenda](https://github.com/ethereum/eth2.0-pm/issues/64) \| [notes](eth2.0-implementers-calls/call_022.md) \| No Reddit | [video](https://www.youtube.com/watch?v=ReSiB2940AE) | + 23 | Thu, Aug 15, 2019 14:00 UTC | [agenda](https://github.com/ethereum/eth2.0-pm/issues/68) \| [notes](eth2.0-implementers-calls/call_023.md) \| [Reddit](https://www.reddit.com/r/ethereum/comments/cqng6t/live_eth20_implementers_call_23_2019815_1400_gmt/) | [video](https://www.youtube.com/watch?v=Av74vZRXeKo) | + 24 | Thu, Aug 29, 2019 14:00 UTC | [agenda](https://github.com/ethereum/eth2.0-pm/issues/73) \| [notes](eth2.0-implementers-calls/call_024.md) \| [Reddit](https://www.reddit.com/r/ethereum/comments/cwxlye/live_eth20_implementers_call_24_2019829_1400_gmt/) | [video](https://www.youtube.com/watch?v=sz87_i5Uy1I) | + 25 | Thu, Sep 9, 2019 14:00 UTC | [agenda](https://github.com/ethereum/eth2.0-pm/issues/85) \| [notes](eth2.0-implementers-calls/call_025.md) \| [Reddit](https://www.reddit.com/r/ethereum/comments/d6beer/eth20_implementers_call_25_2019919_1400_gmt/) | [video](https://www.youtube.com/watch?v=pEdqjXO6euY) | + 26 | Thu, Oct 24, 2019 14:00 UTC | [agenda](https://github.com/ethereum/eth2.0-pm/issues/89) \| [notes](eth2.0-implementers-calls/call_026.md) \| [Reddit](https://www.reddit.com/r/ethereum/comments/dmgoqf/live_eth20_implementers_call_26_20191024_1400_gmt/) | [video](https://www.youtube.com/watch?v=DXGeC7cg71Y) | + 27 | Thu, Nov 7, 2019 14:00 UTC | [agenda](https://github.com/ethereum/eth2.0-pm/issues/95) \| [notes](eth2.0-implementers-calls/call_027.md) \| [Reddit](https://www.reddit.com/r/ethereum/comments/dsxbhc/live_eth20_call_27_2019117_1400_gmt/) | [video](https://www.youtube.com/watch?v=4_EGNG-Yek4) | + 28 | Thu, Nov 7, 2019 14:00 UTC | [agenda](https://github.com/ethereum/eth2.0-pm/issues/101) \| [notes](eth2.0-implementers-calls/call_028.md) \| No Reddit | [video](https://www.youtube.com/watch?v=DzLrxuN55VA) | + 29 | Thu, Dec 5, 2019 14:00 UTC | [agenda](https://github.com/ethereum/eth2.0-pm/issues/108) \| [notes](eth2.0-implementers-calls/call_029.md) \| No Reddit | [video](https://www.youtube.com/watch?v=MxeEWmEdb5E) | + 30 | Thu, Dec 19, 2019 14:00 UTC | [agenda](https://github.com/ethereum/eth2.0-pm/issues/112) \| [notes](eth2.0-implementers-calls/call_030.md) \| [Reddit](https://www.reddit.com/r/ethereum/comments/ecrgfh/live_eth20_call_30_20191219_1400_gmt/) | [video](https://www.youtube.com/watch?v=LYLiqpj-wiE) | diff --git a/eth2.0-implementers-calls/call_009.md b/eth2.0-implementers-calls/call_009.md index 57c6456..addf386 100644 --- a/eth2.0-implementers-calls/call_009.md +++ b/eth2.0-implementers-calls/call_009.md @@ -1,5 +1,5 @@ # Ethereum 2.0 Implementers Call 9 Notes -### Meeting Date/Time: Thursday 2010/1/3 at [14:00 GMT](https://savvytime.com/converter/gmt-to-germany-berlin-united-kingdom-london-ny-new-york-city-ca-san-francisco-china-shanghai-japan-tokyo-australia-sydney/jan-3-2019/2pm) +### Meeting Date/Time: Thursday 2019/1/3 at [14:00 GMT](https://savvytime.com/converter/gmt-to-germany-berlin-united-kingdom-london-ny-new-york-city-ca-san-francisco-china-shanghai-japan-tokyo-australia-sydney/jan-3-2019/2pm) ### Meeting Duration: 1.5 hours ### [GitHub Agenda Page](https://github.com/ethereum/eth2.0-pm/issues/21) ### [Audio/Video of the meeting](https://www.youtube.com/watch?v=6trA-5rjZUQ) diff --git a/eth2.0-implementers-calls/call_016.md b/eth2.0-implementers-calls/call_016.md index a224b68..ea4d0fa 100644 --- a/eth2.0-implementers-calls/call_016.md +++ b/eth2.0-implementers-calls/call_016.md @@ -5,8 +5,10 @@ ### [GitHub Agenda Page](https://github.com/ethereum/eth2.0-pm/issues/37) ### [Audio/Video of the meeting](https://www.youtube.com/watch?v=eN_O8bSaS5Q) +---- + # 1. Testing Updates [_(8:40)_](https://youtu.be/eN_O8bSaS5Q?t=517) -* Diederik - working in integrating tests in specs repo to trigger CI. Several tests including state transition. +* Diederik - working in integrating tests in specs repo to trigger CI. Several tests including state transition. # 2. Client Updates [_(10:26)_](https://youtu.be/eN_O8bSaS5Q?t=626) * Pegasys - Jonny Rhea @@ -26,7 +28,7 @@ * Optimized state transition due to memory leaks * 2 testnets. Public - "Testnet0" & one for development * Improved sync efficiency - * Testnet issues with net traversal - wrapped the mini UPnP + * Testnet issues with net traversal - wrapped the mini UPnP * Some work on Whisper * Eagerly waiting for SSZ tests since cacheing is needed to pass state tests * Harmony - Anton @@ -35,14 +37,14 @@ * Implmented incremental tree hashing - currently benchmarking * Started WIRE implementation * Trinity - Hsiao-Wei Wang - * most of team in EDCON + * most of team in EDCON * testnet under construction - testing blocks between validators * integrating 0.5.1 tests * Lighthouse - Adrian * passing 0.5.1 state transition tests * Paul implemented tree hash caching - should be implemented in runtime next week * assisting BLS standardization by benchmarking a new hash curve method - * lots of bug fixes, + * lots of bug fixes, * started peer management * started building tools for large scale network tests * Prysmatic - Terence @@ -81,7 +83,7 @@ * general form feels largely figured out # 4. Research Updates [_(32:36)_](https://youtu.be/eN_O8bSaS5Q?t=1946) -* Justin +* Justin * team has consensus on spec freeze come end of Q2 * lots of simplifications done and coming for depositis, incentivization, crosslinks, serialization, abstraction, SSZ... * BLS standarization is moving forward - having fortnightly calls (Algorand, EF, Chia, Ledger) @@ -91,12 +93,12 @@ * looking at transaction abstraction - everything could be a contract (still an idea) * Vitalik * thinking about fast cross shard transactions - largely in layer 2 - lot of issues to still work through - * general approach: have state objects in one shard that store dependecies, so potentially mulitiple copies of state object. Some data structure that determines state object most likely to be correct. The rest are there in case first doesn't work. Challenge is elegancy and ease of working with. One contract called a "hypervisor" and transactions might end up being calls to "hypervisor". "Hypervisor" manages different state objects and which contracts to modify. Seems likely this can all be done at layer 2. -* Danny - * on tranfers - intention is to launch with max tranfers per block constant at 0. In favor of forking to implement and practice hard-forking mechanism. + * general approach: have state objects in one shard that store dependecies, so potentially mulitiple copies of state object. Some data structure that determines state object most likely to be correct. The rest are there in case first doesn't work. Challenge is elegancy and ease of working with. One contract called a "hypervisor" and transactions might end up being calls to "hypervisor". "Hypervisor" manages different state objects and which contracts to modify. Seems likely this can all be done at layer 2. +* Danny + * on tranfers - intention is to launch with max tranfers per block constant at 0. In favor of forking to implement and practice hard-forking mechanism. * Leo (BSC) * bit of academic disemination - gave a couple classes on blockchains and presented sharding - + # 5. Network Updates [_(42:04)_](https://youtu.be/eN_O8bSaS5Q?t=2524) * Discovery - Felix * [Discovery v5 spec](https://github.com/ethereum/devp2p/blob/master/discv5/discv5.md) about 95% done @@ -116,7 +118,7 @@ * Whiteblock is reopening performance tests # 6. Spec Discussion [_(55:22)_](https://youtu.be/eN_O8bSaS5Q?t=3322) -* Danny - want to get 0.6 spec out tomorrow or very soon for testing. Almost entirely bug fixes and simplification. Testing is also simplified. +* Danny - want to get 0.6 spec out tomorrow or very soon for testing. Almost entirely bug fixes and simplification. Testing is also simplified. *Discussion * Terence - 3 different scenarios - 1. receive bad block 2. receive block from forked chain 3. receive block from canonical chain - would like to drop bad block, save from forked chain, process normal block * Danny - seems sane, still do standard processing @@ -160,9 +162,3 @@ * Vitalik Buterin (EF/Research) * Zak Cole (Whiteblock) * Meeting notes: Mike LaCroix - - - - - - diff --git a/eth2.0-implementers-calls/call_018.md b/eth2.0-implementers-calls/call_018.md index b21d57b..cfa7b20 100644 --- a/eth2.0-implementers-calls/call_018.md +++ b/eth2.0-implementers-calls/call_018.md @@ -5,17 +5,19 @@ ### [GitHub Agenda Page](https://github.com/ethereum/eth2.0-pm/issues/43) ### [Audio/Video of the meeting](https://www.youtube.com/watch?v=dw2GmEuLr5k&) +---- + # 1. [Testing Updates](https://youtu.be/dw2GmEuLr5k?t=417) -* Protolambda +* Protolambda * Slow week with NY blockchain week, helpful to get together with implementers * Epoch transistions, sanity tests, want clients to create test runners and get feedback * Tests are currently on separate branch, soon to be released * Mikhail * keccak256 still used in BLS test vectors -* Danny - this was likely a mistake, +* Danny - this was likely a mistake, * Protolambda * Loading configuration files: compile-time vs runtime -* Mamy +* Mamy * Nimbus discussed this at length - for now using compile-time constants, not through YAML * Reconsidering in future for users, don't want them have to recompile everytime * Paul @@ -23,14 +25,14 @@ * Danny * Configurable constants validity condition accompanies this, currently enumerating those in a branch * Constants will likely live in a test repo for now - + * Antoine * Testing jenkins instance for building docker files for Lighthouse, Prysm, Artemis for nodes on a simulated testnet * Working without discovery, just for connection. Next step is peer and sync * Format build by Whiteblock - network delays, easy to recreate real world simulations * Danny * Another initial fuzzing test targeting Go and Py specs, overtime will integrate more clients - + # 2. [Client Updates](https://youtu.be/dw2GmEuLr5k?t=1117) * Parity - Wei Tang * Up to date with 0.6 spec @@ -45,17 +47,17 @@ * Implementation of watching validators register; Timing mechanism is now swappable for testing different ones * Nimbus - Mamy * Slow weeks - several people on holiday - * Networking, forward and backward sync + * Networking, forward and backward sync * Still working on libp2p * Some confusion between keccak256 and SHA256 * Shuffling and BLS mainnet tests passing - * Update on ETH 1: new member working networking and reusable parts for ETH 2.0 + * Update on ETH 1: new member working networking and reusable parts for ETH 2.0 * Documentation generator for repo - should be cross language compatible * Also working on multi-threading and debugging Nim library * Prysmatic - Terence * Finished up to 0.6 spec, working on how to use and optimize in testnet * Updating SSZ and trie hashing - * Investigating BLS alternatives + * Investigating BLS alternatives * Possible colaboration with Whiteblock for p2p * Lodestar - Cayman * SSZ and BLS (switched to Milagro) tests passing for 0.6, soon state transtition tests and shuffling @@ -77,12 +79,12 @@ * [V2 of Phase 2 proposal](https://notes.ethereum.org/w1Pn2iMmSTqCmVUTGV4T5A?viewPhase#) * Instead of maintaining large array of state for every shard, 32 byte hash takes that place * Full state can be abstracted across different execution environments - * Despite more abstraction it's simpler based on how it lets you abstract things - ex: no need for 1 standard rent scheme - allows for + * Despite more abstraction it's simpler based on how it lets you abstract things - ex: no need for 1 standard rent scheme - allows for alot more experimentation and design flexibility * Happens to provide a nice slot for ETH 1.0 * Knowns and Unknowns: * Known - fundamentally possible to fulfill vision - complexity doesn't seem to increase with 2 layers over 1 - * Unknown - efficiency benefits from 1 type of committee over 2 types + * Unknown - efficiency benefits from 1 type of committee over 2 types * Unknown - challenges in fragmentation over different environments - harder or easier to upgrade? - Censorship attacks * Unknown - 2 layer structure economic design for fee markets * Discussion of [SSZ partial for light clients](https://youtu.be/dw2GmEuLr5k?t=2883) @@ -99,9 +101,9 @@ * Zak * We're going to want a more solidified spec for libp2p for future implementers and we also need numbers for message sizes (avg, max) for adequate pre-production testing - + # 5. [interop lockin](https://youtu.be/dw2GmEuLr5k?t=3955) -**Joseph:** Ongoing discussion over interop concerning: Why not libp2p first? Why minimum wire protocol for interop? +**Joseph:** Ongoing discussion over interop concerning: Why not libp2p first? Why minimum wire protocol for interop? **Jonny:** HackMD document attempting to outline with interop might look like with clients talking to eachother over libp2p. Mostly to simplify things and attempt to establish a baseline for node communication @@ -109,19 +111,19 @@ **Adrian:** if strip out higher level protcols of libp2p we're mostly working with TCP transport and multistream. Why can't we use basic libp2p with this functionality? -**Zak:** that should work, we just need everyone to interpret messages the same way for consistent execution. +**Zak:** that should work, we just need everyone to interpret messages the same way for consistent execution. **Mikerah:** [minimal libp2p implementation doc](https://github.com/ethresearch/p2p/issues/4) available for reference **Adrian:** libp2p should already be interoperable (Rust, Go, Javascript) off the shelf -**Felix:** spec for frame format that multistream uses? +**Felix:** spec for frame format that multistream uses? **Adrian:** yes **Felix:** is there a way to remove the multistream for testing purposes? -**Paul:** could they not just bind into the daemon? +**Paul:** could they not just bind into the daemon? **Mike:** yeah, we built the daemon version of libp2p specifically for languages without libp2p implementation would be able to interop @@ -135,7 +137,7 @@ **Felix:** we should have an evolving spec for the lower protocol and not just point people to libp2p **Mike:** we've actually been trying to specify what a libp2p 1.0 looks like implmented so perhaps we can contribute - + # Attendees * Danny Ryan (EF/Research) @@ -179,19 +181,3 @@ * Vitalik Buterin (EF/Research) * Zak Cole (Whiteblock) * Meeting notes: Michael LaCroix - - - - - - - - - - - - - - - - diff --git a/eth2.0-implementers-calls/call_019.md b/eth2.0-implementers-calls/call_019.md index 29f666f..b7764ef 100644 --- a/eth2.0-implementers-calls/call_019.md +++ b/eth2.0-implementers-calls/call_019.md @@ -1,25 +1,27 @@ # Ethereum 2.0 Implementers Call 19 Notes - + ### Meeting Date/Time: Thursday June 13, 2019 at 14:00 GMT ### Meeting Duration: 1.5 hours ### [GitHub Agenda Page](https://github.com/ethereum/eth2.0-pm/issues/45) ### [Audio/Video of the meeting](https://www.youtube.com/watch?v=izspfej05lE) +---------- + ## Suggestions **Suggestion 19.1**: Replace SHA256 with xxHash during fuzzing -**Suggestion 19.2**: Data visualization of testnet. +**Suggestion 19.2**: Data visualization of testnet. **Suggestion 19.3**: Add interop to agenda in September. **Suggestion 19.4**: Add to spec - the ability to dump. -**Suggestion 19.5**: Criteria to decide production ready should be written down. +**Suggestion 19.5**: Criteria to decide production ready should be written down. **Suggestion 19.6**: Standardize client implementation by writing specs. ----------- + **Danny**: Welcome everyone. @@ -29,9 +31,9 @@ We released [v0.7.0](https://github.com/ethereum/eth2.0-specs/releases/tag/v0.7. There has been work going on Fuzzing of the Go-specification (ZRNT) and getting some machinery in place to Fuzz the Python spec implementation. -**Protolamba**: There are these two efforts. +**Protolamba**: There are these two efforts. 1. Trying to find new bugs and everything thats been missing in the current spec. Looking into input bugs. New kind of input has to be checked. To add more condition to the spec. -2. Coverage checking helps identify untested parts specs to complement with new tests before the freeze. +2. Coverage checking helps identify untested parts specs to complement with new tests before the freeze. **Danny**: Fuzzing efforts right now isolates the implementation of this spec that go in Python but we have to expand it to clients. Any other testing update ? @@ -44,7 +46,7 @@ There has been work going on Fuzzing of the Go-specification (ZRNT) and getting # 2. Client Updates ## Prysmatic -**Terence**: +**Terence**: * Aligned block and epoch process in 0.7 * Re-implement caching * Benchmark for state transition with profiler and tracer and done optimization of block and epoch process. @@ -57,18 +59,18 @@ There has been work going on Fuzzing of the Go-specification (ZRNT) and getting * decided to deliver no caching until the spec is frozen. Don't want to redo any work. * For next, Shashper, we are looking into network implementation. In short term, we want to reintroduce substrate network library and get that to network and communication layer for our clients and lend some testnets. -## Artemis +## Artemis **Johnny**: -* We did a lot of profiling in optimizing on state transition stuff. When we first merged in v0.5.1, we noticed none of our optimization, caching worked anymore. So we profile that by reimplementing the cashing. -* We're starting on the next version of the spec. +* We did a lot of profiling in optimizing on state transition stuff. When we first merged in v0.5.1, we noticed none of our optimization, caching worked anymore. So we profile that by reimplementing the cashing. +* We're starting on the next version of the spec. * The good news is also our **short-lived testnets can run pretty much indefinitely**. -* We’ve broken out a validator client implementation. Fall in line with other clients by making them discrete from the Beacon chain. +* We’ve broken out a validator client implementation. Fall in line with other clients by making them discrete from the Beacon chain. * Joseph wrote an article about [Ethereum 2.0 Deposit Merkle Tree Implementation Guide](https://medium.com/@josephdelong/ethereum-2-0-deposit-merkle-tree-13ec8404ca4f?postPublishedType=initial). * also working with Harmony and Raul (protocol labs) on [minimal JVM implementation of libp2p](https://github.com/raulk/jvm-libp2p-minimal/) -* Released a bunch of bounties funded by Joe Lubin for super simple Network implementation so that we can test the consensus layer in multi-client testnet. +* Released a bunch of bounties funded by Joe Lubin for super simple Network implementation so that we can test the consensus layer in multi-client testnet. -## Trinity +## Trinity **Hsiao-wei Wang**: * Working on state transition to version 0.7 @@ -80,14 +82,14 @@ There has been work going on Fuzzing of the Go-specification (ZRNT) and getting **Ithaca**: Currently I'm using web3 -## Lodestar +## Lodestar **Cayman**: * In a branch, we are passing the v0.6 spec test except for BLS verification. We're still working through that. It's kind of odd because we're passing the BLS spec tests like the ones for BLS specifically. It has to do it like which private keys are being used. * Also in the past few weeks we integrate GossipSub and implemented the RPC protocol as it exists in the spec right now. So, now have networking layer. -* Also toying around with pulling up pieces of our code and rewriting them in assembly script which is a language that looks like typescript but it compiles to WASM. +* Also toying around with pulling up pieces of our code and rewriting them in assembly script which is a language that looks like typescript but it compiles to WASM. * We're starting with lmd ghost just to try something out and get used to the tooling. -* Our next steps - we're working towards like an end-to-end short-lived testnets. +* Our next steps - we're working towards like an end-to-end short-lived testnets. * We also need to finish our syncing modules, so that we can sync between the network and the chain. ## Nimbus @@ -96,10 +98,10 @@ There has been work going on Fuzzing of the Go-specification (ZRNT) and getting * Regarding the specs, 2 PRs pending for v0.7 compatibility. * We've backward sync integrity, so requesting blocks up to a point is available. * On Networking side, we've libp2p daemon integration in Nimbus. Currently working on releasing libp2p based testnets. -* On libp2p library on pure Nim, we have an issue on mobile because the mobile phone application makes it sleep and it kills the connection. +* On libp2p library on pure Nim, we have an issue on mobile because the mobile phone application makes it sleep and it kills the connection. * On the Eth1 front, we now have an API to watch the contract, the goal is to use Nimbus for that. * Regarding Eth1 security, we are starting fuzzing on the Discovery and fixing bugs for Eth1 implementation. -* Open question to all the clients - we would like to have data visualization of testnet. Add interop to agenda in September. Some kind of minimal RPC standout to request to clients - block we're on, how many things we've processed. So, that we can have some kind of nice display of what is going on multi client testnet. +* Open question to all the clients - we would like to have data visualization of testnet. Add interop to agenda in September. Some kind of minimal RPC standout to request to clients - block we're on, how many things we've processed. So, that we can have some kind of nice display of what is going on multi client testnet. **Danny**: Agreed. @@ -121,15 +123,15 @@ There has been work going on Fuzzing of the Go-specification (ZRNT) and getting **Preston**: About the document that translate, this week I'm putting together the API design. It's still a pull method but supports data providers like Amber data or Etherscan or anybody who wants to build some sort of read access, consume data remotely without having access to the file system, so it supports that use case. -**Paul**: Ther're two different things here. -What Mamy was talking about is metrics. Like developing useful metrics to tracking - how your system is performing (Anton is working). -What Preston is talking about is more like an API to the uses of the application. These are completely different things. +**Paul**: Ther're two different things here. +What Mamy was talking about is metrics. Like developing useful metrics to tracking - how your system is performing (Anton is working). +What Preston is talking about is more like an API to the uses of the application. These are completely different things. -**Mikerah**: We can also have this **extra stuff optional for client developers**. +**Mikerah**: We can also have this **extra stuff optional for client developers**. **Danny**: I agree. -**Suggestion 19.2** : Data visualization of testnet. +**Suggestion 19.2** : Data visualization of testnet. **Suggestion 19.3** :Add data visualization to interop agenda in September. **Suggestion 19.4**: Add to spec - the ability to dump. @@ -158,7 +160,7 @@ What Preston is talking about is more like an API to the uses of the application **Mikareh**: Fuzzing tool, is that specifically for Lighthouse or you are going to generalize it so other client team can also use it? -**Paul**: The one that we use now is Lighthouse specific. We would consider making it. The reason we haven't made it generic is because we already have a generic fuzzer so we didn't think it was useful. This one we are trying to keep it server side. If there is one that everyone is using, will definitely be helping with t hat one too. +**Paul**: The one that we use now is Lighthouse specific. We would consider making it. The reason we haven't made it generic is because we already have a generic fuzzer so we didn't think it was useful. This one we are trying to keep it server side. If there is one that everyone is using, will definitely be helping with t hat one too. **Adrian**: This is a Rust specific one . We're targeting very specific function inside our Networking spec in Lighthouse specifically, can't imagine we target other function in other clients. @@ -173,8 +175,8 @@ What Preston is talking about is more like an API to the uses of the application **Danny**: Whats going on in Phase2 front? **Vitalik**: The main update from on my side is [SSZ](https://github.com/ethereum/eth2.0-specs/issues/1160) stuff. Finally managed to get the SSZ partials implemented in Python. Realization I got from that is it's just way more complex at present that its used to be. The bulk of the complexity comes from Merkle proof paths in the dynamically size of objects like a list instead of a fixed length. If you remove that property so that there is an exact and stable one to one correspondence between paths. If some particular object would always have the exact same sequence of moving Merkle tree to get to it that would probably remove the bulk of the complexities from the SSZ partial implementation. I had some discussion with other people and the proposal that we seem to be converging on is basically requiring list to have a max length so that you can always have them in the same position. -It can be thought identical to Vyper like in Vyper you can have a fixed length list that has end value or you could have a dynamic link list. But with dynamic length list you have to specify what the maximum length is. The idea would be the serialization would not change at all except maybe at some point later in the future we might want to add another SSZ serialization Vyper list. For SSZ hashing length of a Merkle Branch would be length of a fixed value. -Example: If your list has a maximum length of 20. Then it get rounded up to 32. The length of Merkle branch would always be 5. Regardless of what we put the actual length of the list. It doesn't change depending the current / dynamic size of the list. +It can be thought identical to Vyper like in Vyper you can have a fixed length list that has end value or you could have a dynamic link list. But with dynamic length list you have to specify what the maximum length is. The idea would be the serialization would not change at all except maybe at some point later in the future we might want to add another SSZ serialization Vyper list. For SSZ hashing length of a Merkle Branch would be length of a fixed value. +Example: If your list has a maximum length of 20. Then it get rounded up to 32. The length of Merkle branch would always be 5. Regardless of what we put the actual length of the list. It doesn't change depending the current / dynamic size of the list. **Danny**: This is simplification on tree hashing side and not a major change on serialization. @@ -185,34 +187,34 @@ The one thing in the state that is currently dynamic is the validator set. For t **Vitalik**: I've been thinking about **how abstracted fee market would work?** How block producers will collect fees in the context that different execution environment existing. **The main design here is to simplify the experience for the block producers and make them get fair amount of revenue**. I came up with this idea where there are some standards for how execution environment pay fees. They would issue receipt in standardized format. The execution environment will collect the fees from the transaction centre, the execution environment will issue a receipt, the execution environment would have an account at the standard execution center called fee market where block producers will publish the receipt and collect the fees there. -Instead of using receipts, you would use synchronous calls, this would involve transaction being able to call other base layer transactions inside of themselves. +Instead of using receipts, you would use synchronous calls, this would involve transaction being able to call other base layer transactions inside of themselves. Another thing I realized we need to start taking seriously L2 moving forward is Light clients and Light clients server markets. Basically because everyone will be a Light client in almost every shard and there is going to be heavy reliance on this node that have data saves in that particular shards and provide Merkle branches in exchange of payment through a payment channel. If you have that architecture then Light client servers just could be the relayer and this transaction package could just be relayer. The category of node that specializes in maintaining the stage for a particular shards is something that probably we would want to think about more. I know some of Geth developers like Zolt spend some time thinking about it. **Danny**: He is working on channels to fund light servers on Eth1. -**Ben**: Quick update from PegaSys research. The Handle paper of [BLS signature aggregation at a large scale](https://arxiv.org/abs/1906.05132) is publish now. +**Ben**: Quick update from PegaSys research. The Handle paper of [BLS signature aggregation at a large scale](https://arxiv.org/abs/1906.05132) is publish now. **Justin**: Going back to Phase2, one of the things we look at is what is the work to be done to [Eth1 execution engine](https://ethresear.ch/t/work-to-natively-integrate-eth1-into-eth2/5573). There seems to be rough consensys that we wouldn't want to launch Phase2, without any execution engine, just the basic logic, the very thin layer. Instead we would want to go with a more controlled launch where we have either Eth1 as execution engine or a new execution engine which has all the goodies that is in, may be called as Eth2 execution engine or both at the same time. **Danny**: Agreed. -**Justin**: In addition to the consensys layer, I think it would be significant external infrastructure that needs to be built out and tested, like the fee market. We might also want to test Statelessness and things like that. -Another update about **Eth2 Genesis**, phase0. -One of the things merged recently is the removal of the Eth2 Genesis log from the deposit contract. We replaced it in the favor of a custom function subjectively runtime size as they were, which is both more secure because it allows us to better capture what we wants to have as a trigger for the Eth2 Genesis and also more flexible. +**Justin**: In addition to the consensys layer, I think it would be significant external infrastructure that needs to be built out and tested, like the fee market. We might also want to test Statelessness and things like that. +Another update about **Eth2 Genesis**, phase0. +One of the things merged recently is the removal of the Eth2 Genesis log from the deposit contract. We replaced it in the favor of a custom function subjectively runtime size as they were, which is both more secure because it allows us to better capture what we wants to have as a trigger for the Eth2 Genesis and also more flexible. There are few requirements for Genesis: * Sufficient Eth at stake (2mil ETH) * Sufficient production level clients (ideally 3 but could launch with 2 ) -If we’re to bake in a trigger in the deposit contract, when we’re ready to launch; this gives flexibility to update the Genesis trigger. +If we’re to bake in a trigger in the deposit contract, when we’re ready to launch; this gives flexibility to update the Genesis trigger. I guess **from a timing perspective, we're on track for the phase zero spec freeze on June 30th**. That might be a good opportunity at the end of this month to think about new realistic targets. -Two good things to think about is -**1. when we want to launch the deposit contract?** +Two good things to think about is +**1. when we want to launch the deposit contract?** * The idea is to launch the deposit contract ahead the target Genesis to allow time validators to make deposits. - * Do a deposit contract ceremony at Devcon. One of the reasons of having this public ceremony is so that we can all agree on the exact address of the deposit contracts and avoid scam deposit contracts. + * Do a deposit contract ceremony at Devcon. One of the reasons of having this public ceremony is so that we can all agree on the exact address of the deposit contracts and avoid scam deposit contracts. **2. Targate date for Genesis?** We still have quite a bit of time before the end of 2019. I think looking at the target Genesis dates towards the end of 2019 could be realistic. One thing that could work well is the 3rd of January 2020, the 11th anniversary of Bitcoin genesis. @@ -222,38 +224,38 @@ Assuming, we do the deposit contract ceremony at Devcon, it will provide us enou **Vitalik**: Same as we have in Eth1. Long running for some period of time with no bugs and the security auditing on all the clients. -**Suggestion 19.5**: Criteria to decide production ready should be written down in some post. +**Suggestion 19.5**: Criteria to decide production ready should be written down in some post. **Danny**: Agreed. -I think that launching the deposit contract we should at least have some target for going to production. Because otherwise we're asking people to put their money in for an indefinite amount of time. People may not actually show up and we don’t get the participation levels that we expect. +I think that launching the deposit contract we should at least have some target for going to production. Because otherwise we're asking people to put their money in for an indefinite amount of time. People may not actually show up and we don’t get the participation levels that we expect. **Joseph**: I have a question about the deposit contract. so I am assuming the changes you're talking about now are replacing the log with function for Eth2 genesis? -**Danny**: yes so essentially instead of listening for that log, you're running a function locally and get a new deposit on whether it's time to start +**Danny**: yes so essentially instead of listening for that log, you're running a function locally and get a new deposit on whether it's time to start **Joseph**: OK it's a call rather than a log it's going to be a system that would not going require gas for execution. -**Danny**: No, I am receiving logs locally and I've local logic on whether to start the genesis. We are going to be more dynamic to make decisions. Hopefully simpler and flexible. +**Danny**: No, I am receiving logs locally and I've local logic on whether to start the genesis. We are going to be more dynamic to make decisions. Hopefully simpler and flexible. -**Justin**: I mean that was the initial [trigger](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/core/0_beacon-chain.md#genesis-trigger) where we realize that people could make just one Eth deposits the minimum and make a bunch of these and then trigger the Genesis. Someone send 32 Eth at the same address repeatedly and then they triggered the Genesis. The shared source of truth argument is a little bit of an illusion and the reason is that we need an alternative backup mechanism without presets for source of truth. If we don't reach that , we don’t reach the target. +**Justin**: I mean that was the initial [trigger](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/core/0_beacon-chain.md#genesis-trigger) where we realize that people could make just one Eth deposits the minimum and make a bunch of these and then trigger the Genesis. Someone send 32 Eth at the same address repeatedly and then they triggered the Genesis. The shared source of truth argument is a little bit of an illusion and the reason is that we need an alternative backup mechanism without presets for source of truth. If we don't reach that , we don’t reach the target. -**Joseph**: That makes sense but I do a wonder why then we would calculate the sparse Merkle tree in the contract because essentially that the sparse Merkle trees are useless if we’re not ever meeting to any Genesis root value. +**Joseph**: That makes sense but I do a wonder why then we would calculate the sparse Merkle tree in the contract because essentially that the sparse Merkle trees are useless if we’re not ever meeting to any Genesis root value. **Justin**: It’s still valuable. The sparse merkle tree for the deposit basically allows for the accounting of the deposits and making sure that it is properly reflected on Eth2. -**Danny**: Most people will be handling a tree locally. So its a helper, gives you more flexibility. Say, if you started running this for a year from now as a validator, you might use that mechanism and actually have a sparse view of the deposits locally. +**Danny**: Most people will be handling a tree locally. So its a helper, gives you more flexibility. Say, if you started running this for a year from now as a validator, you might use that mechanism and actually have a sparse view of the deposits locally. **Joseph**: I think it would be great if we could get deposit root public. **Justin**: I just checked its public. -**Matt**: There are some more update on research. There are good conversation about, what a token is going to look like on execution environment of Eth2 at scaling Ethereum. And still thinking about different ideas there but I went to share an idea, I can get some feedback is about removing the need for like two transaction flows for ERC20. Discussion in [Eth magician forum](https://ethereum-magicians.org/t/brainstorming-the-token-standard-in-eth2/3135). +**Matt**: There are some more update on research. There are good conversation about, what a token is going to look like on execution environment of Eth2 at scaling Ethereum. And still thinking about different ideas there but I went to share an idea, I can get some feedback is about removing the need for like two transaction flows for ERC20. Discussion in [Eth magician forum](https://ethereum-magicians.org/t/brainstorming-the-token-standard-in-eth2/3135). More about it is the idea of sending a transaction to any kind of contract. Since it's already signed by you or by your contract wallets, you're essentially giving permission to send a token. It's just that right now there's not an ability of saying that you want to also send some ERC 20 token or something other than Ether in one transaction. It has to be split into like notifying the token contract and so if we can extend it to wear message.value is some token contract address and some amount of tokens. Then we can add some EE function or opcode essentially that like as a delegate call to the Token contract assuming it supports like some generic interface that supports transfers. So the message I sent her through delegate call will still be the message. Send her to the Target contract with the user one. Then I can verify that, that user was sent over to that contract. **Danny** : Help me understand, that this is functionality that could be defined in the contract and not the protocol wide? -**Matt**: Yeah, the message I value that's going to be kind of like an EE concept. Since it's not going to live at the protocol layer and so if we can just extend that in the context to be an address and a value. +**Matt**: Yeah, the message I value that's going to be kind of like an EE concept. Since it's not going to live at the protocol layer and so if we can just extend that in the context to be an address and a value. # 4. Network **[fjl](https://github.com/ethereum/eth2.0-pm/issues/45#issuecomment-501699492 )**: Sorry, I cannot join this time. discv5 updates: @@ -263,8 +265,8 @@ More about it is the idea of sending a transaction to any kind of contract. Si * Minor spec changes TBD. * We are negotiating an external protocol audit. -**Mike**: From last call we get some feedback on from production readiness to implementation and test environment. We're taking action on a lot of things that came up. For JVM LibP2P, I think Jonny covered it. Web3 Lab which is also looking to get involved too. so we may get more Firepower on the implementation. But, even without that it seems to be progressing pretty well. On the production readiness of JS LibP2P, we followed up with Chainsafe folks, who have worked on JS libP2P and know what its flaws and warts work. We are looking at making a grant to fix up things, mostly documentation issues so we now have a full-time writer on working on specifications for LibP2P. I know that's been a weak spot. Everyone who tries to implement it how can I implement this without a proper specification. We’ve a full time writer and will continue it indefinitely. -There was some benchmarking at the scaling Ethereum event in Toronto . We are working with White block to try to iterate on those tests. Its good initial work we’ve done. +**Mike**: From last call we get some feedback on from production readiness to implementation and test environment. We're taking action on a lot of things that came up. For JVM LibP2P, I think Jonny covered it. Web3 Lab which is also looking to get involved too. so we may get more Firepower on the implementation. But, even without that it seems to be progressing pretty well. On the production readiness of JS LibP2P, we followed up with Chainsafe folks, who have worked on JS libP2P and know what its flaws and warts work. We are looking at making a grant to fix up things, mostly documentation issues so we now have a full-time writer on working on specifications for LibP2P. I know that's been a weak spot. Everyone who tries to implement it how can I implement this without a proper specification. We’ve a full time writer and will continue it indefinitely. +There was some benchmarking at the scaling Ethereum event in Toronto . We are working with White block to try to iterate on those tests. Its good initial work we’ve done. **Danny**: There is telegram channel where you can ask questions with Mike to be better directed. Any questions? @@ -272,23 +274,23 @@ There was some benchmarking at the scaling Ethereum event in Toronto . We are wo **Mike**: Yeah, it is the intention to move on to TLS. The status of TLS varies with implementation. Whether it is complete or not various implementation. We've working TLS1.3 implementation in go-LibP2P implementation. I do not believe we have one in JS and other languages, but the point is not all of them have it. So, we are going to be falling back. -**Jacek**: Two aspects to that question : +**Jacek**: Two aspects to that question : 1. Is it finalized how LibP2P over TLS should look like from spec perspective or functionality perspective? For clients, do they have something to implement? 2. Are there any concerns that would prevent TLS from becoming the de facto transport for where LibP2P runs implementations have caught up? -**Mike**: On your last question, I am not TLS expert but talking to our expert Martin, there's no reason why we would not eventually go 100% TLS once implementation are caught up. We have no theoretical reason not to do that. +**Mike**: On your last question, I am not TLS expert but talking to our expert Martin, there's no reason why we would not eventually go 100% TLS once implementation are caught up. We have no theoretical reason not to do that. -**Jacek**: From a client perspective, on spec, have you decided on what you want? +**Jacek**: From a client perspective, on spec, have you decided on what you want? -**Mike**: I think we're happy with Go implementation and want to turn that into a spec. I can follow up with Martin, who is TLS expert and implemented that. Overall we're satisfied. -There are a few issues with Rust TLS which Rust main library does not support self designed certificates which we would like to use in some cases. There are some open questions. SO, NO, we are not fully certain but we're extremely close. +**Mike**: I think we're happy with Go implementation and want to turn that into a spec. I can follow up with Martin, who is TLS expert and implemented that. Overall we're satisfied. +There are a few issues with Rust TLS which Rust main library does not support self designed certificates which we would like to use in some cases. There are some open questions. SO, NO, we are not fully certain but we're extremely close. I think, it's not our intention to re-implement TLS on in every language. We're mostly relying on language standard libraries - Go or node1 for JS **Zak**: What's the technical reason behind implementing TLS or requiring it at all? -**Mike**: We want o support something that is industry standard and that TLS is the standard. SECIO is something that we wrote, and security audit of it will be done. But for a lot of use cases we think, it may be safe to support TLS1.3. We couldn't use it in past because, prior to version 1.3 TLS required you to have a notion of a server or a client. You had to designate one side as a server and other side as a client, it doesn't make sense in peer to peer. 1.3 finally gives us a way to not make that distinction. +**Mike**: We want o support something that is industry standard and that TLS is the standard. SECIO is something that we wrote, and security audit of it will be done. But for a lot of use cases we think, it may be safe to support TLS1.3. We couldn't use it in past because, prior to version 1.3 TLS required you to have a notion of a server or a client. You had to designate one side as a server and other side as a client, it doesn't make sense in peer to peer. 1.3 finally gives us a way to not make that distinction. **Zak**: If payloads are inherently cryptographically secured from the application layer, whats the point in providing additional encryption on the wire? @@ -298,18 +300,18 @@ I think, it's not our intention to re-implement TLS on in every language. We're **Mike**: I think this question is out of my expertise so I don't have a good answer for it. I think maybe we could follow up with Raul next week. -**Jacek**: One reason we of then want to use this because some Networks do packet filtering -And anything which they don't recognize like HTTP and HTTPS traffics, so those might be the reasons. +**Jacek**: One reason we of then want to use this because some Networks do packet filtering +And anything which they don't recognize like HTTP and HTTPS traffics, so those might be the reasons. -**Adrian**: The RPC protocol and the Gossip sub don’t have any encryption built in. Adding encryption at the network layer prevents. There is no encryption at the application layer at the moment. +**Adrian**: The RPC protocol and the Gossip sub don’t have any encryption built in. Adding encryption at the network layer prevents. There is no encryption at the application layer at the moment. **Zak**: Why not just use wire guard - VPN tunnel between two separate points? -**Danny**: I think it make sense to have the capability to support encryption in the way. We don’t encrypt at the application there nor should we necessarily look into encrypting at the application there, so having this an option is a good one. +**Danny**: I think it make sense to have the capability to support encryption in the way. We don’t encrypt at the application there nor should we necessarily look into encrypting at the application there, so having this an option is a good one. -**Zak**: Updates - +**Zak**: Updates - * We wrapped up our initial P2P gossip subtests. We had a call with Mike and Raul, a couple days ago. So we're currently in the process of like designing an actual test phase this them, I am drafting something this week. I will post it on GitHub and would like any feedback from the community in designing these tests and ensuring that the topology is correct, based on the consensus of the community. -* We are re-writing the client to remove the daemon our test client. We started working on a discovery v5 implementation and C++. SO we can perform similar tests and analysis on discovery v5; we are doing that concurrently. +* We are re-writing the client to remove the daemon our test client. We started working on a discovery v5 implementation and C++. SO we can perform similar tests and analysis on discovery v5; we are doing that concurrently. **Danny**: Each of you team seams to have at least one networking guys. When Zak does post the next plans for tests, I’d love if you all could take a look before the test implemented. @@ -321,7 +323,7 @@ And anything which they don't recognize like HTTP and HTTPS traffics, so those **Jacek**: I think import export should serve that. -**Zak**: Whatever that is, we should just define. We should just specify that like write a spec; this is how we should do it. We will implement that in all the clients just that we need to agree on what it is going to look like. +**Zak**: Whatever that is, we should just define. We should just specify that like write a spec; this is how we should do it. We will implement that in all the clients just that we need to agree on what it is going to look like. **Danny**: Agreed. @@ -333,29 +335,29 @@ And anything which they don't recognize like HTTP and HTTPS traffics, so those **Danny**: I did want to survey how people are thinking about and searching for attestation slashing. Cem and I were talking about that and I know that some of you have dug into it. If someone wants lay of the land as they see it, might help. **Ithaca**: From clients perspective, that just add complexities. There is no real obligation from a protocol point of view to perform slashing. Its almost outsourced like a third party. -Difficulties lies in the fact that we can't really write conformance test. +Difficulties lies in the fact that we can't really write conformance test. -**Paul**: Part of me thinking about moving into a separate process but not sure if it going to chew up the capacity to maintain consensus but that's actually just more complexity in the long run. +**Paul**: Part of me thinking about moving into a separate process but not sure if it going to chew up the capacity to maintain consensus but that's actually just more complexity in the long run. **Danny**: Generally our view consider narrow every time we have finality. But in doing so , if we receive an attestation for something that's outside of our block tree or may be for something in the past. We may or may not have the requisite data and see if the attestation is valid or see who is even the part of that attestation. We don't necessarily have the state to go and verify that decision. Under that consideration, even if it is slashable, we might just discard. That probably is fine in general because we finalized things. -**Paul**: If we want to try and incentivize clients to implement slashing, one way to do it might be when we release these testnets is to make bunch of open source tools that allow people to very easily create malicious blocks. Add the ability for people to cause chaos. If your clients doesn't support it then we fall of line but that's the way we incentivize people, it's really not protocol level. +**Paul**: If we want to try and incentivize clients to implement slashing, one way to do it might be when we release these testnets is to make bunch of open source tools that allow people to very easily create malicious blocks. Add the ability for people to cause chaos. If your clients doesn't support it then we fall of line but that's the way we incentivize people, it's really not protocol level. -**Danny**: We do want to have testnets in which say 50 % validators go offline and we go through an activity leak and during those times when your block tree becomes relatively large wrt your latest finalized and those are the times that you would be more concerned about people going back to two epochs and signing something new and attempting to mess with things. So, we should definetly create this scenarios. +**Danny**: We do want to have testnets in which say 50 % validators go offline and we go through an activity leak and during those times when your block tree becomes relatively large wrt your latest finalized and those are the times that you would be more concerned about people going back to two epochs and signing something new and attempting to mess with things. So, we should definetly create this scenarios. **Jacek**: I would be interested in hearing thoughts on slashing protection, client stashing data that they don't accidentally cause a slashable condition for their validator. How much extra data do we have to store because we voted for a branch that later became unviable ? SO that clients don't create the slashable condition accidentally because they have forgotten about it. **Danny**: The requisite data held can be very narrow. This is not optimal and in terms of the optionality given. If you remember your latest attstation, you just not vote on something that is from the past at all. I will add more to the validator guide him what you think is the minimal that you think. -**Paul**: As long as you never vote in future, there is always a case where you can choose to just skip a couple of duties and then you're safe again. But if you choose to vote in the future, you've to wait until you say. +**Paul**: As long as you never vote in future, there is always a case where you can choose to just skip a couple of duties and then you're safe again. But if you choose to vote in the future, you've to wait until you say. -**Dany**: The only case in which that is not true if your node sometime forgets the latest justified and points to a previous justified and wants to a new fork. Then you could end up doing us around. +**Dany**: The only case in which that is not true if your node sometime forgets the latest justified and points to a previous justified and wants to a new fork. Then you could end up doing us around. Slashing is hard that is something that we literally cannot launch without. Whether it is baked into clients or we have some sort of other processes running, we as a group need to solve this problem. # 6. Open Discussion/Closing Remarks -**Joseph**: Organizing Interop - We got contract sign and place called Muskoka. It will fit 25-35 people. Its **September 6-13**. I will send out RSVPs as soon as it is confirmed. It will be **restricted to implementers and researchers**. +**Joseph**: Organizing Interop - We got contract sign and place called Muskoka. It will fit 25-35 people. Its **September 6-13**. I will send out RSVPs as soon as it is confirmed. It will be **restricted to implementers and researchers**. **Hsaio**: Reminder: Devcon application is open. @@ -365,7 +367,7 @@ Slashing is hard that is something that we literally cannot launch without. Whet * Adrian Manning (Lighthouse/Sigma Prime) * Alex Stokes (Lighthouse/Sigma Prime) -* Alex B. +* Alex B. * Antoine Toulme (ConsenSys) * Anton N. * Ben Edgington (PegaSys) diff --git a/eth2.0-implementers-calls/call_021.md b/eth2.0-implementers-calls/call_021.md index fc3b3c5..b9899b8 100644 --- a/eth2.0-implementers-calls/call_021.md +++ b/eth2.0-implementers-calls/call_021.md @@ -1,110 +1,42 @@ # Ethereum 2.0 Implementers Call 21 Notes -## Contents - -- [Contents](#contents) -- [1 Meeting Details](#1-meeting-details) -- [2 Attendees](#2-attendees) -- [3 Agenda](#3-agenda) - - [3.1 Testing Updates](#31-testing-updates) - - [3.1.1 Overflow in Slashing](#311-overflow-in-slashing) - - [3.1.2 Spec Freeze](#312-spec-freeze) - - [3.1.3 Fuzzing](#313-fuzzing) - - [3.2 Client Updates](#32-client-updates) - - [3.2.1 Nimbus](#321-nimbus) - - [3.2.2 Artemis](#322-artemis) - - [3.2.3 Trinity](#323-trinity) - - [3.2.4 Yeeth](#324-yeeth) - - [3.2.5 Harmony](#325-harmony) - - [3.2.6 Lighthouse](#326-lighthouse) - - [3.2.7 Prysmatic](#327-prysmatic) - - [3.2.8 Lodestar](#328-lodestar) - - [3.2.9 Parity](#329-parity) - - [3.3 Research Updates](#33-research-updates) - - [3.3.1 Phase 0](#331-phase-0) - - [3.3.2 Phase 1](#332-phase-1) - - [3.3.3 Phase 2](#333-phase-2) - - [3.3.4 PegaSys](#334-pegasys) - - [3.3.5 Runtime Verification](#335-runtime-verification) - - [3.4 Network](#34-network) - - [3.4.1 Libp2p](#341-libp2p) - - [3.4.2 Gossiping Mechanism](#342-gossiping-mechanism) - - [3.5 Spec Discussion](#35-spec-discussion) - - [3.6 Open Discussion/Closing Remarks](#36-open-discussionclosing-remarks) - - - -## 1 Meeting Details - -- **Meeting Date-Time:** Thursday 2019/7/11 at [14:00 GMT](http://www.timebie.com/std/gmt.php?q=14) -- **Meeting Duration:** 1.5 hours -- **[Youtube Livestream](https://www.youtube.com/watch?v=YB8o_5qjNBc)** - -## 2 Attendees +### Meeting Date/Time: Thursday July 11, 2019 at [14:00 GMT](http://www.timebie.com/std/gmt.php?q=14) +### Meeting Duration: 1.5 hours +### [GitHub Agenda](https://github.com/ethereum/eth2.0-pm/issues/55) +### [Audio/Video of the meeting](https://www.youtube.com/watch?v=YB8o_5qjNBc) +### Moderator: Danny Ryan +### Notes: Edson Ayllon -- [Adrian Manning](https://github.com/AgeManning) -- [Alex Stokes](https://github.com/ralexstokes) -- [Ben Edgington](https://github.com/benjaminion) -- [Benjamin Burns](https://github.com/benjamincburns) -- [Carl Beekhuizen](https://github.com/CarlBeek) -- [Cem Ozer](https://github.com/cemozerr) -- [Daniel Ellison](https://github.com/zigguratt) -- [Dankrad Feist](https://github.com/dankrad) -- [Danny Ryan](https://github.com/djrtwo) -- [Dean Eigenmann](https://github.com/decanus) -- [Diederik Loerakker](https://github.com/protolambda) -- [Dmitriy Ryajov](https://github.com/dryajov) -- [Greg Markou](https://github.com/GregTheGreek) -- [Hsiao-Wei Wang](https://github.com/hwwhww) -- [Jacek Sieka](https://github.com/arnetheduck) -- [Jannik Luhn](https://github.com/jannikluhn) -- [John Adler](https://media.consensys.net/@adlerjohn) -- [Jonny Rhea](https://github.com/jrhea) -- JosephC -- [Joseph Delong](https://github.com/dangerousfood) -- [Justin Drake](https://github.com/JustinDrake) -- [Kevin Main-Hsuan Chia](https://github.com/mhchia) -- [Leo Bautista Gomez](https://github.com/leobago) -- [Luke Anderson](https://github.com/spble) -- [Mamy Ratsimbazafy](https://github.com/mratsim) -- [Matt Garnett](https://github.com/c-o-l-o-r) -- [Mike Goelzer](https://github.com/mgoelzer) -- [Mikhail Kalinin](https://github.com/mkalinin) -- [Musab Alturki](https://github.com/malturki) -- [Nicholas Lin](https://www.linkedin.com/in/nicholas-lin-50267ba3/) -- [Nicolas Liochon](https://github.com/nkeywal) -- [Paul Hauner](https://github.com/paulhauner) -- [Preston](https://github.com/prestonvanloon) -- [Raul Jordan](https://github.com/rauljordan) -- [Raúl Kripalani](https://github.com/raulk) -- [Steven Schroeder](https://github.com/schroedingerscode) -- [Trenton Van Epps](https://medium.com/@trenton.v) -- [Vitalik Buterin](https://vitalik.ca/) -- [Wei Tang](https://github.com/sorpaas) -- [Whiteblock](https://github.com/Whiteblock) -- [Will Villanueva](https://medium.com/@william.j.villanueva) -- [Zak Cole](https://github.com/zscole) +----------------------------- + +# Agenda -## 3 Agenda +- [1. Testing Updates](#1-testing-updates) +- [2. Client Updates](#2-client-updates) +- [3. Research Updates](#3-research-updates) +- [4. Network](#4-network) +- [5. Spec Discussion](#5-spec-discussion) +- [6. Open Discussion/Closing Remarks](#6-open-discussionclosing-remarks) -### 3.1 [Testing Updates](https://youtu.be/YB8o_5qjNBc?t=245) +---- +# 1. Testing Updates -#### 3.1.1 [Overflow in Slashing](https://github.com/ethereum/eth2.0-specs/pull/1286) +## 1.1 Overflow in Slashing -**Timestamp: [4:06](https://youtu.be/YB8o_5qjNBc?t=245)** +**Video:** [`[4:06]`](https://youtu.be/YB8o_5qjNBc?t=245) -**Danny Ryan**: Prysmatic Labs, Terence [Tsao], found an issue where the calculation and slashing was potentially overflowing. Relatively non-substantive changes (fixes, documentation, etc.) in v08x branch [#1286](https://github.com/ethereum/eth2.0-specs/pull/1286) includes a fix to this. This will branch will get out in the next few days. +Issue found where calculation and slashing potentially overflowed. v08x branch [#1286](https://github.com/ethereum/eth2.0-specs/pull/1286) includes a fix. -#### 3.1.2 [Spec Freeze](https://github.com/ethereum/eth2.0-specs/pull/1242) +## 1.2 Spec Freeze -**Timestamp: [5:12](https://youtu.be/YB8o_5qjNBc?t=309)** +**Video:** [`[5:12]`](https://youtu.be/YB8o_5qjNBc?t=309) -**Diederik Loerakker**: Spec Freeze is over now, can stop throwing up to the spec and build. +Spec Freeze is over. -#### 3.1.3 [Fuzzing](https://github.com/ethereum/eth2.0-specs/tree/dev/test_libs/pyspec/eth2spec/fuzzing) +## 1.3 Fuzzing -**Timestamp: [6:51](https://youtu.be/YB8o_5qjNBc?t=411)** +**Video:** [`[6:51]`](https://youtu.be/YB8o_5qjNBc?t=411) **Justin Drake**: The goal is to provide basic fuzzing infrastructure for all the clients. The purpose is so Client implementers don't have to worry too much about being compliant with the State Transition Function. @@ -169,20 +101,15 @@ In the next go-spec updates, I optimize, precompute this, precompute that, so we We'll keep everyone updated about Fuzzing over the coming weeks. -### 3.2 [Client Updates](https://youtu.be/YB8o_5qjNBc?t=830) - -#### 3.2.1 [Nimbus](https://github.com/status-im/nimbus) - -**Timestamp: [13:50](https://youtu.be/YB8o_5qjNBc?t=830)** +# 2. Client Updates +## 2.1 Nimbus -**Mamy**: We launched our testnet, based on libp2p daemon, this morning. +**Video:** [`[13:50]`](https://youtu.be/YB8o_5qjNBc?t=830) -We are working towards v0.8. All the small changes were integrated and right now a big focus is SSZ. +Testnet launched. Working towards v0.8. Focus is SZZ. State Transition function following pyspec naming convention. -We also started to align our State Transition function with pyspec in terms of naming. - -We had significant speed improvement during the past week, accumulated 20 to 30x speed-up on the State Transition benchmarks. Links, if people are interested in seeing what we did, so they can reproduce: +Accumulated 20 to 30x speed-up on the State Transition benchmarks. Links so others can reproduce: * [Speed up process_crosslinks(...) and get_crosslink_deltas(...) by 10x - 15x in state_sim #314](https://github.com/status-im/nim-beacon-chain/pull/314) * [~2x state_sim speedup via additional caching in get_crosslink_committee #316](https://github.com/status-im/nim-beacon-chain/pull/316) @@ -190,49 +117,41 @@ Published metrics library for Prometheus compact metrics: * [Nim metrics client library supporting the Prometheus monitoring toolkit](https://github.com/status-im/nim-metrics) -We have a EWASM research library we are very happy with. We have started a domain specific language in NIM that compiles to EWASM. It's quite competitive in terms of contract size: +EWASM research library developed. Contains domain specific language in NIM that compiles to EWASM. It's competitive in terms of contract size: * [Nimplay is Domain Specific Language for writing smart contracts in Ethereum, using the Nim macro system](https://github.com/status-im/nimplay) -On Ethereum 1, we had some connections issues that were resolved to Parity and Geth. - -#### 3.2.2 [Artemis](https://github.com/PegaSysEng/artemis) - -**Timestamp: [17:05](https://youtu.be/YB8o_5qjNBc?t=1025)** +On Ethereum 1.x, connections issues were resolved to Parity and Geth. -**Jonny Rhea**: We've updated, especially with the SSZ. +## 2.2 Artemis -Also been thinking about attester slashings, computational requirements for the worst scenario. +**Video:** [`[17:05]`](https://youtu.be/YB8o_5qjNBc?t=1025) -We see the need to investigate the network load, decide what strategy to use when aggregating. +Client updated, especially with SSZ. Contemplating attester slashings, computational requirements for the worst scenario. Need to investigate network load to decide a strategy for aggregating. -#### 3.2.3 [Trinity](https://github.com/ethereum/trinity) +## 2.3 Trinity -**Timestamp: [17:51](https://youtu.be/YB8o_5qjNBc?t=1071)** +**Video:** [`[17:51]`](https://youtu.be/YB8o_5qjNBc?t=1071) -**Hsiao-Wei Wang**: PySSZ has been synced to v0.8 and the State Transition update is ongoing. Its almost there thanks to Alex. +PySSZ synced to v0.8 and State Transition update is ongoing. -For the networking side, integrating with the Py library, we found some required issues that we need to fix on the upstream library. +For networking, we found issues which need fixed on the upstream library for integrating with the Py library. We are fixing some interoperability requirements. There is an insecure connections protocol in libp2p, which will be brought up in the Networking section of the call. -We are fixing some interoperability requirements. +## 2.4 Yeeth -There is an insecure connections protocol in libp2p, which will be brought up in the Networking section of the call. +**Video:** [`[19:11]`](https://youtu.be/YB8o_5qjNBc?t=1151) -#### 3.2.4 [Yeeth](https://github.com/yeeth) +Worked with Artemis. Returning to update Yeeth to the latest specification. -**Timestamp: [19:11](https://youtu.be/YB8o_5qjNBc?t=1151)** +## 2.5 Harmony -**Dean Eigenmann**: Was working with Artemis, but back to updating Yeeth to the latest spec version. +**Video:** [`[19:37]`](https://youtu.be/YB8o_5qjNBc?t=1176) -#### 3.2.5 [Harmony](https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/eth2.0-teams/harmony/) +Working on v0.8 spec update, SSZ part is still in progress. -**Timestamp: [19:37](https://youtu.be/YB8o_5qjNBc?t=1176)** +Started to work on a slot clock mechanism. PR created with a basic implementation. -**Mikhail Kalinin**: Working on an update to v0.8 spec, we're almost there, but SSZ part is still in progress. - -We started to work on a slot clock mechanism. We have a PR so far with basic implementation of that proposal. - -We have started a small research to investigate into attestation aggregation strategies. The goal is to evaluate an approach that doesn't involve building additional overlays. +Small research started to investigate attestation aggregation strategies. The goal is to evaluate an approach that doesn't involve building additional overlays. * [Add draft spec for plaintext key exchange protocol #186](https://github.com/libp2p/specs/pull/186) Working on minimal libp2p in JVM. @@ -240,85 +159,69 @@ Working on minimal libp2p in JVM. Worked on multistream implementation recently. -#### 3.2.6 [Lighthouse](https://github.com/sigp/lighthouse) - -**Timestamp: [20:57](https://youtu.be/YB8o_5qjNBc?t=1257)** +## 2.6 Lighthouse -**Adrian Manning**: Updating lighthouse to v0.8. We have to re-optimize our tree-hash caching to include for more padding nodes. +**Video:** [`[20:57]`](https://youtu.be/YB8o_5qjNBc?t=1257) -Defining more extensive HTTP APIs which is working to improve dev experience. +Updating to v0.8. Tree-hash caching will be re-optimized to include for more padding nodes. More extensive HTTP APIs are being defined to improve dev experience. Matt from ConsenSys is building out some SSZ partials into our codebase. -Matt from ConsenSys is building out some SSZ partials into our codebase. +Slowly testing an initial version of discovery v5 in small testnets. -Slowly been testing an initial version of discovery v5 in small testnets. - -Working towards standardizing a minimal/final libp2p spec for clients using libp2p. - -The libp2p work lead to updating our RPC. There's been discussion for the RPC to use separate protocol IDs per request: +Working towards standardizing a minimal/final libp2p spec for clients using libp2p. Libp2p work lead to updating our RPC. Discussion occured for the RPC to use separate protocol IDs per request: - [PR where we try to standardize the basic libp2p implementation](https://github.com/ethereum/eth2.0-specs/pull/1281). +## 2.7 Prysmatic +**Video:** [`[22:22]`](https://youtu.be/YB8o_5qjNBc?t=1342) -#### 3.2.7 [Prysmatic](https://github.com/prysmaticlabs) - -**Timestamp: [22:22](https://youtu.be/YB8o_5qjNBc?t=1342)** +Updated to v0.8, passing spec tests. Issues with Genesis trigger. Spec test is lacking of coverage. Passed SSZ tests. SSZ failed in some Block sanity tests. -**Raul Jordan**: Caught up to v0.8, passing all spec tests. +Readying for Prysm optimization. Working on code improvements, beacon chain testing, and general robust improvements to the client. -Issues with Genesis trigger. +## 2.8 Lodestar -There's a lack of coverage for cases of spec test. Passed all SSZ spec tests. Surprised that SSZ failed in some Block sanity tests. +**Video:** [`[24:03]`](https://youtu.be/YB8o_5qjNBc?t=1443) -Getting ready for optimizing Prysm, working on code improvements, beacon chain testing, and generally more robust improvements to the client. +Upgrading to v0.8. SSZ almost up-to-date, ironing out bugs with Proto and Prysm. -#### 3.2.8 [Lodestar](https://github.com/ChainSafe/lodestar) - -**Timestamp: [24:03](https://youtu.be/YB8o_5qjNBc?t=1443)** - -**Greg Markou**: Trying to upgrade to v0.8. - -Began building dev tooling. Will help with providers, like a Web3.js. - -SSZ almost up-to-date, ironing out bugs with Proto and Prysm. +Began building dev tooling, which will help with providers, like Web3.js. Should be up-to-date on [SimpleSerialize.com](https://simpleserialize.com/) for easy online testing. -We're working towards ensuring that BLS works properly in-browser as well. Some peculiar issues there, will keep you updated. +Working towards ensuring that BLS works properly in-browser as well. Some issues there, will provide updates. -Working to using Herumi so that we can have some diversity in BLS. +Working to using Herumi for diversity in BLS. -In regards to the client, comfortable to start doing Block production. Once we finish our update to v0.8, we'll start doing our testnet. Then getting it to work in-browser. +In regards to the client, comfortable to start doing Block production. Once updated to v0.8, testnet will be started, then getting it to work in-browser. -Going back onto assembly script. +Returning to assembly script. Also, NIM, we're coming after you guys on the ERC20 contract, we'll get ya. -#### 3.2.9 [Parity](https://github.com/paritytech/parity-ethereum) +## 2.9 Parity -**Timestamp: [27:54](https://youtu.be/YB8o_5qjNBc?t=1624)** +**Video:** [`[27:54]`](https://youtu.be/YB8o_5qjNBc?t=1624) -**Wei Tang**: Finished the merkleization library last week, hopefully, want to extend that into a caching library, but there are still a few missing pieces. +Finished the merkleization library last week hopefully. Want to extend the merkleization library into a caching library. -We're trying to update to v0.8 spec. The issue we had was in the SSZ, a substantial change for us. Large refactoring of the codebase. +Updating to v0.8 spec. Large refactoring of codebase required by the SZZ. -### 3.3 [Research Updates](https://youtu.be/YB8o_5qjNBc?t=1725) +# 3. Research Updates -**Timestamp: [29:08](https://youtu.be/YB8o_5qjNBc)** +**Video:** [`[29:08]`](https://youtu.be/YB8o_5qjNBc?t=1725) -#### 3.3.1 [Phase 0](https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/eth-2.0-phases/) +## 3.1 Phase 0 -**Timestamp: [34:50](https://youtu.be/YB8o_5qjNBc?t=2083)** +**Video:** [`[34:50]`](https://youtu.be/YB8o_5qjNBc?t=2083) -**Justin Drake**: In parallel to Phase 1 & Phase 2, the research team is doing is more education about Phase 0. Educational documents have been made. +Concurrent to Phase 1 & Phase 2, research team created education documents about Phase 0. -On July 15th 1:00 PM GMT there will be a 2nd Ethereum 2.0 AMA, an opportunity to ask questions related to your implementation work. +On July 15th 1:00 PM GMT there will be a 2nd Ethereum 2.0 AMA, an opportunity to ask questions related to your implementation work. Now that the spec is frozen, feel free to reach out to Justin Drake on Telegrams questions about the design. -Now that the spec is frozen, feel free to reach out with questions about the design. I'm Justin Drake on Telegram. +## 3.2 Phase 1 -#### 3.3.2 [Phase 1](https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/eth-2.0-phases/) - -**Timestamp: [29:08](https://youtu.be/YB8o_5qjNBc)** +**Video:** [`[29:08]`](https://youtu.be/YB8o_5qjNBc?t=1749) **Vitalik Buterin**: On research-side there's a list of To-Do's for Proof-of-Custody and Shard Blocks. @@ -344,9 +247,9 @@ Not seeing any unexpected difficulties on the Phase 1 side. It's looking better One of the primitives we're using is the Legendre symbol, as a PRF. It would still be good to have it audited because it's an assumption not used in production right now. -#### 3.3.3 [Phase 2](https://docs.ethhub.io/ethereum-roadmap/ethereum-2.0/eth-2.0-phases/) +## 3.3 Phase 2 -**Timestamp: [33:06](https://youtu.be/YB8o_5qjNBc?t=1986)** +**Video:** [`[33:06]`](https://youtu.be/YB8o_5qjNBc?t=1986) **Vitalik Buterin**: Not much progress from myself. One of the bigger issues and trade-offs to think about is still how relay markets would work. Would be good to get more feedback on that. @@ -368,28 +271,24 @@ Free markets, we didn't continue diving as we've been in transition. We'll be lo Team is growing. John Adler is collaborating with us. Trying to grow for Rust-based researchers as well. Trying to do more research on Phase 1/Phase 2, more Phase 2 focus, in parallel to expand a lot of this. -#### 3.3.4 [PegaSys](https://github.com/PegaSysEng) - -**Timestamp: [39:28](https://youtu.be/YB8o_5qjNBc?t=2368)** - -We continue to work on roll-ups. Nothing to share yet. +## 3.4 PegaSys -#### 3.3.5 [Runtime Verification](https://github.com/runtimeverification/algorand-verification) +**Video:** [`[39:28]`](https://youtu.be/YB8o_5qjNBc?t=2368) -**Timestamp: [39:44](https://youtu.be/YB8o_5qjNBc?t=2384)** +Nothing to share yet. -**Musab Alturk**: We have this formalization in the K framework, directly based on the specification. +## 3.5 Runtime Verification -Migrated to v0.8 and are looking to have something testable. +**Video:** [`[39:44]`](https://youtu.be/YB8o_5qjNBc?t=2384) -There's an abstract model, lower priority type of development at the moment, but helpful for the future. +Created formalization in the K framework, directly based on the specification. Migrated to v0.8 and are looking to have something testable. There's an abstract model, lower priority type of development at the moment, but helpful for the future. -### 3.4 [Network](https://youtu.be/YB8o_5qjNBc?t=2470) +# 4. Network -#### 3.4.1 [Libp2p](https://github.com/libp2p/js-libp2p) +## 4.1 Libp2p -**Timestamp: [41:10](https://www.youtube.com/watch?v=YB8o_5qjNBc&feature=youtu.be&t=2470)** +**Video:** [`[41:10]`](https://www.youtube.com/watch?v=YB8o_5qjNBc&feature=youtu.be&t=2470) **Mike Goelzer** The grant to Harmony for the minimal `jvm-libp2p` will be finalized Monday. @@ -416,7 +315,7 @@ All `libp2p` implementations are based on the same principles `go-libp2p` and `j **Dean Eigenmann**: What is the current state spec? **Mike Goelzer**: We would like `libp2p` to be a spec-first project. We have a docs writer opening PRs on the specs repo, to define the correct behavior based on what's happening in the Go implementation. - * [libp2p specification](https://github.com/libp2p/specs) +- [libp2p specification](https://github.com/libp2p/specs) In the meantime, we recommend you refer to the Go implementation. @@ -502,9 +401,9 @@ The person to contact is Yusef Napora, who is responsible for writing the specs Discover v5, contacted people for an audit on the protocol. -#### 3.4.2 Gossiping Mechanism +## 4.2 Gossiping Mechanism -**Timestamp: [1:07:56](https://youtu.be/YB8o_5qjNBc?t=4076)** +**Video:** [`[1:07:56]`](https://youtu.be/YB8o_5qjNBc?t=4076) **Whiteblock**: in person last week, we had Artemis, Prysmatic Labs, Lodestar for an exchange of handles using the Simple Hobbits approach. @@ -596,9 +495,9 @@ Then as you start cutting down on the amplification factor, if a particular mess Happy to continue the discussion. Open to exploring different approaches. -### 3.5 [Spec Discussion](https://youtu.be/YB8o_5qjNBc?t=5095) +# 5. Spec Discussion -**Timestamp: [1:24:57](https://youtu.be/YB8o_5qjNBc?t=5095)** +**Video:** [`[1:24:57]`](https://youtu.be/YB8o_5qjNBc?t=5095) **Danny Ryan**: I know implementers mentioned the SSZ. There were a couple more sophisticated types that were added to SSZ. @@ -638,16 +537,71 @@ Do we want to make empty vector illegal? Or do we want to make lists containing **Diederik Loerakker**: We already discussed this issue. If any implemented would need this kind of type, please join the issue in the specs repository. Otherwise, I think it's not too important. -### 3.6 [Open Discussion/Closing Remarks](https://youtu.be/YB8o_5qjNBc?t=5540) +# 6. Open Discussion/Closing Remarks -**Timestamp: [1:32:20](https://youtu.be/YB8o_5qjNBc)** +**Video:** [`[1:32:20]`](https://youtu.be/YB8o_5qjNBc?t=5540) -**Danny Ryan**: Any other things before we close today? +Invitations for the interop went out to team leads. Those invitations are good until the 14th. After the 14th, more invitations will be sent to teams wanting to attend. Please register in the next 3 days. -**Joseph Delong**: For the interop, I want to say the invitations went out to team leads. Those invitations are good until the 14th. +Next meeting is in two weeks. -After that, we will reshuffle and send out more invitations to some of the teams that are wanting to attend. Please do register in the next 3 days. +---- -**Danny Ryan**: It's easy and free to register. +# Annex -We will likely meet in 2 weeks, you can take a look at the calendar first. Talk to everyone soon. +## Links + +- [Overflow in Slashing](https://github.com/ethereum/eth2.0-specs/pull/1286) +- [Spec Freeze](https://github.com/ethereum/eth2.0-specs/pull/1242) +- [Fuzzing](https://github.com/ethereum/eth2.0-specs/tree/dev/test_libs/pyspec/eth2spec/fuzzing) +- [Libp2p](https://github.com/libp2p/js-libp2p) +- [libp2p specification](https://github.com/libp2p/specs) +- [Connections & upgrading #168](https://github.com/libp2p/specs/pull/168/files) +- [Yusef Napora's Github](https://github.com/libp2p/specs/commits?author=yusefnapora) +- [libp2p specification](https://github.com/libp2p/specs) +- [Runtime Verification](https://github.com/runtimeverification/algorand-verification) + +## Attendees + +- [Adrian Manning](https://github.com/AgeManning) +- [Alex Stokes](https://github.com/ralexstokes) +- [Ben Edgington](https://github.com/benjaminion) +- [Benjamin Burns](https://github.com/benjamincburns) +- [Carl Beekhuizen](https://github.com/CarlBeek) +- [Cem Ozer](https://github.com/cemozerr) +- [Daniel Ellison](https://github.com/zigguratt) +- [Dankrad Feist](https://github.com/dankrad) +- [Danny Ryan](https://github.com/djrtwo) +- [Dean Eigenmann](https://github.com/decanus) +- [Diederik Loerakker](https://github.com/protolambda) +- [Dmitriy Ryajov](https://github.com/dryajov) +- [Greg Markou](https://github.com/GregTheGreek) +- [Hsiao-Wei Wang](https://github.com/hwwhww) +- [Jacek Sieka](https://github.com/arnetheduck) +- [Jannik Luhn](https://github.com/jannikluhn) +- [John Adler](https://media.consensys.net/@adlerjohn) +- [Jonny Rhea](https://github.com/jrhea) +- JosephC +- [Joseph Delong](https://github.com/dangerousfood) +- [Justin Drake](https://github.com/JustinDrake) +- [Kevin Main-Hsuan Chia](https://github.com/mhchia) +- [Leo Bautista Gomez](https://github.com/leobago) +- [Luke Anderson](https://github.com/spble) +- [Mamy Ratsimbazafy](https://github.com/mratsim) +- [Matt Garnett](https://github.com/c-o-l-o-r) +- [Mike Goelzer](https://github.com/mgoelzer) +- [Mikhail Kalinin](https://github.com/mkalinin) +- [Musab Alturki](https://github.com/malturki) +- [Nicholas Lin](https://www.linkedin.com/in/nicholas-lin-50267ba3/) +- [Nicolas Liochon](https://github.com/nkeywal) +- [Paul Hauner](https://github.com/paulhauner) +- [Preston](https://github.com/prestonvanloon) +- [Raul Jordan](https://github.com/rauljordan) +- [Raúl Kripalani](https://github.com/raulk) +- [Steven Schroeder](https://github.com/schroedingerscode) +- [Trenton Van Epps](https://medium.com/@trenton.v) +- [Vitalik Buterin](https://vitalik.ca/) +- [Wei Tang](https://github.com/sorpaas) +- [Whiteblock](https://github.com/Whiteblock) +- [Will Villanueva](https://medium.com/@william.j.villanueva) +- [Zak Cole](https://github.com/zscole) diff --git a/eth2.0-implementers-calls/call_022.md b/eth2.0-implementers-calls/call_022.md index 6084e09..572a47c 100644 --- a/eth2.0-implementers-calls/call_022.md +++ b/eth2.0-implementers-calls/call_022.md @@ -1,12 +1,11 @@ # Ethereum 2.0 Implementers Call 22 Notes - + ### Meeting Date/Time: Thursday July 25, 2019 at [14:00 GMT](http://www.timebie.com/std/gmt.php?q=14) ### Meeting Duration: 45 min ### [GitHub Agenda Page](https://github.com/ethereum/eth2.0-pm/issues/64) ### [Audio/Video of the meeting](https://www.youtube.com/watch?v=ReSiB2940AE) - -#### Moderator: Danny Ryan -#### Scribe: Brent Allsop +### Moderator: Danny Ryan +### Scribe: Brent Allsop ## Agenda @@ -108,7 +107,7 @@ They've come up with a plan for for implementing a harnessed single shard phase ## 6 [Open Discussion]((https://www.youtube.com/watch?v=ReSiB2940AE&t=2173)) -**Danny Ryan** discussed [a proposal for Lodestar funding](https://molochdao.com/proposals/81) that would give Lodestar three months of runway. Solicited Moloch support. +**Danny Ryan** discussed [a proposal for Lodestar funding](https://molochdao.com/proposals/81) that would give Lodestar three months of runway. Solicited Moloch support. # Attendees diff --git a/eth2.0-implementers-calls/call_023.md b/eth2.0-implementers-calls/call_023.md index cd9303e..d10d7f9 100644 --- a/eth2.0-implementers-calls/call_023.md +++ b/eth2.0-implementers-calls/call_023.md @@ -4,9 +4,10 @@ ### Meeting Duration: 1.5 hours ### [GitHub Agenda Page](https://github.com/ethereum/eth2.0-pm/issues/68) ### [Audio/Video of the meeting](https://www.youtube.com/watch?v=Av74vZRXeKo) +### Moderator: Danny Ryan +### Scribe: Brent Allsop -#### Moderator: Danny Ryan -#### Scribe: Brent Allsop +---- ## Agenda - [1. Testing and Release Updates](#1-testing-updates) @@ -107,7 +108,7 @@ Event will be the 6th to the 13th. Don't need to bring food. It's catered for ab ## 6. [Open Discussion](https://www.youtube.com/watch?v=Av74vZRXeKo&t=80m10s) -None. Next meeting will be in two weeks time. +None. Next meeting will be in two weeks time. ## Attendees diff --git a/eth2.0-implementers-calls/call_024.md b/eth2.0-implementers-calls/call_024.md index 889ea7f..3a98c6d 100644 --- a/eth2.0-implementers-calls/call_024.md +++ b/eth2.0-implementers-calls/call_024.md @@ -1,12 +1,11 @@ # Ethereum 2.0 Implementers Call 24 Notes - + ### Meeting Date/Time: Thursday August 29, 2019 at 14:00 GMT ### Meeting Duration: 1.5 hours ### [GitHub Agenda Page](https://github.com/ethereum/eth2.0-pm/issues/73) ### [Audio/Video of the meeting](https://www.youtube.com/watch?v=sz87_i5Uy1I) - -#### Moderator: Danny Ryan -#### Scribes: Ben Edgington, Mamy Ratsimbazafy & Brett Robertson +### Moderator: Danny Ryan +### Scribes: Ben Edgington, Mamy Ratsimbazafy & Brett Robertson ---------- @@ -35,8 +34,8 @@ v0.8.3 released last week. No substantive changes from v0.8.2, but there are som [Timestamp 7:39](https://youtu.be/sz87_i5Uy1I?t=459) **Mamy**: -Berlin news: https://our.status.im/nimbus-berlin-update/ -Documentation: https://nimbus-libs.status.im/#get-started +Berlin news: https://our.status.im/nimbus-berlin-update/ +Documentation: https://nimbus-libs.status.im/#get-started Revamped build system, can directly use nim-beacon-chain instead of going through Nimbus Validator deposits from Eth1 almost done Solved most justification and finalisation issues @@ -46,7 +45,7 @@ Working on cryptography benchmarks Can have 2000 validators on a single laptop Networking: interop with Rust libp2, did gossipsub with Lighthouse. Using Go daemon. -### Artemis +### Artemis [Timestamp 11:03](https://youtu.be/sz87_i5Uy1I?t=661) **Shahan**: @@ -61,7 +60,7 @@ Currently benchmarking BLS and aggregation ### Prysmatic [Timestamp 13:29](https://youtu.be/sz87_i5Uy1I?t=809) -**Terence**: +**Terence**: New DB and new fork choice. Working nicely. Implementing initial sync Regular sync, gossipsub, discv5 looking good @@ -71,7 +70,7 @@ Working on lightclient, and slashing detection algorithm ### Lighthouse [Timestamp 14:54](https://youtu.be/sz87_i5Uy1I?t=894) -**Paul**: +**Paul**: - Upgraded to latest network spec - Debugged Go/Rust libp2p compatability with Nimbus - Implemented Vitalik’s fast BLS verification scheme @@ -89,7 +88,7 @@ Working on lightclient, and slashing detection algorithm ** Danny**: Don’t worry too much about discovery, we will mostly use static links for Interop initially -### Trinity +### Trinity [Timestamp 18:42](https://youtu.be/sz87_i5Uy1I?t=1122) **Hsiao-wei Wang**: @@ -100,7 +99,7 @@ Working on lightclient, and slashing detection algorithm -### Lodestar +### Lodestar [Timestamp 20:18](https://youtu.be/sz87_i5Uy1I?t=1218) **Cayman**: @@ -123,7 +122,7 @@ Not present ## 3. Research Updates [Timestamp 22:16](https://youtu.be/sz87_i5Uy1I?t=1335) -**Vitalik**: +**Vitalik**: [Timestamp 22:25](https://youtu.be/sz87_i5Uy1I?t=1345) - Karl’s [blog post](https://medium.com/plasma-group/ethereum-smart-contracts-in-l2-optimistic-rollup-2c1cef2ec537) yesterday on roll-up semi-layer 2 protocols; V publishing [a follow-up](https://vitalik.ca/general/2019/08/28/hybrid_layer_2.html) today. Relevant to Eth2 execution environments. @@ -132,7 +131,7 @@ Not present - [Issue #1340](https://github.com/ethereum/eth2.0-specs/issues/1340): simplifying epoch transitions. A possible change to the protocol to handle the case of many skip slits between block and its parents, which is currently expensive. Makes empty epochs O(1) to validate. -**Justin**: +**Justin**: [Timestamp 23:11](https://youtu.be/sz87_i5Uy1I?t=1391) - Doing a detailed review of Ph1 @@ -142,7 +141,7 @@ Not present - Also looking at Ph1 spec - Thinking about “Herd immunity” on libp2p -**Jacek (Status)**: +**Jacek (Status)**: [Timestamp 27:15](https://youtu.be/sz87_i5Uy1I?t=1635) - Concern about not validating messages: can be an amplification DoS vector. Can nodes validate only a subset of messages? @@ -151,7 +150,7 @@ Not present - Can now prove poly-log communication complexity of Handel aggregation protocol - Handel is designed for large committees, but will also work for small committees and brings advantages in privacy -- Privacy: would be good to break the mapping between IP address of a validator and its Public - Key (which is currently easy to discover). Published a technique yesterday on [ethresear.ch](https://ethresear.ch/t/anonymity-a-zkp-to-remove-the-mapping-ip-address-wallets-public-key-of-a-validator/6049) that uses a ZKP to obscure the mapping. +- Privacy: would be good to break the mapping between IP address of a validator and its Public - Key (which is currently easy to discover). Published a technique yesterday on [ethresear.ch](https://ethresear.ch/t/anonymity-a-zkp-to-remove-the-mapping-ip-address-wallets-public-key-of-a-validator/6049) that uses a ZKP to obscure the mapping. **Protolambda**: [Timestamp 32:46](https://youtu.be/sz87_i5Uy1I?t=1966) @@ -174,14 +173,14 @@ Received some interesting contributions at EthBerlin for Eth2.0 (see chat for li - Wireshark dissectors (that can decrypt). Should be useful for Interop. - Noise handshakes. Implementation in Go as reference implementation. -**Protolambda**: +**Protolambda**: - Test harnesses and benchmarking on the gossipsub Go reference implementation - Meshsim tool for analysing gossipsub networks ### API Repo [Timestamp 41:13](https://youtu.be/sz87_i5Uy1I?t=2473) -**Paul**: +**Paul**: - New [Eth2 API repo](https://github.com/ethereum/eth2.0-apis): will contain APIs that are generally agreed upon by a number of clients. These are not consensus critical, but some conformity is desirable for users. Will evolve over time. - Input from [Lighthouse](https://github.com/ethereum/eth2.0-APIs/pull/3) diff --git a/eth2.0-implementers-calls/call_025.md b/eth2.0-implementers-calls/call_025.md index 4991d60..7507525 100644 --- a/eth2.0-implementers-calls/call_025.md +++ b/eth2.0-implementers-calls/call_025.md @@ -1,15 +1,14 @@ # Ethereum 2.0 Implementers Call 25 Notes - -### Meeting Date/Time: Thursday September 19, 2019 at 14:00 GMT +### Meeting Date/Time: Thursday September 19, 2019 at 14:00 GMT ### Meeting Duration: ~ 50 mins ### [GitHub Agenda Page](https://github.com/ethereum/eth2.0-pm/issues/85) ### [Audio/Video of the meeting](https://www.youtube.com/watch?v=pEdqjXO6euY) - -#### Moderator: Danny Ryan -#### Notes: Pooja Ranjan +### Moderator: Danny Ryan +### Notes: Pooja Ranjan + ---------- - + ## Agenda 1. Testing and Release Updates 2. Client Updates @@ -19,7 +18,7 @@ 6. Spec discussion 7. Open Discussion/Closing Remarks -**Danny**: Welcome everyone! +**Danny**: Welcome everyone! ## 1. Testing and Release Updates @@ -38,43 +37,43 @@ Proto, do you want to add any other thing? ### Fuzzing -**Danny**: On the fuzzing front, we do plan on the next couple weeks open up, reopen the differential fuzzer, *Medi* from Sigma Prime is going to be helping out that effort. There are texts to the goal and we are at the point, where we begin integrating clients into differential fuzzers. More to come in the next few weeks on that. - +**Danny**: On the fuzzing front, we do plan on the next couple weeks open up, reopen the differential fuzzer, *Medi* from Sigma Prime is going to be helping out that effort. There are texts to the goal and we are at the point, where we begin integrating clients into differential fuzzers. More to come in the next few weeks on that. + ## 2. Client Updates -**Danny**: Today, I know we could probably talk about all the exciting things that happened instead instead we will save that for twitter, for individual blog updates. - +**Danny**: Today, I know we could probably talk about all the exciting things that happened instead instead we will save that for twitter, for individual blog updates. + ### Sigma Prime -**Adrian**: I will make this pretty short. -* At interop, we had some successes and LightHouse finalizes blocks. In that process, we find some of bugs that we still need to fix and some discrepancies between other clients that we've been working on that. +**Adrian**: I will make this pretty short. +* At interop, we had some successes and LightHouse finalizes blocks. In that process, we find some of bugs that we still need to fix and some discrepancies between other clients that we've been working on that. * We focusing a little bit more on building over the last week since interop will be adding some extra tool for interop testing. Because we found that during some of our testing, it would have been extra functionality to find some of the bugs quicker. * We're going to start focus on Discovery and making it interoperable with Go; so the Rust that we've built, we're going to start testing it with Go, which is inside Prysm. -* We're also finishing off some of the updates for the latest networks specs so that we can start syncing and hopefully have some longer lasting multiclient testnets. +* We're also finishing off some of the updates for the latest networks specs so that we can start syncing and hopefully have some longer lasting multiclient testnets. That's it from us, thanks. **Danny**: Cool, thanks. ### Prysmatic - + **Terence**: Yeah, pretty much the same update as Adrian. Our top priorities are working on: -* sync resilience. We currently don't handle missing blocks very well -* scaling validator account to 1024 -* we found a few BLS having issues -* updating to the latest network spec PR +* sync resilience. We currently don't handle missing blocks very well +* scaling validator account to 1024 +* we found a few BLS having issues +* updating to the latest network spec PR * also working on SSZ resilience. * we have made some fuzz testing on there and stuff working on test coverage improvement * doing some mutation testing -* we're also cleaning up our package and documentation +* we're also cleaning up our package and documentation * and make sure our frameworks are up to date. - + **Danny**: Cool, thanks. - -### Artemis -**Joseph**: Since interop, -* we integrated JVM libP2P. -* we started working on our sync. +### Artemis + +**Joseph**: Since interop, +* we integrated JVM libP2P. +* we started working on our sync. * we're just cleaning up some technical debt and the test. That covers it. **Danny**: Great. @@ -83,20 +82,20 @@ That's it from us, thanks. **Danny**: Cool, thanks. -### Lodestar - -**Cayman**:This week, +### Lodestar + +**Cayman**:This week, * we've been working on merging in our interop changes in master, fixing those up. -* we're also working on some roadmaps for the next few months so that we kind of have a better sense of priorities in or working on +* we're also working on some roadmaps for the next few months so that we kind of have a better sense of priorities in or working on * we started also developing a roadmap spe cifically for light client work, so want that to flesh out and get started with it. **Danny**: Cool, thanks. - -### Trinity - -**Hsiao-wei Wang**: -* we've learned about many issues during interop that could be summarized into two things: + +### Trinity + +**Hsiao-wei Wang**: +* we've learned about many issues during interop that could be summarized into two things: 1. the stablility, that we are now focusing on make internal test to be more stable and to organize logs to people structural eyes and also make well clear dashboard to monitorit 2. is the ability to distribute the software and set up the client that Alex and Brian have made a file during the interop and decide exploring other solution for various different operation system to support different OS to install the Trinity software. @@ -104,16 +103,16 @@ That's it from us, thanks. ### Harmony -**Mikhail**: Similar to other teams, +**Mikhail**: Similar to other teams, * we are doing some interop follow ups - some fixes and some new stuff that were created during interop. * Also apart from interop, I am going to work on Discovery. It has already almost implemented, the only one thing left is handshake and cryptography. * This implementation doesn't include a topic Discovery. So it's probably would make sense to do some integration tests with Lighthouse, when we are ready. * also working on QA, doing some testnet stuff. -* We decided to start the work on the fork choice testing maybe we can do some work here and publish some tests that are useful for or the other implementation because we think that fork choice is also important. +* We decided to start the work on the fork choice testing maybe we can do some work here and publish some tests that are useful for or the other implementation because we think that fork choice is also important. That's probably it for us. **Danny**: Cool, thanks. - + ### Nimbus **Danny**: Most of them are on flight. From [mratsim](https://github.com/ethereum/eth2.0-pm/issues/85#issuecomment-533089773) @@ -128,25 +127,25 @@ The Nimbus team will be in transit so here are our updates: * Lodestar will be committed soon (living locally on @arnetheduck computer) * Artemis and Shasper are missing * we'll see you in Devcon - + ### Parity **Danny**: Parity wasn't anble to attend but I know that Wei has been working through some pair wise interoperability tests. Last I heared, I knew hedid some work with Lighthouse and updating client to 0.8.3. Wei will be with us in Devcon. Great, did I miss anyone? - + ## 3. Research Updates -**Danny**: Vitalik and Justin are not here. I know, this busyness with Devcon comming up we've interop and something is going on in Tel Aviv. -* The spec repo has been a little bit slow. There some big PR submerge, some last updates to get in. +**Danny**: Vitalik and Justin are not here. I know, this busyness with Devcon comming up we've interop and something is going on in Tel Aviv. +* The spec repo has been a little bit slow. There some big PR submerge, some last updates to get in. * A **lot of focus** has been **in ensuring that** **Phase 1 sharding chain spec is clean** and to begin to **revisit** a lot of **the custody games**. * Relative high complexity in the custody games right now wrt some of the corner cases and edge cases, so planning on giving that a lot of love. Beyond that I am sure there would be a plenty of updates at the Devcon. Other research updates? -**Nicolas**: Outside normally changes, but we're looking at the integration of and learning after needs, so I implemented kind of Proof of Concept in **Vintage Time Protocol Simulator**. I will be working with team inside ConsenSys, specially Sahahan on how to add details. And likely to work with this as well we have recruited a team inside ConsenSys. It's more on implementation point of view. we're not changing the protocol itself. +**Nicolas**: Outside normally changes, but we're looking at the integration of and learning after needs, so I implemented kind of Proof of Concept in **Vintage Time Protocol Simulator**. I will be working with team inside ConsenSys, specially Sahahan on how to add details. And likely to work with this as well we have recruited a team inside ConsenSys. It's more on implementation point of view. we're not changing the protocol itself. -**Mikhail**: Guys excuse me, may I have a question to Nicolas? +**Mikhail**: Guys excuse me, may I have a question to Nicolas? Okay, we've been looking into the attestation and aggregation a bit and the things that I am not able to figure out is for example, handle applicable to work in that P2P Network? Does it strictly require a direct connection between validator and agregrators? **Nocolas**: It requires directly. So the way we see it on peer to peer layer when the committe is established, people will be able to exchange, maybe encrypted messages - what's my IP address of aggregator we're using and then there will be direct messages between those aggregators. @@ -155,13 +154,13 @@ Okay, we've been looking into the attestation and aggregation a bit and the thin **Shahan**: Hey Anton, I'm so sorry for butting in. There is [document](https://docs.google.com/document/d/16Srarfae9FOWPsr67OVL7aWrSujbtRrzPBz4Kv9PTak/edit ) that Nicolas and I are working on. What we used is synchronized asynchronously. About question like that, I can share that with you. -**Danny**: Okay, thanks. +**Danny**: Okay, thanks. ### Beacon chain Musab, any **updates on Beacon chain**? -**Musab**: The **specification is now almost finalized**. All the tests passed, which serves as a very nice validation of the model and right now we are doing **Coverage Analysis**. This is specific to the *K tune* we are using. We are hoping that we get some kind of evaluation of the test suit. And may be suggest some other tests to increase coverage. +**Musab**: The **specification is now almost finalized**. All the tests passed, which serves as a very nice validation of the model and right now we are doing **Coverage Analysis**. This is specific to the *K tune* we are using. We are hoping that we get some kind of evaluation of the test suit. And may be suggest some other tests to increase coverage. Once this is done, which we hope to be very soon, sometime; we will hopefully be able to share this with everyone. We're very excited to have this done once this is ready. **Danny**: Thanks. And some conversations to figure out next steps with the model. How to actually use it to verify some of the properties, we are interested - safety, being the most obvipus ones. @@ -187,39 +186,39 @@ Other research updates? Some of the Ewasm team members also attended interop and had some discussion at the interop. In past couple of months, the main focus for both teams at work were just to prove the feasibility of the idea. We've been focusing on two different efforts: * one **having hashing function and elliptic curve functions in EWASM** and executed to an interpretor and the goal was to fit that into the execution time limit we have set. * second work was related to **having good schemes for Merkle Proofs** and all the witnesses and obviously we've to look into SSZ partials and we also looked into Alexey's multi proof, which is in interval gases, if you guys have heared about that before. -* And there was a couple of other new initiatives to have some different schemes for Merkle proofs and businesses. Many of theses were implemented in different languages as well. Rust, Assembly script editor are major ones we want to be looking at. +* And there was a couple of other new initiatives to have some different schemes for Merkle proofs and businesses. Many of theses were implemented in different languages as well. Rust, Assembly script editor are major ones we want to be looking at. And we've some synthetic benchmarks. * The end results of this work is that the whole concept seems to be feasible, that we are kind of ready to move on to next stage. * The **next stage is to actually create usefull execution environments and benchmark them as a whole**. * The main execution environment that we are looking at is just a simple token transfer execution environment. Because that's like the core function needed for a couple of components as well, like the fee market. * The Ewasm team is really focusing on what I just explained. We all are really **focused in understanding our markets and fee markets better**. -At the interop, we need to look at it more in an integrated +At the interop, we need to look at it more in an integrated manner because they have a heavy influence on the design. I think that's the next step for the two teams to work on this more closely. The very last thing that happened at the interop was **Vitalik came up with a new proposal for phase2**. We spent quite a bit of time discussing it with him trying to understand it and comparing it to the current proposal. It was quite a busy period, sorry for the long update. Thank you. **Danny**: No, Thank you. Appreciate it. -I know, there's still a lot of questions out there regarding us. Some of that because it's still heavy research but some of this because of less information. For example, I haven't responded yet but somebody on the discor id asking about the **faith of the Eth 1 chain**, where it lies? I think, although we don't have 100% answers, **the execution environments have a bright future for the Eth1 chain, living inside the Eth 2**. I'll respond that to on discord too. +I know, there's still a lot of questions out there regarding us. Some of that because it's still heavy research but some of this because of less information. For example, I haven't responded yet but somebody on the discor id asking about the **faith of the Eth 1 chain**, where it lies? I think, although we don't have 100% answers, **the execution environments have a bright future for the Eth1 chain, living inside the Eth 2**. I'll respond that to on discord too. Is anyone from Quilt here? Any other research updates before we move on? - - + + ## 4. Network **Danny**: There was much work done on the network spec at interop. A lot of this primarily had to do with the structure of the request response messages sync and all the related sync messages rather than the gossip and some of the other structures. So, someone working on that would you like to give us a quick report on what happened there? **Adrian**: Yep, sure. So, it was proposed that it would be more efficient and little bit more general, that when requesting large amounts of blocks, previously the Spec required like batched amounts of blocks. So for long range, we're thinking we had blocks, **"blocks by range" is the new name of the RPC request** which you can request. Let's say a hundred blocks and previously you would have to buffer this and get the whole number of blocks in one hit. Now, you can effectively stream them through the networks. So, you send one block wrapped in an RPC response and then another one and then, until either you've completed the entire request or an error has happened. So, this allows implementations to read a single block from the database send it across the network and do this opposed to having to buffer large amounts of blocks. SO, that's the **main change in the two RPC request that required large amount of blocks**. We've renamed them -* one is **block by range** and +* one is **block by range** and * the other one is **blocks by roots** or effectively you can stream these things now that was the major change. That's it in summary. If anyone else has any questions. - + **Danny**: I have to ask, that code that you didn't want to remove and delete and rework, did you end up doing that? -**Adrian**: Partially, I couldn't delete all of it. So, I found a way to keep some of it. It still does batches so we can process blocks in batches but we stream across the network now. +**Adrian**: Partially, I couldn't delete all of it. So, I found a way to keep some of it. It still does batches so we can process blocks in batches but we stream across the network now. **Danny**: Cool, thanks. Any other question regarding that? As I mentioned on the discord, this spec parent lives in the b08x branch and is released into master, a minor release in next few days. But if you're working on that work sync, please check that out rather than the current one with me on 0.8.3. @@ -228,7 +227,7 @@ Did I see someone from Protocol Labs here? Is Michael here or Mike here? **Mike**: I am here. Raul's on vacatio this week. We really didn't have much of an update. I know some of the language teams have been making progress, which is great. They can speak to that if they want. We didn't have update for LibP2P to feed like, overall. -**Danny**: Some work at interop was initially just ironing out some of the idiosyncrasies between some of the language implementation. So at least on the interop subset of LibP2P that we're using, we do have general conformance and implementation starting is exciting. +**Danny**: Some work at interop was initially just ironing out some of the idiosyncrasies between some of the language implementation. So at least on the interop subset of LibP2P that we're using, we do have general conformance and implementation starting is exciting. **Mike**: Awesome. @@ -256,22 +255,22 @@ Any thoughts and comments on goals? **Antoine**: Yeah, I would like to throw my hat in the ring to help you see from the whiteblock perspective. We can see so many new built comming in. We can have to be test to that. So, I think we'd be happy to be involved in help the community in terms of metrics analysis efforts. -**Danny**: Great. +**Danny**: Great. **For the public** - There are increasingly build scripts and things where you can pull down and do some stuff but we don't have any of these like multi client. That's not ready yet. We're planning on supporting users on anything, we still have somethings to do with respect to stabilizing and especially getting the clients conforming to these specification. Is Preston here? Anything you would want to add or talk about? **Preston**: I've been thinking, Devcon is 3 weeks away. We just walked away from interop, that was really good. I was wondering, if we have anything specific in mind, we need to target in the next 3 weeks and then Q4 is coming. Prysmatic were just planning out for rest of the quarter to hear from you or anybody who is interested what the specific goals were coming up? -**Danny**: On my end, it's CI network informants mapping out a plan for public testnets and incentivise that. On client side, I expect continual stability. I know some of them post interop had a big sprint to get to interrupt but now we have a lot of things to clean up around that. Then, I guess going into Devcon, a lot of conversation is there about things coming out next couple of months. +**Danny**: On my end, it's CI network informants mapping out a plan for public testnets and incentivise that. On client side, I expect continual stability. I know some of them post interop had a big sprint to get to interrupt but now we have a lot of things to clean up around that. Then, I guess going into Devcon, a lot of conversation is there about things coming out next couple of months. -**Preston**: Okay, sounds great. I will follow up with you offline. +**Preston**: Okay, sounds great. I will follow up with you offline. **Danny**: Anything else on this? ## 6. Spec discussion -**Danny**: Any questions, concerns things that you've run into this goes here. +**Danny**: Any questions, concerns things that you've run into this goes here. None. @@ -288,10 +287,10 @@ Also the other question, what about contract deployment during the Devcon? **Danny**: You mean deposit contract? -**Mikhail**: Yeah. +**Mikhail**: Yeah. **Danny**: The primary blocker on the deposit contracts being deployed is the BLS standardization process which although has reached what is deemed and relatively stable place. People are still working on early implementations and test vectors. From the perspective of the deposit, we can't reasonably deploy that until we've the standard, in case anything related to public keys and the required initials signature changed. The current, almost certainly will not be deploy that come, because of this walker. Although it is moving fast for a standard, because there's a lot of demand for another blockchains that are involved. It's quite simply not going to be ready by October time. -On this form verification, that is complete. There was an issue in Vyper compiler bug, which I believe has been merged and the updated bytecode has been tested and verified and relating on an actual cut released from Vyper but that's no longer seen as a bottleneck. +On this form verification, that is complete. There was an issue in Vyper compiler bug, which I believe has been merged and the updated bytecode has been tested and verified and relating on an actual cut released from Vyper but that's no longer seen as a bottleneck. **Mikhail**: Okay, I see. @@ -303,20 +302,20 @@ On this form verification, that is complete. There was an issue in Vyper compile **Joseph**: I am just happy that everyone came. I am happy that all the clients showed up, ready to rock. That was the big surprise for me. -**Danny**: Looking up the calender. October 3rd is two week from now, shall we plan for meeting then? +**Danny**: Looking up the calender. October 3rd is two week from now, shall we plan for meeting then? **Joseph**: Sure, that is great. -**Danny**: Sorry, I meant about this call. +**Danny**: Sorry, I meant about this call. I think, 3rd make sense? Cool. Thank you everyone. # Date for Next Meeting: October 3, 2019 at 1400 UTC - + ## Attendees - + * Alex Stokes (Lighthouse/Sigma Prime) * Adrian Manning * Alex Beregszaszi (axic) @@ -333,7 +332,7 @@ Thank you everyone. * Ivan Martinez * Jannik Luhn (Brainbot/Research) * Jonny Rhea (Pegasys) -* Joseph Delong +* Joseph Delong * Kevin Mai-Hsuan Chia * Leo (BSC) * Marin Petrunic diff --git a/eth2.0-implementers-calls/call_26.md b/eth2.0-implementers-calls/call_026.md similarity index 93% rename from eth2.0-implementers-calls/call_26.md rename to eth2.0-implementers-calls/call_026.md index ebe7fa1..a6dad65 100644 --- a/eth2.0-implementers-calls/call_26.md +++ b/eth2.0-implementers-calls/call_026.md @@ -1,12 +1,13 @@ # Ethereum 2.0 Implementers Call 26 Notes - + ### Meeting Date/Time: Thursday October 24, 2019 at [14:00 GMT](http://www.timebie.com/std/gmt.php?q=14) ### Meeting Duration: 1:15 min ### [GitHub Agenda Page](https://github.com/ethereum/eth2.0-pm/issues/89) ### [Audio/Video of the meeting](https://www.youtube.com/watch?v=DXGeC7cg71Y) +### Moderator: Danny Ryan +### Scribe: Brett Robertson & Benjamin Edgington -#### Moderator: Danny Ryan -#### Scribe: Brett Robertson & Benjamin Edgington +--- ## Agenda @@ -23,70 +24,70 @@ **Danny:** It's been over a month since we had this call. -I released [v0.8.4](https://github.com/ethereum/eth2.0-specs/releases/tag/v0.8.4) today, it has been a long time coming. It is primarily some testing updates based off of some of the consensus issues that we found at InterOp, along with the networking updates that were also primarily driven at InterOp. -It includes chunking, listed responses for better streaming or for enabling streaming and modifying some of the message structures to better facilitate the sync. +I released [v0.8.4](https://github.com/ethereum/eth2.0-specs/releases/tag/v0.8.4) today, it has been a long time coming. It is primarily some testing updates based off of some of the consensus issues that we found at InterOp, along with the networking updates that were also primarily driven at InterOp. +It includes chunking, listed responses for better streaming or for enabling streaming and modifying some of the message structures to better facilitate the sync. -We are staging an upcoming semi-major release. There are a number of PRs that are under review. So these things are stuff that has come out of audits for example hardening of the fork choice rule against some of the test attack vectors found by Rhea, but also some other stuff which are some substantive changes to [Phase 0](https://github.com/ethereum/eth2.0-specs/pull/1428) with respect to removing the crosslink scaffolding such that we can continue development while we iron out the actual direction will take on Phase 1. +We are staging an upcoming semi-major release. There are a number of PRs that are under review. So these things are stuff that has come out of audits for example hardening of the fork choice rule against some of the test attack vectors found by Rhea, but also some other stuff which are some substantive changes to [Phase 0](https://github.com/ethereum/eth2.0-specs/pull/1428) with respect to removing the crosslink scaffolding such that we can continue development while we iron out the actual direction will take on Phase 1. Protolambda has an announcement. **Protolambda:** -I shared this diagram on [Twitter](https://twitter.com/protolambda/status/1187320137092714496?s=20) about infrastructure because programs just before DevCon during DevCon and the conference just at Taipei after was too busy to launch. But not that the things are calming down and then it onboard clients on this testing infrastructure and do this performance testing of all the clients in parallel. And then in the next like week or two, I'll reach out to clients and ask them to help with the setup scripts for the official state transitions. +I shared this diagram on [Twitter](https://twitter.com/protolambda/status/1187320137092714496?s=20) about infrastructure because programs just before DevCon during DevCon and the conference just at Taipei after was too busy to launch. But not that the things are calming down and then it onboard clients on this testing infrastructure and do this performance testing of all the clients in parallel. And then in the next like week or two, I'll reach out to clients and ask them to help with the setup scripts for the official state transitions. **Danny:** -Proto has been very actively working on this since InterOp and I'm excited about this as we move towards merged testnets. +Proto has been very actively working on this since InterOp and I'm excited about this as we move towards merged testnets. -Next up is a update from Mehdi on fuzzing. +Next up is a update from Mehdi on fuzzing. **Mehdi:** -So as you all probably this is a follow on from the work started by Guido. -So, we now have it working for block processing, block header processing, attestation processing and chopping. +So as you all probably this is a follow on from the work started by Guido. +So, we now have it working for block processing, block header processing, attestation processing and chopping. So is all working on the latest version of the spec v0.8.3. -**Danny:** There were zero substantive changes to the state transition or some of the core stuff in v0.8.4 so you should be good to go. +**Danny:** There were zero substantive changes to the state transition or some of the core stuff in v0.8.4 so you should be good to go. -**Mehdi:** +**Mehdi:** -We have modified the block fuzz target last week to allow clients to essentially go to beacon state from the file. So we now have a pre-processing function that uses a stake ID reference and which actually passes the relevant state to the all the first targets. So this was a re-architecture of the way we handle the Corpus for both of the beacon state and the block. +We have modified the block fuzz target last week to allow clients to essentially go to beacon state from the file. So we now have a pre-processing function that uses a stake ID reference and which actually passes the relevant state to the all the first targets. So this was a re-architecture of the way we handle the Corpus for both of the beacon state and the block. -So, so far we have guaranteed pi-spec and lighthouse on these fuzzers. Pi-spec is very slow. So we're probably going to want to remove it when deploying to production the fuzzing infrastructure. +So, so far we have guaranteed pi-spec and lighthouse on these fuzzers. Pi-spec is very slow. So we're probably going to want to remove it when deploying to production the fuzzing infrastructure. -We are also tweaking the fuzzer to ensure consistency of behavior across different implementations when returning empty bytes as opposed to an initialized pointers. +We are also tweaking the fuzzer to ensure consistency of behavior across different implementations when returning empty bytes as opposed to an initialized pointers. -We're also working on adding epoch state transitions. So currently looking at process justification finalization, process cross links, process final updates and so on. So this should be fairly straight forward since these functions will only take a beacon state as an input. +We're also working on adding epoch state transitions. So currently looking at process justification finalization, process cross links, process final updates and so on. So this should be fairly straight forward since these functions will only take a beacon state as an input. -We're also exploring creating facilitators - these are also mostly seen as lead parcel plugins to enable structware mutation based fuzzers. So this would help greatly with the coverage. And is another alternative that we could also potentially use is leveraged libprotobuf-mutator also known as LPM. It would essentially help us translate a decoded assisted object into a protobuf and back. +We're also exploring creating facilitators - these are also mostly seen as lead parcel plugins to enable structware mutation based fuzzers. So this would help greatly with the coverage. And is another alternative that we could also potentially use is leveraged libprotobuf-mutator also known as LPM. It would essentially help us translate a decoded assisted object into a protobuf and back. -So first to make an informed decision, we needed accurate coverage measurement. So we decided to focus on that. That's something that we're currently working on. +So first to make an informed decision, we needed accurate coverage measurement. So we decided to focus on that. That's something that we're currently working on. So while we're doing this, this would essentially allows generate and mutate beacon states rather than sticking with known value States. -We're also adding support for more beacon state inputs by essentially adding post state into the list of known valid states that we should lead fuzzer into the input corpora. And finally we started reaching out to some of you guys to onboard additional implementations. So we're looking at onboarding Nim which we should in the very near future, this week on next and then we'll move on to Go, Java and Javascript. +We're also adding support for more beacon state inputs by essentially adding post state into the list of known valid states that we should lead fuzzer into the input corpora. And finally we started reaching out to some of you guys to onboard additional implementations. So we're looking at onboarding Nim which we should in the very near future, this week on next and then we'll move on to Go, Java and Javascript. ## 2. [Client Updates](https://youtu.be/DXGeC7cg71Y?t=730) ### Lighthouse -**Paul Hauner:** +**Paul Hauner:** -So we've been working with Felix to get a standard disk C5 spec without topic going. He's updated the rust code to a new spec and he's tests across compatibility with the reference go code. Ed's talking to prysm about how to test out discoveries and they've also updated to the latest go code. And Huan is working on a basic implementation of topics which is not yet merged. +So we've been working with Felix to get a standard disk C5 spec without topic going. He's updated the rust code to a new spec and he's tests across compatibility with the reference go code. Ed's talking to prysm about how to test out discoveries and they've also updated to the latest go code. And Huan is working on a basic implementation of topics which is not yet merged. -From my side, I've been working on F1 linking. Mostly that. I've create a couple spec issues for some unspecified behavior when making F1 votes if things are going wrong. +From my side, I've been working on F1 linking. Mostly that. I've create a couple spec issues for some unspecified behavior when making F1 votes if things are going wrong. Also raised and interesting attack this morning about how you can basically attain majority after 2 epochs after genesis. -Also, working to build Genesis off prysms deposit contract. I am pretty close, but still not quite there, probably tomorrow or tonight. +Also, working to build Genesis off prysms deposit contract. I am pretty close, but still not quite there, probably tomorrow or tonight. -Scott is working on slashing protection for the validity client with a nice scheme. +Scott is working on slashing protection for the validity client with a nice scheme. -Current found some solid optimizations in the rust BLS library and at the same time we're also building some basic rust bindings for Harumi to see if it's worth us switching over to. +Current found some solid optimizations in the rust BLS library and at the same time we're also building some basic rust bindings for Harumi to see if it's worth us switching over to. What might affect some people trying to do InterOp is that we are going to change the way that you run Lighthouse. So we're going to present a validity client in the beacon node as separate binaries. We're going to move among the one binary code Lighthouse. So it's going to feel a lot more like parity with their subcommands. That's it from me. -### Artemis +### Artemis **Joseph Delong:** @@ -116,13 +117,13 @@ We brought onto a new team member, Tuyen, and he's been contributing and finally **Zahary:** -Then this +Then this -Before I start I will mention that Mamy has created an organization on this GitHub call Ethereum 2 clients and the idea of this organization is that would be a suitable place to store the scripts for that we developed during interop to run testnets between the multiple clients and then it would also help other useful projects such as low-level gossip subchat so we can test the libP2P implementation for conformance. So all the teams should have received an invite for this for being admins and once you are in you can add more people from your team. +Before I start I will mention that Mamy has created an organization on this GitHub call Ethereum 2 clients and the idea of this organization is that would be a suitable place to store the scripts for that we developed during interop to run testnets between the multiple clients and then it would also help other useful projects such as low-level gossip subchat so we can test the libP2P implementation for conformance. So all the teams should have received an invite for this for being admins and once you are in you can add more people from your team. So moving onto updates… We've been working on Eth 1 integration. We are pretty much wrapping this up and we are looking forward to participating in a shared testnet with a contract deployed on Gorlie. Right now we are happy implemented the latest spec 0.8.4 but I guess the consensus here will be that the cross-links simplification will be included in this shared testnet. I'll be expecting feedback from everyone. Otherwise, we'll be now so adding a lot of metrics two Nimbus and we plan to have a public refined instance once the testnet is running and we'll be running probably like 80 or 100 nodes on a server cluster and will be exposing the matrix from that. There has been significant progress in our native libP2P implementation. We are still using the daemon but we've made the first steps towards integrating the native one so it will be possible in the near future to switch between the two implementation in Nimbus. Jacek wanted to share that the ncoi tool, that he has developed during the interop, is now much more refined it and it's already sitting in the Master branch. So if anyone is curious to use it you can find it there. We've also developed fuzzing framework which allows us to use IFL, american fuzzer and lib fuzzer with programs developed in Nim. And now we are just testing the waters, but the initial focus will be on the lower level layers components such as cryptography, SSZ serialization and so on. It will be gradually moving on to the high level components. We hope to integrate without sigma prime and sigma prime differential fuzzer soon. And finally we had to spend some time integrating and switching to Nim 1.0, which was released just a few weeks ago. And actually we had to switch to the very latest version which was released yesterday. So mean was so we assume compatible with Nim 1.2 and that's it. -### Trinity +### Trinity **Hsiao-Wei Wang:** @@ -132,29 +133,29 @@ So after DevCon we have been working on making our libP2P implementation more co **Wei Tang:** -I'm fixing our two remaining issues of interop and hopefully to try to connect with some of the current other client testsnets and will also try to fix those issues in testing. I'm trying to fix some of the issues with the Casper engine it turns out there are some design issues. So I'm trying to fix that as well. +I'm fixing our two remaining issues of interop and hopefully to try to connect with some of the current other client testsnets and will also try to fix those issues in testing. I'm trying to fix some of the issues with the Casper engine it turns out there are some design issues. So I'm trying to fix that as well. ## 3. [Research Updates](https://youtu.be/DXGeC7cg71Y?t=1687) -**Danny:** +**Danny:** -There has been a lot of discussion around the Phase 1 proposal. Vitalik discussed this at length and various workshops at DevCon and on the Blog Posts online. Essentially, it makes the trade-off to have fewer shards at least the start but the ability to cross-link in the best case every shard, every slot facilitate simple slot time inter-shard communications. I don't think we need to go super in-depth into its day. The primary primary application is that it changes some of the Phase 0 machinery that we had in place for cross-links. In retrospect obviously, we were prematurely putting that in the spec.So I have a Phase 0 spec update PR that just removes cross-links altogether from Phase 0. Funny enough cross-links and the updating of cross links and the calculation of reward cross-links was one of our biggest source of consensus errors at interop so would be nice to just remove it anyway. There is a PR up for review and it's been under review for about a week and I think we're very close merging it in 0.9. When we get to the testnet discussion we can discuss the implications on testnets which version we should be testing etc. +There has been a lot of discussion around the Phase 1 proposal. Vitalik discussed this at length and various workshops at DevCon and on the Blog Posts online. Essentially, it makes the trade-off to have fewer shards at least the start but the ability to cross-link in the best case every shard, every slot facilitate simple slot time inter-shard communications. I don't think we need to go super in-depth into its day. The primary primary application is that it changes some of the Phase 0 machinery that we had in place for cross-links. In retrospect obviously, we were prematurely putting that in the spec.So I have a Phase 0 spec update PR that just removes cross-links altogether from Phase 0. Funny enough cross-links and the updating of cross links and the calculation of reward cross-links was one of our biggest source of consensus errors at interop so would be nice to just remove it anyway. There is a PR up for review and it's been under review for about a week and I think we're very close merging it in 0.9. When we get to the testnet discussion we can discuss the implications on testnets which version we should be testing etc. -**Vitalik:** +**Vitalik:** I've been thinking about Phase 1 spec issues and how to optimize beacon blocks more, how to calculate the data availability roots and a couple of other things. I have a couple of open issues out but generally nothing especially hard has come out yet. Like a lot of it is basically just like problems about how do we pack bytes together. Otherwise, yeah, I don't see any super fundamental problems. Maybe the more fundamental problem, well, not even fundamental but just difficulty is there more Phase 2 related ones like how to actually do like how to actually do guaranteed across shard movement of Eth between shards for example. Basically, there's challenges there that have to do with do we want to force every shard to communicate to every other shard with P2P in every single block. Do we want to have that as like more of a second level process and so on and so forth, but that's kind of still thinking. I guess right now, I'm still trying to come up with simplification and modifications for the existing Phase 1 design and still kind of have my eyes and ears open for any potential challenges that we haven't thought about yet. I'm expecting other people to come in with their own opinions about like how particular things to be architected eventually. -**Justin Drake:** +**Justin Drake:** -One update which is relevant to Phase 0 is BLS signatures. So on the standardization I'd say we're in a very good place. The spec really hasn't changed for the last several months with the exception, which is of note, of a very minor kind of security bug which should be very easy fix, like a one-line change. Riad Wahby who is one of the authors of the Wahby-Boneh hash function that we are using is doing an amazing job terms of taking ownership of the standardisation efforts. Lots of polishing. He's also addressed various patents or possible patent infringements and suggested workarounds for those. Between the 16th and the 22nd of November, there's going to be a CFRG meeting with diverse people involved in the standardization. And at that point, I guess the spec can be considered frozen. +One update which is relevant to Phase 0 is BLS signatures. So on the standardization I'd say we're in a very good place. The spec really hasn't changed for the last several months with the exception, which is of note, of a very minor kind of security bug which should be very easy fix, like a one-line change. Riad Wahby who is one of the authors of the Wahby-Boneh hash function that we are using is doing an amazing job terms of taking ownership of the standardisation efforts. Lots of polishing. He's also addressed various patents or possible patent infringements and suggested workarounds for those. Between the 16th and the 22nd of November, there's going to be a CFRG meeting with diverse people involved in the standardization. And at that point, I guess the spec can be considered frozen. -Another update on the BLS stuff is there's this Library called [Herumi](https://github.com/herumi/bls) and it's offered and maintained by Shigeo Mutsinari who came to to DevCon and met some of the present guys and it turns out that this Library seems to be significantly faster than and other libraries like Milagro, the dizzy cache library. A recent benchmark from the Lighthouse Depot suggest that it's 2.4x faster than Milagro. So we're in touch with the author and we're considering a possible grant. One of the complaints that we have had in the past is that the integration with various languages has been not so easy. So working on simplifying the integration for Rust and Java and maybe even other languages will be a priority. He also thinks he can make the library even faster. So right now his pairings take 0.6 of a second, but he thinks he can shave off and 10-20%. It will also be good, for him to implement a really fast version of the Wahby-Boneh hash function. And you know, there's also the possibility of doing formal verification on this specific library being floated around. +Another update on the BLS stuff is there's this Library called [Herumi](https://github.com/herumi/bls) and it's offered and maintained by Shigeo Mutsinari who came to to DevCon and met some of the present guys and it turns out that this Library seems to be significantly faster than and other libraries like Milagro, the dizzy cache library. A recent benchmark from the Lighthouse Depot suggest that it's 2.4x faster than Milagro. So we're in touch with the author and we're considering a possible grant. One of the complaints that we have had in the past is that the integration with various languages has been not so easy. So working on simplifying the integration for Rust and Java and maybe even other languages will be a priority. He also thinks he can make the library even faster. So right now his pairings take 0.6 of a second, but he thinks he can shave off and 10-20%. It will also be good, for him to implement a really fast version of the Wahby-Boneh hash function. And you know, there's also the possibility of doing formal verification on this specific library being floated around. -One piece of good news is that Guido has come back. So he had to do a bunch of other stuff and now he's he's available again. And so he's actually currently working on fuzzy testing the Herumi library. +One piece of good news is that Guido has come back. So he had to do a bunch of other stuff and now he's he's available again. And so he's actually currently working on fuzzy testing the Herumi library. And final update on the BLS stuff the has been a very interesting [paper](https://eprint.iacr.org/2019/1177) recently by Mary Maller where she describes a technique to aggregate signatures in such a way that the aggregated signature is cheap to verify. So when you have n distinct messages regardless of m, you only have to pay two parents to verify the aggregated signature and kind of roughly two m exponentials so that may or may not be something that's relevant for Layer 1 but it's still very exciting and something to keep in mind for Layer 2 or for light clients. It is a very recent paper, so, I guess, we need we need a bit more time to digest it. -In terms of quick updates for the deposit contract formal verification should end in maybe a couple weeks. So there's still one minor point regarding removing some of the safety checks and we should get the final okay on those within a couple weeks. There's also discussions about how we want to design the website to make the deposits so there is still significant work to be done before we want to deploy the deposit contract. +In terms of quick updates for the deposit contract formal verification should end in maybe a couple weeks. So there's still one minor point regarding removing some of the safety checks and we should get the final okay on those within a couple weeks. There's also discussions about how we want to design the website to make the deposits so there is still significant work to be done before we want to deploy the deposit contract. We want to do lots of testing to make sure that the UI is good and we also don't want to be in a situation where validators make deposits to early on and they have the funds in the deposit contract without being able to use them. So I guess there's also no significant rush to deploy, at least, until maybe we have some sort of public cross client testnet. @@ -168,122 +169,122 @@ SSZ is not really changing however, I am putting out some of the specs of the sp ## 4. [Network](https://youtu.be/DXGeC7cg71Y?t=2575) -**Danny:** +**Danny:** I have a [PR](https://github.com/ethereum/eth2.0-specs/pull/1440) out for a Naive Attestation Aggregation proposal in which validators locally aggregate with no necessary sophisticated strategy on subnets before attestations are passed to shared more global network. The bones are in place but we need to flesh it out so if those who have been thinking of networking problems could please have a look at this PR and give me some feedback. -### Felix update +### Felix update **fjl - Felix:** -We made some really good changes to the spec just this week so there is a lot more documentation about the topic in there. The Go and Rust implementations are now interoperable for the basic sort of EHT. I don’t know where the Python implementation is at right now. Too my knowledge Jannick is still working on the wire protocol. And since DevCon the Java team have been working on implementing the wire protocol into Java - I believe they are pretty far with it but I have yet to test it. +We made some really good changes to the spec just this week so there is a lot more documentation about the topic in there. The Go and Rust implementations are now interoperable for the basic sort of EHT. I don’t know where the Python implementation is at right now. Too my knowledge Jannick is still working on the wire protocol. And since DevCon the Java team have been working on implementing the wire protocol into Java - I believe they are pretty far with it but I have yet to test it. -There are two open problems right now in the protocol. These need to be solved before we can think about freezing the spec. One problem is the topic radius. Estimation is not all that well defined in the spec right now and that is because we don’t have a solution for this. I expect we will find a solution to this problem when we implement it for the second time. We have a solution for the radius estimation but the quote is horrible and is actually not clear if this is a workable solution and I don’t want to document this in the spec. I do think there is a simple and good way to do topic radius estimation but we don’t really have it yet. +There are two open problems right now in the protocol. These need to be solved before we can think about freezing the spec. One problem is the topic radius. Estimation is not all that well defined in the spec right now and that is because we don’t have a solution for this. I expect we will find a solution to this problem when we implement it for the second time. We have a solution for the radius estimation but the quote is horrible and is actually not clear if this is a workable solution and I don’t want to document this in the spec. I do think there is a simple and good way to do topic radius estimation but we don’t really have it yet. Another thing that came up during the audit which is almost complete. The audit was paused due to DevCon as I could not get any feedback on the initial report they created. I have however now given them the feedback and they should come back in the next few weeks with the final report and that will of course be published. -The biggest issue in the audit that LeastAuthority was trying to get through was that we should be adding some sort of Proof of Work system on node identities. It is something that I really did not want to do. I even put that in the [spec](https://github.com/ethereum/devp2p/pull/120). +The biggest issue in the audit that LeastAuthority was trying to get through was that we should be adding some sort of Proof of Work system on node identities. It is something that I really did not want to do. I even put that in the [spec](https://github.com/ethereum/devp2p/pull/120). -The proof of work on node identities is a pretty old idea. I think by now we have two options for it. We could use equihash or cuckoo cycle. I have been playing around with cuckoo cycle and integrating it into the protocol in code. I am not super happy with this change to be honest. What I would really like to have is some more solid feedback from other people who are more knowledgeable about proof of work or just in general. We need to make a decision whether we want proof of work in this protocol or not. That is the big question, should we do this in the first place and if yes then which parameters should we use, etc. So if you have any ideas on this topic at all then please provide feedback to the PoW [issue]( https://github.com/ethereum/devp2p/issues/122). +The proof of work on node identities is a pretty old idea. I think by now we have two options for it. We could use equihash or cuckoo cycle. I have been playing around with cuckoo cycle and integrating it into the protocol in code. I am not super happy with this change to be honest. What I would really like to have is some more solid feedback from other people who are more knowledgeable about proof of work or just in general. We need to make a decision whether we want proof of work in this protocol or not. That is the big question, should we do this in the first place and if yes then which parameters should we use, etc. So if you have any ideas on this topic at all then please provide feedback to the PoW [issue]( https://github.com/ethereum/devp2p/issues/122). -**Jacek Sieka:** +**Jacek Sieka:** On the proof of work topic I can briefly mention from Status’ side on of the biggest reasons we are abandoning whisper is that as a spam prevention mechanism it does not it does not quite work, simply because node power. The node doing the work honestly is almost always going to be underpowered and vulnerable to an attacker which makes it pretty much useless. **fjl - Felix:** -So it is a bit different with this type of thing because the issue with the proof of work or discovery or more general as this is not only for discovery, is, do we want to our nodes to add proof of work on our identities? What this prevents is attackers choosing their node identity in an arbitrary way because a lot of things in discovery but more in general a lot of P2P algorithms rely just on having the node ID space uniformly distributed and attackers can actually influence the distribution by choosing their node IDs. So if you add proof of work then the attacker would have to perform PoW many, many times. Where as a node that does not care about it’s ID and just has a random ID would need to perform the Proof of Work one time. So it is a bit different from the Whisper system where you have to put PoW on every single message. So in that case you do have to spend a significant amount of mining resources just computing PoW all the time. Where as node IDs setup is a one time PoW - it runs the first time you start the node and then probably never again. I do think PoW is not that bad in that context. In terms of Node IDs it is something we really need to decide on and make a good decision about it. +So it is a bit different with this type of thing because the issue with the proof of work or discovery or more general as this is not only for discovery, is, do we want to our nodes to add proof of work on our identities? What this prevents is attackers choosing their node identity in an arbitrary way because a lot of things in discovery but more in general a lot of P2P algorithms rely just on having the node ID space uniformly distributed and attackers can actually influence the distribution by choosing their node IDs. So if you add proof of work then the attacker would have to perform PoW many, many times. Where as a node that does not care about it’s ID and just has a random ID would need to perform the Proof of Work one time. So it is a bit different from the Whisper system where you have to put PoW on every single message. So in that case you do have to spend a significant amount of mining resources just computing PoW all the time. Where as node IDs setup is a one time PoW - it runs the first time you start the node and then probably never again. I do think PoW is not that bad in that context. In terms of Node IDs it is something we really need to decide on and make a good decision about it. -**Mikhail Kalinin:** Do you have a list of scenarios for the interop process like you did with Rust? +**Mikhail Kalinin:** Do you have a list of scenarios for the interop process like you did with Rust? **fjl - Felix:** -No, so basically what we did was we just ran the clients against each other and then H basically did all of the work which meant mainly checking in his code where things went wrong and that led to a couple of corrections to the spec, like a couple corrections on the go and so it was liek an interactive bugging more or less. So you could just run the implementation and send a ping message and then see if you can get a response. If you do get a response then you can see if you can encrypt it. But am pretty certain that both Rust and Go are now compliant with the spec so if you want to try either implementation and it works with yours then we are good basically. +No, so basically what we did was we just ran the clients against each other and then H basically did all of the work which meant mainly checking in his code where things went wrong and that led to a couple of corrections to the spec, like a couple corrections on the go and so it was liek an interactive bugging more or less. So you could just run the implementation and send a ping message and then see if you can get a response. If you do get a response then you can see if you can encrypt it. But am pretty certain that both Rust and Go are now compliant with the spec so if you want to try either implementation and it works with yours then we are good basically. -### Whiteblock update +### Whiteblock update **Trenton van Epps:** -We have released our [repo](https://github.com/whiteblock/gossipsub-testing) for our testing methodologies for what we are doing for LibP2P. So we are laying out basically what we are going to do. The specific methods and just some metric that we hope to collect. Please join the [discussion](https://community.whiteblock.io/t/gossipsub-tests/17). We would love to have more people so if you have any thoughts or would like to see how we are doing things then please join us in the discussion. +We have released our [repo](https://github.com/whiteblock/gossipsub-testing) for our testing methodologies for what we are doing for LibP2P. So we are laying out basically what we are going to do. The specific methods and just some metric that we hope to collect. Please join the [discussion](https://community.whiteblock.io/t/gossipsub-tests/17). We would love to have more people so if you have any thoughts or would like to see how we are doing things then please join us in the discussion. -**Antoine Toulme:** +**Antoine Toulme:** -We have some data already that we will be sharing. +We have some data already that we will be sharing. -Nimbus team would it be possible to get access to the organisation github and the script as well? +Nimbus team would it be possible to get access to the organisation github and the script as well? **Mamy:** Yes. Of course. ## 4. [Testnet Discussion](https://youtu.be/DXGeC7cg71Y?t=3229) -**Danny:** +**Danny:** -There is a lot here especially around when the various testnets happen. One of the big things is the Phase 0 update and the pending v0.9 which will include this modification to the state transition function. It is almost entirely simplifying in that it is cutting a few things out and I think Terence has he said has gone through it. I did have some conversations with different teams and it seemed like in general consensus was to get these changes out of the spec, get them integrated into clients before we do some larger more orchestrated multiclient testnets. It also seems that whilst most teams have the Eth1 and Eth2 machinery that most teams were ironing out deposit contract following Eth1 data voting etc. and doing some more single client testnet stuff. Both larger private testnets and some teams were planning on spinning up some public testnets or semi-public testnets where most of the nodes were controlled by the client team. Although these testnets may be dominated by a single client they might do some multi-client testing. So there is still plenty of work to do with regards to single clients doing testing before moving forward to multi-client testnets while we get these Phase 0 changes integrated. +There is a lot here especially around when the various testnets happen. One of the big things is the Phase 0 update and the pending v0.9 which will include this modification to the state transition function. It is almost entirely simplifying in that it is cutting a few things out and I think Terence has he said has gone through it. I did have some conversations with different teams and it seemed like in general consensus was to get these changes out of the spec, get them integrated into clients before we do some larger more orchestrated multiclient testnets. It also seems that whilst most teams have the Eth1 and Eth2 machinery that most teams were ironing out deposit contract following Eth1 data voting etc. and doing some more single client testnet stuff. Both larger private testnets and some teams were planning on spinning up some public testnets or semi-public testnets where most of the nodes were controlled by the client team. Although these testnets may be dominated by a single client they might do some multi-client testing. So there is still plenty of work to do with regards to single clients doing testing before moving forward to multi-client testnets while we get these Phase 0 changes integrated. -**Antoine Toulme:** +**Antoine Toulme:** -We would love to run some of that either as ourselves or in conjunction with any clients. We have an easy way to spin up a bunch of instances. What is the timeline? Do we want to use Goerli like Prysm does? Is there one deposit contract or multiple? Do we have an incerling on that? +We would love to run some of that either as ourselves or in conjunction with any clients. We have an easy way to spin up a bunch of instances. What is the timeline? Do we want to use Goerli like Prysm does? Is there one deposit contract or multiple? Do we have an incerling on that? -**Greg Markou:** +**Greg Markou:** I can get us lots of ETH for Goerli by the way. -**Justin Drake:** +**Justin Drake:** In terms of getting ETH for the testnets. One suggestion is to make the deposit amounts 32 milli-ETH as opposed to 32 ETH and that would make it very easy to get ETH. -**Greg Markou:** +**Greg Markou:** -We have millions though because we are the faucet. +We have millions though because we are the faucet. -**Justin Drake:** +**Justin Drake:** -Excellent. +Excellent. -**Antoine Toulme:** +**Antoine Toulme:** -There were in the past some funny issues there like putting in different amounts that resulted in issues, there is enough finicky stuff in the client that can result in issues last time we ran this in June. So if we can just skip that. It is not that interesting to test the security functionality at this point as I feel it will just waste a little bit of time. If we can go straight to then I am good with that. +There were in the past some funny issues there like putting in different amounts that resulted in issues, there is enough finicky stuff in the client that can result in issues last time we ran this in June. So if we can just skip that. It is not that interesting to test the security functionality at this point as I feel it will just waste a little bit of time. If we can go straight to then I am good with that. -The Prysm contract - Terence should speak about that - has a clause in that where you can drain amounts back to the original sender. So it is not like you are losing ETH. +The Prysm contract - Terence should speak about that - has a clause in that where you can drain amounts back to the original sender. So it is not like you are losing ETH. -**Danny:** +**Danny:** To the question of it is one deposit contract or multiple. It is essentially one per testnet that is connected to an Eth1 chain. -There was also discussion about spinning up proof of authority testnets. I think that just connecting to Goerli is probably simpler than doing that. But it is definitely something that we could consider, especially when we move towards Public testnets or incentivized testnets so proof of authority testnets may work better because we can better allocate the ETH that can participate but that is a little bit further down the line. +There was also discussion about spinning up proof of authority testnets. I think that just connecting to Goerli is probably simpler than doing that. But it is definitely something that we could consider, especially when we move towards Public testnets or incentivized testnets so proof of authority testnets may work better because we can better allocate the ETH that can participate but that is a little bit further down the line. -**Zahary:** +**Zahary:** -One idea that I would like to share is, we are planning to do our testnets in the following way. We are going to just the validators from the mock start to kickstart the network immediately. And the very first block we will reference some current block on Goerli so the validator contract could be used to add additional validators when the network is already running - that is you don’t need to wait for everybody to leave a deposit to become a validator. We can probably publish some sort of common line parameters similar to the mock start. If the other clients are interested as well then I think this could simplify the initial cross client testing. +One idea that I would like to share is, we are planning to do our testnets in the following way. We are going to just the validators from the mock start to kickstart the network immediately. And the very first block we will reference some current block on Goerli so the validator contract could be used to add additional validators when the network is already running - that is you don’t need to wait for everybody to leave a deposit to become a validator. We can probably publish some sort of common line parameters similar to the mock start. If the other clients are interested as well then I think this could simplify the initial cross client testing. -**Danny:** +**Danny:** -Yes, that does sound like a good idea. If you can share your notes then we can put something together like the mock start for interop. +Yes, that does sound like a good idea. If you can share your notes then we can put something together like the mock start for interop. -**Terence (Prysmatic):** +**Terence (Prysmatic):** -There are a few more things to discuss around the config. So for us we actually ended up increasing the injection balance just because we wanted to test when one of our validators gets ejected. And second thing we are seeing is there is that some people left the client running for too long or that people go offline for too long and then setting the threshold has half is a little too low and then it starts to hurt our finality. So that is one config that we had to change. +There are a few more things to discuss around the config. So for us we actually ended up increasing the injection balance just because we wanted to test when one of our validators gets ejected. And second thing we are seeing is there is that some people left the client running for too long or that people go offline for too long and then setting the threshold has half is a little too low and then it starts to hurt our finality. So that is one config that we had to change. -And the second config we had to change Eth1 follow distance. We set it from 1024 to 16 because we don’t want people to wait to long to be activated. +And the second config we had to change Eth1 follow distance. We set it from 1024 to 16 because we don’t want people to wait to long to be activated. -**Danny:** +**Danny:** Maybe it is worth modifying the minimal config to have in a couple of those changes or to add a new one just called minimal testnet or something? So that we can use the shared dev. -**Paiul Hauner:** +**Paiul Hauner:** I think we should probably decide on how we are going to structure the fork for these testnets just so that we as we get closer to genesis we don’t have that situation where people use their testnet keys on mainnet and get slashed. -**Danny:** +**Danny:** So are you suggesting that we start with a fork version that is way out of the domain? -**Paiul Hauner:** +**Paiul Hauner:** -Yeah, it is probably very unlikely but it seemed like a good idea. So maybe we start on the right most bit for big indians and then the left most bit or something? And so get well out of the way of range of the forks we expect to use. +Yeah, it is probably very unlikely but it seemed like a good idea. So maybe we start on the right most bit for big indians and then the left most bit or something? And so get well out of the way of range of the forks we expect to use. -**Danny:** +**Danny:** Yeah, that is a good call. @@ -293,23 +294,23 @@ I don’t think that value is in the config? I think we are just using the defau I think so, we put it in our spec but I cannot remember if it is in the main spec of not. -**Danny:** +**Danny:** -Yeah, I think it would be worth putting it in our config just to ensure we have it as a parameter. +Yeah, I think it would be worth putting it in our config just to ensure we have it as a parameter. **Antoine Toulme:** -There are a couple more things here. It is not really enough to just get the nodes going but we need to monitor and make sure everything is running ok. I know that Zahary mentioned that you can run for ref for testnet for the node that they run. For ourselves if we are given permission with respect to monitoring we that be enough or is there a specific tooling that we should develop to help monitor the testnets? +There are a couple more things here. It is not really enough to just get the nodes going but we need to monitor and make sure everything is running ok. I know that Zahary mentioned that you can run for ref for testnet for the node that they run. For ourselves if we are given permission with respect to monitoring we that be enough or is there a specific tooling that we should develop to help monitor the testnets? -**Zahary:** +**Zahary:** -Our node setup is based on the Prometheus spec that was published. +Our node setup is based on the Prometheus spec that was published. **Antoine Toulme:** Is that going to be enough or do we need to do a bit more? -**Danny:** +**Danny:** So that just allows you to monitor singular nodes Zahary is that correct or is that mulitple nodes to a single place? @@ -317,51 +318,51 @@ So that just allows you to monitor singular nodes Zahary is that correct or is t No, you can do as many as you like. -**Zahary:** +**Zahary:** + +We have some custom setup as we don’t want to expose this Prometheus for the internet so for our own environment we have a custom setup to gather and aggregate all the data in a single place. -We have some custom setup as we don’t want to expose this Prometheus for the internet so for our own environment we have a custom setup to gather and aggregate all the data in a single place. - **Antoine Toulme:** I think this is simple enough for everyone to implement on their own. -**Danny:** +**Danny:** I think that is a good start. There is a push on Protocol Labs side, they are doing some more rigorous gossipsub and pubsub monitoring tools - I don’t know the timeline on that though. -**Jacek Sieka:** +**Jacek Sieka:** -In terms of general tooling one thing I would like to mention we are building a few monitoring applications, like a gossipsub sniffer and few of these things. I expect in time there will be a community that step up around block explorers and things like that. We will also have similar things but say on the web. +In terms of general tooling one thing I would like to mention we are building a few monitoring applications, like a gossipsub sniffer and few of these things. I expect in time there will be a community that step up around block explorers and things like that. We will also have similar things but say on the web. -**Danny:** +**Danny:** -There was some nascent interest many months ago on Block Explorers. I can knock on some doors and see that going again. +There was some nascent interest many months ago on Block Explorers. I can knock on some doors and see that going again. **Antoine Toulme:** Yeah, that is what I mean. -I also know that Prysm had a good setup with Spinnaker cause they were able to do canary deployment testing and all that good stuff. So we spun up the spinnakers as well. We could organise around that as well. Is that something people would be interested in? +I also know that Prysm had a good setup with Spinnaker cause they were able to do canary deployment testing and all that good stuff. So we spun up the spinnakers as well. We could organise around that as well. Is that something people would be interested in? -**Danny:** +**Danny:** What is a spinnaker? **Antoine Toulme:** -Spinnaker is an SSZ pipeline integration that takes a new build, has a workflow for that build. For example you can test it in isolation in 3 or 6 nodes. Look at the stats, look at the results to see if it is good, to see if it passing the tests. It is also going to make it possible to replace the testnet nodes with the new version in an automatic failover manner without downtime. +Spinnaker is an SSZ pipeline integration that takes a new build, has a workflow for that build. For example you can test it in isolation in 3 or 6 nodes. Look at the stats, look at the results to see if it is good, to see if it passing the tests. It is also going to make it possible to replace the testnet nodes with the new version in an automatic failover manner without downtime. If we had six nodes per client then spinnaker works for each of them, every time we push a new doc it would be picked up by them. Test in isolation making sure it is working, etc. Once you have the green light from programs it can transit into the testnet and then it automates the pipeline and it becomes much easier to manage it over time. -**Jacek Sieka:** +**Jacek Sieka:** -One of the concerns I would raise with these tools is that they are very centered on a very centralised approach to managing nodes and is good for cloud and software as a service. But that is not quite we are trying to do here. +One of the concerns I would raise with these tools is that they are very centered on a very centralised approach to managing nodes and is good for cloud and software as a service. But that is not quite we are trying to do here. **Antoine Toulme:** Hang on, one it does not have to be the same testnet. Even if it is the same testnet it does not have to be the majority of the testnet. I could just be a client decides to do it that way. It should not be the end and all of the testnet. If you happen to be using the same contract and you are running independently you should not be at all penalised or have to interact with spinnaker at all. It may just be a way clients do choose to deploy and run their nodes. Make sense? -**Jacek Sieka:** +**Jacek Sieka:** So long as we are aware that not all clients will use these systems. We should have that use can in mind as well. @@ -371,21 +372,21 @@ I think you need both. I think if you want to painless approach to deploy things By the way I am not inventing anything it is just what Prysm is using today. -**Terence (Prysmatic):** +**Terence (Prysmatic):** I think for us it is just about creating the testnet quality. We don’t want PRs going in and breaking the testnet. So our workflow is more like when our PR is linked to master and then a new image is cut so then the image deploys to the cluster then we will direct 10% of the traffic to that image. Then we have 3 hours of measuring report to compare the baseline between the new image and the old image and then we will do some analysis. And then if that passes we can direct more and more traffic to that new image. -**Danny:** +**Danny:** So this is primarily on testnets where you control the majority of the nodes? Is that correct? -**Terence (Prysmatic):** +**Terence (Prysmatic):** For us - yes. Can we talk about aggregation strategy for multi-client testnets? I think for each individual client testnet it does not matter as each client can use their own strategy but for multi-client testnet would people be interested to implement the naive aggregation strategy mentioned in the [PR](https://github.com/ethereum/eth2.0-specs/pull/1440)? -**Danny:** +**Danny:** Once we have any significant load on the testnet we are going to need an aggregation strategy. If you have a single channel where everything is gossiped you don’t strictly need an explicit strategy other than aggregate locally and include in blocks. But I think the intent is to get some version of this naive strategy integrated. And when multi-client testnets come around I think we should move towards that. @@ -397,26 +398,26 @@ So we need to get that PR merged soon and tested and onto these testnets. To tha **Danny:** There is the Phase 0 changes, which will help facilitate this new Phase 1 proposal. Any questions on that or spec in general? -Great. +Great. ### 6. [Open Discussion and Closing Comments](https://youtu.be/DXGeC7cg71Y?t=4519) None. -## Attendees: +## Attendees: - Alex Stokes -- Antoine Toulme +- Antoine Toulme - Ben Edgington - Brent Allsop - Carl - Cayman - Chih-Cheong Lia -- Danno Ferrin +- Danno Ferrin - Danny Ryan - Dankrad - Greg Markou -- Felix +- Felix - Hsiao-Wei Wang - Jacek Sieka - Jannik Luhn @@ -441,7 +442,7 @@ None. - Shahan Khatch - Terence (Prysmatic) - Tomasz Stanczak -- Trent Van Epps +- Trent Van Epps - Vitalik Buterin - Wei Tang - Zahary diff --git a/eth2.0-implementers-calls/call_027.md b/eth2.0-implementers-calls/call_027.md index 58100d3..eae5c68 100644 --- a/eth2.0-implementers-calls/call_027.md +++ b/eth2.0-implementers-calls/call_027.md @@ -1,6 +1,4 @@ -# Ethereum 2.0 Implementers Call #27 - - +# Ethereum 2.0 Implementers Call 27 Notes ### Meeting Date/Time: Thursday, November 7 at 1400 UTC ### Meeting Duration: 38 minutes @@ -9,6 +7,7 @@ ### Moderator: Daniel Ellison ### Notes: Jim Bennett +--- # 1. [Testnet and Release Updates](https://youtu.be/4_EGNG-Yek4?t=264) diff --git a/eth2.0-implementers-calls/call_028.md b/eth2.0-implementers-calls/call_028.md index 26742ec..32f78a1 100644 --- a/eth2.0-implementers-calls/call_028.md +++ b/eth2.0-implementers-calls/call_028.md @@ -1,22 +1,21 @@ # Ethereum 2.0 Implementers Call 28 Notes - ### Meeting Date/Time: Thursday 2019/11/21 at 14:00 GMT +### Meeting Date/Time: Thursday 2019/11/21 at 14:00 GMT +### Meeting Duration: ~ 1 hr 20 mins +### [GitHub Agenda Page](https://github.com/ethereum/eth2.0-pm/issues/101) +### [Audio/Video of the meeting](https://www.youtube.com/watch?v=DzLrxuN55VA) +### Moderator: Danny Ryan +### Notes: Pooja Ranjan - ### Meeting Duration: ~ 1 hr 20 mins - ### [GitHub Agenda Page](https://github.com/ethereum/eth2.0-pm/issues/101) - ### [Audio/Video of the meeting](https://www.youtube.com/watch?v=DzLrxuN55VA) +---------- - #### Moderator: Danny Ryan - #### Notes: Pooja Ranjan - ---------- - - **Danny**: Welcome everyone! + **Danny**: Welcome everyone! ## 1. Testing and Release Updates - + **Danny**: Testing generally stable, Mehdi will add more. - As for release, I do have a pending release on GitHub with some minor clarifications in changes, specifically clarify some things. It might change one test vector, will let you know. Other than that everything is good. - + As for release, I do have a pending release on GitHub with some minor clarifications in changes, specifically clarify some things. It might change one test vector, will let you know. Other than that everything is good. + **Mehdi** : Hi everyone! * Some of you may have seen danny's update. Sigma Prime has been awarded grant from the Ethereum Foundation to do work on Beacon fuzzer and differential fuzzer. * Will be ramping up our efforts on Beacon fuzz from next week, allocating more time and resources. @@ -30,7 +29,7 @@ * Reached out to Nimbus as well. Trying to see how we could prosthetic C-library that we can simply link to our differential fuzzers. * We started integrating Trinity, which should be very straight forward. * We started working on Prysm thinking that having zrnt up and running will be trivial, but turned out quite the opposite. It is not as simple as expected. - + **Next steps:** * finalize all the epoch state transition, should be done next week * will also bump all the current fuzzers to the latest version of the spec @@ -41,13 +40,13 @@ I know there is a desire and even a need for **fork choice tests**, that's been on a back runner for us for a while and we need to prioritize it. I'll try to get some notes for review up on that within the next week. The good thing is some of these corner cases and things we've integrated into the spec recently are those, and not expected to be seen especially on those test nests and even primarily not even seen on mainnet. - + ## 2. Client Updates - - ### Prysm - + + ### Prysm + **Terence**: - + * Relaunched testnet with v0.9 last week. There has been lot of public interest. * 55 peers right now , only 10 are of ours * with that comes a lot of questions, support and great feedback on the community @@ -55,7 +54,7 @@ The good thing is some of these corner cases and things we've integrated into th * lot of bug fixes on RPC back-end * On the side, working on aggregator, because previously every validator aggregate and then broadcast the attestation. So,we are switching to these aggregators. * making SSD performance improvement -* ramping the Eth1 data implementation logic +* ramping the Eth1 data implementation logic * resume finishing fully end to end test from depositing a deposit contract, submitting the deposit transaction and finalizing epoch. **Danny**: Thank you Terence! @@ -67,7 +66,7 @@ The current testnet does not use aggregation, is that what you said? **Terence**: Not yet, it should be the same as minimum config. with an exception. -**Danny**: Okay. When you get chance, just drop in there. Just us getting in the habit of documenting these nets. so that we can begin to small experimentation, will be good. +**Danny**: Okay. When you get chance, just drop in there. Just us getting in the habit of documenting these nets. so that we can begin to small experimentation, will be good. **Terence**: Sure. @@ -78,8 +77,8 @@ The current testnet does not use aggregation, is that what you said? * v 0.9.1 merged, pretty good. * working on a hot/cold database * implemented validator on-boarding flow -* we have a test not running running in the cloud with orchestration and monitoring. We're just not quite ready to push it to the public yet because we want to change the documentation and aim to get hot/col database in there before we make it public. Just so we're not filling up people's machine. -* working on refactoring the validator clients. We're putting in some new slashing protection stuff +* we have a test not running running in the cloud with orchestration and monitoring. We're just not quite ready to push it to the public yet because we want to change the documentation and aim to get hot/col database in there before we make it public. Just so we're not filling up people's machine. +* working on refactoring the validator clients. We're putting in some new slashing protection stuff * doing aggregation in the validator clients. It should make it your beacon node to handle large numbers. * Working with Herumi on fast BLS implementation, but will still maintain our owns. Herumi is fast and extremly impressive. * On the networking side, we've stated working on noise handshaking on P2P. We've added sybil resistance to the DHT @@ -89,7 +88,7 @@ The current testnet does not use aggregation, is that what you said? **Adrain**: On the disc v 5, there was a few suggestions, essentially we limit IP addresses in /24 subnets. In a particular bucket, I think we only allow two /24 subnet on the entire /24 subnet. In entire DHT limit the number of IPs on a /24 subnet. -**FJL**: Oh okay, thank you. +**FJL**: Oh okay, thank you. **Danny**: Thank you Paul. @@ -98,7 +97,7 @@ The current testnet does not use aggregation, is that what you said? **Marin** * we implemented Carls apes in JavaScript and we are currently testing it across the environments and we'll release it soon. -* made huge progress in disc v 5 in JavaScript and +* made huge progress in disc v 5 in JavaScript and * our 0.9 spec is pretty much done. We're just waiting on the next release of JS Lib P2P ### Nimbus @@ -108,15 +107,15 @@ The current testnet does not use aggregation, is that what you said? * weekly testnet setup in place. We reboot the testnet set up every Tuesday morning and it's stable for a week * We've a separate developer branch and we merge everything on Monday. You can use that as a stable branch in comparison to Nimbus. * spec- now compatible with 0.9.1 and waiting for 0.9.2 and verified that we've the same Genesis as 0.9.1 and so that would be deployed on the testnet next Tuesday -* complex sync issue being debug, +* complex sync issue being debug, * working on data logs. Going through all the logs are quite stressing for set up and even for us -* crypto and BLS - I did some benchmark on the new BLS on the Raspberry pi, it was 21 ms for pairing. +* crypto and BLS - I did some benchmark on the new BLS on the Raspberry pi, it was 21 ms for pairing. -**Next to do** +**Next to do** * working with Sigma Prime on Beacon fuzz * on networking front on disc v 5 -Side note on Eth1 - At Nimbus Eth 1, we finished Istanbul hardfork implementation. +Side note on Eth1 - At Nimbus Eth 1, we finished Istanbul hardfork implementation. **Danny**: Are those testnet that you're rebooting is something that public can join? @@ -145,9 +144,9 @@ One mor thing, while we pass the minimal test, we still have some issue with ver **Alex** -* working on spec update and performance +* working on spec update and performance * ver 0.9.0 and 0.9.1 updates are mostly altogether -* some refactoring we have to do on the fork choice that's blocking being fully up-to-date there. We're passing all of the fixture the spec test that +* some refactoring we have to do on the fork choice that's blocking being fully up-to-date there. We're passing all of the fixture the spec test that * updates to pilot Pylibp2p stability * we merged in our Eth 1 monitor * some great performance work on PySSZ, which had been bottleneck for us @@ -159,7 +158,7 @@ One mor thing, while we pass the minimal test, we still have some issue with ver **Joseph** -* split in 2 teams - +* split in 2 teams - (a) **Advanced Research** which combining with Harmony and would be working on the Shard clients (b) **Artemis production readiness** team are making changes and implementing sync right now. Shahan will give update on that. @@ -168,22 +167,22 @@ One mor thing, while we pass the minimal test, we still have some issue with ver * finalizing the naive aggregation stuff the will take a look at 0.9.1 right after * done all the request response methods done to at least basic functionality * we are finalizing a review -* starting a round of interop testing with other clients -* starting to investigate block sync approach, specially Prysmatic +* starting a round of interop testing with other clients +* starting to investigate block sync approach, specially Prysmatic * also working on disc v 5 focused on the interop side of that **Danny**: Great, thanks! Meredith, I saw your question in the chat on it is a function of the size of the validator that I don't know if that is explicitly written down anywhere, but we can. This is **Weak subjectivity period** and it's dynamic. Foe many use cases of the weak subjectivity period, we would instead just rely upon some sort of upper bound rather than using even if it drops lower for the safety and health of network. It's just much simpler to err on the side of conservative on it but I will drop some more notes on that after this call. -**Meridth**: Awesome, thanks. +**Meridth**: Awesome, thanks. ### Harmony **Mikhail** * There is a little progress being done on the gossip sub simulation. This simulator now being able to handle 100,000 of nodes and disseminate a message within there in the same amount of time. -* Further steps are to add the mesh topology and add metrics like bandwidth and so forth to this piece of software +* Further steps are to add the mesh topology and add metrics like bandwidth and so forth to this piece of software * next we did a partial update of all the spec of 0.9.0 and this is within our work on the fork choice tests. we are about to finish this fork choice test for our code base * We probably can use our code to generate some basic test vectors. * also there is a work near to be finished with disc v 5. It's now been testing with the Geth . @@ -192,23 +191,23 @@ This is **Weak subjectivity period** and it's dynamic. Foe many use cases of the * next couple of week will be productive **Danny**: Great, thanks! - + ## 3. Research Updates - - -**Vitalik**: - + + +**Vitalik**: + * **On protocol side** phase 1, we've done some edits phase 1 spec. Proto has been doing some work on kind of plugging into all of the testing machinery. * Not too many changes, fairly small tweaks -* One thing that we talked about is blocks containing multiple chunks vs the ability to have created multiple blocks +* One thing that we talked about is blocks containing multiple chunks vs the ability to have created multiple blocks * The idea is to just collapse the two dimensional array into one. That is simpler in some ways but it's also more complex and less efficient in other ways. * I feel like there might be an opportunity to conceptually simplify things quite a bit otherwise the main thing that could be added on is one fraud proofs and the other group of incorrect groups of custody bits which aren't too difficult because it's only a single round game. But there's still wants of economic insight and incentive nuances there to think about. * I've been getting the feeling from the conversations with other people in these two groups that make people believe more and more that data availability of proofs actually or something important and are not just a kind of optional extras to throw on and to throw on at some point.People are actually afraid of the possibility that committees will break them. May be the skin break can cause the entire chain to finalize something invalid. -* Phase 1 has been designed from the start with phase 2 and or with the data availability proofs in mind. The main reason why blocks have multiple chunks instead of one root is so that it'd makes it easier to and if combined all of those pieces together into a single big root. But then after that there's the question of what specific date availability scheme do we use? The two realistic alternatives either -* something fraud proof based or +* Phase 1 has been designed from the start with phase 2 and or with the data availability proofs in mind. The main reason why blocks have multiple chunks instead of one root is so that it'd makes it easier to and if combined all of those pieces together into a single big root. But then after that there's the question of what specific date availability scheme do we use? The two realistic alternatives either +* something fraud proof based or * something STARK based -There was a version of something fraud proof based that I coded up like almost a year ago and it would need to be updated. +There was a version of something fraud proof based that I coded up like almost a year ago and it would need to be updated. The STARK based one is protocol wise conceptually simpler except there's this one kind of very self-contained much more complex piece which is actually proving and verifying the STARK. But the main challenge there is we need to just make sure we have a decent Stark friendly hash function. @@ -217,8 +216,8 @@ The STARK based one is protocol wise conceptually simpler except there's this on **Next steps**: -* prototype this STARK based stuff and see how viable it is in bps sense. -* Otherwise there is this option of just figuring out how to swats things. +* prototype this STARK based stuff and see how viable it is in bps sense. +* Otherwise there is this option of just figuring out how to swats things. Those are the protocol level things from my side. My own time, I've been spending on some application layer questions. @@ -229,9 +228,9 @@ Those STARK friendly hash functions have not yet been vetted by the community of **Chat question**: Any news from the IETF forum on BLS standardization? -**Carl**: +**Carl**: -**Hash-to-curve** idea was [presented](https://youtu.be/dMFgaeRdsfU?t=1009) at IETF meeting, yesterday. It was mostly update or for those people explaining the changes that have gone in the last meetings, then some questions around where to go from here. All looks very good, no one raised any issue which was precondition on making this a blockchain standard. +**Hash-to-curve** idea was [presented](https://youtu.be/dMFgaeRdsfU?t=1009) at IETF meeting, yesterday. It was mostly update or for those people explaining the changes that have gone in the last meetings, then some questions around where to go from here. All looks very good, no one raised any issue which was precondition on making this a blockchain standard. In terms of the hash to curve, the next thing happening is the proof of concept which is to be the master for most implementation that's being used to generate the test vectors which were removed, making sure all the canonical implementation of hash to curve are good. It should happen in the next two week or so. It will be moved to last call from the status on the an IETF standpoint. It would be submitted for input on the cryptography. @@ -239,7 +238,7 @@ In terms of the hash to curve, the next thing happening is the proof of concept **Carl**: That is much longer, in my view, it is six months or something. -With the reservation that nothing being said we haven't had proper discussions about this since the IETF meeting. We don't have a formal written agreement surface is a standard. I'm reasonably happy to declare those to be the BLS standards going forward and don't really expect anything to change there. +With the reservation that nothing being said we haven't had proper discussions about this since the IETF meeting. We don't have a formal written agreement surface is a standard. I'm reasonably happy to declare those to be the BLS standards going forward and don't really expect anything to change there. I think for most cases it's fair to say that BLS thing is not really holding us back. Only after next internal meeting which is happening in two weeks from now. For now basically think of it as a standard. @@ -256,7 +255,7 @@ I think for most cases it's fair to say that BLS thing is not really holding us **Justin Drake**: I've few updates - -**Relevant for phase 0**. +**Relevant for phase 0**. * The EF is looking for someone to manage the validators that we're going to run. We are looking for someone with Dev Ops skill, operational skills, security skills to help set up the high uptime, high security set up, potentially multi-client, multi-cloud. Essentially, been using the threshold BLS signature and provide all this infrastructure as open source. Potentially being complimentary to institutional, great infrastructure that Coinbase might provide. If you know anyone who might fit the bill, please send me a message. @@ -266,7 +265,7 @@ I think for most cases it's fair to say that BLS thing is not really holding us **Relevant for phase 1** -Spending time on zero knowledge proof. one of the cool things that Dan Boneh came up with a really neat, a secretly election mechanism and he wrote a paper and his paper got accepted, so it will be published very soon. It turns out that the circuit is very simple. You could do it either with ZK proof or fault proof. It is very similar to data availability situation. Of course if we can do it with zk proof, it's cleaner and it turns out in this specific instance, its potentially very doable. +Spending time on zero knowledge proof. one of the cool things that Dan Boneh came up with a really neat, a secretly election mechanism and he wrote a paper and his paper got accepted, so it will be published very soon. It turns out that the circuit is very simple. You could do it either with ZK proof or fault proof. It is very similar to data availability situation. Of course if we can do it with zk proof, it's cleaner and it turns out in this specific instance, its potentially very doable. **Relevant to Phase 2** @@ -308,7 +307,7 @@ One of the hash function available is The Pederson hash which is provably secure **Mamy**: If we can find the contract, the original one in assembly script, we can just replicate it in name, see that we generate something executable that is almost the same. This way it would be like Vyper in terms of interface that we can use for Phase 2 for testing. -**Will**: Awesome! Lets do that. I'll share with you as we get this working and then we should try to write one as well. +**Will**: Awesome! Lets do that. I'll share with you as we get this working and then we should try to write one as well. **Mamy**: Cool! @@ -318,21 +317,21 @@ One of the hash function available is The Pederson hash which is provably secure There's Eth1.x, there is **research call**, they are primarily organizing on Eth research forum. It is to push forward some of the research on the existing chain with a focus on getting one improving theorem today and also staging Ethereum for future upgrade of moving Ethereum to Eth 2, more towards stateless model and other things. So check that out. Like I said, they are organizing a lot on Eth research forum. -In addition to that we are going to start at least monthly **networking call** where a member or two from each team I hope that as been focused primarily on networking, we're going to get together to enumerate the problem more explicitly and work on driving that effort a little bit to sleep. I'm going to lead that call to start but certainly I'm open to not leading that call depending upon who steps up and is available. +In addition to that we are going to start at least monthly **networking call** where a member or two from each team I hope that as been focused primarily on networking, we're going to get together to enumerate the problem more explicitly and work on driving that effort a little bit to sleep. I'm going to lead that call to start but certainly I'm open to not leading that call depending upon who steps up and is available. -I will drop an agenda item on Eth 2 PM repo, an issue that we'll set up this call. It might be next week, if not it will certainly be the following. +I will drop an agenda item on Eth 2 PM repo, an issue that we'll set up this call. It might be next week, if not it will certainly be the following. -Any questions or thought on that particular item? Don't want to introduce an incredible amount of coordination overhead for adding all these calls. They are experiments and if they are valuable, will continue doing. +Any questions or thought on that particular item? Don't want to introduce an incredible amount of coordination overhead for adding all these calls. They are experiments and if they are valuable, will continue doing. **Danny**: One more call **[Light Client task force](https://github.com/ChainSafe/lodestar/issues/555)**. Another call coming up, first week December, Wednesday. As Eth 2 progresses, these two covers an increasingly large domain. Hopefully these domain specific calls, we can rally the effort. - + ## 4. Networking - - **FJL**: No much updates. + + **FJL**: No much updates. * One thing that might be of interest to the historic team that we just Just converted Geth code base to use Go-modules. I am looking to include Disc v 5 code on Geth master branch asap. I think that's going to be a big help to anyone using Go. * Not directly related to Eth2 but might be interesting to Eth 2 in future. Since the Istanbul HF is coming up in the Eth 1 chain. Everyone is upgrading their nodes which means that all of a sudden have a lot more capable Eth 1 nodes around. And we want to leverage that by running a DHT crawler that collects all of these. We've this infrastructure to base your break so you can actually set up. Then we will have something to announce there right after the fork process. I think this is going to be a pretty good test run of DNS infrastructure. I think it's probably going to be really nice for Eth 2 as well once it launches. @@ -343,50 +342,50 @@ As Eth 2 progresses, these two covers an increasingly large domain. Hopefully th * it seems like working without my involvement but would be nice to have more involvement * at the same time, there are research challenges left for this protocol and I will be happy to have get more help on that. * happy to have calls about it - + **Danny**: Thank you, Felix. Networking experts, provide feedback and input and like I said, we've a networking call coming up and we more explicitly rally around some of these problems. other networking updates? - + On Harmony simulations, when you all are expecting to publish some results on that? - - **Mikhail**: I think the basic results should be published by the end of next week. We're just going to publish these basic simulator stuff, get feedback. Proto is willing to the creation simulation. - + + **Mikhail**: I think the basic results should be published by the end of next week. We're just going to publish these basic simulator stuff, get feedback. Proto is willing to the creation simulation. + **Danny**: Cool! - - + + ## 5. Spec discussion - + **Danny**: Proto dropped [issues with and options for signing root](https://github.com/ethereum/eth2.0-specs/issues/1487), discussing pain points in disparity between hash tree root and signing root. - + **Proto**: * signing root is kind of pain, outlined this in detail in the [issue](https://github.com/ethereum/eth2.0-specs/issues/1487). Collect more feedback on the proposal to remove signing roots. Alternatively there are other workaround but they aren't pretty and don't cover all issues. * With more feedback, I'll put together a PR describing the changes and by the next call, I'll like to make a decision as a group of implementers. **Raul**: Signing root can be a little bit confusing to someone not familiar. I agree that it's worth revisiting. There's a lot that can be done to explore alternatives. I like Proto's alternative of having a sign block container and regular block container. -**Mamy**: Actually there is something that we wanted to do in Nimbus. one suspect stabilizes because we have issues on the test suit. We need some kind of workaround on that. I guess having a sign type and something separate will be much easier. +**Mamy**: Actually there is something that we wanted to do in Nimbus. one suspect stabilizes because we have issues on the test suit. We need some kind of workaround on that. I guess having a sign type and something separate will be much easier. **Mikhail , Shahan**: +1 for signed block container -**Proto**: There is something to n/w as well. There are considerations for how you deal with typing structure. Take a look and we will discuss more in next call. +**Proto**: There is something to n/w as well. There are considerations for how you deal with typing structure. Take a look and we will discuss more in next call. **Danny**: other spec related item? - + ## 6. Testnet Discussion - + **Danny**: Status is similar to two weeks ago. Prime focus in most clients is getting a public version of the testnet out or joining other public testnets. - -Some really good movement on that. Prysmatic relaunched testnet, couple of other clients really near to that. Nimbus doing their weekly builds. - + +Some really good movement on that. Prysmatic relaunched testnet, couple of other clients really near to that. Nimbus doing their weekly builds. + It seems like there's still work to do before orchestrate a large scale multi-client public network. Are there any other thoughts, comments, discussion, questions about this? - - - + + + ## 7. Open Discussion/Closing Remarks **Mikhail**: I have a question about weak subjectivity period. It's period size comes from Casper FFG paper. I am wondering if we are tightly coupled with the size calculation that we've so far and does it prevent long range attacks only or if there are some other implications here? -**Vitalik** - **[weak subjectivity period](https://ethresear.ch/t/weak-subjectivity-under-the-exit-queue-model/5187)**, yes there are calculation. I made an Eth Research post about that. How long the week subjectivity period is based on the rate at which people can withdraw. The withdrawal period is maximum is 8 months in the worst case. In the normal case, the one who is withdrawing, get out after about two days. In the case, where there is small amount of Ether, the maximum also drops and of compromise and encourage more people to join in. +**Vitalik** - **[weak subjectivity period](https://ethresear.ch/t/weak-subjectivity-under-the-exit-queue-model/5187)**, yes there are calculation. I made an Eth Research post about that. How long the week subjectivity period is based on the rate at which people can withdraw. The withdrawal period is maximum is 8 months in the worst case. In the normal case, the one who is withdrawing, get out after about two days. In the case, where there is small amount of Ether, the maximum also drops and of compromise and encourage more people to join in. In terms of why that exists and based, one part of it is because it determines how often people needs to come online to get the security guarantee. @@ -422,7 +421,7 @@ Okay I know y'all are all pretty heads down working on these things. I think we * Chih-Cheng Liang * Daniel Ellison (Consensys) * Danny Ryan (EF/Research) -* FJL +* FJL * Hsiao-Wei Wang * Jacek Sieka * JosephC @@ -438,7 +437,7 @@ Okay I know y'all are all pretty heads down working on these things. I think we * Nicholas (Hsiu-Ping) Lin * Nicolas Liochon * Nishant Das -* Paul Hauner +* Paul Hauner * Protolambda * Pooja Ranjan * Raul Jordan diff --git a/eth2.0-implementers-calls/call_029.md b/eth2.0-implementers-calls/call_029.md index fc722d4..cfd9bc2 100644 --- a/eth2.0-implementers-calls/call_029.md +++ b/eth2.0-implementers-calls/call_029.md @@ -1,25 +1,23 @@ -# Ethereum 2.0 Implementers Call 28 Notes - - ### Meeting Date/Time: Thursday 2019/12/5 at 14:00 GMT - - ### Meeting Duration: ~ 53 mins - ### [GitHub Agenda Page](https://github.com/ethereum/eth2.0-pm/issues/108) - ### [Audio/Video of the meeting](https://www.youtube.com/watch?v=MxeEWmEdb5E) - - #### Moderator: Danny Ryan - #### Notes: Sachin Mittal +# Ethereum 2.0 Implementers Call 29 Notes + +### Meeting Date/Time: Thursday 2019/12/5 at 14:00 GMT +### Meeting Duration: ~ 53 mins +### [GitHub Agenda Page](https://github.com/ethereum/eth2.0-pm/issues/108) +### [Audio/Video of the meeting](https://www.youtube.com/watch?v=MxeEWmEdb5E) +### Moderator: Danny Ryan +### Notes: Sachin Mittal ---------- - **Danny**: Welcome everyone! + **Danny**: Welcome everyone! ## 1. Testing and Release Updates - + ### Removal of signing root **Danny**: Being executed by protolamda, feedback so far is overwhelmingly positive. Need a decision on this call. No objections, so plan to merge it today unless any objections noted on PR 1491. - ### Fixes to fork-choice - + ### Fixes to fork-choice + **Danny**: Plan to merge soon, but looking for better ways to test and specify fork-choice behaviour. I suggest, we do unit testing for specific functions and Integration test by throwing a bunch of blocks and add few stations at a client and getting a result. **Mammy**: I'm just thinking for multi-threading testing. Though it's very hard because we have to like test interleaving of four or five phrases in different order and there are ways to do that so maybe we can reuse the same. @@ -33,23 +31,23 @@ Easiest would be to have a lot of SSE objects, and then test values interleaving **Carl**: It is adopting the new hash to curve version, as mentioned in my PR #1499. It basically tries to separate Eth 2.0 specs from the BLS specs to help teams using 3rd party libraries. Onto updating the test vectors. -**Danny**: We might put it into dev, but cut of the test vectors so that when we’ll begin to work on the BLS implementations, we can generate the vectors. +**Danny**: We might put it into dev, but cut of the test vectors so that when we’ll begin to work on the BLS implementations, we can generate the vectors. * Fuzzing (BeaconFuzz) is making progress. - + ## 2. Client Updates - + ### NimBus **Mammy**: - -* We finished the last SSZ bugs, so you can use CLI again. -* Regarding Optimizations, we have removed last quadratic behaviours, now OCI time has been reduced from 50 minutes to less than 20 minutes. -* Final bottlenecks are SHA256 and BLS, but not blocking for having the state transition under 6 seconds. + +* We finished the last SSZ bugs, so you can use CLI again. +* Regarding Optimizations, we have removed last quadratic behaviours, now OCI time has been reduced from 50 minutes to less than 20 minutes. +* Final bottlenecks are SHA256 and BLS, but not blocking for having the state transition under 6 seconds. * On testnet, we are debugging syncing. It is working but we have some edge test cases. Also, we have done a lot of polish on the instructions for Joining. -* For the test and CI, we are in the process of setting up Jenkins so to test Nimbus on controlled hardware, especially Android and ARM. Also, we are now auto tracking running tests especially state transitions to make sure we don't have any regression. -* No more git-LFS or the EF. On the phasing prop, we now have something similar to NCLI called NFS (fuzzing endpoints) and we have PR pending on CPE on becoming the phase repo with shuffling as a proof of concept. +* For the test and CI, we are in the process of setting up Jenkins so to test Nimbus on controlled hardware, especially Android and ARM. Also, we are now auto tracking running tests especially state transitions to make sure we don't have any regression. +* No more git-LFS or the EF. On the phasing prop, we now have something similar to NCLI called NFS (fuzzing endpoints) and we have PR pending on CPE on becoming the phase repo with shuffling as a proof of concept. * For networking, ready to integrate libp2p and remove daemon. Next is discv5. @@ -57,7 +55,7 @@ Easiest would be to have a lot of SSE objects, and then test values interleaving **Alex Stokes**: -* Up to spec 0.9.2. We have done a lot of fork choice updates, refactoring and bug fixes. +* Up to spec 0.9.2. We have done a lot of fork choice updates, refactoring and bug fixes. * Converting Pylibp2p to Trio library. Bugfixes and prep for public testnet. Open PR for attestation aggregation. @@ -68,7 +66,7 @@ Easiest would be to have a lot of SSE objects, and then test values interleaving **Cayman**: * We swapped our BLS implementation with WASM build of Herumi, and it speeded up 40x across the board. -* Implemented BLS EIP 2333-2335 for future use. +* Implemented BLS EIP 2333-2335 for future use. * Still updating to 0.9.x. discv5 in progress. ### Artemis @@ -77,28 +75,28 @@ Easiest would be to have a lot of SSE objects, and then test values interleaving * Up to date with 0.9.2 including naive aggregation. * Req/Resp is done and being tested against Prysm and Lighthouse. -* Focus remains on getting ready to join public Testnets: syncing and importing deposit receipts. +* Focus remains on getting ready to join public Testnets: syncing and importing deposit receipts. * Completing discv5 integration. ### Prysm **Terence**: -* Testnet has been running smoothly, except a couple of finality reversions which have now been debugged. -* Beacon chain explorer has necessitated some work on RPC endpoint. And it is up and running, so people can build some other cool stuff on the top of it. -* Primary focus is 0.9.2 testnet relaunch. +* Testnet has been running smoothly, except a couple of finality reversions which have now been debugged. +* Beacon chain explorer has necessitated some work on RPC endpoint. And it is up and running, so people can build some other cool stuff on the top of it. +* Primary focus is 0.9.2 testnet relaunch. * Raul spent a lot of time optimising SSZ with a functional cache for the custom state SSZ resulting in 50x speedup in syncing. ### Lighthouse **Adrian Manning**: -* Public testnet target release this week. -* Database optimisations have been made. New schema makes the DB very small. It doesn’t duplicate any states and use checkpoints to make the DB small. +* Public testnet target release this week. +* Database optimisations have been made. New schema makes the DB very small. It doesn’t duplicate any states and use checkpoints to make the DB small. * Speedups in SSZ decoding - remove BLS checking when reading state from the DB, big performance gain. -* Rebuilding syncing algorithms to support multiple peers over a longer lasting testnet. Tied up logging to make it more user friendly, Validator onboarding docs written and are in the PR. -* Metrics and monitoring for the testnets up and running. -* We pulled our testnet down today because one of our major bootnodes often booted the other nodes, so we used to ban them but now we have kept it lenient and will kick them only for 30 seconds. +* Rebuilding syncing algorithms to support multiple peers over a longer lasting testnet. Tied up logging to make it more user friendly, Validator onboarding docs written and are in the PR. +* Metrics and monitoring for the testnets up and running. +* We pulled our testnet down today because one of our major bootnodes often booted the other nodes, so we used to ban them but now we have kept it lenient and will kick them only for 30 seconds. **Danny**: Thanks! What were the optimizations from LS, and SSZ? @@ -116,17 +114,17 @@ everything in memory and then using them because that makes a great latency drin **Mikhail** * At 0.9.2, excluding aggregation stuff. -* Working on integration tests for the fork choice. Almost ready to push fork choice tests to community test suite. -* Discv5 has been merged and now we are looking at simulations. -* Also made some progress on gossipsub simulations. Shared during the yesterday’s network call. +* Working on integration tests for the fork choice. Almost ready to push fork choice tests to community test suite. +* Discv5 has been merged and now we are looking at simulations. +* Also made some progress on gossipsub simulations. Shared during the yesterday’s network call. ### Parity - + **Wei Tang**: -* Some updates to Substrate. +* Some updates to Substrate. * Still on 0.9.0; trying to join Prysm testnet, but there is an issue in BLS verification (all the spec tests pass, but real sigs fail which is weird). -**Danny**: Great, Thanks!! We have Tomasz onboard to share their research. +**Danny**: Great, Thanks!! We have Tomasz onboard to share their research. ### Nethermind @@ -134,10 +132,10 @@ everything in memory and then using them because that makes a great latency drin ## 3. Research Updates - + **Vitalik**: * Working with Justin on increasing the efficiency of STARK proving. -* Working on more application level things this week - blog post coming. +* Working on more application level things this week - blog post coming. * Discussing how Phase 2 cross-shard Txs will work: to be enshrined in protocol, or done with receipts in the application layer? Is Eth2 a fat protocol or just a data-availability and computation layer? @@ -151,13 +149,13 @@ everything in memory and then using them because that makes a great latency drin **Musab (Runtime Verification)**: Abstractions of the beacon chain model. Started this week trying to prove safety and liveness. -**Danny**: Daejun (Runtime Verification) is writing up the formal analysis of the deposit contract, expected this month for public review. +**Danny**: Daejun (Runtime Verification) is writing up the formal analysis of the deposit contract, expected this month for public review. -**Matt Garnett (Quilt)**: +**Matt Garnett (Quilt)**: * Phase 2 call happened. Next one is targeted for mid Jan. Will has aggregated some questions regarding the stateless protocols and put it on the eth.research. Here is the [Summary](https://ethresear.ch/t/remaining-questions-on-state-providers-and-stateless-networks-in-eth2/6585). -* I’m working on some tools to improve the process of building and testing execution environments which has been one of the big pain points for both of us to explore in that area and our new hires are still working on the simulation. +* I’m working on some tools to improve the process of building and testing execution environments which has been one of the big pain points for both of us to explore in that area and our new hires are still working on the simulation. ## 4. Networking @@ -174,12 +172,12 @@ everything in memory and then using them because that makes a great latency drin ## 5. Discussion of persisted state size reduction **Danny**: This is an Agenda item from Mikhail. I know, Lighthouse is working on this. Adrian, you wanna give a quick synopsis about your hot and cold scheme? - + **Adrian**: There are three parts, the hot-cold as you said. Hot is pretty much anything after finalize, then after they are moved into the cold database. So in the cold database are things that shouldn't be changing or moved. We can kind of streamline where they're actually stored on the disk. I guess, the main gains that we have is doing an a Nimbus style approach. Where we store state snapshots instead of every state and then if we need to read the state for any reason in the cold database at some stage. You can rebuild a state or replace that by the state from the blocks that we have in the diary. So you keep the blocks and checkpoint states. Essentially we don't duplicate any of the states so if there's a state duplication it kind of just re - references. The main gains which I think are the easiest to do are the staged snapshot in the freezer DB. -**Danny**: How are you choosing, I mean what are the parameters of a snapshot? +**Danny**: How are you choosing, I mean what are the parameters of a snapshot? -**Adrian**: Its configurable, working on it! (We are measuring the time it will take to fill the 32 GB HDD). +**Adrian**: Its configurable, working on it! (We are measuring the time it will take to fill the 32 GB HDD). **Mikhail**: Question! I believe hot storage is very big in size, I mean 100 MB+ to represent an epoch and so on… in my opinion, it requires some reduction as well? @@ -189,9 +187,9 @@ everything in memory and then using them because that makes a great latency drin **Mikhail**: Thinking about incremental storage, just the diffs between states. -**Protolambda**: Lighthouse’s approach seems ideal. Has worked on tree-state. +**Protolambda**: Lighthouse’s approach seems ideal. Has worked on tree-state. -**Jacek Seika**: This may have an impact on state-syncing between nodes. We may wish to agree on which states are available to be synced (e.g. one every few weeks within the weak subjectivity period). +**Jacek Seika**: This may have an impact on state-syncing between nodes. We may wish to agree on which states are available to be synced (e.g. one every few weeks within the weak subjectivity period). **Mikhail**: Anton from our team is planning to look into state sync design. @@ -203,11 +201,11 @@ Discussion of release of Ph1 spec! Vitalik <> Danny **Vitalik**: Yeah, atleast a scaffold of Phase 1 needs to be released so that people can start building, testing over it. Also, about fraud proof part as well. -Also, We need a team looking at Eth1 - Eth2 bridge. +Also, We need a team looking at Eth1 - Eth2 bridge. ## 7. Testnet Discussion -**Danny**: We are still in the optimising/hardening stage. Single-client testnets are good for now - but I would like to see them scaled to very large validator numbers maybe using DevOps scripts and deploying to the cloud. Talk to me, if anyone has ideas around this. +**Danny**: We are still in the optimising/hardening stage. Single-client testnets are good for now - but I would like to see them scaled to very large validator numbers maybe using DevOps scripts and deploying to the cloud. Talk to me, if anyone has ideas around this. ## Attendees @@ -237,7 +235,7 @@ Also, We need a team looking at Eth1 - Eth2 bridge. * Nicolas Liochon * Nishant Das * Protolambda -* Shahan +* Shahan * Terence Tsao (Prysmatic Labs) * Tomasz Stanczak * Trentonvanepps diff --git a/eth2.0-implementers-calls/call_030.md b/eth2.0-implementers-calls/call_030.md new file mode 100644 index 0000000..65d6e9c --- /dev/null +++ b/eth2.0-implementers-calls/call_030.md @@ -0,0 +1,274 @@ +# Ethereum 2.0 Implementers Call 30 Notes + +### Meeting Date/Time: Thursday 2019/12/19 at [14:00 UTC](https://savvytime.com/converter/utc-to-germany-berlin-united-kingdom-london-ny-new-york-city-ca-san-francisco-china-shanghai-japan-tokyo-australia-sydney/dec-19-2019/2pm) +### Meeting Duration: 1 hr +### [GitHub Agenda](https://github.com/ethereum/eth2.0-pm/issues/112) +### [Audio/Video of the meeting](https://www.youtube.com/watch?v=LYLiqpj-wiE) +### Moderator: Danny Ryan +### Notes: Edson Ayllon + + +----------------------------- + +# Summary + +## ACTIONS NEEDED + +Action Item | Description +--|-- +**30.1** | Complete fork-choice test. +**30.2** | Use Muskoka to log failed SSZ blobs. +**30.3** | Decide solution for ETH transfer between execution environments and shards, while being read by block producers +**30.4** | Create full specifications for the Eth1-Eth2 bridge. +**30.5** | Decide on new caching specification proposal. +**30.6** | Create a script that reads and delivers the genesis state to the client. + +----------------------------- + +# Agenda + +- [1. Testing and Release Updates](#1-testing-and-release-updates) +- [2. Client Updates](#2-client-updates) +- [3. Research Updates](#3-research-updates) +- [4. Highlights from Client Survey](#4-highlights-from-client-survey) +- [5. Networking](#5-networking) +- [6. Spec discussion](#6-spec-discussion) +- [7. Open Discussion/Closing Remarks](#7-open-discussionclosing-remarks) + +----------------------------- + + +# 1. Testing and Release Updates + +**Video:** [`[0:46]`](https://youtu.be/LYLiqpj-wiE?t=46) + +`v0.9.3`released which includes changes to State Transition and Networking. Missing in the Networking PR, adding attestation subnet bitfield to ENR, will be added. + +BLS standards integration has gone through iterations. A good PR has been reviewed and will be merged. Release for the first week of January. + +Phase 0 is undergoing a comprehensive audit. An official announcement will be released today. `v0.10` will be the target. + +## 1.1 Fork-Choice + +Still awaiting completion of the fork-choice test. Harmony has finished beacon data processor implementation, close to spec, handling delayed attestations. The beacon data processor can be used to generate comprehensive scenarios for fork-choice. Harmony is prioritizing an integration test approach for fork-choice. + +- [**@harmony-dev/beacon-chain-java#213** fork choice implementation/updates](https://github.com/harmony-dev/beacon-chain-java/pull/213) + +## 1.2 Fuzzing + +Lighthouse team fuzzers are matching `v0.9.1` of spec. Will be upgrading to `v0.9.3` or `v0.9.4` following three existing client implementations. Additionally, Python sub-interpreters integrated to keep Python implementations isolated. Nimbus integrated to multiple fuzzers. Beacon fuzz has potentially identified its first crash due to a failed assertion. More information provided tomorrow. Some fuzzers were published on [Fuzzit](https://fuzzit.dev/). The plan is to submit a request to Google to use their infrastructure for fuzzing, expected end of January. + +Lighthouse has started looking at a library that allows random mutation of photo-buffers. This can be used with guided fuzzing engines, such as lib-fuzzer. Works similar to fuzzing done with Solidity compiler. + +[**@cryptomental**](https://github.com/cryptomental), from the Eth1 fuzzing team, has joined the Lighthouse Beacon Fuzz team, working primarily on onboarding Prysm. Blog post detailing challenges and progress on Beacon Fuzz will be published. + +RPC fuzzer for Lighthouse has been implemented, which has been running about a week. Won't be integrated to Beacon fuzz, but other clients are encouraged to do something similar. + +[Muskoka](https://github.com/protolambda/muskoka-client) can log failed SSZ blobs. + +## Actions +- **30.1**—Complete fork-choice test. +- **30.2**—Use [Muskoka](https://github.com/protolambda/muskoka-client) to log failed SSZ blobs. + +# 2. Client Updates + +**Video:** [`[13:41]`](https://youtu.be/LYLiqpj-wiE?t=821) + +## 2.1 Trinity + +Working towards testnets. [Merged PR](https://github.com/ethereum/trinity/pull/1311) for the first pass at attestation aggregation. [Py-ssz PR merged](https://github.com/ethereum/trinity/pull/1394) handling hash root calculations. Microbenchmarks indicated significant performance speed. + +Other items: +- Progress made on separating validator client. +- Progress on syncing stability. +- Further work on Eth1 data component. + +## 2.2 Artemis + +Progress made on initiating minimal viable sync algorithm. Hoping to join a testnet soon. Refactored storage layer to increase reliability, to support queries needed on P2P. Continuing to integrate Harmony's Discovery v5. + +## 2.3 Prysmatic Labs + +Sixteen thousand validators ran on a single Beacon node locally. Several optimizations made. Working towards testnet restart with spec `v0.9.2`. A few core components will be redesigned. Fixing bugs on testnet as reported by users. + +For networking, adding pubsub validator to stop automated propagation of pubsub message + + +## 2.4 Nimbus + +Started on attestation aggregation, one PR merged. Started on benchmarking tool. + +Researching on managing a fleet of Nimbus nodes, having kill switch reporting, etc. Researching including stacked traces with less overhead, as stacked traces are slowing down processes significantly. + +For libp2p and networking, starting next week will have mixed libp2p daemon and libp2p pure Nim testnet. + +Mostly implemented `v0.9.3` spec. Waiting for zcli or pyspec Trinity state to ensure alignment. + +Research for Phase 2 includes EE, language, and generating WASM. + +For Eth1, looking to sync with Geth, Parity Eth1 chain. There is a bottleneck in storage. + +Started research on EVMC to investigate adding Nimbus as a backend. + +## 2.5 Lodestar + +`v0.9.2` spec branch merged in the next few days. Working on SSZ caching. Will upgrade and refactor libp2p, helping with validating incoming messages. + +## 2.6 Lighthouse + +Started mainnet 16k validator testnet, which ran for a week, containing 4 nodes running 4k validators on AWS. Ran and stopped seeing finality. As a result, now targeting 0.1.2 release which includes a fix for gossip nodes. + +State was being stored before blocks, resulting in database error if the client crashed. Fixed by reversing the storage order. + +Added [fix to Eth1 caching](https://github.com/sigp/lighthouse/pull/709). `deposit_root` and `deposit_count` now come from the logs instead of contract calls. + +Made API upgrades. + +For Networking, updated Rust gossip sub for content addressed messages. Started implementing naive attestation aggregation strategy. + +New testnet may be launched tomorrow and made public next week. + +Also hiring Rust developers, [see Twitter](https://twitter.com/sigp_io/status/1207080033254166528). + +## 2.7 Shasper + +Testing testnet against Prysmatic, ensuring the connection is reliable. The goal is to enter as many testnets as possible. + +## 2.8 Nethermind + +Still in Phase 0. Working on a validator of basic block creation. Still on spec `v0.9.1`. No Phase 1 yet. + +For networking, deciding what algorithm to use for libp2p stack. The first stage will be on Go daemon. + +## 2.9 Harmony + +Working on fork-choice. More simulations are done. +- [Gossip pubsub simulation for Beacon Chain](https://hackmd.io/ZMBsjqdqSAK026iFFu_2JQ) + +ns-3 simulator tested concluding insufficient support for Python. May move to something else. + +Filed issues found on naive aggregation attestation. + +# 3. Research Updates + +**Video:** [`[33:08]`](https://youtu.be/LYLiqpj-wiE?t=1988) + +TXRX consists of members from Artemis and Harmony are merged to focus on Phase 1, Phase 2 research. + +Research areas include discovering the right short term availability scheme. STARKing a merkle root may be the best long term option, but depends on having a reliable STARK compatible hash function. Until then, options include the 2-dimensional scheme, using FRY as a fraud-proof mechanism. + +Researching how ETH transfers will operate in Phase 2. Ether is used to pay transaction fees, which must be seen by block producers. The challenge is to transfer ETH between execution environments, between shards, and be read by block producers. Solution options include guaranteed cross-shard messaging. Here, the ETH execution environment would be the only one block producers would be required to understand. + +Phase 2 call is scheduled for mid-January. Will focus on cross-shard transactions, and flea market. + +Quilt is performing work on tooling for the contract EE to run. These tools will imitate Truffle, to ease developer onboarding. + +Eth2 resource book first chapter will be released within 1-2 weeks. + +Write-up being done on [EthResearch](https://ethresear.ch/) to help make a decision on state provider relayer questions, around block producers and state. + +Quilt collaboration started with TXRX. + +Research should be done to full spec Eth1-Eth2 bridge. + +TXRX will be doing research on Eth bridge, among other things. Workshop will be done outside Stanford blockchain conference focusing on Phase 2. + +EthBarcelona will be organized for May 15 as a one-day event. Will present updates on Eth2.0. +- [Eth Barcelona](https://ethbarcelona.github.io/) + +For zero-knowledge proofs, need an optimal prover and optimal verifier. Currently in possession of an optimal prover, but the verifier is no longer optimal. + +## Actions +- **30.3**—Decide solution for ETH transfer between execution environments and shards, while being read by block producers +- **30.4**—Create full specifications for the Eth1-Eth2 bridge. + + +# 4. Highlights from Client Survey + +**Video:** [`[56:16]`](https://youtu.be/LYLiqpj-wiE?t=3376) + +The survey is to aid in planning and identifying help for resources or bottlenecks. + +Initial look, noise libp2p implementations needed. Will need to review further. + +# 5. Networking + +**Video:** [`[57:16]`](https://youtu.be/LYLiqpj-wiE?t=3436) + +Most of this section has been done in a separate networking call. Another networking call schedule for the second week of January. + +- [Networking call notes](https://hackmd.io/@benjaminion/SJ3W0qwAH) + +# 6. Spec discussion + +**Video:** [`[57:54]`](https://youtu.be/LYLiqpj-wiE?t=3474) + +A proposal made to use timestamps instead of block depth to reduce overhead of caching, and issues handling re-orgs locally. Removes Beacon state read done when loading. +- [**eth2.0-specs#1537** Concerns about Eth1 Voting in Context of Caching](https://github.com/ethereum/eth2.0-specs/issues/1537) + +## Actions + +- **30.5**—Decide on new caching specification proposal. +- **30.6**—Create a script that reads and delivers the genesis state to the client. + + +# 7. Open Discussion/Closing Remarks + +**Video:** [`[1:09:30]`](https://youtu.be/LYLiqpj-wiE?t=4170) + +Happy Holidays. Next call week after new years. + +------ + +# Annex + +## Next Meeting Date/Time + +Thursday January 9, 2019. + +## Attendees + +- Alex Stokes +- Ben Edington +- Carl Beekhuizen +- Cayman +- Chih-Cheng Liang +- Dankrad +- Danny Ryan +- Hsiao Wei Wang +- Jared Wasinger +- John Adler +- Jonny Rhea +- Joseph Delong +- JosephC +- Justin Drake +- Kevin Chia +- Leo BSC +- Mamy +- Marin Petrunic +- Mehdi +- Meredith Baxter +- Mikerah +- Mikhail Kalinin +- Nicholas (Hsiu-Ping) Lin +- Nishant Das +- Paul Haauner +- Protolambda +- Raul Jordan +- Shahan Khatchadourian +- Sly Gryphon +- Terence +- Tomasz Stanczak +- Trenton Van Epps +- Vitalik Buterin +- Wei Tang +- Will Villanueva + +## Links Mentioned + +- [**@harmony-dev/beacon-chain-java#213** fork choice implementation/updates](https://github.com/harmony-dev/beacon-chain-java/pull/213) +- [Eth Barcelona](https://ethbarcelona.github.io/) +- [Networking call notes](https://hackmd.io/@benjaminion/SJ3W0qwAH) +- [**eth2.0-specs#1537** Concerns about Eth1 Voting in Context of Caching](https://github.com/ethereum/eth2.0-specs/issues/1537) +- [Call notes](https://hackmd.io/@benjaminion/SJ3W0qwAH) by [**@benjaminion**](https://github.com/benjaminion) +- [Gossip pubsub simulation for Beacon Chain](https://hackmd.io/ZMBsjqdqSAK026iFFu_2JQ)