Introducing Go-Opera

Earlier this week, we started rolling out Go-Opera, the most significant network upgrade so far.

Go-Opera radically improves network performance and reliability; compared to the previous Go-Lachesis, some parts of the codebase are completely rewritten and optimized. 

All validators and third-party nodes are invited to perform the upgrade: https://github.com/Fantom-foundation/lachesis_launch/blob/master/releases/v1.0.0-rc.0/upgrade_validator.md

Key highlights in the upgrade:

• Performance-wise, the average TTF (time to finality) will be about 1 second.
• P2P synchronization has become 3 times faster. New nodes joining the network will synchronize significantly quicker.
• Emission of events is more efficient as go-opera generates roughly 2x fewer events per frame.
• Events emitter is now reactive to other events. It will hold off emission of an event for a longer time if the emission of the event will not advance consensus (e.g., when less than 2/3 are online) to avoid the validators spamming themselves. 
• Emission is more efficient (i.e., emission of fewer events while TTF is improved) in case of non-ideal network conditions, such as slow data propagation between nodes.
• All the history up to the point of migration will be squished into a Genesis file, roughly 650-700 MB. 
• To set up a new node after migration, node operators will download this genesis file to start with and won’t need to process previous events.

SFCv3

With Go-Opera, we’re also upgrading the Special Fee Contract (SFC) to v3. The SFC maintains a list of validation stakers and delegators and distributes the rewards.

• SFCv3 has a simpler interface to use than SFCv2.
  In SFCv2, validators and delegations are different entities, and they have different sets of methods to work with.
  For example, validators claim rewards with claimValidatorRewards, while delegators do so with claimDelegationRewards.

  In SFCv3, they both use claimRewards because a validator is also a delegation to itself, and they will use the same functions to work with the new SFC.

• Rewards claiming is simplified. Delegators can claim all the rewards at once rather than calling it multiple times, even if they haven’t claimed rewards for many epochs.
  
• There’s no restriction on when a user has to claim rewards. For example, users no longer need to claim them before undelegation.
• In terms of design, SFCv3 has a simpler interface to communicate with the node. This will allow broad changes to SFC rules in the future without requiring a node upgrade.

What’s next

After all validators are upgraded, we will perform a migration call. The migration will take around one hour, during which no new events will be generated. We will announce the migration date and time in advance.

After the upgrade and migration are completed, users will enjoy as low as sub-second transaction confirmation times, and they will be able to claim all staking rewards with one click.