-
Notifications
You must be signed in to change notification settings - Fork 243
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 support of executor gossip #219
Conversation
Now the gossip message for bundle and execution receipt can be sent and received, but still a lot of works to do.
`OpaqueExecutionReceipt` is introduced as `ExecutionReceipt` has both concrete type(`primary_hash`) and generic type `Hash`, used by the client submitting the external ER to runtime.
`GossipMessageHandler` has been changed from `async` to sync due to the `Validator` trait of network-gossip is not async and it's non-trivial to submit a patch to the upstream.
} | ||
|
||
#[derive(Decode, Encode, TypeInfo, PartialEq, Eq, Clone, RuntimeDebug)] | ||
pub struct OpaqueExecutionReceipt(Vec<u8>); |
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.
Why is this necessary? I think both nodes should understand ER fully and have it fully typed.
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.
The problem is that overseer doesn't understand this type as it does not know the Block::Hash
type but that's how ExecutionReceipt
is built.
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 we use a concrete type there then? It should be possible to transform generic type into this specific type and back if need be.
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.
A TODO noted b4c5372.
I was also thinking about if OpaqueExecutionReceipt
is really necessary but failed to make it compile, maybe just some Rust issues I haven't managed to fix, a TODO added anyway, will have a look later.
// - gossip the bundle to the executor peers | ||
// - OnBundleReceivedBySecondaryNode | ||
// - OnBundleEquivocationProof(farmer only) | ||
// - OnInvalidBundleProof(farmer only) | ||
async fn produce_bundle(self, slot_info: ExecutorSlotInfo) -> Option<BundleResult> { |
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.
Same question here, can't we use &self
?
/// Gossip engine messages topic. | ||
fn topic<Block: BlockT>() -> Block::Hash { | ||
<<Block::Header as HeaderT>::Hashing as HashT>::hash(b"executor") | ||
} |
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.
It only seems to be called in one place, so I'd just inline it
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.
It's indeed called once in executor-gossip/src/lib.rs
but called a few times in executor-gossip/src/worker.rs
.
The gossip message for bundle and execution receipt can be sent and
received as expected in the executor gossip network, the logic of
message_expired
and
message_allowed
is not final but should be on the right track.This PR will be squash merged.