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

Abstract common consensus functions and consensus interface #9405

Conversation

adlrocha
Copy link
Contributor

@adlrocha adlrocha commented Oct 3, 2022

Related Issues

#1

Proposed Changes

This PR extends the consensus interface in order to prepare it for the implementation of other consensus algorithms. It also extracts from FilecoinEC common logic that will be shared by all consensus implementations.

  • Extracted block checks and validation to common functions.
  • Extracted ValidatedPubSub as a common function.
  • Abstracted block signature and verification, and the validation of blocks and their headers.
  • Extracted compute_state as common code for all consensus algorithms.
  • Abstracted the application of rewards.

Integration of the interface

To illustrate how this interface can be integrated for the implementation of alternative consensus algorithm, I will share how I imagine it to work and be implemented for Mir:

  • CreateBlock runs the block proposal logic for Mir in Lotus. In CreateBlock Lotus validators pull unverified messages from the mempool, and send them to Mir for ordering. Once the ordered batch is output by Mir, a new Filecoin block is assembled and broadcast through GossipSub to the network.
  • Validators are not subscribed to the block gossipsub topic, as they already receive all the information about new blocks through Mir.
  • Other Lotus nodes in the network will receive updates about new blocks being proposed by Mir through the Gossipsub block topic. When a new block is received, GossipSub triggers ValidateBlockHeader before delivering the block to the node. If the validation succeeds, the block is passed to the syncer which runs ValidateBlock to perform a full block validation to determine if the block is valid and can be executed. As part of these verifications, VerifyBlockSignature may be called.
  • Finally, the execution of the block triggers the consensus-specific RewardFunc that parametrized how should block rewards be distributed among validators.

@adlrocha adlrocha marked this pull request as ready for review October 3, 2022 08:25
@adlrocha adlrocha requested a review from a team as a code owner October 3, 2022 08:25
@jennijuju jennijuju added this to the FEVM BuilderNet milestone Oct 4, 2022
Copy link
Contributor

@magik6k magik6k left a comment

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

First really quick review pass, will do one more careful one tomorrow;

Generally everything looks good, should be easy to land this.

chain/consensus/compute_state.go Show resolved Hide resolved
@adlrocha
Copy link
Contributor Author

Closing in favor of #9481 that already targets master as experimental/fvm-m2 will soon be deprecated.

@adlrocha adlrocha closed this Oct 13, 2022
@adlrocha adlrocha deleted the adlrocha/cns-iface-fvm-m2 branch October 14, 2022 07:08
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
Projects
None yet
Development

Successfully merging this pull request may close these issues.

3 participants