Join GitHub today
GitHub is home to over 31 million developers working together to host and review code, manage projects, and build software together.Sign up
Testnet MVP #96
General idea is to switch
Further, the idea is to introduce a management layer that contains logic for dealing with retrying requests and coordinating peer scoring. Basically, the attestation and block pools signal the hashes they need and a separate layer decides on the logic to fetch these from the peer layer (how many concurrent requests, when to retry the same block). When blocks arrive, either from broadcasts or requests, they should flow into the pool the same way.
When joining the testnet, client will be behind. We will regularly restart the testnet in the beginning, thus we primarily need to have the capability to catch up by "full sync" - downloading all blocks. The other case where blocks are needed is when an attestation or block is received, and the dependent blocks are not (lost in translation, missing history, unknown fork etc)
After validating or proposing blocks, these will be (naively) gossiped all other participants so they can count votes and decide on forks. The most simple implementation idea seems to be to publish attestations with a single signature, then aggregate lazily as needed (for example when proposing a block).
When switching to
Forks start with the latest finalized block and build a tree of possible futures from there. The idea is to manage known blocks and attestations as a collection, and take action to fill out that collection as needed.
There are many race conditions that all need to be handled gracefully, and the code should have room to modify the strategy for handling these:
One problem to consider is that of worst case performance, in case of malicious blocks being posted by validators (for example, lots of unviable forks / blocks causing data structure and network traffic growth)
Adding and removing validators is somewhat in flux, so for now the plan is to not use the ETH1 contract for this feature. Initially, we'll just publish JSON files with validator data (priv key etc) and manage overlap socially. The majority will likely be used in pre-configured beacon nodes running on a server, while some will be reserved for developers to play with.
Potential issues include two people running the same validator - this is a feature as it will help us discover issues when this happens (for example if we receive an attestation signed by our own key that we did not send, this is a warning sign that the private key is being reused).
We'll initially deploy one or more boot nodes on a server, each hosting a number of validators. The general idea is to restart the testnet frequently. People wanting to connect will get genesis and validator information from the server via.. whatever (http listing).
Don't wanna run a big network just yet
The general idea is to follow spec releases by updating every time there's a new upstream release.