# Harmony ETH 2.0 Interop Survey
### 1. General
- **1.1** v0.8.2
- **1.2** Yes.
- **1.3** It's appeared that updating test suite to `v0.8.2` is a pretty tough process. This is still WIP but near to be done.
- **1.4** On our end we have some duties to finish before interop. We're doing our best to get there. And if something isn't done it will be great to have a time and place to do some coding during the event. So, we could adjust with the others.
- **1.5** Network stack and attestation pool might be candidates for that. But its more about good challenges rather than bottlenecks.
- **1.6** Sync process and various consensus breaks due to differencies in implementations. Attestation aggregation and message dissemination.
### 2. Networking Essentials
- **2.1** No, but we are going to integrate JVM libp2p (which is now on its final stage) before the interop. Currently node uses custom wire protocol based on TCP.
- **2.2** No. Aiming to integrate native Java implementation.
- **2.3** Currently static node list. We have plans to partially implement discv5 (act as a client only) prior to the event.
- **2.4** For now it's just a TCP connection without security.
- **2.5** No encryption at the moment. When libp2p is integrated we will support Secio and optionally Noise.
- **2.6** Except of transport (libp2p) our current implementation follows the protocol closely.
### 3. Syncing
- **3.1** Currently we are using identical RPC with our custom wire protocol. The exception is we don't specify `head_block_root` and expecting a peer to return slot blocks from its canonical chain. Switching to this schema is a part of work planned for libp2p integration.
- **3.2** Yes.
- **3.3** No. Gonna add this feature before interop.
- **3.4** Yes, blocks are always requested by 128 chunks (with step 1).
- **3.5** Randomly requesting peers in parallel for block chunks with slots starting from the currently finalized block until some threshold, importing linked blocks, shifting finalized blocks, repeating. Not very optimal strategy but seems pretty reliable.
- **3.6** No.
### 4. State Storage
#### (_Out of interest, no hard requirements_)
- **4.1** At the moment we store full copies without optimisation.
- **4.2** There is a write buffer that is flushed when its reaches pre-defined threshold (64Mb for now). If process shuts down in a normal way then buffer is flushed before shutdown disregarding its size. In case of abnormal exit data written to the buffer gets lost.
### 5. Attestation Aggregation
- **5.1** We're not propagating messages at the moment. It's gonna be done after libp2p integration. Hopefully, before the interop. We're aiming that strategy to be implemented.
- **5.2** No.
### 6. Fork Choice
- **6.1** No.
- **6.2** Unoptimized spec.
### 7. Spec-Tests / Transition Consensus
- **7.1** Yes, we pass them all.
- **7.2** v0.8.2.
### 8. Block Propagation (Strategy)
- **8.1** No. Currently we use unverified blocks.
- **8.2** -.
- **8.3** Do you use any different approaches, like:
- **8.3.1** We always rely on unverified blocks.
- **8.3.2** Processing with no priority.
- **8.3.3** No. Scheduled on before the event.
- **8.3.4** No.
### 9. Attestation Propagation (strategy)
- **9.1** We're expecting beacon block to be imported before attestation is verified and propagated. Hence, attestations to blocks that are not yet imported are queued in memory and wait for processing until their blocks get imported.
### 10. Block Proposals
- **10.1** No. Scheduled on before the interop.
- The format looks good. Only beacon node peer count number doesn't seem to be valuable.
- **10.2** Yes.
- **10.3** We rely on local machine time which assumed to be catched up with NTP server. We, also, started some experiments with network time but didn't get too far (PR https://github.com/harmony-dev/beacon-chain-java/pull/156)
### 11. Monitoring
- **11.1** No. Planned prior to interop.
- **11.2** No, except syncing status implemented as a part of Validator API.
- **11.3** We use log4j2 library. There is an output to file and STDOUT.
- **11.4** -
### 12. Keystore
- **12.1** No.
- **12.2** Yes. We put a comments to that PR.
### 13. SSZ
- **13.1** Yes.
- **13.2** No.
### 14. BLS
- **14.1** Yes.
- **14.2** Milagro. https://github.com/apache/incubator-milagro-java
- **14.3** We use Milagro implementation written in pure Java.
- **14.4** We have a benchmarking tool for our spec implementation which, also, measures BLS stuff. An example of results is here https://github.com/harmony-dev/eth2.0-benchmarks/blob/master/0_beacon-chain.md#bls.
### 15. Chain Start ([reference doc](https://github.com/ethereum/eth2.0-pm/issues/60))
- **15.1** Do you support loading:
9. No. On a schedule to support it before interop.
- **15.2** We have a tool that given a seed generates a number of keypairs. We have a 1M of pre-generated key-pairs here https://github.com/harmony-dev/bls-key-pairs.
### 16. Configuration & Performance
- **16.1** Yes.
- **16.2** No.
- **16.3** Both approaches are supported.
### 17. Building & deploying
- **17.1** Yes. Based on Gradle package manager.
- **17.2** No.
- **17.3** No. Though we have an internal deterministic tesnet running in a single JVM process. Any number of nodes can be deployed and started in that testnet.
- **17.4** x86_64 (Linux/Win/MacOS)
### 18. Conclusion
- **18.1** Looks like a 100% coverage to us.
- **18.2** -
- **18.3** Not sure.
- **18.4** Stop changing test formats :) A joke, we understand that this is a necessary thing to get to a format that everybody are happy with.
- **18.5** Network and chain monitors (might be separated tools). Rich enough to observe all consensus parts including slashing conditions and incentivisation. And to get an information on how message dessimination progresses.
### 19. PS
We have an interop lock-in meta issue to track the progress of interop readyness https://github.com/harmony-dev/beacon-chain-java/issues/173.
It lists functionality that we're lacking according to mocked start spec and various community resources (including this survey).