Skip to content

Instantly share code, notes, and snippets.

@sorpaas
Last active August 29, 2019 00:12
Show Gist options
  • Save sorpaas/7f5843a16fb9cff8b0e99d34be6ef394 to your computer and use it in GitHub Desktop.
Save sorpaas/7f5843a16fb9cff8b0e99d34be6ef394 to your computer and use it in GitHub Desktop.

Answers

Survey v1.0.0.

1. General

1.1 We currently are on v0.8.1.

1.2 Yes.

1.3 No.

1.4 N/A

1.5 It was networking due to gossipsub. We're going to use lighthouse's libp2p fork for the gossipsub functionality, so it's not a blocker any more.

1.6 We weren't doing a lot in terms of optmization until now. But given this seems to be a well-researched topic by other client teams, I think it shouldn't be hard.

2. Networking Essentials

2.1 Yes.

2.2 No. We use native libp2p.

2.3 We're using a simple mDNS discovery and Kademlia, the same approach used by Substrate. Given lighthouse has implemented discv5, that's on our todo list next.

2.4 Our current implementation for networking is rather simple -- clients send each other a status message, and if it indicates a newer head, sync is started.

2.5 We currently use tcp-ws-secio-mplex-yamux.

2.6 Not yet. We're using a simple status sync (see 2.4), but we're planning to conform to the wire protocol.

3. Syncing

3.1 Not yet.

3.2 Yes.

3.3 No.

3.4 No.

3.5 We use simple full sequential.

3.6 No.

4. State Storage

(Out of interest, no hard requirements)

4.1 Our trie library has support immutable data sturcture, but it's not yet integrated. We currently just store the full copy.

4.2 Store every block.

5. Attestation Aggregation

5.1 We haven't yet implemented attestation broadcasting.

5.2 No.

6. Fork Choice

6.1 No. We don't yet have tests for fork choice.

6.2 Unoptimized spec.

7. Spec-Tests / Transition Consensus

7.1 Yes. We pass all spec tests.

7.2 v0.8.1

8. Block Propagation (Strategy)

8.1 We currently just import block first, sending a status, and wait for other peers to sync the block. This is rather inefficient so we definitely plan to improve.

8.2 So we transition state completely.

9. Attestation Propagation (strategy)

9.1 No. We haven't implemented attestation propogation.

10. Block Proposals

10.1 No.

10.2 Yes.

10.3 Rely on system clock.

11. Monitoring

11.1 No.

11.2 No. We don't yet have API endpoints.

11.3 No. We don't yet have logging.

11.4 N/A

12. Keystore

12.1 No.

12.2 Looks fine.

13. SSZ

13.1 Yes.

13.2 No.

14. BLS

14.1 It passed v0.8.1. We haven't upgraded to 0.8.2.

14.2 https://github.com/sigp/milagro_bls

14.3 N/A

14.4 No.

15. Chain Start (reference doc)

15.1 We currently only support loading genesis spec (2).

15.2 Keys we generated are not reproducible yet.

16. Configuration & Performance

16.1 Yes. However the mainnet configuration is currently slow for us.

16.2 N/A.

16.3 Compile-time.

17. Building & deploying

17.1 No.

17.2 No.

17.3 No.

17.4 Only Linux is tested. However adding support for macOS and Windows should be easy.

18. Conclusion

18.1 N/A

18.2 N/A

18.3 N/A

18.4 Our life have been significantly easier after spec freeze. Nothing else!

18.5 N/A


Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment