-
Notifications
You must be signed in to change notification settings - Fork 144
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
Initial Structures for Message - Manager Communication #69
Conversation
* Added chain info struct and new fn
* Added container for decoding pubsub messages * Created new fn for container creation * Added BlockProposer trait
* Renamed chain_info --> block_msg * Corrected export of mod * Removed String in favor for Display * Prefixed dead code with underscore to avoid compiler errors
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Can't really see how exactly this is going to fit in, and not defined in spec but seems like it's on the right track
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Does it not make more sense to have BlockMsg
live under chain_sync
?
I think it would be worth documenting a link to the code the inspired this, will be helpful to know what isn't spec based in the future.
BlockMsg in go-filecoin (chaininfo). Moved into chain_sync |
* Restructured blockmsg to live under chain_sync * Added go-filecoin reference to BlockMsg comment
@GregTheGreek @ec2 ping |
…Safe#69) * feat(cache): generate_post and seal both accept cache dir-path * refactor(trait): remove unused constraints * feat(crate): upgrade to new API * ci(key): cache key should include arch * feat(cache): generate_post and seal both accept cache dir-path * feat(builder): force caller to provide sector cache path
This is a small PR but steps towards setting up the necessary structures for receiving and proposing block data from libp2p. Specifically, this PR contains a struct used to place pubsub message data to be sent to the manager for validation and the
BlockProposer
trait withsend_gossip_block
,send_own_block
,send_hello
to be used for communication between receiving/adding blocks and theChainManager
. For background, the manager in the context of the PR deals with incoming blocks and semantic validation as per the spec and go implementation.Below is further detail and context of the discussion I had with @ec2 and my interpretation of how go-filecoin handles incoming/outgoing data as it related to the
ChainManager
.For
SendGossipBlock
:See ProcessBlock for additional details.
Upon receiving a
pubsub message
to process a block for inclusion into the chain, the data contained within thepubsub message
is decoded, expanded on and placed in a struct for validation prior to propagation.The pubsub message should contain the following fields:
Source peerId
Sender peerId
Block Data
in bytesFrom Block Data you can derive the
head tipset keys
(CIDS), andheight
. These fields are placed insideBlockMsg
struct (as per PR), to be sent to the manager for semantic validation.For
SendOwnBlock
:See AddNewBlock for additional details.
While publishing a new block on the block topic, the fields required for validation are derived from the block and node and are placed in the
BlockMsg
struct to be sent to the manager for semantic validation.