The Infura and Teku teams have teamed up to produce a killer feature for Ethereum 2.0 that significantly reduces the time required to sync the Eth2 clients required to validate on Proof of Stake Ethereum. In this piece, we’ll go over why that’s important, how it works and how it will contribute to the network resilience for Ethereum 2.0 Beacon chain and beyond.
https://www.youtube.com/watch?v=ce9uVRl23zI
Sync Time
The Beacon chain has been running successfully for half a year, and as it matures we’re finding new ways to make it better and stronger. One of those ways has to do with the initial sync time of the client. The initial sync time refers to the time it takes a client to find peers on the network and download the historic network activity. Once the new client has downloaded and processed that data, it will have an accurate view of the network and can start processing new blocks.
It may seem unusual that any historical data is generated at all on the Beacon chain. After all, there aren’t any transactions being sent. However, the Beacon chain is generating information: validator activity. Validator activations, attestations, proposals, slashings—all of this adds to the amount of data being carried by the Beacon chain.
The Beacon chain sync time is not as challenging as an Ethereum 1.0 full sync, but it still can take hours or sometimes days for a new client to sync. The Barcelona Supercomputing Center published a paper looking at sync times across all Ethereum 2.0 clients. A diagram from their paper is shown below:
Chain syncing can take significant time on Ethereum 2.0 (source). However, Teku’s --initial-state reduces this ever-increasing time to mere minutes.
As the chart shows, the traditional sync time will only become longer the more the chain grows. However, Teku’s --initial-state reduces this ever-increasing time to mere minutes. How is this possible?
Finalization and Weak Subjectivity
Ethereum 2.0’s consensus mechanism, Proof of Stake, offers a special benefit for syncing: finality. When the Beacon chain finalizes an epoch, it’s taking a snapshot of all the activity and balances on the network. That snapshot, called a checkpoint, might as well be its own genesis block. The network is not going back.
There is a security weakness in finality, though. From the Teku docs:
If ⅓ of validators withdraw their stake and continue signing blocks and attestations, they can form a chain which conflicts with the finalized state. If your node is far enough behind the chain head to not be aware that they’ve withdrawn their funds, the exited validators can trick you into following the wrong chain.
Well-behaved validators who have successfully and properly exited the chain can sell their private keys on the black market to a malicious actor. (There is no financial disincentive for them to do this as their funds have safely exited the protocol). That malicious actor can then amass enough keys to find validators coming back online after quite a bit of time and commit a Sybil attack. See Meredith Baxter’s excellent explanation below:
https://www.youtube.com/watch?v=Oz3flfj50Ig&t=341s
What’s the solution? Weak Subjectivity Checkpoints. These are pointers to a relatively recent network state confirmed by a majority of actively-staked validators. If a node with relatively scarce network information wants to sync to the Beacon chain, they can start with the genesis block and the weak subjectivity checkpoint. As the node communicates with other peers, they can check to make sure they haven’t been led astray by making sure they end up with the correct network state reflected in the weak subjectivity checkpoints.
For more on Weak Subjectivity Checkpoints, please see Meredith Baxter’s full demo or read Alex Stokes' explainer Twitter thread.
The Teku client has used weak subjectivity checkpoints to safely speed up the process of syncing a new client. Teku has an --initial-state flag which accepts a recent network state generated within the weak subjectivity checkpoint range. You can see it in action in Adrian Sutton’s video at the top of this article or in Meredith Baxter’s full demo here.
But where does one get these checkpoints? If you already have a synced client and you’re migrating, you can make your own. But how about for newcomers, where we provide this state safely and at scale? That’s where Infura comes in.
Infura’s Ethereum 2.0 Offerings
Infura offers its users free Ethereum 2.0 APIs which combined with Teku’s --intial-state option allows for an almost immediate full sync of a new client. We’ll walk through the steps to show how it works.
First, sign up for a free Infura account. Infura offers a tiered system for clients requiring advanced features, but the free account is great for folks running a single validator.
Next, click the Eth2 icon on the left-hand menu on your dashboard and click “New Project,” circled in red below:
Create a project name and copy the HTTP endpoint provided. Notice that Infura also provides endpoints for not just Eth2 mainnet, but also testnets! See the screenshot below:
Next, make sure you have Teku properly installed and configured on your machine. We’re going to start Teku with the --initial-state flag specifying our Infura Eth2 API endpoint, specifically the “get state” at /eth/v1/debug/beacon/states/finalized. Putting it all together, our entire Infura API endpoint looks like:
https://INFURA_PROJECT_ID:[email protected]/eth/v1/debug/beacon/states/finalized
Once that’s ready, you can start your Teku client with:
teku --network [MAINNET / TESTNET_NAME] --initial-state https://INFURA_PROJECT_ID:[email protected]/eth/v1/debug/beacon/states/finalized
Teku will load the most recently finalized checkpoint and then will work to find peers. Teku will ping each discovered peer to validate the finalized checkpoint provided by Infura is considered to be correct. Peers that disagree on this finalized checkpoint will be disconnected. An early warning sign that an initial state is incorrect is difficulty finding peers to connect to. Once enough peers are validated, Teku can download the rest of the chain and quickly catch up to be fully synced.
Another nice feature is that, if you restart your synced Teku client with the --initial-state flag, if Teku realizes it has a database, it will not restart the sync process and will skip over the flag. (This is great if you have it setup as a daemon service running and restarting on its own.)
Those concerned about the finalized state being provided by Infura should know the Ethereum 2.0 network provides safeguards. Specifically, block root hashing allows us to check the initial state we get from Infura, but our client could still be misled through a Sybil attack, arranging a large setup of peers it will connect with that have the same incorrect state. To guard against this , you should compare the initial state checkpoint’s hash provided by Infura (or the head block root once you’re synced) with a public block explorer or another source to double-check.
Bottom line: everyone should always check they wound up on the right chain regardless of how they sync.
Next Steps
Capitalizing on finalization and weak subjectivity checkpoints will only become more important to user experience and safety as we get closer to the Eth1 / Eth2 merge and the network state continues to grow. Even though the sync time will increase with network state size, this Checkpoint Start time will stay relatively stable.
Try it for yourself and let us know what you think!