lighthouse_survey1.md

1

• 1.1 8.2
• 1.2 Yes
• 1.3 Most difficult change for us was merklization.
• 1.4 Conformance with the network spec
• 1.5 Spec updates -- re-doing work or coding defensively in expectation of a spec update.
• 1.6 Perhaps spec updates during future phases, or friction trying to collaborate with other teams.

2

• 2.1 Yes.
• 2.2 No.
• 2.3 Discv5 - Although we can support libp2p kademlia if needed.
• 2.4 A discv5 session handshake is established. Then a libp2p secio - handshake is established with the peer if the peer supports it. (For interop we can ignore the initial discv5 handshake).
• 2.5 Secio (although we could upgrade to noise relatively easily).
• 2.6 Yes.

3

• 3.1 Yes
• 3.2 Yes
• 3.3 No - If there is a standard format, we could support this
• 3.4 Yes - It's based on the BeaconBlocks req. We batch lookup with fixed count parameters.
• 3.5 Primarily full sequential if needed, with optimizations
• 3.6 Not in master, but we are prototyping in a PR (its a part of the hot/cold DB we're working on).

4

• 4.1 Not in master, but we're working on a prototype. Should be ready in 1-2 weeks.
• 4.2 Store state on every block, but we'll move to a hot/cold database where hot is space-inefficient but fast & cold uses a highly optimized layout which assumes no forking (relies upon finality).

5

• 5.1 Following the interop strategy.
• 5.2 We can support strategies but none are built/employed.

6

• 6.1 Yes. We build a beacon chain in-process with different "attestation strategies" and then evaluate the outcome of find_head.
• 6.2 Reduced form - Although have implementations for unoptimized, cached and optimized

7

• 7.1 Yes, we pass all tests
• 7.2 v0.8.2

8

Our current strategy has been to target maximal interoperability - in this vein we do not drop blocks/attestations or kick peers that seem to be behaving maliciously. This logic is intended to be added after we can talk to other clients to avoid instant disconnects and bans during initial testing. We fully expect to implement verification logic soon afterwards.

• 8.1 No - Currently do not have gossipsub validation - it's on the TODO list
• 8.2 Full state transition
  • 8.3.1 - Relay all blocks currently - planned to change
  • 8.3.2 - We request needed blocks during syncing and they are processed sequentially. We process each block from gossip prioritised by time of arrival
  • 8.3.3 We detect this, but do not drop peers
  • 8.3.4 No

9

• 9.1 We forward everything we get :p (naughty lighthouse)

10

• 10.1 We tag the client version.
• 10.2 In the process of upgrading it.
• 10.3 NTP.

11

• 11.1 Yes, but with different names. Can easily alias.
• 11.2 Yes
• 11.3 Rust slog structured-logging library - can dump to JSON
• 11.4 You can get an idea of our API from our source code. There's more endpoints in progress right now.

12

• 12.1 No, currently store raw keys.
• 12.2 No, we plan to implement soon.

13

• 13.1 Yes
• 13.2 No

14

• 14.1 Not sure. Will be easy to fix if not.
• 14.2 Apache Milagro
• 14.3 sigp/milagro_bls
• 14.4 Yes, ~9ms on a i5 laptop.

15

Note: we're just starting interop works now. I expect most (if not all) of these will "WIP" be "yes" before the Canada Interop event.

• 15.1 i) Yes, except not the withdrawal_credentials part. We generate that as per the inter-op docs. ii) WIP. iii) WIP. iv) WIP. v) WIP. vi) No (future). vii) Yes.
• 15.2 Yes - We use a set of deterministic keys to bootstrap genesis. These are reproducible.

We also support a method where we can "bootstrap" a new node from an existing node via the REST API. The new node requests the genesis state and p2p addresses from the existing node, then starts syncing.

16

• 16.1 Yes
• 16.2 These are fine. We generally test with 1s slot times to get more coverage.
• 16.3 For us the spec values are split into two groups: constants (e.g., sizes of arrays) and variables (e.g., slot time). Variables can be configured using a TOML file. Constants must be specified at compile time, however we support multiple sets of constants and you can choose from one of these sets at runtime (e.g., minimal and mainnet).

17

• 17.1 Build is done via cargo, no additional script required.
• 17.2 We have a docker to spin up a number of nodes with metrics.
• 17.3 Yes, as above.
• 17.4 Currently Linux and MacOS.

18

• 18.1 -
• 18.2 -
• 18.3 -
• 18.4 -
• 18.5 Interop network tests, large scale testing, differential fuzzing.