Let’s just admit it, weak subjectivity checkpoints have failed…

The beacon chain brings to Ethereum the concept of weak subjectivity, so prior to the launch of the beacon chain MainNet it was seen as important to have a solution agreed that would allow users starting a new node to verify the chain they sync’d was in fact the canonical chain.

This was before anyone client had implemented checkpoint sync so the proposal was that the epoch and block root from a point close enough to the chain head that it was within the weak subjectivity period but far enough back that it wouldn’t need to change often (e.g update only every 256 epochs). Since it’s small and doesn’t change often people could easily publish it via all kinds of methods - block explorers could show it, twitter bots could post it, it could even be printed in newspapers. Thus it would be easy for users to find it and they’d have lots of different sources to verify against.

Clients would then sync from genesis and when they got to the epoch in the weak subjectivity checkpoint, they’d check that the block root matches the block they have, thus confirming they sync’d the right chain. If it didn’t match the client would crash and the user would have to either correct the weak subjectivity checkpoint they were providing or delete the current sync and try again, hoping the client wound up on the right chain this time.

Of course, that’s the first major problem with weak subjectivity checkpoints - you can waste days syncing before realising you’re on the wrong chain. Then once you discover that you have to start again but don’t really have anything you can do to avoid the problem happening again.

Somewhat surprisingly though, that’s not the biggest problem with weak subjectivity checkpoints. The biggest problem is that they’re actually extremely hard to find. For a while beaconscan provided an endpoint that would give back the current weak subjectivity checkpoint - no explanation of what it was or how to use it, but at least you could get the value. It appears they silently removed it at some point though. I don’t recall seeing weak subjectivity checkpoints published anywhere else.

In fact, I’m actually having trouble turning up a clear reference of how to calculate the weak subjectivity checkpoint. There is this doc in the specs which says how to calculate the weak subjectivity period, which amusingly basically has a TODO how to distribute the checkpoints. There’s also this doc from Aditya which gives a lot more detail on weak subjectivity periods. I had thought there was some spec for ensuring everyone selected the same epoch to use for the weak subjectivity checkpoint and I thought it was a simple “every X epochs” but I can’t actually find that documented anywhere.

We could fix this - a clearer and/or simpler spec on how to get the weak subjectivity checkpoint could be created (and there is a suggestion of adding it to the standard REST API), we could put pressure on providers to publish those checkpoints and setup twitter bots etc so it was available. Even then, we’d still have a truly lousy user experience with slow sync times that get longer as more blocks are piled on to the beacon chain and that can only retrospectively tell you that you’ve been wasting your time.

So let’s just admit it, weak subjectivity checkpoints have failed. The future is in using checkpoint sync to start from the current finalized state. That minimises sync time and users can realistically take advantage of it today. It’s not perfect, we need more places to provide that state and better ways of validating that the state is in fact the right one, but it’s already more accessible than weak subjectivity checkpoints and has infinitely more users actually using it (ie more than zero). If we can move on from the idea of weak subjectivity checkpoints, we can focus on getting the most out of checkpoint sync in terms of usability and security.