# ETH 2.0 Interop Survey Response - Lodestar

### 1. General

- **1.1** What is the latest version of the specification which your client currently supports?
0.8.1
- **1.2** Is `v0.8.2+` targeted as interop version? If not, which version do you suggest?
:heavy_check_mark:
- **1.3** Are any features or components particularly difficult to update, and on what versions are these currently?
:x:
- **1.4** In terms of interop, do you have any suggestions?
We may not have a performant enough client for interop. It will probably be useful for us to focus on specific aspects of interop at the lockin.
TODO: outdated now with latest BLS change?

- **1.5** What has been your primary bottleneck in development?
resource allocation
- **1.6** What do you anticipate to be the primary bottleneck in the future?
Focusing on the "right priorities", being spread thin on different development fronts: full client optimization, light clients, dev tooling polish

### 2. Networking Essentials

- **2.1** Does your client currently implement libp2p? If not, what subset is working?
:heavy_check_mark:
- **2.2** Do you make use of a libp2p daemon approach?
:x:
- **2.3** How does your client become aware of its peers?
Static node list
- **2.4** By which process does your client establish a handshake with its peers?
req/resp hello messages
- **2.5** Which wire-level encryption methods does your client implement or support? Secio? TLS? Other? If your client supports multiple encryption methods, please indicate which ones.
Secio
- **2.6** Does your client conform to the specified wire protocol? If not, please provide a link to the appropriate code snippet or repo which defines these message types.
:heavy_check_mark:

### 3. Syncing

