Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Head input chain offset #175

Closed
Tracked by #246
ranchalp opened this issue Apr 24, 2024 · 5 comments · Fixed by #400
Closed
Tracked by #246

Head input chain offset #175

ranchalp opened this issue Apr 24, 2024 · 5 comments · Fixed by #400

Comments

@ranchalp
Copy link
Contributor

When a participant starts an f3 instance, it needs to determine whether it wants its proposal to contain from baseChain up to the head input chain it locally keeps in EC, or some prefix of it (i.e. offset it by some epochs). Although this may delay latency on the head tipset, it helps reduce latency and reach agreement faster on the EC instance. This is closely related with #173.

@ranchalp
Copy link
Contributor Author

In pair with decision on #173 to wait for 2 epochs from the timestamp on the latest finalized epoch, the participant sets as proposal for the new f3 instance the following:

  • Let $baseChain$ represent the finalized chain up until the latest finalized f3 instance.
  • Let $ECChain$ represent the current heaviest EC chain according to the participant (that extends $baseChain$ by design)
  • Let $e'$ be the epoch at which the participant is starting the new f3 instance (following decision on When to start an f3 instance #173 , $e' >= baseChain.head().epoch + 2$).

Then:

  • If ECChain.head().epoch < e', participant sets its proposal to ECChain
  • If ECChain.head().epoch = e', participant sets its proposal to ECChain[-1] (remove the head tipset, from the current epoch e')
  • ECChain.head().epoch cannot be > e' by design (e' is the current epoch)

@jennijuju jennijuju added this to F3 May 15, 2024
@Kubuxu Kubuxu moved this to Todo in F3 May 16, 2024
@jennijuju jennijuju removed the status in F3 May 22, 2024
@Kubuxu Kubuxu self-assigned this Jun 22, 2024
@anorth
Copy link
Member

anorth commented Jun 25, 2024

I think this is done: it is specified in the FIP so the decision is make. @Kubuxu do you need this issue open to track some implentation task?

@anorth anorth moved this to In review in F3 Jun 25, 2024
@Kubuxu
Copy link
Contributor

Kubuxu commented Jun 25, 2024

We don't have the head offset currently. Looking at the FIP pseudocode, it appears "delete the head always", as I'm assuming CurrentEpoch() is the epoch of the chain head and collecting the chain for HeaviestUnfinalizedChain will return that head.

@anorth
Copy link
Member

anorth commented Jun 25, 2024

It's difficult to be precise with language here. I had interpreted the FIP's use of CurrentEpoch() to mean the one for which new blocks are currently being transmitted but a tipset could not yet be confirmed by a subsequent block pointing to it. This is why it is always deleted.

What exactly do you mean by the epoch of the chain head? Is it the epoch of the blocks currently being proposed? Or the epoch of the tipset to which the most recent possible block points?

@Kubuxu
Copy link
Contributor

Kubuxu commented Jul 4, 2024

What you wrote makes sense.

What exactly do you mean by the epoch of the chain head?

I meant EC Chain head.

Kubuxu added a commit that referenced this issue Jul 4, 2024
Resolves #175

Signed-off-by: Jakub Sztandera <oss@kubuxu.com>
github-merge-queue bot pushed a commit that referenced this issue Jul 4, 2024
Resolves #175

Signed-off-by: Jakub Sztandera <oss@kubuxu.com>
@github-project-automation github-project-automation bot moved this from In review to Done in F3 Jul 4, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
Status: Done
Development

Successfully merging a pull request may close this issue.

3 participants