helios
helios copied to clipboard
a16z
check checkpoint age when starting up
When Helios starts, it needs to fetch a recent beacon blockhash to use as the weak subjectivity checkpoint. If this blockhash is too old (under worst case conditions too old is ~14 days), it is possible for an attacker to trick Helios into following the wrong chain. While this attack is hard to pull off (requires millions in capital to fill the staking deposit and withdrawal queues), we should still check the checkpoint age, and if it is too old, throw and error and tell the user how to fetch a good blockhash.
To do this, use the bootstrap fetched here and check bootstap.header.slot's age using the expected_current_slot and slot_timestamp methods in Consensus.
If it is older that 14 days, throw an error (consensus errors can be found here)
If this blockhash is too old (under worst case conditions too old is ~14 days)
@ncitron Is the age for the worst case condition static and always be ~14 days?
From my quick skim through this post it looks it varies and depends on validator set, entry and exit rates...things that might be difficult for helios to attain without having access to the consensus state.
Yeah it does change, but looking at the bottom chart, it seems like 14 days is a good metric since it increases with the validator set size. Even at 250k its 2 weeks, and Ethereum mainnet has 500k validators. It does bring up a good point that this should be configurable. @0xModene can we add it as a network level config options in config/src/networks.rs instead of hardcoding it to 14 days?