Eth2.0 Implementers Call 8 Agenda

[djrtwo]

Eth2.0 Implementers Call 8 Agenda

Meeting Date/Time: Thursday 2018/12/13 at 14:00 GMT

Meeting Duration 1.5 hours

YouTube Live Stream Link

Agenda

1. Client Updates
2. Research Updates
3. "low hanging fruits" for testing
4. unsigned under and overflow problems
5. Spec discussion
6. Open Discussion/Closing Remarks

[Mikerah]

I won't be able to attend this weeks call due to finals. However, my co-workers will be present. A one-liner summary is that we have successfully migrated to typescript. They will go into more details during the call.

Also, has a decision been made about our next t sharding meetup? It would be nice to be able to plan ahead?

[mratsim]

I'd like to add a "low hanging fruits" for testing to the agenda.

Things that are pretty much self-contained that we could generate test vectors for.

It requires a blessed Python implementation that is up-to-date with the specs however.
When doing the shuffling test vectors in status-im/nimbus-eth2#31 I've noticed for example that Py-EVM shuffling was outdated (using the old dynasty, fixed since then).

For example:

• Shuffling
• Keccak Hashing
• Tree hashing
• BLS aggregation and signature
• ...

[mratsim]

Another item I'd like to discuss is the unsigned underflow problem, see ethereum/consensus-specs#192, ethereum/consensus-specs#224

cc @arnetheduck and cc @paulhauner

This impact testing a lot as lots of test vectors will be needed to cover those edge cases.

[paulhauner]

I won't be on the call sorry @mratsim, but my thoughts are expressed here.

Ultimately, I think the confusion comes from the follwing:

1. The code examples in the spec are in Python.
2. It's unclear as to whether or not block.slot (to take an arbitrary variable) is a Python int or a uint64.
3. If block.slot is a uint64, the behavior of such a type in Python is undefined (even if it seems obvious).

[djrtwo]

Even though the code samples in the spec are python, we should probably move to making the type-hints reflective of the actual integer type values. def sample(slot: uint64) instead of def sample(slot: int) even though the former is not supported in python out of the box.

In production python there will either be better typing or a bunch of if/else to ensure the values are as expected

[arnetheduck]

I believe there's value in keeping the concerns apart - the objects describe a serialization format.

The rest of the spec is about computation. Those are two different worlds, and while we can strive to align them, constraints and priorities are slightly different when designing for the two.

Logically, before we use the values from the network, we have to deserialize them into whatever our respective languages demand of us. By constraining the computation to a lowest common denominator between those languages, or really, by not using certain techniques and features of certain languages (like python, and its native bigints), we can make the translation step easier by having less friction between the layers, but there's a balance to be had as well.

[raulk]

I won't be able to make it today :-( I'll stay tuned for the minutes and I'll watch the video in case something comes up for libp2p.

Big thanks to everyone who participated in our roadmap idea collection phase of libp2p!

[sriharikapu]

lets do it

[zscole]

Wasn't able to join. Thanks for chiming in on my behalf, @mratsim! Everything is still moving along in accordance with our previous roadmap. Preparing something tangible to present for next meeting. Cheers!

[djrtwo]

notes here https://github.com/ethereum/eth2.0-pm/blob/master/eth2.0-implementers-calls/call_008.md