ChainSafe / ChainSafe/lodestar
Holesky Retro Features: Introduce mechanisms to force Lodestar to be on a minority chain
- Dominant language
- TypeScript
- Stars
- 1.4k
- Forks
- 483
- Avg merge
- 1d 18h
- Merged PRs (30d)
- 156
Description
### Problem description
During the recent event of Holesky, we spent a lot of time to force Lodestar to follow the correct fork. Would be great if we can add flags/apis such that fork choice can be intervened.
#7500 allows certain blocks to be blacklisted and thus never to be stored in fork choice. However it would be great if there are more tools on hand to allow us to influence more over fc decision making in future events.
### Solution description
Some ideas:
- Whitelisting blocks: Force LS to follow any fork that contain the whitelisted blocks
- A flag to disable optimistic sync
- An idea raised on discord [link](https://discord.com/channels/595666850260713488/598292067260825641/1344058397527506964) that introduces a post endpoint to allow LS to temporarily track and reorg to a peer specified by enr for limited time.
### Additional context
_No response_
Contributor guide
Research direction
Review the block-blacklisting mechanism proposed in #7500 and compare it with the whitelist, optimistic-sync flag, and ENR-targeted endpoint ideas listed here. Define which fork-choice intervention mechanism is in scope and what behavior would demonstrate that Lodestar can follow or reorg to the intended minority chain; no files or tests are named in the issue.
Written by the indexing model from the issue text.
Assessment
- Tech stack
- typescript
- Domain
- backend-api-design, blockchain
- Issue type
- Feature
- Difficulty
- 5/5
- Estimated time
- Over a week
- Activity status
- Stale
- Clarity
- Needs clarification
- Newbie friendliness
- 25/100