FIP updates with changes since nv24

[BigLep]

Done Criteria

There is an update to the F3 FIP outlining the additions/changes related to the protocol changes as a result of the learnings from nv24 passive testing that will be include in nv25. The set of changes that should be included are:

1. TBD - fill this in

Why Important

There have been non-trivial changes to F3 based on the learnings from nv24. These should make them back to the FIP for visibility to the community, especially since these changes will be shipped as part of nv25.

While we don't expect anyone to care too much about the details, this is about giving visibility into what's changing and following the standard that we'd want any contributing group to follow.

User/Customer

1. Network upgrade scope reviewers
2. Future f3 implementers

Notes

[BigLep]

@masih or @Kubuxu : can you please help fill out the done criteria with the list of things we should include in the FIP update? I'm hoping to capture those now so we can have @Stebalien eyeball it to keep us honest.

Let me know if you disagree, but I'm viewing this FIP update work as procedural requirement for bundling the new changes in the nv25 network upgrade.

[masih]

On my plate here are the changes since nv24 that might be worth bubbling up to the FIP:

• A dedicated timeout multiplier for QUALITY phase: Introduce an explicit delay for QUALITY phase #785
• Propagation of ECChain as their hash in GMessages, and discovery via a separate chain exchange protocol: Hash common fields for message propagation #792
  This item is a big one. More specifically, the protocol changes are:
  * Chain propagation as a separate topic, where mesages contain: instance + chain.
  * Validation of messages on this topic.
  * Rebroadcast strategy for messages on this topic.
  * Partial GMessage validation and how fulfilled messages are fully validated before being fed back to GPBFT.
  * The message buffering mechanism both in Chain Exchange and partial message management.
  * Changes in EChain key calculation across core gpbft

Apart from the last item listed above the core gpbft is unchanged. Of the items listed above, the first one seems like something we should include in the FIP. I am not sure about the rest.

@Stebalien thoughts?

[Stebalien]

Ideally a FIP would include sufficient implementation for an implementer to go ahead and implement the FIP. In practice, there are usually details that get left out but, IMO, we should still strive for this. We absolutely do need to include everything that the community might want to discuss/debate (anything relevant to security, incentives, etc.). This is a bit simpler for actors changes because the actors are effectively a part of the spec so details matter if and only if they're relevant for discussion, but protocol decisions need to be documented fairly thoroughly. Although I'll admit we tend to fall well short of our ideals here.

Honestly, I think everything on that list should to be documented unless we can argue that it really is an implementation detail. Something is an implementation detail if:

1. An independent implementation can take a different approach while remaining compatible with the reference implementation.
2. An independent implementer can "fill in the details" without having to solve any hard problems. I.e., if the problem boils down to "it's just code".

[BigLep]

I think that's a good lens to look at things with @Stebalien .

I'll admit we tend to fall well short of our ideals here

It's hard to pay off sins of the past. I hope we can do it right going forward and that we use this as an opportunity to practice :)

[masih]

I'd be happy to update the FIP with items I listed above, and hope that we can look back at FIP-0086 as one of the better examples of "What a sufficiently detailed FIP should be like" 👍.

@BigLep a small heads-up in terms of timelines: updating the FIP with all the changes introduced as part of #792 and getting it through review could easily sink a week.