1. 8.1 (ish, because we pulled some changes from 8.2 in places if I’m correct)
3. SSZ has been a hassle from 8.0 to 8.1, but we’re finally nearly done
4. Interop Suggestions
1. I would like to see a multi-client integration test network. Each time the core spec revs (or the network stack is updated), then we run a series of tests for the consensus layer and network layer. It would be good to include basic tests for core functionality, but also stress tests to see how the performance is affected after each rev.
For the Lock-In:
1. It would be good if all clients could support static peering
2. Clearly defined goals for interop stages (e.g. Coordinated Start, Join & sync, etc)
3. 2 or 3 teams paired up at a time.
5. SSZ and (more recently) test format changes
6. Keeping 9 clients interoperable.
1. Mothra is handling our libp2p side so yes.
2. No, we have native bindings to rust libp2p. No gRPC required
3. We use discv5 and static nodes (via mothra)
4. Implementing the HELLO handshake as specified in the network spec
5. Secio currently
6. GOSSIP as defined in the network spec. Working on RPC
3) We don’t have syncing yet.
4) We currently store blocks and states on all slots
5) We have no attestation aggregation
6) We haven’t tested the fork choice much. We use the unoptimized spec version.
7) We will have tests passing by the lock-in
1. SSZ_static, Shuffling and BLS. Others are partially working.
8) Block Propagration
2. Terminate state transition
1. We receive the block and propogate before checking it.
9) Attestation Propagation
- we relay first
10) Block Proposals
2. No, we have our own gRPC communication with our Validators
3. Log4J and a Custom JSON/CSV output log (variables can be added and removed via a config file)
2. Seems ok at a glance.
2. We haven't profiled it - seems okay though
2. Milagro(v0.4.0) - https://repo1.maven.org/maven2/
3. Mikuli - will eventually be pushed to Apache Tuweni. Most current code is here: https://github.com/PegaSysEng/artemis/tree/master/util/src/main/java/tech/pegasys/artemis/util/mikuli
15) Chain start
1. We support ii, iv, vi, vii
2. Typically generate them in a predictable manner for debugging.
16) Congig & Perf
2. Not sure
3. We do both
17) Building & deploying
4. OSX and Linux
5. It would be nice to have a way to decode encrypted payloads with wireshark or tcpdump.