# ETH 2.0 Interop Survey # Trinity's Feedback 🔱 Survey `v1.0.0`. The purpose of the following questionnaire is to understand and identify the current progress and status of each client implementation. The results of this survey will allow us (Whiteblock, EF research, and open community) to prioritize and provide appropriate support where necessary. With this in mind, we encourage honest, forward and descriptive responses. Feedback for alternative approaches is welcome. We can also ramp up contact / technical resources to help teams on the issues with the worst interopability prospective. The survey results will be processed in two forms: - A summary table, similar to the common browser-compatibility format. - A long-form comparison which describes content which cannot be more easily expressed within a table. Based on these results, we will present a refined set of requirements for our upcoming interop-lockin event, along with a short-track proposal which identifies the requirements for a cross-client testnet. ## Instructions Please kindly list your answers in a separate markdown document. Do not copy over the questions themselves, just keep the numbering, along with the survey version number (questions may be clarified/extended based on feedback). If questions are unclear, please reach out through the survey distribution channel. ## Questions For each topic, please answer the question in one or two sentences. Please elaborate on your status or approach if you differ significantly from any of the example approaches. ### 1. General - **1.1** What is the latest version of the specification which your client currently supports? - v0.8.2, will be "offically" on v0.8.3 by interop - **1.2** Is `v0.8.2+` targeted as interop version? If not, which version do you suggest? - yes - **1.3** Are any features or components particularly difficult to update, and on what versions are these currently? - we good - **1.4** In terms of interop, do you have any suggestions? - rome wasn't built in a day... start small and build up to greatness - **1.5** What has been your primary bottleneck in development? - optimizing Python but this was our choice - taking on a libp2p implementation w/ little prior work - **1.6** What do you anticipate to be the primary bottleneck in the future? - performant state transition function - unclear if attestation load will be "light" ### 2. Networking Essentials - **2.1** Does your client currently implement libp2p? If not, what subset is working? - Yes - **2.2** Do you make use of a libp2p daemon approach? - We did, but changed to py-libp2p now. - **2.3** How does your client become aware of its peers? Static node list, DHT/discv5, etc. - Static node list - **2.4** By which process does your client establish a handshake with its peers? - The `Hello` Req/Resp described in networking spec - **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. - yes ### 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? - yes - **3.2** Do you support a full sync from genesis after the network is running for a longer period of time? - not yet - **3.3** Can you bootstrap syncing with a copy of sync data? - not yet - **3.4** Do you make use of batch-requests for blocks? If so, what does your batched block request look like? - not yet - **3.5** Do you have any particular sync strategy? (Full sequential, skip-ahead, or some hybrid approach?) - no - **3.6** Do you implement any pruning mechanism? (not necessary for initial interop) - no ### 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 * Support 2. Segmented/chunkfied state * Not support 3. Full copies * Support 4. Other - **4.2** What is your storage approach like? 1. Store on X interval 2. Store every slot 3. Store every block 4. Other Now we store every slot, but have a WIP PR about only storing every state of epoch boundary. ### 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). - yes - **5.2** Do you support alternative (more advanced) aggregation strategies? - no ### 6. Fork Choice - **6.1** Do you test fork choice? In what kind of context(s) do you test it? - we do test it - mock out a chain and then run fork choice and ensure we get the expected head - **6.2** What is your implementation type like: - Unoptimized spec - yes, very little optimization beyond this - Cached spec-like - Reduced form (shortcut 1-child nodes) - Stateful structure - Other ### 7. Spec-Tests / Transition Consensus - **7.1** Do you pass the following spec tests? If not, in which configuration and what tests?: - Block operations - Epoch processing - Sanity tests - BLS integration - SSZ_static - not yet (but integrated py-ssz into pyspec fuzzing) - Shuffling - we pass all tests w/ minimal config, we seem to pass tests for mainnet config but sketchy bc it takes a long time to run - **7.2** What spec version are you currently targetting for tests? - v0.8.3 ### 8. Block Propagation (Strategy) - **8.1** Do you follow the network spec: verify the proposer signature before relaying a block? - yes - **8.2** And if so, do you transition state completely, or just enough to know the proposer index? - just enough to know the proposer index - **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? - no - **8.3.2** Which blocks do you process first (i.e. what gets priority)? - treat them all equally - **8.3.3** Do you detect spam? (i.e. drop peers with high amounts of invalid blocks) - not yet(a rather low priority task to us ATM) - **8.3.4** Is there any security check for double voting on the same block height before propagation? - no ### 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? - no, we currently validate FFG voting/shard number/attestation slot/crosslink but do not check whether the `beacon_block_root` is in our database or not. will add the check ### 10. Block Proposals - **10.1** Do you fill grafitti with any debug data? - No - What do you think of thus grafitti debug format proposal, described [here](https://notes.ethereum.org/VpUNqtrgRvqogY38bmKWpA)? - **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)? - Not yet - **10.3** What is your clock syncing approach? - no clock syncing approach yet. assume the clock is synced ATM ### 11. Monitoring - **11.1** Do you implement the [proposed Metrics](https://github.com/ethereum/eth2.0-metrics/blob/master/metrics.md) - No - **11.2** Do you provide a API endpoint for: - Sync status - Current chain head (from node perspective) - A series of blocks - No - **11.3** What do you use for logging? (e.g. custom JSON, library XYZ) - Python `logging` package - **11.4** Provide links to any misc. API implemented by the beacon node. ### 12. Keystore - **12.1** Do you use anything like the Eth1 keystore format? - we will follow the latest proposed 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? - is it required for interop? can we just use simple bytes to represent privkey for interop? - haven't taken a deep review yet, but will do. - we should also talk with some hardware wallet vendor. ### 13. SSZ - **13.1** Do you have SSZ v0.8 (hash-tree-roots with stable depth, bitlists/vectors) implemented currently? - Yes - **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?) - Now we cache the intermediate Merkle leaves, but it's still really slow to iterate the large list. ### 14. BLS - **14.1** Do tests pass for version v0.8.2+ (little endian domain bytes) - **14.2** What BLS library do you use? (provide link) - https://github.com/sigp/milagro_bls - **14.3** Do you implement a BLS wrapper? (provide link) - https://github.com/ChihChengLiang/milagro_bls_binding - **14.4** Do you have a benchmark of verify-aggregate bench speed of 128 participants, same message being signed. Called from client. - Takes 23ms on my 2.5 GHz Intel Core i7 laptop. ### 15. Chain Start ([reference doc](https://github.com/ethereum/eth2.0-pm/issues/60)) - **15.1** Do you support loading: 1. A kickstart (plain `(balance, pubkey, witdraw_credentials)` tuple) - Yes 3. A list of deposits, with incremental proofs (genesis spec) - No 4. A list of deposits, with proofs all to the same deposit root. - No 5. A series of deposit contract logs from an Eth 1.0 oracle, from a mock/test service - No 6. A series of deposit contract logs from a real Eth 1.0 node? - No 7. A genesis constructed from a (slow and long) stream of deposit log events? - No 8. A plain prepared genesis BeaconState object from SSZ? - From yaml - **15.2** For testing genesis, do you generate keys in advance? And/or in a predictable reproducible manner for debugging? - Yes, yes. ### 16. Configuration & Performance - **16.1** Do you meet minimal configuration in respect to processing performance; 6 seconds with 8-slot epochs? - Similar; our current configuration is with 6 seconds with 4-slot epochs. - **16.2** Are there alternative variations / easier parameters that work particularly well for your testnet(s)? - Yes. https://github.com/ethereum/trinity/blob/f801accfd2845661bac2b6fe71cf4a9303646c8f/eth2/beacon/state_machines/forks/xiao_long_bao/configs.py#L6 - **16.3** Do you load configuration on compile-time or run-time? - compile time (we have on loaded in runtime and one hardcoded) ### 17. Building & deploying - **17.1** Do you provide a build script for the client? - Not yet but we can do it. - **17.2** Do you use a form of containerization? E.g. Docker? - No - **17.3** Have you automated testnet deployments? - Only deployment on localhost - **17.4** What platforms/architectures are supported? - Tested on mac OS ### 18. Conclusion - **18.1** Is there anything that this questionnaire did not cover? - it was very thorough :) - **18.2** Any miscellaneous suggestions? - **18.3** Are there any bottlenecks into which we may not currently have visibility? - not a bottleneck for now at all, but I'm not sure if the phase 1 -> phase 2 protocol change would go smoothly; but it needs to actually implement it to know. - a clear timeline of BLS standard? (not sure about audit time) - **18.4** What can we do to provide you with adequate support? In otherwords, *how can we make your life easier*? - **18.5** In terms of tooling, what are we currently lacking? - network monitor/stats, hive for eth2 - not tooling, but it's better to have stable eth1 light client