ChainSafe / ChainSafe/lodestar

Holesky Retro Features: Introduce mechanisms to force Lodestar to be on a minority chain

Open
#7,504 4 comments 3 reactions 0 assignees View on GitHub
meta-discussion meta-feature-request prio-high
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

Open the contributing 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

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.