Notify AvalancheGo Of Our Latest Tip

[samliok]

// Notify the VM of the currently preferred block.
//
// This should always be a block that has no children known to consensus.
SetPreference(ctx context.Context, blkID ids.ID) **error**

I think before we were thinking of calling SetPreference inVerify on the AvalancheGo side due to some weird subnet evm/coreth usage. But given SAE is shortly coming we don't need to worry about this anymore.

https://github.com/ava-labs/avalanchego/blob/1bda65d2614757857f8821812e64cd98af76defe/snow/engine/snowman/block/vm.go#L40

Instead, SetPreference should be called on the block we intend to build on, even if we are not the block producer. In practice, this is always the latest simplex block (i.e., the highest-sequence block that we have notarized or finalized).

A good place to call SetPreference is when we advance the round, since we already have either a notarization or a finalization for the new preferred block. This approach also preserves the invariant that:

This should always be a block that has no children known to consensus.

When we advance the round, we have not yet entered the new round, meaning no child blocks could have been processed. Therefore, the newly preferred block cannot have any known children in consensus.

This means we would need to update our Simplex api & EpochConfig to include some interface that would notify AvalancheGo of our new preference.

Maybe something similar to

type PreferenceNotifier interface {
    // SetPreference is called when consensus advances a round due to a notarization/finalization.
    // It notifies the callee that `block` is the preferred block to build upon.
    SetPreference(ctx context.Context, block simplex.Block)
}

[yacovm]

But we only need to set the preference in order to either verify or build a block, so why can't we call set preference in the avalanchego side right before we verify or build a block?

[yacovm]

also, a node may be the only node that notarizes a block and the rest time out on it. If we set the preference once we move to a new round then we will need to set the preference "backwards" once we realize our mistake in setting the preference before.

[samliok]

But we only need to set the preference in order to either verify or build a block,

Yes, SetPreference is used by the BlockBuilder but it is also used by the mempool to notify us if we should be expecting a new block. As Stephen explained to me, SetPreference simply notifies the VM what our node expects to build from(post SAE). This means in our current code if we are setting the preference during verify, we could be setting the preference for blocks that are not preferred since replication could give us blocks out of order.

improperly set it during replication.

also, a node may be the only node that notarizes a block and the rest time out on it. If we set the preference once we move to a new round then we will need to set the preference "backwards" once we realize our mistake in setting the preference before.

I'm pretty sure it's fine to re-set the preference, aka "go back". Once we receive a new notarization that updates our highest known block then we can just call set preference on that.

[yacovm]

This means in our current code if we are setting the preference during verify, we could be setting the preference for blocks that are not preferred since replication could give us blocks out of order.

If we are replicating then we are behind the majority, and therefore it matters not on top of what block we build, because we anyway cannot progress the chain because we don't have the latest state/block.

Moreover, while we replicate blocks out of order, we verify them in-order.

I'm pretty sure it's fine to re-set the preference, aka "go back". Once we receive a new notarization that updates our highest known block then we can just call set preference on that.

If it's fine to reset the preference to an older block, then we should be able to do that by verifying a block that is a sibling block.

If we need to reset the preference to an older block, that's because one of the two reasons:

• We need to verify a block that builds on top of the older block
• We need to build a block that builds on top of the older block

I think that either way we can just set the preference in the avalanchego side, right before we build the block or verify the block.

Why can't we?