ava-labs / ava-labs/Simplex

Block building in the presence of epoch change

Open
#515 0 comments 0 reactions 0 assignees View on GitHub
Dominant language
Go
Stars
22
Forks
4
Avg merge
2d 14h
Merged PRs (30d)
34

Description

In our version of Simplex, a node only builds a block in one of two cases:

1. Transactions exist in the mempool of the VM and a block should be built to contain them
2. The block builder detects that an epoch change should occur, or is ongoing, so it builds a block to initiate or drive forward the epoch change.

This means that a block is not built if there is nothing in the mempool or there is no need to initiate an epoch change.

For (1), if a node that is not designated as the leader of the current round detects that transactions exist in the mempool for too long without a block being built and disseminated, it starts lobbying to notarize an empty block, which should make the nodes move to the next round and this will designate a new leader.

For (2), https://github.com/ava-labs/Simplex/pull/514 introduces a mechanism in which a node that is not the leader of the round also starts lobbying to notarize an empty block if a block isn't being built and disseminated for too long and the previous block indicates that there is an ongoing epoch change, or that the previous block doesn't indicate that, but an epoch change should be initiated.

Completing the epoch change requires gathering approvals from at least a quorum of nodes of the next epoch.

However, if there are not enough approvals to collect because the nodes of the next epoch are not available yet (e.g they are still syncing the P-chain) it would mean that blocks will be built indefinitely until then.

We could make the epoch change and the mechanism introduced in (2) smarter and only build a block or expect one to be build in case we know that we can drive forward the approval collection, but that's a problem for the future.

Contributor guide

No contributing guide indexed for this repository

Research direction

Start by tracing the block builder's empty-block lobbying behavior and the epoch-change approval collection described in the issue. Examine how unavailable next-epoch nodes affect approval progress, then define and verify behavior that avoids indefinite block building without preventing a recoverable epoch change.

Written by the indexing model from the issue text.

Assessment

Tech stack
go
Domain
distributed-systems
Issue type
Bug
Difficulty
5/5
Estimated time
Over a week
Activity status
Quiet
Clarity
Needs clarification
Newbie friendliness
35/100

Get new issues in your inbox

A short digest of beginner-friendly GitHub issues.