Exploring Eth2: Previous Attesters
In the beacon chain spec, the chain is justified when at least 2/3rds of the active validating balance attests to the same target epoch. Simple enough, but there’s a couple of little quirks that are easy to miss.
Checkpoint Sync - What If Infura Is Hacked?
One of the common concerns people raise about checkpoint sync is the risk that someone might hack Infura and return malicious initial states causing nodes to sync and be stuck on the wrong chain. Given users usually don’t verify the initial state and Infura is currently the only publicly available service supplying initial states, there is certainly some risk there but how concerned should we really be?
Checkpoint Sync Safety
Apart from being awesomely fast, checkpoint sync also exists to ensure that you can safely sync despite the limitations of weak subjectivity. The initial state you use is considered trusted - you are telling your beacon node that this state is the canonical chain and it should ignore all others. So it’s important to ensure you get the right state.
Weak Subjectivity Checkpoints Have Failed
Let’s just admit it, weak subjectivity checkpoints have failed…
Ethstaker Checkpoint Sync
Recording of my talk on Checkpoint Sync and Weak Subjectivity at EthStaker’s gathering as part of DevConnect 2022.
JSON Type Definitions
In Teku, we’ve come up with a new way to both serialize/deserialize objects to JSON and generate OpenAPI documentation from the same declarative source. This significantly reduces the amount of boiler-plate code we have to write and also avoids a lot of bugs where the generated JSON diverged from the OpenAPI.
Remote Pairing Resources
Bookmarking some resources for remote pairing I’ve recently stumbled across but don’t have time to look into right now.
So Long Wordpress
After far too many years of not getting around to it, I’ve finally migrated this blog off of WordPress. It now uses Hugo to statically generate the site.
Exploring Eth2: Stealing Inclusion Fees from Public Beacon Nodes
With the merge fast approaching, all beacon chain nodes will need to run their own local execution layer client (e.g. Besu or Geth). For validators who have just been using Infura for eth1 data so far, that means some extra setup and potentially more hardware (mostly disk). To avoid this, some people are considering going the other direction and not running their own beacon node either, just running a validator client against a public beacon node API like Infura. While this is possible, it’s extremely likely to result in reduced rewards for a couple of reasons.