owned this note
owned this note
Published
Linked with GitHub
# ETH 2.0 Interop Survey
https://gist.github.com/protolambda/7301987850708d4b0469982da17422f2
### 1. General
- **1.1** v0.8.2
- **1.2** Yes
The following questions are up for discussion:
- **1.3** No.
- **1.4** Start with libp2p and work our way up the stack all the way to application layer / consensus
- **1.5** Dependencies whose code needs writing
- **1.6** Testing / polish while community is pushing for release
### 2. Networking Essentials
- **2.1** Yes. We rely on the Go deamon for the lower-level protocols and we have a compliant implementation of the latest high-level ETH2 spec.
- **2.2** Yes.
- **2.3** We rely on static node lists.
- **2.4** Each peer connects to a pre-determined list of bootstrap nodes. After establishing a connection, the dialing peer opens a `/eth2/beacon_chain/req/hello/1/` stream as specified in the spec and awaits a response from the other peer on the same stream.
- **2.5** Everything supported by the Go daemon.
- **2.6** Yes.
### 3. Syncing
- **3.1** We are currently using requests from the older version of the spec. We expect to have switched to the `/eth2/beacon_chain/req/beacon_blocks/1` request before arriving at the interop lock-in.
- **3.2** Yes.
- **3.3** Yes, we can start from a known good state.
- **3.4** We plan to use batch requests for both `/eth2/beacon_chain/req/beacon_blocks/1` and `/eth2/beacon_chain/req/recent_beacon_blocks/1/`.
- **3.5** We employ a full sequential sync, combined with the ability to monitor the network for recent attestations and to selectively sync missing blocks in backwards fashion (this is a recursive process that starts from the latest blocks and progresses towards the earlier ones).
- **3.6** Not yet.
### 4. State Storage
#### (_Out of interest, no hard requirements_)
- **4.1** We store only full copies of the state.
- **4.2** We store the state on each epoch transition.
### 5. Attestation Aggregation
- **5.1** We support only the most basic aggregation strategy using a single GossipSub topic.
- **5.2** No.
### 6. Fork Choice
- **6.1** No
- **6.2** Unoptimized spec
### 7. Spec-Tests / Transition Consensus
- **7.1** Do you pass the following spec tests? If not, in which configuration and what tests?: (TODO)
- Block operations -> WIP
- Epoch processing -> WIP
- Sanity tests -> WIP
- BLS integration -> yes (minimal and mainnet)
- SSZ_static -> yes (minimal and mainnet)
- Shuffling -> yes (minimal and mainnet)
Also pass SSZ_generic
- **7.2** 0.8.3
### 8. Block Propagation (Strategy)
- **8.1** No.
- **8.2** Our block propagation is immediate and fully naive.
### 9. Attestation Propagation (strategy)
- **9.1** Our attestation propagation is immediate and fully naive.
### 10. Block Proposals
- **10.1** No. It wouldn't be a problem for us to implement https://notes.ethereum.org/VpUNqtrgRvqogY38bmKWpA
- **10.2** No.
- **10.3** We don't have a sophisticated clock syncing strategy yet.
### 11. Monitoring
- **11.1** Do you implement the [proposed Metrics](https://github.com/ethereum/eth2.0-metrics/blob/master/metrics.md) (TODO)
- **11.2** Not yet. We are working on a JSON-RPC interface that may be ready for the interop lock-in.
- **11.3** We have a [flexible in-house library](https://github.com/status-im/nim-chronicles) that can log to JSON and other formats.
- **11.4** No other APIs come to mind. Here is a list of the command-line switches supported by Nimbus:
```
The following options are supported:
--logLevel=LogLevel : Sets the log level
--network=string : The network Nimbus should connect to. Possible values: testnet0, testnet1, mainnet, custom-network.json
--dataDir=OutDir : The directory where nimbus will store all blockchain data.
--bootstrapNode=seq[string] : Specifies one or more bootstrap nodes to use when connecting to the network.
--bootstrapNodesFile=InputFile : Specifies a line-delimited file of bootsrap Ethereum network addresses
--tcpPort=int : TCP listening port
--udpPort=int : UDP listening port
--nat=string : Specify method to use for determining public address. Must be one of: any, none, upnp, pmp, extip:<IP>
--validator=seq[ValidatorKeyPath] : Path to a validator private key, as generated by validator_keygen
--stateSnapshot=Option[TypedInputFile[BeaconState, Json, "json"]]: Json file specifying a recent state snapshot
--nodename=string : A name for this node that will appear in the logs. If you set this to 'auto', a persistent automatically generated ID will be seleceted for each --dataDir folder
Available sub-commands:
beacon_node importValidator
--keyfile=seq[ValidatorKeyPath] : File with validator key to be imported (in hex form)
beacon_node createTestnet
--networkId=uint8 : An unique numeric identifier for the network
--validatorsDir=InputDir : Directory containing validator descriptors named vXXXXXXX.deposit.json
--totalValidators=uint64 : The number of validators in the newly created chain
--firstValidator=uint64 : Index of first validator to add to validator list
--lastUserValidator=uint64 : The last validator index that will free for taking from a testnet participant
--bootstrapAddress=string : The public IP address that will be advertised as a bootstrap node for the testnet
--bootstrapPort=int : The TCP/UDP port that will be used by the bootstrap node
--genesisOffset=int : Seconds from now to add to genesis time
--outputGenesis=OutFile : Output file where to write the initial state snapshot
--outputNetwork=OutFile : Output file where to write the initial state snapshot
```
### 12. Keystore
- **12.1** Not yet.
- **12.2** We won't be able to implement the proposal for the interop lock-in because we don't have a suitable scrypt implementation at the moment.
### 13. SSZ
- **13.1** Yes.
- **13.2** We haven't done extensive performance testing yet, but the ETH2 test suite executes quite quickly for us (both minimal and mainnet).
### 14. BLS
- **14.1** Yes.
- **14.2** https://github.com/status-im/nim-blscurve
- **14.3** https://github.com/apache/incubator-milagro-crypto-c
- **14.4** Do you have a benchmark of verify-aggregate bench speed of 128 participants, same message being signed. Called from client. (TODO)
### 15. Chain Start ([reference doc](https://github.com/ethereum/eth2.0-pm/issues/60))
(TODO)
- **15.1**
1. A kickstart (plain `(balance, pubkey, witdraw_credentials)` tuple)
4. A series of deposit contract logs from an Eth 1.0 oracle, from a mock/test service
5. A series of deposit contract logs from a real Eth 1.0 node?
6. A genesis constructed from a (slow and long) stream of deposit log events?
7. A plain prepared genesis BeaconState object from SSZ? (json really but can add SSZ)
In particular, we do not validate eth1 deposits
- **15.2** Yes
### 16. Configuration & Performance
- **16.1** Yes.
- **16.2** With the right hardware, we have some successful tests with 3 seconds slots in a 16 shards, 1000 validators network.
- **16.3** We support only compile-time configuration.
### 17. Building & deploying
- **17.1** Yes.
- **17.2** Yes.
- **17.3** Yes, for locally running testnets. We have semi-automated deployments for testnets running a server cluster with 10 machines.
- **17.4** Linux, Mac, Windows (in order of frequency of testing).
### 18. Conclusion
- **18.1** -
- **18.2** -
- **18.3** -
- **18.4** -
- **18.5** Network monitoring tools (libp2p, eth2)