- **3.1** Do you use the `/eth2/beacon_chain/req/beacon_blocks/1/` proposed in the [Network Spec](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/networking/p2p-interface.md#beaconblocks) for syncing?
not yet
- **3.2** Do you support a full sync from genesis after the network is running for a longer period of time
:heavy_check_mark:
- **3.3** Can you bootstrap syncing with a copy of sync data?
:x:
- **3.4** Do you make use of batch-requests for blocks? If so, what does your batched block request look like?
:x: we only batch the blocks in initial sync
- **3.5** Do you have any particular sync strategy? (Full sequential, skip-ahead, or some hybrid approach?)
full sequential
- **3.6** Do you implement any pruning mechanism? (not necessary for initial interop)
:x:

### 4. State Storage
#### (_Out of interest, no hard requirements_)

- **4.1** Do you minimize storage? Are you supporting any of the following approaches?
1. Immutable state data structure
2. Segmented/chunkfied state
3. Full copies :heavy_check_mark:
4. Other
- **4.2** What is your storage approach like?
1. Store on X interval
2. Store every slot
3. Store every block :heavy_check_mark:
4. Other

### 5. Attestation Aggregation

- **5.1** Do you follow the current [basic interop aggregate strategy](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/networking/p2p-interface.md#interop-3)? (parse anything, but publish just minimal what you have to aggregate later).
:x:
- **5.2** Do you support alternative (more advanced) aggregation strategies?
:x:

### 6. Fork Choice

- **6.1** Do you test fork choice? In what kind of context(s) do you test it?
Not really, we have unit tests that verify the lmd ghost functionality
- **6.2** What is your implementation type like:
- Unoptimized spec
- Cached spec-like
- Reduced form (shortcut 1-child nodes)
- Stateful structure :heavy_check_mark:
- Other

### 7. Spec-Tests / Transition Consensus

- **7.1** Do you pass the following spec tests? If not, in which configuration and what tests?:

We are passing all spec tests in both configurations.
- Block operations :heavy_check_mark:
- Epoch processing :heavy_check_mark:
- Sanity tests :heavy_check_mark:
- BLS integration :heavy_check_mark:
- SSZ_static :heavy_check_mark:
- Shuffling :heavy_check_mark:
- **7.2** What spec version are you currently targetting for tests?
We are running tests on 0.8.1 spec version but we are in process on migrating to new 0.8.2 spec tests.

### 8. Block Propagation (Strategy)

- **8.1** Do you follow the network spec: verify the proposer signature before relaying a block?
:x:
Should be ready for interop

- **8.2** And if so, do you transition state completely, or just enough to know the proposer index?
We transition the state completely.
- **8.3** Do you use any different approaches, like:
- **8.3.1** Do you at any time randomly (or always) relay blocks without verification of the signature?
:heavy_check_mark:
- **8.3.2** Which blocks do you process first (i.e. what gets priority)?
First come first served.
- **8.3.3** Do you detect spam? (i.e. drop peers with high amounts of invalid blocks)
We save block root of invalid blocks and skip them if they are received repeatedly.
- **8.3.4** Is there any security check for double voting on the same block height before propagation?
:x:

### 9. Attestation Propagation (strategy)

- **9.1** Do you follow the [network spec](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/networking/p2p-interface.md#topics): verify a voted-for block fully before relaying an attestation? (option 1), or do you take another approach, such as relaying first, or with certain peers only?
blindly relay

### 10. Block Proposals

- **10.1** Do you fill grafitti with any debug data?
- What do you think of thus grafitti debug format proposal, described [here](https://notes.ethereum.org/VpUNqtrgRvqogY38bmKWpA)?
lgtm
- **10.2** Do you implement the latest [Validator API](https://github.com/ethereum/eth2.0-specs/blob/dev/specs/validator/0_beacon-node-validator-api.md)?
Working according to spec
- **10.3** What is your clock syncing approach?
rely on system clock

### 11. Monitoring

- **11.1** Do you implement the [proposed Metrics](https://github.com/ethereum/eth2.0-metrics/blob/master/metrics.md)
:heavy_check_mark:
- **11.2** Do you provide a API endpoint for:
- Sync status :x:
- Current chain head (from node perspective) :heavy_check_mark:
- A series of blocks :x:
- **11.3** What do you use for logging? (e.g. custom JSON, library XYZ)
custom text, [winston logger](https://github.com/winstonjs/winston)
- **11.4** Provide links to any misc. API implemented by the beacon node.
:x:
### 12. Keystore

- **12.1** Do you use anything like the Eth1 keystore format?
We use extact eth1 keystore format.
- **12.2** Do you see any problems with the [latest proposed keystore format](https://github.com/ethereum/eth2.0-specs/pull/1361), for interop purposes specifically?
lgtm

### 13. SSZ

- **13.1** Do you have SSZ v0.8 (hash-tree-roots with stable depth, bitlists/vectors) implemented currently?
:heavy_check_mark:
- **13.2** Do you experience any particular delays with hash-tree-root? (If not already for the minimal configuration, does it apply to mainnet state sizes for your ssz implementation?
:x:

### 14. BLS

- **14.1** Do tests pass for version v0.8.2+ (little endian domain bytes)
It passes 0.8.1 and it will probably pass 0.8.2 as we are already using bytes and not uint for domain.
- **14.2** What BLS library do you use? (provide link)
forked milagro js - https://github.com/ChainSafe/incubator-milagro-crypto-js
- **14.3** Do you implement a BLS wrapper? (provide link)
https://github.com/ChainSafe/lodestar/tree/master/packages/bls
- **14.4** Do you have a benchmark of verify-aggregate bench speed of 128 participants, same message being signed. Called from client.
~400ms
### 15. Chain Start ([reference doc](https://github.com/ethereum/eth2.0-pm/issues/60))

- **15.1** Do you support loading:
1. A kickstart (plain `(genesis_time, validator_count)` tuple) :heavy_check_mark:
2. A list of deposits, with incremental proofs (genesis spec) :x:
3. A list of deposits, with proofs all to the same deposit root. :x:
4. A series of deposit contract logs from an Eth 1.0 oracle, from a mock/test service :heavy_check_mark:
5. A series of deposit contract logs from a real Eth 1.0 node? :heavy_check_mark:
6. A genesis constructed from a (slow and long) stream of deposit log events? :?: (Should work)?
7. A plain prepared genesis BeaconState object from SSZ? :heavy_check_mark:
- **15.2** For testing genesis, do you generate keys in advance? And/or in a predictable reproducible manner for debugging?
We generate them from mnemonic.

### 16. Configuration & Performance

- **16.1** Do you meet minimal configuration in respect to processing performance; 6 seconds with 8-slot epochs? :heavy_check_mark:
- **16.2** Are there alternative variations / easier parameters that work particularly well for your testnet(s)? :x:
- **16.3** Do you load configuration on compile-time or run-time?
run-time

### 17. Building & deploying
- **17.1** Do you provide a build script for the client?
:heavy_check_mark:
- **17.2** Do you use a form of containerization? E.g. Docker?
untested docker image
- **17.3** Have you automated testnet deployments?
:x:
- **17.4** What platforms/architectures are supported?
linux, macos, windows

### 18. Conclusion

- **18.1** Is there anything that this questionnaire did not cover?
:x:
- **18.2** Any miscellaneous suggestions?
:x:
- **18.3** Are there any bottlenecks into which we may not currently have visibility?
naive implementation, slow code, brittle cli
- **18.4** What can we do to provide you with adequate support? In otherwords, *how can we make your life easier*?
list optimizations, create "slow network" configuration
- **18.5** In terms of tooling, what are we currently lacking?

---